On Mon, 12 Aug 2002, Philip Hazel wrote:
> But if you have 3 front-end servers sharing a spool, you have ONE point
> of failure, and also ONE botttleneck. If you are interested in
> scalability (which I think you said originally) you should be aware that
> when you keep piling load onto Exim, what runs out first is disc I/O
> capacity. Sharing the spool between servers would make this worse, not
> better, because they'd all be contending for same disc, and would hold
> each other up. For performance reasons, you definitely want to give each
> server its own spool.
Has anyone done a performance analysis of queue-handling on different
filesystems; e.g. Ext2 vs. Sun UFS vs. ReiserFS vs. XFS?
ReiserFS is supposed to be optimized for handling many small files. XFS
is better at handling many (tens of thousands) of files in a directory.
Do any MTA's out there take a custom-filesystem approach, like some of the
UseNet/NNTP servers do?
The reason I wanted a central file store is that high-redundancy file
stores are relatively expensive to build, operate, maintain, etc. Also, if
the only thing that server is doing is serving files with NFS, they are
also very reliable.
> > And most importantly, if one of the front-ends goes down then any mail in
> > its spool will not get processed until that server is restored to
> > operation.
>
> Not if you have some means of attaching its disc to a different host.
> But make sure you use localhost_number if you plan to do this.
Physical changes to effect failover is always something I try to avoid
from an engineering perspective - moving cables around (especially on a
SCSI bus) can be prone to errors - especially at 4am which is when Murphy
dictates that computers go down ;)
The SAN approach that someone mentioned seems reasonable, though. You get
a central file store without sharing the same filesystem, there are no NFS
locking issues, etc. I will have to look into this more. Also, in a
failover situation, you could presumably do a software operation to mount
the failed spool on a different CPU.
Another option I guess would be hot-swap drives: in a system have three
hot-swap drives, the first for system, the second and third for spool
(mirrored). If the hardware fails you can just move the spool disks to a
backup server and boot.
In either of these setups you'd still have a nice fat traditional RAID
file server for user mailboxes (maildirs), and the spool front-ends could
then deliver directly to that filesystem over NFS.
> Admin over multiple hosts can be done with scripts. The system I'm
> sending this from has 3 hosts. I have some hacked up scripts that do
> (for example) log scans over all of them. The config is maintained with
> rdist. Etc., etc. (Some sysadmins use syslog for logging from multiple
> hosts.)
I wrote something similar to syslog (but super-lightweight, no security as
it's running on a private network) to provide combined logs from an Apache
cluster. Doing a merge-sort on the logfiles the size I expect to get would
be pretty expensive. The syslog approach also gives you a single combined
log in real-time.
--
Jawaid Bazyar | Affordable WWW & Internet Solutions
foreThought.net | for Small Business
jawaid.bazyar@??? | 910 16th Street, #1220 (303) 228-0070
--The Future is Now!-- | Denver, CO 80202 (303) 228-0077 fax
