vSphere 6 Fault Tolerance(FT)

FT is one of feature in HA Cluster that provides zero downtime, but due to its limitations till vSphere 5.5 the use cases for this was also limited. But with vSphere 6 a lot of changes have been made in this  feature to overcome from its limitations.

Why one should use FT?

• Continuous Availability with zero downtime and zero data loss.
• Transparent to Guest OS
• It does not depend on Guest OS and Application
• Instantaneous failover from Primary to Secondary VM in case of ESXi Host Failure.

Enhancements in vSphere 6 FT

• Supports for Up to 4 vCPUs and 64 GB RAM
• Supports vMotion of both Primary and Secondary VM
• Supports backup of FT VMs by using VADP like EMC, HP etc.
• Replaced "Record and Replay" with Fast Check-Pointing
• Supports thin, thick eager-zeroed and thick lazy zeroed
• Separate File Copies for Primary and Secondary VMs like .vmx, .vmdk etc. and both can be on difference datastores. 

Use Cases of FT?

• Applications that needs to available all the times
• Custom Applications those do not have their own HA Solution
• Custom Application those do have their HA Solution but that is too much complicated to configure
• On-Demand FT

Requirements for FT?

• Intel Sandy Bridge or Later (Avoton is not supported)
• AMD Bulldozer or later
• 10 Gbps FT logging network

Limits?

• The maximum number of vCPUs aggregated across all fault tolerant VMs on a host. vCPUs from both Primary VMs and Secondary VMs count toward this limit. The default value is 8.

• The maximum number of fault tolerant VMs allowed on a host in the cluster. Both Primary VMs and Secondary VMs count toward this limit. The default value is 4.

Shared Files in vSphere 6 FT?
FT has shared files:-
.shared.vmft = Prevents UUID Change.Which is found on a shared datastore, is the vSphere Fault Tolerance metadata file and contains the primary and secondary instance UUIDs and the primary and secondary vmx paths.
.ftgeneration = Is for split-brain condition. This attempt succeeds if the virtual machines remain running on the isolated or partitioned host and that host lost access to the virtual machines’ datastores when it became isolated or partitioned. A split-brain condition exists because there are two instances of the virtual machine. The .ftgeneration file ensures that only one instance of the virtual machine can read from or write to the virtual machine's virtual disks.

Licensing? 
Number of vCPUs supported by single FT enabled VM is limited by level of licensing

• vSphere Standard or Enterprise Edition = Max. 2 vCPUs
• vSphere Enterprise Plus = Max. 4 vCPUS

Features Not Supported for FT VMs?

When configuring your cluster, you should be aware that not all vSphere features can interoperate with Fault Tolerance.  

The following vSphere features are not supported for fault tolerant virtual machines.

• Storage vMotion. You cannot invoke Storage vMotion for virtual machines with Fault Tolerance turned on. To migrate the storage, you should temporarily turn off Fault Tolerance, and perform the storage vMotion action. When this is complete, you can turn Fault Tolerance back on. 
• Linked clones. You cannot use Fault Tolerance on a virtual machine that is a linked clone, nor can you create a linked clone from an FT-enabled virtual machine.
• VM Component Protection (VMCP). If your cluster has VMCP enabled, overrides are created for fault tolerant virtual machines that turn this feature off.
• Virtual Volume datastores.
• Storage-based policy management.
• I/O Filters
• Snapshots. Snapshots must be removed or committed before Fault Tolerance can be enabled on a virtual machine. In addition, it is not possible to take snapshots of virtual machines on which Fault Tolerance is enabled.