Section 9: Configure and Administer vSphere Availability Solutions
Objective 9.1: Configure Advanced vSphere HA Features: In this objective we should be covering these topics:
- Explain Advanced vSphere HA settings
- Enable/Disable Advanced vSphere HA settings
- Explain how vSphere HA interprets heartbeats
- Interpret and correct errors during conversion
- Identify virtual machine override priorities
- Identify Virtual Machine Component Protection (VMCP) settings
vSphere HA Advanced Options
You can set advanced options that affect the behavior of your vSphere HA cluster.
vSphere HA Advanced Options
Note
If you change the value of any of the following advanced options, you must disable and then re-enable vSphere HA before your changes take effect.
■ das.isolationaddress[…]
■ das.usedefaultisolationaddress
■ das.isolationshutdowntimeout
For a complete list of vSphere HA advanced options, see the VMware knowledge base article at http://kb.vmware.com/kb/2033250.
Set Advanced Options
To customize vSphere HA behavior, set advanced vSphere HA options.
Prerequisites
Verify that you have cluster administrator privileges.
Procedure
1. In the vSphere Web Client, browse to the vSphere HA cluster.
2. Click the Manage tab and click Settings.
3. Under Settings, select vSphere HA and click Edit.
4. Expand Advanced Options.
5. Click Add and type the name of the advanced option in the text box. You can set the value of the option in the text box in the Value column.
6. Repeat step 5 for each new option that you want to add and click OK.
The cluster uses the options that you added or modified.
What to do next
Once you have set an advanced vSphere HA option, it persists until you do one the following:
■ Using the vSphere Web Client, reset its value to the default value.
■ Manually edit or delete the option from the fdm.cfg file on all hosts in the cluster.
Customize an Individual Virtual Machine
Each virtual machine in a vSphere HA cluster is assigned the cluster default settings for VM Restart Priority, Host Isolation Response, VM Component Protection, and VM Monitoring. You can specify specific behavior for each virtual machine by changing these defaults. If the virtual machine leaves the cluster, these settings are lost.
Procedure
1. In the vSphere Web Client, browse to the vSphere HA cluster.
2. Click the Manage tab and click Settings.
3. Under Settings, select VM Overrides and click Add.
4. Use the + button to select virtual machines to which to apply the overrides.
5. Click OK.
6. (Optional) You can change other settings, such as the Automation level, VM restart priority, Host isolation response, VMCP settings,VM Monitoring, or VM monitoring sensitivity settings.
Note
You can view the cluster defaults for these settings by first expanding Relevant Cluster Settings and then expanding vSphere HA.
7. Click OK.
The virtual machine’s behavior now differs from the cluster defaults for each setting that you changed.
Datastore Heartbeating
When the master host in a vSphere HA cluster can not communicate with a slave host over the management network, the master host uses datastore heartbeating to determine whether the slave host has failed, is in a network partition, or is network isolated. If the slave host has stopped datastore heartbeating, it is considered to have failed and its virtual machines are restarted elsewhere.
vCenter Server selects a preferred set of datastores for heartbeating. This selection is made to maximize the number of hosts that have access to a heartbeating datastore and minimize the likelihood that the datastores are backed by the same LUN or NFS server.
You can use the advanced option das.heartbeatdsperhost to change the number of heartbeat datastores selected by vCenter Server for each host. The default is two and the maximum valid value is five.
vSphere HA creates a directory at the root of each datastore that is used for both datastore heartbeating and for persisting the set of protected virtual machines. The name of the directory is .vSphere-HA. Do not delete or modify the files stored in this directory, because this can have an impact on operations. Because more than one cluster might use a datastore, subdirectories for this directory are created for each cluster. Root owns these directories and files and only root can read and write to them. The disk space used by vSphere HA depends on several factors including which VMFS version is in use and the number of hosts that use the datastore for heartbeating. With vmfs3, the maximum usage is approximately 2GB and the typical usage is approximately 3MB. With vmfs5 the maximum and typical usage is approximately 3MB. vSphere HA use of the datastores adds negligible overhead and has no performance impact on other datastore operations.
vSphere HA limits the number of virtual machines that can have configuration files on a single datastore. See Configuration Maximums for updated limits. If you place more than this number of virtual machines on a datastore and power them on, vSphere HA protects a number of virtual machines only up to the limit.
Note
A Virtual SAN datastore cannot be used for datastore heartbeating. Therefore, if no other shared storage is accessible to all hosts in the cluster, there can be no heartbeat datastores in use. However, if you have storage that can be reached by an alternate network path that is independent of the Virtual SAN network, you can use it to set up a heartbeat datastore.
VM Component Protection
If VM Component Protection (VMCP) is enabled, vSphere HA can detect datastore accessibility failures and provide automated recovery for affected virtual machines.
VMCP provides protection against datastore accessibility failures that can affect a virtual machine running on a host in a vSphere HA cluster. When a datastore accessibility failure occurs, the affected host can no longer access the storage path for a specific datastore. You can determine the response that vSphere HA will make to such a failure, ranging from the creation of event alarms to virtual machine restarts on other hosts.
Types of Failure
There are two types of datastore accessibility failure:
PDL
PDL (Permanent Device Loss) is an unrecoverable loss of accessibility that occurs when a storage device reports the datastore is no longer accessible by the host. This condition cannot be reverted without powering off virtual machines.
APD
APD (All Paths Down) represents a transient or unknown accessibility loss or any other unidentified delay in I/O processing. This type of accessibility issue is recoverable.
Configuring VMCP
VM Component Protection is enabled and configured in the vSphere Web Client. To enable this feature, you must select the Protect against Storage Connectivity Loss checkbox in the edit cluster settings wizard. The storage protection levels you can choose and the virtual machine remediation actions available differ depending on the type of database accessibility failure.
PDL failures
A virtual machine is automatically failed over to a new host unless you have configured VMCP only to Issue events.
APD events
The response to APD events is more complex and accordingly the configuration is more fine-grained.
After the user-configured Delay for VM failover for APD period has elapsed, the action taken depends on the policy you selected. An event will be issued and the virtual machine is restarted conservatively or aggressively. The conservative approach does not terminate the virtual machine if the success of the failover is unknown, for example in a network partition. The aggressive approach does terminate the virtual machine under these conditions. Neither approach terminates the virtual machine if there are insufficient resources in the cluster for the failover to succeed.
If APD recovers before the user-configured Delay for VM failover for APD period has elapsed, you can choose to reset the affected virtual machines, which recovers the guest applications that were impacted by the IO failures.
Configure Virtual Machine Responses
The Failure conditions and VM response page allows you to choose settings that determine how vSphere HA responds to host failures and isolations. These settings include the VM restart priority, host isolation response, settings for VM Component Protection, and VM monitoring sensitivity.
Virtual Machine Response page is editable only if you enabled vSphere HA.
Procedure
1. In the vSphere Web Client, browse to the vSphere HA cluster.
2. Click the Manage tab and click Settings.
3. Under Settings, select vSphere HA and click Edit.
4. Expand Failure Conditions and VM Response to display the configuration options.
5. Click OK.
Your Virtual Machine Response settings take effect.
vSphere HA Checklist
The vSphere HA checklist contains requirements that you must be aware of before creating and using a vSphere HA cluster.
Review this list before you set up a vSphere HA cluster. For more information, follow the appropriate cross reference.
■ All hosts must be licensed for vSphere HA.
■ A cluster must contain at least two hosts.
■ All hosts must be configured with static IP addresses. If you are using DHCP, you must ensure that the address for each host persists across reboots.
■ All hosts must have at least one management network in common. The best practice is to have at least two management networks in common. You should use the VMkernel network with the Management traffic checkbox enabled. The networks must be accessible to each other and vCenter Server and the hosts must be accessible to each other on the management networks. SeeBest Practices for Networking.
■ To ensure that any virtual machine can run on any host in the cluster, all hosts must have access to the same virtual machine networks and datastores. Similarly, virtual machines must be located on shared, not local, storage otherwise they cannot be failed over in the case of a host failure.
Note
vSphere HA uses datastore heartbeating to distinguish between partitioned, isolated, and failed hosts. So if some datastores are more reliable in your environment, configure vSphere HA to give preference to them.
■ For VM Monitoring to work, VMware tools must be installed. See VM and Application Monitoring.
■ vSphere HA supports both IPv4 and IPv6. See Other vSphere HA Interoperability Issues for considerations when using IPv6.
■ For VM Component Protection to work, hosts must have the All Paths Down (APD) Timeout feature enabled.
■ To use VM Component Protection, clusters must contain ESXi 6.0 hosts or later.
■ Only vSphere HA clusters that contain ESXi 6.0 or later hosts can be used to enable VMCP. Clusters that contain hosts from an earlier release cannot enable VMCP, and such hosts cannot be added to a VMCP-enabled cluster.
■ If your cluster uses Virtual Volume (vVol) datastores, when vSphere HA is enabled a configuration vVol is created on each vVol datastore by vCenter Server. In these containers, vSphere HA stores the files it uses to protect virtual machines. vSphere HA does not function correctly if you delete these containers. Only one container is created per vVol datastore.
vWannabe 