[BlueOnyx:05267] Re: Secondary mail server

[Gary Sedgwick]

Hi David,

Many thanks, that was just the info I was after, and spot on for what I'm
trying to achieve.  For some reason I had assumed that the vsite config
might have problems if the accompanying users were not set up, but on
reflection I can't see why.

Aventurin{e} looks great, but for many vsites ("unlimited" option) and
clustered, it's just out of my price range.  I'm also worried about what
really happens under the covers e.g. whether to worry about split brains,
etc.  I've spent ages looking into heartbeat/pacemaker etc., but again
it's the issues with split brains, hardware for proper STONITH, etc.  As
well as the fact that it just seems so extremely complicated to set up! 
In contrast, I set up and successfully tested DRBD in no time at all - and
I was worried that was going to prove to be the biggest headache.

As you say, it's most critical my websites get failed over quickly, and
they are mostly static (I'm going to worry about the dynamic ones later). 
Having a haproxy (or similar balancer) solution for this will also
potentially make use of both server's bandwidth allowances as an added
bonus.  And users can live without their mails for a short period while
I/someone manually fails over to the other VM (will have the backup image
via DRBD) - just as long as no mails go missing, hence wanting a backup
mail server.

Thanks to everyone for their help, when I do get this up and running I
plan to put up a detailed howto somewhere.

Gary

>> Many thanks for all the info.  I'd appreaciate it though if you could
>> explain what exactly would happen in the scenario I described, and why
>> mail will "randomly" end up on each server.
>
> You guessed what will happen in your own original question:
>
>>> I'm hoping), or will it be delivered to the redundant mailboxes on the
>>> secondary server?
>
> Mail will get delivered to the mailboxes on whichever server it first
> lands on, not queued for the primary server only.  Not pretty.
>
>
> IF your client websites are completely static, and do not utilize any
> read/write databases or forums or anything like that, then you can achieve
> your goal (load balancing and/or quick failover of web, queued email
> waiting for main server to come back up) with the right config, no extra
> software needed. If you have any dynamic data driven websites, you'll need
> to go with the clustering solution Chris presented.
>
> Quick & Dirty Failover Web for Static Sites
>
> - Configure main and backup servers as primary DNS servers, not
> master/slave. You need to configure all the records on each server
> individually.
> - Set A records of hosts to correct vsite IPs corresponding to that
> specific server (backup server vsite IP not the same as main server vsite
> IP). That yields web load balancing and failover.
> - Set the MX records to deliver to main server at highest priority, backup
> server at lower priority, and make the "mail" hostname A record point to
> main server only.
> - Duplicate the vsites on both servers BUT make sure that the USERS only
> exist on the main server. The backup server should not have any users.
> - MUST ensure that the site domains are listed on the backup server in the
> "Relay Email From Hosts/Domains/IP Addresses" email server setting.
>
> When mail gets received on backup server, it will be queued for delivery
> to user on main server. If the main server is alive, that will happen
> immediately. If the main server is offline, mail will just get queued on
> the backup server until the main server comes back. Default queue duration
> is 5 days I think, you can change that in sendmail config. When a user
> browses a website, they will hit either the main or backup server,
> depending on which DNS server their system queried -- should be completely
> seamless to the user if you have the same web data on both servers. If the
> main server (including DNS) conks out, website users will just be hitting
> the backup server, until the main server is revived.
>
> Your customers will of course be unable to receive their email while the
> main server is down, so they will know there is a problem, but website
> visitors will still be served, and customer emails should be queued until
> the main site returns.
>
> David Thacker
>
> _______________________________________________
> Blueonyx mailing list
> Blueonyx at blueonyx.it
> http://www.blueonyx.it/mailman/listinfo/blueonyx
>