On Monday 24 November 2008 12:04:44 bsd wrote: > Hello folks, > > > I am actually working for an African country where the electricity is > not as stable as one could expect - even in the infrastructure of the > historical telco operator… > > With all the care that we have been able to devote to this project, > stability is still very very limited. > So my idea was to create a fully redundant mail server. > > Ideally I would like people not to have to reconfigure anything on > their client and to be able to connect to any resource available > online (main African server or the backup one in Europe) - in a > seamless way. > > > Mail protocol has solved the issue of "backup" server (secondary MX)… > but how can I achieve a real redundant server. Knowing that the "main > server" and the "slave" are located 8000 Km away with poor link quality. > > What would be your aproach to solving this problem. > Of course loosing mail is really an issue.
Technical solutions to this would typically involve some form of replication, often at the filesystem or block layer (eg: DRBD), coupled to a mechanism to fail-over between systems (eg: heartbeat moving an IP address between two machines on the same subnet). These start to break-down when you have an unreliable link between the two systems, since this will cause a lot of bouncing between the sites, and probably a lot of split-brain scenarios where both machines think they are the primary, and both try and claim the "live" resources. As an aside, requiring that clients do not need to change any configuration would assume that they are configured to point to a DNS hostname, so you'd need a mechanism to change that in the event of a fail-over. While this is technically easy, what happens if your primary DNS server is hosted in the same place as your mail server and a failure occurs? Assuming your working data-set is such that a regular rsync would suffice to keep two machines in sync (with a human making the decision to change a DNS entry to point to the backups server) I think this may be one of the few viable options you have. Mark. -- Mark Watts BSc RHCE MBCS Senior Systems Engineer QinetiQ Applied Technologies GPG Key: http://www.linux-corner.info/mwatts.gpg
signature.asc
Description: This is a digitally signed message part.
