--On 28 January 2003 12:00 +0000 chibi@??? wrote:
>> Another option is to have a dual port raid system, but this isnt truly
>> redundant because you have a SPOF in the raid system itself.
>>
> As others mentioned, replicating the mail spool is an exercise in
> pain probably futility. Make sure that the actual storage is as reliable
> as possible and affordable and supply multiple, redundant front-ends to
> it.
Thanks for the feedback so far from all concerned. Yes, making the actual
MX and SMTP redundant is relatively easy. We can use multiple servers, and
keep storage as redundant as possible. I plan to do the SMTP by L4
switching in the network. If we lose an operational SMTP server from the
cluster, we dont actually lose much at all, maybe one or two messages that
were sitting in the spool actually being delivered at the time of it going
down and any frozen messages in that spool. We can live with that.
The main problem appears to lie in replicating /var/mail/<mboxname> across
multiple servers. These files need to be kept in sync and accessible from
imapd/pop3d. NFS is apparently not a good idea for this due to the locking
issue. How can this be dealt with without NFS??
Someone suggested maildirs with Courier-IMAP but how does this help us
avoid using NFS and locking? A Netapp filer also uses NFS surely?
Is NFS locking _really_ a problem?
I have to come up with reasons for my boss why we shouldnt switch to a
product which claims to support full email redundancy. i.e. Lotus notes
replicated servers, Oracle Collaboration Suite email server. I know I know,
but hard facts are needed...
