As with traditional physical servers, virtual machines (VMs) can also be clustered. A VM cluster starts with two or more physical servers; we'll call them Server A and Server B. In simple deployments, such as a VMware ESX cluster, if Server A fails, its workloads restart on Server B using VMware VMotion. But there is still some downtime between the failure of Server A and when its workloads restart on Server B. VMware Distributed Resource Scheduler and other tools can help balance virtual workloads between physical servers to prevent Server B from becoming overburdened.
A more recent and aggressive alternative is to employ redundant VM hosts on different physical host servers to improve virtual machine performance. For example, one instance of a workload is deployed on Server A, and a redundant copy of that workload is deployed on Server B. The servers within the VM cluster are interconnected with dedicated "heartbeat" signals, and the workloads are synchronized using high-availability software. In this case, if Server A fails, the redundant VM host instance on Server B picks up immediately with almost no downtime for users.
When configuring a VM cluster, it may be beneficial to establish a resource pool across the physical host servers. CPU, memory and other resources are defined and added to the pool, then allocated among the VM hosts to ensure that adequate computing power is available to each virtual workload. Otherwise, a workload with inadequate computing resources may perform poorly, become unstable or even crash.
Administrators can also leave some resources unused in case the computing demands of particular virtual workloads change. For example, if a certain VM needs more CPU cycles than the amount already assigned, more can be taken from the unused resource pool. Of course, there needs to be a limit on the resources that each VM can take.
Administrators have no way of knowing when trouble occurs with servers or resources, so it's important to invest the time and effort in configuring alarms for a VM cluster and its resources. Similarly, it's important to configure alarms for any time the resource pool runs low or any time a VM host demands excessive resources.
This was first published in January 2010