级别： 高级 Harry Murray, 软件工程师, Iris
Gary Sullivan, 营销支持专家, IBM
1999 年 11 月 01 日 本文是分为两部分的系列文章的第 2 部分，主要关注 R5 集群的性能测试。本文介绍 R5 集群的新特性，并讨论负载平衡、邮件负载和集群复制器。此外，还为确定新集群的大小提供深刻的见解。
[编者注：本文是关于 Domino 集群性能分析的两篇系列文章的第 2 部分。本文介绍 R5 集群的新特性，并讨论负载平衡、邮件负载和集群复制器。本系列的
第一篇文章
向您介绍了集群，然后查看了在 R4.6 集群上进行的性能测试。此外，还包含在 R4.6 上进行性能测试得到的建议。]
简介
作为 Domino 管理员，您的主要任务是保证服务器能够全天候为用户社区提供服务。与此同时，您还要让 Domino 具有良好的伸缩性，并且在需求和用户数量增加时继续提供快速的响应。您可以通过创建 Domino 集群解决这两个问题。
本文是分为两部分的系列文章的第 2 部分，主要考察了 Domino 集群的性能益处。本系列的第 1 部分介绍了 Domino 集群的总体概念，并以 R4 测试数据为示例讨论集群性能。为了内容的完整性和连贯性，请在阅读本文之前先阅读 第 1 部分。
在本文中，我们将重点转移到 Domino R5，强调为 R5 建立集群的主要差异。然后，我们将探索 Domino R5 集群工作负载平衡，分析尚未记录到文档中的 NOTES.INI 设置，并为如何将该新设置与现有的 NOTES.INI 变量结合使用提供建议，以实现集群工作负载平衡。
我们还展示了 R5 集群邮件 工作负载数据，包括一个关于集群数据测试的总结。本部分对使用多个集群复制器进行研究。我们揭示了集群复制器的影响，从而帮助确定应该使用多少个复制器。
我们为确定新集群的大小提供一些见解，最后介绍未来的工作负载平衡和容量计划工具，帮助您恰当地分布数据库。
Domino R5 集群的主要差别
集群直接受益于 R5 的总体性能改进。例如，启用事务记录时，磁盘 I/O 将减少 10% 至 20%；内存使用可能下降 30%；响应时间可以改进 75%。这些仅是 R5 总体性能改进的一部分。通过升级到 R5 并利用许多与性能相关的新特性，您将能够减轻现有集群的许多性能瓶颈。
此外，还改进了对 R5 集群服务器的操作，从而支持以下以新特性：
- Web 客户机的故障转移和工作负载平衡 (Internet Cluster Manager)
- 闲时日程安排查找
- 同步不特定于主机服务器执行的新邮件代理
- 输入时提前寻址和地址解析
- 跨所有集群副本同步未读标记
Domino R5 集群工作负载平衡
集群工作负载平衡是 Domino Enterprise Server 的特性，它可以将客户机请求分发到可用的服务器，从而避免过度使用特定服务器。这种分发对用户是相当透明的，它帮助过于繁忙的服务器减轻负担。在良好配置的环境中，这个特性会将工作负载分发到一组 Domino 服务器中。在资源充足的情况下，分发工作负载能够减少响应时间，更重要的是，能够改善响应时间的连续性。
Domino 集群服务器和 Notes 客户机协同工作，实现集群工作负载平衡。通过使用 Domino R5 中的 Internet Cluster Manager，Web 客户机还可以利用工作负载平衡带来的好处。为了让测试保持简单，我们主要关注在 Notes 客户机和 Domino 服务器上进行的测试。
如本系列的 第 1 部分 提到的一样，Server_Availability_Threshold
(SAT) 是服务器上的 NOTES.INI 设置，它可以定义在哪个点发生故障转移。第 1 部分还表明，可以根据服务器的响应时间计算出 Server Availability Index (SAI)。当 SAI 低于 SAT 设置时，服务器处于 BUSY 状态。
当集群中的 Domino 服务器处于 BUSY 状态时，已经打开数据库的 Notes 客户机可以继续访问这些数据库。但当客户机尝试打开 BUSY 服务器的数据库时，客户机将收到服务器不响应的提示。因为客户机会自动启用集群，所以它可以访问集群中可用服务器上的 Cluster Manager。（为了应付这种情况，Notes 客户机在本地缓存中存储一个集群服务器列表）。
Cluster Manager 通过访问 Cluster Database Directory 决定集群中哪个服务器拥有被请求数据库的副本。然后，Cluster
Manager 选择最不繁忙的服务器并将其名称返回给客户机，这样客户机就可以打开该服务器上的数据库。
通过这种方式，可以根据服务器的繁忙程度在服务器之间实现负载平衡。
如果没有恰当地设置 Domino，就难以在集群成员之间实现最佳的工作负载平衡。我们从测试和生产环境中发现，除了设置 SAT 之外，我们还必须设置尚未添加到文档中的 NOTES.INI 设置，否则就不能实现良好的故障转移（在集群中将请求从一个服务器重定向到另一个服务器）。
这个未添加到文档中的设置是 Server_Transinfo_Normalize
(STN)。SAI 计算会使用这个设置的值来 “正常化” 服务器的响应时间（即用响应时间除以该值）。到目前为止，还没关于该设置的任何文档，因为进行的测试很少，无法提供可靠的建议。
为了让 SAI 计算恰当地执行，STN 值应该大致等于平均的 Domino 事务时间（针对当前服务器）乘以 100，单位为毫秒。默认值为 3000 毫秒，对应于平均响应时间 30 毫秒每事务。在几年以前开始附带集群时，该默认设置适用于一般的服务器，但是我们的测试表明，对现代服务器而言，该值太大了。
为了改变默认的 STN 设置，在 NOTES.INI 中包含以下内容：
Server_TransInfo_Normalize = 600
如果使用 STN 的默认设置 (3000)，现代更快的服务器只有在负载很重时才会执行故障转移，这样恢复就不能在合理的时间内完成。在 Windows NT 平台上进行的测试表明，STA 和 STN 设置可以相互配合，从而在集群成员之间提供更加均匀的工作负载平衡。
从 STN 的定义就可以猜到，服务器越快，STN 的值就应该越低。在该环境下，更快的服务器具有更高级的 CPU、更快的磁盘子系统或更高速的总线，因此响应时间也就更快。
为了确定 STA 和 STN 的最佳值，我们在测试环境中改变它们（在服务器运行负载时）。
优化 SAT 和 STN
测试表明，当 SAT 的值低于 95 时，服务器就会在执行故障转移之前超载，并且恢复时间很慢。更高的 SAT 值通常导致服务器过早地执行故障转移，转储过多的工作负载。对您的系统而言，最佳的 SAT
值可能有所不同，但 95 是一个很好的起点。在其余测试中，SAT 的值一般都在 95 至 97 之间，我们通过改变 STN 的值来实现所需的结果。
我们在两个不同的 Domino R5.0 服务器上进行测试：
Compaq 7000
两个 Pentium Pro 200 MHz 处理器（1 MB 二级缓存）
Windows NT Server 4.0 Service Pack
4
2 GB RAM
523MB 页文件
6 数据磁盘，使用 RAID 0 SCSI 控制器
操作系统、Domino 可执行文件和页文件存储在包含两个磁盘的 RAID 1（位于独立的 Smart 控制器上）的第一个分区上，事务日志存储在第二个分区上
网络：10 兆以太网络
IBM Netfinity 7000
M10
4 个 Pentium II 400MHz Xeon 处理器（1 MB 二级缓存）
Windows NT Server 4.0 Service Pack
4
44 GB RAM
2 GB 页文件
8 个数据磁盘，在 IBM Netfinity 服务器 RAID 3H Ultra2 控制器上使用高级 RAID 0
操作系统、页文件和 Domino 可执行文件各有一个磁盘（位于独立的控制器上）
网络：10 兆以太网络
关于工作负载
NotesBench 集群邮件工作负载用于在服务器上生成工作负载。这个工作负载执行的事务和 R4 集群邮件工作负载一样（在未来，我们
将更新该工作负载，使其更具有 R5 邮件工作负载的特征）。下面针对每位 “用户” 归纳了大致的邮件事务。我们这个工作负载，因为它反映了 Domino 邮件的最常用功能。我们分别使用 500 和 1000 个 “用户” 进行测试。
|
每用户每天（8 小时）
|
数字
| | 阅读的邮件文档 |
160
| | 发送的邮件消息 |
5
| | 更新的邮件文档 |
64
| | 删除的邮件文档 |
64
| | 与邮件相关的任务总数（包括各种任务） |
293+
|
建议
我们使用这次测试的结果作为在 Windows NT 系统上进行的两次测试的推荐设置：
|
服务器
|
SAT
|
STN
| | Compaq 7000 |
95
|
600
| | IBM Netfinity 7000 M10 |
97
|
200
|
这些是以我们的测试为依据、针对特定机器推荐的初始设置。对于其他特定环境和系统，很可能需要优化这些初始值。
为系统确定最佳的 SAT 和 STN 值
为了确定这些值的最佳设置，我们应该在服务器运行负载时比较 SAI 的 NT Performance Monitor 图表，然后改变 SAT 和 STN 值，观察故障转移的行为特征。您甚至可以在生产环境中进行尝试。如果激活了 Domino NT Performance Monitor 统计数据，您就可以选择 SAI 和正常的 NT 统计数据。查看这些数据的图表能够深入了解服务器的性能。通过深入了解和使用 Performance Monitor（或其他合适的工具），您应该能够理解如何为系统调整出最佳的 SAT 和 STN 值。
 |
SAI 原理
当服务器接近其极限时，Server Availability Index (SAI) 的首选行为就会快速降至为 Server Availability
Threshold (SAT) 指定的值以下，从而触发故障转移，即将该服务器的一部分负载转移到集群中具有相应处理能力的另一个服务器中。在拒绝额外工作负载之后，该服务器的 SAI 就会快速恢复，并允许服务器重新开始接受工作负载。这种期望的行为的图表大致是一条以 SAT 值为中心的正弦波浪线。
|
|
下面的 3 个 NT Performance Monitor 图表帮助展示 SAI 原理。在图 1 中当 STN 设置为 1000 时，SAI 就急剧下降。这种行为是不希望出现的，它是 STN 过高导致的。
注意：当 NOTES.INI 设置为 MailClusterFailover=0 时，将禁用故障转移。
图 1. STN 设置为 1000
在图 2 中，当 STN 设置为 600 时，SAI 在开始时缓慢下降。这种行为比第一种行为好得多。SAI 逐步下降的原因是 STN 的值接近 Domino 服务器完成一个事务所需的实际平均时间。
图 2. STN 设置为 600
接下来我们启用故障转移，STN 和 SAT 的值分别为 600 和 95。注意，SAI 总体上保持较高的水平。这是我们期望的行为。当服务器可用性指数下降到 SAT 95 以下时，服务器将把新的请求重定向到其他集群成员。然后，该服务器会快速恢复，并准备接受新的请求。这就是以上的 SAI 原理中提到的正弦波浪线。
图 3. STN 设置为 600，SAT 设置为 95
|
测试总结
我们得出的结论是，要改进集群工作负载平衡，就应该调整 NOTES.INI 中的 SAT 和 STN 值，让它们更好地反映现在高端机器的 Domino 服务器事务性能。这种调优方式的好处是让您更好的利用 Domino 服务器的能力（CPU、内存和更快的磁盘子系统）。
|
|
确定 R5 集群邮件工作负载和最佳的集群复制器数量
在这个小节中，我们展示来自集群邮件测试的数据及其含义。我们发现使用多个集群复制器能够改善集群的性能。此外，我们还发现事务日志能够改进集群服务器上的磁盘利用。继续仔细了解我们的测试环境，以及如何在您的环境中测试多个集群复制器的好处。
我们的集群测试环境包含两个服务器。“用户” 位于称为活动服务器的服务器上。另一个服务器用作备用服务器。邮件消息没有路由。所有数据库都复制到备用服务器上。
活动服务器
Compaq 7000，有 2 个 Pentium Pro 200 MHz 处理器（1 MB 二级缓存）
2 GB RAM
512 MB 页文件
2 个 Smart-2DH-Array SCSI 控制器（一个矩阵有 6 个 RAID 0* 数据磁盘，另一个矩阵有 2 个磁盘，用于存储操作系统、页文件、Domino 可执行文件和事务日志**）
网络：10 兆以太网络
操作系统：Windows NT Server 4.0 Service Pack
4
Domino Release 5.0
备用服务器
Dell Dimension，有 2 个 Pentium II/300MHz 处理器
512 MB RAM
1024 MB 页文件
6 个改进的 PowerEdge RAID 1 磁盘（4 个磁盘用于存储数据，2 个磁盘用于存储操作系统、页文件、Domino 可执行文件和事务日志**）
网络：10 兆以太网络
操作系统：Windows NT Server 4.0 Service Pack
4
Domino Release 5.0
* 不推荐对数据磁盘使用 RAID 0，因为它没有容错功能。我们推荐数据磁盘使用改进的 RAID 1。
** 操作系统和 Domino 可执行文件共享一个磁盘，而事务日志和页文件共享另一个磁盘。理想情况下，页文件应该有独立的磁盘，而事务日志应该有自己的 RAID 磁盘集。
图 4. 活动和备用服务器
左边的服务器（活动服务器）具有工作负载，被称为 “活动” 集群成员。右边的服务器（备用服务器）称为 “备用” 集群成员，因为它的唯一负载就是集群复制。
尽管一般不在生产系统中使用该配置，但这是一种有用的测试配置，因为您可以分别在发出集群复制的系统和接收系统上测量复制负载。当您了解某个负载之后，就更容易预测向第二个服务器添加另一个负载时会发生什么。因此，使用 NotesBench 测试允许我们显示精确的 CPU 使用率和磁盘使用率，以及其他集群复制对服务器的影响。
关于工作负载
如上一小节所述，NotesBench 集群邮件工作负载用于在服务器上生成工作负载。
测试参数
子 NOTES.INI 设置：
NthIteration=6（标准设置；在 8 小时内 5 次发送邮件）
NormalMessageSize=10000（大小为 10K 的消息）
NumMailNotesPerUser=100（测试开始时收集箱中有 100 条消息）
NumMessageRecipients=3
集群测试使用 500 个用户，每个集群成员运行一个集群复制器。测试的结果表明：
- 在启用集群的活动服务器上，当服务器运行负载时，2-CPU 200 MHz Pentium Pro 系统的 CPU 使用增加了 32%（CPU 百分比从 25% 上升到 33%），而磁盘使用率增加了 21%。
图 5. CPU 使用
- 在启用事务日志的活动服务器上，CPU 使用保持不变，而磁盘使用下降了 21%（数据磁盘百分比从 74% 下降至 61%）。
图 6. 数据磁盘使用
- 在没有直接工作负载的备用服务器上，在 500 个用户的集群复制活动测试中，产生的 CPU 负载为 8%，磁盘活动为 35%。当在两个服务器上都启用事务日志时，备用服务器上的资源使用稍微增加。这种增加源于活动服务器能够进行更快的复制。
注意：如果向备用服务器集群成员增加工作负载，它将在活动服务器上创建额外的工作负载，包括从备用服务器到活动服务器的复制活动。
在改变集群复制器的数量时测量工作负载
在用户为 500 的集群邮件测试期间，活动服务器上的集群复制器的数量在 1 和 4 之间。
在下面的图表中，服务器 1 为活动服务器，服务器 2 为备用服务器。在所有测试中，备用服务器有 2 个集群复制器。我们从测试中可以看到，使用 2 个以上的集群复制器能够显著提升服务器的性能。当使用多个集群复制器时，集群复制队列和工作队列深度时间都减少了。集群复制器数量为 2 时集群复制器 CPU 使用最少。
注意：如果没有足够的资源支持集群复制器，添加复制器任务会适得其反。
例如，使用一个集群复制器时，将更新从服务器 1 复制到服务器 2 所需的平均时间为 45 秒；而使用 3 个集群复制器时所需时间下降至 14 秒。
图 7. 平均复制器队列时间
工作队列深度是指等待被集群复制器处理的复制数量。因此，该队列越短越好。
图 8. 平均工作队列深度
使用两个集群复制器时 CPU 使用也下降了。
图 9. 所有复制器任务的平均 CPU 使用
这个图表再次表明，使用两个集群复制器时会减少 CPU 的使用。
图 10. 500 个用户时平均 CPU 使用
双节点服务器的推荐集群复制器数量
对于包含两个节点的集群，我们推荐在每个活动成员上使用两个集群复制器。如果有足够的 CPU 储备，您甚至可以运行 3 个集群复制器，以缩短复制的发生周期。如果要添加集群服务器，仅需向 NOTES.INI 中的 ServerTasks 设置添加一个 “clrepl”。例如：
ServerTasks =
ROUTER,UPDALL,ADMINP,CLDBDIR,CLREPL,CLREPL,CLREPL
|
测试总结
我们的建议是，每个集群成员上运行的集群复制器应该比它需要复制到的集群成员的数量多一个。即，当一个成员在一个集群中需要复制到 n 个节点，那么应该在该成员上运行 (n+1) 个集群复制器。然后以此为基线调整集群复制器的数量，同时监控这对复制器队列和 CPU 使用的影响，从而为您的系统找到最佳的复制器值。
此外，我们的测试表明，在 2 CPU 200 MHz Pentium Pro 系统上，添加集群会导致运行负载的服务器的 CPU 使用增加约 32%，而使用集群邮件负载时磁盘使用增加 21%。添加事务日志可以减少磁盘使用。如果集群中的两个成员的活动负载为 500 个用户，那么 CPU 和磁盘使用分别增加 8% 和 35%，因为负载需要从服务器 2 复制到服务器 1。
|
|
确定集群的大小
我们的集群测试数据（参见本系列的 第 1 部分）表明，如果 Domino 服务器的工作负载比较大并且以写更新为主，那么复制对资源的影响非常大。应该提醒的是，没有标准的方法可以确定集群的大小，不过 “有依据的猜测” 会帮上大忙。
为了确定集群的大小，我们首先假设您有一个正在运行的 Domino 服务器。我们将使用该服务器上的资源性能信息来评估集群的硬件。我们假设您打算创建一个包含两个服务器的集群，并且用户和数据库是均匀分布的。我们这样假设的原因是，客户的集群一般都包含 2 个服务器。
如果有多个集群服务器并且有多个副本，那么确定集群的大小就更加困难，但通过将本文的见解和生产测试结合起来，仍然可以解决这个困难。
按比例增加工作负载
创建集群是增加的工作负载与服务器上的工作负载更新强度是成比例的。为集群成员增加的 CPU 资源也是变化的，在以读为主的环境中约为 5%，而在工作负载非常重的环境中，所需 CPU 资源约为非集群基础工作负载的 3 倍。（要了解相关数据，请阅读本系列的 第 1 部分）。
因此，技巧就在于将典型用户活动与本系列第一、第二部分描述的活动进行对比，并找到一个大致的比例系数。然后测量您现在的 CPU 使用，并通过比例系数估计最终的 CPU 使用。
记住，您需要留出足够的容量来接管失败集群成员的工作负载。对于负载正常的服务器，我们建议其总 CPU 使用不要超过平均水平（70%）。
按比例增加磁盘容量
也可以使用以上例子采用的方法估算需要增加的磁盘需求。首先测量当前的磁盘活动，然后将典型用户与我们的测试中的工作负载进行对比，从而得出一个比例系数。
网络带宽
为了确定网络带宽是否够用，您首先需要使用嗅探软件和硬件测量网络中当前的工作负载。如果工作负载接近或大于 40%，您就需要升级现在的网络，或创建一个新的网内集群网络（如本系列 第 1 部分 所述）。
因为集群复制而增加的网络工作负载必须与增加的磁盘活动成比例。在 100 MB 的网络中网络工作负载一般不会造成问题。
内存需求
内存需要比当前的 R5 中稍微高些，在 R5 中约为 200K 每 Notes 客户机。
未来的工作负载平衡和容量计划工具 —— Activity Trends
将数据库分布到各个集群成员是实现集群工作负载平衡的最好方法之一。然而，要恰当地分布数据库可能需要大量时间。客户曾经要求提供一种工具来帮助分布数据库。现在，IBM 的一款产品即将完成，它能够通过图表展示数据库在整个集群中的分布，以及哪个数据库的负载比较重。
在 R5 上运行时，这个新的工具能够以最佳的方式重新分布数据库。当然，即使您不使用集群，该工具还是十分有用的。例如，可以通过它更加轻松地合并服务器任务。总体而言，它可以在一组异构 Domino 服务器中收集、分析服务器数据库和连接活动。这个工具能够根据收集到的数据执行工作负载平衡和容量计划功能。
在发表本文时这个产品还不可用。请关注未来的 Iris Today，了解该产品在何时发布。
要更多地了解关于 Activity Trends 的信息，请阅读由 John Lamb 和 Peter Lew 合著的 Lotus Notes and Domino 5
Scalable Network Design: Web Server Network
Infrastructure，McGraw-Hill 出版社，ISBN
007913792X。
结束语
我们希望本文能够帮助拥有集群的 Domino 管理员改善集群的性能，并鼓励未拥有集群的管理员创建一个集群。需要记住的一件重要事情是，在部署之前要正确地确定集群的大小。
在创建集群之后，要密切监控性能数据，提前发现性能瓶颈。通过这些步骤能够帮助您实现一个有用、高效的 Domino 服务器集群。
参考资料
作者简介 | | | Harry Murray 于 1998 年加入 Iris Performance Group。他目前参与 Windows NT 系统上的 Domino R5 的测试。在加入 Iris 之前，他在 Digital Equipment Corp. 的性能小组工作，负责在数字服务器上对 Domino 进行 NotesBench 测试。在此之前，Harry 管理过许多数字生产系统，并且是 System Technical Support 的许多数字设备的经理。 |
| | | Gary Sullivan 于 1987 年加入 IBM，现在是 IBM Lotus Integration Center 的营销支持专家。在加入 IBM 之前，Gary 是 FMC 公司的容量规划经理，而在此前是 Atlantic Richfield 的研究顾问。 |
对本文的评价
| 
