Failover Between 2 Datacenters
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
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 ?
Do you Yahoo!?
Yahoo! News - Today's headlines
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lvs-users