First glimpse: Cisco OTV and long-distance VMotion
Or how to succeed at data center extension without really tryingFollow @pvenezia
The upshot is that even though the overlay transport is transparent to the ends of the connection, there's no fear of spanning-tree looping as each site maintains a distinct spanning-tree topology and BPDUs aren't forwarded across the WAN. The OTV functions as a gatekeeper for the frames that should remain local while forwarding those that should be allowed to pass.
When databases fly
In the demo I saw, Cisco used OTV to migrate a loaded SQL Server VM from one VMware ESX host to another over a simulated WAN, with the hosts residing at different data centers the equivalent of 400km apart (4ms latency). The VM migrated over in about 30 seconds or so without losing the connection with the client load... with one catch. Although the VM definitely moved, the virtual disk didn't. (Moving an 8GB VMDK through an OC-12 would take far longer than 30 seconds, and such a trip isn't really feasible for a VM under load anyway.) In the demo, NetApp's FlexCache technology bridged this gap, enabling the VM disk to remain in the original data center while keeping the delta at the new data center. Naturally, this isn't a scenario that lends itself to a permanent migration, but it might prove useful in some load-balancing and global distribution scenarios.
It's important to note that the established connections to migrated VMs continue along their original data paths. Even though the VM ends up running at the remote data center, the existing TCP connections to that server must still pass through the initial data center to maintain the consistency of the connection. New connections could be rerouted to the remote data center, but an existing connection cannot. This could add significant latency and bandwidth consumption to the WAN links if not monitored. It should also be noted that current technologies put a distance damper on any effort like OTV, since VMotions on links with greater than 4ms latency can get problematic really fast. This roughly translates to 400km of physical separation. This isn't a limitation of OTV, but it's still a constraint.
Needless to say, Cisco's OTV isn't a technology that many companies need. However, to those that do, it's quite compelling. OTV isn't immediately ready to handle intercontinental data center linking, but it could certainly be used to connect data centers in New York City and Washington, DC, or anywhere within a 250-mile radius.
Although those distance limitations are the result of current data transport technologies, the framework is there to support anything coming down the pike. Once it's feasible to achieve 4ms latencies across a 2,500 mile link, OTV will be ready. As such, it goes a long way toward allowing geographically disparate data centers to play in the same pool while greatly reducing the chance of Layer-2 boogymen compromising the network. It's an important step in localizing remote computing resources.
- How Cisco UCS reinvents the data center
- InfoWorld review: Cisco UCS wows
- VMware vSphere 4: The once and future virtualization king
- Exclusive review: HP BladeSystem Matrix
This story, "First glimpse: Cisco OTV and long distance VMotion," was originally published at InfoWorld.com. Follow the latest developments in virtualization, networking, and cloud computing at InfoWorld.com.
Read more about virtualization in InfoWorld's Virtualization Channel.