Windows 群集体系结构

上一次修改主题： 2005-05-23

Microsoft Windows NT Server 4.0 企业版中的 Microsoft Cluster Server (MSCS) 是 Microsoft 提供的第一个服务器群集技术。组成群集的各个服务器称为节点。群集服务是每个节点上执行特定于群集的任务的组件所构成的集合。群集中的硬件和软件组件由群集服务进行管理，这些组件称为资源。服务器群集提供了通过资源 DLL 来管理资源的检测机制，而资源 DLL 定义了资源抽象（换句话说，它们从具体物理节点抽象出群集资源，使资源能够从一个节点移动到另一个节点）、通信接口和管理操作。

资源是群集中的元素，这些元素具有以下特征：

• 被设为联机（在服务中）和设为脱机（不在服务中）
• 在服务器群集中进行管理
• 每次只能被一个节点拥有

资源组是一个资源集合，这些资源由群集服务将其作为单个的逻辑单位进行管理。这样的逻辑单位通常称为故障转移单位，因为整个组作为单个单位在节点之间移动。资源和群集元素按照添加到资源组中的资源进行逻辑分组。如果群集服务操作是针对资源组执行的，则操作会影响该组中包含的所有单个资源。通常，所创建的资源组包含了群集程序所需的各个资源。

群集资源可能包括物理硬件设备（例如，磁盘驱动器和网卡）以及逻辑项（例如，IP 地址、网络名称和应用程序组件）。

群集还包括公用资源，例如，外部数据存储阵列和私人群集网络。公用资源可被群集中的每个节点访问。一种公用资源是仲裁资源，它在群集操作中扮演重要角色。仲裁资源必须对所有节点操作都是可访问的，这些操作包括形成、加入或修改群集。

服务器群集

Windows Server 2003 企业版提供了两种类型的群集技术，这两种技术均可用于 Exchange Server 2003 企业版。第一种是群集服务，它为需要高级别可用性的后端邮箱服务器提供故障转移支持。第二种是网络负载平衡 (NLB)，它支持高可用和可缩放的前端 Exchange 协议虚拟服务器（例如，HTTP、IMAP4 和 POP3）群集，因而成为服务器群集的补充。

服务器群集使用无共享模型。模型类型定义了群集中的服务器如何管理和使用本地和公用的群集设备和资源。在无共享群集中，每个服务器都拥有和管理它的本地设备。群集所公用的设备（例如，公用磁盘阵列和连接媒体）则每次只由一个节点有选择地拥有和管理。

服务器群集使用标准的 Windows 驱动程序来连接本地存储设备和媒体。对于必须可以被群集中的所有服务器访问的外部公用设备，服务器群集支持这些设备使用多个连接媒体。外部存储设备支持标准的基于 PCI 的 SCSI 连接、光纤通道 SCSI 和具有多个发起方的 SCSI 总线。光纤连接是驻留在光纤通道总线而不是 SCSI 总线上的 SCSI 设备。

下图列出了一个双节点服务器群集的组件，该群集由运行 Windows Server 2003 企业版的服务器组成，服务器之间采用使用 SCSI 或光纤通道 SCSI 的共享存储设备连接。

服务器群集体系结构

服务器群集被设计为单独、隔离的组件集，这些组件与 Windows Server 2003 一起紧密配合工作。对操作系统的修改是在安装群集服务时启用的。这些修改包括：

• 支持动态创建和删除网络名称和地址
• 修改文件系统，以便在磁盘驱动器卸除期间能够将打开的文件关闭
• 修改存储子系统，以便能够在多个节点之间共享磁盘和卷

除了这些和其他次要修改以外，运行 Windows 群集服务的服务器与不运行 Windows 群集服务的服务器的运行情况相同。

群集服务是服务器群集的核心。群集服务由多个功能单位组成，它们包括节点管理器、故障转移管理器、数据库管理器、全局更新管理器、检查点管理器、日志管理器、事件日志复制管理器和备份/还原管理器。

群集服务组件

群集服务运行在 Windows Server 2003 企业版上，它使用了专门为服务器群集及其组件进程而设计的网络驱动程序、设备驱动程序和资源管理进程。群集服务包括以下组件：

• 检查点管理器 该组件将应用程序注册表项保存在存储于仲裁资源上的群集目录中。为了确保发生资源失败后可以恢复群集服务，当资源被设为联机时检查点管理器将检查注册表项，而当资源转到脱机时则将检查点数据写入仲裁资源中。检查点管理器所支持的资源还可以具有在转为联机的资源所在群集节点上被实例化的、特定于应用程序的注册表目录树。资源可以有一个或多个与其关联的注册表目录树。资源处于联机状态时，检查点管理器将监视这些注册表目录树的更改。如果检查点管理器检测到更改，它将把注册表目录树传输给资源的所有者节点。然后，检查点管理器将文件传输给仲裁资源的所有者节点。检查点管理器执行批传输，以便对注册表目录树的频繁更改不会对群集服务产生太沉重的负载。

• 数据库管理器 数据库管理器维护有关群集中所有物理和逻辑实体的群集配置信息。这些实体包括群集本身、群集节点成员身份、资源组、资源类型和具体资源的描述（例如，磁盘和 IP 地址）。
  存储在配置数据库中的永久和不稳定的信息用于跟踪群集的当前和希望的状态。运行在群集内每个节点上的每个数据库管理器实例进行合作，以使整个群集内的配置信息保持一致，并确保所有节点上的配置数据库副本的一致性。
  数据库管理器还提供了供其他群集组件（例如，故障转移管理器和节点管理器）使用的接口。该接口类似于 Microsoft Win32 µÄ×¢²á±í½Ó¿Ú¡£但是，数据库管理器接口将把对群集实体的更改同时写入注册表和仲裁资源中。
  数据库管理器支持对群集注册表配置单元进行事务更新，并且只向内部群集服务组件呈现接口。故障转移管理器和节点管理器通常使用该事务支持来获得被复制的事务。群集 API 将所有数据库管理器函数呈现给客户端，但事务支持函数除外。有关群集 API 的其他信息，请参阅 MSDN 上的 Cluster API（英文）。

  注意：
  应用程序注册表项数据和更改将由检查点管理器记录在仲裁资源内的仲裁日志文件中。

• 事件服务 事件服务充当切换面板，用于向应用程序发送事件以及从应用程序接收事件，并向每个节点上的群集服务组件发送事件。事件服务的事件处理器组件帮助群集服务组件将有关重要事件的信息散发给其他所有组件。事件处理器组件支持群集 API 事件机制。它还执行其他服务，例如，将信号事件传递给群集感知的应用程序，以及维护群集对象。

• 事件日志复制管理器 事件日志复制管理器将事件日志条目从一个节点复制到群集中其他所有节点。默认情况下，群集服务与群集中的 Windows 事件日志服务交互，以便将事件日志条目复制到所有群集节点。群集服务在节点上启动时，它将调用本地事件日志服务中的私人 API，并请求事件日志服务绑定到该群集服务。然后，通过使用本地远程过程调用 (RPC) 将事件日志服务绑定到 CLUSAPI 接口。事件日志服务收到要记录的事件时，它将该事件记录在本地，并将事件放到永久批队列中，然后，如果没有已处于活动状态的计时器线程，它将把一个计时器线程设定为在下一个 20 秒内运行。当计时器线程激发时，它会处理批队列，并将事件作为一个合并缓冲器发送到事件日志服务先前所绑定的群集 API 接口。然后，群集 API 接口将事件发送到群集服务。
  群集服务从事件日志服务收到分批事件之后，它会将事件置于本地传出队列中，并从 RPC 返回。然后，群集服务中的事件广播线程处理该队列，并使用群集内 RPC 将事件发送到所有活动的群集节点。然后，服务器端 API 将事件置于传入队列中。然后，事件日志编写器线程将处理该队列，并通过私人 RPC 请求本地事件日志服务在本地写入事件。
  群集服务使用轻型远程过程调用 (LRPC) 来调用事件日志服务的私人 RPC 接口。事件日志服务还使用 LRPC 来调用群集 API 接口，然后请求群集服务复制事件。

• 故障转移管理器 故障转移管理器执行资源管理工作，并启动相应的操作，例如启动、重新启动和故障转移。故障转移管理器停止和启动资源、管理资源依赖性，并启动资源组的故障转移。若要执行这些操作，故障转移管理器需要从资源监视器和群集节点接收资源和系统状态信息。
  故障转移管理器还决定群集中的哪些节点应当拥有哪个资源组。资源组仲裁完成后，拥有单个资源组的节点将把对资源组中的资源的控制权返回给节点管理器。如果节点无法处理某个资源组的失败，则每个节点上的故障转移管理器将一起配合工作，以便重新指定该资源组的所有权。
  如果资源失败，则故障转移管理器将重新启动该资源，或者让该资源与它的依赖资源一起脱机。如果故障转移管理器让该资源脱机，它将指示此资源的所有权将转交给另一个节点。然后，该资源在新节点拥有它的所有权的情况下重新启动。这称为故障转移，本主题随后的“群集故障转移”部分对此进行了解释。

• 全局更新管理器 全局更新管理器提供群集组件所使用的全局更新服务。全局更新管理器由内部群集组件（例如，故障转移管理器、节点管理器和数据库管理器）用来跨节点向群集数据库复制更改。全局更新管理器更新通常由于群集 API 调用而启动。全局更新管理器更新在客户端节点启动时，它首先请求一个锁定者节点获得全局锁定。如果锁定不可用，客户端将等待一个能够可用的锁定。
  当锁定可用时，锁定者将把锁定授予该客户端，并在本地（在锁定者节点上）发出更新。然后，客户端向所有其他无故障节点（包括它本身）发出更新。如果对锁定者的更新成功，但在某些其他节点上失败，那么将从当前群集成员身份中删除该节点。如果对锁定者节点本身的更新失败，则锁定者只是将失败返回客户端。

• 日志管理器 日志管理器将这些更改写入存储在仲裁资源上的恢复日志。日志管理器与检查点管理器一起确保仲裁资源上的恢复日志中包含最新的配置数据和更改检查点。如果一个或多个群集节点停机，仍然可以对其余节点进行配置更改。这些节点停机时，数据库管理器将使用日志管理器来记录对仲裁资源的配置更改。
  失败的节点返回到服务时，它们将从其本地群集注册表配置单元中读取仲裁资源的位置。由于配置单元数据可能是陈旧的，因此设置了相应机制来检测从陈旧的群集配置数据库中读取的无效仲裁资源。然后，数据库管理器请求日志管理器使用仲裁资源中的检查点文件来更新群集配置单元的本地副本。然后，日志文件在仲裁磁盘中从检查点日志序列号开始进行重播。结果将产生经过完全更新的群集配置单元。一旦仲裁日志被重置就将取得群集配置单元快照，并且每隔四小时执行一次。

• 成员身份管理器 成员身份管理器用于监视群集中所有节点的群集成员身份和运行状况。成员身份管理器（也称为重新组合引擎）维护一个哪些群集节点当前正常运行或停机的一致视图。成员身份管理器组件的核心是一种重新组合算法，只要有一个或多个节点失败的证据就会调用该算法。完成算法后，所有参与计算的节点都会对新的群集成员身份得出相同的结论。

• 节点管理器 节点管理器用于根据组首选项列表和节点可用性来指定对节点的资源组所有权。节点管理器运行在每个节点上，并维护一个由属于群集的本地节点所组成的列表。节点管理器定期地将名为“检测信号”的消息发送给运行在群集中其他节点上的相应项，以检测节点是否失败。群集中的所有节点必须具有完全相同的群集成员身份视图。
  如果群集节点检测到与另一个群集节点的通信失败，它将向整个群集传输一条多播消息。该重新组合事件将导致所有成员验证它们的当前群集成员身份视图。在重新组合事件期间，群集服务将阻止对群集中的所有节点所公用的任何磁盘设备执行写入操作，直到成员身份已经稳定。如果单个节点上的节点管理器实例没有做出响应，将从群集中删除该节点，并且它的活动资源组将移动到另一个活动节点。为了进行该更改，节点管理器将识别出可能拥有单个资源的可能的所有者（节点），同时识别出资源组首选运行于其上的节点。然后，节点管理器选择该节点，并移动资源组。在双节点群集中，节点管理器只需要将资源组从失败节点移动到另一个节点。在由三个或更多个节点组成的群集中，节点管理器有选择地在其余节点中分散资源组。
  节点管理器还充当网关守卫，允许将连接符节点加入到群集中并处理添加或排除节点的请求。

• 资源监视器 资源监视器用于通过使用对资源 DLL 的回调来验证每个群集资源的运行状况。资源监视器运行单独的进程，并通过 RPC 与群集服务器通信。这样可以保护群集服务不会受单个群集资源失败的影响。
  资源监视器提供资源 DLL 和群集服务之间的通信接口。当群集服务必须从资源获得数据时，资源监视器将接收请求并将它转发给相应的资源 DLL。相反，当资源 DLL 必须报告它的状态或将某个事件通知群集服务时，资源监视器将把来自该资源的信息转发给群集服务。
  资源监视进程 (RESRCMON.EXE) 是群集服务进程 (CLUSSVC.EXE) 的子进程。资源监视器加载在其进程空间中用于监视群集资源的资源 DLL。在与群集服务进程分隔的进程中加载资源 DLL 将有助于隔离故障。可以同时实例化多个资源监视器。
  每个资源监视器都充当了群集服务进程的一个 LRPC 服务器。当群集服务收到需要与资源 DLL 交谈的群集 API 调用时，它将使用 LRPC 接口来调用资源监视器 RPC。为了从资源监视器收到响应，群集服务将为每个资源监视器进程创建一个通知线程。该通知线程将调用永久位于资源监视器中的 RPC。当它们生成时，线程将获得通知。只有当资源监视器失败，或者当线程被来自群集服务的关闭命令手动停止时，此线程才会被释放。
  资源监视器不会独自维持永久状态。它会保留资源的有限的内存中状态，但它的所有初始状态信息都是由群集服务提供的。资源监视器通过 DLL 必须呈现的、正确定义的入口点来与资源 DLL 通信。资源监视器独自完成以下操作：

  • 它通过 IsAlive 和 LooksAlive 入口点轮询资源 DLL，交替检查资源 DLL 所通知的失败事件。
  • 为了对资源 DLL 的挂起超时进行监视，它产生了计时器线程，该线程可以从 DLL 的联机或脱机入口点返回 ERROR_IO_PENDING。
  • 它检测群集服务的崩溃，并关闭资源。
    它的其他操作是为了响应群集服务通过 RPC 接口所请求的操作而发生的。群集服务不执行挂起检测。但是，群集服务会监视崩溃，如果它检测到进程崩溃，它将重新启动监视器。
    群集服务和资源监视器进程共享由页面文件支持的内存映射节。内存节的句柄会在资源监视器启动时被传递给资源监视器。然后，资源监视器复制该句柄，并在调用资源 DLL 入口点之前立即将入口点编号和资源名称记录到该节中。如果资源监视器崩溃，群集服务将读取该共享节，以检测导致崩溃的资源和入口点。

• 备份/还原管理器 备份/还原管理器与故障转移管理器和数据库管理器配合工作，以备份或还原仲裁日志文件和所有检查点文件。群集服务使用 BackupClusterDatabase API 来进行数据库备份。首先，BackupClusterDatabase API 与故障转移管理器层联系。故障转移管理器层将请求转发给当前拥有仲裁资源的节点。然后，该节点调用数据库管理器，由后者对仲裁日志文件和所有检查点文件进行备份。
  群集服务还会在启动时将它自己作为备份编写器向卷影复制服务进行注册。当备份客户端调用卷影复制服务来执行系统状态备份时，它还会通过一系列入口点调用来调用群集服务，以执行群集数据库备份。群集服务中的服务器代码将调用故障转移管理器以执行备份，其余操作则通过 BackupClusterDatabase API 发生。
  群集服务使用 RestoreClusterDatabase API 从一个备份路径还原群集数据库。这个 API 只能在本地从一个群集节点进行调用。当 RestoreClusterDatabase API 被调用时，它将停止群集服务，并从备份还原群集数据库，然后设置一个包含备份路径的注册表值，然后重新启动群集服务。启动时，群集服务将检测到请求执行还原操作，因此会将群集数据库从备份路径还原到仲裁资源。

群集故障转移

故障转移可以因为非计划的硬件或软件失败而自动发生，它也可以由于管理员手动启动而发生。两种情况中的算法和行为几乎是相同的。但是，在手动启动的故障转移中，资源将被按顺序关闭；而在非计划的故障转移中，资源则以突然和破坏性的方式（例如，停电或至关紧要的硬件组件失败）关闭。

当群集中某个节点完全失败时，它的资源组将转移到群集中一个或多个可用的节点。自动故障转移类似于计划好的资源所有权的管理性重新指定。但是，它更复杂，这是因为按顺序进行的计划关机步骤可能被中断，也可能根本就不会发生。因此，在失败时，需要执行额外的步骤来评估群集的状态。

当网络遇到自动故障转移时，重要的是确定哪些组正运行在失败的节点上，以及哪些节点应当取得各种资源组的所有权。群集中能够驻留该资源组的所有节点都将参与对所有权的协商。该协商基于节点能力、当前负载、应用程序反馈、节点首选项列表或 AntiAffinityClassNames 属性（特定于群集的配置将讨论该属性）的使用。资源组的协商完成后，群集中的所有节点将更新它们的数据库，并跟踪哪个节点拥有了该资源组。

在有两个以上节点的群集中，每个资源组的节点首选项列表可以指定一个首选服务器，外加一个或多个优先化的备用服务器。这样就可以支持级联故障转移（在级联故障转移中，资源组可以在多次服务器失败后幸存下来）、每次级联或故障转移到其节点首选项列表上的下一个服务器。

自动故障转移的可替代方案通常称为 N+I 故障转移。该方法为所有群集组建立节点首选项列表。节点首选项列表用于标识在第一次故障转移时资源将转移到其上的备用群集节点。备用节点是群集中多数情况下处于空闲状态的服务器，或者是当失败服务器的工作负荷必须转移到备用节点时其工作负荷可以很容易被抢占的服务器。

级联故障转移假定群集中其他每个服务器都有一些多余的能力，并且可以吸收一部分其他任何失败服务器的工作负荷。N+I 故障转移假定：+I 备用服务器是多余能力的主要接收者。

群集故障回复

节点重新联机时，故障转移管理器可以决定将一个或多个资源组移回已恢复的节点。这称为故障回复。资源组的属性必须定义了首选所有者，才能故障回复到被恢复或重新启动的节点。已恢复或重新启动的节点是其首选所有者的资源组将从当前所有者转移到这个已恢复或重新启动的节点。

资源组的故障回复属性可以包括一个在其间允许进行故障回复的小时数，并包括一个对故障回复尝试次数的限制。这使群集服务能够防止在高峰处理时间内发生资源组的故障回复，或防止故障回复发生在尚未正确恢复或重新启动的节点上。

群集仲裁

每个群集都有一个称为仲裁资源的特殊资源。仲裁资源可以是有以下功能的任何资源：

• 为做出成员身份和群集状态决定的仲裁提供方法
• 为容纳配置信息提供物理存储

仲裁日志是用于整个服务器群集的配置数据库。仲裁日志包含群集配置信息，例如，作为群集组成部分的服务器、安装在群集中的资源以及这些资源的状态（例如，联机或脱机）。

仲裁在群集中很重要是因为以下两个原因：

• 一致性 群集由多个物理服务器组成，它充当了一个虚拟服务器。每个物理服务器都有一致的群集配置视图是很关键的。仲裁充当了与群集相关的所有配置信息的权威性存储库。如果群集服务无法访问和读取仲裁，它就无法启动。
• 关系断开 仲裁充当了用于避免发生拆分群集情形的关系断开裁判。当两个或更多个群集节点之间的所有网络通信链路失败时，将发生拆分群集情形。如果发生这种情况，群集可能被拆分成两个或更多个相互之间无法通信的分区。仲裁将确保群集资源只在一个节点上被设为联机。它的做法是允许获得仲裁支持的分区继续，而将其他分区逐出群集。

标准仲裁

此部分前面提到过，仲裁是群集服务的配置数据库，该数据库存储在仲裁日志文件中。标准仲裁使用的仲裁日志文件位于驻留在可以被群集的所有成员访问的共享存储阵列中的磁盘上。

每个成员都使用 SCSI 或光纤通道连接共享存储。存储由外部硬盘（通常配置为 RAID 磁盘）或 SAN（其中，SAN 的逻辑扇区被表示为物理磁盘）组成。

注意：
仲裁使用物理磁盘资源而不是磁盘分区，这是因为在故障转移期间整个物理磁盘资源被转移，这一点很重要。此外，有可能将服务器群集配置为使用服务器的本地硬盘来存储仲裁。之所以支持这种实现（称为独狼群集），只是为了测试和开发目的。独狼群集不应当用来在生产环境中组成 Exchange 2003 群集，因为其单一性使它们不能提供故障转移。

多数节点集仲裁

从服务器群集角度看，多数节点集 (MNS) 仲裁是单个仲裁资源。默认情况下，数据存储在群集中每个节点的本地磁盘上。MNS 资源确保了群集配置数据（存储在 MNS 资源上）在不同磁盘上是一致的。Windows Server 2003 中提供的 MNS 实现使用每个节点的本地磁盘上的目录来存储仲裁数据。如果群集的配置发生更改，该更改将反映在每个节点的本地磁盘上。只有在对该数目的节点进行更改后才会认为更改已提交或永久保存：(节点数/2) + 1。

MNS 仲裁确保了大多数节点都有数据的最新副本。只有当被配置为群集的一部分的多数节点都在运行，并且正在运行群集服务时，群集服务才会启动并将资源设为联机。如果 MNS 仲裁确定多数节点都不存在，则认为群集没有仲裁，并且群集服务将在重新启动循环中等待，直到更多节点尝试加入。当多数节点或节点的仲裁可用时，群集服务将启动并使资源联机。由于最新配置被写入多数节点，而不管节点是否失败，因此群集总能保证它在启动时有最新的配置。

如果发生群集失败，或群集以某种方式进入拆分群集情形，则不包含多数节点的所有分区都会设为脱机。这就确保了如果有包含多数节点的、正在运行的分区，那么它就可以安全启动任何不运行在该分区上的资源，因为它是群集中正在运行资源的唯一分区。

由于共享磁盘仲裁群集的行为方式与 MNS 仲裁群集相比存在差异，因此在决定要使用哪个模型时必须进行仔细考虑。例如，如果群集中只有两个节点，则建议您不要使用 MNS 模型。在该示例中，一个节点的失败将导致整个群集失败，这是因为不可能有多数节点。

多数节点集 (MNS) 仲裁在 Windows Server 2003 企业版和 Windows Server 2003 Datacenter 版群集中可用。MNS 群集为 Exchange 群集所提供的唯一好处是消除了对共享存储阵列中用来存储仲裁资源的专用磁盘的需要。

群集资源

群集服务使用资源监视器和资源 DLL 来管理所有资源对象。资源监视器接口提供了标准通信接口，该接口使群集服务能够启动资源管理命令并获得资源状态数据。资源监视器通过资源 DLL 获得实际的命令函数和数据。群集服务使用资源 DLL 来使资源联机、管理它们与群集中其他资源的交互并监视它们的运行状况。

为了启用资源管理，资源 DLL 将使用几个简单资源接口和属性。资源监视器加载其地址空间中特定的资源 DLL，该 DLL 作为特权代码运行在 SYSTEM 帐户下面。SYSTEM 帐户（即 LocalSystem）是代表操作系统的安全主体帐户。群集服务（运行在用户安全上下文下面）使用 SYSTEM 帐户来执行操作系统中的安全功能。

当资源依赖于其他资源的可用性才能正常工作时，这些依存关系可以被资源 DLL 定义。当资源依赖于其他资源时，群集服务只有在将该资源所依赖的资源按正确顺序设为联机之后，才会将该依赖资源设为联机。

将资源设为脱机的方式与此类似。群集服务只有在将任何依赖资源设为脱机之后，才会将依赖它们的资源设为脱机。这样可以防止在加载资源时引入循环依存关系。

每个资源 DLL 还可以定义该资源所需的计算机和设备连接的类型。例如，某个磁盘资源可能要求仅由物理连接到该磁盘设备的节点拥有对它的所有权。还可以在资源 DLL 中定义在故障转移事件期间执行的本地重新启动策略和希望的操作。

群集管理

管理群集的工具是群集管理器。群集管理器是图形化的管理员工具，它使 Cluster.exe 命令行工具能够执行维护、监视和故障转移管理。服务器群集还提供了自动化接口。该接口可以用来创建自定义脚本工具，以便管理群集资源、节点和群集本身。应用程序和管理工具（例如，群集管理器）可以使用 RPC 访问该接口，不管工具运行在群集中的节点上，还是运行在外部计算机上。

群集信息和操作

在服务器上安装并运行群集服务后，该服务器即可参与群集。群集操作减少了单点故障，并使群集资源能够实现高可用性。下面的部分简短描述了在群集创建和操作期间的节点行为。

创建群集

服务器群集包括群集安装实用程序，该程序可以用来将群集软件安装在服务器上，并新建群集。若要新建群集，需要在被选为群集的第一个成员的计算机上运行该实用程序。第一步通过建立群集名称并创建群集数据库和初始群集成员身份列表，从而定义了新的群集。

创建群集的下一步是添加可供群集内所有成员使用的公用数据存储设备。这将建立具有单个节点及其自己的本地数据存储设备的新群集以及群集公用资源（通常是磁盘或数据存储以及连接媒体资源）。

创建群集的最后一步是在将成为群集成员的其他每台计算机上运行安装实用程序。每个新节点被添加到群集中时，它将从群集的原始成员那里自动接收一份现有群集数据库的副本。当节点加入群集或形成群集时，群集服务就会更新该节点的私人配置数据库副本。

形成群集

如果一个服务器正在运行群集服务并且无法找到群集中的其他节点，那么它可以形成一个群集。若要形成群集，节点必须能够获得对仲裁资源的独占所有权。

群集形成后，群集中的第一个节点将包含群集配置数据库。其他每个节点加入群集时，它将接收和维护它自己的群集配置数据库本地副本。仲裁资源将配置数据库的最新版本作为恢复日志存储起来。日志中包含与节点无关的群集配置和状态数据。

在群集操作期间，群集服务将使用仲裁恢复日志执行以下任务：

• 保证只允许一组活动节点形成群集
• 使节点只有在获得对仲裁资源的控制权时才能形成群集
• 只有节点可与控制仲裁资源的节点通信时，才允许该节点加入现有群集或留在现有群集中

群集形成后，群集中的每个节点都可以处于三个明显不同状态中的某一个状态。这些状态被事件处理器（在下面描述）记录下来，并被事件日志管理器复制到群集中的其他节点。三个群集服务状态是：

• 脱机 节点不是群集的活动成员。节点和它的群集服务可能正在运行，也可能没有运行。
• 联机 节点是群集的活动成员。它接收群集数据库更新、向仲裁算法提供输入、维护群集网络和存储检测信号，并且可以拥有并运行资源组。
• 暂停 节点是群集的活动成员。节点接收群集数据库更新、向仲裁算法提供输入，并维护网络和存储检测信号，但它无法接受资源组。它只能支持那些它当前拥有的资源组。暂停状态使维护工作得以执行。联机和暂停状态被多数服务器群集组件视为等同的状态。

加入群集

若要加入现有群集，服务器必须运行群集服务，并且它必须成功找到群集中的另一个节点。在找到群集中的另一个节点之后，要加入群集的服务器必须进行身份验证，以验证其在群集中的成员身份，并且必须接收群集配置数据库的复制副本。

加入现有群集的过程从 Windows 服务控制管理器启动该节点上的群集服务开始。在启动过程中，群集服务将配置和装入节点的本地数据设备。它不会试图将公用群集数据设备作为节点设为联机，因为现有群集可能正在使用该设备。

为了找到其他节点，将启动发现过程。节点发现群集的任何成员时，它将执行身份验证序列。第一个群集成员将对新节点进行身份验证，如果新节点成功通过身份验证，将返回成功状态。如果加入群集的节点未被识别为群集成员或者它的帐户密码无效而导致身份验证不成功，则系统拒绝其加入群集的请求。

在成功进行身份验证之后，群集中第一个联机的节点将检查新加入节点的配置数据库副本。如果它是最新的，则群集节点将向新加入的服务器发送经过更新的数据库副本。在收到被复制的数据库之后，加入群集的节点就可以用它来查找共享资源，并根据需要将它们设为联机。

脱离群集

当节点关机或群集服务停止时，该节点可以脱离群集。但是，当节点未能执行群集操作时（例如，未能将更新提交到群集配置数据库），它也可以被逐出群集。

节点在计划好的关机状态下脱离群集时，它会向群集中所有其他成员发送 ClusterExit 消息，通知它们自己将要离开。节点不会等待任何响应，它会立即继续关闭资源并关闭所有群集连接。由于其余节点收到该退出消息，所以它们不会执行重新组合过程来重建群集成员身份，而当节点意外失败或网络通信停止时就会发生该操作。

失败检测

失败检测和预防是服务器群集所提供的主要优点。群集中的节点或应用程序失败时，服务器群集可以通过重新启动失败的应用程序或将失败系统的工作分散到群集中其余节点来进行响应。服务器群集失败检测和防止包括双向故障转移、应用程序故障转移、并行恢复和自动故障回复。

当群集服务检测到单个资源或整个节点失败时，它将动态移动并重新启动群集中可用的和健康的服务器上的应用程序、数据和文件资源。这就允许资源（例如，数据库、文件共享和应用程序）对用户和客户端应用程序保持高可用性。

服务器群集的设计中使用了两种不同的失败检测机制：

• 用于检测节点失败的检测信号 每个节点定期通过私人群集网络与群集中的其他节点交换基于用户数据报协议的消息。这些消息称为检测信号。检测信号交换使每个节点能够检查其他节点及其资源的可用性。如果服务器未能对检测信号交换做出响应，则幸存的服务器将启动故障转移过程，这包括对失败服务器所拥有的资源和应用程序进行所有权仲裁。仲裁是使用挑战和防卫协议来执行的。看起来已经失败的节点将被给予一个时间窗口，以便以几种方式中的任何一种来演示它还在正确运行并且可以与幸存节点通信。如果节点无法进行响应，将从群集中将它删除。
  未能对检测信号消息做出响应是由几个事件导致的，例如计算机失败、网络接口失败、网络失败，甚至是很少见的高活动期间。通常，当所有节点都能通信时，配置数据库管理器将向每个节点发送全局配置数据库更新。发生检测信号交换失败时，日志管理器将把配置数据库更改保存到仲裁资源中。这样可以确保其余节点可以在恢复过程中能够访问最新的群集配置和本地节点注册表数据。
  失败检测算法是非常保守的。如果检测信号响应失败的原因是临时的，则最好是避免故障转移可能导致的潜在中断。但是，无法知道节点是否将在另一个毫秒内做出响应，或者它是否遇到了灾难性的失败。因此，在超时之后将启动故障转移。
• 用于检测资源失败的资源监视器和资源 DLL 故障转移管理器和资源监视器一起配合工作来检测资源失败并从资源失败恢复。资源监视器通过使用资源 DLL 定期地轮询资源来跟踪资源状态。轮询涉及两个步骤：简短的 LooksAlive 查询和更长、更有权威性的 IsAlive 查询。资源监视器检测到资源失败时，它将通知故障转移管理器，并继续监视该资源。
  故障转移管理器维护资源和资源组状态。它还会在资源失败时执行恢复，并调用资源监视器以响应用户操作或失败。
  在检测到资源失败之后，故障转移管理器将执行恢复操作，这些操作包括重新启动资源及其依赖资源，或将整个资源组转移到另一个节点。除了节点可用性以外，所采取的恢复操作由资源和资源组属性进行确定。
  在故障转移期间，资源组被视为故障转移单位。这确保了资源依存关系被正确恢复。资源从失败恢复正常后，资源监视器将通知故障转移管理器。然后，故障转移管理器将基于资源组故障回复属性的配置，对资源组执行自动故障回复。