HA機能

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

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

HRPC KVM版でHAを利用するには、「共有ストレージ」に仮想マシンの仮想ディスクが設置されている必要があります。次の条件を満たしている必要があります。

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

Proxmox VEのHAの概要

Proxmox VEのHAの概要は、下記の通りです。

物理ホストをHA Groupを作成する。HA時のふるまいはHA Groupで決める。
仮想マシンをそのHA Groupに参加させる。

クラスター(仮想データセンター)全体でHAが作られ、その中で作られた仮想マシンが、自動的にHA管理される設計思想ではありません。

また、HRPCは、標準でHAは設定されていません。

HA Groupを作成する(機能を有効化)

HA機能を有効にしたい場合、まず左側のペインでデータセンターを選択、中のペインでHAを開きグループをクリックします。右のペインで作成ボタンを押し、HAグループのIDを作成、HAに関係するホストをチェックします。

HA Groupは複数作る事ができますし、HA Groupに物理ホストをいれないこともできるので、4台のマシン契約時に3台でHA Groupをつくり、1台はHA範囲外にすることも可能です。HAグループのrestrictedがチェックされていると、そのHAグループに属している仮想マシンは、HA Groupから外されたホストで起動できません。

nofailbackをチェックしている場合、フェイル(故障)した物理ノードがリブートして戻ってきた際に、仮想マシンを元に戻さず、退避先で動作させ続けます。nofailbackをチェックしていない場合は、元のノードにライブマイグレーションで戻すため、ノードホストと仮想マシンの配置を厳密に管理する事ができます。

物理ノードが不安定になり再起動を繰り返すケースの場合は、またHAが稼働し仮想マシンが再起動を繰り返すことになります。そのため、nofilbackにはチェックを入れることを推奨しています。

また、仮想マシンのライブマイグレーションは実績のある熟れた技術ですが、Proxmox VEを含め、全てのライブマイグレーションは内部的には一瞬の停止があり、その停止中に載せ替えを行います。そこで、リアルタイム性が極めて重要なソフトウェアでは、問題がおきる可能性もあります。

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

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

仮想マシンをHA管理下に置く場合は、当該の仮想マシンを選択し、右上の「More▼」プルダウンメニューから「HAの管理」を選びます。

上記で設定したHAグループのIDをグループから選択し、要求状態をstartedにした上で、追加ボタンを設定します。

これでこの仮想マシンは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等を利用し、ホストのカーネル応答がなくなっても、カーネルを自動的に再起動できるようなデバイスがつけられたハードウェアでプライベートクラウドは動作しています。