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
reason for using this type of cluster are:
- To get
- So you
can add servers as needed
- To create
a fault redundant reliable system
these reasons are invalid or better done using surgemail's mirroring,
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.
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!
- 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)
- the shared drive approach adds significantly to your systems complexity,
as a result failures are very likely to be more common.
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.
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.
- If you are
using a smart router or load balancing tool, read
- 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
- 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)
"/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)
"/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.