Get on board the latency train as the Datanauts chug down bandwidth-restricted tracks, heading for the land of vMotion between data centers. After all, never changing an application IP address fixes a whole bunch of problems for our apps.
Thus, the land of vMotion between data centers is the land of promise, the land that many of us are heading to.
But is the ability to move an application between DCs a wonderful thing? Yes, it’s convenient and seems like a good thing from the layer 8 point of view. But what evil lurks to make vMotion between data centers work?
Chris Wahl and Ethan Banks explore the network and application issues that can undo moving virtual workloads from one data center to another, and talk about ways to enable inter-data center vMotion while minimizing the risks of blowing up both.
Join the Packet Pushers at Interop Las Vegas for the Future of Networking Summit, May 2- 3. It’s a deep dive into the technologies and trends that will affect the next five to ten years of networking. Use the code PPUSHERS in the “Marketing Code” field when you register and get 25% off 5-Day, 3-Day, and 2-Day conference passes.
You know GNS3 for their network lab software. Now they’ve started a training academy, including the “Practical SDN and OpenFlow Fundamentals” course from instructor and CCIE emeritus David Bombal, and Packet Pushers listeners can get 50% off!
Bombal demonstrates SDN and Openflow in detail, covering everything from the basic definition of SDN to capturing messages with Wireshark and even building your own SDN switch with a Raspberry Pi. The first 50 Datanauts listeners to register receive the course for 50% off. To get your discount go to tinyurl.com/gns3sdn OR go to academy.gns3.com and use the coupon PACKETPUSHERS (all one word).
Part 1 – The Application Problem
- Applications are married to IP addresses
- Applications are stateful
- Some applications have a reliance on L2 adjacency
- Some administrators are focused on building workloads within an L2 network
- To avoid in-flight user impacts, a session must be stuck to this with no interruption, even if the system moves
Part 2 – The Issue With This Approach
- Ideally, data centers do not share fate. But extending L2 creates a common broadcast domain in 2 data center. Now, we are sharing fate
- Traffic patterns become sub-optimal
- Where does the default-gateway live? In the local DC? Or remote?
- Traffic to load balancer to pool member, but pool member lives in the remote DC now
- And that’s just L3 considerations. What about L2? How is spanning tree handled between DCs?
- Dealing with these issues has spawned whole new protocols, including Overlay Transport Virtualization (OTV) from Cisco that isolates protocols like STP, HSRP, and VTP to attempt to isolate failure domains and avoid FHRP-related traffic tromboning
- Redundant links between DCs becomes even more critical, because there’s an application assumption that the network is always available
- Latency tends to be high and bandwidth tends to be constrained in DCI, which make it hard to successfully vMotion anything. vMotions are huge datasets constantly changing
- Problems you’d have anyway that are bandwidth problems of their own…
- How is storage being synced between sites?
- What about database stores?
- Site awareness
- How do you abstract the current site of a workload so that the compute knows where it’s running?
- Sync storage across sites – active/active
Part 3 – A Brighter Tomorrow
- Worst-case scenarios: what happens if in-flight sessions are interrupted?
- Consider that HTTP tends to be quick transactions. Do we care if the session is interrupted? (Granted, in a multi-tier app there are many more sessions to consider)
- Applications being redesigned for statelessness
- Using modern hypervisor / CMP combination that understands sites and has awareness of the topology
Cisco Overlay Transport Virtualization FAQ – Cisco Systems