Any reason why the following won't work? It sounds too "easy"...
Server A is the primary DNS for a domain, and hosts its website, its database, and its email (SMTP in, dropped to POP3 mailboxes via spamassassin). All relevant records are in the DNS: www., pop3., etc, and point to Server A.
Server B is the secondary DNS for a domain, but all the records (www./pop3./etc) point to Server B (not A). Server B has an exact copy of the website, the database (synchronised through MySQL replication), and drops any email it receives through its own spamassassin into its local POP3 mailboxes.
Server A also uses fetchmail to collect mail from Server B and drop it into its local POP3 boxes, in case any arrives there.
TTL on DNS records on both servers is set to a short period (say 15 mins).
In normal use, the domain resolves to server A and server B just acts as a redundant backup. If/when server A fails, its DNS vanishes and so clients request from the DNS on server B, which directs them to the website and database on server B and drops email into its local POP3 mailboxes. (The end user, when checking their email, will likewise get Server B when they query pop3.theirdomain and start collecting email from Server B.)
When server A recovers, things go back to normal, with any remaining mail in the POP3 mailboxes on Server B pulled over by fetchmail.
Server A and B will be in entirely different locations (maybe not even on the same continent!)
The only obvious problem which comes to mind is that writes to the database on Server B will get the databases out of sync, therefore I'd make remove write access to the databases from the website and modify the website code to handle that.
In case anyone ends up at server B when server A is up and running, it could be told to connect remotely to the database on server A unless it can't, falling back to database B. In this scenario session handling would be messed up unless the session info is stored in the database and sync'd across.
NB: From experience a lot of spam follows the lower priority MX in case it bypasses the spam checker, which would put a lot of the spam load onto the redundant server, hopefully allowing legitimate email through more quickly.
On Thu, Apr 05, 2007 at 04:28:02PM +0100, Mark Rogers wrote:
Any reason why the following won't work? It sounds too "easy"...
Server A is the primary DNS for a domain, and hosts its website, its database, and its email (SMTP in, dropped to POP3 mailboxes via spamassassin). All relevant records are in the DNS: www., pop3., etc, and point to Server A.
Server B is the secondary DNS for a domain, but all the records (www./pop3./etc) point to Server B (not A). Server B has an exact copy of the website, the database (synchronised through MySQL replication), and drops any email it receives through its own spamassassin into its local POP3 mailboxes.
...
In normal use, the domain resolves to server A and server B just acts as a redundant backup. If/when server A fails, its DNS vanishes and so clients request from the DNS on server B
That's not the way DNS works. Servers are returned in a random order and the concept of "primary" and "secondary" is more accurately described as "master" and "slave" - the primary is the server all the secondaries slave from, but it's not the first server that will necessarily be tried to lookup a host.
J.
Mark
What about mobile IP, does that work over the internet?
ie server A and server B have a virtual IP address and that is what the DNS server points to. Server A normally uses this IP address but when it goes down the IP is passed server B.
A bit like router HSRP but globally.
Regards Keith
________________________________
From: main-bounces@lists.alug.org.uk on behalf of Mark Rogers Sent: Thu 05/04/2007 6:23 PM To: main@lists.alug.org.uk Subject: Re: [ALUG] Redundant web hosting
Jonathan McDowell wrote:
That's not the way DNS works.
Well that pretty much blows that idea out of the water then!
-- Mark Rogers // More Solutions Ltd (Peterborough Office) // 0845 45 89 555 Registered in England (0456 0902) at 13 Clarke Rd, Milton Keynes, MK1 1LG
_______________________________________________ main@lists.alug.org.uk http://www.alug.org.uk/ http://lists.alug.org.uk/mailman/listinfo/main Unsubscribe? See message headers or the web site above!
On 05/04/07, Mark Rogers mark@quarella.co.uk wrote:
TTL on DNS records on both servers is set to a short period (say 15 mins).
In addition to other comments, remember that Windows clients will cache the DNS lookup and ignore the TTL, anyway. Which is a right PITA if you use DNS to redirect lookups from a failed server to a backup.
Greg