性能和容量规划（2）

性能和容量规划（2）
第⼆部分——MSIB 2.0 站点的性能和可扩展性
这⼀部分简单介绍了 MSIB 项⽬组在实现站点代码和实际 MSIB 2.0 部署所需的吞吐量和可扩展性需求时所采⽤的步骤。

这⼀部分并不介绍 编码做法、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 =
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 服务器的性能
调节硬件
在进⾏性能分析的过程中，为 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 站点的可⽤性
您可以按照不同级别的可⽤性部署 MSIB 2.0 解决⽅案。

应当在规划阶段中确定您的 MSIB 2.0 站点的可⽤性⽬标。

这⼀部分介绍了可⽤性，概述了可能会造成您的 MSIB 2.0 站点不可⽤的事件，提供了⾼可⽤性技术和建议，介绍了如何避免单点故障，并讨论了 MSIB 2.0 企业部署的恢复模型。

本部分包括：
什么是可⽤性？
使站点不可⽤的三类事件
⾼可⽤性技术和建议
避免单点故障
MSIB 2.0 企业部署的恢复模型
确定预期的可⽤性
什么是可⽤性？
本⽂中使⽤了可⽤性的定义，因为它是 Internet 站点涉及到的⼀个概念。

可⽤性包括可靠性、故障恢复和故障⼏个⽅⾯。

最常⽤的可⽤性计量标准之⼀就是“九的个数”。

“这⼀数字可以转换为某⼀系统可正常⼯作的时间百分⽐。

例如，⼀个运⾏时间百分⽐为 99.999 的系统可以说成其可⽤性为五个九。

下表给出了九的个数和时间之间的对应关系。

可接受的运⾏时间百分⽐每天的停机时间每⽉的停机时间每年的停机时间
9572.00 分钟36 ⼩时18.26 天
9914.40 分钟7 ⼩时 3.65 天
99.986.40 秒钟43 分钟8.77 ⼩时
99.998.64 秒钟 4 分钟52.60 分钟
99.9990.86 秒钟26 秒钟 5.26 分钟
从运⾏时间的⾓度来看可⽤性
从上表可以看出，可接受运⾏时间为百分之 99.9 的系统平均每天只有 86.40 秒钟或每⽉只有 43 分钟是不可运⾏的。

要获得更多个九的可⽤性，必需要对系统部署、软件和解决⽅案实施的管理加以改进。

要预测⼀个系统何时甚⾄是隔多久会发⽣故障是⾮常困难的，因此要获得更好的可靠性，⼀个关键的规划⽅法是要缩短故障的恢复时间。

如果您的系统可以在 86.4 秒钟之内从故障中恢复过来，那么系统即使每天发⽣⼀次故障，仍然能够达到三个九的可⽤性。

从成功交易⾓度来看可⽤性
上述的可⽤性概念是作为运⾏时间的函数分析的，与此相反是将可⽤性作为成功交易的函数来分析可⽤性这个概念。

换句话说，如果某⼀个Web 站点每天处理 100000 个请求，那么百分之 99.9 的可⽤性就意味着每天有 100 个请求是失败的。

如果您将此作为衡量可⽤性的标准，那么在业务规划中对可⽤性的要求就可能会发⽣变化。

例如，在⼀天之内⼀个 Web 站点的通信量是在改变的。

在凌晨两点的时候，您的站点每⼩时的访问次数可能还不到 100 。

如果您的站点在这期间发⽣故障，那么此时发⽣的失败请求数量⼤约要⽐下午 5 点时少四倍，那个时候是⼀天中的峰值时刻，每⼩时的访问次数为 400 次或更多。

使站点不可⽤的三类事件
有三类时间可能会造成您的 MSIB 2.0 站点⽆法⼯作，从⽽造成其不可⽤：⼈为错误、硬件故障和软件故障。

如果规划不当的话，这些事件中的任何⼀个都可能会使站点的⽬标可⽤性⽆法实现。

⼈为错误
硬件故障
硬件故障可能会在任何时候发⽣。

这类故障包括环境故障，如天灾和⽕灾等。

在硬件实现的设计中将单点故障降到最低是降低这种风险的最安全⽅式。

在部署计划阶段中，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
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 部署的组件能⼒。

建议您在运⾏ 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 服务就得到了循环利⽤。

旨在获得⾼可⽤性的硬件建议
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
不过，⼀旦基础设施级别上的容错功能未能保护⼦系统，这种故障就会以⽂件丢失、⽬录丢失或驱动器句柄的形式反映在操作系统（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 服务器中分离开来。