|
|
|
|
|
|
|
| |
|
|||||
| |
|
|
|
|
|
|
| |
||||||
Performance and Scalability
SurgeMail has been designed from scratch with performance in mind. This means you can almost literally host "an unlimited number of users and virtual domains on a single system". However we also had in mind ridiculously large systems, with 1-100 million users, in these situations there are two methods you can use.
- Proxy Servers (huge systems)
- NFS / Shared Networked drives (huge systems)
- Simple splitting up of function (medium sized systems)
Proxy Servers (huge systems)
This systems allows both infinite scaling, and 3 layer security. The incoming POP/SMTP connections arrive at one of several front end 'proxy' servers (running SurgeMail in proxy mode) these servers then lookup the user in the networked user database (via LDAP or our own TCPAuth module) and along with the normal response an extra response code of 'tohost=backend.host.name' is returned, the proxy then redirects the user to the appropriate back end system.
So you might run 4 back end systems, each with 100,000 users, and 2 front end systems. To add more users you just add as many front end and back end servers as needed to cope with the load.
Each user is only on one of the back end systems, the only piece in the system that has to handle all the users is the user database, which is a relatively trivial task as the quantity of data per entry is so small. We recommend the use of NWAuth or LDAPAuth but any of the database back end authent modules would be suitable.
See here for technical details
Note: 3 Layer Security: This model is called '3 layer security' as the front and back end systems can be separated by another fire wall. And in the case of 'WebMail' the user web interface can also be separated from the front end systems by a fire wall, hence '3 layer' :-)
To implement this system set on the proxy system the setting g_proxy true, and in the authent module add the 'tohost=xxx' field. For existing user accounts you can define g_proxy_default host.name so that user records with no 'tohost' entry are correctly sent to the existing back end system. In this way a non proxy based system can be instantly turned into a proxy based system.
NFS / Shared Drives, Clustering Support
In this mode you simply define your main drop path for a domain as a networked drive, and setup multiple systems using that same drop path. As SurgeMail uses a 'maildir' directory format there are almost no locking issues even with bad NFS implementations (and most NFS implementations are a little dodgy :-).
NFS / Shared Drives - FAQ/Howto
Set in surgemail.ini g_pop_lock true, so that pop logins will not occur on multiple systems for the same user as that could cause some issues.
Only share the mailbox_path between the systems, don't share the workarea or home etc.
If you symlink the surgemail.ini it will work but if you change settings from two different systems at the same time it could be corrupted or lost, so it's probably better to pick a master for making admin changes, and run a cron job on the slaves that will issue a tellmail reload command if the file is changed.
