Linux下高可用-可伸缩Sendmail研究.doc

　　Linux下高可用/可伸缩Sendmail研究 　　运行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.，会返回以下 IP 地址列表： 　　Name: .ibm. 　　Addresses: 129.42.16.99, 129.42.17.99, 129.42.18.99, 129.42.19.99 　　重复查询，返回： 　　Name: .ib