VMware – Best Features of Fault Tolerance Prowess
VMware Fault Tolerance (FT) imparts continuous robust virtual machine availability and accessibility in the event of a server failure. FT follows the best practices of High Availability.
The new version of Fault Tolerance (FT) in vSphere 6.0 helps and supports multi-vCPU virtual machines as well as single-vCPU virtual machines.
Under particular circumstances, the previous version of FT, (now also known as Legacy FT) can be enabled in vSphere 6.0 on single-vCPU virtual machines.
When FT is enabled in a virtual machine, that virtual machine is denoted as the FT primary virtual machine, or primary.
Every such FT primary virtual machine is paired with other virtual machine, also known as the FT secondary virtual machine, or secondary.
The functional roles of primary and secondary are dynamic. The virtual machines are permitted to swap roles at the time of failover.
Since FT needs some additional resources, therefore, before turning on FT for a virtual machine, ensure you have the following resources duly available: „
Storage: The secondary virtual machine utilizes storage for its configuration file, as well as its VMDK files, each of that file are complete copies of the primary’s VMDK files.
Assure you have appropriate space for the secondary virtual machine; such space can be made available on the same datastore as the primary or a variant datastore.
As long as a virtual machine is FT secure and protected, amendments to the primary’s VMDK files is going to be mirrored to the secondary’s VMDK files. „
Memory: The primary and secondary virtual machines by default automatically receive a full memory reservation, assuring ballooning or swapping is never needed on either virtual machine.
Ensure that the hosts on which the primary and secondary virtual machines is going to run have sufficient memory for this reservation.
While the primary virtual machine is powered on, both the primary and secondary virtual machines utilize to consume additional overhead memory. The amount based on virtual machine memory size however is generally in the range of 1GB-2GB each. „
Network: Ensure the FT logging traffic is carried by utmost a 10Gb/s NIC. While the amount of network traffic is based on the workload, even one multi-vCPU virtual machine may require several Gb/s. „
CPU: The secondary virtual machine needs some additional CPU cycles to support the synchronization among the primary and secondary.
This is in proportion to how active the primary VM is, and is usually low. The primary and secondary should undergo an initial synchronization of their respective memory and VMDK states, prior to a virtual machine is made FT protected.
This is performed via a live memory and disk migration which occurs while the FT virtual machine is running. The disk synchronization, specifically, can be a lengthy operation, so expect a delay before it finishes and the virtual machine becomes FT protected.
The initial synchronization occurs in the following cases. As this process can be resource intensive, avoid doing these operations more frequently than necessary. „
- When FT gets turned on for a running virtual machine. „
- When an FT virtual machine alters from powered-off to powered-on. „
- When the continued Resume Fault Tolerance operation is executed on a running FT virtual machine which has had the interrupted Suspend Fault Tolerance operation conducted on it. „
- When FT protection is restored and reestablished following the failure of either the primary or secondary.This might be caused by a hardware failure or intentionally triggered along with the Test Failover or Test Restart Secondary operations.In either of the case the initial synchronization is going to execute to re-establish FT protection. „
The live migration which takes place for initial synchronization can concisely saturate the vMotion network link and might also cause spikes in CPU utilization. „
Restrain from using the same network link for both FT logging traffic and another network traffic (like, vMotion traffic); one kind of traffic may negatively affect the other, particularly while multiple FT virtual machines are running on the same host. „
FT logging traffic is asymmetric type, and the majority of the traffic flows from primary to secondary. Congestion of logging traffic can therefore be minimized by distributing primaries across multiple hosts. For instance, on a cluster with two ESXi hosts and two FT virtual machines, placing or setting one of the primary virtual machines on each respective hosts permitting FT logging traffic to consume the network bandwidth bi-directionally. „
Avert placing more than four FT virtual machines on a single host, or imbibing more than eight total FT vCPUs over a host.
Moreover, to minimize the likelihood of saturating the FT logging NIC, this also restricts the number of simultaneous live-migrations required to build new secondary virtual machines at the event of a host failure. „
In case the secondary virtual machine runs out of resources (such as CPU cycles, FT logging bandwidth, or storage bandwidth) which the primary virtual machine has plenty of, then ESXi may slow the primary to permit the secondary to keep up.
For instance, in case the host on which the secondary is running also has several other secondaries which is saturating the FT logging bandwidth, however the host on which the primary is running has only single FT virtual machine, then that primary may be slowed to entertain the lack of resources on the secondary. The following recommendations help averting such situation: „
- Ensuring the hosts on which the primary and secondary virtual machines execution are relatively closely matched in contexts of datastore bandwidth and load, CPU performance, virtual machine load (including and especially FT virtual machine load), and load.Bottlenecks in any of such areas on the primary or secondary might be detrimental to the effective performance of the other virtual machine. „
- Assure that power management scheme settings (both in the BIOS and in ESXi) which cause CPU frequency scaling are consistent among the hosts on which the primary and secondary virtual machines run. „
- Empower CPU reservations for the primary virtual machine (which will be duplicated for the secondary virtual machine) by enabling it, to ensure that the secondary receives CPU cycles when it needed them. „
While FT is enabled for a virtual machine, that virtual machine might use only hardware CPU and MMU virtualization. „
Though FT is going to work on several earlier generation CPUs , for the best performance we suggest and recommend the following CPUs : „
- AMD Platform: AMD “Piledriver” generation (like, AMD Opteron 6300 Series) or later.
- Intel Platform: Intel “Haswell” generation (like, as Intel Xeon 2600-v3 Series) or later.
Testing performed confirms that vSphere FT might successfully protect several workloads like servers, CPU-bound workloads, complex database workloads and I/O-bound workloads, and but, admins must avert using vSphere FT for protecting highly latency-sensitive applications like high-frequency trading (HFT) or voice-over-IP (VOIP).
- Microsoft Sharepoint2018.03.30How to Select the Best between SharePoint Server and SharePoint Online
- SharePoint Hosting2018.03.22Avoid SharePoint Compliance Risk by implementing a Robust Information Governance Plan
- Dedicated Hosting2018.03.20Guide to Selecting the Best between Office 365 Hosting and Hosted Exchange
- QuickBooks2018.03.07Boost Up Your Accounting Performance with Managed QuickBooks Support Services