Improper planning, however, can lead to serious problems. High-availability
Requires Free Membership to View
|
||||
Define the VMs to be mirrored. The members of a server cluster will likely host a variety of virtual machines (VMs), so decide which VMs need protection through mirroring across servers and which less critical VMs don't. There's no point in duplicating VMs if it takes only two or three minutes to recover a VM on another server.
Consider server computing resources. Each VM requires CPU, RAM, I/O and network connectivity, so assign and balance workloads to stay within the available computing power of each server. Be sure to consider the added computing requirements for duplicated -- mirrored -- or failed-over VMs.
|
||||
Select VM mirroring software. Mirroring software must be fully interoperable with the hypervisor on each server, as well as the applications being protected. For example, everRunVM from Marathon Software can protect Exchange, SQL, SharePoint and BlackBerry services and is fully compatible with Citrix Systems Inc.'s XenServer.
Test failover/failback regularly. Once tested and deployed, it's important to verify HA readiness by periodically testing the failover/failback behavior of mirrored VMs. The trigger may be as simple as disconnecting a network cable from one server and verifying that the mirrored VM continues application availability from the second server without disruption.
Maintain virtualization high availability in backup regimen. Protecting VMs with HA is often considered a form of DR, but even mirrored VMs need to be backed along with other nonmirrored VMs. Backups can be performed from a SAN to other storage or off-site locations using a variety of software tools.
This was first published in March 2010
Virtualization Strategies for the CIO

Join the conversationComment
Share
Comments
Results
Contribute to the conversation