Sun Cluster 数据服务故障监视器

本节提供了有关数据服务故障监视器的一般信息。 Sun 提供的数据服务包含内置于软件包中的故障监视器。 故障监视器（或故障探测）是探测数据服务的运行状况的进程。

故障监视器调用

使资源组及其资源联机时，RGM 将调用故障监视器。 此调用会使 RGM 内部调用用于数据服务的 MONITOR_START 方法。

故障监视器可执行以下两种功能。

• 监视数据服务服务器一个或多个进程的不正常退出

• 检查数据服务的运行状况

监视服务器进程的不正常退出

进程监视器工具 (PMF) 可监视数据服务进程。

数据服务故障探测以无限循环运行，并进行休眠（时间为资源特性 Thorough_probe_interval 设置的可调时间）。 进行休眠时，探测将使用 PMF 进行检查以确定进程是否已退出。 如果进程已退出，探测会将数据服务的状态更新为“服务守护程序未运行”，并采取措施。 该操作可以包括在本地重新启动数据服务或将数据服务故障转移到次群集节点。 要确定是重新启动数据服务还是故障转移数据服务，探测将检查数据服务应用程序资源的资源特性 Retry_count 和 Retry_interval 中设置的值。

检查数据服务的运行状况

通常，探测和数据服务之间通过专用命令或与指定数据服务端口的成功连接来进行通信。

探测使用的逻辑大致如下所示。

1. 进行休眠 (Thorough_probe_interval)。

2. 在超时特性 Probe_timeout 下执行运行状况检查。 Probe_timeout 是您可以设置的每个数据服务的资源扩展特性。

3. 如果步骤 2 成功，即服务运行正常，请更新成功/失败历史记录。 要更新成功/失败历史记录，请清除早于为资源特性 Retry_interval 设置的值的所有历史记录。 探测会将资源的状态消息设置为“服务处于联机状态”，并返回步骤 1。

   如果步骤 2 的结果是失败，则探测将更新失败历史记录。 然后探测将计算运行状况检查失败的总次数。

   运行状况检查结果的范围为从完全失败到成功。 对结果的解释取决于特定的数据服务。 请考虑一种情况：探测可以成功连接到服务器并将握手消息发送到服务器，但是探测在超时之前仅收到部分响应。 这种情况很可能是系统负载过重的结果。 如果采取了某个操作（例如重新启动服务），客户机将重新连接到该服务，这会进一步使系统负载过重。 如果发生此事件，数据服务故障监视器会确定不将此“部分”失败视为致命失败， 而是将此失败记录为服务的非致命探测。 这些部分失败仍在 Retry_interval 特性指定的时间间隔内进行累计。

   但是，如果探测根本无法连接到服务器，则可以将该失败视为致命失败。 部分失败以小于一的数作为失败计数。 每次失败计数达到总失败次数（按一个致命失败或部分失败累计结果计算）后，探测将重新启动数据服务或故障转移数据服务以尝试更正该状况。

4. 如果步骤 3 中的计算结果（历史记录时间间隔中的失败次数）小于资源特性 Retry_count 的值，则探测将尝试在本地更正该状况（例如通过重新启动服务）。 探测会将资源的状态消息设置为“服务已降级”，并返回步骤 1。

5. 如果 Retry_interval 中的失败次数超出了 Retry_count，则探测将调用带有“停止”选项的 scha_control。 此选项将请求服务的故障转移。 如果此请求成功，则故障探测将在此节点上停止。 探测会将资源的状态消息设置为“服务已失败”。

6. Sun Cluster 框架会因各种原因拒绝上一步骤中发出的 scha_control 请求。 scha_control 的返回代码将标识原因。 探测将检查返回代码。 如果 scha_control 被拒绝，探测将重置失败/成功历史记录并重新启动。 此探测重置历史记录的原因是失败次数已超出 Retry_count，故障探测可能会尝试在每个后续迭代中发出 scha_control（可能会再次被拒绝）。 此请求可能会在系统中安置额外负载，并可能会增加更多服务失败的可能性。

   随后探测将返回步骤 1。