WindowsServer2003服务器群集.doc

microsoft windows server 2003 technical articlewindows server 2003 服务器群集：架构概述microsoft corporation发布日期： 2003 年 3 月摘要服务器群集是 microsoft windows 服务器产品家族提供的两种 microsoft windows 群集技术中的一种。windows server 2003 为那些要求高可用性和数据完整性的后端应用和服务提供了故障转移支持。这些后端应用包括数据库、文件服务器、企业资源计划 (erp) 以及消息系统等企业应用。本白皮书立足于这种群集服务的架构和功能，介绍了其术语、概念、设计目标、关键组件和预定的发展方向。本文档所包含的信息代表了在发布之日，microsoft corporation 对所讨论问题的当前看法。因为 microsoft 必须顺应不断变化的市场条件，故该文档不应理解为 microsoft 一方的承诺，microsoft 不保证所给信息在发布之日以后的准确性。本文档仅供参考。对本文档中的信息，microsoft 不做任何明示、默示或法定的保证。遵守所有适用的版权法律是用户的责任。在不对版权法所规定的权利加以限制的情况下，如未得到 microsoft corporation明确的书面许可，不得为任何目的、以任何形式或手段（电子的、机械的、影印、录制等等）复制、传播本文的任何部分，也不得将其存储或引入到检索系统中。microsoft 可能拥有本文档主题涉及到的专利、专利申请、商标、版权或其他知识产权。除非在 microsoft 的任何书面许可协议中明确表述，否则获得本文档不代表您将同时获得这些专利、商标、版权或其它知识产权的许可证。 2003 microsoft corporation. 保留所有权利。microsoft、windows、windows徽标和windows nt是 microsoft corporation在美国和/或其它国家或地区的注册商标或商标。此处提到的实际公司和产品名称可能是其各自所有者的商标。目录目录iii简介4发展背景4群集术语6服务器群集6虚拟服务器8资源组9服务器群集架构11群集服务组件11节点管理器12数据库管理器12检查点管理器13日志管理器13故障转移管理器13故障转移14故障恢复14全局更新管理器14备份/恢复管理器15事件日志复制管理器15成员身份管理器15非群集服务组件15资源监视器15事件服务16群集仲裁18标准仲裁18多数节点集仲裁19群集资源20群集管理22群集的形成和操作23创建群集23形成群集23加入群集24脱离群集24故障检测25检测节点故障25检测资源故障25未来方向26详细信息27书籍27相关链接270server clusters :服务器群集0 architecture overviewiii microsoft windows server 2003 技术文章简介服务器群集功能最早是为 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 和 windows2000 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 操作系统的现有基础之上。服务器群集的核心正是群集服务，该服务包括几个功能单元。它们是节点管理器、故障转移管理器、数据库管理器、全局更新管理器、检查点管理器、日志管理器、事件日志复制管理器以及备份/恢复管理器。resource monitors 图 6 详细显示了这些组件之间的关系架构示意。群集服务组件群集服务运行在 windows server 2003 或 windows 2000 操作系统上，而这些操作系统又使用了专门针对服务器群集及其组成过程设计的网络驱动程序、设备驱动程序以及资源规范过程。这些同群集服务紧密相关的组件是： 检查点管理器 负责将应用程序注册表项保存到位于仲裁资源上的群集目录中。 数据库管理区 负责维护群集配置信息。 事件日志复制管理区 负责将事件日志从一个节点复制到群集中的所有其它节点。 故障转移管理区 负责执行资源管理和启动相应的操作，比如启动、重启和故障转移。 全局更新管理器 负责提供群集组件使用的全局更新服务。 日志管理器 负责将变更写入存储在仲裁资源上的恢复日志中。 成员管理器 负责管理群集的成员关系，并且监视群集中其它节点是否正常。 节点管理器 负责根据资源组首选项列表和节点的可用性来指定节点对资源组的所有权。 资源监视器 使用对资源 dll 的回调来监视每个群集资源的健康状况。资源监视器以独立的进程运行，它通过远程过程调用 (rpc) 同群集服务器通信，以保护群集服务器不受群集资源中个别故障的影响。 备份/恢复管理器 借助故障转移管理器和数据库管理器，备份或恢复仲裁日志文件和所有的检查点文件。资源dll群集 api 群 集 服 务检查点管理器节点 管理器事件日志 复制 管理器全局更新 管理器备份/恢复管理器故障转移 管理器数据库库管理器日志 管理器资源监视器windows 文件系统windows 注册表资源 dll图 5 群集服务组件示意图节点管理器 节点管理器运行在每个节点上，它维护着一个包含群集所属节点的本地列表。节点服务器会定期向在群集中其它节点上运行的节点服务器发送消息（称为“心跳”），以检测节点故障。这是保持群集中的所有节点时时刻刻都具有完全一致的群集成员身份所不可或缺的。如果一个节点检测到同另一节点的通信故障，它就会向整个群集发送多播消息，从而让所有成员都对其当前的群集成员身份进行检查。这被称作一个重新分组事件。除非已建立起稳定的成员关系，否则群集服务将禁止对所有群集节点所共用的任何磁盘设备执行写入操作。如果某个节点上的节点管理器没有响应，则该节点将被从群集中删除，其活动的资源组会被转移到另外的活动节点上。为选择应将资源组转移到哪个节点上，节点管理器会确定资源组首选运行的节点以及可以拥有单独资源的潜在拥有者（节点）。在 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 事件处理机制。事件处理器执行杂项服务，比如向那些可感知群集的应用程序发送信号事件和维护群集对象。图 6 服务器群集架构。非群集组件带有灰色背景群集仲裁每个群集都有一种特定资源，即所谓的仲裁资源。仲裁资源可能是执行以下操作的任何资源： 提供一种旨在实现成员身份和群集状态决定的仲裁机制。 提供物理性存储空间以存储配置信息。仲裁日志只是一种用于服务器群集化功能的配置数据库。它保存了多种配置信息，比如群集的成员服务器都有哪些、群集中安装了哪些资源以及这些资源处于何种状态（例如，是联机还是脱机）。默认情况下，该仲裁日志位于 mscsquolog.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 说明了这种标准仲裁。图 7 四节点群集中的标准仲裁示意多数节点集仲裁从服务器群集的发展来看，多数节点集 (mns) 仲裁将成为唯一的仲裁资源。但在默认情况下，其数据实际存储在各个群集成员的系统磁盘上。mns 资源负责确保在 mns 上存储的群集配置数据在不同磁盘上都保持一致性。图 8 显示了一个使用 mns 仲裁配置的四节点群集。您可以在 windows server 2003 enterprise edition 以及 windows server 2003 datacenter edition 中使用多数节点集仲裁。图 8 四节点群集中的 mns 仲裁示意尽管构成 mns 的磁盘在理论上说可以是共享存储结构上的磁盘，但作为 windows server 2003 的一部分提供的 mns 实现使用各个节点本地系统磁盘上的目录来存储仲裁数据。如果群集配置发生变化，这种变化将被反映到各个不同磁盘上。只有对以下数目的节点都进行了更改，这种更改才被认为是完成的，即成为持久性更改： （/2) + 1这保证了大多数节点都可以获得最新的数据副本。如果被配置为群集成员的大多数节点都能正常运行群集服务，群集服务会直接启动，并且让资源联机。如果只是少数节点，群集会被告知没有仲裁，因此群集服务会始终等待（试图重新启动），直到更多的节点试图加入进来。只有当大多数节点都可用或者节点仲裁可用时，群集服务才会启动，并且资源才会联机。在这种方式下，由于不考虑节点故障就将最新的配置写入大多数节点，因此群集会始终保证它仅在最近和最新的配置下被启动。当发生故障或“各自为政”的情况时，所有未包含大多数节点的派别都将被终止。这保证了如果有一个运行的派别包括了大多数节点，该派别将可以随意启动过去未在该派别上运行的任何资源，换言之，它将是群集中唯一能运行资源的派别（因为其它所有派别都被终止）。由于清楚了共享磁盘仲裁群集同 mns 仲裁群集在行为方式上的区别，因此用户在确定要选择的模型时必须谨慎。例如，如果您的群集中只有两个节点，则最好不要使用 mns 模型，因为一旦某个节点发生故障，将导致整个群集失败（因为不可能存在多数节点）。群集资源群集服务使用资源监视器和资源 dll 将所有资源都作为不透明的对象进行管理。资源监视器接口为群集服务启动资源管理命令和获取资源状态数据提供了标准的通讯接口。资源监视器通过资源 dll 执行实际的命令和获取数据。群集服务使用资源 dll 将资源联机、管理这些资源同其它群集资源的交互，单更为重要的是通过监视它们的健康状况来检测故障情况。服务器群集提供的资源 dll 可以同时支持 microsoft 群集感知应用程序和独立软件供应商 (isv) 以及第三方公司提供的通常不能感知群集的应用程序。另外，isv 和第三方也可以提供让它们的特定产品能够感知群集的资源 dll。有关当前可感知群集的应用程序和硬件的详细信息，请参阅“详细信息”一节。为支持资源管理，资源 dll 仅需要提供少量的简单资源接口和属性。资源监视器可将特定的资源 dll 作为系统帐户下优先运行的代码载入其地址空间。系统帐户是仅供操作系统以及同基础操作系统集成的服务所使用的帐户。借助系统帐户，群集服务可以在操作系统的上下文中执行多种功能。有关 windows server 2003 或 windows 2000 系统服务架构以及帐户安全性的详细信息，请访问：/windows2000/techinfo/howitworks/default.aspmicrosoft 为 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 的数据