High availability, disaster recovery, business continuity, etc. are all key concerns of any data center design. They all describe separate components of the big concept: ‘When something does go wrong how do I keep doing business.’
Very public real world disasters have taught us as an industry valuable lessons in what real business continuity requires. The Oklahoma City bombing can be at least partially attributed to the concepts of off-site archives and Disaster Recovery (DR.) Prior to that having only local or off-site tape archives was commonly acceptable, data gets lost I get the tape and restore it. That worked well until we saw what happens when you have all the data and no data center to restore to.
September 11th, 2001 taught us another lesson about distance. There were companies with primary data centers in one tower and the DR data center in the other. While that may seem laughable now it wasn’t unreasonable then. There were latency and locality gains from the setup, and the idea that both world class engineering marvels could come down was far-fetched.
With lessons learned we’re now all experts in the needs of DR, right up until the next unthinkable happens ;-). Sarcasm aside we now have a better set of recommended practices for DR solutions to provide Business Continuity (BC.). It’s commonly acceptable that the minimum distance between sites be 50KM away. 50KM will protect from an explosion, a power outage, and several other events, but it probably won’t protect from a major natural disaster such as earthquake or hurricane. If those are concerns the distance increases, and you may end up with more than two data centers.
There are obviously significant costs involved in running a DR data center. Due to these costs the concept of running a ‘dark’ standby data center has gone away. If we pay for: compute, storage, and network we want to be utilizing it. Running Test/Dev systems or other non-frontline mission critical applications is one option, but ideally both data centers could be used in an active fashion for production workloads with the ability to failover for disaster recovery or avoidance.
While solutions for this exist within the high end Unix platforms and mainframes it has been a tough cookie to crack in the x86/x64 commodity server system market. The reason for this is that we’ve designed our commodity server environments as individual application silos directly tied to the operating system and underlying hardware. This makes it extremely complex to decouple and allow the application itself to live resident in two physical locations, or at least migrate non-disruptively between the two.
In steps VMware and server virtualization. With VMwareâ€™s ability to decouple the operating system and application from the hardware it resides on. With the direct hardware tie removed, applications running in operating systems on virtual hardware can be migrated live (without disruption) between physical servers, this is known as vMotion. This application mobility puts us one step closer to active/active datacenters from a Disaster Avoidance (DA) perspective, but doesnâ€™t come without some catches: bandwidth, latency, Layer 2 adjacency, and shared storage.
The first two challenges can be addressed between data centers using two tools: distance and money. You can always spend more money to buy more WAN/MAN bandwidth, but you canâ€™t beat physics, so latency is dependent on the speed of light and therefore distance. Even with those two problems solved there has traditionally been no good way to solve the Layer 2 adjacency problem. By Layer 2 adjacency Iâ€™m talking about same VLAN/Broadcast domain, i.e. MAC based forwarding. Solutions have existed and still exist to provide this adjacency across MAN and WAN boundaries (EoMPLS and VPLS) but they are typically complex and difficult to manage with scale. Additionally these protocols tend to be cumbersome due to L2 flooding behaviors.
Up next is Cisco with Overlay Transport VLANs (OTV.) OTV is a Layer 2 extension technology that utilizes MAC routing to extend Layer 2 boundaries between physically separate data centers. OTV offers both simplicity and efficiency in an L2 extension technology by pushing this routing to Layer 2 and negating the flooding behavior of unknown unicast. With OTV in place a VLAN can safely span a MAN or WAN boundary providing Layer 2 adjacency to hosts in separate data centers. This leaves us with one last problem to solve.
The last step in putting the plumbing together for Long Distance vMotion is shared storage. In order for the magic of vMotion to work, both the server the Virtual Machine (VM) is currently running on, and the server the VM will be moved to must see the same disk. Regardless of protocol or disk type both servers need to see the files that comprise a VM. This can be accomplished in many ways dependent on the storage protocol youâ€™re using, but traditionally what you end up with is one of the following two scenarios:
In the diagram above we see that both servers can access the same disk, but that the server in DC 2, must access the disk across the MAN or WAN boundary, increasing latency and decreasing performance. The second option is:
In the next diagram shown above we see storage replication at work. At first glance it looks like this would solve our problem, as the data would be available in both data centers, however this is not the case. With existing replication technologies the data is only active or primary in one location, meaning it can only be read from and written to on a single array. The replicated copy is available only for failover scenarios. This is depicted by the P in the diagram. While each controller/array may own active disk as shown, itâ€™s only accessible on a single side at a single time, that is until Vplex.
EMCâ€™s Vplex provides the ability to have active/active read/write copies of the same data in two places at the same time. This solves our problem of having to cross the MAN/WAN boundary for every disk operation. Using Vplex the virtual machine data can be accessed locally within each data center.
Putting both pieces together we have the infrastructure necessary to perform a Long Distance vMotion as shown above.
OTV and Vplex provide an excellent and unique infrastructure for enabling long-distance vMotion. They are the best available â€˜plumbingâ€™ for use with VMware for disaster avoidance. I use the term plumbing because they are just part of the picture, the pipes. Many other factors come into play such as rerouting incoming traffic, backup, and disaster recovery. When properly designed and implemented for the correct use cases OTV and Vplex provide a powerful tool for increasing the productivity of Active/Active data center designs.