故障检测和相关链接


故障检测和防范是服务器群集提供的关键优点 。当群集中的节点或应用程序失败时,服务器群集可以通过重启失败的应用程序或将故障系统的工作分散给幸存的群集节点来做出响应 。服务器群集故障检测和防范包括双向故障转移、应用程序故障转移、并行恢复以及自动故障恢复 。
群集服务可以检测各个资源或整个节点的故障,并动态地将应用程序、数据和文件资源转移到群集中可用的正常服务器上,然后重新启动它们 。借此,数据库、文件共享和应用程序等资源可以对用户和客户端应用程序保持高度可用性 。
服务器群集在设计上带有两个不同的故障检测机制 :
•心跳 通讯,用于检测节点故障 。
•资源监视器和资源 DLL,用于检测资源故障 。
检测节点故障群集的各个节点在相互间会定期使用专用的群集网络交换数据报消息 。这些消息被称作 心跳。通过心跳通讯,每个节点可以检查其它节点以及它们的应用程序的可用性 。如果服务器没有对心跳通讯做出响应,则正常工作的服务器会启动故障转移过程(包括对故障服务器拥有的资源和应用程序的所有权进行仲裁) 。仲裁是使用质询和辩护协议来执行的 。换言之,如果某个节点似乎发生了故障,则会在给定的时间内允许它以几种方式中的任何一种表明它仍处于正常运行当中,并且可以同其它正常的节点通讯 。如果它无法证明,则此时会将它移出群集 。
多种事件都可能导致节点无法响应心跳消息,比如计算机故障、网络接口故障、网络故障,甚至可能是由于少有的高峰活动期 。通常来说,当所有节点进行通讯时,配置数据库管理器会向每个节点发送全局性的配置数据库更新 。但当发生心跳通讯失败时,日志管理器还会将配置数据库的变更保存到仲裁资源中 。这保证了幸存的节点可以在恢复过程中访问最新的群集配置和本地节点的注册表项数据 。
要注意的是,故障检测算法相当保守 : 换句话说,它会尽量多地给那些明显发生故障的节点以质询的机会,然后才会进入故障转移过程 。如果导致心跳响应失败的原因是暂时的,避免故障转移所可能造成的潜在影响当然是再好不过 。但是,由于无法知道这样的节点还将沉默多少时间,因此该节点可能遭受长时期的故障影响 。因此,在经过一个合理的时间段后,就应该启动故障转移 。
检测资源故障故障转移管理器和资源监视器可联同检测资源故障并实现从资源故障的恢复 。资源监视器通过使用资源 DLL 对资源进行定期轮询来跟踪资源状态 。轮询包括两个步骤,即一个短促的 LooksAlive 查询和一个时间较长并且更权威的 IsAlive 查询 。当资源监视器检测到资源故障时,它会通知故障转移管理器并且继续监视该资源 。
故障转移管理器将维护资源和资源组的状态 。它还负责在资源发生故障时执行恢复操作,并且调用资源监视器来响应用户操作或故障 。
检测到资源故障后,故障转移管理器可以执行恢复操作,这包括重启资源及其依存的资源,或者将整个资源组转移到另外的节点上 。资源和资源组的属性以及节点的可用性将决定要执行的是哪种恢复操作 。
为了保证能正确恢复资源依存关系,在故障转移过程中,资源组将被作为故障转移单位 。一旦资源从故障中恢复,资源监视器就会通知故障转移管理器,而后者又可以基于资源组故障转移属性的配置,接着执行资源组的自动故障转移 。
未来方向同基于 Windows 的产品一样,服务器群集的将来发展也将立足于以下主要环节 :
•更方便地安装和检查群集配置,包括对新型硬件的支持 。

推荐阅读