4.3. GFS2 ファイルシステムがハングし、全ノードのリブートが必要

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