A customer approached us a few days ago with this: "I need you to host ONE MILLION MAILBOXES"
... first, just send $50k to Lagos to win the contract.
To make the story short, he certainly needs ONE MILLION boxes for a huge social project in a latinamerican Country. Project aims to give mailboxes to One Million citizens among very small cities in that country. Those small cities (aprox 170 small cities) are already finishing a project where their schools, city hall and some other places will have low and medium speed internet access.
ok
Those Million MailBoxes will be hosted in about 170 domains.
Good, you can spread the domains over many Imail boxes. 170 domains is domain-per-village? Would there be 170 Imail machines placed in each village? or a single, central machine room?
If so, we are down to the much more manageable number of average 6K users/server.
Now the question is ... Can Imail Server support this kind of Challenge?
On one Imail server?
Back of the envelope:
With an average of 1 legit msg/usr-day, that's 42k msgs/hour, 12 msgs/second. You'll need very hot hardware to handle that rate, and the peaks, and growth in traffic as these new users probably ramp up their personal daily volumes.
The you have the huge issue of keeping spam and infections out of the boxes. I have no idea how to proceed there. :)
Any ideas how? We have thought a lot about it.
you're just warming up! :)
We have many questions to be still solved yet.
One MX10 record for all 170 domains?
Every domain needs its own MX records, but all 170 MX could point to 2 or more hostnames that will be your primary and secondary MX.
You will also need 2 or more dedicated DNS boxes. I would go with BIND on *nix.
(of course.. 3 or 5 spool and forward servers will work too).
Divide 170 domains among several MX10 records and assign those MX10 records to different servers each one.. that way each server will manage 50 thousand or 60 mailboxes per server? End up having 16 or 20 servers with the solution. Let's say that domains starting with letters A to C in one Server, from letters E to G in another server and so on?
Alphabetic distribution of the domains isn't precise. Figure out how many users there are per each domain and then distribute the domains to balance the users/box so that you limit each box to something like 50K user/box, 20 boxes.
In that case use SQL2000 (one SQL server or a cluster solution just in case), a SQL Server for each Imail server? or just use Internal Imail Data Base per server?
Imail registry would be sufficient, but then what about your apps to manage the user base? Which is where the utility of an external db is welcome.
Can I work with a peering solution for 170 domains.. or peering is just for one domain?...
Forget peering, it sucks in general, and is anyway for spreading one domain over several boxes. It is useless in your case.
Can one Box host One Million Mail boxes?
If you have ask the question seriously (that is, you really don't have the experience and knowledge about scaling mail systems to answer that question yourself), then don't even think about one box. Run multiple boxes.
Imail internal Data Base can handle
them?
yes
Should we go with SQL2000?
Only if you are going to run apps to manage the user base. If not, stick with imail registry db. SQL is whole set of skills and headaches, plus $5k license or whatever per CPU, that you don't want to take on if you don't need it. But whether you or don't need an external database is a key decision.
If you go with SQL, I bet you could get all the SQL you need out of PostgreSQL, saving you a bunch of money. Ask here is somebody has interfaced Imail to Postsgres or check the list archives. db admin for a million-user database is significant responsiblity.
What is the maximum users One box can handle? 60 thousand? 100 thousand?
That's do-able. It's not only the disks but the memory and CPU of support x,000 simultaneous webmail users per server.
If the WAN links from the 170 villages to a central mail service are slow, then the loading up the huge webmail pages and the http traffic paging through huge mailboxes will be painfully slow, perhaps fatally.
So setting and enforcing a limit on the mailbox size is extremely important to performance, and then max msg size must fit into the mailbox limit.
You will be in mail archive business, meaning the users will be expecting you to keep their mail on-line for a long time since it will be their only mail storage. You'll need disk mirroring for on-line reliability, and tape backup for long-term reliability.
What type of DB are they using?
There are a lot of questions we don't have the answers to like "how many messages per day the solution will be handling?
The volume of msgs is the starting point. You just have to make some assumptions and run with it. Your scaleablity to 1 million or 10 million msgs/day will come from having distributed the users more or less equally among a larger number of mailbox servers in parallel, rather than a few number of more stressed servers.
what type of mail users will typically receive, etc..
Probably like anybody else.
With no personal PCs, they probably won't be sending big attachments, but they could of course receive big attachments and then want to keep them long term in their mailboxes. So two key parameters are 1) max mailbox size and 2) max msg size. This influences disk size, number of disks, partitioning, and overall webmail performance.
so there wouldn't be enough information to have the best solution. However we wanted to post this to the list to see if someone have ideas on how to handle this or have a nice initial approach...
If you are going jump start all 1M users at same time, then define a single box as the template server, and buy 20 or 25 identical boxes in one go. This will simplify the logistics and training and hardware maintenance.
You also have to address:
DNS and domain names.
anti-virus
anti-spam
Len
To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
