运行Sendmail的服务器群集能够在有竞争力的价格上提供高性能和高可用性。对于经验丰富的系统管理员，这一贯是常用的做法。本文描述了我们的研究，量化和描述实现高可用／可伸缩Sendmail 的方法。

我们研究了Linux上Sendmail群集的几种配置，并对它们的相对性能进行了量化。我们通过调整 Sendmail 的配置以及 Linux 操作系统中的参数，研究并测试了公共性能。我们还没有一个共享磁盘用于这些测试，因此我们将项目的范围限定在只包括 SMTP 路由和排队。这是位于专用网的边缘或作为内部邮件存储的前端的Sendmail群集的常用配置。

虽然我们的硬件资源很普通，但我们相信这些相对差异会使我们的结果对于那些要实现基于Linux的 Sendmail服务器群集的系统架构设计师是非常重要的，因为我们的结果说明了Sendmail群集的设计特性的相对重要性。

汇总结果

Sendmail、LDAP 和 DNS 有许多配置选项，但我们只考虑那些对于该应用程序很重要的选项。除非另有声明，否则我们使用标准软件和缺省设置。在这些选项中，我们发现有少数因素可以对性能产生巨大影响，或者是实现可伸缩性必不可少的，如 LogLevel 和 QueueDirectory。

最后，我们发现即使正确配置了 Sendmail，所有这些重要因素也会告诉我们两个事实：

Sendmail 是磁盘密集型的，磁盘速度越快，Sendmail 的速度就越快。

不受控因素也许会影响我们所感知到的性能。如，远程 DNS 服务器发生故障，路由失常、队列填满和其它第三方问题。

我们发现了什么

集群的服务器：通过集群两个服务器并在前端添加负载均衡器，我们发现了最佳消息吞吐量 — 大约每秒 100 条消息。这是最佳单服务器结果的性能的两倍，单服务器的最佳性能大约是每秒 50 条消息。当添加第三个服务器时，几乎看不到性能有所改进。

LogLevel：由于 Sendmail 日志记录的用途有时象审计跟踪，它显示了 SMTP 邮件的进入和外出，因此从磁盘 I/O 的角度来看，日志记录的代价比较昂贵。在某些情况下，允许或者应该关闭此审计功能，以便提供更高的吞吐量。但即使启用了完全日志记录（LogLevel 9），只要将日志文件移到更快的文件系统上，我们仍可以得到可接受的性能。

QueueDirectory：队列目录也是一个明显的争用点。通过使用多个队列以及将 QueueSortOrder 切换成文件名，我们找到了最佳性能。LogLevel 和 QueueDirectory 在使吞吐量增加中共同起着举足轻重的作用。

其它配置选项：我们还测试了关闭 Ident 查找、对于工作负载使用 SharedMem 键和传递模式（Delivery Mode）。这些的作用很小，但我们假设在真正的方案中它们也许会更重要。我们的 Linux 安装要求做很少的更改，它基本上是标准 Red Hat 7.1 并附带标准 kernel.org 2.4.4 内核。我们找出了一些网络问题，但在更改了简单的运行时配置之后已经解决了这些问题。注：我们没有尝试网络 syslog 程序（syslogger）。

测试方案

我们评估了几种测试方案：

单服务器；

循环 DNS；

负载均衡器；

基于 MX 的故障转移。

对于负载均衡器方案，我们尝试了 Alteon 180 设备和运行均衡软件的专用 Linux 服务器。我们使用一台主机逐一调整重要的配置因子来寻找最优的 Sendmail 配置。通过使用此测试的结果，我们得到了最优化的配置，并将它用于其它不同的群集配置中。

循环 DNS

DNS 循环是将多路到来的因特网 SMTP 流量分配到多台机器上的一种简单方法。在其最简单的形式中，针对某一个邮件服务器主机名，会输入几个 A 记录。每个参与的 Sendmail 服务器都被配置成以这个主机名的名义接收邮件。当发送方要将邮件传递给接收方时，就生成了一个 DNS 查询。其结果将包含该主机的所有 A 记录的列表。缺省情况下，大多数 MTA 实现会采用列表中的第一个成员。同一主机名的重复查询会产生 IP 地址的循环列表（这是 BIND/DNS 的一个特性）。例如，如果在因特网上查找名称“us.ibm.com”，会返回以下 IP 地址列表：

　　Name: www.ibm.com 

　　Addresses: 129.42.16.99, 129.42.17.99, 129.42.18.99, 129.42.19.99

重复查询，返回：

　　Name: www.ibm.com 

　　Addresses: 129.42.19.99, 129.42.16.99, 129.42.17.99, 129.42.18.99

再查询一次，返回：

　　Name: www.ibm.com 

　　Addresses: 129.42.17.99, 129.42.18.99, 129.42.19.99, 129.42.16.99

在图 1 中，我们看到一个循环 DNS 正在运行。Sendmail 服务器的所有外部接口都直接连接到因特网，并且在 DNS 中发布。每台机器都充当 SMTP 路由器／缓冲器，从因特网获取邮件并将邮件传递到专用网上的某种公共邮箱服务器。这种方案很容易实施，而且很便宜，如果正确实施，它可以是无故障的。

图 2 说明了使用循环 DNS 的问题。由于 DNS 的工作方式和高速缓存 DNS 记录的可能性，如果某台主机发生故障，邮件代理也许仍会尝试联系它。至少，邮件会被延迟，一直等待连接超时，然后被排入队列，并在补偿时间之后重新发送。

负载均衡器

在最近几年，越来越多地使用了外部的工作负载导向器。这些专用设备可以在几个服务器之间巧妙地分配工作负载，以及处理故障转移／故障恢复。我们对 Alteon 180 交换机进行了大量测试。它允许我们创建虚拟邮件服务器。到达此虚拟服务器的邮件被循环传送到这三个真正的服务器中的每一个。如果其中一个 Sendmail 服务器由于某种原因发生故障，Alteon 将停止发送新连接到该服务器（定期检查该服务器是否已恢复）。

这种配置的优点之一就是它不具有循环 DNS 解决方案的缺点。由于只向全球公布一个 IP 地址，因此当添加／除去群集的成员时，没有理由担心高速缓存的项。由使用诸如 Alteon 180 和 F5 Network 的 Big-IP 之类产品所知，这种做法通常是切实可行的。但是，该设备可能非常昂贵，此外当然会增加另一个维护点。要提供最大保护并且避免单点故障，应该至少安装两个这样的设备。

基于 MX 的故障转移

这是传统的 Sendmail/DNS 配置。DNS 中的主机名可以有一个或多个邮件交换（MX）记录。这些记录包括一个加权因子。当其它 SMTP 服务器试图将邮件传递到此主机时，它们首先寻找 MX 记录及其对应权重。当有多个 MX 记录时，会选择具有最低权重值的 MX 记录。邮件将被传递到第一个主机（该主机应答时，具有最低权重／数字）。

在下例中，某个域具有两个 MX 记录，一个指向芝加哥办事处，权重为 10，另一个指向纽约办事处，权重为 20。在正常情况下，所有邮件都会经过芝加哥办事处，流经公司的 WAN，进行内部传递。

如果芝加哥办事处发生故障，或者到芝加哥办事处的路由发生故障，邮件将自动经由纽约办事处传递。

Linux联盟收集整理

频道声明：本频道的文章除部分特别声明禁止转载的专稿外，可以自由转载.但请务必注明出出处和原始作者 文章版权归本频道与文章作者所有.对于被频道转载文章的个人和网站,我们表示深深的谢意。 原始作者:佚名 录入时间:2007-3-31 2:05:29 信息来源:不详 投稿信箱:itqoo@126.com