Matthias F. Brandstetter wrote:
Hi all,

I have to plan and setup a mail solution for about 50.000 users, here are some key features requested by our customer:

 - self coded webfrontend w/ webmail and administration (filter, alias etc)
 - 100MB quota per user
 - autoresponder
 - about 50.000 user
 - online backup of data
 - some more featuers for web frontend

Since I happily use qmail for some other (but smaller) installations, I want to try it with qmail here for this project as well. My only problem is, I have no clue where to start ... beginning from "should I use 2 redundant and really strong or some more but cheaper servers?" to "which qmail distributions and patches should I use (ldap, mysql, ...)?" and "how to store data (mails) and do online backup w/o downtime?".

I know you can't give me _the_ solution for this issue, but I am thankful for any hints and internet links on this topic.


I'd go with three or more servers if possible. That way doing maintenance is easy and losing a server due to failure is annoying, not an emergency. I like my sleep.
Mail tends to be I/O intensive, again depending on a number of factors, so having more cheaper machines is an easy way to get more I/O. On the other hand, spam filter can be CPU intensive and use a ton of RAM. Unfortunately my exp has been at the wrong ends of the scale. Previous job was 5 million active mail boxes and the current gig is barely pushing 1000. The large system had numerous cluster that supported mail. The pop cluster, smtp-relay, smtp-inbound, spam/content filtering, imap, http-frontend so it was easy to fix miscalculation in usage by throwing more hardware at the problem.


If you support webmail you need an imap backend. The squirrel mail site has a lot of good info about picking your imap backend and lots of general performance data. I'd lean towards Courier-imap as it's probably the fasted IMAP server that doesn't use it's own data format.
I'd look around and see what you can modify to your own use rather than create from scratch. Squirrel mail, horde, postfixadmin, etc are all packages that do some of what you want. Unless you've got a lot of time and people to develop and know that you're never going to allow your packages to face the public Internet then it might be doable.


In an environment your size I assume you're looking at shared storage via NFS or something similar. A number of places have had good luck with Netapp, but it's pricey. You might want to look at some of the cheap Dell stuff which is rebranded EMC.
Maildir format is probably best for using shared storage, but things can get interesting have a few million files on your filesystem. With 50k users you shouldn't see any of the stranger issues, but you may want to keep an eye on inode usage. Reiserfs may be your best bet here.


I use Mysql on my current system with Postfix. I assume qmail can play nicely with Mysql as well. I am running into some Mysql connection problems because each Postfix process has it's own Mysql connection. IIRC you can configure Mysql:proxy in Postfix and Courier to multiplex queries over a single connection... something I'm planning on doing later this month.

I used the qmail-1.03-r10 ebuild in production last time, but cut a number of patches out since it was only for sending client emails to customers. You'll probably want r15 since you're going to have users directly connecting. Don't be afraid to cut patches you don't need, but you'll definitely want to keep these big-todo and big-concurrency for performance. qmail-link-sync support async filesystems, aka anything journaled. The rest should be pretty self explanatory.

That's off the top of my head... hopefully it highlighted some issues that you might have missed.

kashani
--
[email protected] mailing list



Reply via email to