本文通過介紹 Lotus Domino 的 Cluster 技術及多種監控手段，幫助用戶建立強壯的郵件系統。
一提到 Domino，大家會自然而然的想到郵件系統。是的，構建企業級穩定高效的郵件系統是 Domino 的最核心的功能。在企業辦公日益依賴電子郵件的時代，保障 Mail 系統 7*24 小時穩定運行顯得猶爲重要。 Domino 提供了多種途徑幫助企業維護管理 Mail 系統，讓我們看看怎樣利用這些技術建立一套完善的多級 Mail 監控系統，及時爲管理員提供系統運行情況，有效提高 Domino 系統穩定運行。
下面逐級介紹如果構建強壯的多級 Mail 監控系統。
首先，有效利用 Domino Cluster 系統的特性構建一個強壯的 Mail 系統，Domino Cluster 可以爲用戶提供持續穩定的訪問 , 可以均衡 mail 服務器負載，還可以實現災難備份。根據企業的不同規模，可以採用不同的構建方案。
- 小型企業，兩臺服務器，用戶數不多，可以採用雙機熱備的方案。在日常使用中可以採用兩種方式：
- 一主一備方式：所有的用戶同時訪問一臺主機，另外一臺作爲災難備份機，當主機發生故障是，自動切換到備份機上。以 100 個用戶爲例，所有用戶的 home server 都指向主服務器。
- 平衡負載方式：兩臺服務器同時提供服務，均衡負載，互爲備份，一旦一臺服務器發生故障，另外一臺接管所有的服務。以 100 個用戶爲例，50 個用戶的 home server 都指向一臺服務器，剩餘的用戶指向另一臺服務器。
圖 1. 平衡負載![圖 1. 平衡負載]()
- 大中型企業，多臺服務器，大量用戶。可以採用分散熱備的方案。下圖很好的解釋了這種運做方式。四臺 Mail 服務器，1200 個用戶，每臺設備註冊 300 個用戶，分別有 100 個用戶與其他三臺服務器備份。如果一臺設備發生故障，其他三臺機器各自分攤其中的 100 個用戶，這種方案使每臺機器的負載從 25% 提高到 33%，升幅不大，系統響應速度不會明顯降低。
圖 2. 多臺服務器負載![圖 2. 多臺服務器負載]()
有兩種方法可以爲用戶 Mail 數據庫建立 Replica 。
- 在註冊新用戶時，直接在 Mail 欄目直接指定 Mail File Replicas 服務器。
- 爲已有用戶建立 Replica，用 Administrator – > File (Tab) -> 左側 Mail folder-> 選中一個或多個 Mail file-> 拖動到左側 Server Pane 中 Cluster 機器上。
  |
|
利用 Domino 自有的監控機制，逐級主動監控 Mail 系統
在建立起企業 Mail 系統之後，管理員可以啓用郵件監控工具 Message tracking 來跟蹤、分析、 優化郵件系統的性能。等系統穩定以後，日常的主要工作則集中在系統突發性事件的處理上，如何能知道 Mail 系統的突發事件那？換句話說，迅速判斷出 Mail 系統出現問題的部分，採取相應的措施恢復系統。
在介紹具體的監控的手段之前，我們先簡單介紹一下 Domino Mail 系統的工作原理。 Domino 郵件系統的核心是 Router 任務，它具備發送、傳輸兩種功能：發送是指把 MAIL.BOX 中的 Message 發送到用戶郵箱或數據庫中 ; 傳輸則是完成服務器之間 MAIL.BOX 的消息傳輸。郵件路由分外部與內部兩種，總體來說與外部通訊支持 SMTP、POP3、IMAP 協議，對內通訊則使用 NRPC 或 SMTP，由 Router 根據郵件內容格式（MIME/CD）和郵件地址格式（Internet Address 帶 @ / Notes Address）來選擇路由協議。下圖很好的解釋了郵件的發送的工作過程。
圖 3. 郵件發送過程
在《 IBM Lotus Domino Administrator help 》中有對 Cluster 系統監控的介紹，這裏我們就不累述了。
一個合理的企業 Mail 架構只是設置特定的服務器與外界通訊，因此監控郵件系統可以轉化爲監控 Mail 各種協議端口和 Router 任務。依據這條線索，我們可以利用 Domino 提供了多種監控途徑，實現 Mail 系統的多級監控。以下圖爲例，選擇 SMTP 協議，模擬企業 Mail 系統。 Mail2 負責發送郵件到 Internet，Mail3 負責從 Internet 接收郵件，這裏需要做如下的配置。
- Enable 服務器 Mail2 “ SMTP used when sending messages outside of the local Internet domain ”。
- Enable 服務器 Mail3 “ the SMTP listener task ”
圖 4
我們選用 Mail Routing Event Monitor 和 TCP Server Generator 分別監控 Mail 服務器的 Router 任務與偵聽郵件服務端口。這兩種監控都是利用服務器的 ISpy 任務實現的，當配置好 Event Generator 後，ISpy 就會定時發送探測消息到指定郵箱，檢測 Router 任務； Ispy 也會定時偵測服務器的服務端口。一旦測試失敗，則發送通知消息。既然我們的主要任務是監控郵件服務的，所以在選擇事件通知方式時最好不要選擇 Mail 發送，因爲 Router 一旦出現問題，管理員是不能及時收到告知消息的。
下面介紹的兩種配置方案，在小型企業是可以直接應用的。
- 配置一，Mail 服務器各自監控自己，選擇 Relay to other server 事件通知方式，存入統一的數據庫中。
圖 6![圖 6]()
- 配置二，選擇一臺服務器（Mail1）路由監控的主服務器，由這臺服務器發送偵測消息，並把所有服務器的事件通知消息統一存儲到監控服務器的數據庫中。
從 Domino 7.0 開始，增加了新 DDM (Domino Domain Monitoring) 功能。 DDM 的顯著特點是：
- 以 Server Collection Hierarchy 的層級方式，利用複製公式逐級上傳事件信息，集中存儲單個 Domain 乃至跨 Domain 事件信息。
- 提供解決事件問題的幾種可能方案，幫助管理員迅速決策。
- 在 Event4.nsf 中創建一個 Server Collection Hierarchy 。 在下圖中，w704spr 集中收集服務器 a704spr、l704spr、s704spr 的事件信息。
圖 7![圖 7]()
此時 DDM 數據庫的複製設置中 Advanced 會自動生成複製選擇公式。
圖 8![圖 8]()
- DDM 提供了更加細化的 Probe，下圖的分類增加了 NRPC Routing Status、SMTP Process State、Transfer Queue Check 等 Probe 類型，相對於 Event Generator，事件的類型更精細準確。
圖 9![圖 9]()
- 事件通知信息會存入到 ddm.nsf 數據庫中，結果中包含了事件引起的可能原因與解決方法。
圖 10![圖 10]()
由此可見，DDM 幫助管理員簡化了管理流程，提高了故障診斷效率。
|
|
於第三方監控軟件結合實現 Mail 系統監控，在事件產生的方式上可分爲兩種方式：主動傳輸事件消息和被監控方式。
Domino DDM/Event, 主動向第三方監控軟件傳輸事件消息
Domino 從 7.0 版本起，提供了向 Tivoli Enterprise Console 傳輸 DDM 事件信息的功能，但事件類型僅僅侷限於 Operating System probe 。 並不能滿足 Mail 監控的需要，從 8.0 開始，任何一種 Event 事件類型都能通過格式轉化功能，轉化成 TEC 格式，發送到 TEC 服務器。除了在 Tivoli Server 端設置一個基於允許接受 Domino Event 的 Rule 外，還需配置 Domino Server Configurations 中的 Basics， 啓用 Enable Logging to Tivoli Enterprise Console，另外就是修改 Event handler 中 Notification Method 爲 Forward event to Tivoli Enterprise Console 。
圖 11
利用 Domino 提供的 C++ API，編寫監控 Domino 的特定服務的 Probe，部署到第三方監控軟件上
企業用戶可能部署了第三方監控產品，比如 HP OpenView 等其他產品 。目前，Domino 不提供直接發送到這類監控產品，我們可以利用 Domino C++ API， 遵循前面所述的偵測特定服務及端口的原則，測試郵件是否是否成功。按照監控產品的 Probe 開發規範，開發並部署監控 Domino 的 Probe，主動偵測 Mail 服務及端口。一樣可以實現 Domino Mail 系統監控。
以上所述的三種監控方式（Event、DDM、與第三方監控軟件的結合），爲 Mail 系統管理員提供了發現問題，解決問題的途徑。
|
|
Domino 系統還提供了許多其它監控手段幫助用戶管理維護系統，我們這裏只是針對 Domino 的 Mail 系統這一主體，闡述了利用 Cluster 技術及監控手段爲用戶構建強壯的 Mail 系統的一些方法。在實際的生產環境中，還有其他許多監控功能值得的我們發掘，幫助用戶解決問題。