第7章 GFS2 ファイルシステムに伴う問題の診断と修正

本セクションでは、GFS2 の一般的な問題と対処方法に関する情報を提供します。

7.1. ノードで利用できない GFS2 ファイルシステム (GFS2 の withdraw 機能)

GFS2 の withdraw (無効) 機能は、GFS2 ファイルシステムのデータ整合性機能であり、ハードウェアまたはカーネルソフトウェアの不良によるファイルシステムの損傷を防ぎます。指定したクラスターノードで GFS2 ファイルシステムを使用している場合に、GFS2 カーネルが非整合性を検出すると、マウントを解除して再マウントするまでそのノードで利用できなくなります (または問題を検出したマシンが再起動します)。マウントしたその他の GFS2 ファイルシステムはすべて、そのノードで完全に機能し続けます。GFS2 の withdraw 機能は、ノードをフェンスする原因となるカーネルパニックよりも厄介なものではありません。

以下は、GFS2 を無効にする可能性のある非整合の種類です。

  • inode 整合性エラー
  • リソースグループの整合性エラー
  • ジャーナル整合性エラー
  • マジックナンバーのメタデータの整合性エラー
  • メタデータ型の整合性エラー

GFS2 の無効を引き起こす (撤回) 可能性がある不一致の例は、ファイルの inode に対するブロック数が間違っています。GFS2 がファイルを削除すると、そのファイルが参照するすべてのデータおよびメタデータブロックがシステムにより削除されます。完了すると、inode のブロック数を確認します。ブロック数が 1 でない場合 (つまり、残りのすべてがディスクの inode 自体である場合)、inode のブロック数はファイルに使用されている実際のブロックと一致しないため、ファイルシステムが不整合であることを示します。

多くの場合、この問題の原因は、ハードウェアの障害 (メモリー、マザーボード、HBA、ディスクドライブ、ケーブルなど) にある可能性があります。また、カーネルのバグ (GFS2 のメモリーを誤って上書きする別のカーネルモジュール) や、実際のファイルシステムの損傷 (GFS2 のバグによる) が原因で発生した可能性もあります。

多くの場合、撤回した GFS2 ファイルシステムから復元する最善の方法は、ノードを再起動またはフェンスすることです。撤回した GFS2 ファイルシステムでは、クラスターの別のノードにサービスを再配置する機会が与えられます。サービスが再配置されれば、このコマンドを使用してノードを再起動するか、フェンスを強制的に実行できます。

# pcs stonith fence node
警告

umount コマンドと mount コマンドを使用してファイルシステムのマウントを解除して再マウントしないようにしてください。代わりに pcs コマンドを使用する必要があります。このコマンドを使用しないと、ファイルシステムサービスが消えたことを Pacemaker が検出し、ノードをフェンスしてしまうからです。

撤回の原因になった整合性の問題によりシステムがハングアップする可能性があるため、ファイルシステムのサービスを停止できなくなる可能性があります。

再マウントしても問題が解決しない場合は、ファイルシステムサービスを停止して、クラスターの全ノードからファイルシステムのマウントを削除し、以下の手順に従ってサービスを再起動する前に、fsck.gfs2 コマンドでファイルシステムの確認を実行します。

  1. 影響を受けるノードを再起動します。
  2. Pacemaker でクローン以外のファイルシステムサービスを無効にして、クラスター内のすべてのノードからファイルシステムのマウントを解除します。

    # pcs resource disable --wait=100 mydata_fs
  3. クラスターの 1 つのノードから、ファイルシステムデバイスで fsck.gfs2 コマンドを実行して、ファイルシステムの損傷を確認して修復します。

    # fsck.gfs2 -y /dev/vg_mydata/mydata > /tmp/fsck.out
  4. ファイルシステムサービスを再度有効にして、すべてのノードで GFS2 ファイルシステムを再マウントします。

    # pcs resource enable --wait=100 mydata_fs

ファイルシステムサービスに -o errors=panic オプションを指定してファイルシステムをマウントすることで、GFS2 の withdraw 機能を無効にできます。

# pcs resource update mydata_fs “options=noatime,errors=panic”

このオプションが指定されていると、通常はシステムを無効にするようなエラーが発生すると、代わりにカーネルパニックが発生します。これによりノードの通信が停止し、ノードがフェンスされます。これは特に、監視や介入がなく長期間にわたり無人状態になるクラスターに役に立ちます。

内部的には、GFS2 の withdraw 機能は、ロックプロトコルを切断することで機能し、それ以降のすべてのファイルシステム操作で I/O エラーが発生するようにします。その結果、withdraw が発生すると、通常は、システムログに報告されたデバイスマッパーデバイスからの I/O エラーが多数表示されるようになります。

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

GFS2 ファイルシステムがハングし、それに対して実行したコマンドを返さなくても、ある特定のノードをリブートするとシステムが正常な状態に戻る場合には、ロックの問題もしくはバグの兆候である可能性があります。これが発生した場合は、「トラブルシューティングに使用する GFS2 データの収集」の説明に従って、これらの発生時に GFS2 データを収集し、Red Hat サポートにサポートチケットを作成してください。

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

ご使用の GFS2 ファイルシステムがハングし、それに対して実行したコマンドを返さず、使用できる状態にするためにクラスター内の全ノードをリブートする必要がある場合は、以下の問題を確認してください。

  • フェンスに失敗した可能性があります。GFS2 ファイルシステムはフリーズし、フェンスが失敗した場合にデータの整合性を確保します。メッセージログを確認して、ハング時に失敗したフェンスがあるかどうかを確認します。フェンシングが正しく設定されていることを確認します。
  • GFS2 ファイルシステムがクラッシュした可能性があります。メッセージログで withdraw という単語を確認し、GFS2 のメッセージおよびコールトレースで、ファイルシステムが撤回されたことを示すメッセージがないかどうかを確認します。withdraw は、ファイルシステムの破損、ストレージ障害、またはバグを示します。ファイルシステムのマウントを解除するするのが都合が良い早い段階で、以下の手順を実行する必要があります。

    1. 撤回が発生したノードを再起動します。

      # /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 ファイルシステム (GFS2 の withdraw 機能)」を参照してください。

  • このエラーは、ロックの問題またはバグを示している可能性があります。「トラブルシューティングに使用する GFS2 データの収集」に従ってこの問題の発生時にデータを収集し、Red Hat サポートにサポートチケットを開きます。

7.4. 新たに追加したクラスターノードに GFS2 ファイルシステムをマウントできない

新しいノードをクラスターに追加し、そのノードで GFS2 ファイルシステムをマウントできない場合は、GFS2 ファイルシステムのジャーナル数が、GFS2 ファイルシステムへのアクセスを試行しているノードよりも少ない可能性があります。ファイルシステムをマウントする GFS2 ホストごとに、ジャーナルが 1 つ必要です (ただし、spectator マウントオプションを設定してマウントした GFS2 ファイルシステムはジャーナルを必要としないため除外されます)。gfs2_jadd コマンドを使用して、GFS2 ファイルシステムにジャーナルを追加できます。「GFS2 ファイルシステムへジャーナルの追加」を参照してください。

7.5. 空のファイルシステムで使用中と表示される領域

空の GFS2 ファイルシステムがある場合は、df コマンドで、占有されている領域が存在することが示されます。これは、GFS2 ファイルシステムのジャーナルがディスク上で領域 (ジャーナルの数 * ジャーナルサイズ) を消費するためです。多数のジャーナルがある GFS2 ファイルシステムを作成した場合、または指定したジャーナルサイズが大きい場合に df コマンドを実行すると、(ジャーナルの数 * ジャーナルのサイズ) が使用されているものとして表示されます。大量のジャーナルや大規模なジャーナルを指定していない場合でも、小さな GFS2 ファイルシステム (1GB 以下の範囲) には、デフォルトの GFS2 ジャーナルサイズで、使用中の大容量の領域が表示されます。

7.6. トラブルシューティングに使用する GFS2 データ収集

GFS2 ファイルシステムがハングし、それに対して実行したコマンドを返さず、Red Hat サポートのチケットを作成する必要がある場合は、最初に以下のデータを収集してください。

  • 各ノード上のファイルシステム用の GFS2 ロックダンプの場合:

    cat /sys/kernel/debug/gfs2/fsname/glocks >glocks.fsname.nodename
  • 各ノードのファイルシステム用の DLM ロックダンプの場合: この情報は、dlm_tool を使用して確認できます。

    dlm_tool lockdebug -sv lsname.

    このコマンドでは、lsname は、問題のファイルシステムに対して DLM が使用するロックスペース名です。group_tool コマンドの出力で、次の内容を確認できます。

  • sysrq -t コマンドの出力
  • /var/log/messages ファイルの内容

データを収集したら、Red Hat サポートのチケットを作成して、収集したデータを提出してください。


このページには機械翻訳が使用されている場合があります (詳細はこちら)。