ESX 4 Fault Tolerance
In the next step in virtualization evolution; VMware is introducing vLockStep. This technology is the beginning of a true active, near zero downtime clusters. David Davis reports on techtarget, that vLockStep will create a standby running image of the VM. This VM is running in step with the primary VM, any change on the primary VM is nearly instantaneously completed on the standby image. In case of hardware failure of the ESX node hosting the primary image, the standby will become active and continue on servicing clients as if nothing happened. A video on VMware’s website demonstrates this active/standby connection very effectively.
There are some additional requirements that Scott Lowe wrote about in his blog at ScottLowe.com. One of the biggest is that the FT pair must use thick provisioned vmdks. Then provisioned disks will be expanded to thick. On an NFS based datastore, one of the benefits is to leverage thin provisioning. Scott also writes that a minimum of 4 NICS are required to support vLockStep: Service Console, Clients, FT, and vMotion. Given that redundancy is a given in the production environment, we are now up to a minimum of 8 nics, and at least 2 more if the NFS datastore is used.
Also, there are limitations to vLockStep. One such limitation is that the VM guest can only be single vCPU. A second limitation is that the secondary VM must reside on the same datastore as the primary. I’m making an assumption on the third limitation: It would appear that the secondary VM will need to run on the same VI cluster as the primary.
The first limitation of single vCPU is the largest shortcoming of vLockStep. Most of the critical applications that would benefit from a truly active cluster are going to be database servers and mail servers. Critical servers that the entire business requires, most of these servers are going to be multi vCPU. The second and third limitation would have been niceties. Placing a vLockStep enabled VM across both multiple datastores and multiple clusters would have truly enhanced the disaster recovery capabilities of VMware. Firms would be able to survive not only a small ESX host failure, but also entire storage failures, Power Failures, natural disasters. Hopefully, the vLockStep technology will be enhanced in future releases of ESX.
David Davis discussing vLockStep Technology: http://searchvmware.techtarget.com/video/0,297151,sid179_gci1336986,00.html?track=NL-915&ad=670476&asrc=EM_NLN_4862015&uid=2353064
VMware Site demonstrating vLockStep Technology: http://download3.vmware.com/vdcos/demos/FT_Demo_800x600.html
Scott Lowe’s Blog on vLockStep: http://blog.scottlowe.org/2008/09/16/bc2621-fault-tolerant-vms-in-vi-operations-and-best-practices/
VMware ESX 4 Storage vMotion
One of the features being updated in the next release of VMware ESX is storage vMotion. Storage vMotion was released in ESX 3.5 and while great for administrators that leverage either iSCSI or VMFS, it was of limited use to administrators leveraging NFS datastores.
One benefit of using NFS datastores is the default creation of thin VMDKs. Administrators can create larger VMDKSs on VM creation, and not waste space on the storage unit. I consider this a set it and forget it option. We only need to monitor the datastore and increase the size of the NFS mount when required. While thin provisioning is the default configuration option when using NFS datastores, the thin provisioning was not kept when moving the VMDKs from one storage unit to another. This is a limitation of the underlying ESX hypervisor, as we could not even move the VMDKs through the service console without losing the thin provisioning.
Enter ESX 4. According to VMware demo at http://download3.vmware.com/vdcos/demos/Storage_VMotion_800x600.html, we now have the option to live migrate from thin to thin. It also appears that we can now move VMDKs from thick to thin, thin to thick, even RDM to either thick or thin or any of the above to RDM. One of the selling points of storage vMotion in 3.5 was the ability to move the VM live between storage. You could build your server on tier 2 storage, when ready to go to production; you could move the VM to tier 1 storage with no downtime to the VM. Now, NFS datastore administrators can fully leverage this technology.
What are some benefits of the enhanced storage vMotion?
- Build VMs on tier 2 storage and move to tier 1 storage when ready for production.
- Remove our lock-in to FC, iSCSI or NFS. Build using one technology now and migrate in the future based on performance requirements.
- Migrate to new storage when replacing aged storage heads.
While on the topic of storage, one feature that I would like to see implemented by VMware is the ability to leverage VCB for NFS datastores. While many might question why you would want to use VCB for backing up NFS, when you can use the the same storage backup solution as the NFS host, there are good reasons. Backing up VMs becomes more difficult as the numbers increase. By leveraging VCB, the stress of backups is moved from the virtual infrastructure to a separate windows server. This could provide options such as backing up outside of the normal backup nightly backup window, or adding additional incremental or differential backups.
About mordtech
Experience:
I’m an IT professional with over ten years of Microsoft Server support. I’ve also supported Checkpoint and VMware. I’m currently employed by a large IT outsourcing corporation in the US.
I’ve implemented Windows Active Directory, Checkpoint VPN/Firewalls, VMware Infrastructure, Sharepoint/Project Server amongst others.
Personal:
I’m married and a father of two boys, which is by far the most trying job of my life: the boys, not the marriage. We reside in the midwest and aren’t looking forward to the fast approaching winter.
sitemeters
