Configuring Scalable Servers

---

qmail is compact and efficient, and a large, well-equipped server system can send and receive prodigious quantities of mail and serve it via Post Office Protocol (POP3) or Internet Mail Access Protocol (IMAP) to its owners. But what if you need to set up a really large mail system, capable of handling millions of mailboxes or tens of millions of messages per day?

The best approach to setting up a huge system isn't simply to set up one hugely powerful system. Such a system would be expensive, but, more importantly, it would represent a serious liability. If the huge server broke, the entire system would be unusable.

A much better approach is to distribute the load among a set of smaller "commodity" systems. qmail's modular architecture and maildir mailbox format, combined with load-balancing hardware or software, enable relatively easy construction of scalable mail systems. If one of the subsystems breaks, only a subset of users or functions is disrupted. And if additional capacity is required, additional systems can be easily added later.

The four main functions of a mail server are sending mail, receiving mail, delivering mail to local mailboxes, and serving mailboxes to users. You'll examine each of these functions and consider ways to distribute their load across multiple systems. However, setting up a high-performance, high-availability, and scalable mail system is a complex task. You can hire consultants who have experience doing this, and it might make more sense to employ their services than to develop this expertise in-house. (See http://www.qmail.org/top.html#paidsup for a list of commercial support providers.)

Outgoing Mail

There are basically two scenarios involving the large-scale sending of mail: a single message distributed to a large mailing list and individually customized messages distributed to a large list of recipients.

Although both may result in about the same number of deliveries, they present dramatically different loads to the sending mail system. Take the example of a single message sent to a list of 10,000 recipients versus a customized message of the same length sent to the same 10,000 recipients. The message is 2,000 bytes, and the average recipient's address contains fifteen characters.

The first case requires generating and queuing one message, resulting in a handful of queue files, and occupying disk space proportional to the size of the message plus the size of the mailing list. In this case, that's 2,000 bytes for the message plus 150,000 bytes for the mailing list (10,000 x 15), a total of 152,000 bytes.

The second case requires generating and queuing 10,000 messages, resulting in a few tens of thousands of queue files, and occupying disk space proportional to 10,000 times the size of the message and the recipient. That's 10,000 x 2015, a total of 20,150,000 bytes!

Obviously, you should be careful to avoid the message-per-recipient scenario whenever possible.

Either way, though, the scalable solution is to divide the workload among a set of N outgoing servers. With the first scenario, this is easily accomplished by dividing the list into N "sublists," one of which resides on each of the servers. With the second scenario, the list of recipients is again broken into N sublists, but the process that generates the messages must also be broken into N subprocesses (see Figure 12-4).

Figure 12-4: Distributing outgoing load

Incoming Mail

If you need to handle high volumes of incoming mail—whether for final delivery to user mailboxes or for routing to other systems—the Domain Name System (DNS) mail exchanger (MX) mechanism nicely facilitates load distribution. If you have N SMTP server systems, you simply create an MX record in the DNS for each, all at the same priority. Sending MTAs automatically pick one MX randomly from a set of MX records at the same priority.

If MX load distribution is inadequate—maybe you want more flexibility than DNS allows, or you need more servers than DNS can easily accommodate—hardware load-balancers are available that will split traffic to a single Internet Protocol (IP) address across multiple systems.

Once the incoming SMTP traffic is split, all you need to do is configure each server to forward or deliver the messages as desired. Disposition information could be stored in a remotely accessible database and retrieved using a Lightweight Directory Access Protocol (LDAP) or Structured Query Language (SQL) lookup tool or add-on. (LDAP and SQL are covered later in this chapter.)

Figure 12-5 shows an MX-distributed incoming service.

Figure 12-5: Distributing incoming load with MX records

Figure 12-6 shows a transparently distributed incoming SMTP service using a load-balancer or round-robin DNS.

Figure 12-6: A transparently distributed SMTP service

Mailbox Delivery

So you've got a couple million users and you want to distribute delivery to their mailboxes. qmail's maildir format allows multiple delivery agents to update a single mailbox simultaneously—safely and without the need for complex locking mechanisms, even over Network File System (NFS).

A single, high-performance network-attached storage (NAS) device with built-in redundancy and battery-backed write cache can serve a large number of mailboxes to an array of servers. If you need more than one mailbox server, simply distribute the mailboxes across the set of mailbox servers, perhaps using LDAP or some other database to contain the mapping between mailbox name and mailbox server. Figure 12-7 shows a distributed mailbox configuration.

Figure 12-7: Distributing mail delivery

Mailbox Service

Now you've got thousands or millions of mailboxes stored on one or more mailbox servers, and you need to provide access to those mailboxes via POP3 or IMAP. You can set up multiple POP3/IMAP servers behind a hardware load-balancer or round-robin DNS server so all users access the same POP3/IMAP server name, but the load is transparently distributed across the server pool. Figure 12-8 shows a distributed mailbox service.

Figure 12-8: Distributed POP3/IMAP service

---