In previous versions of VMware vSphere, real-time fault tolerance (FT) was only possible for single vCPU VMs. The problem was that most modern apps need more than one CPU. That’s why it’s no surprise that virtualization admins everywhere are thrilled about vSphere 6 supporting 4 virtual CPUs in a fault-tolerant configuration.
Here’s what’s changing in vSphere 6:
SMP Fault Tolerance
With vSphere 6, the VMware team has redesigned FT from the ground up. Symmetric Multiprocessing-Fault Tolerance (SMP-FT), uses a new underlying feature called Fast Checkpointing. Instead of the traditional vLockstep technology, where every command is sent initially to the primary VM and then copied over the log network to the secondary VM, Fast Checkpointing uses snapshots and XvMotion to send a stream of snapshots that are constantly applied to a secondary VM. This is a major improvement.
- SMP-FT supports a 4 vCPU per VM ratio. This means that all but the most intensive applications have the ability to be deployed in a FT environment.
- Primary and Secondary VMs do not need to share storage. In vSphere 6, the secondary VM does not use the same VMDK as the primary. Not only does this increase an administrator’s flexibility in locating secondary VMs, such as hosts that don’t share storage, it gives administrators VMDK redundancy for fault-tolerant storage.
- VMDKs can now be thin provisioned or lazy-zeroed thick provisioned. While this may seem like a small issue, the important takeaway here is that you can now enable FT on a VM that wasn’t initially built for a FT environment. This includes situations where administrators can use FT in a pinch to solve a specific problem, or when a previously low-priority VM suddenly becomes much higher priority.
- In this same vein, FT is now able to be hot-added. This enables you to quickly make a VM fault tolerant without first needing to require downtime (which is the exact opposite of what you’re trying to achieve with FT in the first place!).
- Finally, FT enabled VMs are now able to be non-disruptively snapshotted with vStorage APIs for Data Protection (VADP). While FT is an excellent availability and disaster avoidance technology, it still only protects at the hardware level. Issues like software crashes, data corruption, and other OS-level issues will not be protected via FT (as the “problem” would also be copied over to the secondary VM). With vSphere 6, you no longer need to rely on in-guest backup solutions for your FT-enabled VMs.
- 4x vCPU VMs consume a significant amount of network traffic. Make sure you have a 10-Gbps network.
- The new maximum fault-tolerant VMs per host is 4 FT VMs or 8 FT-protected vCPUs, whichever limit you hit first. This includes both primary and secondary VMs, regardless of host performance and size.
At ServerCentral, we’re incredibly excited to begin using this new version of FT in current and future vSphere environments. Almost any application with high performance requirements, especially those that are difficult or impossible to cluster can now be protected at the virtualization layer. Furthermore, the added benefit of redundant VMDKs resolves one of the main issues that even single vCPU VMs could still face at the hardware level.
We’re closer to running 100% virtualized environments than ever before.
If you’re interested in learning more about vSphere 6 or how we’ll use the new capabilities, please let us know.