クラスター化されたプールのトラブルシューティング

最終公開日 : Oct 07, 2026
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. オフラインのホストを回復できない場合は、デッドとしてマークし、クラスターから削除します。詳細については、「クラスター化されたプール内のホストがオフラインで回復できません。クラスターからホストを削除するにはどうすればよいですか?」(#a-host-in-my-clustered-pool-is-offline-and-i-cant-recover-it-how-do-i-remove-the-host-from-my-cluster)を参照してください。

クラスター化されたプールの一部のメンバーが自動的にクラスターに参加しない場合はどうすればよいですか?

この問題は、クラスター化されたプールのメンバーが同期を失っていることが原因である可能性があります。
クラスター化されたプールのメンバーを再同期するには、次のコマンドを使用します。
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=&lt;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
デバッグのためにログを収集する際は、クラスター内のすべてのホストから診断情報を収集してください。単一のホストがセルフフェンスした場合、クラスター内の他のホストの方が有用な情報を持っている可能性が高いです。
クラスター化されたプール内のホストの完全なサーバー状態レポートを収集します。詳細については、XenServer サーバー状態レポートを参照してください。

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

ホストの数が偶数のクラスター化されたプールがある場合、クォーラムを 達成 するために必要なホストの数は、クォーラムを 維持 するために必要なホストの数より1つ多くなります。クォーラムの詳細については、クォーラムを参照してください。
ホストの数が偶数のプールにいて、ホストの半分を回復した場合、クラスターを回復する前に、もう1つのホストを回復する必要があります。
次のコマンドを実行して、クラスターにクォーラムがあるかどうかを確認できます。
xe cluster-list params=is-quorate uuid=&lt;cluster_id>

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

クラスターの構成を更新すると、無効なトークン("[[\"InternalError\",\"Invalid token\"]]")に関する次のエラーメッセージが表示されることがあります。
この問題を解決するには、次の手順を実行します。
  1. (オプション) xapi-clusterdおよびシステムログを含むサーバー状態レポートを収集して、現在のクラスター構成をバックアップします。
  2. XenCenterを使用して、GFS2 SRをクラスター化されたプールからデタッチします。
    プールのストレージタブで、GFS2 SRを右クリックし、**デタッチ...**を選択します。
  3. クラスター内の任意のホストで、このコマンドを実行してクラスターを強制的に破棄します。
    xe cluster-pool-force-destroy cluster-uuid=&lt;uuid>
  4. XenCenterを使用して、プールでクラスタリングを再度有効にします。
    1. ツールバーから、プール > プロパティを選択します。
    2. クラスタリングタブで、クラスタリングを有効にするを選択し、クラスタリングに使用するネットワークを選択します。
    3. 変更を適用するには、OKをクリックします。
  5. XenCenter を使用して、GFS2 SR をプールに再接続します。
    プールの「ストレージ」タブで、GFS2 SR を右クリックし、「修復」を選択します。