クラスター化されたプールのトラブルシューティング
GFS2 を使用して共有ブロックストレージをシンプロビジョニングする XenServer® プールはクラスター化されています。これらのプールは、共有ファイルベースストレージまたは共有ブロックストレージと LVM を使用するプールとは異なる動作をします。そのため、XenServer のクラスター化されたプールおよび GFS2 環境では、いくつかの特定の問題が発生する可能性があります。
この機能を使用する際に発生する可能性のある軽微な問題のトラブルシューティングには、以下の情報を使用してください。
すべてのホストは互いにpingできますが、クラスターを作成できません。その理由?
クラスタリングメカニズムは特定のポートを使用します。ホストがこれらのポートで通信できない場合(他のポートで通信できる場合でも)、プールでクラスタリングを有効にすることはできません。
プール内のホストが以下のポートで通信できることを確認してください。
- TCP: 8892, 8896, 21064
- UDP: 5404, 5405 (マルチキャストではない)
プール内のホスト間にファイアウォールまたは類似のものが存在する場合は、これらのポートが開いていることを確認してください。
以前にプールで HA を構成している場合は、クラスタリングを有効にする前に HA を無効にしてください。
既存のクラスター化されたプールに新しいホストを参加させようとするとエラーが発生する理由?
プールでクラスタリングが有効になっている場合、プールメンバーシップの変更はすべて、成功する前にクラスターのすべてのメンバーによって合意される必要があります。クラスターメンバーに連絡できない場合、クラスターメンバーシップを変更する操作(ホストの追加やホストの削除など)は失敗します。
クラスター化されたプールに新しいホストを追加するには:
-
すべてのホストがオンラインであり、連絡可能であることを確認してください。
-
プール内のホストが以下のポートで通信できることを確認してください。
- TCP: 8892, 8896, 21064
- UDP: 5404, 5405 (マルチキャストではない)
-
参加するホストのNICに、プールのクラスターネットワークに参加するためのIPアドレスが割り当てられていることを確認してください。
-
クラスタリングがプール内で非管理VLANネットワークを使用していないことを確認してください。
-
新しいホストがクラスター化されたプールに参加しようとしているときに、プール内のどのホストもオフラインではないことを確認してください。
-
オフラインのホストを回復できない場合は、それをデッドとしてマークし、クラスターから削除します。詳細については、クラスター化されたプール内のホストがオフラインで回復できません。クラスターからホストを削除するにはどうすればよいですか?を参照してください。
クラスター化されたプールの一部のメンバーが自動的にクラスターに参加しない場合、どうすればよいか?
この問題は、クラスター化されたプールのメンバーが同期を失っていることによって引き起こされる可能性があります。
クラスター化されたプールのメンバーを再同期するには、次のコマンドを使用します。
xe cluster-pool-resync cluster-uuid=<cluster_uuid>
問題が解決しない場合は、GFS2 SRを再アタッチしてみてください。このタスクは、xe CLIを使用するか、XenCenterを介して実行できます。
xe CLIを使用してGFS2 SRを再アタッチする手順:
-
プールからGFS2 SRをデタッチします。各ホストで、xe CLIコマンド
xe pbd-unplug uuid=<uuid_of_pbd>を実行します。 -
コマンド
xe cluster-pool-destroy cluster-uuid=<cluster_uuid>を使用して、クラスター化されたプールを無効にします。上記のコマンドが失敗した場合は、プール内のすべてのホストで
xe cluster-host-force-destroy uuid=<cluster_host>を実行して、クラスター化されたプールを強制的に無効にできます。 -
コマンド
xe cluster-pool-create network-uuid=<network_uuid> [cluster-stack=cluster_stack] [token-timeout=token_timeout] [token-timeout-coefficient=token_timeout_coefficient]を使用して、クラスター化されたプールを再度有効にします。 -
各ホストで
xe pbd-plug uuid=<uuid_of_pbd>コマンドを実行して、GFS2 SRを再アタッチします。
または、XenCenterを使用してGFS2 SRを再アタッチするには、次の手順を実行します。
- プールストレージタブで、GFS2 SRを右クリックし、デタッチ…を選択します。
- ツールバーから、プール > プロパティを選択します。
- クラスタリングタブで、クラスタリングを有効にするの選択を解除します。
- 変更を適用するには、OKをクリックします。
- ツールバーから、プール > プロパティを選択します。
- クラスタリングタブで、クラスタリングを有効にするを選択し、クラスタリングに使用するネットワークを選択します。
- 変更を適用するには、OKをクリックします。
- プールストレージタブで、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\"]]")に関する次のエラーメッセージが表示されることがあります。
この問題は、次の手順を実行することで解決できます。
-
(オプション) xapi-clusterdおよびシステムログを含むサーバー状態レポートを収集して、現在のクラスター構成をバックアップします。
-
XenCenterを使用して、GFS2 SRをクラスター化されたプールからデタッチします。
プールのストレージタブで、GFS2 SRを右クリックし、デタッチ…を選択します。
-
クラスター内の任意のホストで、このコマンドを実行してクラスターを強制的に破棄します。
xe cluster-pool-force-destroy cluster-uuid=<uuid> -
XenCenterを使用して、プールでクラスタリングを再度有効にします。
- ツールバーから、プール > プロパティを選択します。
- クラスタリングタブで、クラスタリングを有効にするを選択し、クラスタリングに使用するネットワークを選択します。
- 「OK」をクリックして変更を適用します。
-
XenCenter を使用して、GFS2 SR をプールに再接続します。
プールの「ストレージ」タブで、GFS2 SR を右クリックし、「修復」を選択します。
この記事の概要
- すべてのホストは互いにpingできますが、クラスターを作成できません。その理由?
- 既存のクラスター化されたプールに新しいホストを参加させようとするとエラーが発生する理由?
- クラスター化されたプールの一部のメンバーが自動的にクラスターに参加しない場合、どうすればよいか?
- ホストが自己フェンスしたかどうかを知る方法?
- ホストがオフラインになるのはなぜですか。どのように回復できますか?
- クラスター化されたプール内のホストがオフラインになり、回復できません。クラスターからホストを削除するにはどうすればよいですか?
- 停止済みとマークされたホストを修復しました。クラスターへの再追加方法?
- クラスターがクォーラムを失い続け、ホストがフェンシングを繰り返す場合の対処法?
- クラスター化されたプールでプールコーディネーターが再起動されるとどうなりますか?
- クラスター化されたプール内のホストが強制的にシャットダウンされた後、私のプールが消滅したのはなぜですか?
- クラスター化されたプール内のすべてのホストが同時に再起動したのはなぜですか?
- クォーラムがあるのに、クラスター化されたプールを回復できないのはなぜですか?
- クラスター設定を変更すると、Invalid tokenエラーが表示されるのはなぜですか?