Redundant mail without xsan?

Question

Scenario:
Two buildings, A and B. Both have 1 internet line each. Both have 1 computer running OS X server. Currently all of our mail runs through the server in building A. I know this is not ideal since if the internet connection goes down in building A, our mail goes down too. From my understanding, an MX record could be created so that all mail would be routed to building B when building A goes down. Is there an easy way to link the datastores together (some sort of replication or sync?) so that mail will appear to have never gone down?
Any help or suggestions would be greatly appreciated.
Thanks!
-Matt
PS: I have a proposal in now to get another connection added to building A however it may not happen for some time.
Message was edited by: Matt Edman

Answer 1

It's tricky to get multiple mail servers writing to the same mail store (e.g. user mailboxes) at the same time. Issues of concurrent access mean that if both servers try to save a user's message at the same time, bad things can happen. That's the element that XSAN addresses - arbitrating which server has access to the files.
That said, all is not lost.
First you need to consider the duration and frequency at which building A's network goes down - are you trying to engineer a solution for something that happens rarely?
If Building A's network goes down for 5 minutes once a year then the pain and cost of failover (and fallback) may outweigh the problem. If it goes down daily for an hour, though, then that's a different problem (probably one I'd raise with the ISP in question, but that's a different issue )
Second, are building A and building B's connected directly, or do they communicate over the same internet connections?
By this I mean is Building A's internet connection goes down can the server in Building B still talk to it over some internal network, or would it try to use the broken internet link?
If they can't communicate directly then I don't see much of a solution anyway - there's no way for Server B to update the mail stores anyway.
If they can communicate directly then the simplest solution would be to setup Server B as a simple mail relay for your domain. In this way, remote mail servers send their messages to Server B (via MX records in DNS), Server B accepts the message and relays it over the internal network to Server A.
Server A is still running, and has access to the mail store, it just can't talk to the internet, but it doesn't need to in this scenario. More importantly, Server B doesn't need direct access to the mail stores - it's just passing the messages to Server A to deal with as it would normally.
None of this, though, addresses the issue of user mailboxes. For internal users it's not an issue - they can still access the POP/IMAP service on Server A, regardless of the building's internet connection. External users, however, wouldn't be able to connect since Building A's internet link is down.
Solutions to this one are harder since there's no automatic failover technology for POP or IMAP protocols (unlike MX records for SMTP). Typically this is addressed by changing your DNS to send external users to a second IP address (e.g. one on the server in Building B), and that's where the pain of failover comes in.
If your DNS TTL is set to something typical like 4 hours then it could take up to 4 hours for external clients to notice a DNS change, in which time their mail client will continue to try to connect to the server in Building A. If the network comes back up in that time then the user didn't need the failover anyway so you wasted your time in setting up the DNS failover.
Some people overcome this by setting very low TTLs on the mail server DNS records (e.g. 5 minutes). This causes the mail client to lookup the mail server address more often, so it will notice a switch faster, but at the cost of additional load on your DNS server.
There's also the question of how to change the DNS. Some people opt for an automatic switch, others prefer a manual switch (where someone goes in and changes the server address in DNS). Both have their pros and cons. Personally I prefer the manual approach since you can decide whether or not to fail over client traffic based on expectation of outage duration (if you think the network is likely to be down for only a few minutes then don't bother switching the DNS since no one's going to notice it anyway).