Re: Failover Between 2 Datacenters

[ken price <kprice75@xxxxxxxxx>]

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