[Dovecot] Newbie questions: Load-balanced Dovecot with NFS storage
Mike Brudenell
pmb1 at york.ac.uk
Fri Mar 2 16:12:10 EET 2007
Hi,
I experimented with Dovecot a while back and our site is now taking
the plunge to switch to it from the UW IMAP server when we rejig the
topology of our mail store and IMAP servers.
Currently we have a farm of 5 IMAP servers running the UW server.
Each has locally attached disk used to store people's mailboxes.
Each user is allocated to one of these five servers and can only
access their mail via that server. Our aim is to remove this
restriction to provide resilience in the event of a server failing.
Our thoughts...
* We are envisaging having a farm of N (to be determined) servers
running
Dovecot. These will be closed systems: users do not have shell-
access,
and can only reach their mail via IMAP.
* A single mailstore common to all N servers will be hosted on our
NetApp
filer and NFS-mounted on each server. Each server would be running
Solaris 10. If we use all-new kit it will be x86-based, or we
may have
to redeploy some of our existing SPARC boxes to the new service.
* We will be converting user mailboxes to be in Maildir format.
* Our hardware load balancer, which supports persistent sessions,
will be
used to distribute users between the servers.
This could either direct a user to any one of the N servers, or
could be
set to 'prefer' a given server for a particular user (only
failing over
to one of the others if their 'usual' server was unavailable).
More on
this in my questions below. :-)
I have been scouring the Dovecot list, archives and Wiki and think I
have come up with a set of issues we need to be aware of and things
we have to do in order to make this work reliably.
Please would you let me know if I have missed or misunderstood anything?
Issues To Watch For
-------------------
* For timestamp integrity our servers will be synched with NTP to our
local time server.
* Because sessions could be on different servers memory mapping of
index
files doesn't work well with NFS, so set
mmap_disable=yes
in dovecot.conf.
* Dovecot relies on the mtime timestamp of mailbox files so the
NFS-mounted mailstore needs to be mounted with these options on each
server:
actimeo=0
(Are there any other mount options we should use too?)
* We will be using filesystem quotas on users mailboxes. We understand
that Dovecot's index files are best on no-quota filestores so
will store
these separately.
Questions
---------
Q1. Would it be better to store the index files on NFS-shared
filestore and
direct users to any of the IMAP server machines? Or to store
the index
files on local disk and direct each user to their 'preferred' IMAP
server machine?
Q2. Does Dovecot (or "something") clean out old index files that haven't
been accessed for a while? Eg, when a user has temporarily come
through on a different IMAP server to normal. Or do the index
files
sit there untouched for evermore?
Q3. Storing the index files on the NetApp filer would give us the
ability
to share them between servers and grow their volume as need be,
but at
the cost of performance. How big do the index files get? Are they
typically a few kBytes per message? Per mailbox? Per user? Or more?
Q4. We will be using Exim as the MTA, which can deliver direct to
Maildir
mailboxes. However I understand that Dovecot's "deliver" LDA
adds the
benefit of updating the index files as each message is
delivered. Is
this a significant gain? Or is there little difference in
actual use?
Q5. We have around 20,000 mail accounts and will therefore be seeing
lots
of concurrent IMAP sessions, usually secure (SSL) ones. I have
seen
mention that this can give rise to "Too many open files" errors
under
Solaris. How do we avoid this when we are likely to have several
thousand concurrent IMAP sessions per server machine?
With many thanks for your time and advice...
Cheers,
Mike Brudenell
--
The Computing Service, University of York, Heslington, York Yo10 5DD, UK
Tel:+44-1904-433811 FAX:+44-1904-433740
* Unsolicited commercial e-mail is NOT welcome at this e-mail address. *
More information about the dovecot
mailing list