無停止環境を実現するVMware FTとは：VMware vSphere 4徹底解剖（5）（5/6 ページ）

VMware FTの動作の仕組み

それではVMware FTの構造について解説しよう。VMware FTはその基礎技術としてRecord/Replayと呼ばれる機能を活用している。このため、まずRecord/Replayテクノロジーについて解説し、その後VMware FTの構造について解説する。

仮想マシンのRecord/Replayテクノロジー

　Record/Replay機能とは、その名の通り仮想マシンの実行を記録・再生する機能である。製品としてはVMware Workstation 6.0（2007年販売開始）より本機能を提供している。

　Record/Replayの基本アイデアは、「仮想マシンの実行履歴を記録しておき、後から再生できるようにする」というものだ。コンピュータを「巨大なステートマシン」として捉えてみよう。すると個々のインストラクションは「状態遷移」と見なすことができる。もし全ての「状態遷移」を記録することができたならば、コンピュータの実行を「再生」することもできるだろう、というものだ。

　ただ、コンピュータが実行するインストラクションは膨大な量となるため、これらを全て記録することは性能・計算資源の両面において現実的ではない。そこでVMwareでは、全インストラクションを記録せずとも、コンピュータの動作の記録・再生を実現できないかと考えた。

　コンピュータの動作はInput、Calculation、Outputのいずれかに大別することができる。そして、「今日のアーキテクチャのコンピュータは、その動作の大半がCalculationで占められている」ということが分かっている。そしてコンピュータには「Calculationは、Inputによって決定される」、「OutputはCalculationによって決定される」という特性があるため、「Inputを正確に記録・再現できれば、Calculation、Outputも正確に再現できる」ということになる。

　InputはCalculationに比べると遥かにデータ量が小さいため、記録・再生は比較的現実的な計算資源の中で対応することができる。しかし、扱うデータ量が現実的になったとしても、実際のInput情報を正確に記録し、正確に再現することは、技術的な観点において困難とされてきた。コンピュータへのInputと一言で言っても、時刻や割り込みなど、ソフトウェア的な記録や再現が困難な要素が多分に含まれるためである。このため、物理マシンに対してソフトウェアでRecord/Replayを実現するのは現実的なアプローチではないと考えられている。

　しかし、対象を仮想マシンに限定すると、このアプローチは極めて現実的なものとなる。仮想マシンはソフトウェアによって構成されているため、実行時にInput情報を記録しておき、再生時には実行時と完全に同一の入出力デバイスを再現し、Input情報を流し込むことが可能になる。

　VMware WorkstationのRecord/Replay機能はこの考え方を製品として実装したものである。仮想マシンの実行ログをファイルに記録しておき、それを後から再生することができる。同一のInput情報を用いて仮想マシンの再生が行われるため、記録時に発生したさまざまな入力や時刻など、全てのCalculationとOutputが再現される。VMware Workstationではこの機能を開発・デバッグ時のツールとして位置付けている。

図15 仮想マシンのRecord/Replay機能

Record/ReplayとVMware FT

　VMware FTはRecord/Replay技術をうまく活用することで実現されている。プライマリ仮想マシン側で発生したInput情報を、ネットワーク経由で別のESXに転送し、そこでセカンダリ仮想マシンを常に再生し続けることで、待機系として利用しようというアイデアである。FT Loggingインターフェイスがこのトラフィックの転送に利用される。この技術のことをvLockstepテクノロジーと呼ぶ。また、VMware FTの仕組みの中で転送されるRecord/ReplayログのことをFTログと呼ぶ。

図16　vLockstepテクノロジーによるフォールトトレランスの実現

　技術的には、仮想マシンに対して発生したInput情報を正しく伝播させることができれば実現できるが、仮想マシンの各実行ステートに対して正確にイベントを送り込む処理は、それなりに計算コストが高い。本番業務で利用するには、計算資源の消費を現実的なレベルに抑え、性能的なオーバーヘッドを最小限に留めなければならない。Record/Replayテクノロジーではマシンのステートに同期したInputの正確な記録・再生を実現するため、eip（Extended Instruction Pointer）、brCnt（Branch Counter）、ecx（iteration counter）と呼ばれる3個のレジスタの値を利用しているが、VMware FTではこれらのデータのインタープリタ部分において、Performance Counterと呼ばれるハードウェアの機能を活用している。分岐や繰り返し処理のカウントをハードウェアで処理することにより、実行ステートに対するイベントの正確なデリバリ処理を、高速・低負荷で実現することに成功している。

　VMware FTの利用がサポートされているCPUは比較的新しいものに限られているが、その理由はここにある。Performance Counter機能を保有するCPUはIntelでは45nm Core 2（Penryn）以降、AMDでは3rd Generation Opteron（GreyHound）以降となっており、VMware FTはこれに依存しているためである。

データロスの可能性を排除

　VMware FTはプライマリVM側から送出されたFTログを、セカンダリVM側で受信・再生し続けるという方式で動作しているため、プライマリVMのステート、セカンダリVMのステートの間には時間的な遅延が存在している。一方で、フォールトトレランスを実現するためには、どのタイミングでプライマリ側が故障しても、セカンダリVMはデータロスを発生させることなく、プライマリに昇格して処理を引き継ぐことができなければならない。つまり、セカンダリは多かれ少なかれ確実に遅れて実行されているという前提の中で、データロスの可能性を構造的に排除しなければならないということである。

　これを実現するため、VMware FTではOutputの遅延処理という技術が導入されている。先述の通り、コンピュータはInput、Calculation、Outputのいずれかを実行している。Outputとは具体的にはネットワークのパケット送出や、ディスクへの書き込み処理のことを指す。FTログがセカンダリ側のESXに到達する前に、プライマリVMがOutputを実行してしまうと、データロスの可能性を排除できなくなってしまう。故障発生のタイミングによっては、セカンダリVMをプライマリVMに昇格させる際に必要となるデータが、セカンダリ側のESXにまだ到達していなかったという状況が起こり得るためだ。

　そこでVMware FTでは、FTログの転送機構の中で「到着確認応答」の処理を実装している。セカンダリ側のESXは、各FTログについて受信完了の応答信号をプライマリ側のESXに送り続ける。これにより、プライマリ側はセカンダリ側のFTログの受信状況を知ることができる。プライマリVMがOutput処理を実行する際には、そこまでのFTログがセカンダリに到達していることを確認してから、実際のOutput処理を行う。Outputの遅延処理を行うことで、プライマリ/セカンダリのペアを1つの系として捉えたときのフォールトトレランスを実現しているのである。

　ここで重要なのは、プライマリVMがOutputの遅延処理を行っている間、仮想マシン全体を停止しているわけではない、という部分にある。Outputの遅延処理を行っているのは仮想デバイスのレイヤであり、ゲストOSはその間も動作し続けている。ゲストOSは仮想NICや仮想HBAなどにOutput処理を発行済みであるが、それをハンドルする仮想化レイヤ側において、仮想デバイス単位でOutputの遅延処理を行っている。ゲストOS側からはデバイスからのI/O完了応答を待っている状態として処理されるため、ゲストOSはI/O Wait時間を別のCPU処理に割り当てることができる。このような粒度の細かい遅延処理を実装することで、仮想マシンのスループットをほとんど劣化させることなく、構造的にデータロスの可能性を排除したFT機構を実現している。

　セカンダリVMもInputに基づいてVMを実行しているため、プライマリVM側がOutputを実行した直後に、セカンダリVM側も同内容のOutputを実行することになる。ただしそれらは仮想化レイヤ側が吸収し、実際に外部に対しては出力されない。このため、ネットワークパケットの送出や、ディスク装置への書き込み処理は、全てプライマリVM側から実行されている。