[Linux-cluster] High availability mail server

[Roger Pena Escobio]

--- On Mon, 10/26/09, Gordan Bobic <gordan at bobich.net> wrote:

> From: Gordan Bobic <gordan at bobich.net>
> Subject: Re: [Linux-cluster] High availability mail server
> To: "linux clustering" <linux-cluster at redhat.com>
> Received: Monday, October 26, 2009, 8:50 PM
> On 26/10/2009 23:54, Ray Burkholder
> wrote:
> >> 
> >> High avail. Mail? That's what MX records are
> for.  Performance, would
> >> be a side effect of multiple MXs.  Having it
> "clustered" wouldn't make
> >> mail deliver any quicker.  Why make something
> so simple into something
> >> complex?
> >> 
> > 
> > Mail delivery and MX records are easy.  But once
> mail is received, you have
> > to get it to user's mail boxes, and users have to gain
> access to the
> > repository.  The repository should be 'highly
> available' in some fashion:
> > partitioned storage units, redundant storage,
> replicated storage, backup
> > storage, or whatever.  I believe that is the hard
> bit:  making the
> > repository 'highly available'.
> > 
> > How do people do it?
> 
> Here are some options you have:
> 
> 1) Use a NAS/NFS box for shared storage - not really a
> solution for high availability per se, as this becomes a
> SPOF unless you mirror it somehow in realtime. Performance
> over NFS will not be great even in a high state of tune due
> to latency overheads.
> 
> 2) Use a SAN with a clustered file system for shared
> storage. Again, not really a solution for high availability
> unless the SAN itself is mirrored, plus the performance will
> not be great especially with a lot of concurrent users due
> to locking latencies.
> 
> 3) Use a SAN with exclusively mounted non-shared file
> system (e.g. ext3). Performance should be reasonably good in
> this case because there is no locking latency overheads or
> lack of efficient caching. Note, however, that you will have
> to ensure in your cluster configuration that this ext3
> volume is a service that can only be active on one machine
> at a time. If it ends up accidentally multi-mounted, your
> data will be gone in a matter of seconds.
> 
> 2b) Split your user data up in such a way that a particular
> user will always hit a particular server (unless that server
> fails), and all the data for users on that server goes to a
> particular volume, or subtree of a cluster file system (e.g.
> GFS). This will ensure that all locks for that subtree can
> be cached on that server, to overcome the locking latency
> overheads.

what about using a combination of 3 and 2b:
3b- split your users in a set of servers which use ext3 FS but are part of a cluster, the servers are really services of a cluster (IP and FS are resources of a CLuster Service) so, if a server fail its service can be migrated to another node of the cluster

let say for example
users starting with letter 'a' to users starting with letter 'h' will "assigned" to MailA , users from 'i' to 'z' will be assigned to MailB.
MAilA --> ipA and filesystemA
MAilB --> ipB and filesystemB

Cluster ServiceA will have resource ipA and filesystemA
Cluster ServiceB will have resource ipB and filesystemB

and ServiceA will be configured to run in nodeA, while ServiceB will be set to run in nodeB of the cluster, but will be set to failover to nodeC (standby server)

the hard part of this is how to balance the users between MailA and MailB (and MailC , D, E). Changing the value of "mail_host" in user attr (if using a Directory Service) and moving user's email from one filesystem to another

this is just food for the brain, the scenario could be as complex as you like :-), but definitely is no good idea to have GFS for mail servers if the clients can connected from multiple sources and dont have a "proxy" to tunnel all request for same user to same backend server.

thanks
roger