Re: [Dovecot] Migration questions...
Hello again, people,
I have been reading all of the emails sent back and forth recently, and reading many web pages, and I have a new draft of my migration plan. If anyone has the time and generosity to read through this latest plan for me and let me know if you spot any potential problems with it, i'd really appreciate it.
FYI, we're moving from a Debian 3.1/exim/uw-imapd/qpopper/mbox setup to a Debian 5.0/exim/dovecot/maildir setup, and the final version of this document can hopefully become a useful guide for lots of people in future too, if I get it right :-)
Anyway... here's the plan...
Install Debian with exim, spamassassin, mysqld (for Horde/IMP) and mailman. Use ReiserFS for the indexes and data. XFS would be second choice for filesystem, and this is something of a religious argument, but Dovecot's own page states that ReiserFS is a better choice, and loads of pages on the Internet say that one or the other is better - there's no clear winner, really, so ReiserFS (the FS we already know and trust) wins the battle.
Run an online update.
Setup IPMI and monitor it from Nagios.
Install HotSaNIC to monitor historical system stats.
Install and configure Dell OpenManage Server Administrator (or whatever it's called) to monitor hardware, and make sure we will be emailed if a hard drive fails.
Rsync homedirs and inboxes onto new server, ready for initial exim configuration.
Configure exim as per existing mail server and test that mailing lists and normal email works. You should now have the existing mail delivery solution on the brand new hardware.
Configure Spamassassin as per current configuration and test.
Configure mailman as per current configuration and test.
Once mail delivery is sorted, add "deb http://www.backports.org/debian lenny-backports main contrib non-free" into "/etc/apt/sources.list" and run "aptitude update && aptitude install debian-backports-keyring && aptitude update".
Install dovecot (at the time of writing, this was version 1.1.13-2).
Run the conversion utility (use "mb2md.py" from http://wiki.dovecot.org/Migration/MailFormat because "convert-tool" doesn't preserve msg UIDs) to convert all existing "mbox" mailboxes into "maildir" mailboxes, for use with Dovecot.
Setup exim to use Dovecot's delivery agent ("deliver") so the indexes are updated on mail delivery instead of when the mailbox is requested and also to use the new maildir format.
Setup dovecot for IMAP and POP3 and test.
*****THIS IS WHERE THE REPEATABLE SECTION BEGINS*****
Stop exim and dovecot services.
Rsync homedirs and inboxes onto new server again.
Run the conversion utility (use "mb2md.py" from http://wiki.dovecot.org/Migration/MailFormat because "convert-tool" doesn't preserve msg UIDs) to convert all existing "mbox" mailboxes into "maildir" mailboxes.
Start exim and dovecot services and test SMTP, Spamassassin, mailman, IMAP and POP3.
*****THIS IS WHERE THE REPEATABLE SECTION ENDS*****
- Once everything is working perfectly, send an email to the entire company instructing them what to do after the outage and arrange an outage and do the following steps as soon as the outage begins:
a. Unplug DMZ switch from firewall to make delivered mail wait atthe sender.
b. Stop exim, IMAP, POP3 and dovecot services on both mail servers.
c. Rsync homedirs and inboxes onto new server again.
d. Run the conversion utility (use "mb2md.py" fromhttp://wiki.dovecot.org/Migration/MailFormat because "convert-tool" doesn't preserve msg UIDs) to convert all existing "mbox" mailboxes into "maildir" mailboxes.
e. Start exim and dovecot services and test SMTP, Spamassassin,mailman, IMAP and POP3.
f. Reconfigure my own mail client to point to the new mail server(192.168.2.3).
g. Reconfigure firewall to think the mail server is now on192.168.2.3 instead of 192.168.2.2.
h. Prepare an email in webmail somewhere in the world, ready to sendto a user on our mail server.
i. Plug DMZ switch back into firewall and begin monitoring exim logsto check that mail is being delivered.
j. Send the email from webmail and check that is goes through eximperfectly and is sitting in the users Inbox. NOTE: We now have a working mail delivery solution!
k. Start dovecot IMAP and POP3 and test both.
l. Once exim and dovecot are both working against live mailboxes,tell everyone the outage is over.
Install and configure Horde & IMP to access email via IMAP.
Reconfigure backup script to make sure new server is backed up.
Modify Nagios config to monitor new server.
DONE!
Thanks in advance, everyone! :-)
Richard.
Brandon Lamb wrote:
On Fri, May 15, 2009 at 5:02 AM, Richard Hobbs richard.hobbs@crl.toshiba.co.uk wrote:
Richard Hobbs wrote:
Seth Mattinen wrote:
Phillip Macey wrote:
On 14/05/2009 5:11 PM, Steffen Kaiser wrote: > On Wed, 13 May 2009, Richard Hobbs wrote: >> The main complaint we have from users is that their IMAP Inbox, with >> 5000 emails in it takes ages to appear, and no amount of coaxing will >> convince them to split their inbox into multiple folders. > Oh, we serve Maildir via Dovecot IMAP and 5000 messages per folder are > a wimp. Problems start if the user: We are having some performancec issues on our server at the moment - all I can put it down to is the large size of some maildirs. Eg.
ls -ld Maildir/curmight show a directory >20Mb in size for some of our users (20-30k emails). (Performance issues == everything is running ok then all of a sudden load avg goes through the roof, system cpu time goes crazy. Reading mail grinds to a halt. Then everything recovers just as suddenly and the load avg gradually returns to normal levels) Are you using ext3 by chance? Vanilla ext3 without directory indexing (or whatever it's called) *hates* directories with a lot of files - like maildir. Personally, I use XFS, which doesn't suffer from this problem since it uses b-trees instead of a table(!) like ext3 does. This raises another question for me actually...We will have one volume for indexes and another volume for data (using maildir). We will be using the latest stable Debian Linux distro.
Any opinions on the best filesystem to use? We would normally go ReiserFS for large volumes, and ext3 for small volumes because of the unlimited inodes in reiserfs, but i understand that support for that is beginning to disappear given that Hans Reiser got into a bit of trouble a few years ago.
Anyway... that would leave ext3, but is there a better choice i could make in this instance? We do want performance, of course, but also complete reliability and resilience when it comes to system crashes etc... we do *not* want data corruption, and ext3 we know has a very good journalling and data recovery methods. Well... they're very mature, anyway.
I used to use ext3, ran into its horrible performance even with directory indexing enabled, went to XFS and never looked back. All of my systems are Debian stable. Reiser3 is part of the kernel so I wouldn't worry about that; Namesys considered it complete and stopped work on it long before the whole murder thing. Both Reiser3 and XFS have worse reputations than ext3, however, I've seen ext3 filesystems hosed beyond repair, too. All my XFS filesystems have battery-backed cache controllers, so it hasn't happened to me yet, hopefully never. ;) One catch with XFS (such as with LVM) to keep in mind is you can't ever shrink it, only grow. Trouble is... i've been googling this as well, just now, and loads of
Seth Mattinen wrote: people say XFS has the better performance, but loads of other people say ReiserFS has the better performance.
We have battery backed up RAID controllers too, in this new system, and the systems are UPSd, so on that basis i'm still none the wiser! lol
I appreciate your experience with XFS is a positive one, but even the dovecot web site says XFS might now be a good choice...
http://wiki.dovecot.org/MailboxFormat/Maildir
What a tough decision! I know it probably won't make too much difference in my situation, but i want this to be a very long-term solution, so want to do it right first time!
Any other opinions on XFS vs Reiserfs with Dovecot maildir?
Thanks again!
Richard.
ext3 is mature but IMHO completely unsuitable for a busy mail server or any situation where you'll have a bajillion of files in one directory. The exact point at which ext3 will screw you over obviously depends on many factors. But when it happens it'll probably be painful to reformat to something better.
~Seth
This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email
-- Richard Hobbs (IT Specialist) Toshiba Research Europe Ltd. - Cambridge Research Laboratory Email: richard.hobbs@crl.toshiba.co.uk Web: http://www.toshiba-europe.com/research/ Tel: +44 1223 436999 Mobile: +44 7811 803377
We have been using XFS on our raids for the last few years. We have fairly new hardware, and using maildir. Delivering over nfs using exim+dovecot deliver. pop3/imap is near instant load on our webmail. We have about 16,000 email accounts with ~175 imap+pop3 connections open all the time. 20 drive sata2 raid 10. amd quad core 9850 with 8 gigs ram. load sits about 0.30 - 0.45 all day/night. Last I checked backups were 30-45 minutes, 413 gigs. 6,403,942 files.
This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email
-- Richard Hobbs (IT Specialist) Toshiba Research Europe Ltd. - Cambridge Research Laboratory Email: richard.hobbs@crl.toshiba.co.uk Web: http://www.toshiba-europe.com/research/ Tel: +44 1223 436999 Mobile: +44 7811 803377
Richard Hobbs richard.hobbs@crl.toshiba.co.uk writes:
- Once everything is working perfectly, send an email to the entire company instructing them what to do after the outage and arrange an outage and do the following steps as soon as the outage begins:
a. Unplug DMZ switch from firewall to make delivered mail wait atthe sender. [...] i. Plug DMZ switch back into firewall and begin monitoring exim logs to check that mail is being delivered.
If I'm not misunderstanding the steps between 19.a -- 19.i are going to be done while not network connected? I'd be slightly concerned that these steps may involve anything some that needs to do DNS lookups or the like at which point they may hit long(ish) timeouts or just fail completely.
pod wrote:
Richard Hobbs richard.hobbs@crl.toshiba.co.uk writes:
- Once everything is working perfectly, send an email to the entire company instructing them what to do after the outage and arrange an outage and do the following steps as soon as the outage begins:
a. Unplug DMZ switch from firewall to make delivered mail wait atthe sender. [...] i. Plug DMZ switch back into firewall and begin monitoring exim logs to check that mail is being delivered.
If I'm not misunderstanding the steps between 19.a -- 19.i are going to be done while not network connected? I'd be slightly concerned that these steps may involve anything some that needs to do DNS lookups or the like at which point they may hit long(ish) timeouts or just fail completely.
Because the mail servers are in a DMZ, they have their own DNS running locally. Local DNS lookups, therefore, shouldn't be a problem.
Good point though, so thank you for that - i ought to adjust my instructions to include installation of the DNS service! lol
Thanks again, Richard.
-- Richard Hobbs (IT Specialist) Toshiba Research Europe Ltd. - Cambridge Research Laboratory Email: richard.hobbs@crl.toshiba.co.uk Web: http://www.toshiba-europe.com/research/ Tel: +44 1223 436999 Mobile: +44 7811 803377
participants (2)
-
pod
-
Richard Hobbs