Mike Kiev - Fotolia
VMware vMotion has become an essential tool for virtual machine migration and workload balancing, helping virtualized data centers become more responsive to changing business needs. But vMotion has traditionally experienced serious practical limitations due to the latency, or distance, between data center locations.
VSphere 6 lifts these limitations with long-distance vMotion, which supports migrations with far greater latency and moves workloads across continental distances. This promises to open new uses for workload migration, which had been problematic or impossible with earlier versions of vMotion. Let's take a closer look at long-distance vMotion and its implications for the enterprise.
All network communication is affected by latency which (for our purposes) is basically a delay between the time a packet is sent to the time that packet is received. Latency involves many factors that include processing, memory and I/O movement time (even application performance issues) within servers as well as port delays in switch and routing equipment. But the largest factor in network communication latency is the physical distance between endpoints, and communicating across vast regions can add several milliseconds to each packet. When packet delivery must be acknowledged, the round-trip latency time (RTT) is effectively doubled.
Previous versions of VMware vMotion have imposed a round-trip latency limit of 10 milliseconds (ms). That's 5 ms there and 5 ms back. Assuming the electronics need 1-2 ms on each end, that's about 3 ms of actual travel time one way. At around 124 miles per millisecond, the practical distance limit has been between 300-400 miles. That distance has been fine for local workload balancing (such as moving VMs between servers in the data center or between buildings across a campus) or perhaps moving VMs to or from nearby backup or colocation sites.
However, distance limits of vMotion impose restrictions on where the enterprise can move workloads. A business might need to migrate VMs farther for disaster preparedness -- such as moving workloads out of a war zone or an area hit by a natural disaster -- or even just routinely migrate VMs to distant data centers as user demand varies. For example, moving a VM from New York to London might be ideal during certain times of the day when user demand in distant locations are greatest (a tactic sometimes called "chasing the daylight").
VSphere 6 seeks to overcome these distance limits by introducing long-distance vMotion which raises the round-trip latency limit from 10 ms to as much as 150 ms. This vastly increases the practical distance allowed for VM migrations. With an RTT of 150 ms and a one-way latency of about 70 ms (allowing about 5 ms for electronics each way), that's more than 8,500 miles. In actual practice, the RTT rarely exceeds 100 ms, leaving one-way latency around 45 ms (with up to 5 ms for electronics) for distances over 5,500 miles. This supports enormous migration distances such as from New York to Los Angeles (about 2,800 miles) or from New York to London (about 3,500 miles).
These distances open up new use cases for the enterprise. For example, with long-distance vMotion, businesses can build new data centers or engage colocation providers that are far more distant than previously possible, allowing data protection or disaster preparedness strategies that span between continents. Similarly, workload balancing and other data center resource management can now span across a greater number of far-flung sites helping organizations to consolidate and streamline IT management.
Dig Deeper on vMotion and Storage vMotion
Related Q&A from Stephen J. Bigelow
Learn how load balancing in the cloud differs from a traditional network traffic distribution, and explore services available from AWS, Google and ... Continue Reading
Access management is critical to securing the cloud. Understand the differences between AWS IAM roles and users to properly restrict access to AWS ... Continue Reading
Containers have rapidly come into focus as a popular option for deploying applications, but they have limitations and are fundamentally different ... Continue Reading