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