Domino 集群，第 1 部分
此内容是该系列 # 部分中的第 # 部分： 优化 Lotus Domino 服务器性能https://www.ibm.com/developerworks/cn/views/global/libraryview.jsp?series_title_by=优化+lotus+domino+服务器性能敬请期待该系列的后续内容。此内容是该系列的一部分：优化 Lotus Domino 服务器性能敬请期待该系列的后续内容。
[编者注：本文是关于 Domino 集群性能分析的两篇系列文章的第 1 部分。本文首先介绍集群，然后再查看在 R4.6 集群上进行的性能测试。此外，还包含在
R4.6 上进行性能测试得到的建议。本系列的
主要关注 R5 集群的性能测试，包括关于 Internet Cluster Manager 和集群复制的数据。] 简介作为 Domino 管理员，您的主要任务是保证服务器能够全天候为用户社区提供服务。与此同时，您还要让 Domino 具有良好的伸缩性，并且在需求和用户数量增加时继续提供快速的响应。您可以通过创建 Domino 集群解决这两个问题。本文是分为两部分的系列文章的第 1 部分，主要考察了 Domino 集群的性能益处。本文首先介绍 Domino 集群，关注与性能相关的方面。然后，查看我们在 Domino R4.6 集群上进行的性能测试。 讨论 R5 集群的性能测试，包括关于 Internet Cluster Manager 和集群复制的数据。
在本文章您将看到，在 Domino R4.6 上进行的性能测试涉及到各种系统配置。在这些测试中，我们考察了不同的评估场景，并看到在特定工作负载下各种配置的表现。这些评估场景帮助我们得出关于性能的以下结论：
集群如何影响服务器上的负载
添加多个 Cluster Replicators（集群复制器）对性能的影响
如何改进现有集群的性能这些测试数据来自各个小组，包括 IBM 在得克萨斯州奥斯汀市的 Distributed Systems Performance Analysis 部门；Iris Performance 小组和 IBM Lotus Integration Center (ILIC)，后者支持所有 Lotus 产品，包括 Domino 集群。我们希望这些结论能够对您有所帮助，让集群更好地为您工作。什么是 Domino 集群？Domino 集群将多个 Domino 服务器连接起来，从客户机的角度看它们就是一个统一的资源。集群充当各种资源的 “统一” 供应者，这使客户机请求能够得到及时处理。如果特定服务器在请求到达时不可用或过于繁忙，集群可以透明地将该请求传递给其他可用的服务器。集群成员可以分布在各种受支持的 Domino 平台上，包括 Windows NT、各种 UNIX 系统、IBM AS/400、MVS 或 OS/2。集群支持 Notes 客户机和 Web 浏览器客户机。
Domino 集群完全是在应用程序级实现的。不需要特别的硬件。通过使用集群，在多个服务器上的多个数据库副本能够提供高可用性。此外，Domino 在集群成员之间分配负载（称为工作负载平衡），从而降低总体响应时间，并在高峰期实现更连贯的响应时间。
在 Domino 集群中，如果一个成员出现故障，集群中的另一个成员将透明地承担失败成员的工作负载。这一行为称为故障转移。通过将请求重新定向到集群中的另一个具有处理该请求的数据库副本的服务器，Domino 服务器为客户机提供故障转移。（要更多地了解关于集群故障转移的信息，请参见 ）。重定向是 Cluster Manager 的一个功能。Cluster Manager 跟踪集群成员和所有集群服务器的状态。集群成员可能位于同一个房间中，也可能分散在世界各地。
当数据库发生变更时，Domino 集群将把变更复制到数据库的所有复制副本中。这种集群组件的同步对 Domino 的高可用性十分关键。这种类型的复制称为事件驱动（即时）复制，这与按计划进行的标准复制相对。事件驱动复制是 Cluster Replicator 的功能之一。其他集群解决方案，比如 Microsoft Clusters (Wolfpack)，也提供数据库故障转移，但其转移目标是使用数据库的单个实例的集群成员。两个集群成员共享相同的 RAID 集。如果因为磁盘驱动器或 RAID 故障而造成数据库不可访问，就不能进行故障转移。在 Microsoft Clusters 中，仅能在硬件级别进行故障转移。此外，因为 Microsoft Clusters 只有数据库的单个副本，所以不能将数据库分布到不同的地理位置，以进行 “热点” 故障转移。 关于工负载平衡 通过将超载服务器的用户请求重新发送到其他具有可用资源的服务器，Domino 集群提供了工作负载平衡。为了优化工作负载平衡，您可以使用以下技术：1.
确保在集群中均匀地分布数据库。 当集群中的某个服务器发生故障或超载时，用户请求就被自动重定向到集群中的其他服务器。理想情况下，该负载应该平均分配到集群的其他所有服务器中。然而，仅当失败服务器的数据库副本大致均匀地分布在集群的其他所有服务器中时，才能实现平均分配故障服务器的负载。要了解如何在集群中分布数据库，请查看 “” 中提供的一个例子。注意，如果您将数据库均匀地分布到所有服务器中，那么这些数据库的活跃性就是一样的。如果您有一些非常活跃的数据库，您可能需要微调这些数据库的分配，让每个服务器的活跃性大致相同。
如本文后面的测试数据所示，平均地分布数据库是实现高效工作负载平衡的关键。 要了解集群成员之间的数据库平衡，请阅读本系列的 。2. 对繁忙的服务器设置阈值。 集群中的每个服务器都会周期性地确定自己的工作负载
，其依据是服务器最近处理的请求的平均响应时间。服务器可用性指数 反映服务器的繁忙程度。指数值范围是 0 至 100，100 表明服务器的负载很轻（响应时间很快），而 0 表明服务器的负载很重（响应时间很慢）。通过 NOTES.INI 设置 SERVER_AVAILABILITY_THRESHOLD，您可以指定一个阈值，它将确定服务器可用性指数的最低值，处于该值的服务器被认为是不繁忙的。当服务器可用性指数低于这个阈值时，服务器就处于繁忙状态。处于繁忙状态的服务器将其用户请求重定向到集群中的其他服务器。
服务器的可用性指数是指当前响应时间和最佳响应时间（没有 Domino 事务）的比率。注意，这里的响应时间仅是针对服务器而言的，不考虑网络时间。每个服务器上的 Cluster Manager 进程监控一组服务器操作的平均响应时间，周期约为 75 秒。
当要计算服务器的可用性指数以正常化观察到的响应时间时（即用正常值除以观察到的响应时间），Domino 将使用 NOTES.INI 设置 SERVER_TRANSINFO_NORMALIZE。到目前为止，该设置还没有加入到文档中，但在 R4.6 和 R5 中已经可用。
要让可用性指数计算能够恰当执行，正常化后的值应该大致等于平均的 Domino 事务时间（针对当前服务器），单位为 milliseconds*100（毫秒*100）。默认值为 3000ms，对应于每个事务的平均响应时间 30 ms。在几年以前开始附带集群时，该默认设置适用于一般的服务器，但是对于现代的服务器，该值太大了。您应该在今天更快的服务器上使用更小的正常值，以让负载能够正确地实现故障转移。
我们在 Windows NT 上的测试表明您可以协调阈值和正常值设置，以在集群成员之间实现均匀的负载平衡。即当某个服务器过于繁忙或不可用时，您可以将故障转移到其他服务器。要更多地了解如何指定 NOTES.INI 设置，请阅读本系列的 。
设置每个服务器的最大用户数。
通过 NOTES.INI 设置 SERVER_MAXUSERS，您可以指定能够同时访问服务器的最大用户数。当服务器达到这个值时，它就拒绝开始其他会话的请求。因此，用户的请求就被转移到集群中的其他服务器中。这个设置不是集群本身的，但在集群成员遇到问题时它可以重定向用户请求，这十分有用。
设置集群布局在设置集群时，您应该考虑使用私有 LAN 实现网内集群通信的好处。以这种方式，您可以从 LAN 解除集群的探测和复制网络流量，从而为客户机与集群服务器的交流提供更多带宽。这样还可以在集群中避免网络单点失败。要更多地了解使用私有 LAN 实现网内集群通信，请阅读 “”。
设置多个 Cluster Replicator另外，您应该考虑设置多个 Cluster Replicator。当向集群添加一个服务器时，Domino 将加载 Cluster Replicator (CLREPL)，并将其添加到 ServerTasks= line in the NOTES.INI 文件。通过这种方式，当您重启服务器时就会自动加载 Cluster Replicator。这对大部分集群配置已经足够。但是在某些情况下，单个 Cluster Replicator 可能跟不上复制工作负载。（当一个数据库被复制之后，更新原始数据库的事务也将更新所有数据库副本）。
如果您运行多个 Cluster Replicators，就可以划分复制工作负载，以并行的方式处理它们。这种功能类似于标准 Domino replicator，它也运行多个 replicator 任务。您还可以在 ServerTasks= line 上指定 CLREPL 的多个实例，这会在服务器启动时加载指定数量的 Cluster Replicator。
为了确定添加额外的 Cluster Replicator 任务是否有好处，您可以监控 Replica.Cluster.WorkQueueDepth 统计数据（在 Replica Statistics 报告中）。该数据显示当前已修改并等待集群复制的数据库数量。如果这个值总是大于 0，您应该启用更多 Cluster Replicator。要更多地了解关于集群统计数据的信息，请阅读 “”。
要更多地了解什么时候应该添加额外的 Cluster Replicator 任务，请查看本文后面提供的测试数据。此外，在本系列的
中查看 R5 测试数据。
Domino R4.6 集群的测试方法
这个小节概括地描述了我们在 Domino R4.6 集群测试场景中使用的测试方法，其中包括关于系统配置、工作负载和评估场景的信息。
请注意，我们在性能测试中使用的配置不一定是推荐的配置。我们选择这些特定配置的主要原因是，它们能够便捷地度量各种集群组件的资源利用率。此外还要注意，这些服务器是低端的服务器 —— 我们仅使用它们显示各种资源的相对变化。磁盘资源是该配置的限制，您将在本文随后提供的数据看到。
另外，Domino 集群是相当灵活的。例如，一些站点可以创建一个 Domino 服务器集群，它可以跨同一硬件服务器的多个操作系统分区。我们的测试例子仅是众多 Domino 集群之一。事实上，本系列的
显示了中级集群服务器的 R5 数据。
系统配置为了运行这些场景，我们使用以下配置：
服务器CPU：Dell PowerEdge 2200 ，带有一个 Pentium II/333MHz 处理器
内存：512MB RAM
523MB 页文件
两个 SCSI 控制器和两个磁盘
网络：100 兆以太网（私有）
操作系统：Windows NT Server 4.0
Domino：Release 4.6.2
客户机CPU：Dell Dimension，有一个 Pentium II/400MHz 处理器
内存：256MB RAM
267MB 页文件
操作系统：Windows NT Workstation 4.0
Notes：Release 4.6a
来自 IBM Center of Competency 的邮件工作负载关于工作负载在我们的前三个测试场景中，我们设置 Notes 客户机运行 R4 邮件工作负载，即来自 IBM Center of Competency 的称为 “IBM Geoplex 站点” 的工作负载。这个工作负载使用标准的 Notes 邮件 —— 那就是使用 Notes Remote Procedure Call (RPC) 协议而不是 Internet 协议传输邮件。该工作负载模拟 3 种类型的邮件用户：轻型、中型和重型。在每次长度为 15 分钟的脚本迭代期间，用户：
在邮件数据库上进行导航
重新归档、删除和更新邮件文档这个工作负载以一个非常活跃的 IBM 站点为模型，并且更新速度非常快（即引起很多磁盘写操作）。由于更新引起了集群复制，所以它的量是很大的。IBM Geoplex 站点工作负载强度大约为 NotesBench R4 邮件工作负载的 3.5 倍。下面的表显示了针对轻型、中型和重型用户的 IBM Geoplex 站点工作负载的详细信息：单位轻型中型重型客户机吞吐量（每 100 个用户）# API/每分钟245337850服务器吞吐量（w/o 集群）（每 100 个用户）# 事务/每分钟488500901邮件吞吐量（每 100 个用户）# 消息/每分钟1146240平均邮件大小字节1,0001,0006,888# 模拟 Geoplex 用户每用户线程211我们在场景 4 中使用 NotesBench R4 邮件负载。该工作负载使用 nthiteration 设置确定模拟用户发送 1K 消息的频率。当 nthiteration=1 时，在该时间周期内发送的邮件消息的最大数量 —— 是收件人为 3 时的 32 陪。在每次脚本迭代期间，用户：
每天阅读 160 个邮件文档
每天更新 64 个邮件文档
每天删除 64 个邮件文档要更多地了解 R4 邮件工作负载，请查看 NotesBench Web 站点。关于评估场景如前所述，这些评估场景帮助我们得出关于性能的以下结论：
集群如何影响服务器上的负载
添加多个 Cluster Replicators 对性能的影响
如何改进现有集群的性能每个场景都关注集群复制，因为集群的所有开销都源于集群复制。我们的性能测试表明，其他集群进程（Cluster Database Directory Manager 和集群探测等）占用的开销很小。场景 1：使用邮件工作负载的集群复制这个场景测试在轻型、中型和重型邮件使用时（使用 IBM Geoplex 站点负载）集群复制对性能的影响。我们首先测量在用户数为 100 时 CPU 的利用率。然后，我们使用不同的用户数运行工作负载，并测量客户机响应时间、探测响应时间、CPU 利用率、磁盘写时间和磁盘利用率。Domino 配置我们使用四种集群/非集群配置设置了 Domino 服务器。在第一种配置（配置 1）中，我们使用一个没有集群的服务器：
图 1. 配置 1在下一个配置中（配置 2），我们将用户平均分配到两个服务器，同时也不使用集群。每个服务器向彼此发送所有邮件信息。
图 2. 配置 2第三种配置（配置 3）在一个集群中使用两个服务器。用户在其中一个服务器上，该服务器称为活动服务器。另一个服务器是备用 成员，因为它的唯一负载是集群复制。活动服务器不 向备用服务器传输邮件信息。 所有邮件都发送给活动服务器上的用户，因此所有消息都是本地发送的。活动服务器将所有数据库复制到备用服务器。（注意：尽管一般不在生产环境中使用这个配置，但这是一种有用的测试配置，因为您可以分别在发出集群复制的系统和接收系统上测量复制负载。当您了解某个负载之后，就更容易预测向第二个服务器添加另一个负载时会发生什么）。
图 3. 配置 3最后一种配置（配置 4）同样在一个集群中使用两个服务器，但这一次两个服务器都是活动的。用户在这两个服务器上。在第一个服务器上的用户向第二个服务器发送电子邮件，反之亦然，因此两个服务器彼此传输消息。另外，两个服务器都对数据库使用集群复制。
图 4. 配置 4关于测试第一个测试使用用户数为 100 的工作负载，分别运行前三个 Domino 集群/非集群配置。然后，我们在最后一个 Domino 集群配置中运行用户数不同的工作负载。用户数为 100 的测试帮助我们建立基线，用于预测在用户数不等的测试中的资源使用。要查看这些测试的结果，请阅读侧栏 “”。
注意：我们使用 100 个用户作为基线，因为我们的系统受磁盘 I/O 限制。当使用更多用户时，磁盘 I/O 限制会导致结果不连贯。在 R5 集群测试中，我们使用更加适合的系统，这在本系列的
中讨论。总体而言，我们的测试结果表明，对于更新频繁的工作负载，CPU 和磁盘使用增长比较显著。另外，响应时间随着用户数的增加而延长。（响应时间几乎是最重要的性能度量指标，因为它测量服务器对用户的响应速度。如果用户经常要等待 1 秒钟以上，就认为服务器过于繁忙）。要查看完整的结论列表，请阅读本文后面的 “”。场景 2：多个 Cluster Replicator在这一场景中，我们针对不同数量的 Cluster Replicator 任务测量 CPU 和磁盘的利用率。通过这种方式，我们可以确定增加 replicator 对性能的影响。 推荐您使用与需要复制到的集群成员一样多的 Cluster Replicator。在场景 3（以及本系列的 ）中，您将更多地了解使用多个 Cluster Replicator 的实际好处。
Domino 配置要运行这个场景，我们使用上面的配置 4 中的集群配置，但在这里我们使用多个备用服务器，如下所示：
一个集群包含 3 个服务器 —— 1 个活动服务器和 2 个备用服务器
一个集群包含 5 个服务器 —— 1 个活动服务器和 4 个备用服务器
一个集群包含 6 个服务器 —— 1 个活动服务器和 5 个备用服务器注意，在每种配置中，都仅有一个活动服务器带有工作负载。活动服务器的负载将被复制到所有其他备用服务器。（对于活动服务器上的每个数据库，在每个备用服务器上都有它的一部副本）。 关于测试我们的测试使用 100 个用户的中型邮件用户工作负载，运行第三种集群配置。我们将 Cluster Replicator 任务数从 1 该至 N，其中 N
即备用服务器的数量。要查看这些测试的结果，请阅读侧栏 “”。 我们的测试结果总体上表明，使用多个 replicator 时 CPU 和磁盘利用率上升。这意味着如果您已经利用上所有 CPU 和磁盘资源，就不应该使用多个 Cluster Replicator。要查看完整的结论列表，请阅读本文后面的 “”。场景 3：更新副本时出现的并发性该场景和场景 2 一样，仍然测试改变 Cluster Replicator 任务数时 CPU 的利用率。我们对这 5 个服务器使用一样的集群配置 —— 一个活动服务器和 4 个备用服务器。同样，仅在活动服务器上具有工作负载。活动服务器的负载将被复制到所有其他备用服务器。我们的测试仍然使用中型的邮件用户工作负载，唯一不同的是我们将一条消息发送给活动服务器的 50 个用户。修改之后会给服务器带来较大的 “负载冲击”，这有利于测量完成最终复制所需的时间。我们将 Cluster Replicator 任务数从 1 改为 4，其中 4 是备用服务器的数量。要查看这次测试的结果，请阅读侧栏 “”。
我们的测试结果总体上表明，增加 Cluster Replicator 任务的数量可能增加更新副本时出现的并发性。在一个服务器上运行多个任务可以缩短时间延迟，即什么时候对该服务器上的数据库进行更新和什么时候将更改传播到多个备用服务器上的副本之间的差距。然而，如前所述，因为增加 Cluster Replicator 任务可能会增加 CPU 和磁盘负载，所以在服务器超载的情况下不要增加任务。要查看完整的结论列表，请阅读本文后面的 “”。
注意：您可以使用 Replica.Cluster.SecondsOnQueue.Avg 统计数据了解 Cluster Replicator 将更改传播到其他服务器所需的时间。您可以以此决定增加 Cluster Replicator 任务是否会减少更新其他服务器上的副本所需的时间。要更多地了解集群统计数据，请阅读 “ ”。
场景 4：通过实践解决集群性能问题最后一个场景源于 IBM Lotus Integration Center 与现实客户机的合作。该客户机有一个包含 3 个成员的集群，它遇到了性能问题。因此，在这个场景中，我们测试其配置并找到解决问题的办法。
为了运行这个场景，我们设置了一个具有 3 个服务器的 Domino 集群，其配置如下：
两个 IBM Netfinity 7000 with four 200MHz 1MB and 1GB RAM（服务器 1 和 2）
一个 IBM PC Server 704 with four 200MHz 1MB and 768MB RAM（服务器 3）
两个 IBM ServRAIDII，配置为 RAID5，BIOS 2.40（服务器 1 和 2）
一个 IBM ServRAIDI，配置为 RAID5，BIOS 2.27（服务器 3）
6 个 9GB 的驱动器，RAID5
一个 44GB 磁盘矩阵
8K stripe size RA-WT (write ahead/write-through) 缓存（C：用于 OS；D：用于实用程序；E：用于Scanmail 隔离；F：用于 Domino 文件和数据）
两个 IBM 10/100 EtherJet
网络：专用 100 兆线段
操作系统：Windows NT Server 4.0 SP3
Domino：Release 4.6.2a
Scanmail 病毒应用程序
ARCServe 备份这个集群有两个活动 Domino 服务器，仅在出现故障时将它们的邮件文件复制到一个备用服务器（没有负载平衡）。每个活动服务器（服务器 1 和 2）大约有 1450 个注册用户，备用服务器（服务器 3）大约有 2650 个集群副本数据库。下面的图详细描绘了集群配置：图 5. 集群配置关于我们的分析为了确定改进该场景的性能的最好方法，我们对硬件设置和 Domino 集群配置进行分析。
首先，我们发现服务器在 Windows NT 和 RAID 级别使用默认的设置。通过修改这些设置可以获得更好的性能。要了解更多信息，请看下一小节 “优化这个配置的推荐设置”。
然后，我们使用 Windows NT Performance Monitor 监控硬件，它能发现饱和磁盘 I/O 子系统。平均磁盘队列长度比矩阵中的物理驱动器的数量大（&6），这表明读和写正在等待磁盘完成。此外，平均地磁盘传输时间为 108ms，其范围应该在 10 至 30ms 之间。%Disk Time 反映了 100% 的利用率（75% 读和 25% 写）。每次传输的平均磁盘字节数为 12k。另外，两个网卡上的平均网络利用率都低于 10%。
接下来，我们通过从服务器收集统计数据和分析 NOTES.INI 设置来分析 Domino 配置。我们的结果表明大部分性能问题出现在服务器 1 上，然后影响到整个集群的性能。要查看统计数据的结果，请阅读侧栏 “”。
优化这个配置的推荐设置我们对服务器 1 和 3 进行以下更改，并看到了巨大的性能提升：
为 IBM ServRAID 适配器将 BIOS 和设备驱动器更新到 2.82 或更高版本
为所有集群服务器的 NOTES.INI 文件添加以下内容：SERVER_MAXSESSIONS=550
SERVER_SESSION_TIMEOUT=45 (minutes)
NSF_BUFFER_POOL_SIZE = 为了进一步优化该配置的性能，我们得出以下额外建议（注意，这些建议应用到该特定配置时还受到成本限制，因此可能不适用于所有情况）：
使用更强大的 CPU（比如 Netfinity 7000 M10）替换服务器 3 的 CPU。一般而言，应该在集群中使用相同级别的机器（即都为 Netfinity 7000 或 7000 M10）。
使用改进的 RAID1 (RAID 0+1) 而不是 RAID5。（在这里 RAID1 提供更好的性能）。
在服务器 1 和服务器 3 上，将磁盘 I/O 分散到不同的矩阵。对于操作系统和 Domino 数据目录，应该使用多个矩阵。
将所有组件的 BIOS 更新到最新版本
将 RAID 条带大小保持为 16k，带有匹配的格式化块大小
将 LOG.NSF 移动到另一个矩阵，以腾出磁盘 I/O，或关闭复制日志记录
将集群配置从活动-活动-故障转移修改为活动-活动-活动从硬件角度看，底线是磁盘子系统成为 Domino 系统的瓶颈。处理器能够处理当前的负载。适当地添加驱动器和重构矩阵能够大大改进硬件的性能。从 R4.6 集群测试得到的建议通过在 R4.6 上测试集群性能，我们得出以下建议。我们希望这些建议能够帮助您改善集群的性能。（本系列的
包含其他建议和观察数据）。
受到服务器工作负载的影响，集群向服务器增加的负载与磁盘读比率是成比例的。因为服务器和网络负载增加的大部分负载都是集群复制 造成的。当向数据库写入任何更改时就会导致集群复制，比如创建新的文档和发送新的邮件消息等。因此，您可以通过测量磁盘写来评估增加的负载。（要了解更多关于此的信息，请阅读本系列的 ）。
您不应该完全依赖 NOTES.INI 设置 SERVER_AVAILABILITY_THRESHOLD (SAT) 和 SERVER_TRANSINFO_NORMALIZE (STN) 来在集群成员之间实现负载平衡。Domino 仅在发生引发故障转移的事务时才在集群中重新分配工作负载，比如双击数据库图标。您应该经常手动地调整用户和数据库的分配，以确保负载的平均分配。（要了解更多关于此的信息，请查看本系列的 ）。
如果可能的话，您应该在非高峰期重新启动失败的服务器。因为失败服务器需要与正在运行的服务器同步，从而确保数据库是最新的。同步时进行的复制会给服务器带来很大的负载。当您重启服务器时，确保 NOTES.INI 设置 SERVER_MAXUSERS 为 0 —— 一直要保持到复制同步完数据库。在 Domino R5 中，Cluster Replicator 检测服务器重新连接到集群的速度快得多，通常在一两分钟内完成。如果您发现在 R4.x 环境中更新失败服务器出现延迟，那么不用担心以后会出现这种问题。
我们应该监控服务器统计数据（尤其是磁盘队列）以维护集群性能。客户端响应时间并不总能反映服务器已接近饱和，因为负载在服务器队列中得到缓冲。磁盘队列通常是受到最大影响的资源。在 Windows NT 上，磁盘队列长度是 I/O 饱和程度的最好指示器，并且它应该小于数据 RAID 集中的磁盘数减去 1。在 UNIX 上，%iowait（CPU 等待磁盘 I/O 的时间百分比）是 I/O 饱和程度的最好指示器，并且其平均值应该小于 25%。（注意：当在 AIX 上拥有一个以上的处理器时，要获得有效的 I/O 指示可能有困难）。例如，您应该使用 Windows NT Performance Monitor (PerfMon) 监控数据磁盘（RAID 集）。在 PerfMon 中，添加对象 “逻辑磁盘”、计数器 “磁盘队列”，并实例化数据磁盘。（要更多地了解 I/O 和 RAID，请阅读 “”）。
在添加更多的 Cluster Replicator 任务之前，要考虑服务器上的负载。您可以将 Cluster Replicator 的数量设置为与集群中需要复制到的服务器相等，这样可以改进并发性并加快复制。然而，多个 replicator 任务可能给服务器的 CPU 和磁盘增加负载。在服务器已经超载时再添加任务是不明智的。
对于每个集群数据库副本，与写磁盘操作相关的网络流量会加倍。如果有两个副本（复制到两个其他集群成员），与写磁盘操作相关的网络流量会是原来的 3 倍。如果网络 LAN 流量成为性能瓶颈，您可以通过 TCP/IP 添加一个独立的网内集群通信网络，仅用于集群通信。只要您有足够的 WAN 带宽处理复制流量，也可以实现跨 WAN 网络的集群。
延迟出现在特定的网络结构中，并且向 LAN 添加开销时会增加。开销是由多个跃点（hop）引起的。减少通过网关和路由器的网络路径（跃点）能够改善性能。此外，升级到更快的集线器也可以改善性能。对于以太-交换集线器尤其如此，在同一网络中性能可以提高至 3 倍。
最后，为了让终端用户获得最佳的性能，可以查找用户周边访问频率比较高的服务器。
在集群中使用最少数量的服务器来满足应用程序可用性需求，从而保持简单的集群结构。在很多情况下，使用包含两三个服务器的集群就可以了。它们能够高效工作，并且容易配置和管理。由 3 个成员组成的集群的优势是，当一个服务器出现故障时，还有两个服务器可以处理负载。如果集群的服务器超过两个，您应该仅维护数据库的一个副本（只要能够满足可用性需求）。多个副本会大大增加服务器的资源需求。将高级硬件容错功能和 Domino 集群与一个数据库副本结合就能满足大部分需求。然而，如果集群负载以读为主 —— 就像 Web 站点 Notes.net 一样 —— 可以使用多个集群成员。这是因为产生的复制流量很少。
确保正确地调整服务器的大小。如果没有适当地安排服务器的大小，当更新活动比较频繁时，集群复制维护数据库同步的能力就会受到限制。在个别情况下还会导致网络流量问题。
使用几乎完全相同的配置构建集群，并使用相同级别的机器。这样，当发生故障转移时，其他成员可以轻松地承担额外的负载（减少来自失败系统的复制流量）。
您不应该通过集群延长淘汰的、性能不佳的设备的寿命。集群中的开销要求您使用规格相当的设备。
添加或订阅评论，请先或。
有新评论时提醒我
static.content.url=http://www.ibm.com/developerworks/js/artrating/SITE_ID=10Zone=LotusArticleID=398640ArticleTitle=优化 Lotus Domino 服务器性能: Domino 集群，第 1 部分publish-date=