リソースのエラーリカバリのシナリオ

LifeKeeper は、LifeKeeper が保護するリソースのステータスと健全性をチェックするリアルタイムデーモンモニタ lkcheck を装備しています。 In Service の各リソースについて、 lkcheck が定期的にそのリソースタイプの quickCheck スクリプトを呼び出します。 quickCheck スクリプトがリソースのクイック健全性チェックを実行し、リソースが障害のある状態にあると判断すると、 quickCheck スクリプトはイベント通知メカニズム sendevent を呼び出します。

以下の図に、 lkcheck がプロセスを開始したときのリカバリプロセスの作業を示します。

1. lkcheck が実行されます。デフォルトでは、 lkcheck プロセスは 2 分ごとに実行されます。 lkcheck が動作すると、システムで In Service の各リソースについて適切は quickCheck スクリプトを呼び出します。

2. quickCheck スクリプトがリソースをチェックします。 quickCheck スクリプトが実行するチェックの内容は、各リソースタイプによって異なります。通常、スクリプトは、リソースのクライアントの動作をシミュレートして、予測した応答を受信するかどうかを確認することにより、目的の作業を実行するためにリソースが使用可能かどうかを単純に確認します。

3. quickCheck スクリプトが sendevent を呼び出します。 quickCheck スクリプトが、リソースが障害のある状態にあると判断した場合、 sendevent を呼び出して、適切なクラスとタイプを持つイベントを開始します。

4. リカバリ手順の検索。システムイベント通知メカニズム sendevent は、はじめに、イベントタイプまたはコンポーネントについて、LCD がリソースまたはリカバリを持つかどうかを判断しようとします。この判断を行うために、is_recoverable プロセスは LCD のリソース階層をスキャンして、イベントに対応するリソースインスタンス (この例では filesys　の名前) を検索します。

次の手順の動作は、スキャンでリソースレベルのリカバリ手順が検出されたかどうかによって異なります。

• • 検出されない場合。リカバリ手順が見つからない場合、is_recoverable は sendevent に戻り、 sendevent は基本イベント通知を続行します。
    

• • 検出された場合。スキャンでリソースが検出された場合、is_recoverable はリカバリプロセスをバックグラウンドに運びます。is_recoverable プロセスが戻り、 sendevent が基本イベント通知を続行します。推奨フラグ「 -A 」を基本警告イベント応答スクリプトに渡し、LifeKeeper がリカバリを実行することを示します。
    

5. リカバリプロセスが開始されます。リカバリが続行していると仮定して、is_recoverable はリカバリプロセスを開始し、はじめにローカルリカバリを試行します。

6. ローカルリカバリが試行されます。インスタンスが検出された場合、リカバリプロセスは、LCD　内のリソース階層にアクセスし、階層ツリーからイベントに応答する方法を知っているリソースを検索して、ローカルリカバリを試行します。各リソースタイプについて、イベントクラスにちなむ名前を持つサブディレクトリ (そのイベントタイプのリカバリスクリプトを持つ) を含むリカバリサブディレクトリを検索します。

リカバリプロセスが、リソース階層で障害が発生しているリソースから上方向に最も離れたリソースに関連付けられている、リカバリスクリプトを実行します。リカバリスクリプトが正常に完了した場合、リカバリは停止します。スクリプトが失敗した場合、次のリソースに関連付けられたスクリプトが実行され、リカバリスクリプトが正常に完了するか、障害が発生したインスタンスに関連付けられたリカバリスクリプトが試行されるまで続行されます。

ローカルリカバリが正常に完了した場合、リカバリは停止します。

7. サーバ間のリカバリが開始されます。ローカルリカバリに失敗した場合、イベントはサーバ間のリカバリにエスカレートします。

8. リカバリが続行されます。ローカルリカバリに失敗しているので、リカバリプロセスは失敗したインスタンスを Out-of-Service-FAILED (OSF) 状態にマークし、この失敗したリソースに依存するすべてのリソースを Out-of-Service-UNIMPAIRED (OSU) 状態にマークします。リカバリプロセスは次に、障害が発生したリソース、または障害が発生したリソースに依存するリソースが、他のシステム上にあるリソースとイクイバレンシー情報を持っているかどうかを判断し、優先順位が最高の動作可能なサーバを選択します。同時にアクティブにできるイクイバレンシー情報を持つリソースは 1 つのみです。

イクイバレンシー情報が存在しない場合、リカバリプロセスは停止します。

イクイバレンシー情報が検出されて選択された場合、LifeKeeper はサーバ間のリカバリを開始します。リカバリプロセスが LCM 経由で、イクイバレンシー情報を持つリソースを持つ選択されたバックアップシステムの LCD プロセスにメッセージを送信します。これは、LifeKeeper がサーバ間のリカバリを試行することを意味します。

9. lcdrecover プロセスが転送を調整します。バックアップサーバの LCD プロセスが lcdrecover プロセスを運び、同等リソースの転送を調整します。

10. バックアップサーバのアクティブ化。 lcdrecover プロセスが同等のリソースを検出し、そのリソースが Out of Service のリソースに依存しているかどうかを判断します。 lcdrecover が、必要な各リソースについて restore スクリプト (リソースリカバリ動作スクリプトの一部) を実行し、リソースを In Service にします。

バックアップサーバでリソースをリストアすることにより、プライマリシステムからより多くの共有リソースを転送することが必要になる場合があります。プライマリシステムとの間で、プライマリサーバ上でのサービスから削除する必要があるリソースを示すメッセージが送受信され、次に選択したバックアップサーバで In Service になり、重要なアプリケーションのすべての機能が提供されます。この動作は、転送する追加の共有リソースがなくなり、バックアップで必要なすべてのリソースインスタンスがリストアされるまで続行されます。