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