Get started Bring yourself up to speed with our introductory content.

New vSphere 6.5 features: Updates to DRS, High Availability and more

The latest version of vSphere offers major improvements to VMware resource management services, including the Distributed Resource Scheduler and High Availability.

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.

The cluster resource percentage setting.
Figure A. Defining host failover capacity with the cluster resource percentage setting.

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.

Creating a VM/Host rule.
Creating a VM/Host rule with Virtual Machines to Virtual Machines.

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.

Established VM/Host rules.
Established VM/Host rules.

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.

VM Dependency Restart Condition.
Figure D. Using the VM Dependency Restart Condition setting.

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.

Next Steps

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

This was last published in December 2016

Dig Deeper on VMware new releases and updates

Join the conversation

1 comment

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

What can VMware do to further improve its resource management services?
Cancel

-ADS BY GOOGLE

SearchServerVirtualization

SearchVirtualDesktop

SearchDataCenter

SearchCloudComputing

Close