トラブルシューティングを行う
変更を提案
PDF
BeeGFS HAクラスタのトラブルシューティング
概要
このセクションでは、BeeGFS HAクラスタの運用中に発生する可能性のあるさまざまな障害やその他のシナリオを調査してトラブルシューティングする方法を説明します。
トラブルシューティングガイド
予期しないフェイルオーバーを調査してい
ノードが予期せずフェンシングされていてサービスが別のノードに移動された場合は、の下部でクラスタがリソース障害を示していないかどうかを最初に確認する必要があります pcs status。通常、フェンシングが正常に完了し、リソースが別のノードで再起動された場合、何も表示されません。
通常、次の手順では、を使用してシステムログを検索します journalctl 残りのファイルノードのいずれか（Pacemakerログは、すべてのノードで同期されます）。障害が発生した時刻がわかっている場合は、障害が発生する直前に検索を開始できます（通常は10分前までに実行することをお勧めします）。
journalctl --since "<YYYY-MM-DD HH:MM:SS>"以降のセクションでは、ログに含まれているをgrepで検索できる一般的なテキストを示します。これにより、調査をさらに絞り込むことができます。
調査/解決の手順
手順1：BeeGFSモニタで障害が検出されたかどうかを確認します。
BeeGFSモニタによってフェイルオーバーがトリガーされた場合は、エラーが表示されます（次の手順に進みない場合）。
journalctl --since "<YYYY-MM-DD HH:MM:SS>" | grep -i unexpected
[...]
Jul 01 15:51:03 beegfs_01 pacemaker-schedulerd[9246]: warning: Unexpected result (error: BeeGFS service is not active!) was recorded for monitor of meta_08-monitor on beegfs_02 at Jul 1 15:51:03 2022このインスタンスでは、何らかの理由でBeeGFSサービスMETA_08が停止しました。トラブルシューティングを続行するには、beegfs_02を起動し、でサービスのログを確認する必要があります /var/log/beegfs-meta-meta_08_tgt_0801.log。たとえば、BeeGFSサービスで内部問題 やノードの問題が原因でアプリケーションエラーが発生した可能性があります。
|
Pacemakerのログとは異なり、BeeGFSサービスのログはクラスタ内のすべてのノードに分散されるわけではありません。これらのタイプの障害を調査するには、障害が発生した元のノードのログが必要です。 |
モニタで報告される可能性がある問題は次のとおりです。
-
ターゲットにアクセスできません。
-
概要 ：ブロックボリュームにアクセスできなかったことを示します。
-
トラブルシューティング：
-
代替ファイルノードでサービスも開始できない場合は、ブロックノードが正常な状態であることを確認してください。
-
このファイルノードからブロックノードにアクセスできなくなる可能性がある物理的な問題がないかどうかを確認します。たとえば、InfiniBandアダプタまたはケーブルに障害がある場合などです。
-
-
-
ネットワークに到達できません。
-
概要 ：このBeeGFSサービスへの接続にクライアントが使用するアダプタがオンラインではありませんでした。
-
トラブルシューティング：
-
複数またはすべてのファイルノードが影響を受けた場合は、BeeGFSクライアントとファイルシステムの接続に使用されるネットワークに障害が発生していないかどうかを確認します。
-
InfiniBandアダプタやケーブルの障害など、このファイルノードからクライアントにアクセスできなくなる物理的な問題がないかどうかを確認してください。
-
-
-
BeeGFSサービスはアクティブではありません。
-
概要 ：BeeGFSサービスが予期せず停止しました。
-
トラブルシューティング：
-
エラーが報告されたファイルノードで、影響を受けたBeeGFSサービスのログを調べて、クラッシュが報告されたかどうかを確認します。この場合は、ネットアップサポートに問い合わせてクラッシュを調査できるようにケースをオープンしてください。
-
BeeGFSログにエラーが報告されていない場合は、ジャーナルログを調べて、サービスが停止した理由がシステムに記録されているかどうかを確認します。一部のシナリオでは、プロセスが終了する前（たとえば、誰かが実行された場合）にBeeGFSサービスがメッセージをログに記録できなかった可能性があります
kill -9 <PID>）。
-
-
手順2：ノードがクラスタから予期せず離れていないかを確認します
ノードで壊滅的なハードウェア障害が発生した場合（システム基板が故障した場合など）、またはカーネルパニックまたは同様のソフトウェア問題 が発生した場合、BeeGFSモニタはエラーを報告しません。代わりにホスト名を検索し、Pacemakerからのメッセージで、ノードが予期せずに失われたことを示すメッセージが表示されます。
journalctl --since "<YYYY-MM-DD HH:MM:SS>" | grep -i <HOSTNAME>
[...]
Jul 01 16:18:01 beegfs_01 pacemaker-attrd[9245]: notice: Node beegfs_02 state is now lost
Jul 01 16:18:01 beegfs_01 pacemaker-controld[9247]: warning: Stonith/shutdown of node beegfs_02 was not expected手順3：Pacemakerがノードを遮断できたことを確認します
すべてのシナリオで、ノードが実際にオフラインであることを確認するためにペースメーカーがノードを遮断しようとすると考えられます（正確なメッセージはフェンシングの原因 によって異なる場合があります）。
Jul 01 16:18:02 beegfs_01 pacemaker-schedulerd[9246]: warning: Cluster node beegfs_02 will be fenced: peer is no longer part of the cluster
Jul 01 16:18:02 beegfs_01 pacemaker-schedulerd[9246]: warning: Node beegfs_02 is unclean
Jul 01 16:18:02 beegfs_01 pacemaker-schedulerd[9246]: warning: Scheduling Node beegfs_02 for STONITHフェンシング処理が正常に完了すると、次のようなメッセージが表示されます。
Jul 01 16:18:14 beegfs_01 pacemaker-fenced[9243]: notice: Operation 'off' [2214070] (call 27 from pacemaker-controld.9247) for host 'beegfs_02' with device 'fence_redfish_2' returned: 0 (OK)
Jul 01 16:18:14 beegfs_01 pacemaker-fenced[9243]: notice: Operation 'off' targeting beegfs_02 on beegfs_01 for pacemaker-controld.9247@beegfs_01.786df3a1: OK
Jul 01 16:18:14 beegfs_01 pacemaker-controld[9247]: notice: Peer beegfs_02 was terminated (off) by beegfs_01 on behalf of pacemaker-controld.9247: OK何らかの理由でフェンシングアクションが失敗した場合、データ破損のリスクを回避するために別のノードでBeeGFSサービスを再起動できなくなります。たとえば、フェンシングデバイス（PDUまたはBMC）にアクセスできなかったり、誤って設定されていた場合、問題 は個別に調査します。
Address Failed Resource Actions（PCステータスの下部にある）
BeeGFSサービスの実行に必要なリソースに障害が発生すると、BeeGFSモニタによってフェイルオーバーがトリガーされます。この場合は、の下部に[Failed Resource Actions]が表示されない可能性があり `pcs status`ます。[How to]の手順を参照してください。"計画外フェイルオーバー後のフェイルバック"
そうしないと、通常、「Failed Resource Actions」というメッセージが表示されるシナリオは2つだけになります。
調査/解決の手順
シナリオ1：フェンシングエージェントで一時的または永続的な問題 が検出され、再起動されたか、別のノードに移動された。
フェンシングエージェントの中には、他のエージェントよりも信頼性の高いものがあり、それぞれがフェンシングデバイスの準備が整ったことを確認する独自の監視方法を実装しています。特に、Redfishフェンシングエージェントは、次のような失敗したリソースアクションを報告するようになりましたが、まだ開始されています。
* fence_redfish_2_monitor_60000 on beegfs_01 'not running' (7): call=2248, status='complete', exitreason='', last-rc-change='2022-07-26 08:12:59 -05:00', queued=0ms, exec=0ms特定のノードで失敗したリソースアクションを報告するフェンシングエージェントは、そのノードで実行されているBeeGFSサービスのフェールオーバーをトリガーする必要はありません。同じノードまたは別のノードで自動的に再起動されるだけです。
解決手順：
-
フェンシングエージェントが、すべてのノードまたは一部のノードでの実行を常に拒否している場合は、それらのノードがフェンシングエージェントに接続できるかどうかを確認し、フェンシングエージェントがAnsibleインベントリで正しく設定されていることを確認します。
-
たとえば、Redfish（BMC）フェンシングエージェントがフェンシングを担当するノードで実行されており、OS管理とBMC IPが同じ物理インターフェイス上にある場合、一部のネットワークスイッチ構成では2つのインターフェイス間の通信が許可されないため（ネットワークループが回避されます）、デフォルトでは、HAクラスタは、フェンシングを担当するノードにフェンシングエージェントを配置しないようにしますが、これは一部のシナリオや構成で発生する可能性があります。
-
-
すべての問題が解決したら（または問題 が一時的なものと思われる場合）、を実行します
pcs resource cleanup失敗したリソースアクションをリセットします。
シナリオ2：BeeGFSモニタが問題 を検出してフェイルオーバーをトリガーしましたが、何らかの理由でセカンダリノードでリソースを起動できませんでした。
フェンシングが有効で、リソースが元のノードで停止しないようにブロックされていない場合（「standby」（on -ffail）のトラブルシューティングのセクションを参照）、最も可能性の高い理由は、次のような理由からセカンダリノードでリソースを起動する際の問題です。
-
セカンダリノードはすでにオフラインでした。
-
物理構成または論理構成の問題 によって、セカンダリはBeeGFSターゲットとして使用されるブロックボリュームにアクセスできなくなりました。
解決手順：
-
失敗したリソースアクションの各エントリについて、次の手順を実行します。
-
失敗したリソースアクションが開始操作であることを確認します。
-
指定したリソースと、失敗したリソースアクションで指定されたノードに基づきます。
-
ノードが指定したリソースを起動できないような外部の問題がないかどうかを確認して解決します。たとえば、BeeGFS IP address (floating IP) failed to startの場合は、必要なインターフェイスの少なくとも1つが接続/オンラインであり、適切なネットワークスイッチにケーブル接続されていることを確認します。BeeGFSターゲット（ブロックデバイス/Eシリーズボリューム）に障害が発生した場合は、バックエンドブロックノードへの物理接続が正常に接続されていることを確認し、ブロックノードが正常であることを確認します。
-
-
明らかな外部の問題がなく、このインシデントに対するrootの原因 が必要な場合は、以下の手順を進める前にネットアップサポートの調査ケースをオープンして原因 分析（RCA）を実施することを検討することを推奨します。
-
-
外部の問題を解決したあと：
-
Ansibleのinventory.ymlファイルから機能しないノードをコメント化し、完全なAnsibleプレイブックを再実行して、すべての論理構成がセカンダリノードで正しくセットアップされていることを確認します。
-
注：ノードが正常でフェイルバックの準備ができたら、これらのノードのコメントを解除してプレイブックを再実行してください。
-
-
または、クラスタのリカバリを手動で実行することもできます。
-
次のコマンドを使用して、オフラインのノードをオンラインに戻します。
pcs cluster start <HOSTNAME> -
障害が発生したすべてのリソースアクションをクリアするには、
pcs resource cleanup -
PCステータスを実行し、すべてのサービスが期待どおりに開始されることを確認します。
-
必要に応じてを実行します
pcs resource relocate runをクリックして、リソースを優先ノードに戻します（使用可能な場合）。
-
-
一般的な問題
BeeGFSサービスは、要求されたときにフェイルオーバーやフェイルバックを行いません
可能性の高い問題 ： pcs resource relocate 実行コマンドは実行されましたが、正常に終了しませんでした。
*確認方法:*実行 pcs constraint --full IDがの場所の制約がないかどうかを確認します pcs-relocate-<RESOURCE>。
*解決方法:*実行 pcs resource relocate clear 再実行します pcs constraint --full 追加の拘束が除去されたことを確認します。
フェンシングが無効な場合、PCステータスの一方のノードに「standby (on-fail)」と表示されます
考えられる問題 ： Pacemakerは、障害が発生したノードですべてのリソースが停止していることを正常に確認できませんでした。
解決方法:
-
を実行します
pcs statusおよび出力の一番下に「started」または「エラーが表示されていないリソースがないかどうかを確認し、問題を解決します。 -
ノードをオンラインに戻すには、次の手順を実行します
pcs resource cleanup --node=<HOSTNAME>。
想定外のフェイルオーバーが発生すると、フェンシングが有効になっている場合、PCのステータスに「started（on-fail）」と表示されます
*問題 の可能性：*フェールオーバーをトリガーしたが、Pacemakerがノードをフェンシングしていることを確認できなかった問題が発生しました。フェンシングが正しく設定されていないか、フェンシングエージェントを含む問題 が存在することが原因で発生します（例：PDUがネットワークから切断されています）。
解決方法:
-
ノードの電源がオフになっていることを確認します。
指定したノードが実際にはオフになっておらず、クラスタのサービスやリソースを実行している場合は、データの破損やクラスタ障害が発生します。 -
フェンシングを手動で確認する場合：
pcs stonith confirm <NODE>
この時点で、サービスのフェイルオーバーが完了し、別の正常なノードで再開されます。
一般的なトラブルシューティングタスク
BeeGFSサービスを個別に再起動します
通常、BeeGFSサービスを再起動（設定変更を容易にするためなど）する必要がある場合は、Ansibleインベントリを更新してプレイブックを再実行します。一部のシナリオでは、個 々 のサービスを再起動して迅速なトラブルシューティングを実現したい場合があります。たとえば、プレイブック全体の実行を待たずにログレベルを変更する場合などです。
|
|
Ansibleインベントリに手動で変更を追加しないかぎり、次回Ansibleプレイブックが実行されたときに変更が元に戻されます。 |
オプション1：systemdで制御された再起動
新しい設定でBeeGFSサービスが適切に再起動しないリスクがある場合は、まずクラスタをメンテナンスモードにして、BeeGFSモニタがサービスを停止して不要なフェイルオーバーをトリガーしないようにします。
pcs property set maintenance-mode=true必要に応じて、でサービス設定を変更します /mnt/<SERVICE_ID>/_config/beegfs-.conf （例： /mnt/meta_01_tgt_0101/metadata_config/beegfs-meta.conf）次にsystemdを使用して再起動します。
systemctl restart beegfs-*@<SERVICE_ID>.service例 systemctl restart beegfs-meta@meta_01_tgt_0101.service
オプション2：ペースメーカーの再起動を制御
新しい設定で原因 サービスが予期せず停止する（ロギングレベルの変更など）か、メンテナンス時間になっていてダウンタイムが気にならない場合は、再起動するサービスのBeeGFSモニタを再起動するだけです。
pcs resource restart <SERVICE>-monitorたとえば、BeeGFS管理サービスを再起動するには、次の手順を実行します。 pcs resource restart mgmt-monitor