In setting up a Dynamic Resource Scheduling (DRS) cluster, there are various reasons to want to separate or group client systems together. For example, you may have a set of systems that communicate constantly in processing information and therefore you want them to be on the same ESX host. On the other side, you may be using an array of common service servers (such as domain controllers, mail gateways, etc.) that you want to keep separated to minimize their impact on each other. The first case is handled well in DRS, the latter can be very difficult to manage and maintain.
The exclusion problem
In VirtualCenter 2.5, you can set the Affinity rules by right-click on the cluster and then selecting “Edit Settings…”. This will bring up a dialog box that provides you the ability to set the options for High Availability (HA) and DRS. In particular, you can set the DRS affinity by clicking on the “Rules” option under VMware DRS. This will show you the current list of rules and give you the ability to add/remove/edit or obtain details about your rules.
By clicking on “Add…”, you get a new dialog box that asks you for a name of the new rule, the type of rule and the virtual machines that will participate in that rule.
So far, this is very simple and straight-forward. Let’s try a few examples to see where the complication begins.
In our first example, we have two mail servers that we want to keep on separate hosts. We will call the rule “Keep mail separated”. We can enter the name, select “Separate Virtual Machines” in the drop-down box for type and then click the “Add…” button to show a list of servers in the cluster to select from. In our case we will select smtp0 and smtp1. When we click “OK”, the rule will take effect and we are done.
In our next example, we have four mail servers that we want to keep on separate hosts. When we click on the “Add…” button to show a list of servers in the cluster, we select all of them and click “OK”, and now the problem shows up. A dialog box pops up telling us that this type of rule can only contain two virtual machines.
So, how do we get what we want? For four servers you will have to build six rules, since each rule can only have two members. You can determine the set of rules by the summation equation shown at the right. For four items, it is the sum of 3+2+1=6, so for eight clients it would be 7+6+5+4+3+2+1=28 separate rules. Try keeping that straight as you build your environment! The rules in our little example would be:
Name | Type | Virtual Machines |
Keep mail separated.1 | Separate Virtual Machines | smtp0, smtp1 |
Keep mail separated.2 | Separate Virtual Machines | smtp0,mail1 |
Keep mail separated.3 | Separate Virtual Machines | smtp0,smtp-cc |
Keep mail separated.4 | Separate Virtual Machines | smtp1,mail1 |
Keep mail separated.5 | Separate Virtual Machines | smtp1,smtp-cc |
Keep mail separated.6 | Separate Virtual Machine | mail1,smtp-cc |
Now, if you want to add a mail server to this cluster, you will have to add n-1 rules where n is now 5, for a total of 10 rules.
Confusion Continues
Suppose you now have all of these rules for your client separations. As you maintain and configure things, you may want to make changes or your list of rules scrolls beyond the size of the dialog box. While the system can maintain the list, users generally cannot. The issue here is that a rule can be duplicated one or more times and the system does not catch the duplicates. So, when you think you have deleted a condition or set of conditions by removing a rule, it may in fact not work as expected since the duplicate will still be in force. VMware needs to add logic here to detect and disable duplicates from being created, but in the meantime, users need to be careful in this area.
Conclusion
While it is possible to build a complicated set of rules for handling exclusion situations, the real answer is for VMware to fix this problem in the product. Just let the users select as many servers in the exclusion case as the inclusion case. Even if the software insists on binary rules for exclusion handling, that can all be handled behind the scenes where they can implement a four-way exclusion rule with six internal binary rules. It should not be the responsibility of the users to maintain that level of detail. If users want to exclude four domain controllers from running on a single ESX host, it should be a single rule to make this happen. Lets make software do its job and let administrators focus on the tasks at hand.
Pingback: Anonymous()