windows群集服务（NLB、Cluster）配置指南（转）
Windows Server 2003 服务器群集：架构概述
服务器群集是 Microsoft Windows 服务器产品家族提供的两种 Microsoft Windows 群集技术中的一
种。Windows Server 2003 为那些要求高可用性和数据完整性的后端应用和服务提供了故障转移支持。这
些后端应用包括数据库、文件服务器、企业资源计划 (ERP) 以及消息系统等企业应用。本文立足于这种
群集服务的架构和功能，介绍了其术语、概念、设计目标、关键组件和预定的发展方向。
简介
服务器群集功能最早是为 Microsoft Windows NT® Server 4.0 操作系统设计的，这一功能在 Microsoft
Windows Server 2003 Enterprise Edition 和 Windows Server 2003 Datacenter Edition 操作系统中
又得到重大改进。您可以借助服务器群集功能将多台服务器连接在一起，从而为在该群集中运行的数据和
程序提供高可用性和易管理性。服务器群集提供了以下三种主要的群集技术优点：
• 更高的可用性。允许服务器群集中的服务和应用在硬件或软件组件故障下或在计划维护期间仍能
不间断地提供服务。
• 更高的可扩展性。支持通过增加多个处理器（在 Windows Server 2003 Enterprise Edition 中
最多可达 8 个，在 Windows Server 2003 Datacenter Edition 中最多可达 32 个）和额外内存（在企
业版中，随机存取内存 [RAM] 最多可达 8 GB，在 Windows Server 2003 Datacenter Edition 中最多可
达 64 GB）来扩展服务器。
• 更高的可管理性。允许管理员如同管理单台计算机那样管理整个群集内的设备和资源。
该群集服务是两种互为补充的 Windows 群集技术（为了扩展 Windows Server 2003 和 Windows 2000 基
础操作系统而提供的）中的一种。另一个群集技术是网络负载均衡（Network Load Balancing，NLB）。
该技术作为服务器群集的互补，可面向前端应用和服务（如 Internet 或 Intranet 站点、基于 Web 的
应用、媒体流以及 Microsoft 终端服务）来支持高度可用和可伸缩的群集。
本白皮书仅立足于服务器群集的架构和功能，介绍了服务器群集的术语、概念、设计目标、关键组件和预
定的发展方向。本白皮书结尾处的“详细信息”小节提供了一个参考列表，您可以通过这些资源了解服务器
群集和 NLB 技术的详细信息。
发展背景
计算机群集的出现和使用已经有十几年的历史。作为最早的群集技术设计师之一，G. Pfister 对群集的
定义是，“一种并行或分布式的系统，由全面互连的计算机集合组成，可作为一个统一的计算资源使用”。
将数台服务器计算机组合成一个统一的群集，多台服务器将可以在用户或管理员不必了解细节的情况下分
担计算负载。例如，如果服务器群集中的任何资源发生了故障，则不论发生故障的组件是硬件还是软件资
源，作为一个整体的群集都可以使用群集中其它服务器上的资源来继续向用户提供服务。
换言之，当资源发生故障时，同服务器群集连接的用户可能经历短暂的性能下降现象，但不会完全失去对
服务的访问能力。当需要更高的处理能力时，管理员可以通过滚动升级过程来添加新资源。该过程中，群
集在整体上将保持联机状态，它不仅可供用户使用，而且在升级后，其性能也将得到改善。
Windows Server 2003 Enterprise Edition 和 Windows Server 2003 Datacenter Edition 操作系统是
完全针对用户和业务对群集技术的要求而设计开发的。主要目标是：开发一种能满足大多数商业机构和组
织的群集需求的操作系统服务，而不是仅针对小型和特定的市场段。
Microsoft 市场调查显示，随着中小型商业机构的日常运作已越来越离不开数据库和电子邮件，因此它们
对高可用系统的需求很大，而且这种需求日趋旺盛。易于安装和管理，被认为是这种规模的机构最关键的
要求。Microsoft 的调查同时显示，那些对高性能和高可用性具有很高要求的大企业对基于 Windows 的
服务器也日益感兴趣。
作为 Windows NT、Windows 2000 和 Windows Server 2003 基础操作系统的集成化扩展而开发的服务器
群集服务，正是源于此次市场调查。该服务同其设计目标保持了一致，通过它可将多台服务器和数据存储
组件连接成一个易于管理的单元，即服务器群集。对于大型和小型企业中运行基于 Windows Server 2003
和 Windows 2000 的应用程序的系统，服务器群集功能将可以赋予它们高可用性和易管理性。服务器群集
功能还提供了开发可利用服务器群集的高可用功能并且具有群集意识的新应用程序所必需的应用程序接口
和工具。
群集术语
“服务器群集”是 Windows Server 2003 中群集技术的名称，Microsoft 最初在 Windows NT Server 4.0
Enterprise Edition 中提供该技术时使用的是“Microsoft 群集服务器” (MSCS)。当谈到构成一个群集的
服务器时，各个服务器计算机都被称为节点。群集服务 是指在各个节点上执行群集操作的组件所构成的
集合，而资源 是指在群集内由群集服务管理的硬件和软件组件。服务器群集为实现资源管理而提供的规
范机制是资源动态链接库 (DLL)。资源 DLL 定义了资源抽象方法、通讯接口以及管理操作。
当资源可供使用并且可以向群集提供其服务时，我们说它是联机 的。资源是符合以下条件的物理或逻辑
实体：
• 可以联机（服务）和脱机（停止服务）。
• 可以在服务器群集中管理。
• 一次只能由一个节点拥有。
群集资源包括磁盘驱动器和网卡等物理硬件设备以及 Internet 协议 (IP) 地址、应用程序、应用数据库
等逻辑实体。群集中的每个节点都有自己的本地资源。但群集也有共用资源，比如共用的数据存储阵列和
专用的群集网络。群集中的每个节点都可以访问这些共用资源。一个特殊的共用资源是仲裁资源，这是指
共用的群集磁盘阵列中对群集运行有着关键性作用的物理磁盘。它是节点操作（比如构成群集或加入群集
）得以发生所必须具备的。
资源组 是指群集服务作为一个逻辑单元进行管理的资源集合。通过将逻辑上相关的资源分成资源组，可
以非常容易地管理应用资源和群集实体。对资源组执行群集服务操作时，操作对于该组内包含的各个资源
都有效。通常来说，创建资源组的目的是为了将特定应用程序服务器和客户端正常使用该应用程序而所需
的全部元素都包括在一起。
服务器群集
服务器群集基于无共享的群集架构模型。这种模型涉及群集的服务器如何管理和使用本地以及共用的群集
设备和资源。在无共享的群集中，每个服务器都拥有和管理自己的本地设备。对于群集共用的设备，比如
共用的磁盘阵列和连接介质，在任何给定时间，只能由一个服务器选择性地拥有和管理。
在这种无共享的模型下，可以更为轻松地管理磁盘设备和标准应用程序。这种模型不需要任何专门的布线
或应用程序即可让服务器群集支持基于 Windows Server 2003 和 Windows 2000 的标准应用程序和磁盘
资源。
对于本地存储设备和介质连接，服务器群集使用标准的 Windows Server 2003 和 Windows 2000 Server
驱动程序。对于群集内的所有服务器都需要访问的外部共用设备，服务器群集支持多个连接介质。群集共
用的外部存储设备需要有小型计算机系统接口 (SCSI) 设备，并且支持标准的 PCI SCSI 连接以及位于光
纤通道和 SCSI 总线上、带有多个始发端的 SCSI 连接。光纤连接是指仅位于光纤通道（而不是 SCSI 总
线）上的 SCSI 设备。理论上说，光纤通道技术会在光纤通道内封装 SCSI 命令，并且允许使用服务器群
集意欲支持的 SCSI 命令。这些 SCSI 命令（“预留/释放”以及“总线复位”）在标准的或非光纤 SCSI 互
连介质上具有相同的作用。
下图显示了一个 2 节点服务器群集的组件。构成这个服务器群集的服务器可能运行 Windows Server
2003 Enterprise Edition 或 Windows 2000 Advanced Server，并且具有 SCSI 或光纤通道 SCSI 形式
的共享存储设备连接。
图 1- 运行 Windows Server 2003 Enterprise Edition 的 2 节点服务器群集
Windows Server 2003 Datacenter Edition 支持 4 节点或 8 节点群集，它要求使用光纤通道形式的设
备连接（以下 4 节点群集的组件图对此进行了说明）。
图 2- 运行 Windows Server 2003 Datacenter Edition 的 4 节点服务器群集
虚拟服务器
群集的优点之一是，运行在服务器群集上的应用程序和服务可以用虚拟服务器的形式出现在用户和工作站
面前。用户和客户端在连接到以群集化的虚拟服务器形式运行的应用程序或服务时，就如同连接到一台物
理性的服务器。事实上，群集中的任何节点都可以接受这样的虚拟服务器连接。用户或客户端不会知道虚
拟服务器真正驻留在哪个节点上。
注意：如果某个服务或应用程序不是供用户或客户端应用程序访问的，则它们可以运行在不是以虚拟服务
器形式管理的群集节点上。
在群集中可以驻留代表不同应用程序的多个虚拟服务器。图 3 展示了这种情况。
图 3 – 虚拟服务器在群集服务器下的实际表观
上图显示了一个含有四个虚拟服务器的 2 节点群集；每个节点有两个虚拟服务器。服务器群集将虚拟服
务器作为资源组加以管理，每个虚拟服务器资源组都包含两个资源：一个 IP 地址以及一个同该 IP 地址
相对应的网络名称。
应用程序客户端将通过客户端会话同虚拟服务器建立连接。这些客户端会话仅知道由群集服务作为该虚拟
服务器的地址发布的 IP 地址。在客户端方面，仅涉及各个网络名称和 IP 地址。对于支持四个虚拟服务
器的 2 节点群集，图 4 显示了该群集节点和四个虚拟服务器的客户端情况。
如图 4 所示，客户端只能看到 IP 地址和网络名称，它们无法了解同任何一个虚拟服务器的物理位置有
关的信息。这为服务器群集针对以虚拟服务器形式运行的应用程序提供高可用性支持创造了条件。
图 4- 服务器群集的虚拟服务器的客户端情况
一旦应用程序或服务器发生故障，群集服务就会将整个虚拟服务器资源组转移到群集中的另一个节点上。
在发生这样的故障时，客户端将会在其同该应用程序的会话中检测到故障，并且试图用与先前连接完全一
致的方式进行重新连接。由于群集服务在恢复操作中可以简单地将虚拟服务器的公开 IP 地址映射到群集
中幸存的节点，因此客户端的上述努力将可以获得成功。客户端会话不必知道相关的应用程序现在是否已
实际驻留到了群集中的不同节点上就可以重建同该应用程序的连接。
注意：虽然这可以为应用程序或服务提供高可用性，但同发生故障的客户端会话有关的会话状态信息将丢
失，除非该应用程序在设计上或在配置上会将客户端会话数据存储在磁盘上以备在应用程序恢复期间使用
。服务器群集虽然可以实现高可用性，但不能提供应用程序容错，除非应用程序自身支持容错行为。在存
储客户端数据以便实现客户端会话故障恢复的应用示例中，Microsoft 的动态主机配置协议 (DHCP) 服务
算是其中的一个。DHCP 客户端的 IP 地址预订信息保存在 DHCP 数据库中。如果 DHCP 服务器资源发生
故障，上述 DHCP 数据库将可以被转移到群集中可用的节点上，并且可以用从该 DHCP 数据库恢复的客户
端数据重新启动。
资源组
资源组是群集资源的不同逻辑集合。通常而言，资源组是由逻辑上相关的资源（比如应用程序及其关联的
外围设备和数据）组成的。但是，资源组也可能包含仅出于管理需要而相互关联的群集实体，比如由服务
器名称和 IP 地址组成的管理性集合。资源组一次只能由一个节点所拥有，一个资源组的各个资源都必须
位于当前拥有该组的节点上。在任何给定的情况下，群集中的不同服务器都不能拥有同一资源组内的不同
资源。
每个资源组都对应一个全群集性的策略。该策略指定了该资源组将优先在哪个服务器上运行，以及在发生
故障时该资源组应该转移到哪个服务器上。为了允许网络客户端绑定到资源组提供的服务，每个资源组还
有一个网络服务名称和地址。在发生故障时，可以将资源组作为最小单元的形式从故障节点故障转移到群
集中另一可用的节点。
资源组中的各个资源可能依赖群集中的其它资源。这种资源之间的依存关系指定了只有首先启动哪些资源
并让它们可用才能启动另外的资源。例如，如果要启动数据库应用程序并向其它程序和客户端提供服务，
可能会取决于磁盘、IP 地址和网络名称是否可用。
资源依存关系是使用群集资源组属性来标识的。借此，群集服务可以控制资源联机和脱机的顺序。对任何
指定的依存关系而言，其作用范围只能局限于同一资源组内的资源。群集管理的依存关系不能超出资源组
的范围，原因是资源组可以联机、脱机并且可以独立被转移。
服务器群集架构
服务器群集在设计上是由联同操作系统一起工作的组件构成的单独、隔离的集合。这种设计避免了在服务
器群集和操作系统之间引入复杂的处理系统。但为了实现群集功能，仍将要求对基础操作系统进行某些更
改。这些更改包括：
• 支持动态地创建、删除网络名称和地址。
• 修改了文件系统，以便在磁盘驱动器卸载期间可以关闭打开的文件。
• 修改了输入输出 (I/O) 子系统，以便实现在多个节点之间共享磁盘和卷集。
如果抛开上述变化和其它细微修改不论，可以说群集功能就建立在 Windows Server 2003 和 Windows
2000 操作系统的现有基础之上。
服务器群集的核心正是群集服务，该服务包括几个功能单元。它们是节点管理器、故障转移管理器、数据
库管理器、全局更新管理器、检查点管理器、日志管理器、事件日志复制管理器以及备份/恢复管理器。
图 6 详细显示了这些组件之间的关系架构示意。
群集服务组件
群集服务运行在 Windows Server 2003 或 Windows 2000 操作系统上，而这些操作系统又使用了专门针
对服务器群集及其组成过程设计的网络驱动程序、设备驱动程序以及资源规范过程。这些同群集服务紧密
相关的组件是：
• 检查点管理器 — 负责将应用程序注册表项保存到位于仲裁资源上的群集目录中。
• 数据库管理区 — 负责维护群集配置信息。
• 事件日志复制管理区 — 负责将事件日志从一个节点复制到群集中的所有其它节点。
• 故障转移管理区 — 负责执行资源管理和启动相应的操作，比如启动、重启和故障转移。
• 全局更新管理器 — 负责提供群集组件使用的全局更新服务。
• 日志管理器 — 负责将变更写入存储在仲裁资源上的恢复日志中。
• 成员管理器 — 负责管理群集的成员关系，并且监视群集中其它节点是否正常。
• 节点管理器 — 负责根据资源组首选项列表和节点的可用性来指定节点对资源组的所有权。
• 资源监视器 — 使用对资源 DLL 的回调来监视每个群集资源的健康状况。资源监视器以独立的进
程运行，它通过远程过程调用 (RPC) 同群集服务器通信，以保护群集服务器不受群集资源中个别故障的
影响。
• 备份/恢复管理器 — 借助故障转移管理器和数据库管理器，备份或恢复仲裁日志文件和所有的检
查点文件。
节点管理器
节点管理器运行在每个节点上，它维护着一个包含群集所属节点的本地列表。节点服务器会定期向在群集
中其它节点上运行的节点服务器发送消息（称为“心跳”），以检测节点故障。这是保持群集中的所有节点
时时刻刻都具有完全一致的群集成员身份所不可或缺的。
如果一个节点检测到同另一节点的通信故障，它就会向整个群集发送多播消息，从而让所有成员都对其当
前的群集成员身份进行检查。这被称作一个重新分组事件。除非已建立起稳定的成员关系，否则群集服务
将禁止对所有群集节点所共用的任何磁盘设备执行写入操作。如果某个节点上的节点管理器没有响应，则
该节点将被从群集中删除，其活动的资源组会被转移到另外的活动节点上。为选择应将资源组转移到哪个
节点上，节点管理器会确定资源组首选运行的节点以及可以拥有单独资源的潜在拥有者（节点）。在 2
节点群集中，节点管理器会直接将资源组从故障节点转移到幸存的节点。在 3 节点或更多节点的群集中
，节点管理器有选择地将资源组分发到幸存的节点。
节点管理器还充当网关守卫的作用，它允许“合作”节点进入群集并且负责处理添加或逐出节点的请求。
注意： 当群集服务及其组成过程发生故障时，同遭遇故障的节点连接的资源将被停止，目的是在群集的
有效节点上重新启动它们。
数据库管理器
数据库管理器提供了维护群集配置数据库（该数据库包括了有关群集中所有物理和逻辑实体的信息）需要
的功能。这些实体包括群集本身、群集节点的成员身份、资源组、资源类型以及特定资源（如磁盘和 IP
地址）的描述。
存储在该配置数据库中的长期性和短暂性信息可用于跟踪群集的当前状态或意欲了解的状态。运行在各个
群集节点上的数据库管理器共同维护着在整个群集内一致的配置信息。为了确保所有节点上的配置数据库
副本都一致，一次只能有一个数据库管理器向配置数据库提交数据。数据库管理器还提供了可供其它群集
服务组件（如故障转移管理器和节点管理器）使用的接口。该接口类似于 Win32 应用程序编程接口
(API) 集提供的注册表接口。主要区别是，数据库管理器会将对群集实体进行的更改同时记录到注册表和
仲裁资源中（这些更改由日志管理器写入仲裁资源）。全局更新管理器随即将注册表变化复制到其它的节
点。
数据库管理器支持对群集部分的事务性更新，并且仅向内部群集服务组件提供接口。故障转移管理器和节
点管理器通常会借助这种事务性支持，因为它们要获取复制的事务。
群集 API 会将除事务支持外的数据库管理器功能暴露给客户端。这些数据库管理器 API 的主要客户端是
资源 DLL，它们将使用数据库管理器将专用属性保存到群集数据库中。其它客户端通常使用数据库管理器
查询群集数据库。
注意： 应用程序注册表项的数据和变化将由检查点管理器记录到位于仲裁资源上的仲裁日志文件中。
检查点管理器
为确保群集服务能够从资源故障中恢复，检查点会在资源联机时检查注册表项，并在资源脱机时向仲裁资
源写入检查点数据。能够感知群集的应用程序可使用群集配置数据库存储恢复信息。不能感知群集的应用
程序将在本地服务器注册表中存储信息。
检查点管理器还支持资源拥有特定于应用程序的注册表树（该注册表树是在资源联机的群集节点上被实例
化的，一个资源可以拥有一个或多个关联的注册表树）。当资源联机时，检查点管理器会监视对这些注册
表树所作的更改。如果检测到已发生了更改，它会在拥有该资源的节点上创建注册表树的转储文件，然后
将其转移到拥有仲裁资源的节点上。检查点管理器会执行一定量的“批处理”，这样一来，对注册表树的频
繁更改就不会为群集服务施加过重的负担。
日志管理器
日志管理器联同检查点管理器一起工作，确保仲裁资源上的恢复日志包含有最近的配置数据和变更检查点
。如果一个或多个群集节点发生故障，仍然可以对幸存的节点进行配置更改。当这些节点发生故障时，数
据库管理器会使用日志管理器记录仲裁资源的配置变化。
当故障节点重新投入服务时，它们会从其注册表的本地群集部分读取仲裁资源的位置。由于这部分的数据
可能已过时，因此会有一个内置的机制来检测从过时的群集配置数据库中读取的无效仲裁资源。数据库管
理器随后会请求日志管理器使用仲裁资源中的检查点文件对本地副本的群集部分进行更新，并接着从检查
点日志的序列号开始在仲裁磁盘中重放日志文件。这样就可以完全更新群集部分的信息。
一旦重置了仲裁日志，就会制作群集信息的快照。另外，这种操作也会每四个小时执行一次。
故障转移管理器
故障转移管理器负责停止和启动资源、管理资源依存关系以及启动资源组的故障转移。为执行这些操作，
它会从资源监视器和群集节点接收资源和系统状态信息。
故障转移管理器还负责决定群集中的节点可以拥有的资源组。完成了资源组的仲裁后，拥有各个资源组的
节点会将对资源组内资源的控制权移交给节点管理器。当拥有某个资源组的节点无法处理该组内的资源故
障时，各个群集节点上的故障转移管理器将一起来仲裁该资源组的所有权。
发生资源故障时，故障转移管理器可能重新启动该资源或将资源及其依存资源脱机。如果将资源脱机，它
会指示将该资源的所有权移交给另一节点并且以新节点的名义重新启动该资源。这被称作故障转移。
故障转移
在发生意外的硬件或应用程序故障时，故障转移可能会自动执行，也可能由群集管理人员手动触发。这两
种情形的算法相同，只不过在人工启动故障转移时，资源是按有序方式关闭的（即使这种关闭形式在故障
状态下可能显得突然和具有破坏性）。
当群集中的某个节点完全失效时，其资源组将被转移到群集中的一个或多个可用的服务器。自动故障转移
类似于按照计划对资源所有权进行管理性的重新分配。但该过程将更为复杂一些，因为正常有序的关闭步
骤可能受到影响或者根本就不会发生。因此为了评估故障时的群集状态，还将需要一些额外步骤。
自动故障转移需要确定在故障节点上运行的资源组以及哪些节点将会获得各个资源组的所有权。群集中所
有可以驻留这些资源组的节点会彼此协商这些资源组的归属事宜。这种协商基于节点性能、当前负载、应
用程序反馈或者节点首选项列表。节点首选项列表是资源组属性的一部分，可用来将资源组指定给某个节
点。一旦完成资源组的协商，所有群集节点就会更新各自的数据库并跟踪拥有资源组的节点。
在具有两个以上节点的群集中，各个资源组的节点首选项列表可以指定一个首选服务器外加一个或多个优
先的备用服务器。这样可以实现级联式故障转移 功能。通过该功能，资源组可以不受多个服务器故障的
影响，因为它们可以逐级地故障转移到节点首选项列表的下一个服务器上。群集管理员可以为某个服务器
上的资源组设置不同的节点首选项列表，这样，一旦服务器发生故障，就可以将该资源组分发到幸存的群
集服务器上。
这种方案的一个替代做法是设置群集中所有资源组的节点首选项列表（该做法通常称为 N+I 故障转移）
。节点首选项列表将确定首次故障转移时应将资源转移到哪个备用的群集节点。这些备用服务器应该是群
集中最为空闲的服务器，或者它们可以非常容易地清除自己的工作载荷以便接收故障服务器转移来的工作
载荷。
当群集管理员在选择级联式故障转移和 N+I 故障转移时，关键问题是要考虑群集是否有额外的容量来容
纳因为少了服务器而损失的容量。使用级联式故障转移的前提是，群集的每个服务器都有一定的额外容量
来接纳其它服务器发生故障时转移来的一部分工作负载。而使用 N+I 故障转移的前提是，这“+I”个备用
服务器将是提供额外容量的主要位置。
故障恢复
当节点恢复联机时，故障转移管理器可以决定是否将某些资源组转移回这个已恢复正常的节点。这被称作
故障恢复。只有资源组的属性定义了首选的拥有者，已恢复正常或重新启动的节点才有可能实现故障恢复
。如果恢复的或重新启动的节点是资源组的首选拥有者，则该资源组会从其当前的拥有者转移到恢复的或
重启的节点。
资源组的故障恢复属性可能包括在一天之中的哪个时间才允许故障恢复以及对故障恢复尝试时间的限制。
这样，群集服务就可以防止在高峰处理时间进行资源的故障恢复，或者保护尚未正确恢复或重启的节点。
全局更新管理器
内部群集组件（比如故障转移管理器或数据库管理器）可以使用全局更新管理器 (GUM) 以原子方式（或
者更新所有正常的节点，或者一个都不更新）和串行方式（保持一个整体顺序）将群集服务器的变更复制
到各个群集节点。GUM 更新的发起，通常源于群集 API 调用。在客户端节点上启动 GUM 更新时，GUM 首
先会请求负责锁定的节点实现全局（“全局“表示所有的群集节点）锁定。如果无法进行全局锁定，客户端
会一直等待。
当可以锁定时，负责锁定的节点会将锁定授予该客户端，并且从本地（在负责锁定的节点上）发布更新。
该客户端随即将更新发布到包括它自身在内的所有正常节点。如果在负责锁定的节点上成功完成了更新，
但在其它某些节点上更新失败，则会剥夺这些节点在当前群集中的成员资格。如果在负责锁定的节点上更
新失败，该节点仅向客户端返回故障信息。
备份/恢复管理器
群集服务为群集数据库备份提供了一个 API，即 BackupClusterDatabase。BackupClusterDatabase 首先
会同故障转移层联系，而后者会接着将请求转交给拥有仲裁资源的节点。这样就可以调用该拥有者节点中
的数据库管理器，并由它来完成仲裁日志文件和所有检查点文件的备份。
除了 API 外，群集服务在启动时也会以备份写入程序的形式将自己注册到卷影复制服务 (VSS)。当备份
客户端调用 VSS 执行系统状态备份时，它会通过一系列的入口点调用来调用群集服务执行群集数据库备
份。群集服务中的服务器代码会直接调用故障转移管理器来执行备份，其余的操作与
BackupClusterDatabase API 相同。
为了从备份路径恢复群集数据库，群集服务提供了另一个 API，即 RestoreClusterDatabase。该 API 只
能从某个群集节点的本地调用。调用该 API 时，它将依次停止群集服务、从备份中恢复群集数据库、设
置包含备份路径的注册表值，然后再启动群集服务。群集服务在启动时会检测到需要进行恢复，并会接着
从备份路径将群集数据库恢复到仲裁资源中。
事件日志复制管理器
群集服务会同群集中的事件日志服务进行交互，以便将事件日志条目复制到所有的群集节点。当群集服务
在某个节点上启动时，它会调用本地事件日志服务中的专用 API，并且要求该事件日志服务向回绑定到群
集服务。作为响应，该事件日志服务将使用 LRPC 绑定到 clusapi 接口。从此时开始，只要事件日志服
务收到要记录的事件，它就会在本地记录它，然后将事件放到持续性的批处理队列中，并且安排一个计时
器线程。如果没有活动的计时器线程，该线程就会在 20 秒后启动。计时器线程启动时，它会排空批处理
队列，并借助事件日志服务已绑定的群集 API 接口将所有事件作为一个整体缓冲发送到群集服务。
一旦群集服务收到来自事件日志服务的批量事件，它会将这些事件放到本地的“传出”队列中并且从该 RPC
返回。群集服务中的事件广播器线程会排空该队列，并借助群集内的 RPC 将队列中的事件发送到所有有
效的远程群集节点。服务器侧的 API 将收到的事件放到“传入”队列中。事件日志写入程序线程随后会排
空该队列，并且通过专用的 RPC 请求本地事件日志服务在本地写入这些事件。
群集服务使用 LRPC 来调用事件日志专用 RPC 接口。事件日志服务也会使用 LRPC 来调用请求群集服务
对事件进行复制的群集 API 接口。
成员身份管理器
成员身份管理器（也称为“重新分组引擎）负责维护在任何给定时刻的群集节点情况（活动或停机）的一
致性。组件的心跳是决定是否重新分组的依据。只要有证据表明一个或多个节点已失效，就会调用重新分
组。在重新分组过程的最后，所有有关的节点都会对新的群集成员身份达成相同的看法。
非群集服务组件
虽然以下组件通常被认为并不属于真正的群集服务，但它们仍然是同群集服务操作紧密联系在一起的。
资源监视器
资源监视器提供了资源 DLL 同群集服务之间的通讯接口。当群集服务需要从资源获取数据时，资源监视
器会收到该请求并将它转交给相应的资源 DLL。相反，当资源 DLL 需要报告其状态或需要通知群集服务
某个事件时，资源监视器会将这些来自资源的信息转交给群集服务。
资源监视器进程是作为群集服务的子进程而派生的，该进程在自己的进程空间中加载监视群集资源的资源
DLL（在同群集服务进程不同的进程中加载资源 DLL 将有助于隔离故障）。同时可以派生和执行多个资源
监视器进程。一个同资源关联的共用属性将确定是将对应的 DLL 载入单独的监视器进程还是载入默认的
监视器进程。在 Windows server 2003 群集中，只能在单独的监视器进程载入一个资源 DLL，不允许进
行资源分组。默认情况下，仅会派生一个资源监视器进程，而所有的资源 DLL 都将被载入该单一进程。
每个资源监视器都充当群集服务进程的 LRPC 服务器。当群集服务收到要求同资源 DLL 通讯的群集 API
调用时，它会使用这种 LRPC 接口来调用资源监视器 RPC。为了接收来自资源监视器的响应，群集服务会
为每一个资源监视器进程创建一个通知线程。该通知线程将调用暂时停留在资源监视器中的 RPC，从而一
旦有通知生成就可以立即接收它们（比如“资源 X 已联机“）。该线程只有当资源监视器终止或通过来自
群集服务的关闭命令明确停止了资源监视器时才会被释放。
资源监视器并不维护同自身有关的任何存续状态。其所有初始状态都是群集服务提供的，它仅保存某些有
限的资源内存状态。资源监视器通过完善定义的入口点（这是资源 DLL 必须提供的，类似于 COM V-
Table）同资源 DLL 通讯。对资源监视器自身而言，它要执行的唯一操作是通过“IsAlive”和“LooksAlive
”入口点来轮询资源 DLL（或者说轮流检查资源 DLL 表明的故障事件）、派生计时器线程（针对那些从
Online 或 Offline 入口点返回 ERROR_IO_PENDING 的资源 DLL，目的是监视其未决的超时）、检测群集
服务是否崩溃（如果崩溃，则关闭资源）。在资源监视器中发生的其它操作则要取决于群集服务通过 RPC
接口请求了什么样的操作。
群集服务会监视资源监视器是否崩溃，如果检测到该进程崩溃，它将重新启动一个监视器。在目前的群集
服务器中，群集服务不会执行任何 hang（暂停）检测。
群集服务和资源监视器进程共享一个内存映射扇区（由分页文件支持），在资源监视器启动时，系统会将
该扇区的句柄传递给资源监视器。资源监视器随即会复制该句柄。资源监视器进程在调用资源 DLL 入口
点之前会将入口点编号和资源名称记录到该映射区中。如果资源监视器崩溃，群集服务（以及该资源监视
器的上级异常过滤器）会读取这个共享扇区，以检测导致监视器进程崩溃的资源及其入口点。
事件服务
事件服务充当了电子交换机的作用，它负责为在群集节点上运行的应用程序和群集服务组件发送事件，或
者将事件发送给它们。事件处理器可帮助群集服务组件将有关重要事件的信息分发给所有其它组件，并且
可支持群集 API 事件处理机制。事件处理器执行杂项服务，比如向那些可感知群集的应用程序发送信号
事件和维护群集对象。
群集仲裁
每个群集都有一种特定资源，即所谓的仲裁资源。仲裁资源可能是执行以下操作的任何资源：
• 提供一种旨在实现成员身份和群集状态决定的仲裁机制。
• 提供物理性存储空间以存储配置信息。
仲裁日志只是一种用于服务器群集化功能的配置数据库。它保存了多种配置信息，比如群集的成员服务器
都有哪些、群集中安装了哪些资源以及这些资源处于何种状态（例如，是联机还是脱机）。默认情况下，
该仲裁日志位于 \MSCS\quolog.log。
仲裁在群集中非常重要，其主要原因有两个。以下介绍了这两个原因。
一致性
由于群集的基本设计理念就是多台物理服务器充当一个虚拟服务器的作用，因此每个物理服务器在群集配
置方式上是否具有一致的状态，将显得非常关键。对所有同群集有关的配置信息而言，仲裁充当了最具权
威性的仓库。如果群集服务无法读取仲裁日志，它将不会启动，因为它无法保证群集是否处于一致性的状
态，而这又是群集最主要的要求之一。
斡旋作用
仲裁提供的斡旋作用可以避免“各自为政”的情况。当两个或多个群集节点之间的所有网络通讯链路都失效
时，会发生“各自为政”的局面。此时，群集可能分成两个或更多个在彼此之间无法交流的“派别”。使用仲
裁后，可以保证任何群集资源只会在某一个节点上进入联机状态。这是通过仅允许“拥有”仲裁的一派继续
存在，同时将其它派别逐出群集来实现的。
标准仲裁
如上所述，仲裁只是用于 Microsoft 群集服务的一种配置数据库，它存储在仲裁日志文件中。标准的仲
裁是使用位于互连的共享存储区中的仲裁日志文件，群集的所有成员都可以访问该文件。
注意： 可以对服务器群集进行配置，让它使用服务器的本地硬盘来存储仲裁，但仅在出于测试和开发目
的时才支持这样做，在生产环境中不应该使用这样的配置。
各个成员都将可以使用某种互连形式（比如 SCSI 或光纤通道）同共享存储区连接，而共享存储区可以
由外部硬盘（通常配置为 RAID 磁盘）或存储区域网络 (SAN) 构成。使用 SAN 时，其逻辑片段将显示为
物理磁盘。
注意： 非常重要的一点是，仲裁需要使用物理磁盘资源而不是磁盘分区，因为在故障转移过程中，整个
物理磁盘资源都将被转移。
您可以在 Windows NT 4.0 Enterprise Edition、Windows 2000 Advanced Server、Windows 2000
Datacenter Edition、Windows Server 2003 Enterprise Edition 以及 Windows Server 2003
Datacenter Edition 中使用标准仲裁，图 7 说明了这种标准仲裁。
多数节点集仲裁
从服务器群集的发展来看，多数节点集 (MNS) 仲裁将成为唯一的仲裁资源。但在默认情况下，其数据实
际存储在各个群集成员的系统磁盘上。MNS 资源负责确保在 MNS 上存储的群集配置数据在不同磁盘上都
保持一致性。图 8 显示了一个使用 MNS 仲裁配置的四节点群集。
您可以在 Windows Server 2003 Enterprise Edition 以及 Windows Server 2003 Datacenter Edition
中使用多数节点集仲裁。
尽管构成 MNS 的磁盘在理论上说可以是共享存储结构上的磁盘，但作为 Windows Server 2003 的一部分
提供的 MNS 实现使用各个节点本地系统磁盘上的目录来存储仲裁数据。如果群集配置发生变化，这种变
化将被反映到各个不同磁盘上。只有对以下数目的节点都进行了更改，这种更改才被认为是完成的，即成
为持久性更改：
（<群集中配置的节点数目>/2) + 1
这保证了大多数节点都可以获得最新的数据副本。如果被配置为群集成员的大多数节点都能正常运行群集
服务，群集服务会直接启动，并且让资源联机。如果只是少数节点，群集会被告知没有仲裁，因此群集服
务会始终等待（试图重新启动），直到更多的节点试图加入进来。只有当大多数节点都可用或者节点仲裁
可用时，群集服务才会启动，并且资源才会联机。在这种方式下，由于不考虑节点故障就将最新的配置写
入大多数节点，因此群集会始终保证它仅在最近和最新的配置下被启动。
当发生故障或“各自为政”的情况时，所有未包含大多数节点的派别都将被终止。这保证了如果有一个运行
的派别包括了大多数节点，该派别将可以随意启动过去未在该派别上运行的任何资源，换言之，它将是群
集中唯一能运行资源的派别（因为其它所有派别都被终止）。
由于清楚了共享磁盘仲裁群集同 MNS 仲裁群集在行为方式上的区别，因此用户在确定要选择的模型时必
须谨慎。例如，如果您的群集中只有两个节点，则最好不要使用 MNS 模型，因为一旦某个节点发生故障
，将导致整个群集失败（因为不可能存在多数节点）。
群集资源
群集服务使用资源监视器和资源 DLL 将所有资源都作为不透明的对象进行管理。资源监视器接口为群集
服务启动资源管理命令和获取资源状态数据提供了标准的通讯接口。资源监视器通过资源 DLL 执行实际
的命令和获取数据。群集服务使用资源 DLL 将资源联机、管理这些资源同其它群集资源的交互，单更为
重要的是通过监视它们的健康状况来检测故障情况。
服务器群集提供的资源 DLL 可以同时支持 Microsoft 群集感知应用程序和独立软件供应商 (ISV) 以及
第三方公司提供的通常不能感知群集的应用程序。另外，ISV 和第三方也可以提供让它们的特定产品能够
感知群集的资源 DLL。有关当前可感知群集的应用程序和硬件的详细信息，请参阅“详细信息”一节。
为支持资源管理，资源 DLL 仅需要提供少量的简单资源接口和属性。资源监视器可将特定的资源 DLL 作
为系统帐户下优先运行的代码载入其地址空间。系统帐户是仅供操作系统以及同基础操作系统集成的服务
所使用的帐户。借助系统帐户，群集服务可以在操作系统的上下文中执行多种功能。有关 Windows
Server 2003 或 Windows 2000 系统服务架构以及帐户安全性的详细信息，请访问：
http://www.microsoft.com/windows2000/techinfo/howitworks/default.asp
Microsoft 为 Microsoft 群集感知应用程序提供的所有资源 DLL 都仅在单一的资源监视器进程中运行。
ISV 或第三方资源 DLL 可能需要有自己的资源监视器。当在群集节点上安装或启动资源时，群集服务会
根据需要创建资源监视器进程。
如果某些资源要求有其它资源才能工作，这些依存关系可以通过资源 DLL 来定义。如果某个资源依赖于
其它资源，则群集服务只有在该资源所依存的资源按照正确的序列联机后才会让该资源联机。
资源的脱机方式与此类似。群集服务只有在任何所依存的资源已脱机后才会将有关资源脱机。这可以防止
在加载资源时导致依存关系循环。
每个资源 DLL 都可以定义资源所要求的计算机类型和设备连接类型。例如，磁盘资源可能要求只有同该
磁盘设备物理相连的节点才能拥有它。在资源 DLL 中还可以定义本地重启策略以及在故障转移事件期间
希望执行的操作。
借助随 Windows server 2003 产品一起提供的资源 DLL，服务器群集可以支持以下资源：
• 文件和打印共享
• 通用服务或应用程序
• 通用脚本
• 物理磁盘
• Microsoft 分布式事务协调器 (MSDTC)
• Internet 信息服务 (IIS)
• 消息队列 (MSMQ) 触发器
• 网络地址和名称
Windows Server 2003 Enterprise Edition 和 Windows Server 2003 Datacenter Edition 中还包括用
于以下附加服务的资源 DLL：
• 分布式文件系统 (DFS)
• 动态主机配置协议 (DHCP) 服务
• Windows Internet 服务 (WINS)
提供了自己的资源 DLL 和资源监视器的群集感知应用程序可以实现高级的可扩展性和故障转移功能。例
如，带有自己的数据库资源 DLL 的数据库服务器应用程序允许群集服务将单个的数据库从一个节点故障
转移到另一节点。如果没有特定的数据库资源 DLL，数据库应用程序将使用默认的通用服务器应用程序资
源 DLL 在群集上运行。当使用通用的应用程序服务器资源 DLL 时，群集服务只能将整个通用的服务器应
用程序（包括其数据库）进行故障转移。但如果使用单独的资源 DLL（比如数据库资源 DLL），数据库可
以作为群集服务可以监视和管理的资源被对待。这样，应用程序就不再是服务器群集可以管理的唯一资源
单位和故障转移单位。借此可以在不同的群集节点上同时运行某个应用程序的多个实例，并且每个实例都
有自己的数据库组合。为了实现可感知群集的应用程序，提供定义了应用程序特定资源的资源 DLL 还只
是第一步。
有关创建群集服务器资源 DLL 的信息，请访问：
http://msdn.microsoft.com/library/backgrnd/html/msdn_mscs_resource_dlls.htm
群集管理
群集的管理是使用 Cluster Administrator（一个图形化的管理员工具，通过它可执行维护、监视和故障
转移管理）来实现的。另外，服务器群集还提供了一个自动化接口，借此可创建管理群集资源、节点和群
集自身的自定义脚本工具。无论应用程序和管理工具（如 Cluster Administrator）是运行在群集节点上
还是在外部计算机上，它们都可以使用 RPC 访问该接口。该管理接口提供了对本文所述的群集组件管理
器的访问，从而可以实现对群集实体（如节点、资源、资源组）和群集自身的管理。有关使用该自动化接
口开发管理工具的信息，请参阅 Windows 平台软件开发人员工具包 (SDK) 的群集章节：
http://www.msdn.microsoft.com/library
有关使用 Cluster Administrator 的信息，请参阅 Windows Server 2003 Enterprise Edition 和
Windows Server 2003 Datacenter Edition 中的产品帮助。
群集的形成和操作
一旦在服务器上安装并运行了群集服务，该服务器即可加入群集。群集化操作可以减少单点故障数量，并
且实现了群集化资源的高可用性。下述各节简要介绍了群集创建和群集操作中的节点行为。
注意： 有关安装群集服务器的信息，请参阅 Windows server 2003 产品家族的帮助和部署指南。
创建群集
在服务器群集产品中含有用来在服务器上安装群集软件和创建新群集的群集安装实用工具。创建新群集时
，首先在选择作为群集的第一个成员的计算机上运行该实用工具。第一步是确定群集名称并创建群集数据
库和初始的群集成员列表来定义新群集。Windows server 2003 群集新增了一个群集管理设置向导以及使
用 cluster.exe 命令行界面创建（包括从远程创建）群集的功能。
创建群集的第二步是，添加可供所有群集成员使用的共用数据存储设备。这样，创建的新群集将带有一个
节点、自己的本地数据存储设备以及群集共用资源——通常是磁盘或数据存储和连接介质资源。
创建群集的最后一步是，在另外将要成为群集成员的每一台计算机上运行安装实用工具。每当将新节点添
加到群集中时，新节点都会自动从群集的原始成员获得现有群集数据库的副本。当节点加入或形成群集时
，群集服务会更新该节点私有的配置数据库副本。
形成群集
如果服务器运行了群集服务并且无法找到群集中的其它节点，它自己可以形成一个群集。要形成群集，节
点必须能够获得对仲裁资源的独占权。
当最初形成群集时，群集中的第一个节点将包括群集配置数据库。每当有新节点加入群集时，新节点都会
在本地获得并保持群集配置数据库的副本。仲裁资源用恢复日志（其中含有同节点无关的群集配置和状态
数据）的形式存储配置数据库的最新版本。
在群集运行中，群集服务使用仲裁恢复日志执行以下操作：
• 保证只有一组活动、可相互通讯的节点才能形成群集
• 仅当某个节点可以获得对仲裁资源的控制权时，才允许它形成群集
• 仅当某个节点可以同控制仲裁资源的节点通讯时，才允许它加入或留在现有群集中
从群集中的其它节点和群集服务管理接口的角度看，当形成群集时，群集中的每个节点可能处于三种不同
状态中的一种。事件处理器会记录这些状态，而事件日志管理器会将这些状态复制到群集的其它节点。群
集服务状态包括：
• 脱机。此时的节点不是完全有效的群集成员。该节点及其群集服务器可能在运行，也可能未运行
。
• 联机。此时的节点是完全有效的群集成员。它遵从群集数据库的更新、对仲裁算法施加自己的影
响、维护心跳通讯，并可以拥有和运行资源组。
• 暂停。此时的节点是完全有效的群集成员。它遵从群集数据库的更新、对仲裁算法施加自己的影
响、维护心跳通讯，但它无法接受资源组。它只能支持它当前已拥有的那些资源组。之所以提供暂停状态
，是为了允许执行某些维护。大多数服务器群集组件会将联机和暂停视为等价的状态。
加入群集
如果一个服务器要加入现有群集，则它必须运行群集服务并且必须成功找到群集中的其它节点。在找到其
它节点后，加入的服务器必须接受群集成员资格验证，并获得群集配置数据库的副本。
加入现有群集的过程开始于 Windows Server 2003 或 Windows 2000 Service Control Manager 在节点
上启动群集服务之时。在启动过程中，群集服务会配置并装入该节点的本地数据设备。它并不会试图将共
用的群集数据设备作为节点联机，因为现有群集可能正在使用这些设备。
为了查找其它节点，会启动一个发现过程。当节点发现任何群集成员时，它将执行身份验证序列。第一个
群集成员会对新加入者进行身份验证，并且在新服务器得到成功验证后返回成功状态。如果验证不成功（
未能识别待加入节点的群集成员身份，或者它使用了无效的帐户密码），则加入群集的请求会被拒绝。
进行成功验证后，首先联机的群集节点会检查加入节点上的配置数据库副本。如果该副本已过时，对加入
服务器进行验证的群集节点会为加入的服务器发送该数据库的更新副本。刚加入群集的节点在收到复制的
数据库后，可以用它查找共享资源并根据需要将它们联机。
脱离群集
当节点关闭或群集服务被停止时，节点可能脱离群集。但当节点不执行群集操作（比如不向群集配置数据
库提交更新）时，节点也可能被迫脱离（被逐出）群集。
如果节点根据预先的计划脱离群集，它会向其它所有节点成员发送 ClusterExit 消息，通知它们它将脱
离群集。该节点不等待任何响应就会立即进行关闭资源和所有群集连接的操作。由于其余节点收到了退出
消息，因此它们不会执行在节点意外失效或网络通讯停止时发生的重新分组过程以重新确立群集成员身份
。
故障检测
故障检测和防范是服务器群集提供的关键优点。当群集中的节点或应用程序失败时，服务器群集可以通过
重启失败的应用程序或将故障系统的工作分散给幸存的群集节点来做出响应。服务器群集故障检测和防范
包括双向故障转移、应用程序故障转移、并行恢复以及自动故障恢复。
群集服务可以检测各个资源或整个节点的故障，并动态地将应用程序、数据和文件资源转移到群集中可用
的正常服务器上，然后重新启动它们。借此，数据库、文件共享和应用程序等资源可以对用户和客户端应
用程序保持高度可用性。
服务器群集在设计上带有两个不同的故障检测机制：
• 心跳通讯，用于检测节点故障。
• 资源监视器和资源 DLL，用于检测资源故障。
检测节点故障
群集的各个节点在相互间会定期使用专用的群集网络交换数据报消息。这些消息被称作心跳。通过心跳通
讯，每个节点可以检查其它节点以及它们的应用程序的可用性。如果服务器没有对心跳通讯做出响应，则
正常工作的服务器会启动故障转移过程（包括对故障服务器拥有的资源和应用程序的所有权进行仲裁）。
仲裁是使用质询和辩护协议来执行的。换言之，如果某个节点似乎发生了故障，则会在给定的时间内允许
它以几种方式中的任何一种表明它仍处于正常运行当中，并且可以同其它正常的节点通讯。如果它无法证
明，则此时会将它移出群集。
多种事件都可能导致节点无法响应心跳消息，比如计算机故障、网络接口故障、网络故障，甚至可能是由
于少有的高峰活动期。通常来说，当所有节点进行通讯时，配置数据库管理器会向每个节点发送全局性的
配置数据库更新。但当发生心跳通讯失败时，日志管理器还会将配置数据库的变更保存到仲裁资源中。这
保证了幸存的节点可以在恢复过程中访问最新的群集配置和本地节点的注册表项数据。
要注意的是，故障检测算法相当保守： 换句话说，它会尽量多地给那些明显发生故障的节点以质询的机
会，然后才会进入故障转移过程。如果导致心跳响应失败的原因是暂时的，避免故障转移所可能造成的潜
在影响当然是再好不过。但是，由于无法知道这样的节点还将沉默多少时间，因此该节点可能遭受长时期
的故障影响。因此，在经过一个合理的时间段后，就应该启动故障转移。
检测资源故障
故障转移管理器和资源监视器可联同检测资源故障并实现从资源故障的恢复。资源监视器通过使用资源
DLL 对资源进行定期轮询来跟踪资源状态。轮询包括两个步骤，即一个短促的 LooksAlive 查询和一个时
间较长并且更权威的 IsAlive 查询。当资源监视器检测到资源故障时，它会通知故障转移管理器并且继
续监视该资源。
故障转移管理器将维护资源和资源组的状态。它还负责在资源发生故障时执行恢复操作，并且调用资源监
视器来响应用户操作或故障。
检测到资源故障后，故障转移管理器可以执行恢复操作，这包括重启资源及其依存的资源，或者将整个资
源组转移到另外的节点上。资源和资源组的属性以及节点的可用性将决定要执行的是哪种恢复操作。
为了保证能正确恢复资源依存关系，在故障转移过程中，资源组将被作为故障转移单位。一旦资源从故障
中恢复，资源监视器就会通知故障转移管理器，而后者又可以基于资源组故障转移属性的配置，接着执行
资源组的自动故障转移。
未来方向
同基于 Windows 的产品一样，服务器群集的将来发展也将立足于以下主要环节：
• 更方便地安装和检查群集配置，包括对新型硬件的支持。
• 继续支持地理位置分散的群集，实现能容忍灾难的配置。
• 对基于群集的应用程序进行更简单、更有效的管理，包括继续关注脚本化、远程和快捷管理。
• 将群集的可用性和可扩展性优点扩展到更多的系统服务身上。
• 将基础设施和所有基于 Windows 的群集技术的接口进行更为紧密的集成，以增强性能、灵活性
以及可管理性。
• 继续支持第三方 ISV 和公司的开发人员，使他们可以简化群集感知应用程序的开发、安装和支
持，从而实现更高的可用性和更高的可扩展性。
注意： 第三方开发者可以根据上述要求来创建独特的、具有群集感知能力的仲裁资源类型。有关开发群
集感知产品的信息，请访问 MSDN 上的 Platform SDK
