HA機能

High Availability機能は、物理ホストに障害があった際、自動的に正常な他のホストで仮想マシンを「再起動」(これをフェイルオーバーと呼びます)する機能です。そのため仮想マシンのゲストOS内で、自動的にシステムが復旧するように、事前に整えておく必要があります。

HAを利用するための条件とは？

HRPC KVM版で、HAを利用するには、次の条件を満たす必要があります。

3台以上の完全な同一構成のノードで組まれた仮想データセンターであること。
HCIタイプか、3Tierタイプであること。これは、共有ストレージ(Ceph、ESによるESF)が必要となるためです。
機器に十分な余剰(特にメモリ)があること。少なくてもノード1台分のメモリは全体で空いていることが重要です。
※たとえば、3台のノードで組まれた仮想データセンターの場合、合計で2台分のメモリしか利用してはいけません。
仮想マシンのバックアップが確実に取られていること
Backup Storageなどの契約をし、仮想マシンの定期バックアップを設定することを強く推奨します。

HA機能を有効にするには？

HA機能を有効にしたい場合、まず左側のペインでデータセンターを選択、中のペインでHAを開きグループをクリックします。

右のペインで作成ボタンを押し、HAグループのIDを作成、HAに関係するホストをチェックします。HAに関係するホストで仮想マシンを作る際には、少なくても物理ホスト1台分のメモリの余剰を用意しておかなくてはなりません。768GBのメモリを搭載しているHRPC合計4台を、全てHAに参加させる場合、HRPC1台が物理的に障害を起こしたとしても、他の機器で動作が続けられるように、残り3台で768GB分の空きメモリ容量が必要になります。HAグループにチェックを入れない場合、同一データセンターにありながら、HA対象から無視されます。

HAのメンバーから敢えて外されたホストがあるとき、HAグループのrestrictedがチェックされていると、そのHAグループに属している仮想マシンは、外されたホストで起動できません。

nofailbackをチェックしている場合、フェイル(故障)した物理ノードがリブートして戻ってきた際に、仮想マシンを元に戻さず、退避先で動作させ続けます。nofailbackをチェックしていない場合は、元のノードにライブマイグレーションで戻すため、ノードホストと仮想マシンの配置を厳密に管理する事ができます。しかし物理ノードが不安定になり再起動を繰り返すケースの場合は、またHAが稼働し仮想マシンが再起動を繰り返すことになります。そのため、nofilbackにはチェックを入れることを推奨しています。

また、ライブマイグレーションはあまり失敗しない機能ではありますが、内部的には一瞬の停止があり、その停止によってリアルタイム系ソフトウェアに問題を引き起こすこともあります。

仮想マシンをHAの対象にするには？

ProxmoxのHAは仮想マシンをHA管理下に置かない限りHAの対象にはなりません。

仮想マシンをHA管理下に置く場合は、当該の仮想マシンを選択し、右上の「More▼」プルダウンメニューから「HAの管理」を選びます。上記で設定したHAグループのIDをグループから選択し、要求状態をstartedにした上で、追加ボタンを設定します。

これでこの仮想マシンはHAの管理下に入ります。

HAの動作範囲は、ハイパバイザによってポリシーが異なります。VMwareでは仮想データセンターでHAを有効にした場合は仮想データセンター内の仮想マシン全てが影響しますし、XenOrchestraではプール内で有効にした仮想マシンで「再起動」を設定したマシンにだけ効果があります

HAグループに入っているノード(ホスト)のメンテナンス再起動と仮想マシンの関係

HAグループに入ったノードをメンテナンスなどで再起動させる時(不意の障害などではなく)、仮想マシンのふるまいは、HAの管理下にあるかどうかで異なります。

HA管理下の仮想マシン	別のマシンへライブマイグレーションする
HA管理外の仮想マシン	自動的にシャットダウンし、再起動後もシャットダウンしたまま

コラム

HA機能の限界

HA機能には限界があり、HAを利用することで起きる障害があります。

仮想マシンの不慮の再起動
仮想マシンのデータの破壊

シンプルに言えば、HAはノードに障害が起きた時に、別のノードから仮想マシンを起動する機能ですが、これは神の眼で見た視点での動作であって、実際のソフトウェアロジックは全く異なる実装をせざるを得ません。

まず、3つのノード全体(ノードA、ノードB、ノードCがあるとき)の中で、固有のノードに「障害が起きた」ということを定義することは厳密にはできません。HAはそれぞれのノードが互いに協調しあって動作しています。

ノードA視点でノードBに対する疎通が取れなくなったとき、ノードBに障害が起きたのか、ノードAとノードBの疎通が取れなくなっただけなのかがわかりません。仮にノードA視点でノードCと疎通があれば、ノードBに障害が起きたであろう可能性は想像できます。

しかしノードBに収容している仮想マシンのデータが、共有ストレージ上で更新され続けている場合、ノードBは純粋に孤立してる可能性もあります。

上記でノードAとCが疎通している場合、ノードBに障害が起きている可能性が高くなります。そこでノードAとCはノードBが収容している仮想マシンを自分達がブートしようとします。

しかしノードBは障害ではなく、孤立している可能性もあります。ノードは自身が孤立したと判断した場合、ノードAとCが起動する可能性に備え、直ちに収容している仮想マシンをシャットダウンさせます。これが上記の不慮の再起動を引き起こします。

ではノードBがもし、シャットダウンさせない場合は、どうなるのでしょうか？

同じ仮想マシンがノードBと他のノードの2箇所で動くことになり、仮想マシンの仮想ディスクはたちまち破損してしまいます。これが上記の仮想マシンのデータの破壊に繋がります。

つまり再起動か、データの破壊かの二者択一となるのです。

≫ 参考テクニカルノート/CAP定理を時間と空間に拡張する「落ちず、速く、信頼できるサービスをどう作るのか？」

HAはそれぞれのノードの間で協調しながら、落ちてるのか、疎通を失ってるだけなのか、遅いのかを判別する必要があります。

上記の2つの障害が二者択一である場合、避けなくてはならないのはデータの破壊です。従って直ちにシャットダウンをするのです。

この判断はインターバルを持って行い、Proxmoxでは2分単位に行います。2分応答しなければ「ホストに障害が起きた」と判断します。そのため最短でも2分間＋仮想マシンがブートする時間は、ダウンタイムに繋がります(実際はもっとかかります)。

しかし、ノードの速度が遅くなっていたり、メモリがスワップアウトしたり、Ballooningドライバによるメモリ回収で一時的に重くなったり、また、ストレージの書き込みが遅くなったりすることが発生すると、2分という時間はすぐに過ぎてしまい、シャットダウンが間に合わない場合もあります。守らなくてはならないのはデータであるため、システムは自動的にWatchDog Timer等を利用し、ホストのカーネル応答がなくなっても、カーネルを自動的に再起動できるようなデバイスがつけられたハードウェアでプライベートクラウドは動作しています。