- Upto 4 vCPUs per VM (Its a Hard Limit)
- Upto 8 vCPUs per host (User Customizable)
- Upto 4 FT Protected VMs per host (User Configurable)
- Any Disk FT supported like Thin, Thick or EZT
- Hot enable FT supported, means you can turn ON or OFF FT while VM is running.
- Greatly enhanced Host compatible with FT. So now if your hosts are vMotion compatible, most likely they would be FT compatible.
- FT previously was compatible with SRM but now currently isn't compatible with SRM.
- FT still is not supported for SDRS, vVols, VCD, VR or stretched clusters (try for stretched Clusters but not supported due to performance)
- Legacy FT VMs can run on vSphere 6 to upgrade FT 5 to FT 6, Turn FT OFF and then back ON. If you want to continue using old FT, it is possible (you need to configure VM advanced options "vm.UseLegacyFT=True")
- If you have some Legacy FT protected VMs and some new FT protected VMs and if you are not sure which are which then if you look in the VMXlog file of either of the Primary or secondary and search for an option FTCPP.enabled=TRUE, then its New FT.
- FT for VCenter (Tiny/small flavors are supported)
- Upto 64GB RAM
- Although there is no direct way for a user to take snapshot for FT VM but VADP Backup is supported which can make use of the snapshot feature.
- Earlier storage was a single point of failure for FT VMs, now you can use different datastores for FT VMs. This is the recommended policy to keep both FT VM copies on different datastore.
- The FT Lockstep would run on the speed of the slower system.
- FT currently doesn't support vVol based storage.
- FT currently doesn't have any direct integration with VASA , so things like dedup at array levels are not currently integrated, however, if backend array supports dedup, the FT VMs will also be treated like any other VMs and dedups would happen.
- FT has been completely refreshed from the technology perspective. They now use a technology which is called as "Fast Checkpointing" which copies active memory contents from Primary to Secondary via FT logging network on a continuous basis and hence a 10G network is recommended.
- Checkpoint is kind of snapshot of the memory state of the FT VM. Unlike snapshot, checkpoint only contains the incremental state changes. Checkpoint Interval would be dynamic from a few ms to couple of hundred ms. It would adapt to maximize the workload performance.
- During checkpointing, the VM gets frozen. Checkpoint also contains the contents of VM memory, disk options, devices and vmx config options.
- When a packet comes to the primary VM, before the primary VM would send the receive Acknowledgement, the VM is frozen, the checkpoint is created and transferred over the FT logging network to the secondary VM. The acknowledgement is being sent from the secondary VM to the primary back and then the primary VM gets unfrozen and the reply receive acknowledgement is being sent back to the original source from where the packet had initiated originally.
- FT is not a good candidate for workloads which are latency sesitive.
- There are few files which have to be on shared storage and these files are FT configuration files. "Shared.vmft file", ".ftgeneration file" (which works as a Tiebreaker file between the hosts) and "Primary VM.vmx file". These three files have to be on shared storage.
- If you want you can save your Primary and Secndary VM files on local storage but then if Primary host fails, secondary would become the New Primary but until the failed host comes back up, FT would not be able to create a New Secondary VM.
- VC responsibilities for FT are (a) Defines the FT workflows and allows clients to invoke them. (b) Validate FT compatibility for different VM operations. (c) Inter-Operation with other features like VADP, DRS etc. FT is not dependent on VC otherwise and even if VC fails, FT would still continue work the same way other than you would not be able to turn OFF FT if you want.
- Its the HA/FDM agent which is responsible for (a) Creating and start new secondary as needed. (b) Restart secondary to re-establish FT protection after FT-Failover.
- FT motion mirror driver does the initial FT migration and the secondary VM is going to be powered on. After that FT uses its own technology of checkpoint.
- FT is not a replacement for MS-Cluster or Oracle-RACK. FT is only going to protect host failures and not application failures. If application crashes in Primary, it's going to do the same on Secondary as well.
- vSphere Standard and Enterprise License would let you do 2 vCPU FT, Enterprise + would allow 4 vCPU FT.
- You can monitor FT logging Network Utilization on VM Config page of Primary and Secondary.
- FT would give more performance on a Haswell Processor compared to older ones let's say Sandybridge.
VMware vSphere 6.0 Fault Tolerance - Main Points
- You are here:
-
Home
- VMware vSphere 6.0 Fault Tolerance - Main Points
