7.6. ホストの耐障害性
7.6.1. ホストの高可用性
Red Hat Virtualization Manager はフェンシングを使用してクラスター内のホストを応答可能な状態に維持します。Non Responsive のホストは、Non Operational のホストとは異なります。Manager は Non Operational のホストとは通信することができますが、ホストの設定は正しくありません (例: 論理ネットワークが見つからないなど)。Manager は、Non Responsive のホストとは通信できません。
フェンシングにより、クラスターは予期せぬホスト障害に対応可能となり、パワーセービング、負荷分散、および仮想マシンの可用性の各ポリシーが強化されます。ホストの電源管理デバイスにはフェンシングパラメーターを設定し、その正確性を時々テストすることを推奨します。フェンシングの操作では、応答なしのホストがリブートされて、所定時間内にアクティブな状態に戻らない場合には、手動による介入とトラブルシューティングが行われるまで、応答なしの状態が続きます。
engine-config の PMHealthCheckEnabled (デフォルト: false) および PMHealthCheckIntervalInSec (デフォルト: 3600 秒) オプションを設定して、フェンシングパラメーターを自動的に確認することができます。
PMHealthCheckEnabled を true に設定すると、PMHealthCheckIntervalInSec で指定した間隔ですべてのホストエージェントが確認され、問題が検出されると警告が出されます。engine-config オプション設定の詳細については、「engine-config コマンドの構文」を参照してください。
電源管理の操作は、再起動後の Red Hat Virtualization Manager、プロキシーホスト、または管理ポータルでの手動操作により実施することができます。応答なしのホスト上で実行されている仮想マシンはすべて停止し、高可用性の仮想マシンが別のホストで起動します。電源管理の操作には、少なくとも 2 台のホストが必要です。
Manager の起動後、沈黙時間 (デフォルトでは 5 分) が経過しても電源管理が設定されたホストが応答なしの場合には、自動的にフェンシングを試みます。沈黙時間は、engine-config の DisableFenceAtStartupInSec オプションを更新して設定することができます。
engine-config の DisableFenceAtStartupInSec オプションにより、Manager が起動中のホストをフェンシングしようとするのを防ぐことができます。通常、ホストの起動プロセスは Manager より長いので、データセンターの障害が発生した後にこのような状況となる可能性があります。
電源管理のパラメーターを使用すると、プロキシーホストによりホストを自動的にフェンシングすることができます。手動で行うには、ホストを右クリックすると表示されるメニューのオプションを使用します。
高可用性の仮想マシンを実行するホストでは、電源管理を有効にして設定する必要があります。
7.6.2. Red Hat Virtualization におけるプロキシーを使用した電源管理
Red Hat Virtualization Manager はフェンスエージェントとは直接通信を行いません。その代わりに、Manager はプロキシーを使用して電源管理のコマンドをホストの電源管理デバイスに送ります。Manager は VDSM を利用して電源管理デバイスの操作を実行し、環境内の別のホストがフェンシングプロキシーとして使用されます。
以下のいずれかを選択することができます。
- フェンシングが必要なホストと同じクラスター内にある任意のホスト
- フェンシングが必要なホストと同じデータセンター内にある任意のホスト
有効なフェンシングプロキシーホストのステータスは Up または Maintenance です。
7.6.3. ホスト上でのフェンシングパラメーターの設定
ホストのフェンシング用のパラメーターを編集するには、新規ホスト または ホストの編集 ウィンドウの 電源管理 タブを使用します。電源管理により、システムは Remote Access Card (RAC) などの追加のインターフェースを使用して、問題のあるホストをフェンシングすることができるようになります。
電源管理操作はすべて、Red Hat Virtualization Manager が直接行うのではなく、プロキシーホストを使用して実行します。電源管理の操作には、少なくとも 2 台のホストが必要です。
ホスト上でのフェンシングパラメーターの設定
- → をクリックし、ホストを選択します。
- 編集 をクリックします。
- 電源管理 タブをクリックします。
- 電源管理を有効にする のチェックボックスを選択し、フィールドを有効にします。
kdump 統合 チェックボックスを選択して、カーネルクラッシュダンプの実行中にホストがフェンシングされないようにします。
重要既存のホストで kdump 統合 を有効にする場合には、kdump を設定するためにそのホストを再インストールする必要があります。「ホストの再インストール」を参照してください。
- オプションで、ホストが属するクラスターの スケジューリングポリシー がホストの電源管理を制御しないようにするには、電源管理のポリシー制御を無効にする のチェックボックスを選択します。
- + のボタンをクリックして、新規電源管理デバイスを追加します。フェンスエージェントの編集 ウィンドウが開きます。
- 電源管理デバイスの アドレス、ユーザー名、および パスワード を入力します。
ドロップダウンリストから電源管理デバイスの タイプ を選択します。
注記カスタムの電源管理デバイスの設定方法については、「How to set up a custom fence agent for power management in RHEV 3.5」の記事を参照してください。
- 電源管理デバイスがホストとの通信に使用する SSH ポート 番号を入力します。
- 電源管理デバイスのブレードの特定に使用する スロット 番号を入力します。
- 電源管理デバイスの オプション を入力します。「key=value」エントリーのコンマ区切りリストを使用してください。
- 電源管理デバイスからホストへのセキュアな接続を有効にするには、セキュリティー保護 のチェックボックスを選択します。
テスト ボタンをクリックして、設定が正しいことを確認します。検証が正常に完了すると、「Test Succeeded, Host Status is: on」というメッセージが表示されます。
警告Red Hat Virtualization Manager によって電源管理のパラメーター (ユーザー ID、パスワード、オプションなど) がテストされるのは、セットアップ時のみで、それ以降は手動で実行します。パラメーターが正しくないことを警告するアラートを無視した場合や、電源管理デバイスで変更されたパラメーターが Red Hat Virtualization Manager では同じように変更されていない場合には、フェンシングを最も必要とする時に失敗してしまう可能性があります。
- OK をクリックして フェンスエージェントの編集 ウィンドウを閉じます。
- 電源管理 タブでは、オプションとして 詳細パラメーター の箇所を展開し、上下に移動するボタンを使用して Manager がフェンシングプロキシーを探す際に使用するリソース (cluster および dc (データセンター)) の順序を指定します。
- OK をクリックします。
ホストの一覧に戻ります。ホスト名に横の感嘆符が表示されなくなった点に注意してください。これは、電源管理の設定が適切に完了したことを意味します。
7.6.4. fence_kdump の詳細設定
kdump
ホスト名をクリックして、詳細ビューの 全般 タブで kdump サービスのステータスを確認します。
- 有効: kdump が適切に設定されており、kdump サービスが実行中です。
- 無効: kdump サービスは実行されていません (その場合には、kdump 統合は適切に機能しません)。
- 不明: kdump ステータスを報告しない、以前のバージョンの VDSM を使用しているホストでのみ発生します。
kdump のインストールおよび使用方法に関する詳しい情報は、『Red Hat Enterprise Linux 7 カーネル管理ガイド』の「カーネルクラッシュダンプガイド」を参照してください。
fence_kdump
新規ホスト または ホストの編集 ウィンドウの 電源管理 タブで kdump 統合 を有効にすると、標準的な fence_kdump 構成が設定されます。環境のネットワーク設定が単純で、かつ Manager の FQDN が全ホストで解決可能な場合に使用するには、デフォルトの fence_kdump 設定で十分です。
ただし、fence_kdump の詳細設定が必要となる場合があります。より複雑なネットワークには、Manager と fence_kdump リスナーのいずれか一方または両方の設定を手動で変更する必要がある可能性があります。たとえば、kdump 統合 を有効にした全ホストで Manager の FQDN が解決できない場合には、engine-config を使用して、適切なホスト名または IP アドレスを設定することができます。
engine-config -s FenceKdumpDestinationAddress=A.B.C.D以下の例のような場合には、設定の変更も必要となる可能性があります。
- Manager に 2 つの NIC があり、一方がパブリックで、他方が fence_kdump メッセージの指定送信先の場合。
- 異なる IP またはポートで fence_kdump リスナーを実行する必要がある場合。
- fence_kdump 通知メッセージの間隔をカスタム設定して、パッケージの損失を防ぐ必要がある場合。
デフォルト設定の変更は、ネットワーク設定がより複雑な場合にのみ必要となるので、カスタマイズされた fence_kdump 検出設定は上級ユーザーのみが使用することを推奨します。fence_kdump リスナーの設定オプションについては、「fence_kdump リスナーの設定」を参照してください。Manager 上での kdump の設定については、「Manager での fence_kdump の設定」を参照してください。
7.6.4.1. fence_kdump リスナーの設定
fence_kdump リスナーの設定を編集します。この手順は、デフォルトの設定が十分でない場合にのみ必要です。
fence_kdump リスナーの手動設定
- /etc/ovirt-engine/ovirt-fence-kdump-listener.conf.d/ に新規ファイルを作成します (例: my-fence-kdump.conf)。
OPTION=value の構文でカスタマイズの設定を入力し、ファイルを保存します。
重要編集した値は、「Manager での fence_kdump の設定」の fence_kdump リスナーの設定オプションの表に記載したように、
engine-configでも変更する必要があります。fence_kdump リスナーを再起動します。
# systemctl restart ovirt-fence-kdump-listener.service
以下のオプションは、必要に応じてカスタマイズすることができます。
表7.9 fence_kdump リスナーの設定オプション
| 変数 | 説明 | デフォルト | 注記 |
|---|---|---|---|
|
LISTENER_ADDRESS |
fence_kdump メッセージを取得する IP アドレスを定義します。 |
0.0.0.0 |
このパラメーターの値を変更する場合には、 |
|
LISTENER_PORT |
fence_kdump メッセージを受信するポートを定義します。 |
7410 |
このパラメーターの値を変更する場合には、 |
|
HEARTBEAT_INTERVAL |
リスナーの Heartbeat の更新間隔を秒単位で定義します。 |
30 |
このパラメーターの値を変更する場合には、 |
|
SESSION_SYNC_INTERVAL |
リスナーのホストのメモリー内の kdump セッションをデータベースと同期する間隔を秒単位で定義します。 |
5 |
このパラメーターの値を変更する場合には、 |
|
REOPEN_DB_CONNECTION_INTERVAL |
以前に利用できなかったデータベース接続を再開する間隔を秒単位で定義します。 |
30 |
- |
|
KDUMP_FINISHED_TIMEOUT |
kdump を実行するホストからメッセージを最後に受信した後に、ホストの kdump フローが FINISHED とマークされるまでのタイムアウトの最大値を秒単位で定義します。 |
60 |
このパラメーターの値を変更する場合には、 |
7.6.4.2. Manager での fence_kdump の設定
Manager の kdump 設定を編集します。この手順は、デフォルトの設定が十分でない場合にのみ必要です。現在の設定値は、以下のコマンドを実行すると確認できます。
# engine-config -g OPTIONengine-config を使用した kdump の手動設定
engine-configコマンドを使用して kdump の設定を編集します。# engine-config -s OPTION=value
重要編集した値は、
Kdump の設定オプションの表に記載した fence_kdump リスナーの設定ファイルでも変更する必要があります。「fence_kdump リスナーの設定」を参照してください。ovirt-engineサービスを再起動します。# systemctl restart ovirt-engine.service
- 必要な場合には、kdump 統合 が有効化されている全ホストを再インストールします (以下の表を参照)。
以下のオプションは、engine-config を使用して設定することができます。
表7.10 Kdump の設定オプション
| 変数 | 説明 | デフォルト | 注記 |
|---|---|---|---|
|
FenceKdumpDestinationAddress |
fence_kdump メッセージの送信先のホスト名または IP アドレスを定義します。この値が指定されていない場合には、Manager の FQDN が使用されます。 |
空の文字列 (Manager の FQDN が使用されます) |
このパラメーターの値を変更する場合には、fence_kdump リスナー設定ファイルの |
|
FenceKdumpDestinationPort |
fence_kdump メッセージを送信するポートを定義します。 |
7410 |
このパラメーターの値を変更する場合には、fence_kdump リスナー設定ファイルの |
|
FenceKdumpMessageInterval |
fence_kdump メッセージの送信間隔を秒単位で定義します。 |
5 |
このパラメーターの値を変更する場合には、fence_kdump リスナー設定ファイルの |
|
FenceKdumpListenerTimeout |
最後の Heartbeat の後に、fence_kdump リスナーが実行中と見なされなくなるまでのタイムアウトの最大値を秒単位で定義します。 |
90 |
このパラメーターの値を変更する場合には、fence_kdump リスナー設定ファイルの |
|
KdumpStartedTimeout |
kdump を実行するホストからの最初のメッセージを受信するまで (ホストの kdump フローが開始したことを検知するまで) の待ち時間のタイムアウトの最大値を定義します。 |
30 |
このパラメーターの値を変更する場合には、fence_kdump リスナー設定ファイルの |
7.6.5. ホストのソフトフェンシング
ホストは、予期しない問題が原因となって応答なしの状態になる場合があります。VDSM は要求に応答できませんが、VDSM に依存している仮想マシンは稼働を続け、アクセス可能な状態のままとなります。このような状況が発生した場合には、VDSM を再起動すると、VDSM が応答可能な状態に戻り、問題は解決します。
「SSH を介したソフトフェンシング」は、Manager が SSH を使用して、応答しない状態のホストで VDSM の再起動を試みるプロセスです。Manager が SSH を使用した VDSM の再起動に失敗した場合には、フェンシングは外部のフェンスエージェントの責任となります (外部のフェンスエージェントが設定されている場合)。
SSH ソフトフェンシングが機能するためには、ホストでフェンシングが設定および有効化されており、かつ有効なプロキシーホスト (同じデータセンター内にある、ステータスが Up の第 2 のホスト) が存在している必要があります。Manager とホスト間の接続がタイムアウトになると、次のような状態となります
- 初回のネットワーク障害発生時には、ホストのステータスが「connecting」に変わります。
- Manager は次に VDSM に対してステータス確認を 3 回試みるか、ホストの負荷によって決定される時間が経過するのを待ちます。この時間は、[TimeoutToResetVdsInSeconds (デフォルトは 60 秒)] + [DelayResetPerVmInSeconds (デフォルトは 0.5 秒)] * [ホスト上で実行中の仮想マシン数] + [DelayResetForSpmInSeconds (デフォルトは 20 秒)] * [1 (ホストが SPM として稼働している場合) または 0 (ホストが SPM としては稼働していない場合)] の計算式で決定されます。VDSM が応答する時間を最大限にするために、Manager は上記のオプション (VDSM のステータス確認を 3 回試みる、または上記の計算式で決定される時間の経過を待つ) のいずれか長い方を選択します。
-
この時間が経過してもホストが応答しない場合には、SSH を介して
vdsm restartが実行されます。 -
vdsm restartを実行しても、ホストと Manager 間の接続が再度確立されない場合には、ホストのステータスがNon Responsiveに変わります。電源管理が設定されている場合には、フェンシングは外部のフェンスエージェントによって引き継がれます。
SSH を介したソフトフェンシングは、電源管理を設定していないホストに対しても実行することが可能です。これは、「フェンシング」とは異なります。フェンシングは、電源管理が設定されたホストでしか実行することはできません。
7.6.6. ホストの電源管理機能の使用方法
ホストに電源管理の設定を行うと、管理ポータルから数多くのオプションにアクセスすることができるようになります。電源管理デバイスには、それぞれカスタマイズ可能なオプションがありますが、ホストを起動、停止、再起動する基本的なオプションは全デバイスでサポートされます。
ホストの電源管理機能の使用方法
- → をクリックし、ホストを選択します。
→ をクリックし、以下のオプションのいずれかを選択します。
-
再起動: このオプションはホストを停止させて、ホストのステータスが
Downに変わるのを待ちます。ホストが Down の状態となったことをエージェントが確認すると、高可用性の仮想マシンが同じクラスター内の別のホスト上で再起動します。次にエージェントは、このホストを再起動させて、ホストの準備が整うと、ステータスがUpに変わります。 -
起動: このオプションは、ホストを起動させて、クラスターにアタッチします。使用する準備が整うと、ステータスが
Upに変わります。 停止: このオプションは、ホストの電源を切断します。このオプションを使用する前には、そのホスト上で実行中の仮想マシンが同じクラスター内の別のホストに移行済みであることを確認してください。そうでない場合には、仮想マシンがクラッシュし、高可用性のマシンのみが別のホストで再起動します。ホストが停止すると、ステータスは
Non Operationalに変わります。注記電源管理が有効ではないホストを再起動または停止するには、そのホストを選択して 管理 ドロップダウンメニューをクリックし、再起動 または 停止 を選択します。
重要1 台のホストに 2 つのフェンスエージェントを定義すると、それらのエージェントは同時もしくは順次に使用することができます。同時エージェントの場合に、ホストを停止させるには、両方のエージェントが停止のコマンドに応答する必要があります。また、一方のエージェントが起動のコマンドに応答すると、ホストが起動します。順次エージェントの場合に、ホストを起動または停止させるには、プライマリーエージェントが最初に使用され、それが失敗するとセカンダリーエージェントが使用されます。
-
再起動: このオプションはホストを停止させて、ホストのステータスが
- OK をクリックします。
7.6.7. 応答なしのホストの手動によるフェンシングまたは分離
ハードウェア障害などが原因で、ホストが予期せず応答なしの状態となった場合には、環境のパフォーマンスに多大な影響を及ぼす可能性があります。電源管理デバイスを使用していない場合や、正しく設定されていない場合は、ホストを手動でリブートすることができます。
ホストを手動でリブートした場合以外は、ホストがリブートされていることを確認 のオプションは使用しないでください。ホストの稼働中にこのオプションを使用すると、仮想マシンのイメージが破損してしまう場合があります。
応答なしのホストの手動によるフェンシングまたは分離
-
管理ポータルで → をクリックし、ホストのステータスが
Non Responsiveであることを確認します。 - ホストを手動で再起動します。これは、物理マシンの電源ボタンを押してホストをリブートすることを意味します。
- 管理ポータルでホストを選択し、 → をクリックします。
- 操作を承認 チェックボックスにチェックを入れて、OK をクリックします。
ホストの起動に通常より長い時間がかかる場合は、
ServerRebootTimeoutを設定してホストをNon Responsiveとみなすまでの時間を指定することができます (秒単位)。# engine-config --set ServerRebootTimeout=integer

Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.