Live Migration vs. vMotion: A guide to VM migration
A comprehensive collection of articles, videos and more, hand-picked by our editors
It's a virtualization administrator's dream: Moving a live virtual machine from one data center to another with...
no downtime. Supporting this dream means building a dream infrastructure to underpin the VMware Metro vMotion feature -- and that's no small task.
VMware Metro vMotion can move a virtual machine (VM) between two physically separate data centers without taking it offline. Metro vMotion also allows VMware vSphere High Availability (HA) to restart an entire data center's VMs in a different data center in the event of a major failure. But the four main Metro vMotion requirements are beyond typical IT shops' networking, vCenter and storage bounds.
Two Metro vMotion network requirements
VMware requires that Metro vMotion users stretch Layer 2 networks across both data centers so that the same IP subnet concurrently exists at both sites. With this requirement met, the network configuration, particularly the IP address, does not have to change when a VM vMotions between sites. This must be a single subnet, not just the same IP address range, otherwise VMs at the first site would lose connectivity to the moving VM once the operation completes. HA and vMotion can't change a VM's network configuration, since they are vSphere features. Keeping the same subnet between data centers allows the VM to maintain network connectivity after it vMotions.
Staying within vMotion's boundaries
Digging into Metro vMotion storage reqs
Test your vMotion knowledge
All Metro vMotion connections on all hosts must be on the same IP subnet. All ESXi management ports on all hosts must also be on the same IP subnet, but usually it will be a different subnet than vMotion, regardless of which site.
If you can swing the two subnets across both data centers, be sure you have less than 10 millisecond round-trip latency between sites, and redundant bandwidth of at least 622 Mbps.
One vCenter to rule them all
All vSphere host servers Metro vMotion uses must be managed by a single vCenter instance. Metro vMotion cannot cross the boundary of vCenter data center objects, so if all the hosts are not within the same vCenter data center object, the VMs are stuck. When utilizing VMware HA across data centers, all hosts share the same vCenter cluster object, since this is HA's management domain.
Use affinity rules via the VMware Distributed Resource Scheduler utility to control in which data center a VM will primarily exist, and which VMs should stay together in a single data center. For example, to reduce cross-site traffic, the Web, app and database servers in a three-tier application could be configured to have affinity for one another, and the group itself to have affinity to one data center or the other. This setup also requires all hosts to exist within a single vCenter cluster object.
The active storage hurdle
The final, and most difficult, Metro vMotion requirement is that the two sites' storage arrays must be truly active-active. This requires synchronous replication with less than 5 millisecond latency. The pair of arrays must be configured to present themselves to vSphere as a single array and must be able to present a read/write version of the same logical unit number (LUN) at the same time. To accomplish true active-active paired storage arrays, every write operation must be committed on both arrays prior to acknowledging to the host.
Not many storage options can provide this level of consistency between two arrays at different sites, which severely limits the infrastructure available for deploying this part of the design.
Brian Knudtson asks:
Do you think the rewards of VMware's Metro vMotion are worth its tough requirements?
0 ResponsesJoin the Discussion