Configuring 'Shared Storage Clusters'

Surgemail can be configured in a more traditional shared storage cluster configuration using an NFS (or other) shared storage device for providing standard mail services.

In this configuration you have several servers all running surgemail handling all mail services storing users mail using the same central storage. The incoming connection load is shared between all servers using an appropriate technique. This is typically a hardware based load balancing router.

STOP! we think this is the wrong solution for you - here's why
The normal reason for using this type of cluster are: To get load sharing So you can add servers as needed To create a fault redundant reliable system All of these reasons are invalid or better done using surgemail's mirroring, here's why: Load sharing & Adding servers - this assumes the limiting factor is the cpu, due to the speed of modern multi processor systems, this is not the limiting factor, the disk IO is probably going to be the limiting factor, so you gain nothing with the extra boxes. This is because only improving the 'bottle neck' increases throughput. Redundant failover etc - since only a single copy of the data exists on the shared network drive, the system is not particularly redundant. Your network drive may be raid or something else fancy, but it's still a single point of failure - and network fancy drives are significantly more prone to failure than simple internal disk arrays, this is just a feature of complexity, always avoid complexity! Performance - network drives tend to be significantly slower, this is because small requests that would be cached on a local drive, cannot be cached and must go over the network link. Even if the network link can cope with the level of requests (and the limit is packets per second, not bytes per second so a faster network may not help) Complexity/reliability - the shared drive approach adds significantly to your systems complexity, as a result failures are very likely to be more common. Some features of SurgeMail will not fully work in this environment. (SurgePlus for example can only be used on a single cluster member) Core functionality should work fine though. In summary, although SurgeMail supports this layout, we have almost never seen a system where it was the 'right' solution to use, careful use of mirroring and split functionality will almost certainly give you a more reliable, faster, simpler system for less cost. But there are exceptions, so if you are sure, proceed :-)

STOP! we think this is the wrong solution for you - here's why

The normal reason for using this type of cluster are:

To get load sharing
So you can add servers as needed
To create a fault redundant reliable system

All of these reasons are invalid or better done using surgemail's mirroring, here's why:

Load sharing & Adding servers - this assumes the limiting factor is the cpu, due to the speed of modern multi processor systems, this is not the limiting factor, the disk IO is probably going to be the limiting factor, so you gain nothing with the extra boxes. This is because only improving the 'bottle neck' increases throughput.
Redundant failover etc - since only a single copy of the data exists on the shared network drive, the system is not particularly redundant. Your network drive may be raid or something else fancy, but it's still a single point of failure - and network fancy drives are significantly more prone to failure than simple internal disk arrays, this is just a feature of complexity, always avoid complexity!
Performance - network drives tend to be significantly slower, this is because small requests that would be cached on a local drive, cannot be cached and must go over the network link. Even if the network link can cope with the level of requests (and the limit is packets per second, not bytes per second so a faster network may not help)
Complexity/reliability - the shared drive approach adds significantly to your systems complexity, as a result failures are very likely to be more common.
Some features of SurgeMail will not fully work in this environment. (SurgePlus for example can only be used on a single cluster member) Core functionality should work fine though.
In summary, although SurgeMail supports this layout, we have almost never seen a system where it was the 'right' solution to use, careful use of mirroring and split functionality will almost certainly give you a more reliable, faster, simpler system for less cost.
But there are exceptions, so if you are sure, proceed :-)

How to configure surgemail to use a shared NFS (or network) drive:

You should only share the 'mailbox_path' for each domain, do not share the workarea or other directories within surgemail.
g_share_quota "true"
g_share_mail "true"
g_pop_lock "true"
If you are using a smart router or load balancing tool, read this page
Do not use of the automatic account expiry and deletion functions such as g_delete_user_after / g_delete_user_mode / g_delete_user_suspend functions.
To allow webmail to be run on more than one host see this page.
In the surgemail home directory sym link the directory 'resp' to a shared area (this allows the auto responder to work correctly and each cluster member will remember who has been replied to)
g_autologin_file "/shared/autologin.dat" - Where that file is shared between all servers via nfs
In addition you probably should share the directory (suregmail home)/resp (We will provide mechanism to do this on windows shortly)
g_domuser_file "/shared_folder/domuser.dat" - define the alias file in a shared area so user aliases work

Warnings - Things to avoid doing in this configuration:

You cannot use surgemail 'mirroring' feature in addition to sharing the mail spool.
Do not use the migration mechanism on multiple shared hosts at the same time, as then it will be in danger of converting one user twice at the same time.


Search website:

Help Index

Configuring 'Shared Storage Clusters'

How to configure surgemail to use a shared NFS (or network) drive:

Warnings - Things to avoid doing in this configuration: