[Dovecot] Hardware infrastructure for email system

[Michael Wessel]

Hi p at rick and thanks for the response.

On 6/23/2012 3:25 AM, Patrick Ben Koetter wrote:
> Michael,
>
> * Michael Wessel <michael at think-for-yourself.org>:
>> I'm currently (re-)planning my email setup and have been doing some
>> research. I have done some searches and read several threads in the
>> areas of my questions here. While there are some that come close I
>> haven't yet been able to get all my questions answered.
>>
>> I currently run a postfix, dovecot & roundcube setup and have about
>> 2000 active accounts. I have a separate SMTP server for outbound
>> mail and auth is done against a separate LDAP server. In front of
>> the POP/IMAP server I have another SMTP (4 in parallel actually)
>> server that receives and filters inbound mail through a company
>> specific, proprietary filter before the mail hits the POP/IMAP
>> server. LDAP & SMTP servers are ESXi VMs.
> Do people use 'real' mail clients to connect and IDLE too?
Yes, though not sure of the percentage. Most will likely use webmail, 
some will use POP and some will use IMAP with "real clients". Right now 
my guess would be about 20% IMAP with Outlook, Thunderbird and such, 10% 
POP and the rest webmail.
>
>
>> So right now both dovecot and roundcube run on the same box which is
>> a Dell PE2950 with dual quad-core Xeon, 16GB RAM and 6 1TB disks in
>> RAID 6, so only local storage using maildir.  So far it's been
>> holding up fine, but it's beginning to show signs of overload now. I
>> also expect an increase in users over the next few months up to
>> somewhere between 10 - 20,000 mail boxes. Hence the re-planning.
>>
>> My first priority in redesigning my setup is reliability. I
>> definitely need something fail-save and as close to always on as
>> possible. Next is performance. And while the budget is of course
>> limited for the moment I'm setting that aside and will worry about
>> that when the time comes.
>>
>> Now here is my question(s):
>>
>> In order to support up to 20,000 mailboxes (distributed over several
>> times-zones so they won't all be used at the same time) with a very
>> reliable service with good performance, what do I actually need?
>>
>> Do I need(ul) SAN or is it just a "would be nice to have"? If yes,
>> why and what would be appropriate for my needs? Or will a setup with
>> a few more servers like the ones I already have, using something
>> like DRBD and distributing services (imap, http, spamd etc) onto
>> different boxes do?
> Will the server enforce quota?
Yes, default quota is 200MB right now, some have larger quotas and a few 
of those hit several GB.
>
> What will be the average mailbox size?
Since the quota is probably going to go up some I'd guess around 400MB 
on average.
>
> Do people share content e.g. mailings with attachments that go out to all
> recipients?
No, only on a limited basis (like cc'ing maybe 15 or so people but even 
that's rare) There will be somewhat large attachments involved (20-30MB) 
but that's mostly between individual users and users outside my system.
>
> What might be the maximum number of clients using the server at one time?
Hard to say with the data at hand. I have a caching IMAP proxy for 
webmail and that has so far recorded 50 as the highest concurrent 
connections. So adding IMAP users to that and then extrapolating this to 
20000 total boxes I'd say 4-500.
>
> Will all users use the same client product e.g. roundcube?
No, they have their choice of any POP3/IMAP client or webmail
>
> What's your backup strategy? What do you use to backup mailboxes?
I was afraid someone was going to ask that question... there isn't one 
(it hurts just writing that!) The only "backup" currently in place is 
redundancy on the hardware-side plus limited (i.e. only parts of the 
mail store) to disk backup. The VMs are easily replaced, but if my 
maildir goes up in smoke tomorrow then I will probably follow shortly 
after! So that's definitely part of what I'm working out here. Wanted to 
nail down the general approach first though before looking at that.
>
> p at rick
>