製品ドキュメント
XenServer
XenServer 9 XenServer 8.4
PDFを表示

GFS2クラスタープールのトラブルシューティング

August 25, 2026
寄稿者: 
X

GFS2を使用して共有ブロックストレージをシンプロビジョニングするXenServer®プールはクラスター化されています。これらのプールは、共有ファイルベースストレージまたは共有ブロックストレージとLVMを使用するプールとは異なる動作をします。そのため、XenServerクラスタープールおよびGFS2環境では、特定のいくつかの問題が発生する可能性があります。

この機能を使用する際に発生する可能性のある軽微な問題のトラブルシューティングを行うには、以下の情報を使用してください。

すべてのホストが互いにpingできますが、クラスターを作成できません。その理由?

クラスタリングメカニズムは特定のポートを使用します。ホストがこれらのポートで通信できない場合（他のポートで通信できる場合でも）、プールでクラスタリングを有効にすることはできません。

プール内のホストが以下のポートで通信できることを確認してください。

  • TCP: 8892, 8896, 21064
  • UDP: 5404, 5405 (マルチキャストではない)

プール内のホスト間にファイアウォールなどがある場合、これらのポートが開いていることを確認してください。

以前にプールでHAを設定している場合、クラスタリングを有効にする前にHAを無効にしてください。

既存のクラスタープールに新しいホストを参加させようとするとエラーが発生する理由?

プールでクラスタリングが有効になっている場合、すべてのプールメンバーシップの変更は、成功する前にクラスターのすべてのメンバーによって合意される必要があります。クラスターメンバーに連絡できない場合、クラスターメンバーシップを変更する操作（ホストの追加やホストの削除など）は失敗します。

新しいホストをクラスタープールに追加するには：

  1. すべてのホストがオンラインであり、連絡可能であることを確認してください。

  2. プール内のホストが以下のポートで通信できることを確認してください。

    • TCP: 8892, 8896, 21064
    • UDP: 5404, 5405 (マルチキャストではない)

  3. 参加するホストが、プールのクラスターネットワークに参加するNICにIPアドレスが割り当てられていることを確認します。

  4. クラスター化が、プール内の非管理VLANネットワークを使用していないことを確認します。

  5. 新しいホストがクラスター化されたプールに参加しようとしているときに、プール内のホストがオフラインになっていないことを確認します。

  6. オフラインのホストを回復できない場合は、クラスターから削除するために「dead」としてマークします。詳細については、「クラスター化されたプール内のホストがオフラインで回復できません。クラスターからホストを削除するにはどうすればよいですか？」を参照してください。

クラスター化されたプールの一部のメンバーが自動的にクラスターに参加しない場合の対処法?

この問題は、クラスター化されたプールのメンバーが同期を失っていることが原因である可能性があります。

クラスター化されたプールのメンバーを再同期するには、次のコマンドを使用します。

xe cluster-pool-resync cluster-uuid=<cluster_uuid>

問題が解決しない場合は、GFS2 SRを再アタッチしてみてください。このタスクは、xe CLIまたはXenCenterを使用して実行できます。

xe CLIを使用してGFS2 SRを再アタッチします。

  1. GFS2 SRをプールからデタッチします。各ホストで、xe CLIコマンド xe pbd-unplug uuid=<uuid_of_pbd> を実行します。

  2. コマンド xe cluster-pool-destroy cluster-uuid=<cluster_uuid> を使用して、クラスター化されたプールを無効にします。

    前のコマンドが失敗した場合は、プール内のすべてのホストで xe cluster-host-force-destroy uuid=<cluster_host> を実行して、クラスター化されたプールを強制的に無効にすることができます。

  3. コマンド xe cluster-pool-create network-uuid=<network_uuid> [cluster-stack=cluster_stack] [token-timeout=token_timeout] [token-timeout-coefficient=token_timeout_coefficient] を使用して、クラスター化されたプールを再度有効にします。

  4. 各ホストでコマンド xe pbd-plug uuid=<uuid_of_pbd> を実行して、GFS2 SR を再アタッチします。

または、XenCenter を使用して GFS2 SR を再アタッチするには、次の手順を実行します。

  1. プールの ストレージ タブで、GFS2 SR を右クリックし、デタッチ… を選択します。
  2. ツールバーから、プール > プロパティ を選択します。
  3. クラスタリング タブで、クラスタリングを有効にする の選択を解除します。
  4. OK をクリックして変更を適用します。
  5. ツールバーから、プール > プロパティ を選択します。
  6. クラスタリング タブで、クラスタリングを有効にする を選択し、クラスタリングに使用するネットワークを選択します。
  7. OK をクリックして変更を適用します。
  8. プールの ストレージ タブで、GFS2 SR を右クリックし、修復 を選択します。

ホストが自己フェンスしたかどうかの確認方法?

ホストが自己フェンスした場合、再起動時にクラスターに再参加した可能性があります。ホストが自己フェンスして回復したかどうかを確認するには、/var/opt/xapi-clusterd/boot-times ファイルをチェックしてホストが起動した時刻を確認します。ファイル内に予期しない起動時刻がある場合、ホストは自己フェンスしています。

ホストがオフラインになる理由と回復方法?

ホストがオフラインになる理由は多数あります。理由によっては、ホストを回復できる場合とできない場合があります。

ホストがオフラインになる以下の理由はより一般的であり、ホストを回復することで対処できます。

  • クリーンシャットダウン
  • 強制シャットダウン
  • 一時的な電源障害
  • 再起動

ホストがオフラインになる以下の理由は、あまり一般的ではありません。

  • 永続的なホストハードウェア障害
  • 永続的なホスト電源障害
  • ネットワークパーティション
  • ネットワークスイッチ障害

これらの問題は、ハードウェアを交換するか、障害が発生したホストをデッドとしてマークすることで対処できます。

クラスター化されたプール内のホストがオフラインになり、回復できません。クラスターからホストを削除する方法?

クラスターにホストを忘れるように指示できます。この操作により、ホストはクラスターから永続的に削除され、クォーラムに必要なライブホストの数が減少します。

回復不能なホストを削除するには、次のコマンドを使用します。

xe host-forget uuid=<host_uuid>

このコマンドは、ホストをクラスターから永続的に削除し、クォーラムに必要なライブホストの数を減少させます。

注記:

ホストがオフラインでない場合、このコマンドはデータ損失を引き起こす可能性があります。コマンドを続行する前に、確認を求められます。

ホストが忘れられた後、クラスターに再度追加することはできません。このホストをクラスターに再度追加するには、ホストにXenServerを新規インストールする必要があります。

死んでいるとマークされたホストを修復しました。クラスターに再度追加するにはどうすればよいですか?

死んでいるとマークされたXenServerホストは、クラスターに再度追加することはできません。このシステムをクラスターに再度追加するには、XenServerを新規インストールする必要があります。この新規インストールは、クラスターには新しいホストとして認識されます。

クラスターがクォーラムを失い続け、ホストがフェンシングを続ける場合、どうすればよいですか?

クラスター内の1つ以上のXenServerホストが、継続的にクォーラムを失うためにフェンスループに陥る場合、nocluster dom0コマンドライン引数を使用してホストを起動できます。ホストの物理コンソールまたはシリアルコンソールに接続し、dom0コマンドラインで次のコマンドを実行します: /opt/xensource/libexec/xen-cmdline --set-dom0 nocluster。次回ホストが再起動するとき、クラスターへの参加を試みません。

ホストの問題を診断して解決した後、nocluster 引数を削除することでクラスタリングを有効にできます。そのためには、次のコマンドを実行します: /opt/xensource/libexec/xen-cmdline --remove-dom0 nocluster。変更を有効にするには、ホストを再起動してください。

シリアルコンソールを介したホストへのアクセスとXenコマンドラインの編集の詳細については、高度なトラブルシューティングを参照してください。

クラスター化されたプールでプールコーディネーターが再起動された場合、どうなります?

ほとんどの場合、クラスター化されたプールでプールコーディネーターがシャットダウンまたは再起動されたときの動作は、他のプールメンバーがシャットダウンまたは再起動されたときと同じです。

ホストのシャットダウンまたは再起動の方法は、クラスター化されたプールのクォーラムに影響を与える可能性があります。クォーラムの詳細については、クォーラムを参照してください。

動作の唯一の違いは、プールでHAが有効になっているかどうかによって異なります。

  • HAが有効になっている場合、新しいコーディネーターが選択され、一般的なサービスが維持されます。
  • HAが有効になっていない場合、プールにはコーディネーターがいません。残りのホストで実行中のVMは引き続き実行されます。コーディネーターが再起動するまで、ほとんどの管理操作は利用できません。

クラスター化されたプール内のホストが強制的にシャットダウンされた後、プールが消滅したのはなぜです?

ホストを通常どおりシャットダウンした場合（強制的にではない場合）、ホストは電源が再びオンになるまで一時的にクォーラム計算から除外されます。ただし、ホストを強制的にシャットダウンした場合、または電源が失われた場合、そのホストは引き続きクォーラム計算に含まれます。たとえば、3台のホストからなるプールがあり、そのうち2台を強制的にシャットダウンした場合、残りのホストはクォーラムを失うためフェンスします。

クラスター化されたプール内のホストは、常にクリーンにシャットダウンするようにしてください。詳細については、「クラスター化されたプールの管理」を参照してください。

クラスター化されたプール内のすべてのホストが同時に再起動したのはなぜですか?

アクティブなクラスター内のすべてのホストは、プール内の接続可能なホストの数が次の値よりも少ない場合に、クォーラムを失ったと見なされます。

  • 偶数個のホストを持つプールの場合: n/2
  • 奇数個のホストを持つプールの場合: (n+1)/2

文字nは、クラスター化されたプール内のホストの総数を示します。クォーラムの詳細については、「クォーラム」を参照してください。

この状況では、すべてのホストが自己フェンスし、すべてのホストが再起動するのを確認できます。

プールがクォーラムを失った理由を診断するには、次の情報が役立ちます。

  • XenCenterで、問題発生時の通知セクションをチェックして、自己フェンスが発生したかどうかを確認します。
  • クラスターホストで、/var/opt/xapi-clusterd/boot-timesをチェックして、予期しない時間に再起動が発生したかどうかを確認します。
  • Crit.logで、自己フェンスメッセージが出力されているかどうかを確認します。

  • フェンシング情報について、dlm_tool statusコマンドの出力を確認します。

    dlm_tool status出力例:

     dlm_tool status

 cluster nodeid 1 quorate 1 ring seq 8 8
 daemon now 4281 fence_pid 0
 node 1 M add 3063 rem 0 fail 0 fence 0 at 0 0
 node 2 M add 3066 rem 0 fail 0 fence 0 at 0 0
 <!--NeedCopy-->

デバッグのためにログを収集する際は、クラスター内のすべてのホストから診断情報を収集してください。単一のホストが自己フェンスした場合、クラスター内の他のホストの方が有用な情報を持っている可能性が高くなります。

クラスタ化されたプール内のホストの完全なサーバー状態レポートを収集します。詳細については、XenServer サーバー状態レポートを参照してください。

クォーラムがあるのに、クラスタ化されたプールを回復できないのはなぜですか?

ホスト数が偶数のクラスタ化されたプールの場合、クォーラムを 達成する ために必要なホスト数は、クォーラムを 維持する ために必要なホスト数よりも1つ多くなります。クォーラムの詳細については、クォーラムを参照してください。

ホスト数が偶数のプールで、半数のホストを回復した場合、クラスターを回復する前に、もう1つのホストを回復する必要があります。

次のコマンドを実行して、クラスターにクォーラムがあるかどうかを確認できます。

xe cluster-list params=is-quorate uuid=<cluster_id>

クラスター設定を変更すると、Invalid tokenエラーが表示されるのはなぜですか?

クラスターの構成を更新する際に、無効なトークン("[[\"InternalError\",\"Invalid token\"]]")に関する次のエラーメッセージが表示されることがあります。

この問題は、次の手順を実行することで解決できます。

  1. (オプション) xapi-clusterdおよびシステムログを含むサーバー状態レポートを収集して、現在のクラスター構成をバックアップします。

  2. XenCenterを使用して、GFS2 SRをクラスタ化されたプールからデタッチします。

    プールのストレージタブで、GFS2 SRを右クリックし、デタッチ…を選択します。

  3. クラスター内の任意のホストで、このコマンドを実行してクラスターを強制的に破棄します。

    xe cluster-pool-force-destroy cluster-uuid=<uuid>

  4. XenCenterを使用して、プールでクラスタリングを再度有効にします。

    1. ツールバーから、プール > プロパティを選択します。
    2. クラスタリングタブで、クラスタリングを有効にするを選択し、クラスタリングに使用するネットワークを選択します。
    3. 「OK」をクリックして変更を適用します。

  5. XenCenter を使用して、GFS2 SR をプールに再アタッチします。

    プールの「ストレージ」タブで、GFS2 SR を右クリックし、「修復」を選択します。

GFS2クラスタープールのトラブルシューティング
August 25, 2026
寄稿者: 
X
August 25, 2026
寄稿者: 
X

この記事の概要

サイトに関するフィードバック | Your privacy choices footer linkプライバシーに関する選択肢 | プライバシーと法令 | 同意設定 | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.