[c-nsp] LAM / Mobile IP in modern times

[cisconsp at SecureObscure.com]

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: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Alexander Clouter
Sent: Tuesday, August 10, 2010 6:53 AM
To: Lincoln Dale
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] LAM / Mobile IP in modern times

Hi,

* Lincoln Dale <ltd at cisco.com> [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  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/