vMotion over Distance and Stretched VLAN across L3 WAN – Cisco OTV is your Answer @stretchcloud

Not a new article, but this topic came up in debate for a current project working on but illustrated the point nicely of when you dont have L2 across sites and must use routed networks.

Below courtesy @stretchcloud. Read the article here: http://stretch-cloud.info/2012/07/vmotion-over-distance-and-stretched-vlan-cisco-otv-is-your-answer/

…I will talk about how do you stretch the VLAN onto a different DC.

Yes, I am talking about Cisco OTV. Cisco’s OTV provides a mechanism to transport native Layer-2 Ethernet frames to a remote site. With a standard Layer-3 WAN, there is no way to bridge layer-2 VLANs, and as a result, communication between two sites must be routed. Because of the routing aspect, it is not possible to define the same VLAN in two locations and have them both be actively transmitting data simultaneously.

Because OTV can operate over any WAN that can forward IP traffic, it can be used with a multitude of different underlying technologies. It provides mechanisms to control broadcasts at the edge of each site, just as with a standard Layer-3 WAN, but also gives you the ability to allow certain broadcasts to cross the islands. OTV only needs to be deployed at certain edge devices, and is only configured at those points, making it simple to implement and manage. It also supports many features to optimize bandwidth utilization, provide resiliency and scalability.

Let’s look at how OTV operates. Here we have two sites separate by a standard Layer-3 WAN connection. OTV is deployed across the WAN by configuring it on an edge switch at both sites. Each end of the OTV “tunnel” is assigned an IP address. Both OTV switches maintain a MAC-to-Next Hop IP table so that they know where to forward frames in a multi-site configuration.

When a host at one site sends a frame to a host at the other site, it can determine the MAC address of the other host, since it is on the same VLAN/network. The host sends the Ethernet frame, which is accepted by the OTV switch and then encapsulated in an IP packet, sent across the WAN, and subsequently decapsulatedby the remote OTV switch. From here, the Ethernet frame is delivered to the destination as if it had been sent locally.

Concept in Practice: Workload Relocation Across Sites

In the event that there is a planned event that will impact a significant number of resources, services must be moved to an alternate location. Unfortunately, because the networks are disjointed, there is no way to seamlessly migrate virtual servers from one location to another without changing IP addresses. As a result, Site Recovery Manager is used to provide an offline migration to the second site, and update DNS records to reflect the new IP addresses for the affected servers. Once the event is complete, another offline migration is performed to restore services to the primary site.

Concept in Practice: vMotion over Distance with OTV & Stretched VLANs

By using OTV in this situation, instead of having to use SRM to emulate a disaster situation, vMotion can be used to migrate the VMs from one site to the other. While this migration is still an offline event, it does provide a much simpler solution to implement and manage by allowing the VM to maintain it’s network identity in either location.

In addition to addressing the initial challenge, OTV provides additional benefits. By having two functional sites with the same network attributes, it is possible to split workloads for services, providing fault tolerance and redundancy. So, if the primary site does have a planned event, failing resources over to the second site may not even be necessary. It also allows the infrastructure to scale by having added ESXi servers operational at the second location to distribute the load.