4.3. GFS2 ファイルシステムがハングし、全ノードのリブートが必要
ご使用の GFS2 ファイルシステムがハングし、それに対して実行したコマンドを返さず、使用できる状態にするためにクラスター内の全ノードをリブートする必要がある場合は、以下の問題を確認してください。
- フェンスに失敗した可能性があります。GFS2 ファイルシステムはフリーズし、フェンスが失敗した場合にデータの整合性を確保します。メッセージログを確認して、ハング時に失敗したフェンスがあるかどうかを確認します。フェンシングが正しく設定されていることを確認します。
- GFS2 ファイルシステムがクラッシュした可能性があります。メッセージログで
withdrawという単語を確認し、GFS2 のメッセージおよびコールトレースで、ファイルシステムが撤回されたことを示すメッセージがないかどうかを確認します。withdraw は、ファイルシステムの破損、ストレージ障害、またはバグを示します。ファイルシステムのマウントを解除するするのが都合が良い早い段階で、以下の手順を実行する必要があります。- 撤回が発生したノードを再起動します。
#
/sbin/reboot - ファイルシステムリソースを停止して、すべてのノードで GFS2 ファイルシステムをマウント解除します。
#
pcs resource disable --wait=100 mydata_fs - gfs2_edit savemeta... コマンドでメタデータを取得します。ファイルに十分な空きがあることを確認する必要があります。この例では、メタデータは
/rootディレクトリーのファイルに保存されています。#
gfs2_edit savemeta /dev/vg_mydata/mydata /root/gfs2metadata.gz gfs2-utilsパッケージを更新します。#
sudo yum update gfs2-utils- 1 つのノードで、システム上において fsck.gfs2 コマンドを実行し、ファイルシステムの整合性を確保して損傷を修復します。
#
fsck.gfs2 -y /dev/vg_mydata/mydata > /tmp/fsck.out - fsck.gfs2 コマンドが完了したら、ファイルシステムのリソースを再度有効にして、サービスに戻します。
#
pcs resource enable --wait=100 mydata_fs - Red Hat サポートに、サポートチケットを作成します。GFS2 が無効になったことを伝え、sosreports コマンドおよび gfs2_edit savemeta コマンドで生成されたログとデバッグ情報を添付してください。
GFS2 の撤回では、ファイルシステムまたはそのブロックデバイスにアクセスしようとしているコマンドがハングすることもあります。このような場合は、クラスターを再起動するにはハードリブードが必要です。GFS2 の withdraw 機能の説明は、「GFS2 withdraw 機能」 を参照してください。 - このエラーは、ロックの問題またはバグを示している可能性があります。「GFS2 ファイルシステムがハングし、単一ノードのリブートが必要」 に従ってこの問題の発生時にデータを収集し、Red Hat サポートにサポートチケットを開きます。
