關於作者
Jay D. Allen 白天在 IBM 從事於 IT 前沿技術，主要是使用 Linux。夜裡，Jay 研究 IT 領域的一些沒落技術，主要是使用 DEC PDP-11 和其它古董技術。可以通過 [email protected] 與他聯系。
自 1992 年以來，Peter Bogdanovic 一直是一位軟件工程師和 Unix 系統管理員。他目前在 IBM 的 Linux Competency Center 工作。可以通過 [email protected] 與他聯系。
Clifford White 是 IBM 的解決方案工程師，在 IBM 的 Linux Competency Center 工作。可以通過 [email protected] 與他聯系。
運行 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）。這些的作用很小，但我們假設在真正的方案中它們也許會更重要。
OS。我們的 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 記錄的可能性，如果某台主機發生故障，郵件代理也許仍會嘗試聯系它。至少，郵件會被延遲，一直等待連接超時，然後被排入隊列，並在補償時間之後重新發送。
圖 1 圖 2
負載均衡器
在最近幾年，越來越多地使用了外部的工作負載導向器。這些專用設備可以在幾個服務器之間巧妙地分配工作負載，以及處理故障轉移／故障恢復。我們對 Alteon 180 交換機進行了大量測試。它允許我們創建虛擬郵件服務器。到達此虛擬服務器的郵件被循環傳送到這三個真正的服務器中的每一個。如果其中一個 Sendmail 服務器由於某種原因發生故障，Alteon 將停止發送新連接到該服務器（定期檢查該服務器是否已恢復）。
這種配置的優點之一就是它不具有循環 DNS 解決方案的缺點。由於只向全球公布一個 IP 地址，因此當添加／除去群集的成員時，沒有理由擔心高速緩存的項。由使用諸如 Alteon 180 和 F5 Network 的 Big-IP 之類產品所知，這種做法通常是切實可行的。但是，該設備可能非常昂貴，此外當然會增加另一個維護點。要提供最大保護並且避免單點故障，應該至少安裝兩個這樣的設備。
圖 3 圖 4
基於 MX 的故障轉移
這是傳統的 Sendmail/DNS 配置。DNS 中的主機名可以有一個或多個郵件交換（MX）記錄。這些記錄包括一個加權因子。當其它 SMTP 服務器試圖將郵件傳遞到此主機時，它們首先尋找 MX 記錄及其對應權重。當有多個 MX 記錄時，會選擇具有最低權重值的 MX 記錄。郵件將被傳遞到第一個主機（該主機應答時，具有最低權重／數字）。
在下例中，某個域具有兩個 MX 記錄，一個指向芝加哥辦事處，權重為 10，另一個指向紐約辦事處，權重為 20。在正常情況下，所有郵件都會經過芝加哥辦事處，流經公司的 WAN，進行內部傳遞。
如果芝加哥辦事處發生故障，或者到芝加哥辦事處的路由發生故障，郵件將自動經由紐約辦事處傳遞。
如果芝加哥辦事處在 SMTP 事務中發生故障，那麼該事務就會失敗（紅線）。由於 SMTP 是一個事務，因此保證了消息完整性，發送方將超時、回退，並在以後重新發送整條消息。如果芝加哥辦事處仍然停機，郵件會自動流經紐約辦事處。
這種方法的主要優點是它是一種非常成熟的過程，有完善的文檔，易於理解。另外，它只需要做少量的配置變動，而且不需要附加軟件或硬件。遺憾的是，工作負載沒有被平均分配，因此實際上在重負載情況下，服務也許會前後“變化不定”。MX 解決了可用性問題，但沒有解決可伸縮性問題。其結果就是為了解決在高峰流量負載期間可能發生的故障，您最終要購買雙份硬件。
圖 5 圖 6
混合／實際情況
實際解決方案趨向於上述所有技術的混合。例如，發送到 IBM 的因特網郵件被傳遞到以下三個地區中心之一：科羅拉多州、紐約州和北卡羅萊納州。通過將用於故障轉移的 MX 記錄和循環 DNS 組合在一起，IBM 保證了快速／可靠的因特網郵件。以下是公開 DNS 記錄：
us.ibm.com preference = 10, mail exchanger = e22.nc.us.ibm.com
us.ibm.com preference = 10, mail exchanger = e23.nc.us.ibm.com
us.ibm.com preference = 10, mail exchanger = e24.nc.us.ibm.com
us.ibm.com preference = 20, mail exchanger = e1.ny.us.ibm.com
us.ibm.com preference = 10, mail exchanger = e2.ny.us.ibm.com
us.ibm.com preference = 10, mail exchanger = e3.ny.us.ibm.com
us.ibm.com preference = 10, mail exchanger = e4.ny.us.ibm.com
us.ibm.com preference = 20, mail exchanger = e31.co.us.ibm.com
us.ibm.com preference = 10, mail exchanger = e32.co.us.ibm.com
us.ibm.com preference = 10, mail exchanger = e33.co.us.ibm.com
us.ibm.com preference = 10, mail exchanger = e34.co.us.ibm.com
us.ibm.com preference = 20, mail exchanger = e21.nc.us.ibm.com
重復的 DNS 查詢生成了 MX 首選項的循環列表：
us.ibm.com preference = 10, mail exchanger = e2.ny.us.ibm.com
us.ibm.com preference = 10, mail exchanger = e3.ny.us.ibm.com
us.ibm.com preference = 10, mail exchanger = e4.ny.us.ibm.com
us.ibm.com preference = 20, mail exchanger = e31.co.us.ibm.com
us.ibm.com preference = 10, mail exchanger = e32.co.us.ibm.com
us.ibm.com preference = 10, mail exchanger = e33.co.us.ibm.com
us.ibm.com preference = 10, mail exchanger = e34.co.us.ibm.com
us.ibm.com preference = 20, mail exchanger = e21.nc.us.ibm.com
us.ibm.com preference = 10, mail exchanger = e22.nc.us.ibm.com
us.ibm.com preference = 10, mail exchanger = e23.nc.us.ibm.com
us.ibm.com preference = 10, mail exchanger = e24.nc.us.ibm.com
us.ibm.com preference = 20, mail exchanger = e1.ny.us.ibm.com
結果
單個 SMTP 服務器
測試名稱 隊列位置 LogLevel SharedMem Ident 傳遞方式 提交數／秒
stmpa-def 磁盤 9 否 是 異步 8.4
smpta-interactive 磁盤 9 否 是 交互式 10.0
smpta-noident 磁盤 9 否 否 交互式 9.7
smpta-sharedmem 磁盤 9 是 是 交互式 9.8
smpta-log4 磁盤 4 否 是 交互式 24.2
smtpa-ramdisk RAM 9 否 是 交互式 19.4
smtpa-ramdisk-log4 RAM 4 否 是 交互式 48.4
smtpa-ramlog9 磁盤 9
RAM 否 是 交互式 25.8
smtpa-freshlog9 磁盤 9
新文件 否 是 交互式 10.1
smtpa-toeleven RAM 9
RAM 是 否 交互式 49.0
由 MailStone 報告的單服務器解決方案的連接錯誤百分率始終是 0.0
多個 SMTP 服務器
對於多服務器測試，我們只使用單服務器測試的最高性能組合，觀察當添加服務器時，其規模是如何增長的。對於所有多服務器測試，選項是：
RAM 上的隊列
RAM 上的 LogLevel 9
啟用共享內存
禁用 Ident
傳遞方式設置成交互式
測試名稱 循環
設備 服務器數量 提交數／秒 連接錯誤
bigmail2-allram Alteon 2 95.9 43.1%
balance2-allram Balance 2 74.6 30.1
bigmail3-allram Alteon 3 102.8 87.8%
balance3-allram Balance 3 103.8 81.4%
結束語
通過使用現成的計算機設備，我們演示了可以構建高性能、高可用的 Sendmail 服務。在我們的測試中，磁盤 I/O 是 Sendmail 系統的總體性能中最重要的因素。將服務器配置成不記錄日志，或者將日志記錄到 RAM 磁盤，會大大提高性能。另外，郵件隊列也是 Sendmail 服務器進程中另一個磁盤密集型的部分。將隊列分配到多個目錄、將隊列目錄放到最快的可用文件系統上或者將隊列移到 RAM 磁盤也會大大提高性能。將郵件隊列移動到 RAM 磁盤也許不適合許多安裝，因為 — 在 OS 崩潰或服務器硬件故障的情況下 — 會損害 Sendmail 系統的消息傳遞完整性。
我們很驚奇地了解到，對於工作負載，我們可以將負載均衡管理器 Alteon 180 這個商業產品替換成運行 user-land 程序“balance”的專用 Linux 系統。這種 Linux 解決方案的經濟效益是頗為引人注目的，而且使用設備也許會有操作上的好處。
我們看到，Sendmail 服務器由一個升到兩個時，性能翻了一倍，但奇怪的是，添加第三個服務器卻沒有效果。我們的負載生成裝置正在努力工作，因此也許是郵件生成裝置已經達到了飽和。我們還發現在重負載情況下的一些 TCP/IP 問題，這些問題可能會造成連接出錯率的上升。我們建議使用許多負載生成機器來處理每天一千萬條消息以上的負載。
配置和注意事項
Sendmail 就象大多數傳統 Unix 程序。它是高度專用的，而且是模塊化的，因此可以很容易地與其它組件集成，組成更大的解決方案。Sendmail 群集就是這樣一種解決方案，我們需要描述其它組件的配置。其中一些是為增加性能或可伸縮性、工作負載分派器和網絡設計而設計的。其它組件是用於增加 Sendmail 群集的可管理性的，如 LDAP 和 rsync。最後，我們描述了為測試環境模擬真正工作負載所使用的工具。
Sendmail 配置
Sendmail 群集硬件／服務器
網絡設置和檢驗
LDAP 服務器設置
名稱服務設置
Mailstone SMTP 負載模擬器
如果您有問題、想要更多信息或者想要他們在此研究中使用的配置文件副本，盡請聯系作者。
免責聲明：上述文章是基於在實驗室環境中進行的實驗室測試。特殊定制安裝中的結果也許會由於許多因素而發生變化，這些因素包括每個特殊安裝中的工作負載和配置。因此，上述信息是在以“按現狀”的基礎上提供的。明確表示不承擔適銷性和適用於某特定用途的保證。使用本信息帶來的風險將由您自行承擔。