Failover Between 2 Datacenters

ken price kprice75 at yahoo.com
Thu May 1 18:33:27 BST 2003


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 at wordwork.co.za> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.graemef.net/pipermail/lvs-users/attachments/20030501/1ebb5ece/attachment-0001.html 


More information about the lvs-users mailing list