性能和容量规划（3）

中级 ISA NLB 群集

中级 ISA 网络负载均衡（NLB）群集是一种双节点的 NLB 服务器群集。 这种系统的可用性是根据 MMASC 计算的。 MSIB 项目组发现，这一层的平均故障切换时间为三分钟，故障服务器重新加入群集需要六分钟三十六秒的时间。 下表给出了两个不同的 MTTF ，并展示了 MTTF 数值是如何影响节点的总体可用性的。

下表给出了根据搜集到的数据，改变节点的 MTTF ，为一个活动-活动 2 节点群集计算得到的可用性。 MTTF 仍然无法轻松测到，因此该表给出了在目标 MTTF 处的可用性。

使用 MMASC 方法，此 2 节点活动-活动群集计算得到的可用性为 99.9197%

下表给出了在 MTTF 为 30 天的条件下，计算得到的活动-活动 2 节点群集的可用性。

使用 MMASC 方法，此 2 节点活动-活动群集计算得到的可用性为 99.9813%

注: 前面的两张表格给出了一个节点和两个节点情况下的故障切换实例。 对于以单个节点而非一个群集的形式运行的服务器来说，预计其 MTTF 大约为 2 节点活动-活动群集的一半。

SQL Server 群集

顶级 SQL 服务器 是一种双节点的活动——被动 MSCS 群集。 这种系统的可用性是根据 MMASC 计算的。

注: 前面两张表格是和介绍活动-活动群集的表格不同的，这是因为当群集某一成员发生故障的时候，活动——被动群集不能进行更多的工作。 这样一来，最后一个节点进行故障切换的 MTTF 就等于前一个活动节点的值。

MSIB 项目组发现，这一层的平均故障切换时间为五分钟，故障服务器重新加入群集需要八分钟三十秒的时间。

下表展示了 MTTF 数值是如何影响群集的总体可用性的。

使用 MMASC 方法，此 2 节点活动——被动群集计算得到的可用性为 99.9504%

下表给出了在目标平均时间为 30 天的条件下，计算得到的活动-活动 2 节点群集的可用性。

使用 MMASC 方法，此 2 节点活动——被动群集计算得到的可用性为 99.9884%

整体可用性

如前所述，整个集成系统的可用性为以下计算的结果：

p₁ X p₂ X p₃ X p₄ X p₅

对每个节点都以 MTTF 为一星期和一个月为条件进行计算。 利用这个方程， IT 专业人员可以建立起每个节点的目标 MTTF ，从而实现可测量的整系统可用性。 这样一来您就能够掌握主动，决定目标 MTTF 是多少，而不是必需要猜测为了满足正常运行时间标准系统出现故障之后 MTTF 将会是多少。 这一分析确切地给出了要实现整系统可用性服务水平协议的要求哪些节点必需要加以改进。

下表总结了如本部分前面所述使用了同样的 MTTF 向量的系统的整体可用性。

返回页首

附录 A ——硬件和网络拓扑详述

这一部分介绍了在进行本文所述的测试过程中 MSIB 项目组所用的硬件和网络拓扑。 下图给出了 MSIB 2.0 基础部署的网络图。

下图给出了 MSIB 2.0 企业部署的网络图。

查看完整的图像。

这一部分介绍了在进行本文所述的测试过程中 MSIB 项目组所用的 Web 服务器的配置。

Web 服务器

这一部分介绍了在进行本文所述的测试过程中 MSIB 项目组所用的搜索服务器的配置。

搜索服务器

这一部分介绍了在进行本文所述的测试过程中 MSIB 项目组所用的 SQL Server 的配置。

SQL server

这一部分介绍了在进行本文所述的测试过程中 MSIB 项目组所用的 ISA 服务器的配置。

ISA 服务器

返回页首

附录 B——许可计算

下表给出了 MSIB 项目组创建的两个电子数据表。 以后可以从与本文所在的同一 Web 页面上获得这些表格。

返回页首

附录 C — 搜集可用性数据

当两台服务器利用网络负载均衡（NLB）工作在活动-活动群集的模式下时，这对服务器的系统吞吐量情况将会和下图类似。

查看完整的图像。

X轴上标出了 4 个点，它们代表了与 NLB 故障切换和恢复过程有关的事件。

从 0：00 到第一个标识点（0:10），群集处于正常运行状态，服务器 1 和服务器 2 分担着同样的负载或吞吐量。到了这一刻，服务器 1 出现故障，无法工作了。

从 0:10 到 0:26 ，到服务器 1 的所有请求都丢失了，这是因为群集还没有发现服务器 1 出现故障了。 在这期间，群集是以不到一半的容量运行的。

在 0:26 秒的时候，群集发现了服务器 1 的故障，服务器 2 开始处理其请求。 此时服务器 2 是在两倍的负荷工作的，不过仍然在其限额之内。

1:01 (图中标注的第三个点）时，服务器 1 重新设定了 W3 SVC 服务，这一过程大约需要一分钟的时间。

2:00 （图中标注的第四个点）时，服务器 1 恢复过来并通过收敛过程重新加入到 NLB 群集中来。

在做可用性分析的时候，为了测量群集的恢复时间和故障切换时间，您需要监控两个时间间隔长度：

为了测量 MTTR ，您应当具备管理软件或警告软件，以检测故障并完成故障恢复过程。 对 MSIB 来说，建议您利用 Microsoft Operations Manager （MOM）实现错误发现和解决的自动化。 如果您没有用以自动检测和故障恢复的解决方案，您应当将解决 IT 问题的平均时间作为 MTTR 。

本文中的信息，包括 URL 及其他 Internet Web 站点的引用，如有更改恕不另行通知。 除非另外指明，在本文例中提到的公司、单位、产品、域名、e-mail 地址、徽标、人员、地点和事件等都是虚构的，不与任何真实的公司、单位、产品、域名、e-mail地址、徽标、人员、地点和事件发生任何联系，也不应从中做任何此类联系方面的推断。 用户有责任遵守所有适用的版权法律。 在不限制版权所赋予权利的前提下，没有 Microsoft Corporation 明确的书面允许，不得以任何形式或通过任何手段（电子的、机械的、影印、录制或其他）或出于任何目的复制本文的任何部分或将其存储或引入检索系统，或进行传播。

Microsoft 可能具有一些专利、专利申请、商标、版权或其他知识产权涉及到本文所述主题。 除非微软公司通过书面许可协议明确提供，此文档并没有授予您对这些专利，商标，版权或其他知识产权的任何许可。

© 1996-2003 Microsoft Corporation 。 保留所有权利。

Microsoft 、Active Directory、MS-DOS、Windows、Windows NT 和 SharePoint 为 Microsoft Corporation 在美国和/或其他国家的注册商标或商标。

本文提到的实际公司和产品的名称可能是其相应所有者的商标。