[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Linux-cluster] High availability mail server

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

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.

In options 2 and 3 you could use DRBD instead of a SAN, which would give you advantages of mirroring data between servers and not needing a SAN (this ought to reduce your budget requirements to a small fraction of what it would be with a SAN). Two birds with one stone.

You could also use GlusterFS for your mirrored data storage (fuse based, backed by a normal file system, doesn't live on a raw block device). Performance is similar to NFS, but be advised, you'll need to test it for your use case as it is till a bit buggy.

There is also another option, that doesn't involve block level or file system level mirroring - DBMail. You can back your mail storage in an SQL database rather Maildir. Point it at MySQL, set up MySQL replication, and you're good to go. At this point you may be thinking about master-master replication and sharing load between the servers. This would be unreliable due to the race conditions inherent in MySQL's master-master replication. You won't lose data, but mail clients assume that the message IDs always go up. That means of two messages get delivered in quick succession, the app might see the later message delivered to the local server, but not the earlier message that got delivered to the other server that hasn't replicated yet. Next time it checks for updates in the inbox, it'll not spot the other message with a lower message ID! The client would have to purge local caches and resync data to see the missing message. This means that with this solution you would still have to run it in fail-over mode (even if both MySQL instances would run at the same time to achieve real-time data mirroring). The only way you could overcome this with MySQL is to use NDB tables, but that brings you back to clustered storage performance issues (performance on NDB tables is pretty attrocious compared to the likes of MyISAM and InnoDB).

Anyway, that should be enough to get you started.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]