Clusters and High Availability

This chapter is from the book

VCP-DCV for vSphere 8.x Cert Guide, 5th Edition

Learn More Buy

This chapter is from the book

This chapter is from the book 

VCP-DCV for vSphere 8.x Cert Guide, 5th Edition

Learn More Buy

Other Resource Management and Availability Features

This section describes other vSphere features related to resource management and availability.

Predictive DRS

Predictive DRS is a feature in vSphere 6.5 and later that leverages the predictive analytics of VMware Aria Operations, formerly known as vRealize Operations (vROps), and vSphere DRS. Together, these two products can provide workload balancing prior to the occurrence of resource utilization spikes and resource contention. Every night, Aria Operations calculates dynamic thresholds, which are used to create forecasted metrics for the future utilization of virtual machines. Aria Operations passes the predictive metrics to vSphere DRS to determine the best placement and balance of virtual machines before resource utilization spikes occur. Predictive DRS helps prevent resource contention on hosts that run virtual machines with predictable utilization patterns.

The following prerequisites are needed to run Predictive DRS:

• vCenter Server 6.5 or later is required.

• Predictive DRS must be configured and enabled in both vCenter Server and Aria Operations.

• The vCenter Server and Aria Operations clocks must be synchronized.

Distributed Power Management (DPM)

The vSphere Distributed Power Management (DPM) feature enables a DRS cluster to reduce its power consumption by powering hosts on and off, as needed, based on cluster resource utilization. DPM monitors the cumulative virtual machine demand for memory and CPU resources in the cluster and compares this to the available resources in the cluster. If sufficient excess capacity is found, vSphere DPM directs the host to enter Standby Mode. When DRS detects that a host is entering Standby Mode, it evacuates the virtual machines. Once the host is evacuated, DPM powers it off, and the host is in Standby Mode. When DPM determines that capacity is inadequate to meet the resource demand, DPM brings a host out of Standby Mode by powering it on. Once the host exits Standby Mode, DRS migrates virtual machines to it.

To power on a host, DPM can use one of three power management protocols: Intelligent Platform Management Interface (IPMI), Hewlett-Packard Integrated Lights-Out (iLO), or Wake-on-LAN (WoL). If a host supports multiple protocols, they are used in the following order: IPMI, iLO, WOL. If a host does not support one of these protocols, DPM cannot automatically bring a host out of Standby Mode.

DPM is very configurable. As with DRS, you can set DPM’s automation to be manual or automatic.

To configure IPMI or iLO settings for a host, you can edit the host’s Power Management settings. You should provide credentials for the Baseboard Management Controller (BMC) account, the IP address of the appropriate NIC, and the MAC address of the NIC.

Using WOL with DPM requires that the following prerequisites be met:

• ESXi 3.5 or later is required.

• vMotion must be configured.

• The vMotion NIC must support WOL.

• The physical switch port must be set to automatically negotiate the link speed.

Before enabling DPM, use the vSphere Client to request the host to enter Standby Mode. After the host powers down, right-click the host and attempt to power on. If this is successful, you can allow the host to participate in DPM. Otherwise, you should disable power management for the host.

You can enable DPM in a DRS cluster’s settings. You can set Automation Level to Off, Manual, or Automatic. When this option is set to Off, DPM is disabled. When it is set to Manual, DPM makes recommendations only. When it is set to Automatic, DPM automatically performs host power operations as needed.

Much as with DRS, with DPM you can control the aggressiveness of DPM (that is, the DPM threshold) with a slider bar in the vSphere Client. The DRS threshold and the DPM threshold are independent of one another. You can override automation settings per host. For example, for a 16-host cluster, you might want to set DPM Automation to Automatic on only 8 of the hosts.

Fault Tolerance (FT)

If you have virtual machines that require continuous availability as opposed to high availability, you can consider protecting the virtual machines with vSphere Fault Tolerance (FT). vSphere FT provides continuous availability for a virtual machine (the primary VM) by ensuring that the state of a secondary VM is identical at any point in the instruction execution of the virtual machine.

If the host running the primary VM fails, an immediate and transparent failover occurs. The secondary VM becomes the primary VM host without losing network connection or in-progress transactions. With transparent failover, there is no data loss, and network connections are maintained. The failover is fully automated and occurs even if vCenter Server is unavailable. Following the failover, FT spawns a new secondary VM and reestablishes redundancy and protection, assuming that a host with sufficient resources is available in the cluster. Likewise, if the host running the secondary VM fails, a new secondary VM is deployed. vSphere Fault Tolerance can accommodate symmetric multiprocessor (SMP) virtual machines with up to eight vCPUs.

Use cases for FT include the following:

• Applications that require continuous availability, especially those with long-lasting client connections that need to be maintained during hardware failure

• Custom applications that have no other way of being clustered

• Cases in which other clustering solutions are available but are too complicated or expensive to configure and maintain

Before implementing FT, consider the following requirements:

• CPUs must be vMotion compatible.

• CPUs must support hardware MMU virtualization.

• A low-latency 10 Gbps network is required for FT Logging.

• Virtual machine files other than VMDK files must be stored on shared storage.

• A vSphere Standard License is required for FT protection of virtual machines with up to two virtual CPUs.

• A vSphere Enterprise Plus License is required for FT protection of virtual machines with up to eight virtual CPUs.

• Hardware Virtualization (HV) must be enabled in the host BIOS.

• Hosts must be certified for FT.

• The virtual memory reservation should be set to match the memory size.

• vSphere HA must be enabled on the cluster.

• SSL certificate checking must be enabled in the vCenter Server settings.

• The hosts must use ESXi 6.x or later.

You should also consider the following VMware recommendations concerning vSphere FT:

• VMware recommends a minimum of two physical NICs.

• VMware recommends that the host BIOS power management settings be set to Maximum Performance or OS-Managed Performance.

• You should have at least three hosts in the cluster to accommodate a new secondary VM following a failover.

The following vSphere features are not supported for FT-protected virtual machines:

• Snapshots (An exception is that disk-only snapshots created for vStorage APIs for Data Protection [VADP] backups are supported for FT but not for legacy FT.)

• Storage vMotion

• Linked clones

• Virtual Volumes datastores

• Storage-based policy management (However, vSAN storage policies are supported.)

• I/O filters

• Disk encryption

• Trusted Platform Module (TPM)

• Virtual Based Security (VBS)–enabled VMs

• Universal Point in Time snapshots (a next-generation vSAN feature)

• Physical raw device mappings (RDMs) (However, virtual RDMs are supported for legacy FT.)

• Virtual CD-ROMs for floppy drives backed by physical devices

• USB devices, sound devices, serial ports, and parallel ports

  • N-Port ID Virtualization (NPIV)

• Network adapter passthrough

• Hot plugging devices (Note that the hot plug feature is automatically disabled when you enable FT on a virtual machine.)

• Changing the network where a virtual NIC is connected

• Virtual Machine Communication Interface (VMCI)

• Virtual disk files larger than 2 TB

• Video devices with 3D enabled

You should apply the following best practices for FT:

• Use similar CPU frequencies in the hosts.

• Use active/standby NIC teaming settings.

• Ensure that the FT Logging network is secure (that is, FT data is not encrypted).

• Enable jumbo frames and 10 Gbps for the FT network. Optionally, configure multiple NICs for FT Logging.

• Place ISO files on shared storage.

• If vSAN is used for primary or secondary VMs, do not also connect those virtual machines to other storage types. Also, place the primary and secondary VMs in separate vSAN fault domains.

• Keep vSAN and FT Logging on separate networks.

In vSphere 6.5, FT is supported with DRS only when EVC is enabled. You can assign a DRS automation to the primary VM and let the secondary VM assume the same setting. If you enable FT for a virtual machine in a cluster where EVC is disabled, the virtual machine DRS automation level is automatically disabled. In versions since vSphere 6.7, EVC is not required for FT to support DRS.

To enable FT, you first create a VMkernel virtual network adapter on each host and connect to the FT Logging network. You should enable vMotion on a separate VMkernel adapter and network.

When you enable FT protection for a virtual machine, the following events occur:

• If the primary VM is powered on, validation tests occur. If validation is passed, then the entire state of the primary VM is copied and used to create the secondary VM on a separate host. The secondary VM is powered on. The virtual machine’s FT status is Protected.

• If the primary VM is powered off, the secondary VM is created and registered to a host in the cluster but not powered on. The virtual machine FT Status setting is Not Protected, VM not Running. When you power on the primary VM, the validation checks occur, and the secondary VM is powered on. Then FT Status changes to Protected.

Legacy FT VMs can exist only on ESXi hosts running on vSphere versions earlier than 6.5. If you require legacy FT, you should configure a separate vSphere 6.0 cluster.

vCenter Server High Availability

vCenter Server High Availability (vCenter HA) is described in Chapter 1, “vSphere Overview, Components, and Requirements.” vCenter HA implementation is covered in Chapter 8, “vSphere Installation.” vCenter HA management is covered in Chapter 13, “Managing vSphere and vCenter Server.”

VMware Service Lifecyle Manager

If a vCenter service fails, VMware Service Lifecycle Manager (vmon) restarts it. VMware Service Lifecycle Manager is a service that runs in a vCenter server that monitors the health of services and takes preconfigured remediation action when it detects a failure. If multiple attempts to restart a service fail, the service is considered failed.