性能和容量规划（2）
第二部分——MSIB 2.0 站点的性能和可扩展性
这一部分简单介绍了 MSIB 项目组在实现站点代码和实际 MSIB 2.0 部署所需的吞吐量和可扩展性需求时所采用的步骤。 这一部分并不介绍 ASP.NET 编码做法、Microsoft Internet Information Services (IIS) 5.0 调节参数或 SQL 服务器的调节参数。
为了优化 MSIB 2.0 站点的性能，MSIB 开发组对以下内容做了调查：
| • |
分析 SQL 服务器 |
| • |
使用高速缓存方案 |
| • |
调节硬件 |
| • |
调节 IIS |
| • |
横向扩展 Web 群 |
分析 SQL 服务器
优化站点软件性能和可扩展性的第一步就是分析后端 SQL 服务器的使用情况。 MSIB 项目组为站点内的每个页面进行了一次 SQL Query Analyzer 追踪。 以下是免费文本搜索页面的输出结果：
EventClass TextData CPU Reads Writes Duration SPID StartTime
SQL:BatchCompleted SET NO_BROWSETABLE ON 0 0 0 0 52 2000-12-05
11:07:16.513
SQL:BatchCompleted select * from CatalogGlobal where [CatalogName] =
N'ANVIL0' 0 2 0 0 52 2000-12-05 11:07:16.513
SQL:BatchCompleted SET NO_BROWSETABLE ON 0 0 0 0 52 2000-12-05
11:07:16.513
SQL:BatchCompleted SELECT A.* FROM CatalogAttributes A, syscolumns S
WHERE S.id = OBJECT_ID('ANVIL0_CatalogProducts') AND A.propertyname =
S.name ORDER BY A.PropertyName 15 55 0 16 52 2000-12-05 11:07:16.513
SQL:BatchCompleted EXEC sp_GetResults_for_AllColumns N'ANVIL0', N'*',
N'FREETEXT (*, N''testasdf'' )', '', 1,11,1,39 32 1147 0 76 52 2000-12-
05 11:07:16.530
SQL:BatchCompleted EXEC sp_CheckCatalog '*', 'ANVIL0', 'FREETEXT (*,
N''testasdf'' )' 0 29 0 0 52 2000-12-05 11:07:16.607
MSIB 项目组的第一项查询优化措施就是在追踪分析过程中发现的。 MSIB 项目组在页面上查找重复的查询并减少冗余的 Select 语句。 MSIB 项目组很好地跟踪了目标的信息并对代码重新排序，使得查询操作只能进行由条件调用，从而完成了这一步骤。
接下来， 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 项目组考虑了以下几个方面：
| • |
内存 |
| • |
磁盘子系统 |
| • |
网络系统 |
| • |
CPU |
内存
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 站点的可用性
可用性规划和可扩展性规划是非常类似的两项工作。 可用性规划的第一步就是要确定您的业务需求。 作为一项指导，建议您重新审查一下您现有站点的行为，然后将您的站点与竞争对手们的站点加以比较。 如需获得各个竞争对手的可用性和页面等待时间等信息的列表，参见 http://www.keynote.com，地址在 http://go.microsoft.com/fwlink/?LinkId=15046。
有两个站点提供了全面的 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 企业部署的恢复模型
确定预期的可用性
什么是可用性？
本文中使用了可用性的定义，因为它是 Internet 站点涉及到的一个概念。 可用性包括可靠性、故障恢复和故障几个方面。 最常用的可用性计量标准之一就是“九的个数”。“这一数字可以转换为某一系统可正常工作的时间百分比。 例如，一个运行时间百分比为 99.999 的系统可以说成其可用性为五个九。 下表给出了九的个数和时间之间的对应关系。
| 可接受的运行时间百分比 | 每天的停机时间 | 每月的停机时间 | 每年的停机时间 |
|
95 |
72.00 分钟 |
36 小时 |
18.26 天 |
|
99 |
14.40 分钟 |
7 小时 |
3.65 天 |
|
99.9 |
86.40 秒钟 |
43 分钟 |
8.77 小时 |
|
99.99 |
8.64 秒钟 |
4 分钟 |
52.60 分钟 |
|
99.999 |
0.86 秒钟 |
26 秒钟 |
5.26 分钟 |
从运行时间的角度来看可用性
从上表可以看出，可接受运行时间为百分之 99.9 的系统平均每天只有 86.40 秒钟或每月只有 43 分钟是不可运行的。 要获得更多个九的可用性，必需要对系统部署、软件和解决方案实施的管理加以改进。 要预测一个系统何时甚至是隔多久会发生故障是非常困难的，因此要获得更好的可靠性，一个关键的规划方法是要缩短故障的恢复时间。 如果您的系统可以在 86.4 秒钟之内从故障中恢复过来，那么系统即使每天发生一次故障，仍然能够达到三个九的可用性。
从成功交易角度来看可用性
上述的可用性概念是作为运行时间的函数分析的，与此相反是将可用性作为成功交易的函数来分析可用性这个概念。 换句话说，如果某一个 Web 站点每天处理 100000 个请求，那么百分之 99.9 的可用性就意味着每天有 100 个请求是失败的。 如果您将此作为衡量可用性的标准，那么在业务规划中对可用性的要求就可能会发生变化。 例如，在一天之内一个 Web 站点的通信量是在改变的。 在凌晨两点的时候，您的站点每小时的访问次数可能还不到 100 。 如果您的站点在这期间发生故障，那么此时发生的失败请求数量大约要比下午 5 点时少四倍，那个时候是一天中的峰值时刻，每小时的访问次数为 400 次或更多。
使站点不可用的三类事件
有三类时间可能会造成您的 MSIB 2.0 站点无法工作，从而造成其不可用：人为错误、硬件故障和软件故障。如果规划不当的话，这些事件中的任何一个都可能会使站点的目标可用性无法实现。
人为错误
人为错误是最需要认真对待的一类事件。 在用户和正在工作的站点交互作用的时候，他们可能会执行某些对站点管理造成不良影响的操作。 因此，强烈建议对管理操作首先在专门测试环境中加以测试然后再编写脚本。 当新的管理操作第一次用于实际运行站点的时候，应当对其进行仔细监控，观察其对整个系统的影响。 认真的规划会有助于站点实现最高的可用性。 参见 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 2.0 站点。
本部分包括：
用于高可用性的群集和负载均衡技术
旨在获得高可用性的软件建议
旨在获得高可用性的硬件建议
用于高可用性的群集和负载均衡技术
群集是指一组相互独立的计算机，它们共同合作运行公共的一套应用程序或服务，对客户端和应用程序来说像是单个系统一样。 群集计算机在物理上通过网线连接到一起，在程序上则通过群集软件连接到一起。 这些连接使得这些计算机可以使用单独的计算机无法使用的一些问题解决功能，例如负载均衡和故障切换等。
负载均衡功能将负载在所有配置的服务器之间分配，防止某一台服务器负载过度。 通过这种方式从而又让您能够逐步增大容量以满足自己的需求。 故障切换功能可以自动将资源从故障的或脱机的群集服务器上转移到正在运行的一台服务器上，从而为用户提供了恒定的支持。 这样用户就始终都可以访问 MSIB 站点的资源了。 目前，Windows Clustering 可以提供如下的群集和负载均衡技术：
| • |
网络负载均衡 |
| • |
Microsoft 群集服务 |
| • |
组件负载均衡 |
网络负载均衡
网络负载均衡（NLB）技术可以把多达 32 台运行 Windows 2000 Advanced Server 组合到经负载均衡的单个群集中，从而可以提供基于 TCP/IP 的应用和服务的可扩展性和高可用性。
在本文测试的 MSIB 2.0 企业部署中，MSIB 项目组利用 NLB 技术将下表所列的服务器群集了起来。
| 服务器 | 备注 |
|
前端 Web 服务器 ( IIS 和商务服务器 ) |
可以利用 MSIB 2.0 解决方案对前端 web 服务器进行负载均衡的原因在于 Web 服务器中没有维护每个用户的状态信息。 所有的相关数据都是通过 Commerce Server 2002 的对象返回到 SQL 服务器的。 |
|
搜索服务器 （带搜索组件的 SharePoint 门户服务器） |
由于 Internet 上所有的通信量都是发自客户的，MSIB 项目组利用 NLB 配置了这些内容以便在峰值使用时段提供高可用性。 |
|
ISA 服务器 |
企业部署中构成防火墙的 ISA 服务器也是做了负载均衡的，这是为了实现冗余和提高吞吐量。 注: ISA Enterprise Edition 以阵列模式运行，可以为 MSIB 2.0 提供具备最高可用性的解决方案防火墙。 |
Microsoft 群集服务
在 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 部署中典型的单点故障并提供了用于解决每种 SPOF 的高可用性技术。
以下这些方面是 MSIB 2.0 部署中常见的故障点：
| • |
网络 |
| • |
服务器硬件 |
| • |
磁盘子系统 |
| • |
应用程序 |
| • |
数据库和数据库连接 |
下表所列的技术可以用来在您的 MSIB 2.0 部署中提供高可用性，并且介绍了它们能够解决哪些故障点。 这些高可用性技术可以解决本文前面介绍的问题。 建议您在部署 MSIB 2.0 site 站点的时候在较宽基础结构的层次上（如附录A“Hardware and Network Topology Details”给出的企业部署）采用这些技术。 在您的部署中遇到的单点故障越少，这种部署就更加具有高可用性。
| 高可用性技术 | 网络 | 服务器 | 磁盘 | 应用程序 | 数据库 |
|
多块网络接口卡 |
X |
|
|
|
|
|
多个 Internet 服务提供商 |
X |
|
|
|
|
|
地理上分散的数据中心 |
X |
X |
X |
X |
X |
|
不间断电源（UPS） |
X |
X |
X |
X |
X |
|
双电源 |
X |
X |
X |
X |
X |
|
双路由器 |
X |
|
|
|
|
|
数据备份 |
|
X |
X |
X |
X |
|
RAID 磁盘阵列 |
|
|
X |
|
|
|
磁盘镜像 |
|
|
X |
|
|
|
双磁盘控制器 |
|
|
X |
|
|
|
负载均衡的冗余服务 |
|
X |
|
X |
|
|
群集配置 |
|
X |
X |
X |
X |
|
数据复制 |
|
X |
X |
X |
X |
典型的易发故障点和建议采用的解决方案
这一节详细介绍了 MSIB 2.0 企业部署中典型的易出故障的点（如前表所列）并为避免这些故障提出了建议。
网络
网络是将所有的服务器、内联网、Internet 和用户连接到一起的结构。 没有网络连接的话，整个系统都会瘫痪。 网络故障可能会由网络硬件故障、套接字故障或远程过程调用（RPC）连接造成的。
网络硬件故障
网络故障的主要原因有：
| • |
交换机/路由器故障 |
| • |
网络接口卡 (NIC) 故障 |
| • |
电缆媒质故障，如网线故障等 |
建议采用的解决方案
建议采用的高可用性解决方案如下：
| • |
利用 TCP/IP 协议。 |
| • |
启用路由和管理协议，如 Routing Information Protocol 2 (RIP2)、Open Shortest Path First (OSPF)和 Internet Control Message Protocol (ICMP)等。 启用这些协议可能需要配置防火墙策略。 |
| • |
部署冗余的交换机、路由器、电缆和分组的网络接口卡。 |
套接字故障
许多可感知网络的应用程序都是利用传输控制协议（TCP）或用户数据报协议（UDP）的套接字与运行在多个服务器之间的应用程序相互通信的。 要实现 Windows 2000 高可用性所需的通信协议为 TCP/IP 。 连接是利用 TCP 或 UDP 模式的套接字建立起来的。 TCP 套接字是一种状态连接，用于需要数据的决定性定购和保证交付的情形（例如 SQL 查询和 HTTP 查询等）。 UDP 套接字是一种无状态连接，用于定购和交付保证不是非常重要的情况下（如音频流等）。
TCP 套接字是由 MSIB 2.0 所依赖的下列软件使用的：
| • |
SQL Server 2000 |
| • |
Internet Information Server (IIS) |
| • |
SMTP Mail Server |
| • |
Agent 和 Consolidator /agent Manager 之间的 Microsoft Operations Manager (MOM) |
以下的 MSIB 2.0 特性利用了 TCP 套接字：
| • |
Commerce Server 2002 Direct Mail （用于通过 SMTP Server 发送邮件） |
| • |
User Profile System （用于连接到 LDAP 服务器：Active Directory®、Site Server 和第三方。还用于连接到 SQL Server） |
UDP 套接字由 Commerce Server 2002 所依赖的以下软件使用：
| • |
Active Directory （最近的域控制器发现算法） |
TCP/IP 套接字可能会因如下原因发生故障：
| • |
网络故障 |
| • |
服务器故障 |
建议采用的解决方案
建议采用两种 Windows 2000 高可用性解决方案：
| • |
Microsoft 群集服务 (MSCS)。 这种解决方案适用于 SQL Server （工作于主机和发布者模式下）或 IIS （工作于主机和发布者模式下）。 |
| • |
用于 IIS Server 的网络负载均衡（NLB）服务。 这种解决方案适用于 IIS Server （工作于横向扩展模式）、SQL Server （工作于横向扩展模式）、外部 SMTP Mail 服务器和 LDAP 服务器。 |
远程过程调用（RPC）连接故障
RPC 连接是由访问如下内容的应用程序使用的：
| • |
远程资源（映射的驱动器、共享文件夹等） |
| • |
远程 COM+ 组件（通过 DCOM ） |
以下的 MSIB 依赖项可能会用到 RPC 连接：
| • |
远程 COM+ 应用程序 |
| • |
为 SQL 2000 Server 使用 Distributed Transaction Coordinator （DTC）的管道组件 |
| • |
用于目的地复制的 Application Center 源 |
RPC 连接可能会因为以下因素发生故障：
| • |
网络故障 |
| • |
服务器故障 |
建议采用的解决方案
建议采用两种 Windows 2000 高可用性解决方案：
| • |
Microsoft Cluster Service (MSCS) |
| • |
Component Load Balancing (CLB) 服务 |
在故障切换期间，一个访问群集远程文件系统服务器的应用必需要执行如下的操作：
| • |
跟踪文件或正被访问的目录路径内的搜索位置 |
| • |
重新打开正在访问的文件或目录 |
| • |
从故障切换发生的地点开始继续处理，从头开始重新启动处理过程，或返回稳态，令应用程序来决定解决方法 |
在故障切换期间，正在访问远程 COM+ 服务器（或 MSCS 或 CLB 群集）的应用程序必需要执行如下操作：
| • |
跟踪处理点 |
| • |
重新初始化远程 COM+ 对象 |
| • |
从故障切换发生之处开始继续处理，从头开始重新启动处理过程，或返回稳态，令应用程序来决定解决方法 |
服务器硬件
应用程序、中间层和数据库层都运行在物理服务器上。 尽管 Windows 平台可以使用容错系统，不过这些容错系统往往比较昂贵，而且难以适应大范围的商品市场。
因硬件故障导致的服务器故障有如下几种方式：
| • |
随机存取存储器（损坏、耗尽） |
| • |
CPU （过热引起的故障） |
| • |
内部电源（保险丝故障、冗余电源完全失效） |
| • |
母板（电子故障） |
在每种情况下，任何一个底层服务器组件的故障都会导致整个服务器的故障。
建议采用的解决方案
为实现服务器硬件的高可用性，建议采用如下的 Windows 2000 解决方案：
| • |
Microsoft 群集服务 (MSCS)。 这种解决方案适用于工作在主机或发布者模式下的服务器。 一般情况下，MSCS 需要对服务器进行读/写访问，其中，客户应用程序从服务器创建、更新和读出数据。 一般情况下这种解决方案适用于 SQL Server 、Exchange Server 和 COM+ Server 。 |
| • |
网络负载均衡(NLB)服务。 这种解决方案适用横向扩展模式。 在这种模式下，多个数据库服务器在一个单一的虚拟 IP 地址之下进行了负载均衡。 一般情况下这些数据库服务器是作为主数据库服务器的用户工作的，这个数据库服务器则作为一个数据发布者工作。 在一个数据库服务器出现故障的时候， NLB 将该服务器从群集中删除并将连接指向其他正常的服务器。 |
| • |
组件负载均衡(CLB) 服务。 这种解决方案适用于 COM+ 应用程序。 远程 COM+ 组件是安装在 CLB 服务上的。 在某一台 COM+ 服务器出现故障的时候， CLB 能够检测到该故障并将请求指向功能正常的服务器上。 |
| • |
多台服务器。 专门为 Active Directory Domain Controller 部署多台服务器。 Active Directory 是通过复制其目录存储和在多个域控制器之间分布请求实现高可用性的。 |
| • |
硬件冗余。 使用内置硬件冗余的计算机系统，例如冗余电源等。 |
磁盘
磁盘子系统是由 MSIB 2.0 下列的依赖项使用的：
| • |
IIS Server （包括 IIS 元数据库、Web 站点内容：ASP ，HTML ，GIF ，PCF 等等。） |
| • |
Commerce Server 2002 Direct Mailer 用的 Mail Drop 文件夹 |
| • |
搜索内容的内容索引 |
文件/磁盘子系统可能会因为如下原因发生故障：
| • |
硬盘驱动器中物理磁头失效 |
| • |
电子故障 |
| • |
硬盘驱动器中物理扇区损坏 |
建议采用的解决方案
在磁盘子系统这一个级别上，建议您使用以下技术中的一个或多个以确保实现高可用性：
| • |
RAID 5 |
| • |
RAID 1 |
| • |
RAID 1 + 0 |
| • |
多个 SAN 光纤信道通道（交换机、总线和控制器等） |
不过，一旦基础设施级别上的容错功能未能保护子系统，这种故障就会以文件丢失、目录丢失或驱动器句柄的形式反映在操作系统（OS）级别上，引起对文件/磁盘子系统资源的后续访问失败。 如需了解关于 RAID 的更多信息，请在 Windows 2000 Help 中搜索 RAID 。
应用程序
Commerce Server 和 ISA 等应用程序都是由 MSIB 2.0 用以执行该解决方案所需的综合软件功能的。 由于应用程序是运行在平台操作系统（OS）顶部的，因此存在很多引起故障的原因，包括：
| • |
磁盘子系统失效 |
| • |
网络故障 |
| • |
二进制失效 |
| • |
服务器故障 |
建议采用的解决方案
建议采用两种 Windows 2000 高可用性解决方案：
| • |
Microsoft 群集服务。 这种解决方案适用于那些本身是服务而且支持这一功能的应用程序组件。 |
| • |
网络负载均衡(NLB)。 这种解决方案适用于工作于横向扩展模式下的 Search ，ISA ，MCMS 和 Commerce Server 2002 。 在这种模式下，多个应用服务器在一个单一的虚拟 IP 地址之下进行了负载均衡。 前端应用服务器上运行的组件为那些需要使用持续状态的操作在后端数据库服务器上维护着状态。 在一个应用服务器出现故障的时候， NLB 将该服务器从群集中删除并将连接指向其他正常的服务器。 |
| • |
解决方案部署中应当包括对构成应用程序的其他二进制代码的备份。 |
数据库
SQL Server 2000 由 MSIB 2.0 及其依赖项用于连接到数据库上。 由于数据库服务器是运行在平台操作系统和服务顶部的，因此存在很多引起故障的原因，包括：
| • |
文件/磁盘系统失效 |
| • |
网络故障 |
| • |
数据库应用程序故障 |
| • |
服务器故障 |
建议采用的解决方案
建议采用两种 Windows 2000 高可用性解决方案：
| • |
Microsoft 群集服务 (MSCS)。 这种解决方案适用于 MSIB 数据库服务器。 这种解决方案可以提供可靠性，不过却不能提供额外的可扩展性，这是因为其工作负荷并不是分布式的。 |
| • |
网络负载均衡(NLB)。 这种解决方案适用横向扩展模式。 在这种模式下，多个数据库服务器在一个单一的虚拟 IP 地址之下进行了负载均衡。 一般情况下这些数据库服务器是作为主数据库服务器的用户工作的，这个数据库服务器则作为一个数据发布者工作。 在一个数据库服务器出现故障的时候， NLB 将该服务器从群集中删除并将连接指向其他正常的服务器。 |
| • |
解决方案部署中应当包括对数据库和构成数据库的存储过程的备份。 |
类似地，如果现有的计算机出现了硬件资源的瓶颈，那么您应当为 Web 群添加后端 SQL 服务器。 在添加了更多 SQL 服务器之后，构成 MSIB 2.0 解决方案的数据库应当在 SQL 服务器中分离开来。
