Re: Failover Between 2 Datacenters

[nick garratt <nick-lvs@xxxxxxxxxxxxxx>]

Well a State falling off the map is hardly a failure situation that makes sense  building in 60s minimum latency cutover for. What if the United States fell off the map ? What if the map ceased to exist ?

Keeping your DNS TTLs really low can help you somewhat in this situation, although they certainly cannot be set to not cache at all. Also I have also encountered DNS servers that do not correctly observe these settings. You have no control over all the intermediate name servers that might be caching your DNS records and thus is not suited to low latency failover.

VRRP is basically IP failover through election and is not relevant to this discussion.

It seems to me the only satisfactory solution is for you to apply for your own autonomous system (at considerable cost) which will allow you full control of your BGP data. It will be possible with cooperation for other AS admins to ensure substantial route redundancy and rapid cutovers should you lose a datacentre/state/continent :)

Nick

> 1)  My example should have explained
> ... what if California fell off the map?  A multi-homed,
> redundant facility doesn't do much good.  For the record, I'm
> already colocated at a fully redundant, carrier-class facility. 
> It still doesn't guarantee uptime should a catastrophe occur.  My
> exact reasons for seeking out this type of solution are irrelevant. 
> I simply want to know what my options are with regards to failing over
> live services between datacenters ... much like VRRP between routers,
> or LVS using persistant connections between real servers.
>  
> 2)  Fail to see how that helps me. 
> There are still single points of failure brought on by DNS.  I
> need the source IP of www.somewhere.com to not only
> dynamically change to the backup cluster should a failure occur,
> but update the cached DNS entry in the client's DNS or browser within
> minutes.  Is setting a DNS record to instantly expire really
> feasable?  It's obviously not ideal.
>  
> 3, 4, 5, 6)  Huh?  If WWW is
> always available, why do I need to failover between datacenters to
> begin with?  The assumption is:  What if WWW can't be made
> always available?  (see response #1)
>  
> 7)  I'm already handling all
> database & filesystem replication over an IPSec VPN, so there's no
> need to discuss in this forum.  Thank you, though.
>  
> Thanks,
> Ken
>
> nick garratt <nick-lvs@xxxxxxxxxxxxxx> wrote:
> > Hii
> >
> > Just some clarity: are we talking about HTTP services or any
> > arbitrary service ?
> >
> > Ideally one's hosting facility should be multi-homed and dealing
> > with
> > route redundancy at the BGP level. Clearly this is not an option
> > in
> > the cases under discussion.
> >
> > I really don't see this as an issue that LVS is suited to. The
> > simplest possible solution to this issue as I see it is:
> >
> > 1. Co-host or host a server at a multi-homed (no single route
> > failure
> > will render it unreachable) facility with redundancy ala heartbeat
> > (www).
> > 2. the servers which will actually do the work are hosted
> > elsewhere
> > at multiple cheaper facilities perhaps, without the
> > required route
> > redundancy (www1, www2).
> > 3. mon on www monitors the availability of www1 and
> > www2.
> > 4. ALL incoming HTTP requests are initially directed to
> > www which is
> > always available. one only need issue this URL to one's clients.
> > 5. www simply issues a HTTP header redirect either to www1 or www2
> > according to their health/ redirect count.
> > 6. after the redirect the HTTP client continues to access the
> > server
> > it was redirected to.
> > 7. database replication can be handled over VPN between www1 and
> > www2
> > if necessary. this has its own issues, but is doable.
> >
> > Is this not a workable solution ?
> >
> > Nick
>

---

> Do you Yahoo!?
> Yahoo! News - Today's
> headlines
> _______________________________________________
> LinuxVirtualServer.org mailing list -
> lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
> or go to http://www.in-addr.de/mailman/listinfo/lvs-users