In addition to a handful of new features in vSphere 6.5, VMware introduced a number of significant updates to preexisting...
features. Among these was a facelift to its resource management services, including the Distributed Resource Scheduler and High Availability. In this article, we'll take an in-depth look at some of these updated vSphere 6.5 features.
New admission control default setting
Until vSphere 6, the default setting for admission control was to use High Availability (HA) slot calculation to set the number of tolerable host failures. This slot calculation creates problems in environments in which VM reservations are highly heterogeneous. For example, if you have a handful of VMs with no reservations and then a few with 8 GB RAM reservations, it causes a VM with 4 GB RAM to claim an 8 GB slot.
In previous versions of vSphere you could also use the percentage-based setting, but this method often resulted in users overcommitting clusters because they set their percentage too low. Even worse, in many deployments, the admission control policy would report that no resources were available, leading administrators to disable the feature entirely.
The default setting has been changed to use the cluster resource percentage setting, shown in Figure A, with VMware selecting the percentage for you based on the number of host failures you want to tolerate. For example, in a four-node cluster, the percentage would be 25% -- meaning one host failure could occur without compromising cluster availability.
Starting VMs in a predefined order after a failure
When an ESXi host fails, the VMs running on that host are automatically restarted on a different host. That's great, but when a VM is dependent on another VM to load its services, then loading the application stack may fail and your service won't be reinstated after a failure.
With vSphere 6.5 you can configure a list of dependencies for VMs that need to start before other VMs. This utility is called orchestrated restart and a typical use case is for tiered applications. You need to start your database server before the application server can contact it during startup; when that VM is fully loaded it's a good time to start the dependent web server. Another example would be to start certain infrastructure machines, such as a domain controller, Domain Name System or Dynamic Host Configuration Protocol server before starting other machines. This ability existed when using the restart priority, but it did not provide granular control over the exact restart order or delays.
With this new feature you can configure VM dependencies with a new VM/Host rule named Virtual Machines to Virtual Machines. The example shown in Figure B defines a rule that starts VMs in the Infrastructure VMs group before starting VMs from the Database VMs group.
When you have multiple VMs that need to be started and a larger dependency chain exists, then it's important that all machines are grouped and rules for all groups exist. Otherwise, VMs that are not in a group will start randomly and not in the right order. A complete listing for three groups could look like the one shown in Figure C. After the infrastructure machines are started, the database servers will start. Then, the application servers will start in phase two and the web servers in phase three.
You will have to configure one more setting before you can use this feature as intended. In the event of a failover, the next stage will continue only when the VMs in the previous stage are powered on and have claimed resources. This is also the behavior for when the priority setting is used: If all machines with high priority are started, HA continues onward to the medium level category and so on.
However, just because the machine has been powered on doesn't mean the OS or application on the VM is ready. Therefore, it's important to configure the new VM Dependency Restart Condition setting that allows you to configure HA to continue to the next phase when a condition is met. Under this setting, select Guest Heartbeats detected. This condition is triggered as soon as the VMware Tools start. This still doesn't guarantee that the application is running. In order to remedy this, choose the App Heartbeats detected option under the VM Dependency Restart Condition setting as shown in Figure D.
These restart conditions are also used when vSphere Availability progresses from one priority level to another. So, even without any rules configuring this setting, it is important in every HA cluster.
The feature for monitoring application status is not commonly used, especially after VMware stopped developing the vSphere App HA product and announced its end of life in 2015. The application programming interface that enables this feature has, however, been updated to work with new vSphere 6.5 features.
Veritas ApplicationHA is one of the few products to use this feature. Most customers, however, don't have such a product. As such, this dependency check still won't do 100% of what it promises to do. It's not uncommon for a database server to take longer to initialize, exceeding the time is takes for VMware Tools to report. This causes the next stage to kick in before the dependent application starts. To resolve this, some administrators have created their own scripts to check if another server or service is available before starting an application or service in a dependent machine.
VMware upgrades erase early year doubts
VSphere 6.5 rounds out a year of high and lows for VMware
VMware vSphere 6.5 keeps things simple
Test your vSphere 6.5 knowledge with this quiz