Topics


Blogs


Forums


Samples


Media


Labs


Resources

 




DevCentral > Weblogs > Lori MacVittie - Two Different Socks
 Migrate a live application across clouds with no downtime? Sure, no problem.
posted on Monday, August 31, 2009 4:33 AM

F5 and VMware demonstrate live migration of a virtualized application across clouds without downtime or user disruption

Cloud is reaching the peak of possibilities and that (often) means just more paper solutions. You know the ones; the ones that exist only on paper (or in blogs as the case may be). Those paper solutions need to exist because the ideas need to come first either out of necessity, i.e. to solve a specific problem, or out of a desire to find new ways to leverage emerging technology, like virtualization. But still, you’d like to see some of these paper solutions come to fruition, if for no other reason than to prove to yourself (or management) that this stuff is real.

imageNow, we’ve talked about cloud balancing, about cloud bursting, and how to utilize cloud environments as overdraft protection and availability insurance. We’ve more recently dived into internal cloud bursting and leveraging virtualization from the inside out. But one of the things we haven’t talked about is how virtualized applications get from one data center to another, regardless of whether that’s between cloud providers or between corporate data centers or some combination thereof.

Oh, we’ve talked about sneakernet and virtual private cloud connections, but that doesn’t dig into actually moving the virtual machines from one physical location to another. Until today. As you’ve been very patient about that, we can take that concept one step further and not only migrate virtual machines from one locality to another, but we can show you how to do it live.  

Seriously, not kidding. Live migration of an application running in a VM from one vSphere environment to another. No downtime, no disruption,migration no kidding. The ability to perform such a feat is brought to you by a virtual private cloud connection, vMotion, vSphere, F5 BIG-IP Local Traffic Manager, BIG-IP Global Traffic Manager, iSessions, and F5’s service-enabled control plane, iControl.

And several very tired (but excited) solution architects.

There are caveats to such a feat (VMotion is today limited to a single L2 broadcast domain, Storage VMotions are even more restrictive, and IP address space limitations make management cumbersome at best) hence the requirement for a virtual private cloud connection and the employment of integration technologies provided by the infrastructure, but what you’ll see is an application move over a secure, accelerated virtual private cloud connection – completely – from one data center to another without disrupting users. And if you abstract the technologies, you’ll soon see that if we can get some kind of standards going in the cloud around interoperability then we really can move applications – live – between clouds by leveraging virtualization and a dynamic infrastructure.

This kind of live migration is one of the ways in which both internal and external cloud bursting can be achieved in real-time; it’s a way to support on-demand cloud balancing; it’s a way to leverage secondary data center – cloud-based or not – when there may be a need for the primary data center to “go offline” for maintenance, to keep costs down, for whatever reason you may have.

It’s a demonstration that the collaborative capabilities of Infrastructure 2.0 are real and beneficial; that the integration of the application delivery network with the application infrastructure does result in the ability to design some truly innovative solutions that can be leveraged to take advantage of cloud-based data centers.

If you’re hanging around VMworld you can see this happen live and in the flesh. If you’re not fortunate enough to be hanging out at VMworld you can still take a gander at the process and watch it pseudo-live (recorded earlier).


vmworld_2009

WEDNESDAY, SEPTEMBER 2 @ 10:30am & 5:15pm

in the cloud pavilion: live application migration between clouds with f5 and vcenter

You can follow F5 on Twitter for reminders - we’ll make sure you know where to be when it happens.


Follow me on Twitter View Lori's profile on SlideShare friendfeedicon_facebook AddThis Feed Button Bookmark and Share

Related blogs & articles:



 
      

Feedback


9/8/2009 4:24 PM
Gravatar Hello Devcentral Guru's,

I did visit F5 booth at vmwold and one of the wondefull marketing person at the booth explained me about the demo but was not able to answer few questions which are troubling me since saw this demo. Even the technote doesn't explain the solution from technical/configuration perspective. Below are few of my questions can someone please answer these else I will pull my hair :-)

1. What is the default gateway for the servers (VM) which is part of the pool that is migrated to cloud?
2. Are the connections SNAT'ed to the VM's???
3. How are the connections SYNC'ed to the BIG-IP LTM in the cloud?
4. If the connections are SSL then how are the connections SYNC'ed to clound LTM?
5. Does the existing connections take asymmetric path?? forward direction handled by DC LTM and return is handled by cloud LTM? If yes how are connections SYNC'ed??

Thanks,
Tech Savy Engineer

Tech Savy

9/10/2009 9:35 AM
Gravatar @Tech Savy,

I've consulted ye experts on this demo and have some answers for you:

1. Most likely, given the setup, the default route of the server is the local LTM. Basically the route has to go through the LTM eventually. It kind of depends on the implementation, but the VM's in the demo were directly attached to the internal network or the LTM, which would make the default GW on the servers the local LTM.

2. We're NAT'ing the destination address from a public to a private and using GTM to distribute the appropriate public address.

3, 4, & 5. Existing connections maintain the same path/connection they did before the move. We don't need to do any synching. The connections that went to the old data center
still go there and return from there--so, no asynchronous return routing--although, depending on the security implementation, there would be no reason we couldn't.

Hope this answers your questions, and thanks for asking!
Lori MacVittie

9/10/2009 11:15 AM
Gravatar @Lori,

Thanks for your prompt reply and yes it did clear some of my doubts but there are still some doubts specific to this demo which are not yet clear.

So firstly let's say www.foo.com is mapped to IP which is in DC1 by GTM. Users are connected to this IP which is a virtual server on DC1 LTM. Now you mentioned that you are NAT'ing only Destination and NOT source. So when the VM is vMotioned to DC2, for exisiting connections how would the VM servers response go back to DC1's LTM which handled this traffic originally?. Infact if I look at the Demo on the youtube again I see that for exisiting connections after the VM has moved to DC2 the return trafffic directly goes to the client (Red dot traversing back to client in the video). So would it be possible for you to explain based on the some IP addresses and flows to understand how the packets traverse before and after the VM vMotion'ed that would be really really helpful as there is lot of interest in this demo.

Thanks,
Tech Savy Engineer
Tech Savy

9/10/2009 11:39 AM
Gravatar I see your question. We have a "Tech Brief" on the subject (available here [PDF]) but the relevant information is:

4. Data Center Connection Redirection
After successful completion of the VMotion migration event to the secondary data center, BIG-IP LTM at the secondary data center will recognize that the application is up and available. BIG-IP LTM at the primary data center will start routing existing connections through the iSessions tunnel to the VM now running at the secondary data center. BIG-IP GTM will also begin sending any new connections directly to the migrated VM in the secondary data center. As the existing user connections naturally terminate, all application traffic will be routed natively to the secondary data center.

Sorry no specific IP addresses, but this seems to answer your question directly: after migration existing connections are routed through (bidirectionally) the iSession tunnel, new connections are routed directly to DC2 LTM.
Lori MacVittie

9/10/2009 11:43 AM
Gravatar One more thing - apparently the recorded demo has an error that was fixed in the slides nad presentations at VMWorld regarding the path of existing connections. The recorded video shows the path of traffic as:

LTM1 -> tunnel -> LTM2 -> VM -> Client

The return path is wrong in that it doesn't go back through the tunnel. On the return path the traffic simply reverses so it traverses the tunnel.
Lori MacVittie

9/10/2009 4:35 PM
Gravatar Thanks Lori, I infact had gone through the PDF document you have mentioned earlier but I am not able to clearly get the flow of the packets. It would be very helpful if someone from F5 posts this demo's configuration details.

Anyway thanks for your prompt responses.

Tech Savy Engineer
Tech Savy

9/2/2009 4:04 AM
Gravatar How to Build a Cloud Without Using Virtualization
Lori MacVittie

10/2/2009 12:01 PM
Gravatar @ Tech savy
I was stumped by some of the same questions. One of the pieces that I think is missing from the demo and tech brief is the use of a second pool member on the DC1 LTM. This pool member is actually a virtual server on the DC2 LTM and uses priority group activation. You would probably need to SNAT the traffic to get it to return via the DC1 LTM symmetrically (across the iSession tunnel). Hope this helps explain.
-Bob
SemperFiGuy

1/8/2010 3:56 AM
Gravatar Pursuit of Intercloud is Practical not Premature
Lori MacVittie
 Leave Feedback
Title  
Name  
Email
Url
Comments   
Please add 3 and 3 and type the answer here: