Not to side step the original question, but I see this kind of discussion frequently. This is another example of where the network can be made to solve a problem that it's best leaving up to a higher-level mechanism.
In this case, if you have multi-site fault tolerance requirements between N datacenters, it's far simpler to not vmotion between them. Rather, replicate the resource tier (database & storage), stand up the presentation and business-logic tiers in multiple sites, and front-end the service with a load balancer. Cisco actually makes a product, the Global Site Selector (GSS) to handle this kind of scenario. By probing the load balancer at each site for service health checks, and manipulating DNS replies, we can guarantee that service requests only get sent to datacenters where the service is healthy. We can completely side-step the problem is moving an IP address by letting the services designed to handle this kind of thing work their magic. Now, I will be the first to admit that there are some cases where this simply doesn't work well, legacy services that only support one instance and no replication, etc. however for the majority of modern apps that fit a tiered model (presentation, business-logic, resource), this is a far simpler, faster, and less complex way to achieve maximum redundancy and DR capability. 3 -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Alexander Clouter Sent: Tuesday, August 10, 2010 6:53 AM To: Lincoln Dale Cc: [email protected] Subject: Re: [c-nsp] LAM / Mobile IP in modern times Hi, * Lincoln Dale <[email protected]> [2010-08-10 20:46:53+1000]: > > >>> The only remaining question is why for it's money have VMWare not done > >>> the trivial task of making OSPF part of their VMotion malarkey...*sigh* > >> > >> because its not /quite/ as simple as you suggest. > >> > > The awkward part I see is host based (not service) L3 connectivity. The > > operating system would need work happily in a multihomed configuration > > and to understand what a dead gateway means. This probably would not be > > easy to pull off on a Windows based guest, but it should be quite doable > > on....well *any* other OS :) > > the premise of VM mobility is that the OS and apps being virtualised > are completely unaware that they have been virtualised. > > what this means in reality is that you can migrate a VM from one > physical host to another and there is no disruption to traffic flows. > there are no disruptions to any TCP connections to apps running on the > (virtualised) server. > ...and there would not be as the *service* IP would remain present. It is the service IP that is being advertised over OSPF, *not* the host IPs. The idea is you assign multiple IP's to your hosts. Sure this approach, instead puts the complication of migration into the multiple number of hosts (would not be a problem if VMware did the OSPF) rather than in the network. The advantage is that you are now playing with a very familiary technology (OSPF/iBGP) where you can find many engineers who can understand what is going on. > but in order for this trick to be pulled off, you need a common L2 > domain. > No you do not. > if you're willing to remove that requirement and potentially have an > outage or disruption at the host or app level, or you're willing to do > whatever integration work is necessary to mitigate that, then i > believe its technically possible to have vMotion across L3. > The disruption lasts only as long as your iBGP/OSPF takes to rejiggle surely? Not much worse than ARP argubly. > but note that not all apps will be supported. nor all hosts. and if > those apps/hosts are doing any form of network-based storage access > (NFS, CIFS, iSCSI et al), then bad things may well happen unless you > can quiesce the virtual host on a migration. > iSCSI can re-establish transparently the connection, NFS you can put into UDP mode as a quick fix. CIFS, crime and punishment ;) If you want to maintain TCP state, that you add to your routing table that when communicating with ${STORAGE_SERVER} use a particular source IP, this is not tricky stuff. Cheers -- Alexander Clouter .sigmonster says: Life is like a simile. _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
