Avoid resource contention with the help of VMware HA
Use VMware HA VM-to-VM rules and host groups and avoid resource contention. This can help balance resources between your production and testing and development VMs.
VMware High Availability rules ensure virtual workloads restart in the event of an issue with hosts or clusters. Although VMware has tweaked High Availability over the years, at its core, it remains mostly unchanged from the vSphere versions. However, although it has stayed consistent, the applications that depend on it have changed, and you must now use High Availability to avoid resource contention.
When HA was introduced, applications were still typically monolithic in design, and HA just needed to keep one or two servers together, such as a database and web server. As the typical application stack evolved from monolithic to distributed, HA's role in a VMware environment -- specifically, the way HA balances resources for different types of workloads, from testing and development to production -- has also changed. HA can also affect security and performance.
Evolution of the application stack
In previous generations of applications, it was easy to mix production with testing and development. Monolithic application stacks enabled a healthy mix of the two application types on a single host. As a result, in the event of a host failure, you didn't lose an all-production host. This also helped mitigate resource contention because you could limit testing and development's resources and funnel more resources into production.
Applications can't function without a few key pieces, such as databases and application cores. These can be starting points for setting up an HA grouping.
New application models have changed this setup. Now, there are more application clusters of VMs that provide for the same production application. This leads to questions about how to segment these clusters to prevent a host failure from affecting an application, or even whether you still should segment your clusters. It's likely you have an essential tier of VMs that an application requires, while a second tier provides helpful services, such as reporting or archiving.
Applications can't function without a few key pieces, such as databases and application cores. These can be starting points for setting up an HA grouping. Surround the primary pieces of an application, such as its database server, with web and application pieces that can take advantage of the performance benefits of sharing the same host. However, avoid putting multiple VMs that require high performance on the same host. Although this can reduce your overall application cluster size, you must then monitor the application's performance and adjust workload size and placement.
Balancing production versus testing and development servers
Over time, workload size has grown with cluster size. This growth has a direct effect on how many testing and development servers a host can hold. Larger workloads and clusters can reduce your ability to decrease testing and development resources in the event of resource contention, and they might force you to isolate larger groups of production VMs. This, in turn, can decrease your flexibility or your network speed.
If you enable VMware HA to keep certain production clusters with certain testing and development machines that don't require the same resources, you can mitigate some of the resource contention risk. You can create HA affinity rules for VM to VM, with the option of either keeping two VMs together or apart. You can also take advantage of VM groups and modify the "should run on" setting to balance performance and protection for your applications.
To do this, first create two VM groups: one group for your core application VMs and another for the testing and development servers with which you want your core VMs to share a host. Then, specify which host you want these VMs to run on. To do this, create a host group and then modify the "should run" rule to specify which application group and which group of testing and development VMs you want to run on which host.
Ensure you use the "should run" rule as opposed to "must run" in order to maintain some flexibility. "Should run" still gives application clusters the ability to run anywhere with a preference for a specific host.
HA and application rules
Although linking VMs and hosts in this way decreases the flexibility of HA, it does improve performance while maintaining HA protection.
Although this approach can complicate affinity rules, because it requires having a lot more groups and rules in place, you can reduce the number of VM-to-VM rules. What you gain is improved application performance with reduced physical network traffic -- both help you to avoid running into bottlenecks of resource contention. Those two benefits just might outweigh the additional effort and frustration of creating the rules to begin with.
