故障转移-HPECommunity.doc

故障转移 在发生意外的硬件或应用程序故障时，故障转移可能会自动执行，也可能由群集管理人员手动触发。这两种情形的算法相同，只不过在人工启动故障转移时，资源是按有序方式关闭的（即使这种关闭形式在故障状态下可能显得突然和具有破坏性）。 当群集中的某个节点完全失效时，其资源组将被转移到群集中的一个或多个可用的服务器。自动故障转移类似于按照计划对资源所有权进行管理性的重新分配。但该过程将更为复杂一些，因为正常有序的关闭步骤可能受到影响或者根本就不会发生。因此为了评估故障时的群集状态，还将需要一些额外步骤。 自动故障转移需要确定在故障节点上运行的资源组以及哪些节点将会获得各个资源组的所有权。群集中所有可以驻留这些资源组的节点会彼此协商这些资源组的归属事宜。这种协商基于节点性能、当前负载、应用程序反馈或者节点首选项列表。节点首选项列表是资源组属性的一部分，可用来将资源组指定给某个节点。一旦完成资源组的协商，所有群集节点就会更新各自的数据库并跟踪拥有资源组的节点。 在具有两个以上节点的群集中，各个资源组的节点首选项列表可以指定一个首选服务器外加一个或多个优先的备用服务器。这样可以实现级联式故障转移 功能。通过该功能，资源组可以不受多个服务器故障的影响，因为它们可以逐级地故障转移到节点首选项列表的下一个服务器上。群集管理员可以为某个服务器上的资源组设置不同的节点首选项列表，这样，一旦服务器发生故障，就可以将该资源组分发到幸存的群集服务器上。 这种方案的一个替代做法是设置群集中所有资源组的节点首选项列表（该做法通常称为 N+I 故障转移）。节点首选项列表将确定首次故障转移时应将资源转移到哪个备用的群集节点。这些备用服务器应该是群集中最为空闲的服务器，或者它们可以非常容易地清除自己的工作载荷以便接收故障服务器转移来的工作载荷。 当群集管理员在选择级联式故障转移和 N+I 故障转移时，关键问题是要考虑群集是否有额外的容量来容纳因为少了服务器而损失的容量。使用级联式故障转移的前提是，群集的每个服务器都有一定的额外容量来接纳其它服务器发生故障时转移来的一部分工作负载。而使用 N+I 故障转移的前提是，这“+I”个备用服务器将是提供额外容量的主要位置。 故障恢复 当节点恢复联机时，故障转移管理器可以决定是否将某些资源组转移回这个已恢复正常的节点。这被称作故障恢复。只有资源组的属性定义了首选的拥有者，已恢复正常或重新启动的节点才有可能实现故障恢复。如果恢复的或重新启动的节点是资源组的首选拥有者，则该资源组会从其当前的拥有者转移到恢复的或重启的节点。 资源组的故障恢复属性可能包括在一天之中的哪个时间才允许故障恢复以及对故障恢复尝试时间的限制。这样，群集服务就可以防止在高峰处理时间进行资源的故障恢复，或者保护尚未正确恢复或重启的节点。 全局更新管理器 内部群集组件（比如故障转移管理器或数据库管理器）可以使用全局更新管理器 (GUM) 以原子方式（或者更新所有正常的节点，或者一个都不更新）和串行方式（保持一个整体顺序）将群集服务器的变更复制到各个群集节点。GUM 更新的发起，通常源于群集 API 调用。在客户端节点上启动 GUM 更新时，GUM 首先会请求负责锁定的节点实现全局（“全局“表示所有的群集节点）锁定。如果无法进行全局锁定，客户端会一直等待。 当可以锁定时，负责锁定的节点会将锁定授予该客户端，并且从本地（在负责锁定的节点上）发布更新。该客户端随即将更新发布到包括它自身在内的所有正常节点。如果在负责锁定的节点上成功完成了更新，但在其它某些节点上更新失败，则会剥夺这些节点在当前群集中的成员资格。如果在负责锁定的节点上更新失败，该节点仅向客户端返回故障信息。 备份/恢复管理器 群集服务为群集数据库备份提供了一个 API，即 BackupClusterDatabase。BackupClusterDatabase 首先会同故障转移层联系，而后者会接着将请求转交给拥有仲裁资源的节点。这样就可以调用该拥有者节点中的数据库管理器，并由它来完成仲裁日志文件和所有检查点文件的备份。 除了 API 外，群集服务在启动时也会以备份写入程序的形式将自己注册到卷影复制服务 (VSS)。当备份客户端调用 VSS 执行系统状态备份时，它会通过一系列的入口点调用来调用群集服务执行群集数据库备份。群集服务中的服务器代码会直接调用故障转移管理器来执行备份，其余的操作与 BackupClusterDatabase API 相同。 为了从备份路径恢复群集数据库，群集服务提供了另一个 API，即 RestoreClusterDatabase。该 API 只能从某个群集节点的本地调用。调用该 API 时，它将依次停止群集服务、从备份中恢复群集数据库、设置包含备份路径的注册表值，然后再启动群集服务。群