[Dovecot] Redundant shared mail store?

[bofh list]

On 10/30/06, Joshua Goodall <joshua_goodall at pacific.net.au> wrote:
>
> ...
>
I recommend a pair of NetApp filers (e.g. 2 x 3020c) exporting NFS from
> shared disk shelves in their high-availability mode.  This is a hybrid
> of the two options, except a) it's a fully supported and stable NetApp
> configuration, b) they're sharing disk storage, c) you're not hog-tied
> to GFS, d) it's the best NFS implementation in the world (you can even
> trust the fcntl locking), e) it's really fast, f) NetApp's onboard
> snapshots and other funky software bits will make you wonder how you
> lived without them, g) the HA actually works.
>
> I have a six-digit userbase with mailboxes in this configuration.
>
> JG
>
> We are in the process of rolling out / migrating mail from various "other"
imap stores to a cluster of two servers running dovecot-1.0.beta9 attached
to a 3050c cluster.  Hosts are running RHEL4u3 on x86_64 on the latest
official kernel, 2.6.9-42.0.3.ELsmp.  NFS mount options on both machines are
(rw,nosuid,nodev,tcp,nfsvers=3,rsize=8192,wsize=8192,soft,intr,noac,actimeo=0).
We are using default_mail_env with Maildir/indices stored over NFS.  Postfix
with procmail delivery.  Currently we are using DNS round robin as there is
no SLB in the mix just yet.  It is extremely fast.

The only thing I am still mildly concerned about are some errors regarding
index corruption.  These are seen on both machines.  Hopefully a newer
version fixes these.  See below:

dovecot: Oct 31 11:56:52 Error: IMAP(user): Corrupted index cache file
mailstore/user/Maildir/.My-Folder.blah/dovecot.index.cache: invalid record
size

These errors don't appear to have any impact on the client side, performance
or otherwise.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://dovecot.org/pipermail/dovecot/attachments/20061031/b69626c6/attachment.htm