This thread has raised some questions about NFS that I'd like to talk
about since I'm looking at potentially using qmail with NFS to create
an e-mail cluster. I'm looking at qmail because its maildir message
store appears to be NFS safe. We're currently using Innosoft's SMTP
and POP servers along with the Cyrus IMAP server on two independent
machines. At one time, we had 6 independent servers, but we've
consolidated into 2 to save $$$. It seemed too many costs were
multiplied by the number of servers. And load balancing across so
many independent servers was difficult for users. But now we've got
too many eggs in too few baskets. We lost one of these servers for
the better part of a day a few months back when a RAID 5 system
failed and caught quite a bit of grief. A RAID controller failed and
when the system attempted to roll over to the redundant controller,
it hung and was corrupted. It took about 6 hours to get the system
back online.
I'm sure NFS has earned its reputation for unreliability, but I think
there are a new generation of dedicated NFS appliances that deserve a
second look. We've been using NetApp filers with our web and database
servers and I've been pleased with the reliability and performance. I
don't mean for this to be a pitch for NetApp. NetApp has several able
competitors. NetApp is just the one we've chosen and where we have
some experience.
We use the NetApp filers as backend servers on a private gigabit LAN
so security is manageable.
The NetApp class of machine is designed for simplicity and
reliability. Multiple hot-swappable power supplies and fans,
hot-swappable disks, and you can buy a spares kit with the things
that are most likely to fail, including the mother board. So if you
have a hardware failure that brings the system down, you should be
able to get back up quickly. You can "cluster" two NetApp's in a
fully redundant system, but that was a little beyond our budget. We
are looking at using their mirroring software to create a mirror of
the e-mail volumes on the web filer. That way, if the e-mail filer
failed and we couldn't get it back up quickly, we could mount the
mirror volume from the web filer.
My goal is to create a cluster that supports SMTP, POP, and IMAP. If
one of the servers fails, existing connections might be broken, but
the system should appear to heal itself quickly and, when users try
again, it should appear fully functional. We'll do the load balancing
with MX and Foundry Network's ServerIron layer 4 switches. Foundry
also has a number of able competitors.
To me, I want both the MTA (SMTP) and mailbox servers (POP/IMAP) to
be clustered. I don't see a need to separate the MTA from the mailbox
servers since they seem so interdependent. Actually, I worry a bit
less about the MTA since SMTP is inherently store and forward and MX
provides an easy way to load balance across multiple MTA's. I worry
more about the mailbox servers. If it takes a little while longer for
some messages to be delivered because of an MTA failure, users may
not notice. If a mailbox server fails, users will know immediately.
If that mailbox server is down for very long, users will be looking
for scalps.
So the scenario I'm looking at would look something like:
( public network )
|
+------------+
| firewall +
+------------+
|
+------------+
| switch(es) |
+------------+
| |
+------------+ +------------+
| server 1 + | server 2 + (more servers, if needed)
+------------+ +------------+
| |
+------------+
| switch(es) |
+------------+
|
+------------+
| filer(s) |
+------------+
Another thing I like about these filers is the ability to manage
_storage_ separate from _servers_. Before, each server had its own
storage subsystem that had to be managed separately. If one server
was running low on space, it wasn't easy to move space from one
server to another. With a filer, we can add disks as needed, on the
fly in most cases, and the space is immediately available to all of
the servers. It also makes backup easier.
Not being familiar with qmail, the biggest question for me is if I'll
be able to do all the things I'm doing now. For example, our current
POP/IMAP servers don't allow plaintext login, but provide a number of
options such as SSL, APOP, and CRAM-MD5. We also do SMTP AUTH with
SSL and CRAM-MD5 authentication. And our SMTP server allows relaying
if you authenticate. And we can automatically post messages to any
IMAP mailbox. One thing we don't have at this point is a single,
unified account database and message store for POP and IMAP. Cyrus
could do this as will the next version of the Innosoft product, but
neither will support NFS.
--
James N. (Jamey) Maze
Oak Ridge National Laboratory
Computing, Information and Networking Division
http://www.ornl.gov/cind