| 概述
本文中用于计算 MSIB 2.0 站点容量的方法被称为交易成本分析（TCA）。 如需了解对 TCA 过程更为深入的讨论，可以参见以下网址上的 Capacity Planning Using Transaction Cost Analysis Methodology ： http://go.microsoft.com/fwlink/?LinkId=9498。 本文假设：
如需了解关于 MSIB 2.0 及其相关组件以及其基准和企业部署方面的更多信息，可参见下面地址处的 MSIB Overview http://www.microsoft.com/china/technet/itsolutions/techguide/mso/msib/default.mspx. 本文分成三个部分论述。 下表介绍了这三个部分
执行摘要 根据本文所搜集的数据，对运行企业和基本部署的 MSIB 2.0 解决方案的性能和容量、可扩展性和可用性等方面可以得出以下几个结论： 性能和容量
可扩展性
可用性
第一部分——性能和容量规划 本部分包括：
MSIB 2.0 Web 站点是围绕着企业级内容易管理 Web 站点的概念设计的。 本站点是为那些希望利用类似功能创建站点的企业设计的快速上市的平台。 与大多数软件情况类似，该站点尚未得到完全优化，总有改进的余地。 您应当利用以下的性能计数器监控您的 MSIB 2.0 站点的性能。 关键性能的计数器 很多性能目标都是内置于 Microsoft Windows? 2000 操作系统及其他 Microsoft
应用程序和服务中的。 您利用性能计数器可以跟踪这些目标的性能。
如需了解关于性能计算器的更多信息，参见 Windows 2000 Server 帮助中的“性能目标和计数器”部分。 如需了解建议用于监控您的 ISA 服务器性能的性能计数器的信息，参见 http://go.microsoft.com/fwlink/?LinkId=14746。 交易成本分析 部分包括：
本部分介绍了 MSIB 项目组用以为 MSIB 2.0 站点计算交易成本分析 (TCA) 的在线使用概况、
MSIB 使用概况和站点概况。 要执行一个 MSIB 2.0 站点的 TCA ，您必须首先创建一个使用概况和站点概况。 然后您才能够利用
TCA 方法计算您的站点容量，这种方法将在本文后面的部分加以介绍。 编制使用概况的过程在“Commerce Server 2002
Creating a Usage Profile for Site Capacity Planning”中有详细介绍，地址在 http://go.microsoft.com/fwlink/?LinkId=9498。 在线概括描述了在线时 MSIB 2.0 站点的使用情况。 这一概括不包括 MSIB 2.0 站点离线时可能发生的任何操作。 下表列出了本文中 MSIB 项目组所用的在线使用概括。 峰值乘数用于计算与平均负载有关的系统的最大容量。 如果每秒钟的平均请求数量是 50 ，如果您的峰值乘数是 3 的话那么预期峰值将会是每秒钟 150 次请求。 为了对实施 MSIB 2.0 进行容量规划，您应当为系统的峰值容量做规划。
MSIB 使用概况 下表列出了本文中 MSIB 项目组测试的 MSIB 2.0 操作使用概况。 这些测试值是通过分析 Web 站点信息流量得到的。 注意以下方面： 其中 分布权重 一栏给出拉某类操作占总请求数的百分比。 其中 标准化 一栏表示分布百分比乘以前表给出的每用户每次访问请求数得到的结果。 注意这一栏合计达6。 其中 每个操作的请求数 一栏给出了执行某一操作所用的用户请求数量。 由于回帖或服务器重定向等原因，有些操作会产生多个
ASP.NET 请求。 MSIB 项目组为本文进行的测试中所用的目录数据库包含了四种语言编写的一百万条项目。 搜索页组是利用均匀分布方式在一万个项目的子集中挑选的。 UPM 数据库中包含了一百万个用户。 MSIB 项目组测试了一个有 100 条信道，每条信道 100 条记录的 MSIB 2.0 站点。 操作成本摘要 本部分列出了用户访问 MSIB 2.0 站点时可以执行的每种操作的典型核心成本。 这些成本是根据 MSIB 企业部署和基准部署计算的，这些部署中使用的软硬件配置如“附件 A -hardware and Network Topology Details”所述。 成本以 P4EM 描述，如本文前面部分“术语定义”所述。 注意，两种部署下的 SQL P4MC 是一样的。 下表给出的一些操作涉及到多个 ASP.NET 页面或 HTML 请求和发布。 每一种成本都表示系统运行在最佳吞吐量下，在这些测试中前端 Web 服务器的 CPU 利用率采用百分之 85，计算得到了这些成本。 为了进行数学分析，在后面的方程中将会把该表看成一个矩阵。
使用 TCA 方法进行容量规划 本节提供了为 MSIB 2.0 站点进行容量规划所用的数学计算方法。 您可以利用交易成本分析 (TCA) 方法将站点中的每项操作隔离开来，以便进行性能调节。 利用 TCA 方法您还可以利用不同的使用配置文件和类似的页面组计算 Web 站点的容量。 类似地，当您要改变 Web 站点的单个页面组的时候，您可以简单计量一下与单个页面组相关的新成本从而规划其容量。 每用户频率的操作 The 每用户频率的操作 如下表所示。 这个频率是根据定义的使用配置文件获得的统计结果。 每秒钟每位用户的操作次数 一栏给出了每位并发用户的操作频率、或请求比率。 每秒钟的请求频率 = 每个会话的请求数/会话的平均时间 其中 每个会话的请求数 来自于 每个会话的请求数 一栏，位于 MSIB 使用配置文件 表中，而 会话的平均时间 来自于 联机使用概况. 这样一来，对于 匿名主页 操作来说；
下一步是要将频率乘以 Web CPU 和SQL CPU 等硬件资源的成本。 例如，一项操作的 CPU 成本是： 每个用户每秒钟的操作成本 ( 单位：P4EM ) = 频率 * P4MC 成本 其中 频率 来自于 上表的每秒钟每位用户的操作次数 一栏，而 P4MC 成本 来自于 本文操作成本摘要部分中表格的 Web P4MC 栏。 columns of the table in the Operation Costs Summary section of this document. 这样一来，对于 匿名主页 操作来说； 0.004556 每秒钟每位用户的操作次数 * 11.54 P4MC = 0.05258 P4EM 这样就得到了每位并发用户如下的成本矩阵： 下一步是要根据 CPU 容量按照如下方式计算最大并发用户数： 一个系统的 CPU 容量 是用处理器数量乘以 CPU 的 MHz 定额得到的。 因此，对一台安装了两个 2 GHz 处理器的计算机来说； CPU 容量 = 2 x 2000 MHz = 4000 P4EM The 工作载荷下的系统目标 CPU 容量 通常由 IT 部门决定。如果没有这方面的标准可循，那么您应比照着平均的长期载荷对峰值载荷进行分析，据此决定这一目标值，确保 CPU 在100％容量以下运行。 假设一台计算机在 85％ 的容量下运行，那么应该按照如下方式计算其目标 CPU 容量： 目标 CPU 容量 = 4000 P4EM 的 CPU 容量x0.85=3400 P4EM 为了 根据目标 CPU 容量和总用户成本计算 Web 服务器的目标用户容量， 在前表中找到每位并发用户 Web CPU 的总成本（0.55000）。 然后将这一成本分成目标 CPU 容量。 目标用户容量 = 目标 CPU 容量 每个用户 Web CPU 总成本 Web CPU cost per user (基础 Web P4EM) = 3400/ 0.5500 = 6182 并发用户 服务机会 您应当把交易成本分析（TCA）和可用性规划看作是一种服务机会。 应当将本文祥述的步骤看作是用于管理
MSIB 2.0 站点可用性的最佳做法。 为了优化 MSIB 2.0 站点的性能，MSIB 开发组对以下内容做了调查：
分析 SQL 服务器 优化站点软件性能和可扩展性的第一步就是分析后端 SQL 服务器的使用情况。 MSIB 项目组为站点内的每个页面进行了一次 SQL Query Analyzer 追踪。 以下是免费文本搜索页面的输出结果： EventClass TextData CPU Reads Writes Duration SPID
StartTime 接下来， MSIB 项目组从磁盘读取的角度确定了最为昂贵的查询。 为了简化这些操作，MSIB 项目组尝试着降低查询操作的 I/O 复杂性。 例如，改变 Select * 语句，使其归入隔离更好的返回子集中。 最后，MSIB 项目组通过 SQL 服务器调节向导重放了记录下的跟踪结果。 该向导建议对表格索引进行一些变更。 所有这些页面级变更的组合降低了后端 SQL 服务器的负荷并因此改善了 MSIB 2.0 Web 站点的可扩展性。 在 SQL Server 服务器上，MSIB 项目组保留了与性能有关的所有默认配置。 使用高速缓存方案 提高吞吐量的下一步就是利用应用服务器中的高速缓存。 MSIB 项目组利用了以下的高速缓存方案以优化 MSIB 2.0 站点的性能。 页面输出高速缓存 Microsoft .NET Framework 系统内内置了页面输出高速缓存。 关于 MSIB 项目组如何使用这种功能的详细情况在 MSIB Developers Guide 中有所介绍，该资料随 MSIB 2.0 提供。 这种高速缓存方案对于未经个性化的页面是有效的，例如那些未用个性化内容对象（PCO）显示 Microsoft Content Management Server （MCMS）的页面。 MCMS 服务器的性能 Microsoft Content Management Server (MCMS) 2002 可以在纵横两个方向上进行扩展。 目前正在编写一份关于 MCMS 部署的文件，其中讨论了各种可用于 MCMS 的高速缓存方法。 在编写完成之后，可以从以下地址得到该文件 http://go.microsoft.com/fwlink/?LinkId=15170。如需了解关于 MCMS 2002 高速缓存的更多信息，参见 MCMS 2002 Help 中的“Optimizing MCMS Site Performance”。 如需了解关于利用 MCMS 2002 SCA 设置高速缓存属性的更多信息，参见 MCMS 2002 Help 中的“Specifying cache properties”部分。 如需了解 MCMS 性能的更多信息，参见 MCMS 主页，地址在 http://go.microsoft.com/fwlink/?LinkId=8426. 调节硬件 在进行性能分析的过程中，为 Web 服务器和 SQL 服务器选择正确的硬件发挥着非常重要的作用。 此外知道如何为这些服务器选择正确的硬件还能够让您为其他用户提供相关硬件的建议。 这一部分介绍了 MSIB 项目组是如何为本文所述的测试选择 SQL 服务器的。 Web 服务器 在为 Web 服务器选择硬件的时候， MSIB 项目组考虑了以下几个方面：
内存 MSIB 项目组为 Web 服务器配置了较大的随机存取存储器（RAM），所配容量超出了服务器运行任务所需的量。 为了确定服务器可以减少多少物理 RAM 内存，之后项目组计算了在工作负载下服务器的最大工作集。 一个典型部署所需的 RAM 数量取决于您为该部署对高速缓存和内存的需求。 不过，在大多数情况下，1GB 的物理 RAM 已经是足够的了。 磁盘子系统 MSIB 站点前端 Web 服务器的磁盘子系统作为一个只读设备，是用来存储自举分区和站点内容的。 这一子系统必需要有读/写设备才能进行文件分页操作，不过如果有足够的物理存储器支持系统的话，这些操作都是最低限度的要求了。 Web 服务器确实是利用磁盘子系统写事件日志和 Web 日志的。 这种操作已经由 Windows 2000 操作系统进行了很好的调节，很少需要超过一个内存芯片才能达到所需性能的。 网络系统 Web 服务器上的网络系统至少应当包括一块 100BaseT 的网卡。 要实现更高的安全性、可管理性和可用性，服务器应该配备两块甚至三块网卡。 在 MSIB 项目组的测试中，web 服务器的网路吞吐量并不足以用完一块 100 兆位的网卡能力。 CPU 最后，应当为服务器选用当前最好的 CPU 和处理子系统。 在可以预见到的将来，这个特别的硬件子系统仍将是该服务器的瓶颈。 这是因为动态 Web 页动态和过程全面的性质造成的。 确定适当的 CPU 数量是 Microsoft Server 每处理器许可计划的一项要求。 要确定这一需求，需要对您的 MSIB 2.0 站点进行一次 TCA 分析，在本文前面的“使用 TCA 方法进行容量规划”一部分对此做了介绍。 SQL 服务器 MSIB 项目组利用本部分介绍的指南建立起了 SQL 服务器，使之并未成为 MSIB 2.0 部署中的瓶颈。 在为 SQL 服务器选择硬件的时候， MSIB 项目组考虑了以下几个方面：
内存 大量的随机存取存储器（RAM）对于 SQL 服务器是有好处的，因此您应当依照数据库的工作集权衡 RAM 的数量。 在运行的时候测试网络的输入/输出 （I/O）。 SQL 服务器的处理负荷将是访问 SQL 服务器数据库的前端服务器数量以及负荷配置文件的正函数。 磁盘子系统 一般情况下， SQL 服务器最重要的调节选项就是安装物理磁盘子系统。 为了获得最佳性能，数据库应当与它们在不同物理驱动器上的业务处理记录分离开来。 您应当建立起所有的数据库、业务处理记录和 TempDB ，这样才不致让单个的磁盘子系统成为瓶颈。 在 MSIB 项目组的测试方案中，磁盘子系统并未成为一个问题。 不过，对于正在运行中的站点来说，您应当认真地将磁盘成本和交易联系起来考虑，以便为增加的磁盘需求做好规划。 数据库 MSIB 2.0 的设计使其可以进行横向扩展并为后端数据库系统分区。 用于营销、用户配置文件管理、目录、数据仓库、交易、内容和管理的数据库可以分离开来，放到物理 SQL 服务器数据库中。 这样一来您就能够轻松地按照数据库将部署系统分配到独立的服务器或群集上去。 关于如何做到这一点的详细介绍在随 MSIB 2.0 附带的 MSIB 2.0 部署指南中可以找到。 调节 IIS 为了进行本分析，MSIB 项目组对前端 web 服务器进行了最小限度的调节。 在默认 Web 站点的 Properties 页面的 Performance 选项卡上，性能调节块被改变为每天超过 100000 次命中的数值。 所有其他的设置都保持原状。 如果您必需要在测试站点或实际站点中改变任何参数的话，那么请每次只改变一个，然后将新的结果与旧结果加以比较。 重要事项： 对这些参数中的任何一个进行不适当的改变可能会给站点管理带来麻烦。 Web 群：MSIB 2.0 站点的扩展 如果所需的 CPU P4EM 比单台服务器所能提供的能力大，那么 Web 群将需要用到多台 Web 服务器。 出于可用性和可靠性的考虑，MSIB 项目组建议在任何部署中最少都要使用两台 Web 服务器。 第三部分 — MSIB 2.0 站点的可用性 有两个站点提供了全面的 Internet 性能和一般性能指导性原则，它们是www.mediametrix.com ，地址在 http://go.microsoft.com/fwlink/?LinkId=15045 和“http://Nielsen-netratings.com”，地址在 http://go.microsoft.com/fwlink/?LinkId=15043。 您可以按照不同级别的可用性部署 MSIB 2.0 解决方案。 应当在规划阶段中确定您的 MSIB 2.0 站点的可用性目标。 这一部分介绍了可用性，概述了可能会造成您的 MSIB 2.0 站点不可用的事件，提供了高可用性技术和建议，介绍了如何避免单点故障，并讨论了 MSIB 2.0 企业部署的恢复模型。 本部分包括： 什么是可用性？ 使站点不可用的三类事件 高可用性技术和建议 避免单点故障 MSIB 2.0 企业部署的恢复模型 确定预期的可用性 什么是可用性？
从上表可以看出，可接受运行时间为百分之 99.9 的系统平均每天只有 86.40 秒钟或每月只有 43 分钟是不可运行的。 要获得更多个九的可用性，必需要对系统部署、软件和解决方案实施的管理加以改进。 要预测一个系统何时甚至是隔多久会发生故障是非常困难的，因此要获得更好的可靠性，一个关键的规划方法是要缩短故障的恢复时间。 如果您的系统可以在 86.4 秒钟之内从故障中恢复过来，那么系统即使每天发生一次故障，仍然能够达到三个九的可用性。 从成功交易角度来看可用性 上述的可用性概念是作为运行时间的函数分析的，与此相反是将可用性作为成功交易的函数来分析可用性这个概念。 换句话说，如果某一个 Web 站点每天处理 100000 个请求，那么百分之 99.9 的可用性就意味着每天有 100 个请求是失败的。 如果您将此作为衡量可用性的标准，那么在业务规划中对可用性的要求就可能会发生变化。 例如，在一天之内一个 Web 站点的通信量是在改变的。 在凌晨两点的时候，您的站点每小时的访问次数可能还不到 100 。 如果您的站点在这期间发生故障，那么此时发生的失败请求数量大约要比下午 5 点时少四倍，那个时候是一天中的峰值时刻，每小时的访问次数为 400 次或更多。 使站点不可用的三类事件 人为错误 人为错误是最需要认真对待的一类事件。 在用户和正在工作的站点交互作用的时候，他们可能会执行某些对站点管理造成不良影响的操作。 因此，强烈建议对管理操作首先在专门测试环境中加以测试然后再编写脚本。 当新的管理操作第一次用于实际运行站点的时候，应当对其进行仔细监控，观察其对整个系统的影响。 认真的规划会有助于站点实现最高的可用性。 参见 MSIB Solutions Operations Guide 地址在 http://go.microsoft.com/fwlink/?LinkId=15047 ，其中介绍了可以减少人为错误的主意和最佳做法。 硬件故障 硬件故障可能会在任何时候发生。 这类故障包括环境故障，如天灾和火灾等。 在硬件实现的设计中将单点故障降到最低是降低这种风险的最安全方式。 在部署计划阶段中，MSIB 2.0 站点的实施人员应当编制一份硬件地图，给出存储器、网络和软件逻辑的所有连接点。 之后可以制定解决潜在单点故障的方案并进行成本和风险对比分析。 这方面可以有很多不同的解决方案，从自始至终对关键数据进行简单磁带备份到可以容灾的系统防护系统不一而足。 软件故障 软件故障是可能导致您的站点无法工作的第三类事件。 为了避免因软件故障造成总的功能损失，MSIB 2.0 使用了群集技术以提高可用性。 站点代码和基本部件的设计允许在发生临时故障的时候进行重试操作。 MSIB 2.0 解决方案中执行交易的部分利用了 Distributed Transaction Coordinator (DTC)、Microsoft Message Queue (MSMQ) 和交易以保证数据的完整性。 高可用性技术和建议 本部分包括： 用于高可用性的群集和负载均衡技术 旨在获得高可用性的软件建议 旨在获得高可用性的硬件建议 用于高可用性的群集和负载均衡技术 群集是指一组相互独立的计算机，它们共同合作运行公共的一套应用程序或服务，对客户端和应用程序来说像是单个系统一样。 群集计算机在物理上通过网线连接到一起，在程序上则通过群集软件连接到一起。 这些连接使得这些计算机可以使用单独的计算机无法使用的一些问题解决功能，例如负载均衡和故障切换等。 负载均衡功能将负载在所有配置的服务器之间分配，防止某一台服务器负载过度。 通过这种方式从而又让您能够逐步增大容量以满足自己的需求。 故障切换功能可以自动将资源从故障的或脱机的群集服务器上转移到正在运行的一台服务器上，从而为用户提供了恒定的支持。 这样用户就始终都可以访问 MSIB 站点的资源了。 目前，Windows Clustering 可以提供如下的群集和负载均衡技术：
网络负载均衡 网络负载均衡（NLB）技术可以把多达 32 台运行 Windows 2000 Advanced Server 组合到经负载均衡的单个群集中，从而可以提供基于 TCP/IP 的应用和服务的可扩展性和高可用性。 在本文测试的 MSIB 2.0 企业部署中，MSIB 项目组利用 NLB 技术将下表所列的服务器群集了起来。
在 Windows 2000 Advanced Server 中使用 Microsoft Cluster Service (MSCS) 您可以将两台服务器组合到一起作为一个服务器群集工作，确保客户端始终可以使用到任务关键性应用和资源。 服务器群集使得用户和管理员可以把它们作为一个单一的系统而不是独立的计算机，对服务器的某些资源或节点进行访问。 在 MSIB 2.0 的企业部署中，MSIB 项目组使用了可感知群集的 Commerce Server 2002 和 SQL Server 2000 的组件。 Content Management Server 2002 Microsoft Content Management Server （MCMS）2002 不支持群集和故障切换。 特别需要指出的是，MCMS 2002 的组件在故障切换时数据库连接断开的时候不会自动重试操作。 这样一来，在被动节点变为活动节点的过程中，指向启用了 MCMS 的页面的页面请求将会产生 ODBC 错误。 当系统处于 DEBUG 模式时，或者当浏览器会话是发起自正在与数据库断开连接的 Web 服务器时，这些错误只会返回到客户端的浏览器上。 注: 这些错误只是在 MCMS 站点的页面请求失败的时候发生。 Commerce Server 2002 关于如何群集每个 Microsoft Commerce Server 2002 组件的详细介绍可以在 Planning for Reliability and High Availability 中找到，地址在 http://go.microsoft.com/fwlink/?LinkId=15044。 SQL Server SQL Server 为 MSIB 解决方案主管运行数据库、管理数据库和数据仓库。 另外，SQL Server 2000 还为报告和分析solution 提供了联机分析处理（OLAP）引擎。 MSIB 2.0 解决方案中所有的服务器产品都要与一台群集 SQL 服务器一起工作，因此在 MSIB 2.0 的企业部署中， MSIB 项目组实施了一个两节点的群集。 如需了解群集选项和故障切换群集方面的详细信息，参见 SQL Server 2000 Resource Kit 中的第 12 章。 MSIB 项目组为本文实施的群集选项在 MSIB 2.0 随带的 MSIB Deployment Guide 中有详细介绍。 组件负载均衡 Microsoft Application Center 可以提供组件负载均衡（CLB）技术，供管理员创建一个服务器群集，对组件请求做出响应。 为了实现高可用性，MSIB 项目组未配置的组件 出于编写本文的考虑， MSIB 项目组决定以单点故障（SPOF）配置实施本部分前面所述的几个软件组件。 这只不过是一个设计决策，并不能反映出使用 CLB 部署的组件能力。 在 MSIB 2.0 解决方案中，有多个 Microsoft Operations Manager Consolidator /Agent Manager 未被 MSIB 实施。 关于如何添加这项功能的详细介绍可以在 Configuring Microsoft Operations Manager 2000 to Manage Complex Distributed Environments 一文中找到，地址在 http://go.microsoft.com/fwlink/?LinkId=15101. 此外，MSIB 项目组还没有在一个高度可用的环境中实施 Commerce Server 2002 Direct Mailer 。 关于如何安装这项功能的详细介绍可以在 Planning for Reliability and High Availability 一文中找到，地址在 http://go.microsoft.com/fwlink/?LinkId=15102. OLAP 解决方案同样未被 MSIB 项目组以一种高度可用的方式加以安装。 如需了解关于如何实现 OLAP 解决方案高可用性的方面的信息，参见 Creating Large-Scale ， Highly Available OLAP Sites 一文， http://go.microsoft.com/fwlink/?LinkId=15103. 旨在获得高可用性的软件建议 建议您在运行 IIS 5.0 的 Web 服务器上使用以下软件将资源消耗问题降到最低程度，以免这些问题影响到您的 MSIB 2.0 部署的性能和可用性。 IIS5Recycle IIS 5.0 Process Recycling Tool，IIS5Recycle 是作为一项服务运行在运行着 Windows 2000 和 Internet Information Services (IIS) 5.0 的计算机上的。 IIS5Recycle 的目的是要重复利用过程，在资源消耗问题影响到性能和可靠性之前将其影响降到最小程度。 这一工具可以根据存储在 Windows 注册表中的配置对 IIS 过程进行重复利用。 管理员还可以利用 IIS5Recycle 收集信息以便在排除故障过程和应用中使用。 在重复利用 IIS 过程之前， IIS5Recycle 会在启用了 Windows Network Load Balancing （NLB）的系统中从群集（Web 群）中将 Web 服务器删除掉。 每次把某一服务器从群集中删除的时候，到这个 Web 服务器的连接也将会断掉。 一旦连接号降至配置的阈值之下或已经达到了给定的时间， IIS 服务就得到了循环利用。 如需下载该工具及其随带的文档，可参见 http://go.microsoft.com/fwlink/?LinkId=15077。 旨在获得高可用性的硬件建议 MSIB 项目组为本文所用的 MSIB 2.0 企业部署方案中包括了以下旨在实现高可用性的硬件建议。 存储系统 部署中所用的每台服务器都有其相应的存储需求。 为了消除单点故障，MSIB 项目组部署了一个存储区域网（SAN）。 该 SAN 单元本身带有冗余的驱动器、控制器和电源。 SAN 甚至还可以通过与另一个数据中心之间的远程光纤连接将自身复制一份。 可以通过冗余的主机总线适配卡实现 SAN 的连接，这样适配卡本身就不会成为一种单点故障了。 网络系统 网络可以具备几个层次的冗余。 对非冗余服务器中的每块网络接口卡（NIC）都进行 分组目的是为了防止 NIC 本身成为一种单点故障（SPOF）。 在本文后面的部分中对单点故障以及如何避免的问题进行了讨论。 为了避免因单个路由器故障造成的网络停用，您可以部署冗余的路由器。 还可以在设计上使路由器最少有两个到外部网络，即 Internet 的连接。 这种层次上的设置不在 MSIB 2.0 版本介绍范围之内。 服务器系统 如本文前面部分所述，为了实现高可用性，MSIB 项目组使用 NLB 和 Microsoft Cluster Service （MSCS）以群集的方式部署了物理服务器。 避免单点故障 以下这些方面是 MSIB 2.0 部署中常见的故障点：
下表所列的技术可以用来在您的 MSIB 2.0 部署中提供高可用性，并且介绍了它们能够解决哪些故障点。 这些高可用性技术可以解决本文前面介绍的问题。 建议您在部署 MSIB 2.0 site 站点的时候在较宽基础结构的层次上（如附录A“Hardware and Network Topology Details”给出的企业部署）采用这些技术。 在您的部署中遇到的单点故障越少，这种部署就更加具有高可用性。
这一节详细介绍了 MSIB 2.0 企业部署中典型的易出故障的点（如前表所列）并为避免这些故障提出了建议。 网络 网络是将所有的服务器、内联网、Internet 和用户连接到一起的结构。 没有网络连接的话，整个系统都会瘫痪。 网络故障可能会由网络硬件故障、套接字故障或远程过程调用（RPC）连接造成的。 网络硬件故障 网络故障的主要原因有：
建议采用的解决方案 建议采用的高可用性解决方案如下：
套接字故障 许多可感知网络的应用程序都是利用传输控制协议（TCP）或用户数据报协议（UDP）的套接字与运行在多个服务器之间的应用程序相互通信的。 要实现 Windows 2000 高可用性所需的通信协议为 TCP/IP 。 连接是利用 TCP 或 UDP 模式的套接字建立起来的。 TCP 套接字是一种状态连接，用于需要数据的决定性定购和保证交付的情形（例如 SQL 查询和 HTTP 查询等）。 UDP 套接字是一种无状态连接，用于定购和交付保证不是非常重要的情况下（如音频流等）。 TCP 套接字是由 MSIB 2.0 所依赖的下列软件使用的：
以下的 MSIB 2.0 特性利用了 TCP 套接字：
UDP 套接字由 Commerce Server 2002 所依赖的以下软件使用：
TCP/IP 套接字可能会因如下原因发生故障：
建议采用的解决方案 建议采用两种 Windows 2000 高可用性解决方案：
远程过程调用（RPC）连接故障 RPC 连接是由访问如下内容的应用程序使用的：
以下的 MSIB 依赖项可能会用到 RPC 连接：
RPC 连接可能会因为以下因素发生故障：
建议采用的解决方案 建议采用两种 Windows 2000 高可用性解决方案：
在故障切换期间，一个访问群集远程文件系统服务器的应用必需要执行如下的操作：
在故障切换期间，正在访问远程 COM+ 服务器（或 MSCS 或 CLB 群集）的应用程序必需要执行如下操作：
服务器硬件 应用程序、中间层和数据库层都运行在物理服务器上。 尽管 Windows 平台可以使用容错系统，不过这些容错系统往往比较昂贵，而且难以适应大范围的商品市场。 因硬件故障导致的服务器故障有如下几种方式：
在每种情况下，任何一个底层服务器组件的故障都会导致整个服务器的故障。 建议采用的解决方案 为实现服务器硬件的高可用性，建议采用如下的 Windows 2000 解决方案：
磁盘 磁盘子系统是由 MSIB 2.0 下列的依赖项使用的：
文件/磁盘子系统可能会因为如下原因发生故障：
建议采用的解决方案 在磁盘子系统这一个级别上，建议您使用以下技术中的一个或多个以确保实现高可用性：
不过，一旦基础设施级别上的容错功能未能保护子系统，这种故障就会以文件丢失、目录丢失或驱动器句柄的形式反映在操作系统（OS）级别上，引起对文件/磁盘子系统资源的后续访问失败。 如需了解关于 RAID 的更多信息，请在 Windows 2000 Help 中搜索 RAID 。 应用程序 Commerce Server 和 ISA 等应用程序都是由 MSIB 2.0 用以执行该解决方案所需的综合软件功能的。 由于应用程序是运行在平台操作系统（OS）顶部的，因此存在很多引起故障的原因，包括：
建议采用的解决方案 建议采用两种 Windows 2000 高可用性解决方案：
数据库 SQL Server 2000 由 MSIB 2.0 及其依赖项用于连接到数据库上。 由于数据库服务器是运行在平台操作系统和服务顶部的，因此存在很多引起故障的原因，包括：
建议采用的解决方案 建议采用两种 Windows 2000 高可用性解决方案：
类似地，如果现有的计算机出现了硬件资源的瓶颈，那么您应当为 Web 群添加后端 SQL 服务器。
在添加了更多 SQL 服务器之后，构成 MSIB 2.0 解决方案的数据库应当在 SQL 服务器中分离开来。
服务器故障切换恢复 前面的部分讨论了如何利用网络负载均衡（NLB）和 Microsoft Cluster Service （MSCS）消除单点故障。 这一部分的目的是要介绍，当您在企业部署种使用了 NLB 和MSCS 时，MSIB 2.0 是如何从故障种恢复过来的。 ISA 故障切换 在 ISA 服务器因服务器故障而出现故障的时候， NLB 软件(运行在 ISA 服务器之上)将会把故障服务器从 NLB 群集中删除掉。 在 ISA 服务器因连接、RPC 或磁盘故障而出现故障的时候，ISA 服务器会将自己从群集中脱离开。 最后的结果是，仍然正常的冗余服务器将会把所有的请求接管过来。
当某一表示层服务器不能发送或响应心跳消息的时候，其他服务器将会进行收敛。 最后的结果是，仍然可对请求作出响应的表示服务器会为故障服务器处理所有的入站请求。 当某台新的表示服务器试图加入到该群集的时候，它将会发出一个意在收敛的心跳消息。 当所有的表示服务器都同意接受该成员的时候，将会对客户端的工作量重新划分。
SQL Server MSCS 数据库故障切换 SQL Server 使用了一套共享的磁盘子系统，它可以以一个群集服务器的形式工作。 当群集中的某活动 SQL 服务器出现故障的时候，备用的 SQL 服务器将会接管故障服务器的负载，处理客户请求，从同一共享盘上读取和写数据，如下图所示。
在这一模型中需要考虑五个 MSIB 2.0 企业部署的群集。 这五个群集都是由两个节点/计算机构成的，它们必需能够正常运行，令那些考虑要可用的系统真正可用。 出于这一分析的考虑，群集列举如下： 1.面向 Internet 的防火墙 NLB 群集 每个群集都有一个可用性，p n 其中，0n <=1。 整个系统的可用性由以下的计算得到： p1 X p2 X p3 X p4 X p5 群集内每个节点的可用性可以通过带入以下三个数值的平均测量值得到。
MSIB 项目组首先切断活动-活动群集中来自服务器/节点的基本网络连接，然后再重新启用这些连接，通过这种方法测量了企业部署的恢复时间和故障切换时间。 对于活动——被动 SQL 群集，项目组从群集管理控制台执行了一个移动组命令。 如需了解关于如何测定恢复时间和故障切换时间的更多信息，参见“附件 C——Collecting Availability Data”。 请注意由 MSIB 项目组为本文所述测试部署的系统是按照 MSIB 2.0 随带的 MSIB 2.0 Deployment Guides 中所述的严格的设置和配置进行部署的。 顶级 ISA NLB 群集 顶级 ISA 网络负载均衡（NLB）群集是一种双节点的 NLB Web 服务器群集。 这一系统的可用性是根据服务器群集可用性的马尔可夫模型（MMASC）计算的。 这一实例是根据 Microsoft Technical Report 中的Markov Model of Availability for Server Clusters 中的数学模型给出的，地址在 http://go.microsoft.com/fwlink/?LinkId=15127对这一群集来说，MSIB 项目组发现其平均故障切换时间为 3 分钟，MTTR 时间为 9 分钟 56 秒。 下表给出了根据搜集到的数据和节点的目标 MTTF 为一个活动-活动 2 节点群集计算得到的可用性。 MTTF 仍然无法轻松测到，因此该表给出了在目标 MTTF 处的可用性。
下表给出了在 MTTF 为 30 天的条件下，计算得到的活动-活动 2 节点群集的可用性。
注: 前面的两张表格给出了一个节点和两个节点情况下的故障切换实例。 对于以单个节点而非一个群集的形式运行的服务器来说，预计其 MTTF 大约为 2节点活动-活动群集的一半。 Web NLB 群集 顶级 Web 服务器 NLB 群集是一种双节点的 NLB 服务器群集。 这种系统的可用性是根据 MMASC 计算的。 对这一层来说，MSIB 项目组发现其平均故障切换时间为 15 分钟，MTTR 时间为 9 分钟 2 秒。 下表给出了两个不同的 MTTF ，并展示了 MTTF 数值是如何影响节点的总体可用性的。 下表给出了根据搜集到的数据，改变节点的 MTTF ，为一个活动-活动 2 节点群集计算得到的可用性。 MTTF 仍然无法轻松测到，因此该表给出了在目标 MTTF 处的可用性。
下表给出了在 MTTF 为 30 天的条件下，计算得到的活动-活动 2 节点群集的可用性。 注: 前面的两张表格给出了一个节点和两个节点情况下的故障切换实例。 对于以单个节点而非一个群集的形式运行的服务器来说，预计其 MTTF 大约为 2节点活动-活动群集的一半。 搜索 NLB 群集 顶级 搜索 NLB 群集也是一种双节点的 NLB 服务器群集。 这种系统的可用性是根据 MMASC 计算的。 对这一层来说，MSIB 项目组发现其平均故障切换时间为 15 秒钟，MTTR 时间为 4 分钟 56 秒。 下表给出了两个不同的 MTTF ，并展示了 MTTF 数值是如何影响节点的总体可用性的。 下表给出了根据搜集到的数据，改变节点的 MTTF ，为一个活动-活动 2 节点群集计算得到的可用性。 MTTF 仍然无法轻松测到，因此该表给出了在目标 MTTF 处的可用性。
下表给出了在 MTTF 为 30 天的条件下，计算得到的活动-活动 2 节点群集的可用性。 注: 前面的两张表格给出了一个节点和两个节点情况下的故障切换实例。 对于以单个节点而非一个群集的形式运行的服务器来说，预计其 MTTF 大约为 2节点活动-活动群集的一半。 中级 ISA NLB 群集 中级 ISA 网络负载均衡（NLB）群集是一种双节点的 NLB 服务器群集。 这种系统的可用性是根据 MMASC 计算的。 MSIB 项目组发现，这一层的平均故障切换时间为三分钟，故障服务器重新加入群集需要六分钟三十六秒的时间。 下表给出了两个不同的 MTTF ，并展示了 MTTF 数值是如何影响节点的总体可用性的。 下表给出了根据搜集到的数据，改变节点的 MTTF ，为一个活动-活动 2 节点群集计算得到的可用性。 MTTF 仍然无法轻松测到，因此该表给出了在目标 MTTF 处的可用性。
下表给出了在 MTTF 为 30 天的条件下，计算得到的活动-活动 2 节点群集的可用性。 注: 前面的两张表格给出了一个节点和两个节点情况下的故障切换实例。 对于以单个节点而非一个群集的形式运行的服务器来说，预计其 MTTF 大约为 2 节点活动-活动群集的一半。 SQL Server 群集 顶级 SQL 服务器 是一种双节点的活动——被动 MSCS 群集。 这种系统的可用性是根据 MMASC 计算的。 注: 前面两张表格是和介绍活动-活动群集的表格不同的，这是因为当群集某一成员发生故障的时候，活动——被动群集不能进行更多的工作。 这样一来，最后一个节点进行故障切换的 MTTF 就等于前一个活动节点的值。 MSIB 项目组发现，这一层的平均故障切换时间为五分钟，故障服务器重新加入群集需要八分钟三十秒的时间。 下表展示了 MTTF 数值是如何影响群集的总体可用性的。
下表给出了在目标平均时间为 30 天的条件下，计算得到的活动-活动 2 节点群集的可用性。
使用 MMASC 方法，此 2 节点活动——被动群集计算得到的可用性为 99.9884% 整体可用性 如前所述，整个集成系统的可用性为以下计算的结果： p1 X p2 X p3 X p4 X p5 对每个节点都以 MTTF 为一星期和一个月为条件进行计算。 利用这个方程， IT 专业人员可以建立起每个节点的目标 MTTF ，从而实现可测量的整系统可用性。 这样一来您就能够掌握主动，决定目标 MTTF 是多少，而不是必需要猜测为了满足正常运行时间标准系统出现故障之后 MTTF 将会是多少。 这一分析确切地给出了要实现整系统可用性服务水平协议的要求哪些节点必需要加以改进。 下表总结了如本部分前面所述使用了同样的 MTTF 向量的系统的整体可用性。
Web 服务器 CPU: 2 x 1.4-GHz Pentium 4 搜索服务器 CPU: 2 x 1.4-GHz Pentium 4 SQL server CPU: 4 x 1.4 GHz Pentium 4 ISA 服务器 CPU: 2 x 550-MHz Pentium III 文件名 用于 附录 C — 搜集可用性数据
从 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 在美国和/或其他国家的注册商标或商标。 |
