本文通过介绍 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 系统的一些方法。在实际的生产环境中，还有其他许多监控功能值得的我们发掘，帮助用户解决问题。