| |||||||||||||||||||||||||||||||||||
|
Could Kansas Save Texas? Members of the ISP-Tech list discuss setting up a simple emergency backup system for e-mail services, but disagree about how simple the system can be.
On the ISP-Tech list in March, TW inquired,
SY offered one possible solution: "You could just set up your DNS with a low TTL value. Of course, your DNS traffic would increase, but if the server went down you would just go in and change the IP address to that of the backup server, and all would be well. I know you could specify two different IP numbers for the same A record, but I'm not sure how machines would react to that. I guess there is only one way to find out: give it a try, and see what happens." DV contended that the answer might be even simpler: "Why not run both sites concurrently, load balancing? Then when one goes down, the other just carries on. Handle the data transaction by transaction, with a 'back channel' link, each server notifying the other of transactions as they go down. You can use GNU Wget to generate a filled-out form to submit to the other server. I've done this with one project, about 2000 transactions per second on a pretty limited server." [SY warned] "The only problem is, where do you put the load balancing device? If the link to that goes down, you're dead." DH suggested that the real answer is actually far more complex: "You're talking about 'round robin DNS,' which will work, but doesn't provide any true redundancy. half of your users will go to the server that's up, and the other half will get a server down message. What you're looking to use is global server load balancing. It will work regardless of whether one link is down. Since both servers would have a device in front of them, there won't be a single point of failure. This isn't going to be cheap, though: you're going to want something like the Cisco DistributedDirector."
End
|
|
|||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||
#