※この記事は翻訳されたものです。本記事の原文はこちら
サポート業務に携わっていると、お客様からよくいただく質問のひとつに、「プライマリーノードからセカンダリーノードへのフェイルオーバーが発生した原因は何ですか？」というものがあります。
フェイルオーバーが起きる理由はいくつか考えられますが、ここでは最も一般的な原因と、その特定方法について説明します。
その前に、「フェイルオーバー」と「スイッチオーバー」を同じ意味で使用しているお客様が多くいらっしゃるため、これらの用語を区別しておきましょう。
「スイッチオーバー」とは、手動でプライマリーノードからセカンダリーノードへ階層を移動する行為です。これは、GUIを使用してセカンダリーノードで「In Service」を実行するか、以下のようにコマンドラインから行うことができます。
perform_action -a restore -t $LKTag (階層をIn-Serviceにする)
一方、「フェイルオーバー」は手動での操作なしに実行されるもので、それまでアクティブだったサーバー、アプリケーション、ハードウェアやネットワークに障害が発生した場合に、自動的にバックアップサーバーに切り替えられることを言います。
フェイルオーバーとスイッチオーバーは基本的に同じ動作ですが、フェイルオーバーは通常は警告なしに自動的に行われるのに対し、スイッチオーバーは意図的に行われ、人間の介入が必要であるという点が異なります。
「フェイルオーバー」を誘因する最も一般的な「障害」は次のとおりです。
1. サーバーレベルの障害によるフェイルオーバー
サーバー障害
- プライマリーサーバーの電源が切れた、またはオフになった。
- 過度の負荷によるCPU使用率の増加 — I/O負荷が非常に高い場合、遅延やメモリ不足によりシステムが応答しなくなり、その結果LifeKeeperはサーバーがダウンしたと検出し、フェイルオーバーを開始することがあります。
- Quorum/Witness – Quorum/WitnessのI/Oフェンシングメカニズムの一部として、プライマリーサーバーがQuorumを失った場合
通信（ハートビート）障害
LifeKeeperには「ハートビート」と呼ばれる信号が組み込まれており、構成内の各サーバーに対して、そのペアとなるサーバーが動作していることを定期的に通知します。デフォルトでは、LifeKeeperは5秒ごとにサーバー間にハートビートを送信します。通信の問題によりハートビートが2回スキップされても、3回目で再開された場合、LifeKeeperは何も行いません。しかし、コミュニケーションパスが3回のハートビートにわたって切断されたままである場合、LifeKeeperはそのコミュニケーションパスを切断されたと見なします。冗長化されたコミュニケーションパスも切断されている場合（サイオスでは2つのパスを推奨しています）、LifeKeeperはフェイルオーバーを開始します。
ハートビートが失われる原因としては、以下のようなことが考えられます。
- プライマリサーバーへのネットワーク接続が失われた
- ネットワークの遅延
- TCPコミュニケーションパス上のネットワークトラフィックが多すぎると、フェイルオーバーの誤作動やLifeKeeperの初期化の問題など、予期しない動作が発生する可能性があります。
- NICの障害
- ネットワークスイッチの障害
- ネットワーク接続の手動での抜線・取り外し
- プライマリーサーバーの電源喪失または電源オフ
- 過度の負荷によるCPU使用率の増加 — I/O負荷が非常に高い場合、遅延やメモリ不足によりシステムが応答しなくなり、LifeKeeperがサーバーダウンを検知してフェイルオーバーを開始することがあります。
ハートビートパラメーターの調整：
LCMNUMHBEATS=Y（ここで、Yはコミュニケーションパス障害エラーをログに記録するまでのハートビートの回数です。）デフォルトは3ですが、システムがビジー状態の場合やWANを経由する場合は、コミュニケーションパス障害の誤検知を回避するために変更できます。
LCMHBEATTIME=5（これは秒単位のデフォルトの間隔です。変更しないでください。）
これらの調整可能なパラメーターは、デフォルトでは/etc/default/LifeKeeperファイルにはありません。ハートビート値を変更するには、これらを追加する必要があります。
これらの調整可能なパラメーターと値を/etc/default/LifeKeeperに追加した場合、LifeKeeperを停止して再起動する必要があります。lkstop -fコマンドを使用すると、LifeKeeperは停止しますが、保護されているアプリケーションは停止しません。
これは、両方のシステムで行う必要があります。
これにより、LifeKeeperがコミュニケーションパスを障害としてマークするまでに、Y秒の5倍の時間が与えられます。
2. リソース障害によるフェールオーバー
LifeKeeperは、個々のアプリケーションと関連アプリケーションのグループを監視し、保護されているアプリケーションに障害が発生した場合、定期的にローカルリカバリーまたは通知を実行するように設計されています。ここで関連アプリケーションとは、プライマリーアプリケーションが下位レベルのストレージまたはネットワークリソースに依存する階層です。
LifeKeeperは、これらの保護されているリソースのステータスと健全性を監視します。リソースが障害状態にあると判断された場合、外部からの介入なしに、現在のシステム（In-Serviceのノード）上でリソースまたはアプリケーションの復旧を試みます。このローカルリカバリーが失敗した場合、リソースのフェイルオーバーを開始します。
アプリケーション障害
- アプリケーションの障害が検出されたが、ローカルの復旧プロセスが失敗した。
- リソースのフェイルオーバープロセス中、重要なアプリケーションの完全な機能を提供するために、特定のリソースをプライマリーサーバーのサービスから削除し、選択したバックアップサーバーでIn-Serviceにする必要があります。この削除プロセスが失敗すると、プライマリーサーバーの再起動が実行され、サーバーが完全にフェイルオーバーされます。
削除の失敗の例は以下の通りです。
- ファイルシステムをアンマウントできない
- 保護されているアプリケーション（Oracle、Mysql、Postgresなど）をシャットダウンできない
ファイルシステムの問題
- ディスクフル — LifeKeeperのファイルシステムの健全性監視は、ファイルシステムリソースのフェイルオーバーを引き起こす可能性のあるディスクフル状態を検出することができます。
- ファイルシステムがマウントされていない、または不適切にマウントされている— In-ServiceのLKで保護されたファイルシステムで、ユーザーが手動でアンマウントまたはオプションを変更した。
- 再マウントの失敗 — フェイルオーバーにつながる再マウント失敗の一般的な原因には、次のようなものがあります。
- ファイルシステムの破損（fsckの失敗）
- マウントポイントディレクトリの作成失敗
- マウントポイントがビジー状態
- マウント失敗
- LifeKeeperの内部エラー
IPアドレス障害
IP Recovery KitがIPアドレスの障害を検出すると、その結果生じた障害によってIPローカルリカバリースクリプトの実行がトリガーされます。
LifeKeeperはまず、現在のネットワークインターフェース上でIPアドレスを使用可能な状態に戻そうとします。
ローカルリカバリーの試行が失敗した場合、LifeKeeperはIPアドレスと依存するすべてのリソースをバックアップサーバーにフェイルオーバーします。フェイルオーバー中、削除プロセスによって現在のサーバーのIPアドレスの設定が解除され、バックアップ サーバーで設定できるようになります。この削除処理に失敗すると、システムが再起動します。
- IPの競合
- IPの衝突
- DNS解決の失敗
- NICまたはスイッチの障害
リザベーションの競合
- 保護されたデバイスのリザベーションが喪失した、または奪われた
- 保護されたリソースデバイスのリザベーションまたは制御を回復できない（ユーザーによる手動操作、HBAまたはスイッチの障害が原因）
SCSIデバイス
- 保護されたSCSIデバイスを開けない。デバイスが故障しているか、システムから取り外されている可能性があります。
フェイルオーバーの原因を特定するためのリソース
/var/log/lifekeeper.log
LifeKeeperによって書き込まれたこのログファイルは、フェイルオーバーの原因を特定する際に最初に見るべきものです。
例えば、最も一般的な原因のひとつは、コミュニケーションパスの障害です。以下は、この問題が発生した場合にlifekeeper.logに表示されるエントリーの例です。
Sep 21 11:06:57 es1ecc08tev lcm[46893]: INFO:lcm.tli_hand:::005257:missed heartbeat 1 of 48 on dev 10.236.17.226/10.238.17.226 (lcm driver number = 129).
Sep 21 11:06:57 es1ecc08tev lcm[46893]: INFO:lcm.tli_hand:::005257:missed heartbeat 1 of 48 on dev 10.236.17.226/10.237.17.226 (lcm driver number = 1360929).
Sep 21 11:07:02 es1ecc08tev lcm[46893]: INFO:lcm.tli_hand:::005257:missed heartbeat 2 of 48 on dev 10.236.17.226/10.238.17.226 (lcm driver number = 129).
ハートビートの最大数に達すると、フェイルオーバーが開始されます。
Sep 21 11:10:49 es6ecc08tev lcm[9416]: INFO:lcm.tli_hand:::005257:missed heartbeat 47 of 48 on dev 10.237.17.226/10.236.17.226 (lcm driver number = 71).
Sep 21 11:10:49 es6ecc08tev eventslcm[47082]: WARN:lcd.net:::004258:Communication to es1ecc08tev by 10.237.17.226/10.236.17.226 FAILED
Sep 21 11:10:49 es6ecc08tev eventslcm[47082]: WARN:lcd.net:::004261:COMMUNICATIONS failover from system “es1ecc08tev” will be started.
Sep 21 11:10:49 es6ecc08tev lifekeeper[47121]: NOTIFY:event.comm_down:::010466:COMMUNICATIONS es1ecc08tev FAILED
/var/log/messages
このLinuxが生成したファイルには、通常、システム上で実行されているさまざまなプロセスやサービスによって生成されたシステムメッセージが含まれています。これらのメッセージには以下のようなものがあります。
システムブートメッセージ：カーネルメッセージやsystemdまたは他のinitシステムからのメッセージなど、システムブートプロセスに関する情報。
サービスのスタートアップとシャットダウンのメッセージ：プロセス中に発生したエラーや警告など、サービスが開始または停止されたことを示すメッセージ。
カーネルメッセージ：ハードウェアの検出、デバイスの初期化、カーネルのエラーや警告など、Linuxカーネルの動作に関する情報。
ネットワーク関連のメッセージ：ネットワーク接続、ファイアウォールのアクティビティ、ネットワーク設定の変更に関する情報。
システムパフォーマンス情報：CPU使用率、メモリ使用率、ディスクI/O統計などのシステムパフォーマンスの監視に関するメッセージ。
SIOSの高可用性とディザスターリカバリー
サイオステクノロジー株式会社は、お客様の重要なアプリケーションをクラスター管理で保護し、ITインフラを最適化する高可用性およびディザスターリカバリー製品を提供しています。詳細については、今すぐお問い合わせください。
