Hi,
* Lincoln Dale <l...@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
