#VCAPorBUST Objective 3 – Implement and Manage Host Clusters – DRS

Welcome to the latest installment of the #VCAPorBUST series – aimed at preparing for VMware VCAP certifications.  You can see the rest of the articles in this series here.  Today we are going to talk about VMware DRS.  If you are looking for a more general, easy to understand overview of DRS, be sure to check out this VMware Basics article on DRS and vMotion.

DRS – Implement and Manage Host Clusters

VMware vSphere DRS, or Distributed Resource Scheduler, is one of the coolest vSphere features if I do say so myself.  DRS is one of the big brains behind your vSphere environment, it handles balancing the workload across your cluster.  There’s also VMware vSphere Storage DRS, or SDRS which behaves the same way, except it focuses on balancing storage performance over multiple datastores.

DRS and SDRS use vMotion and Storage vMotion to accomplish this.  Regular vMotion moves the CPU and Memory (the contents of memory are moved between hosts, before the VM starts running on the destination host), which is one of the reasons shared storage became so vital to vSphere environments.  Storage vMotion works in a similar manner, except instead of moving CPU and Memory, it is moving the files making up the VM.

There’s also a concept of shared-nothing vMotion, which I’m a huge fan of.  Besides shared storage, networks need to be available on both the source and destination hosts, host profiles are a great way to ensure that ESXi hosts are all configured the same way.

(Configuring DRS)

Let me take a step back here, before I start writing a soliloquy on what I think of these features and how I’ve used them.  I have to admit, writing this blog series has been interesting, and different than I expected.  As anyone who’s worked with VMware, or architecture, or infrastructure knows, many, many topics can fall in under the topic of “it depends”.

Configuring VMware DRS

How should I configure my VMware environment?  Well, “it depends”.  It depends on your budget, it depends on your business requirements, it depends on a lot of things.  Nothing is as simple as configure vSphere in this pre-defined prescriptive manner every time you deploy (unless, perhaps, you’re designing a data center in a rack type infrastructure with set requirements for each of your sites, see, here I go again).  Every time I write a topic I find myself wanting to go into the million different reasons why a feature may or may not be relevant, but I think I’m going to stay away from that for now – I’ll save methodology for future posts.  My goal with the DCA series is to review the information for my own study purposes.  Back to the regularly scheduled program.

I think there is a lot of confusion when people first start working with VMware.  DRS and vMotion are not the same thing, DRS uses vMotion in order to enforce the DRS policies, which there are a number of.  DRS is enabled and configured at the cluster level, and is required if resource pools are going to be used.  One of the key settings of DRS is the automation level of the cluster.  The options are Manual, Partially Automated, and Fully Automated.  Manual is exactly that, Manual.  Administrators will need to select the ESXi host that the VM will run on every time a VM is started.  In addition, it will not move VMs, but make recommendations that can be carried out by an administrator.  Partially Automated will decide where to place a VM when it is started, but will not move VMs automatically.  Fully Automated will place VMs and automatically move VMs within the cluster, depending on how you set the Migration Threshold.

Fun fact, older versions of VMware used the verbiage of “Star recommendations” and now the verbiage is “priority recommendations”.  DRS can also be set to run on a schedule, or manually invoked at any time, it takes a look at your cluster every 5 minutes.

DRS rules can also be configured.  You may want a group of VMs to stay on the same host, or to never be on the same host.  This is where you can set that up.  For example, I’ve created a rule that says the virtual machines. Scully and Mulder must always be on the same host.  I’ve also created another rule that says the virtual machines Mulder and SmokingMan should never be on the same host.  This is all done in the management section of your vSphere Cluster.

DRS groups can be configured to ensure VMs stay on the same host during a HA event, as vSphere HA doesn’t doesn’t pay attention to VM-VM affinity rules.  This can be especially useful when virtualizing Microsoft Clusters.  HA will only take into account VM-Host rules.  There is a great writeup of DRS groups in the Official vSphere 5.5 documentation.

(DPM is configured when configuring DRS)

Distributed Power Management, or DPM also falls into the DRS category.  When using DPM, DRS will migrate VMs off of hosts to evacuate them for power down.  When it is time for the Hosts to come back from the dead, DPM will use IPMI, HP iLO or WOL to resuscitate them.  If you’re using WOL, the vMotion NIC must support it.

Another feature that falls under this category is Enhanced vMotion Capability, or EVC allows migration of VMs between hosts of different CPU generations.  I’ve used this feature when migrating VMs to new hardware, by adding new hosts into a cluster of older hosts and utilizing vMotion that way.  Here is a great VMware KB with more information.  However, remember, you can’t use this feature to go between different processor architecture (AMD and Intel), just different CPU families (different generations of Opteron).

That’s a quick overview of DRS and the features associated with it.  Don’t forget to read through the vSphere Resource Management guide!