在 2006 年初，马歇尔大学制定了一项计划，以迁移 HOBBIT（图 1），这是一个处理全校电子邮件服务的 HP OpenVMS 集群。由于垃圾邮件攻击日益增多，该集群经历了严重的性能下降。虽然我们员工的电子邮件存储库在最近几年已迁移到 Microsoft Exchange，但电子邮件路由、邮件列表和学生电子邮件存储库（包括 IMAP 和 POP3 服务）仍然由 OpenVMS 提供服务，用户约有 30,000 名活跃用户。HOBBIT 的电子邮件软件 PMDF 提供的功能集相当有限，同时收取高昂的许可费。在其外部磁盘存储系统上发现了一个主要的瓶颈：过时的存储技术导致有限的磁盘 I/O 吞吐量（最大 40MB/秒），而电子邮件系统正在进行密集的 I/O 操作。

图 1. HOBBIT OpenVMS 集群硬件

为了解决现有的电子邮件性能问题，我们进行了头脑风暴会议、需求分析、产品比较和测试实验室原型设计。然后，我们提出了新电子邮件系统的设计方案：它被命名为 MUMAIL（图 2），并使用安装在 Red Hat Enterprise Linux 上的标准开源软件（Postfix、Cyrus-IMAP 和 MySQL）。核心系统由前端电子邮件中心和后端电子邮件存储库组成。前端电子邮件中心使用两台运行 Linux 上 Postfix 的戴尔刀片服务器。网络负载均衡配置为在它们之间分配负载。后端电子邮件存储库由另外两台刀片服务器组成，它们运行 Cyrus-IMAP 聚合设置。然后，每个后端节点都连接到 EMC 存储区域网络 (SAN) 上的不同存储组。第五台刀片服务器被指定为主节点，用于存储集中的用户电子邮件设置。此外，我们使用 LDAP 和 Kerberos 将电子邮件用户身份与 Windows Active Directory (AD) 集成。

图 2. Linux 电子邮件服务器刀片和 SAN

图 3 说明了我们新的电子邮件系统架构以及与现有服务的子系统交互，这些服务包括 Webmail、AD 和 SMTP 网关。红色突出显示的框图是要详细研究的组件。

图 3. 系统架构

在我们进一步深入了解我们新的电子邮件系统之前，我想提及高等教育环境中一些现有的 Linux/UNIX 电子邮件解决方案。首先，Linux Journal 文章（请参阅资源）中讨论的 HEC 蒙特利尔电子邮件系统影响了我们的设计，该设计基于 Cyrus-IMAP 和 Postfix。其次，我们研究了剑桥大学的解决方案。它使用自定义 IMAP 代理前端服务器和多对 Cyrus-IMAP 邮件存储服务器，这些服务器相互复制数据。此外，最初开发 Cyrus-IMAP 的卡内基梅隆大学 (CMU) 使用 Sendmail 作为前端邮件交换器，并在后端使用 Cyrus-IMAP Murder Aggregator 设置。哥伦比亚大学于 2006 年将其电子邮件系统迁移到基于 Cyrus-IMAP 的解决方案，印第安纳大学早在 2005 年就迁移到了 Cyrus。斯坦福大学也使用了 Cyrus 和 Postfix。

尽管这些相关解决方案的设计有所不同，但它们中的大多数都使用基于集群的方法，将邮件传输/传递与邮件存储库分开。设置了多个前端 MTA-MDA（邮件传输代理和邮件传递代理）服务器，以将邮件传递到后端邮件存储库，然后后端邮件存储库将消息保存在文件系统（例如，Maildir）或数据库中。大多数解决方案都使用 Cyrus-IMAP（在 UNIX 或 Linux 上）作为其邮件存储服务器。

一些独特的差异使我们的设计与现有解决方案区分开来

我们设计了一个电子邮件用户数据库（在主节点上运行 MySQL），用作集中式数据存储库，用于存储包括电子邮件帐户、用户电子邮件路由、组别名和邮件列表在内的信息。使用 PHP 开发了基于 Web 的用户界面，允许用户更改数据库中的设置。在前端节点上运行的自动化脚本将查询数据库以获取用户设置，并构建 Postfix 映射以应用这些设置。

Postfix 服务器可以被认为是路由器（不是用于 IP 数据包，而是用于电子邮件）。对于每封电子邮件，Postfix 都会查看目标（信封收件人）和来源（信封发件人），然后选择如何将电子邮件路由到更靠近其目标的位置。称为映射（例如传输、虚拟、规范和别名映射）的查找表用于查找下一跳电子邮件传递位置或应用电子邮件地址重写。

每个前端电子邮件中心节点上都运行着一个后台作业，以“拉取”存储在电子邮件用户数据库中的电子邮件设置（传递位置、电子邮件别名和组别名信息）到 Postfix 映射（别名、虚拟、规范和传输）。该程序用 Perl 编写，配置为定期作为 crond 作业运行。

我们新电子邮件系统的设计原则是从单个、单片架构扩展到多个节点共享相同的处理负载。在大型电子邮件环境中，扩展前端 MTA 系统比扩展后端邮件存储库容易得多。由于前端节点本质上是无数据的，因此在多个前端服务器上使用 DNS 或基于 IP 的负载均衡是一种典型的做法。但是，相同的技术不能应用于设计用户数据所在的后端邮件存储库。如果没有集群、共享存储或额外的软件组件（例如代理服务器），多个邮件存储服务器无法在统一的服务命名空间下共享相同的 IMAP/POP3 处理负载。因此，使用单个邮件存储服务器往往是一个显而易见的解决方案。但是，当需要购买更强大的服务器硬件来适应不断增加的系统负载时，单个节点通常意味着更高的服务器硬件费用。配备四个 CPU 的中端服务器的价格通常远高于三台或更多入门级服务器的总价。此外，单节点架构降低了系统可扩展性并创建了单点故障。

Cyrus-IMAP 软件包被证明是强大且适用于大型设置的。它与其他 Maildir 或 mbox IMAP 服务器的不同之处在于，它旨在作为“封闭”邮箱服务器运行——Cyrus 邮箱数据库存储在文件系统的某些部分中，这些部分对 Cyrus-IMAP 系统是私有的。更重要的是，支持使用 Cyrus Murder 聚合的多服务器设置。它通过使用多个前端 IMAP 代理将 IMAP/POP3 流量定向到多个后端邮件存储节点来扩展系统的负载。尽管我们发现了其他扩展 Cyrus-IMAP 的方法——例如，本文“相关解决方案”部分中提到的剑桥大学的成对复制方法，或使用集群文件系统在多个服务器之间共享 IMAP 存储分区，并使用 Red Hat 的 Global File System (GFS) 等产品——但与聚合方法相比，这些解决方案要么太定制化而无法支持（剑桥方法），要么涉及额外成本（GFS 由 Red Hat, Inc. 单独销售）。

因此，采用了 Cyrus-IMAP 聚合方法。图 4 说明了设置：设置了两个 Cyrus 后端服务器，每个服务器处理一半的用户 population。指定了两个 Postfix MTA 前端节点来提供代理功能。当电子邮件客户端通过 SMTP/IMAP/POP3 连接到前端服务器时，Cyrus Proxy 服务将使用 MUPDATE 协议与 Cyrus Master 节点通信，以便它获取有关哪个 Cyrus 后端节点存储当前客户端电子邮件的信息。此外，后端 Cyrus 节点将通知 Master 节点有关邮箱更改（创建、删除和重命名邮箱或 IMAP 文件夹）的信息，以便使 Master 节点保持最新的邮箱位置信息。Master 节点将这些更改复制到前端代理节点，这些节点会定向传入的 IMAP/POP3/LMTP 流量。MUPDATE 协议用于传输邮箱位置更改。

图 4. Cyrus-IMAP 聚合设置

虽然它不是完全冗余的解决方案（Master 节点仍然是单点故障），并且如果任何一个后端节点发生故障，我们一半的用户将遭受使用中断，但聚合器设置将 IMAP 处理负载分配到多台服务器上，每台服务器承担 50% 的负载。由于这种劳动分工，新的邮件存储系统现在可以扩展到多台服务器，并且能够处理不断增长的用户 population 和不断增加的磁盘使用量。更多的后端 Cyrus 节点可以加入聚合器以扩展系统。

我们新电子邮件系统的要求之一是将用户身份与大学目录服务集成。由于 Microsoft Active Directory 服务已成为我们集中式校园 IT 环境中的标准，因此 Cyrus (IMAP/POP3) 和 Postfix (SMTP) 被设计为从 AD 获取用户身份验证/授权。集成后，所有电子邮件用户凭据都可以从 AD 进行管理。大多数目录服务都是基于 LDAP 构建的。AD 使用 LDAP 进行授权，并且它有自己的 Kerberos 实现进行身份验证。集成 AD 身份验证的目标是允许 Linux 电子邮件服务器使用 AD 来验证用户凭据。用于支持 AD 集成方案的技术主要基于 Kerberos 和 LDAP 支持，这些支持随附本机 Linux 组件，如图 5 所示。

图 5. Linux 针对 AD 的身份验证和授权

以下是它的工作原理。首先，我们使用 AD Kerberos 对 Linux 客户端进行身份验证。Pluggable Authentication Module (PAM) 配置为获取用户凭据并将其传递给 pam_krb5 库，然后使用 pam_krb5 库使用 Linux Kerberos 客户端连接到 Active Directory 上的密钥分发中心 (KDC) 来验证用户身份。这种做法消除了在 Linux 端进行身份验证管理的需要。但是，仅使用 Kerberos 集成，Linux 必须将授权数据存储在本地 /etc/passwd 文件中。为了避免管理单独的用户授权列表，LDAP 用于从 AD 检索用户授权信息。其思想是首先让名称服务交换机 (NSS) 处理授权请求。NSS 允许使用集中式数据库或多个数据库替换许多 UNIX/Linux 配置文件（例如 /etc/passwd、/etc/group 和 /etc/hosts），并且用于访问这些数据库的机制是可配置的。然后，NSS 使用名称服务缓存守护程序 (NSCD) 来提高查询性能。（NSCD 是一个守护程序，为最常见的名称服务请求提供缓存。）当针对大型 AD 用户容器使用时，这可能非常重要。最后，NSS_LDAP 配置为充当 LDAP 客户端以连接到 Active Directory，从而从 AD 用户容器中检索授权数据。（NSS_LDAP 由 PADL 开发，是一组 C 库扩展，允许将 LDAP 目录服务器用作别名、以太网、组、主机、网络、协议、用户、RPC、服务和影子密码的主要来源。）现在，通过使用 LDAP 和 Kerberos 完全集成到 AD 中的授权和身份验证，无需维护本地用户凭据。

为了支持与 Linux 的 LDAP 授权集成，在每个 AD 域控制器上都安装了 Windows Server 2003 Release 2 (R2)，其中包括对 RFC 2307 的支持。R2 引入了新的 LDAP 属性，用于存储 UNIX 或 Linux 用户和组信息。如果没有像 R2 使用的那样的扩展 AD LDAP 架构，则无法实现 Linux 与 AD 的自动授权集成。同样重要的是要提到图 3 中显示的 SASL 身份验证层正在使用 Cyrus-SASL，它是卡内基梅隆大学作为标准软件包分发的。实际设置使用 PAM 对 IMAP/POP3 用户进行身份验证。它需要使用特殊的 Cyrus 守护程序 saslauthd，SASL 机制使用该守护程序通过 Linux 命名套接字进行通信。

我们新的电子邮件系统主要基于开源软件。Postfix、Cyrus-IMAP 和 MySQL 的结合使用有助于满足大多数系统要求。从硬件角度来看，使用的技术，如存储区域网络 (SAN)、刀片服务器和 Intel x86_64 CPU，有助于满足快速访问、系统可扩展性和高可用性的要求。但是，使用开源软件和新的硬件技术可能会引入新的管理开销。虽然新系统上使用的所有开源软件包都是成熟的产品，但与商业软件相比，它们通常缺少用于系统管理的 GUI。它们的配置和自定义完全基于一组纯文本配置文件。最初，这可能会带来学习曲线，因为必须研究这些配置文件的语法。但是，一旦通过学习曲线，未来的管理可以很容易地自动化，因为可以编写脚本来管理配置参数并将它们存储在中心位置。在硬件方面，复杂的设置也可能意味着复杂的网络和服务器管理设置，这也可能在系统管理期间引入开销。但是，使用所讨论技术的优势大于所涉及的复杂性和学习曲线。通过适当的设计、配置管理和系统自动化，很容易克服缺点。

在撰写本文时，我们新的 Linux 电子邮件系统 (MUMAIL) 已在生产环境中运行了十个月。在此期间，整个系统一直处于稳定状态，停机时间极少。最初在 HOBBIT 上的所有用户电子邮件都在三天迁移窗口中成功迁移到 MUMAIL，迁移过程自动化且无中断。用户现在体验到明显更快的 IMAP/POP3 访问速度。他们的电子邮件存储配额从 20MB 提高到 200MB，并且有可能将配额提高到更高的数字 (1GB)。随着网关级垃圾邮件/病毒防火墙的安装以及硬件速度的提高，在最近的垃圾邮件/病毒爆发期间，MUMAIL 上没有出现电子邮件积压的情况。通过集成的 Active Directory 用户身份验证设置，用户密码或其他敏感信息不再存储在电子邮件系统上。这减少了用户困惑和帐户管理开销，并提高了网络安全性。在 SAN 环境中，更快的磁盘访问显着提高了邮件存储备份速度。最后，新系统提供了硬件和软件环境，通过采用可扩展的设计来支持未来的增长。当未来系统使用量增长时，可以添加更多的服务器节点（前端和后端）和存储。