群集体系结构.docx
- 文档编号:6178808
- 上传时间:2023-05-09
- 格式:DOCX
- 页数:17
- 大小:55.50KB
群集体系结构.docx
《群集体系结构.docx》由会员分享,可在线阅读,更多相关《群集体系结构.docx(17页珍藏版)》请在冰点文库上搜索。
群集体系结构
Windows群集体系结构
主题上次修改时间:
2005-05-23
MicrosoftWindowsNTServer4.0企业版中的MicrosoftClusterServer(MSCS)是Microsoft提供的第一个服务器群集技术。
组成群集的各个服务器称为节点。
群集服务是每个节点上执行特定于群集的任务的组件所构成的集合。
群集中的硬件和软件组件由群集服务进行管理,这些组件称为资源。
服务器群集提供了通过资源DLL来管理资源的检测机制,而资源DLL定义了资源抽象(换句话说,它们从具体物理节点抽象出群集资源,使资源能够从一个节点移动到另一个节点)、通信接口和管理操作。
资源是群集中的元素,这些元素具有以下特征:
∙被设为联机(在服务中)和设为脱机(不在服务中)
∙在服务器群集中进行管理
∙每次只能被一个节点拥有
资源组是一个资源集合,这些资源由群集服务将其作为单个的逻辑单位进行管理。
这样的逻辑单位通常称为故障转移单位,因为整个组作为单个单位在节点之间移动。
资源和群集元素按照添加到资源组中的资源进行逻辑分组。
如果群集服务操作是针对资源组执行的,则操作会影响该组中包含的所有单个资源。
通常,所创建的资源组包含了群集程序所需的各个资源。
群集资源可能包括物理硬件设备(例如,磁盘驱动器和网卡)以及逻辑项(例如,IP地址、网络名称和应用程序组件)。
群集还包括公用资源,例如,外部数据存储阵列和私人群集网络。
公用资源可被群集中的每个节点访问。
一种公用资源是仲裁资源,它在群集操作中扮演重要角色。
仲裁资源必须对所有节点操作都是可访问的,这些操作包括形成、加入或修改群集。
服务器群集
WindowsServer 2003企业版提供了两种类型的群集技术,这两种技术均可用于ExchangeServer 2003企业版。
第一种是群集服务,它为需要高级别可用性的后端邮箱服务器提供故障转移支持。
第二种是网络负载平衡(NLB),它支持高可用和可缩放的前端Exchange协议虚拟服务器(例如,HTTP、IMAP4和POP3)群集,因而成为服务器群集的补充。
服务器群集使用无共享模型。
模型类型定义了群集中的服务器如何管理和使用本地和公用的群集设备和资源。
在无共享群集中,每个服务器都拥有和管理它的本地设备。
群集所公用的设备(例如,公用磁盘阵列和连接媒体)则每次只由一个节点有选择地拥有和管理。
服务器群集使用标准的Windows驱动程序来连接本地存储设备和媒体。
对于必须可以被群集中的所有服务器访问的外部公用设备,服务器群集支持这些设备使用多个连接媒体。
外部存储设备支持标准的基于PCI的SCSI连接、光纤通道SCSI和具有多个发起方的SCSI总线。
光纤连接是驻留在光纤通道总线而不是SCSI总线上的SCSI设备。
下图列出了一个双节点服务器群集的组件,该群集由运行WindowsServer 2003企业版的服务器组成,服务器之间采用使用SCSI或光纤通道SCSI的共享存储设备连接。
示例双节点Windows群集
服务器群集体系结构
服务器群集被设计为单独、隔离的组件集,这些组件与WindowsServer 2003一起紧密配合工作。
对操作系统的修改是在安装群集服务时启用的。
这些修改包括:
∙支持动态创建和删除网络名称和地址
∙修改文件系统,以便在磁盘驱动器卸除期间能够将打开的文件关闭
∙修改存储子系统,以便能够在多个节点之间共享磁盘和卷
除了这些和其他次要修改以外,运行Windows群集服务的服务器与不运行Windows群集服务的服务器的运行情况相同。
群集服务是服务器群集的核心。
群集服务由多个功能单位组成,它们包括节点管理器、故障转移管理器、数据库管理器、全局更新管理器、检查点管理器、日志管理器、事件日志复制管理器和备份/还原管理器。
群集服务组件
群集服务运行在WindowsServer 2003企业版上,它使用了专门为服务器群集及其组件进程而设计的网络驱动程序、设备驱动程序和资源管理进程。
群集服务包括以下组件:
∙检查点管理器该组件将应用程序注册表项保存在存储于仲裁资源上的群集目录中。
为了确保发生资源失败后可以恢复群集服务,当资源被设为联机时检查点管理器将检查注册表项,而当资源转到脱机时则将检查点数据写入仲裁资源中。
检查点管理器所支持的资源还可以具有在转为联机的资源所在群集节点上被实例化的、特定于应用程序的注册表目录树。
资源可以有一个或多个与其关联的注册表目录树。
资源处于联机状态时,检查点管理器将监视这些注册表目录树的更改。
如果检查点管理器检测到更改,它将把注册表目录树传输给资源的所有者节点。
然后,检查点管理器将文件传输给仲裁资源的所有者节点。
检查点管理器执行批传输,以便对注册表目录树的频繁更改不会对群集服务产生太沉重的负载。
∙数据库管理器数据库管理器维护有关群集中所有物理和逻辑实体的群集配置信息。
这些实体包括群集本身、群集节点成员身份、资源组、资源类型和具体资源的描述(例如,磁盘和IP地址)。
存储在配置数据库中的永久和不稳定的信息用于跟踪群集的当前和希望的状态。
运行在群集内每个节点上的每个数据库管理器实例进行合作,以使整个群集内的配置信息保持一致,并确保所有节点上的配置数据库副本的一致性。
数据库管理器还提供了供其他群集组件(例如,故障转移管理器和节点管理器)使用的接口。
该接口类似于MicrosoftWin32µÄ×¢²á±í½Ó¿Ú¡£但是,数据库管理器接口将把对群集实体的更改同时写入注册表和仲裁资源中。
数据库管理器支持对群集注册表配置单元进行事务更新,并且只向内部群集服务组件呈现接口。
故障转移管理器和节点管理器通常使用该事务支持来获得被复制的事务。
群集API将所有数据库管理器函数呈现给客户端,但事务支持函数除外。
有关群集API的其他信息,请参阅MSDN上的ClusterAPI(英文)。
注意:
应用程序注册表项数据和更改将由检查点管理器记录在仲裁资源内的仲裁日志文件中。
∙事件服务事件服务充当切换面板,用于向应用程序发送事件以及从应用程序接收事件,并向每个节点上的群集服务组件发送事件。
事件服务的事件处理器组件帮助群集服务组件将有关重要事件的信息散发给其他所有组件。
事件处理器组件支持群集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入口点之前立即将入口点编号和资源名称记录到该节中。
如果资源监视器崩溃,群集服务将读取该共享节,以检测导致崩溃的资源和入口点。
∙备份/还原管理器备份/还原管理器与故障转移管理器和数据库管理器配合工作,以备份或还原仲裁日志文件和所有检查点文件。
群集服务使用BackupClusterDatabaseAPI来进行数据库备份。
首先,BackupClusterDatabaseAPI与故障转移管理器层联系。
故障转移管理器层将请求转发给当前拥有仲裁资源的节点。
然后,该节点调用数据库管理器,由后者对仲裁日志文件和所有检查点文件进行备份。
群集服务还会在启动时将它自己作为备份编写器向卷影复制服务进行注册。
当备份客户端调用卷影复制服务来执行系统状态备份时,它还会通过一系列入口点调用来调用群集服务,以执行群集数据库备份。
群集服务中的服务器代码将调用故障转移管理器以执行备份,其余操作则通过BackupClusterDatabaseAPI发生。
群集服务使用RestoreClusterDatabaseAPI从一个备份路径还原群集数据库。
这个API只能在本地从一个群集节点进行调用。
当RestoreClusterDatabaseAPI被调用时,它将停止群集服务,并从备份还原群集数据库,然后设置一个包含备份路径的注册表值,然后重新启动群集服务。
启动时,群集服务将检测到请求执行还原操作,因此会将群集数据库从备份路径还原到仲裁资源。
群集故障转移
故障转移可以因为非计划的硬件或软件失败而自动发生,它也可以由于管理员手动启动而发生。
两种情况中的算法和行为几乎是相同的。
但是,在手动启动的故障转移中,资源将被按顺序关闭;而在非计划的故障转移中,资源则以突然和破坏性的方式(例如,停电或至关紧要的硬件组件失败)关闭。
当群集中某个节点完全失败时,它的资源组将转移到群集中一个或多个可用的节点。
自动故障转移类似于计划好的资源所有权的管理性重新指定。
但是,它更复杂,这是因为按顺序进行的计划关机步骤可能被中断,也可能根本就不会发生。
因此,在失败时,需要执行额外的步骤来评估群集的状态。
当网络遇到自动故障转移时,重要的是确定哪些组正运行在失败的节点上,以及哪些节点应当取得各种资源组的所有权。
群集中能够驻留该资源组的所有节点都将参与对所有权的协商。
该协商基于节点能力、当前负载、应用程序反馈、节点首选项列表或AntiAffinityClassNames属性(特定于群集的配置将讨论该属性)的使用。
资源组的协商完成后,群集中的所有节点将更新它们的数据库,并跟踪哪个节点拥有了该资源组。
在有两个以上节点的群集中,每个资源组的节点首选项列表可以指定一个首选服务器,外加一个或多个优先化的备用服务器。
这样就可以支持级联故障转移(在级联故障转移中,资源组可以在多次服务器失败后幸存下来)、每次级联或故障转移到其节点首选项列表上的下一个服务器。
自动故障转移的可替代方案通常称为N+I故障转移。
该方法为所有群集组建立节点首选项列表。
节点首选项列表用于标识在第一次故障转移时资源将转移到其上的备用群集节点。
备用节点是群集中多数情况下处于空闲状态的服务器,或者是当失败服务器的工作负荷必须转移到备用节点时其工作负荷可以很容易被抢占的服务器。
级联故障转移假定群集中其他每个服务器都有一些多余的能力,并且可以吸收一部分其他任何失败服务器的工作负荷。
N+I故障转移假定:
+I备用服务器是多余能力的主要接收者。
群集故障回复
节点重新联机时,故障转移管理器可以决定将一个或多个资源组移回已恢复的节点。
这称为故障回复。
资源组的属性必须定义了首选所有者,才能故障回复到被恢复或重新启动的节点。
已恢复或重新启动的节点是其首选所有者的资源组将从当前所有者转移到这个已恢复或重新启动的节点。
资源组的故障回复属性可以包括一个在其间允许进行故障回复的小时数,并包括一个对故障回复尝试次数的限制。
这使群集服务能够防止在高峰处理时间内发生资源组的故障回复,或防止故障回复发生在尚未正确恢复或重新启动的节点上。
群集仲裁
每个群集都有一个称为仲裁资源的特殊资源。
仲裁资源可以是有以下功能的任何资源:
∙为做出成员身份和群集状态决定的仲裁提供方法
∙为容纳配置信息提供物理存储
仲裁日志是用于整个服务器群集的配置数据库。
仲裁日志包含群集配置信息,例如,作为群集组成部分的服务器、安装在群集中的资源以及这些资源的状态(例如,联机或脱机)。
仲裁在群集中很重要是因为以下两个原因:
∙一致性群集由多个物理服务器组成,它充当了一个虚拟服务器。
每个物理服务器都有一致的群集配置视图是很关键的。
仲裁充当了与群集相关的所有配置信息的权威性存储库。
如果群集服务无法访问和读取仲裁,它就无法启动。
∙关系断开仲裁充当了用于避免发生拆分群集情形的关系断开裁判。
当两个或更多个群集节点之间的所有网络通信链路失败时,将发生拆分群集情形。
如果发生这种情况,群集可能被拆分成两个或更多个相互之间无法通信的分区。
仲裁将确保群集资源只在一个节点上被设为联机。
它的做法是允许获得仲裁支持的分区继续,而将其他分区逐出群集。
标准仲裁
此部分前面提到过,仲裁是群集服务的配置数据库,该数据库存储在仲裁日志文件中。
标准仲裁使用的仲裁日志文件位于驻留在可以被群集的所有成员访问的共享存储阵列中的磁盘上。
每个成员都使用SCSI或光纤通道连接共享存储。
存储由外部硬盘(通常配置为RAID磁盘)或SAN(其中,SAN的逻辑扇区被表示为物理磁盘)组成。
注意:
仲裁使用物理磁盘资源而不是磁盘分区,这是因为在故障转移期间整个物理磁盘资源被转移,这一点很重要。
此外,有可能将服务器群集配置为使用服务器的本地硬盘来存储仲裁。
之所以支持这种实现(称为独狼群集),只是为了测试和开发目的。
独狼群集不应当用来在生产环境中组成Exchange 2003群集,因为其单一性使它们不能提供故障转移。
多数节点集仲裁
从服务器群集角度看,多数节点集(MNS)仲裁是单个仲裁资源。
默认情况下,数据存储在群集中每个节点的本地磁盘上。
MNS资源确保了群集配置数据(存储在MNS资源上)在不同磁盘上是一致的。
WindowsServer 2003中提供的MNS实现使用每个节点的本地磁盘上的目录来存储仲裁数据。
如果群集的配置发生更改,该更改将反映在每个节点的本地磁盘上。
只有在对该数目的节点进行更改后才会认为更改已提交或永久保存:
(节点数/2)+1。
MNS仲裁确保了大多数节点都有数据的最新副本。
只有当被配置为群集的一部分的多数节点都在运行,并且正在运行群集服务时,群集服务才会启动并将资源设为联机。
如果MNS仲裁确定多数节点都不存在,则认为群集没有仲裁,并且群集服务将在重新启动循环中等待,直到更多节点尝试加入。
当多数节点或节点的仲裁可用时,群集服务将启动并使资源联机。
由于最新配置被写入多数节点,而不管节点是否失败,因此群集总能保证它在启动时有最新的配置。
如果发生群集失败,或群集以某种方式进入拆分群集情形,则不包含多数节点的所有分区都会设为脱机。
这就确保了如果有包含多数节点的、正在运行的分区,那么它就可以安全启动任何不运行在该分区上的资源,因为它是群集中正在运行资源的唯一分区。
由于共享磁盘仲裁群集的行为方式与MNS仲裁群集相比存在差异,因此在决定要使用哪个模型时必须进行仔细考虑。
例如,如果群集中只有两个节点,则建议您不要使用MNS模型。
在该示例中,一个节点的失败将导致整个群集失败,这是因为不可能有多数节点。
多数节点集(MNS)仲裁在WindowsServer 2003企业版和WindowsServer 2003Datacenter版群集中可用。
MNS群集为Exchange群集所提供的唯一好处是消除了对共享存储阵列中用来存储仲裁资源的专用磁盘的需要。
群集资源
群集服务使用资源监视器和资源DLL来管理所有资源对象。
资源监视器接口提供了标准通信接口,该接口使群集服务能够启动资源管理命令并获得资源状态数据。
资源监视器通过资源DLL获得实际的命令函数和数据。
群集服务使用资源DLL来使资源联机、管理它们与群集中其他资源的交互并监视它们的运行状况。
为了启用资源管理,资源DLL将使用几个简单资源接口和属性。
资源监视器加载其地址空间中特定的资源DLL,该DLL作为特权代码运行在SYSTEM帐户下面。
SYSTEM帐户(即LocalSystem)是代表操作系统的安全主体帐户。
群集服务(运行在用户安全上下文下面)使用SYSTEM帐户来执行操作系统中的安全功能。
当资源依赖于其他资源的可用性才能正常工作时,这些依存关系可以被资源DLL定义。
当资源依赖于其他资源时,群集服务只有在将该资源所依赖的资源按正确顺序设为联机之后,才会将该依赖资源设为联机。
将资源设为脱机的方式与此类似。
群集服务只有在将任何依赖资源设为脱机之后,才会将依赖它们的资源设
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 群集 体系结构