クラスター化プールのトラブルシューティング
GFS2を使用して共有ブロックストレージをシンプロビジョニングするCitrix Hypervisorプールはクラスター化されています。これらのプールは、共有ファイルベースのストレージまたはLVMで共有ブロックストレージを使用するプールとは動作が異なります。その結果、Citrix Hypervisorクラスター化プールおよびGFS2環境で特定の問題が発生する可能性があります。
以下の情報を使用して、この機能の使用時に発生する可能性のある軽微な問題をトラブルシューティングします。
すべてのホストが相互にpingを送信できるものの、クラスターを作成できません。なぜですか?
クラスタリングメカニズムは特定のポートを使用します。ホストがこれらのポートで通信できない場合（他のポートで通信できる場合でも）、プールのクラスタリングを有効にすることはできません。
プール内のホストが次のポートで通信できることを確認します：
- TCP：8892、8896、21064
- UDP：5404、5405（マルチキャストではない）
プール内のホスト間にファイアウォールなどがある場合は、これらのポートが開いていることを確認してください。
以前にプール内で高可用性を構成したことがある場合は、クラスタリングを有効にする前に高可用性を無効にしてください。
新しいホストを既存のクラスター化プールに参加させようとするとエラーが発生するのはなぜですか?
プールでクラスタリングが有効になっている場合、プールのメンバーシップの変更はすべて、クラスターのすべてのメンバーによって同意されないと成功しません。クラスターメンバーが接続不可の場合は、クラスターメンバーシップを変更する操作（ホストの追加や削除など）を行うことができなくなります。
新しいホストをクラスター化プールに追加するには、次の手順を実行します：
-
すべてのホストがオンラインであり、接続できることを確認してください。
-
プール内のホストが次のポートで通信できることを確認します：
- TCP：8892、8896、21064
- UDP：5404、5405（マルチキャストではない）
-
参加ホストのIPアドレスが、プールのクラスターネットワークに参加するNICに割り当てられていることを確認します。
-
新しいホストがクラスター化プールに参加しようとするときに、プール内のホストがオフラインになっていないことを確認します。
-
オフラインのホストを回復できない場合は、そのホストを停止としてマークしてクラスターから削除します。詳しくは、「クラスター化プール内のホストがオフラインになっており回復できません。クラスターからホストを削除するにはどうすればよいですか?
クラスター化プールの一部のメンバーが自動的にクラスターに参加しない場合はどうすればよいですか?
この問題は、クラスター化プールのメンバーが同期を失っていることが原因である可能性があります。
クラスター化プールのメンバーを再同期するには、次のコマンドを使用します：
xe cluster-pool-resync cluster-uuid=<cluster_uuid>
問題が解決しない場合は、GFS2ストレージリポジトリを再接続してみることができます。このタスクは、xe CLIまたはXenCenterを使用して実行できます。
xe CLIを使用してGFS2ストレージリポジトリを再接続します：
-
GFS2ストレージリポジトリをプールから切り離します。各ホストで、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ストレージリポジトリを再接続します。
または、XenCenterを使用してGFS2ストレージリポジトリを再接続するには、次の手順を実行します：
- プールの ［ストレージ］ タブで、GFS2ストレージリポジトリを右クリックし、［接続解除］ を選択します。
- ツールバーから ［プール］>［プロパティ］ を選択します。
- ［クラスタリング］ タブで、［クラスタリングを有効にする］ の選択を解除します。
- ［OK］ をクリックして変更を適用します。
- ツールバーから ［プール］>［プロパティ］ を選択します。
- ［クラスタリング］ タブで、［クラスタリングを有効にする］ を選択し、クラスタリングに使用するネットワークを選択します。
- ［OK］ をクリックして変更を適用します。
- プールの ［ストレージ］ タブで、GFS2ストレージリポジトリを右クリックし、［修復］ を選択します。
ホストが自己隔離しているかどうかを確認するにはどうすればよいですか?
ホストが自己隔離している場合は、再起動時にクラスターに再度参加している可能性があります。ホストが自己隔離して回復したかどうかを確認するには、/var/opt/xapi-clusterd/boot-timesファイルをチェックしてホストが起動した時間を確認できます。ファイル内に予想外の開始時間が含まれている場合は、ホストが自己隔離しています。
ホストがオフラインになっているのはなぜですか? どうすれば回復できますか?
ホストがオフラインになる理由は数多く考えられます。理由に応じて、ホストを回復できるかどうかが決まります。
以下は、ホストがオフラインになるより一般的な理由であり、ホストを回復することで対処できます：
- 完全なシャットダウン
- 強制シャットダウン
- 一時的な停電
- 再起動
以下は、ホストがオフラインになるあまり一般的ではない理由です：
- 永続的なホストのハードウェア障害
- 永続的なホストの停電
- ネットワークパーティション
- ネットワークスイッチの障害
これらの問題は、ハードウェアを交換するか、障害が発生したホストを停止としてマークすることで解決できます。
クラスター化プール内のホストがオフラインになっており回復できません。クラスターからホストを削除するにはどうすればよいですか?
クラスターにホストを消去するよう指示できます。この操作は、クラスターからホストを永久に削除し、クォーラムに必要な稼働中ホストの数を減らします。
回復不可能なホストを削除するには、次のコマンドを使用します：
xe host-forget uuid=<host_uuid>
このコマンドは、クラスターからホストを永久に削除し、クォーラムに必要な稼働中ホストの数を減らします。
注：
ホストがオフラインでない場合、このコマンドによりデータ損失が発生する可能性があります。コマンドを続行する前に、間違いがないことを確認するよう求められます。
ホストが停止としてマークされると、そのホストをクラスターに再度追加することはできません。このホストをクラスターに再度追加するには、ホスト上でCitrix Hypervisorを新規インストールする必要があります。
停止とマークされたホストを修復しました。クラスターに再度追加するにはどうすればよいですか?
停止としてマークされたCitrix Hypervisorホストをクラスターに再度追加することはできません。このシステムをクラスターに再度追加するには、ホスト上でXenServerを新規インストールする必要があります。この新規インストールは、クラスターでは新しいホストとして認識されます。
クラスターがクォーラムを失い続け、そのホストが隔離を続けている場合はどうすればよいですか?
クォーラムの取得と喪失が繰り返されるためにクラスター内の1つ以上のCitrix Hypervisorホストが隔離のループに陥った場合は、noclusterカーネルコマンドライン引数を使用してホストを起動できます。ホストの物理コンソールまたはシリアルコンソールに接続し、grubで起動引数を編集します。
例：
/boot/grub/grub.cfg
menuentry 'XenServer' {
search --label --set root root-oyftuj
multiboot2 /boot/xen.gz dom0_mem=4096M,max:4096M watchdog ucode=scan dom0_max_vcpus=1-16 crashkernel=192M,below=4G console=vga vga=mode-0x0311
module2 /boot/vmlinuz-4.4-xen root=LABEL=root-oyftuj ro nolvm hpet=disable xencons=hvc console=hvc0 console=tty0 quiet vga=785 splash plymouth.ignore-serial-consoles nocluster
module2 /boot/initrd-4.4-xen.img
}
menuentry 'Citrix Hypervisor (Serial)' {
search --label --set root root-oyftuj
multiboot2 /boot/xen.gz com1=115200,8n1 console=com1,vga dom0_mem=4096M,max:4096M watchdog ucode=scan dom0_max_vcpus=1-16 crashkernel=192M,below=4G
module2 /boot/vmlinuz-4.4-xen root=LABEL=root-oyftuj ro nolvm hpet=disable console=tty0 xencons=hvc console=hvc0 nocluster
module2 /boot/initrd-4.4-xen.img
}
<!--NeedCopy-->
クラスター化されたプールでプールマスターが再起動されるとどうなりますか?
ほとんどの場合、クラスター化プールでプールマスターがシャットダウンまたは再起動されたときの動作は、別のプールメンバーがシャットダウンまたは再起動されたときの動作と同じです。
ホストのシャットダウンまたは再起動の方法は、クラスター化プールのクォーラムに影響を与える可能性があります。クォーラムについて詳しくは、「クォーラム」を参照してください。
動作の唯一の違いは、プールでHAが有効になっているかどうかによります：
- HAが有効な場合、新しいマスターが選択され、一般的なサービスが維持されます。
- HAが有効になっていない場合、プールのマスターは存在しません。残りのホストで実行中の仮想マシンは引き続き実行されます。ほとんどの管理操作は、マスターが再起動されるまで使用できません。
クラスター化プール内のホストが強制的にシャットダウンされた後、プールが消えたのはなぜですか?
ホストを（強制的ではなく）平常どおりにシャットダウンすると、再度オンになるまで、そのホストはクォーラム計算から一時的に削除されます。一方で、ホストを強制的にシャットダウンした場合、またはホストの電源が失われた場合、そのホストはクォーラムの計算にカウントされます。たとえば、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-->
デバッグ用のログを収集する場合は、クラスター内のすべてのホストから診断情報を収集します。単一のホストが自己隔離されている場合、クラスター内の他のホストが有用な情報を持っている可能性が高くなります。
クラスター化プール内のホストの完全なサーバーの状態レポートを収集します。詳しくは、「Citrix Hypervisorのホストログ」を参照してください。
クォーラムがあるのにクラスター化プールを回復できないのはなぜですか?
偶数のホストを持つクラスター化プールがある場合、クォーラムを_達成する_ために必要なホストの数は、クォーラムを_維持する_ために必要なホストの数より1つ多くなります。クォーラムについて詳しくは、「クォーラム」を参照してください。
偶数のプールでホストの半分を回復している場合は、クラスターを回復する前に、もう1台のホストを回復する必要があります。
クラスター設定を変更するとInvalid tokenエラーが表示されるのはなぜですか?
クラスターの構成を更新するときに、無効なトークン("[[\"InternalError\",\"Invalid token\"]]")に関する次のエラーメッセージが表示される場合があります。
この問題は、以下の手順を実行することで解決できます：
-
（オプション）xapi-clusterdおよびシステムログを含むサーバーの状態レポートを収集して、現在のクラスター構成をバックアップします。
-
XenCenterを使用して、クラスター化されたプールからGFS2ストレージリポジトリを解除します。
プールの ［ストレージ］ タブで、GFS2ストレージリポジトリを右クリックし、［接続解除］ を選択します。
-
クラスター内の任意のホストで次のコマンドを実行してクラスターを強制的に破棄します：
xe cluster-pool-force-destroy cluster-uuid=<uuid> -
XenCenterを使用して、プールのクラスタリングを再度有効にします。
- ツールバーから ［プール］>［プロパティ］ を選択します。
- ［クラスタリング］ タブで、［クラスタリングを有効にする］ を選択し、クラスタリングに使用するネットワークを選択します。
- ［OK］ をクリックして変更を適用します
-
XenCenterを使用してGFS2ストレージリポジトリをプールに再接続します
プールの ［ストレージ］ タブで、GFS2ストレージリポジトリを右クリックし、［修復］ を選択します。
この記事の概要
- すべてのホストが相互にpingを送信できるものの、クラスターを作成できません。なぜですか?
- 新しいホストを既存のクラスター化プールに参加させようとするとエラーが発生するのはなぜですか?
- クラスター化プールの一部のメンバーが自動的にクラスターに参加しない場合はどうすればよいですか?
- ホストが自己隔離しているかどうかを確認するにはどうすればよいですか?
- ホストがオフラインになっているのはなぜですか? どうすれば回復できますか?
- クラスター化プール内のホストがオフラインになっており回復できません。クラスターからホストを削除するにはどうすればよいですか?
- 停止とマークされたホストを修復しました。クラスターに再度追加するにはどうすればよいですか?
- クラスターがクォーラムを失い続け、そのホストが隔離を続けている場合はどうすればよいですか?
- クラスター化されたプールでプールマスターが再起動されるとどうなりますか?
- クラスター化プール内のホストが強制的にシャットダウンされた後、プールが消えたのはなぜですか?
- クラスター化プール内のすべてのホストが同時に再起動したのはなぜですか?
- クォーラムがあるのにクラスター化プールを回復できないのはなぜですか?
- クラスター設定を変更するとInvalid tokenエラーが表示されるのはなぜですか?