On 01/13/2012 12:22 AM, Paul O'Rorke wrote: > hmmm - it looks like I may have to re-evaluate this. > > Geographic redundency is the point of this exercise, our office is in a > location that has is less than ideal history for power reliability. We are > a small software company and rely on email for online sales and product > delivery so our solution - what ever it be - must allow for one location to > completely lose power and still deliver client emails.
as Dimitri says ... you really want to have a look at Google apps for business ... Regards, Andreas > > Mail is a very complex subject and I must confess that the excellent > suggestions made here may be a little more than I was prepared to dive into. > > Given that this is a HA-Linux list, and that if I understand this correctly > it is not really designed for multi-site clusters, can anyone suggest a > more suitable technology? (the server is running CentOS/Exim) > > Or perhaps I should be doing the grunt work and trying out some of the > above suggestions... > > I do appreciate the excellent feedback to date! > > thanks > > On Thu, Jan 12, 2012 at 1:53 PM, Arnold Krille <[email protected]> wrote: > >> On Thursday 12 January 2012 22:14:41 Jakob Curdes wrote: >>> Miles Fidelman wrote: >>>> - you can set up a 2ndry server (give it an MX record with lower >>>> priority than the primary server) - it will receive mail when the >>>> primary goes down; and you can set up the mail config to forward stuff >>>> automatically to the primary server when it comes back up -- people >>>> won't be able to get to their mail until the primary comes back up, but >>>> mail will get accepted and will eventually get delivered >>> >>> Just one additional note: in such a setup, you should not assume that >>> the secondary server only receives mail when the first one is down from >>> your side of view. >>> A client somewhere might have a different connectivity view and might >>> deliver mail to your secondary MX at any time. It is well-known that >>> spammer systems even try to deliver to the secondary in the hope that >>> protection there is lower. So, if you have a secondary, you must arrange >>> for mail delivered to that server to be passed on to the primary or a >>> separate backend server. And you need to protect it exactly as good as >>> your primary against virus, spam, and DOS attacks. >> >> So: If you go through the hazzles to set up a second receiving host with >> the >> same quality and administration requirements as the first one, you will >> also >> want to reflect that by giving it an equally high score in the mx field. >> That >> way both servers will be used equally and you get load-balancing where you >> originally meant to buy hot-standby:-) >> >> Another comment from here: Email is such an old protocol that the immunity >> to >> network errors was built in. If a sending host can't reach the receiver, it >> will try again after some time. And then again and again until a timeout is >> reached. And that timeout is not 2-4 seconds like with many tcp-based >> protocols but 4 days giving the admins the chance on monday to fix the >> mailserver that crashed on friday evening. Of course, if you rely on "fast" >> mail for your business, the price of redundant smtp and redundant pop3/imap >> servers might pay off. >> For redundant pop3/imap the cyrus project (and probably the other too) >> seem to >> have a special daemon to sync mails and mail-actions across servers. Add a >> redundant master-slave replicating mysql (or postgres) for the account >> database or even ldap and you should get something that even scales beyond >> 2 >> machine. Completely off-topic for this list as I haven't thrown in any >> heartbeat, pacemaker, corosync or drbd at this point. >> >> Have fun, >> >> Arnold >> >> _______________________________________________ >> Linux-HA mailing list >> [email protected] >> http://lists.linux-ha.org/mailman/listinfo/linux-ha >> See also: http://linux-ha.org/ReportingProblems >> > > > -- Need help with Pacemaker? http://www.hastexo.com/now
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
