Archive for June, 2007

IT Policies: Monitoring Physical and Virtual Environments

This article was first published on SearchServerVirtualization.TechTarget.com.

Here’s quick question: How many virtual machines and physical servers are currently running on your production environment? If you can answer that, congratulations! Here’s a harder one: Identify the top 10 physical or virtual machines based on resource utilization. For most IT organizations, both of these questions can be difficult to answer. Fortunately, there are ways to implement monitoring in an automated way. In this tip, I’ll present some advice related to monitoring VMs and host computers in a production environment.

They’re all pretty much the same…

In many ways, the tasks associated with monitoring virtual machines are similar to those of working with physical ones. Organizations that have invested in centralized monitoring solutions can continue to rely upon them for gaining insight into how applications and services are performing. Examples include:

  • Establishing Baselines: A baseline helps you determine the standard level of resource utilization for a physical or virtual workload. Details to track typically include CPU, memory, disk, and network performance.
  • Root-Cause Analysis / Troubleshooting: When users complain of slow performance, it’s important for IT staff to be able to drill-down into the main cause of the problem. Performance statistics can often help identify which resources are constrained. Ideally, that will help identify the source of the problem and provide strong hints about resolving them.
  • Generating Alerts: In order to proactively manage performance, IT staff should be alerted whenever resource utilization exceeds certain thresholds. This can help reconfigure workloads

All of these tasks are fairly standard in many IT environments and are also applicable to working with virtual workloads.

… Except for their differences

Environments that use virtualization also have some unique challenges related to performance monitoring. Since it’s quick and easy to deploy new VMs, keeping track of them is a huge challenge. Some additional features and functions that can be helpful include:

  • Mapping Guest-to-Host Relationships: While virtual machines have their own operating system, resource utilization is often tied to other activity on the same host server. Virtualization-aware monitoring tools should be able to uniquely identify VMs and relate them to the physical computers on which they are running.
  • Automated Responses / Dynamic Reconfiguration: In many cases, it’s possible to perform automated tasks in reaction to performance-related issues. For example, if CPU usage of a single VM is slowing down the entire host, VM priority settings can be adjusted. Or, when excessive paging is occurring, the VM’s memory allocation can be increased.
  • Broad Platform Support: There’s a good chance that you’re supporting many more OS versions and flavors for VMs than on physical machines. A good performance monitoring solution will support the majority of virtual operating environments.
  • Reporting / Capacity Planning: The primary purpose of performance monitoring is to facilitate better decision-making. Advanced reporting features can help track untapped resources and identify host servers that are overloaded. Tracking historical performance statistics can also be very helpful.

Choosing the Right Tools for the Job

Most operating systems provide simple tools for troubleshooting performance issues on a single or a few computers. In environments that support more than a few VMs, automated performance monitoring and management tools are practically a must-have. Figure 1 provides some details into features that can be useful.

image

Figure 1: Features to look for in performance management tools

Summary

Overall, many of the standard IT best practices apply equally to monitoring physical and virtual machines. When searching for tools to get the job done, however, there are certain features that can dramatically reduce the time and effort required to gain insight into production performance.

IT Policies: Service Level Agreements (SLAs)

This article was first published on SearchServerVirtualization.TechTarget.com.

Have you heard the one about the IT department whose goals were not well-aligned with the needs of its users? OK, so that’s probably not a very good setup for a joke. One of the most common challenges faced by most IT organizations is defining their internal customers’ requirements and delivering services based on them. In this Tip, I’ll provide details on how you can define Service Level Agreements (SLAs) and how you can use them to better manage virtualization and to reduce costs.

Agreeing to Service Level Agreements

Challenges related to deploying virtualization include skepticism related to the technology. This often reads to resistance and a lack of knowledge about the potential cost and management benefits of using virtual machines.

The purpose of a Service Level Agreement is to define, prioritize, and document the real needs of an organization. All too often, IT departments tend to work in a relatively vacuum, focusing on technology. The area of virtualization is no exception – it’s often much easier to create and deploy VMs than it is to determine the strategic needs of the company. The problems range from poorly managing users’ expectations to large costs that might not directly address the most important challenges. The goal of containing costs is the basis for a lot of virtualization decisions, so it’s important to keep this in mind.

When developing SLAs, the most important aspect is for the process to be a team effort. Managers, IT staff, and end-users should all have input into the process. Typical steps in the process are shown in Figure 1.

image

Figure 1: Steps in the process of creating a new SLA

Defining SLA Goals and Metrics

SLA goals define the targeted levels of service that are to be expected from IT departments. Metrics are the specific statistics and data that must be measured to ensure that the levels are being met. Some examples might include:

  • Deployment: The time it takes to provision a new VM
  • Performance: Ensuring adequate application and service response times
  • Availability: Verifying virtual machine uptime
  • Change Management: Efficiently managing VM configuration updates

A well-defined SLA should include details about how the quality of the service is measured. For example, the goal for the uptime of a particular VM might be 99.9%. This can be measured using standard enterprise monitoring tools. Or, the deployment goal for a standard configuration of a virtual machine might be 4 business hours from the time of the request.

Reducing Costs with SLAs

If you haven’t yet created SLAs, you might be thinking about the time and effort that it will take to setup and track the associated metrics. While there is certainly a cost to be paid for creating SLAs, there can also be numerous benefits. One important aspect is that areas for improvement can easily be identified. For example, if a business finds that it could improve its operations by more quickly deploying VMs, an investment in automation could help. Table 1 provides that and some other hypothetical examples.

image

Table 1: Examples of potential cost savings based on automation

Summary

IT organizations that constantly find themselves trying to keep up with virtualization-related requirements can benefit by creating SLAs. When done properly, this will help technical initiatives (such as VM deployments and server consolidations) stay in line with users’ expectations. Overall, this can help the entire organization make better decisions about the importance of virtual infrastructures.