New DRS Groups and Rules, Would Like to Avoid vMotion Storm

[jonh3000]

Do the DRS groups and rules below look good for introducing to our cluster that has never had either?

Our current enterprise cluster (20 hosts running ESXi 5.5U2) has no DRS rules in place.  I'd like to introduce five new nodes to this cluster, but I don't want DRS (fully automated) to move our production critical VMs to these five nodes until they are sufficiently burned in.  We only want our non-production critical VMs to migrate to these new nodes for the time being.

DRS Group Manager

1. Create two 'Host DRS Groups':
   1. existing VM hosts
   2. new VM hosts
2. Create two 'VM DRS Groups':
   1. production critical VMs
   2. non-production critical VMs

Here are screenshots of the DRS rules that I haven't enabled yet.  Will DRS attempt to reshuffle all of the production critical VMs (1000 VMs) on these existing hosts or will it see that they already exist on these hosts and leave them alone?  Will it gracefully vMotion the 100 non-production critical VMs to the new hosts I'm bringing into this cluster?  I'd like to avoid creating havoc by having the 1000 production critical VMs shuffling around the existing VM hosts.

[Timothy_Wood]

Well, as always, the answer is simple. It depends.

It's my favorite answer.

There are two factors that are going to come into play here. First is how aggressive your DRS settings are configured (i.e. how "aggressive" or "conservative" you have the settings). The second is whether your current hosts are under load.

Someone smarter than me might know the algorithms DRS uses to determine when to move loads, but in my experience DRS does not attempt to simply balance workloads between all hosts in a cluster. Instead, workloads only migrate when the resources on a particular host hit certain thresholds, which then trigger then need to shuffle loads to another host. If your current hosts are not particularly maxed out in terms of resource usage and you add another bunch of hosts, then nothing will happen automatically. Over time you may see some movement, but again it will be based on host thresholds. If your current hosts are heavily loaded, then you should see things start to migrate fairly quickly.

The mixture of critical vs. non-critical loads on the hosts will be a factor as well. If all your existing hosts have an even mixture of critical and non-critical loads on them currently, and there are unloaded hosts that will only accept the non-critical loads (based on DRS rules), then I would expect that the non-critical hosts would rise to the top of the heap when host resources hit a threshold that will trigger a migration. And I would expect the critical hosts to be left where they are. If, on the other hand, you have some hosts that are unevenly loaded between critical and non-critical loads (say 75% critical vs. 25% non-critical), then your results will vary.

The resource sizing of your VMs will play a factor as well; if your critical loads tend to be larger than non-critical in terms of memory allocation, vCPUs, etc., then that will have an effect on how DRS decides to move things around.

It's not much of an answer, but resource scheduling is not a particularly simple topic.

Hope that helps in some little respect.

[a_p_ · Accepted solution]

With the two rules configured as "must" rules, and all VM's currently running on the "Existing VM Hosts", I'd expect that DRS will start migrating the "Non-Production Critical VMs"as soon as the rules are enabled. What I usually do when setting up DRS rules is to temporarily set DRS to "Manual", configure/add the rules, and then go to the DRS tab to see whet DRS recommends after pressing the "Run DRS" button. If the DRS recommendations match me expectations, I then set DRS to automatic again, and let DRS do its job.

André

[Timothy_Wood]

Good point, André. I missed the "must" in those rules. And I totally agree with setting DRS to manual before enabling those rules, particularly since he seems interested in avoiding a mass migration. Being able to preview the DRS recommendations prior to implementing them will bring the peace of mind he seems to be looking for.

Another alternative to avoid a "vMotion storm" would be to only add a few hosts at a time to the non-production critical VMs group, let those migrate, then add some more. This would allow a more controlled migration.