マシンの障害に対処する
このセクションでは、さまざまな障害シナリオから回復する方法について詳しく説明します。すべての障害回復シナリオでは、バックアップに記載されているバックアップタイプのうち1つ以上を使用する必要があります。
メンバーの障害
HAがない場合、プールコーディネーターノードは、定期的なハートビートメッセージを受信することでメンバーの障害を検出します。600秒間ハートビートが受信されない場合、プールコーディネーターはメンバーが停止していると判断します。この問題から回復するには、次の2つの方法があります。
-
停止したホストを修復します（たとえば、物理的に再起動する）。メンバーへの接続が復元されると、プールコーディネーターはメンバーを再び稼働中としてマークします。
-
ホストをシャットダウンし、
xe host-forgetCLIコマンドを使用して、プールコーディネーターにメンバーノードを忘れるように指示します。メンバーが忘れられると、そこで実行されていたすべてのVMはオフラインとしてマークされ、他のXenServerホストで再起動できます。XenServer®ホストが実際にオフラインであることを確認することが重要です。そうしないと、VMデータが破損する可能性があります。
xe host-forgetを使用して、プールを単一ホストの複数のプールに分割しないでください。この操作により、すべてのプールが同じ共有ストレージをマッピングし、VMデータが破損する可能性があります。
警告:
- 忘れられたホストを再度アクティブなホストとして使用する場合は、XenServerソフトウェアを新規インストールしてください。
- プールでHAが有効になっている場合は、
xe host-forgetコマンドを使用しないでください。まずHAを無効にし、ホストを忘れ、その後HAを再度有効にしてください。
メンバーのXenServerホストが故障した場合、実行中の状態として登録されたVMが残っている可能性があります。メンバーのXenServerホストが確実に停止していると確信できる場合は、xe vm-reset-powerstate CLIコマンドを使用してVMの電源状態をhaltedに設定してください。詳細については、vm-reset-powerstateを参照してください。
警告:
このコマンドを誤って使用すると、データ破損につながる可能性があります。必要な場合にのみこのコマンドを使用してください。
別のXenServerホストでVMを起動する前に、VMストレージのロックを解除する必要もあります。SR内の各ディスクは、一度に1つのホストのみが使用できます。ホストが故障した場合、ディスクを他のXenServerホストからアクセス可能にすることが重要です。そのためには、影響を受けるVMのディスクを含む各SRについて、プールコーディネーターで次のスクリプトを実行します: /opt/xensource/sm/resetvdis.py host_UUID SR_UUID master
障害が発生したホストがクラッシュ時にSRプールコーディネーターであった場合にのみ、3番目の文字列（「master」）を指定する必要があります。（SRプールコーディネーターとは、プールコーディネーターまたはローカルストレージを使用するXenServerホストのことです。）
警告：
このコマンドを実行する前に、ホストが停止していることを確認してください。このコマンドを誤って使用すると、データ破損につながる可能性があります。
resetvdis.pyスクリプトを実行する前に別のXenServerホストでVMを起動しようとすると、次のエラーメッセージが表示されます: VDI <UUID> already attached RW。
プールコーディネーターの障害
リソースプールのすべてのメンバーは、必要に応じてプールコーディネーターの役割を引き継ぐために必要なすべての情報を含んでいます。プールコーディネーターノードが失敗すると、次のイベントシーケンスが発生します。
-
HAが有効になっている場合、別のプールコーディネーターが自動的に選出されます。
-
HAが有効になっていない場合、各メンバーはプールコーディネーターが復帰するのを待ちます。
この時点でプールコーディネーターが復帰すると、メンバーとの通信を再確立し、操作は正常に戻ります。
プールコーディネーターが停止している場合は、メンバーの1つを選択し、その上でコマンドxe pool-emergency-transition-to-masterを実行します。それがプールコーディネーターになったら、コマンドxe pool-recover-slavesを実行すると、メンバーは新しいプールコーディネーターを指すようになります。
元のプールコーディネーターであったホストを修復または交換する場合、単に起動し、XenServerソフトウェアをインストールして、プールに追加することができます。プール内のXenServerホストは均一であることが強制されているため、交換されたホストをプールコーディネーターにする必要は実際にはありません。
メンバーのXenServerホストがプールコーディネーターに移行されたら、デフォルトのプールストレージリポジトリが適切な値に設定されていることを確認してください。この確認は、xe pool-param-listコマンドを使用して、default-SRパラメーターが有効なストレージリポジトリを指していることを検証することで行うことができます。
プールの障害
不幸にもリソースプール全体が失敗した場合、プールデータベースを最初から再作成する必要があります。xe pool-dump-database CLIコマンドを使用して、プールメタデータを定期的にバックアップするようにしてください（pool-dump-databaseを参照）。
完全に失敗したプールを復元するには：
-
新しいホストセットをインストールします。この段階ではプールにまとめないでください。
-
プールコーディネーターとして指定されたホストについては、
xe pool-restore-databaseコマンドを使用してバックアップからプールデータベースを復元します (pool-restore-database を参照)。 -
XenCenter® を使用してプールコーディネーターに接続し、すべての共有ストレージとVMが再び利用可能であることを確認します。
-
残りの新しくインストールされたメンバーホストでプール結合操作を実行し、適切なホストでVMを起動します。
構成エラーによる障害への対処
物理ホストマシンは動作しているが、ソフトウェアまたはホスト構成が破損している場合：
-
ホストソフトウェアと構成を復元するには、次のコマンドを実行します。
xe host-restore host=host file-name=hostbackup <!--NeedCopy--> -
ホストインストールCDで再起動し、バックアップから復元を選択します。
物理マシンの障害
物理ホストマシンが故障した場合は、以下のリストから適切な手順を使用して復旧します。
警告：
以前のメンバー（または以前のホスト）で実行されていて障害が発生したVMは、データベース内で引き続き
Runningとマークされます。この動作は安全のためです。2つの異なるホストで同時にVMを起動すると、深刻なディスク破損につながります。マシン（およびVM）がオフラインであることを確認できる場合は、VMの電源状態をHaltedにリセットできます。
xe vm-reset-powerstate vm=vm_uuid --forceその後、XenCenterまたはCLIを使用してVMを再起動できます。
障害が発生したプールコーディネーターを稼働中のメンバーに置き換えるには：
-
次のコマンドを実行します。
xe pool-emergency-transition-to-master xe pool-recover-slaves <!--NeedCopy--> -
コマンドが成功したら、VMを再起動します。
すべてのホストが失敗したプールを復元するには：
-
コマンドを実行します。
xe pool-restore-database file-name=backup <!--NeedCopy-->警告：
このコマンドは、ターゲットマシンに適切な数の適切な名前のNICがある場合にのみ成功します。
-
ターゲットマシンが元のマシンと異なるストレージビューを持っている場合は、
pbd-destroyコマンドを使用してストレージ構成を変更します。次に、pbd-createコマンドを使用してストレージ構成を再作成します。これらのコマンドのドキュメントについては、pbd commands を参照してください。 -
ストレージ構成を作成した場合は、
pbd-plugまたは XenCenter の Storage > Repair Storage Repository メニュー項目を使用して、新しい構成を使用します。 -
すべてのVMを再起動します。
VMストレージが利用できない場合にVMを復元するには：
-
次のコマンドを実行します。
xe vm-import filename=backup metadata=true <!--NeedCopy--> -
メタデータのインポートが失敗した場合は、コマンドを実行します。
xe vm-import filename=backup metadata=true --force <!--NeedCopy-->このコマンドは、「最大限の努力」に基づいてVMメタデータを復元しようとします。
-
すべてのVMを再起動します。