On 11/29/2011 2:46 PM, Donny Brooks wrote:
Hello all. I am in need of some guidance. First a little background. Currently our mail server is on physical hardware (Dell server with 2x 2.8GHz Xeon w/ 4GB ram, raid5 array, single gigabit nic) running on Fedora 11 and postfix-2.5.6-3.fc11.x86_64 with dovecot-1.2.11-3.fc11.x86_64. Mailstore is via Maildir format that was converted from mbox about a year ago. This same machine is also our PDC with samba, Master LDAP, slave MySQL replication, primary DNS, and home server for about 20 users.
We have approximately 200 end users that have mailboxes on the server ranging from 1KB to 20GB in size. Total mail store is currently at 300GB. About 75 of the users are currently POP access and their mail will be moved to the server soon and setup as IMAP. This is calculated to add roughly another 150GB of mail for a total of 450GB mail store. Being a state agency we have to keep the mail indefinitely for public record reasons. We use a mixture of Thunderbird as an IMAP client and SOGo for web access.
Now to the problem: Recently we have been having super slow access to the mail server. Turns out the load was insanely high partially due to the samba home server portion, which is being moved off as we speak, and the other part is due to people searching their mail. Just yesterday one of our users nearly brought the entire agency to its knees by performing a search on her 8GB of mail via IMAP.
Since the server is old in both hardware and software I have been tasked with moving it to newer hardware and a newer OS. We currently have 3 virtual servers running Xen and a SAN. The new setup will be placed in the virtual environment. I will probably run Fedora 16 as the OS but am open to Centos, Fedora, or Ubuntu.
Now to the question: What is the best way to setup Dovecot so that it is tuned for performance and high available? We have been running with this single point of failure for years so as long as we are moving the mail server we might as well build in some redundancy. To solve the searching problem I thought of maybe setting up some type of indexing. I do kind of want to break the various services out on to separate virtual machines for a little more fault tolerance, but that is not totally necessary.
What do you think of things like iRedmail? I see it's usefulness but the not being able to separate services kind of defeats the purpose, plus I want to setup a high available MySQL cluster and possibly OpenLDAP or 389 cluster so iRedMail may not be the best solution.
Sorry for the long email but I am trying to get all the information out there at once so it will help get more directed responses in the shortest amount of time. I look forward to any and all input on this matter
Donny B MDAH
Build an Enkive server: http://www.enkive.org/ and configure your SMTP MTAs to transparently copy all email to it (recipient_bcc for example). This fulfills your retention requirements.
Since all emails are now archived by Enkive as they arrive, cron a nightly script on the Dovecot server to delete any emails over a week/month/etc old (depending on your short term access needs) from your active Dovecot mailboxes. This drastically reduces your Dovecot storage requirements.
Searches will be performed by the Enkive server, removing that load from your Dovecot host. Search interface demo here: http://www.enkive.org/demo
In addition your total mail storage (active+archive) requirement will be a fraction of what it is now because Enkive performs deduplication of email content and attachments so you save even more disk space.
Enkive can run fine as a VM if you give it the required resources. Carve an appropriately sized LUN off the SAN array for the Enkive server storage. Format it with XFS for best performance.
Enkive should be a good fit for your needs. Bear in mind installing/configuring it is not for the faint of heart:
http://wiki.enkive.org/index.php/Installation_Instructions http://wiki.enkive.org/index.php/GettingMailIntoEnkive
But thankfully administration is relatively easy: http://wiki.enkive.org/index.php/Administrator_Manual
-- Stan