You dont say who the "clients" are - I presume this is a web based application so essentially you are trying to migrate service in flight to another set of servers within the TCP/HTTP session timeout without the client missing a beat ?<br><br>If another kind of client, does it also have auto reconnect/retry logic built in for service restoral if the connection timesout ?<br><br>Is the session/host state worth preserving for communication between the servers in the cluster or between the clients and the service also ?<br><br>I know of people who have been able to do this on LANs using SANs to store shared host states and having a new VM pick up the connections, but on an internet-wide scale you are likely looking only at a probabilistic guarentee assuming that your routing would always converge in time and packets start flowing to the Disaster Recovery (DR) site.<br><br>This is much easier if you can stick within a single AS ofcourse. <br><br>Others will be able to answer
 whether these routing changes will attract dampening penalties if you have to pick providers in different ASes.<br><br>Assuming all of that doesnt matter, then a somewhat cleaner way to do this would be to advertize a less specific route from the DR location covering the more specific route of the primary location.  If the primary route is withdrawn, voila .. traffic starts moving to the less specific route automatically without you having to scramble at the time of the outage to inject a new route.<br><br><br><br><b><i>Andrew Warfield <andrew.warfield@cl.cam.ac.uk></i></b> wrote:<blockquote class="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"> <br>I've got a bit of a network reconfiguration question that I'm<br>wondering if anyone on NANOG might be able to provide a bit of advice<br>on:<br><br>I'm working on a project to provide failover of entire cluster-based<br>(and so multi-host) applications to a
 geographically distinct backup<br>site.  The general idea is that as one datacentre burns down, a live<br>service may be moved over to an alternate site without any<br>interruption to clients.  All of the host-state migration is done<br>using virtual machines and associated magic; I'm trying to get a more<br>clear understanding as to what is involved in terms of moving the IPs,<br>and how fast it can potentially be done.<br><br>I'm fairly sure that what I would like to do is to arrange what is<br>effectively dual-homing, but with two geographically distinct homes:<br>Assuming that I have an in-service primary site A, and an emergency<br>backup site B, each with a distinct link into a common provider AS, I<br>would configure B's link as redundant into the stub AS for A -- as if<br>the link to B were the redundant link in a (traditional single-site)<br>dual-homing setup.  B would additionally host it's own IP range, used<br>for control traffic between the two sites in normal
 operation.<br><br>When I desire to migrate hosts to the failover site, B would send a<br>BGP update advertizing  that the redundant link should become<br>preferred, and (hopefully) the IGP in the provider AS would seamlessly<br>redirect traffic.  Assuming that everything works okay with the<br>virtual machine migration, connections would continue as they were and<br>clients would be unaware of the reconfiguration.<br><br>Does the routing reconfiguration story here sound plausible?  Does<br>anyone have any insight as to how long such a reconfiguration would<br>reasonably take and/or if it is something that I might be able to<br>negotiate a SLA for with a provider if I wanted to actually deploy<br>this sort of redundancy as a service?  Is anyone aware of similar<br>high-speed failover schemes in use on the network today?<br><br>Thoughts appreciated, I hope this is reasonably on-topic for the list.<br><br>best,<br>a.<br></blockquote><br>