Use placement approaches to deliver HA and performance on VMware

Explore colocation and affinity to ensure virtual machine high availability in a VMware environment

High availability (HA) is an important feature that enables an enterprise to run business-critical applications without any unplanned downtime. There are many solutions to provide HA in the physical server environment, but with the pervasive introduction of cloud and other virtualized systems, businesses need methods to ensure HA for virtualized environments. The author details several methods to deliver HA for clouds, including anti-colocating a pair of servers over a hypervisor (to enable HA) and colocating the servers (to boost performance of the application that uses the resources on both servers).

Bhanu P Tholeti (btholeti@in.ibm.com), Systems Engineer and Architect, IBM

Author photoBhanuprakash has worked in the software industry since 2004 on various technologies and products such as application development for pocket PCs, web-based applications, video streaming solutions, and products like Tivoli® Workload Scheduler, WebSphere® Data Interchange, Tivoli Service Automation Manager, and Tivoli Provisioning Manager. He is part of IBM® SmartCloud Enterprise+, working on cloud infrastructures and hypervisors.



17 June 2014

Also available in Chinese Japanese

Enterprise computing relies on the concept of high availability (HA) because it delivers the capability of running business-critical applications — which must be available to clients and customers 24/7 — without the possibility of unplanned downtime.

Although technology professionals have been dealing with delivering HA for physical servers for quite a while now, delivering the same capability is still relatively new for virtualized resource environments. Regardless of the physical/virtual status of the system, though, HA still requires:

  • Two servers
  • A network connection (heartbeat)
  • Some sort of online/real-time replication between them or shared storage

Often, you will need to consider delivering HA in a virtualized environment in the context of balancing it with delivering performance because the two concepts carry some competing requirements.

To achieve HA in a virtualized system, you can complete this task by anti-colocating a pair of servers over a hypervisor. At the same time, you will colocate the servers to boost the performance of the application or applications that share resources residing in both servers. In this example, I will demonstrate how to do this in a VMware® hypervisor environment; I will provide definitions for anti-colocation and anti-affinity rules, colocation and affinity rules, and programmatic examples of how to achieve both of these states.

Anti-colocation and colocation

Now let's explore anti-colocation, colocation, and affinity rules; first, though, let's take a quick look at our virtualized sample environment.

VMware Distributed Resource Scheduler (DRS)

In a VMware virtualized environment of multiple ESX hosts forming a cluster in a data center, the cluster is enabled with the VMware Distributed Resource Scheduler (DRS). DRS ... dynamically balances computing capacity across a collection of hardware resources aggregated into logical resource pools, continuously monitoring utilization across resource pools, and intelligently allocating available resources among the virtual machines based on pre-defined rules. ... When a virtual machine experiences an increased load, VMware DRS automatically allocates additional resources by redistributing virtual machines among the physical servers in the resource pool. (From VMware DRS datasheet, PDF)

The DRS cluster is a collection of ESX/ESXi hosts and associated virtual machines with shared resources and a shared management interface; DRS is what enables dynamic resource sharing and allocation. When you add a host to a DRS cluster, the host's resources become part of the cluster's resources. In addition to this aggregation of resources, with a DRS cluster you can support cluster-wide resource pools and enforce cluster-level resource allocation policies.

Affinity rules are how you add some manual control to the dynamic, automated balance provided by VMware DRS.

Affinity and anti-affinity rules

An affinity rule is a setting that establishes a relationship between two or more VMware VMs and/or hosts. It is a tool that allows the developer or administrator to insert more fine-grained control over the load-balancing-oriented automatic placement of VMs that the VMware DRS performs.

Affinity rules and their anti-affinity counterparts tell the vSphere hypervisor platform to keep virtual entities together or separated; the "highest" affinity rule would be:

  • Keep VM-A and VM-B together on one host.

The "lowest" affinity rule (anti-affinity) would be:

  • Keep VM-A and VM-B apart on different hosts.

The goal of the rules is two-fold:

  • To reduce traffic across networks
  • To keep the virtual workload balanced on available hosts

For example, if two VMs communicate frequently, an affinity rule would keep them on the same host. Two resource-hungry VMs (that could overwhelm a single host's resources) could be kept on separate hosts by an anti-affinity rule.

Affinity and anti-affinity rules can be applied between VMs and hosts as well; a VM can be subject to both VM-to-VM and VM-to-host affinity rules at the same time. (In fact, different rules in a vSphere environment can conflict with one another, such as when two VMs with an anti-affinity relationship are linked to a third VM in an affinity relationship but can't share a host.)

With DRS, when you add or edit an affinity rule and the current cluster state violates the new/altered rule, the system will keep operating and trying to correct the violation. If your DRS cluster is manual or partially automated, DRS will offer you migration recommendations based on rule fulfillment and load balancing. If you make the changes, the recommendations will stop; if not, they keep coming.

Anti-colocation

For the purposes of this exercise, anti-colocation is an approach that provisions two virtual machines, paired to act as a cluster, on two different SysX ESX hosts. This approach means that if anything happens to one VM or to the host platform where the VM resides, the paired one can be made active because it is on a separate host platform; that way, applications running in the paired VM aren't affected by a failure in the other VM (or host platform).

In the process of provisioning the VMs in VMware using the vSphere APIs, most of the time it is the DRS that selects the host to which the VM will be deployed. (DRS uses performance and other factors in determining the best placement for your VMs.) This almost eliminates the programmer's need to calculate the overhead of resource capacity reservations, which can be a complex topic. There are other constraints that are hard to include in the DRS algorithm, however; those limitations can be configured using anti-affinity and affinity rules.

Colocation

As the name implies, colocation is the capability to make two virtual machines, paired to act as a cluster, provision on a single SysX ESX host to boost the performance of the application that utilizes the resources in both servers on the same host.

While provisioning the servers, DRS might select a different host for each of the two servers you want to pair and make them colocated. This colocation can be achieved after the two VMs are provisioned by setting an affinity rule between the VMs.

Next, let's explore a programmatical approach to anti-colocation in order to deliver high availability.


The programmatical approach for anti-affinity

Delivering HA in a virtualized environment (anti-colocating two VMs) can be done using this five-step approach using the VMware vSphere API.

Step 1: Acquire the managed object reference for both VMs

Get the managed object reference (MOR) that you want to anti-colocate for both the VMs:

ManagedObjectReference vm1 = objRef.getVMMorByUUID(vmUUID_vm1);
 //Getting the VM MOR by the VM UUID, 
   we can also get from the vmname, by using getVMMORByName.
ManagedObjectReference vm2 = objRef.getVMMorByUUID(vmUUID_vm2);

You can use your own methods (that do the same thing as objRef.getVMMorByUUID) to retrieve the MOR from vSphere for any specified vSphere-Data.

Step 2: Get the MOR for VM's host platforms

Next, get the MOR for both VM's host platforms.

ManagedObjectReference vm1hostMor = (ManagedObjectReference 
 )objRef.getObjectProperty(vm1, "summary.runtime.host");
ManagedObjectReference vm2hostMor = (ManagedObjectReference 
 )objRef.getObjectProperty(vm2, "summary.runtime.host");

Again, you can use your own methods like I have with getObjectProperty to retrieve properties from vSphere for any specified vSphere-managed object references.

Step 3: Create and populate a new complete cluster configuration

Create a new ClusterConfigSpec and populate it with related data for the anti-affinity rule; the ones shown here are vSphere-provided data objects.

String rulename = "antiAffinityRule_vm1_vm2"
ClusterConfigSpecEx ccs = new ClusterConfigSpecEx();
ClusterAntiAffinityRuleSpec cars = new ClusterAntiAffinityRuleSpec();
cars.setName(ruleName);
cars.setEnabled(Boolean.TRUE);
cars.setVm(new ManagedObjectReference[] {vm1, vm2});

ClusterRuleSpec crs = new ClusterRuleSpec();
//*NOTE*: the following setOperation has to be called because operation must be set.
crs.setOperation(ArrayUpdateOperation.add);
crs.setInfo(cars);
ccs.setRulesSpec(new ClusterRuleSpec[] {crs});

Step 4: Reconfigure the cluster

Now reconfigure the cluster in which the VMs reside with the configspecobject you just created.

//get the cluster compute resource object MOR.

ManagedObjectReference clusterMor = objRef.getMorByValue("ClusterComputeResource", 
 "name", clusterName);//User should know the cluster name in the vcenter.

//set the configspecobject with anti-affinity rule into the cluster.

ManagedObjectReference taskMor = 
 _service.reconfigureComputeResource_Task(clusterMor, ccs, true);

//now monitor the task status

String taskResult = null;
taskResult = getTaskResultAfterDone(taskMor);

if (taskResult.equals("error")) {
       LocalizedMethodFault mf = (LocalizedMethodFault) objRef
              .getValsFromProperty("info.error", taskMor)[0];
       taskResult = taskResult.toUpperCase() + ": "
              + mf.getFault().getClass().getName()
              + " occurred when reconfiguring cluster " + clusterMor + ". "
              + mf.getLocalizedMessage();
       System.Out.Println(taskResult);
} else {
if (taskResult.equals("success")) {
       System.Out.Println("Anti-affinity rule set successfully !");
}
}

Step 5: Initiate the migration of the VM

Now you have to initiate the migration of the VM (vm2) so that the migration process gets to check the rule that we set in Step 3 and make the VM move to a host that is different from the host containing the other VM.

//here we are migrating the vm2.
ManagedObjectReference taskMor1 = _service.migrateVM_Task(vm2, null, null,  
 VirtualMachineMovePriority.highPriority,
 VirtualMachinePowerState.poweredOn);
 
//Monitor the task status
taskResult = getTaskResultAfterDone(taskMor1);

if (taskResult.equals("error")) {
       LocalizedMethodFault mf = (LocalizedMethodFault) objRef
              .getValsFromProperty("info.error", taskMor1)[0];

taskResult = taskResult.toUpperCase() + ": "
              + mf.getFault().getClass().getName()
              + " occurred when reconfiguring cluster " + clusterMor + ". "
              + mf.getLocalizedMessage();
System.Out.Println(taskResult);

} else {

if (taskResult.equals("success")) {
       System.Out.Println("Migration of VM using DRS RULE '" + ruleName +"' 
       successfully initiated !");
}
}

You are done migrating vm2; when you check now, vm2 will have a different host than vm1.


The programmatical approach for affinity

Managing performance in a virtualized, HA environment (colocating two VMs; making sure both are on the same host platform in a cluster) can be done using the same five-step approach to achieve anti-affinity, albeit with a change to Step 3. (Steps 1, 2, 4, and 5 are the same.)

Step 3: Create and populate a new complete cluster configuration

Create a new ClusterConfigSpec and populate it with related data for the affinity rule; the ones shown here are vSphere-provided data objects.

String rulename = "AffinityRule_vm1_vm2"
ClusterConfigSpecEx ccs = new ClusterConfigSpecEx();
//the following line is the only change.
ClusterAffinityRuleSpec cars = new ClusterAffinityRuleSpec();
cars.setName(ruleName);
cars.setEnabled(Boolean.TRUE);
cars.setVm(new ManagedObjectReference[] {vm1, vm2});

ClusterRuleSpec crs = new ClusterRuleSpec();
//*NOTE*: the following setOperation has to be called because operation must be set.
crs.setOperation(ArrayUpdateOperation.add);
crs.setInfo(cars);
ccs.setRulesSpec(new ClusterRuleSpec[] {crs});

Conclusion

The techniques I've provided in this article are the simplest ways to anti-colocate and colocate a pair of VMs in a virtualized environment in order both to deliver high availability by keeping VMs on separate host platforms and to boost performance by binding VMs to each other on the same host platforms.

Resources

Learn

Get products and technologies

Discuss

  • Get involved in the developerWorks community. Connect with other developerWorks users while exploring the developer-driven blogs, forums, groups, and wikis.

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Cloud computing on developerWorks


  • Bluemix Developers Community

    Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.

  • Cloud digest

    Complete cloud software, infrastructure, and platform knowledge.

  • DevOps Services

    Software development in the cloud. Register today to create a project.

  • Try SoftLayer Cloud

    Deploy public cloud instances in as few as 5 minutes. Try the SoftLayer public cloud instance for one month.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Cloud computing
ArticleID=974708
ArticleTitle=Use placement approaches to deliver HA and performance on VMware
publish-date=06172014