Everyday Virtualization

Separating VMs in a Sub-Cluster

You may want to implement a sub-cluster within a VMware DRS cluster for a number of reason.

• By Rick Vanover
• 11/04/2010

You may want to implement a sub-cluster within a VMware DRS cluster for a number of reason. Let's start with what I mean by 'sub-cluster' in terms of traditional configuration. Within vSphere, the cluster entity is a collection of hosts, rules and virtual machines. Prior to vSphere 4.1, there was no native way to split or subjugate the host resources into smaller units while being part of the parent within the normal operations of DRS.

Before vSphere 4.1, the only way I determined to (easily) implement an effective sub-cluster was to provision different virtual machine port groups for selected hosts. For example, there could be a VLAN 799 on which all virtual machines are connected. To separate a cluster, two of the hosts could call VLAN 799 one name in the port group and the rest of the hosts would use a different name for VLAN 799's port group. This would ensure that a virtual machine with the correct port group lands on the designed 'pool' of hosts.

vSphere 4.1 makes that much easier with the introduction of DRS Groups. DRS Groups are one of the many features to the updated offering of DRS within version 4.1. Fig. 1 shows the DRS Group area of the cluster properties.

Figure 1. vSphere 4.1 delivers expanded capabilities to DRS clusters with host-based DRS Groups. (Click image to view larger version.)

The DRS Group fun doesn't stop there as there also a DRS Group object for guest virtual machines, which functions in the same fashion. Fig. 2 shows a guest virtual machine DRS Group being created.

Figure 2. Like hosts, guest can be in a DRS Group. (Click image to view larger version.)

This naturally flows into the creation of expanded DRS rules. This includes host residence requirements and recommendations. The standard DRS complexity warning should follow also, as a guest virtual machine as well as host can be a member of multiple DRS Groups. This becomes additional overhead to the already complicated DRS algorithm. The rules process is expanded to include the new group functionality for cluster configuration options, as shown in Fig. 3.

Figure 3. DRS rules can now be expanded to include host residence requirements. (Click image to view larger version.)

The primary use cases for creating an effective sub-cluster include separating development and production, licensing reasons or intentional light workloads on hosts. The DRS Group is a much easier than what hoops we had to go through in previous versions, and will surely allow administrators to allow a more granular control to where virtual machines reside.

Have you used the new DRS Group functionality? Share your comments here.