障害が発生した場合、LifeKeeper には2つのリカバリー方式があります。ローカルリカバリーとサーバー間リカバリー（フェイルオーバー）です。ローカルーリカバリーが失敗した場合、「フェイルオーバー」が実行されます。フェイルオーバーは、アクティブだったアプリケーション、サーバー、システム、ハードウェアコンポーネント、ネットワークの障害や異常終了が発生したときのバックアップサーバーへの自動的な切り替えと定義されます。フェイルオーバーとスイッチオーバーは基本的には同じ動作ですが、スイッチオーバーが人の介入を必要とするのに対し、フェイルオーバーは自動で、通常は警告なしで実行されます 。この自動的なフェイルオーバーは、さまざまな理由で発生します。以下は、LifeKeeper が開始するフェイルオーバーの最も一般的な例の一覧です。
サーバーレベルでの原因
サーバーの障害
LifeKeeperには設定内の各サーバーに、ペアのサーバーが動作していることを定期的に通知する組み込みのハートビート信号があります。サーバーがハートビートメッセージを受信しなかった場合に、障害として検出されます。
- プライマリーサーバーが電源を喪失するか、電源がオフになる。
- 過負荷による CPU 使用率 – 非常に高負荷の I/O の下では、これらの遅延と低メモリ状態によってシステムが無応答になり、LifeKeeper がこれをサーバーのダウンとして検知し、フェイルオーバーを開始することがあります。
- Quorum/Witness – プライマリーサーバーが Quorum を失った場合、Quorum/Witness の I/O フェンシングメカニズムの一環として、( 設定に基づいて )「 fastboot 」、「 fastkill 」、または「 osu 」が実行され、フェイルオーバーが開始されます。フェイルオーバー時を決定する際、プライマリーサーバーで障害が発生しクラスターを構成できなくなったことが確認できた場合にのみ、witness サーバーによりバックアップサーバー上でリソースを in service にすることができます。全体のアクセスや、パフォーマンス、in-service のノードが影響を受けない場合は、これによってノード間で発生する単純な通信障害から発生するフェイルオーバーを回避します。
| サポートストレージ一覧 |
| サーバー障害リカバリーのシナリオ |
| LifeKeeper ハートビートの調整 |
| Quorum/Witness |
通信障害 / ネットワーク障害
LifeKeeperは、サーバー間で 5 秒ごとにハートビートを送信します。通信障害によって 2 回のハートビートが途絶し3 回目のハートビートで再開した場合、LifeKeeperは一切処置を行いません。コミュニケーションパスの切断継続時間がハートビート 3 回分になった場合は、LifeKeeperはコミュニケーションパスを切断と判定します。ただし、他方の冗長的なコミュニケーションパスも切断と判定されるまではフェイルオーバーを開始しません。
- プライマリーサーバーへのネットワーク接続の喪失。
- ネットワークの遅延。
- TCP コミュニケーションパス上のネットワークトラフィックが大きくなると、偽のフェイルオーバーや LifeKeeper の初期化の問題など、予期せぬ動作が生じる可能性があります。
- STONITH を使用しているときに LifeKeeper がノードとの通信障害を検出すると、そのノードの電源が切断され、フェイルオーバーが発生します。
- NIC の障害。
- ネットワークスイッチの障害。
- 手動によるネットワーク接続の解除。
| コミュニケーションパスの作成 |
| LifeKeeper ハートビートの調整 |
| ネットワーク設定 |
| ネットワーク設定の確認 |
| SNMP 経由の LifeKeeper イベントの転送 |
| ネットワーク関連のトラブルシューティング |
| ファイアーウォールを使用した状態での LifeKeeper の実行 |
| STONITH |
スプリットブレイン
単一のコミュニケーションパスを使用しているときに、そのコミュニケーションパスで障害が発生した場合、複数のシステム上で同時に LifeKeeper の階層が in service になることがあります。これは、偽のフェイルオーバーまたは「 スプリットブレイン 」シナリオと呼ばれます。「スプリットブレイン」シナリオでは、各サーバーが、アプリケーションを制御できると認識しているため、データにアクセスしようとしたり共有ストレージデバイスにデータを書き込もうとする場合があります。スプリットブレインシナリオを解決するために、LifeKeeper では、サーバーの電源をオフにしたり、再起動したり、階層を out-of-service にすることで、すべての共有データに対するデータの整合性を保証することができます。また、TCP コミュニケーションパス上のネットワークトラフィックが大きくなると、偽のフェイルオーバーや LifeKeeper が適切に初期化できなくなるなど、予期しない動作が生じる可能性があります。
以下に、スプリットブレインが発生する可能性のあるシナリオを示します。
- 上記のいずれかの通信障害
- LifeKeeper の不正なシャットダウン
- サーバーリソースの枯渇
- すべてのネットワークパスの喪失
- DNS またはその他のネットワークの問題
- システムのロックアップ / 解除
リソースレベルでの原因
LifeKeeper には、個々のアプリケーションおよび関連アプリケーションのグループを監視する機能があり、定期的にローカルリカバリーを実行したり、保護下のアプリケーションに障害が発生したときに通知することができます。関連し合うアプリケーションの例としては、主アプリケーションが下位のストレージまたはネットワークリソースに依存する階層などがあります。LifeKeeper は、これらの保護下のリソースのステータスと健全性を監視します。LifeKeeper は、リソースが障害状態にあると判断すると、外部の介入なしに現在のシステム (in-service のノード) でリソースまたはアプリケーションをリストアしようとします。このローカルリカバリーが失敗した場合、リソースのフェイルオーバーが開始されます。
アプリケーションの障害
- アプリケーションの障害が検出されたが、ローカルリカバリープロセスが失敗。
- 削除の失敗 - リソースのフェイルオーバープロセスでは、該当する重要なアプリケーションのすべての機能を提供するために、プライマリーサーバー上でのサービスから特定のリソースを削除し、選択したバックアップサーバーでそのリソースを in service にする必要があります。 この削除プロセスが失敗した場合は、プライマリーサーバーの再起動が実行され、 その結果、完全なサーバーフェイルオーバーに移行します。
削除の失敗の例
- ファイルシステムをアンマウントできない
- ファイルシステムをアンマウントできない
- 保護対象のアプリケーション (Oracle、mySQL、Postgres など) をシャットダウンできない
- 保護対象のアプリケーション (Oracle、mySQL、Postgres など) をシャットダウンできない
| ファイルシステムの健全性監視 |
| リソースエラーリカバリーのシナリオ |
ファイルシステム
- ディスクフル - LifeKeeper のファイルシステムの健全性監視は、ファイルシステムリソースのフェイルオーバーになる可能性のある、ファイルシステムのディスクフル状態を検出できます。
- アンマウントされた、または不適切にマウントされたファイルシステム - in-service 状態で LK 保護下のファイルシステムをユーザが手動でアンマウントまたはオプションを変更。
- 再マウントの障害 - 以下のリストに、フェイルオーバーに進行する場合がある再マウントの障害の一般的な原因を示します。
- ファイルシステムが破損している (fsck の障害)
- ファイルシステムが破損している (fsck の障害)
- マウントポイントディレクトリの作成失敗
- マウントポイントディレクトリの作成失敗
- マウントポイントがビジー
- マウントポイントがビジー
- マウントの失敗
- マウントの失敗
- LifeKeeper の内部エラー
- LifeKeeper の内部エラー
| ファイルシステムの健全性監視 |
IP アドレスの障害
IP Recovery Kit によって IP アドレスの障害が検出されると、結果として生じる障害によって IP ローカルリカバリースクリプトが起動されます。LifeKeeper は最初に、その IP アドレスを現在のネットワークインターフェース上で in service に戻そうとします。ローカルリカバリーの試みが失敗すると、LifeKeeper はその IP アドレスと依存関係を持つすべてのリソースのバックアップサーバーへのフェイルオーバーを実行します。フェイルオーバー中に、削除プロセスによって現在のサーバー上の該当する IP アドレスの設定が解除され、バックアップサーバー上でそのアドレスを設定できるようになります。 この削除プロセスに失敗すると、システムは再起動します。
- IP 競合
- IP コリジョン
- DNS の名前解決の障害
- NIC やスイッチの障害
| 切り替え可能な IP アドレスの作成 |
| IP ローカルリカバリー |
リザベーションコンフリクト
- 保護されたデバイスへのリザベーションの喪失または盗難
- 保護されたリソースデバイスへのリザベーションまたは制御の回復が不可能 (手動のユーザ介入、HBA またはスイッチの障害が原因)
| SCSI リザベーション |
| リザベーションの無効化 |
SCSI デバイス
- 保護された SCSI デバイスを開くことができない。デバイスに障害が発生しているか、システムからデバイスが削除されている可能性があります。
このトピックへフィードバック