仮想化導入ガイドPart9 仮想環境の高可用性実現のためにすべきこと：Step by Step

仮想化環境でシステム全体をダウンさせることなく、継続稼働させる（＝可用性を高める）のに有効なフェイルオーバーとクラスタリングについて解説する。

[Alessandro Perilli，TechTarget]

　仮想データセンターの高可用性（High Availability）を実現するには、ライブバックアップとフェイルオーバーやクラスタリングなど、複合的な取り組みが必要になる。この連載の前回では、仮想マシン（VM）のバックアップを取り上げた。今回は、仮想環境でフェイルオーバーを構成する方法やクラスタを構築する方法を見てみよう。

　仮想環境の高可用性は、2つのレベルで実現される。ゲストレベルで高可用性を実現する上では、OSとアプリケーションのディザスタリカバリ機能を利用できるが、ホストレベルで高可用性を実現しようとすると、仮想環境固有の問題に直面することになる。

　ゲストレベルでの高可用性構成の実装プロセスは、われわれが物理環境で行ってきたプロセスとほとんど同じだ。注意点としては、各仮想ネットワークインタフェースの静的MACアドレスの設定など、対処すべき技術的問題があるほか、選択した仮想化プラットフォームと高可用性ソフトウェアに応じて制約もある。しかし、基本的には常に、仮想クラスタの構築は可能であり、1つ以上のノードが仮想マシンで、ほかのノードが物理マシンである混合型クラスタを構築することもできる。

　これに対し、はるかに複雑だが、はるかに必要性が高いのが、ホストの高可用性の実現だ。例えば、フェイルオーバーによってホストの高可用性を実現する場合、あるホストで稼働する仮想マシンを別のホストにコピーして継続的に同期を取り、仮想ディスクと仮想メモリの変更をレプリケートしなければならない。このオペレーションでは、厄介な要素はライブバックアップと同じだが、すべてを可能な限り迅速かつ頻繁に行うための処理は、より複雑になる。

　こうしたフェイルオーバーを行うための主要なツールとして、ビジョンコアのesxReplicatorがある。esxReplicatorは、中央ストレージの有無にかかわらず、稼働中のVMを、ヴイエムウェアのVMware ESX Server間でコピーできる。だが、残念ながらesxReplicatorは、自動フェイルオーバーに必要なネットワーク変更に対応していないため、障害が発生したホストとコールドスタンバイホストの切り替えを手動で行わなければならない。

　より動的なソリューションがヴイエムウェアから提供されている。同社がESX Server 3とVirtualCenter 2で導入した、VMotionに基づくフェイルオーバーオプションだ。VMware HAと呼ばれるこのオプションは、ビジョンコアのesxReplicatorとは異なり、障害が発生したホストのVMを自動的に再開する。だが残念ながら、VMware HAは構成上の要件がはるかに厳しい。VMware HAは、VirtualCenterとVMotionを必要とし、VMがFibre Channel SAN環境に保存されていなければ、機能しない。

ほかの高可用性実現方法

　一方、P2V（Physical to Virtual）移行ツールは、V2V（Virtual to Virtual）移行に役立つことから、仮想マシンの内容をホスト間でレプリケートするように構成することができる。

　現在、この分野では、Windowsのライブ移行が可能なプレートスピンの製品の人気が高い。この技術はディザスタリカバリにも利用できる。だが残念ながら、ビジョンコアの製品と同様に、プレートスピンの製品はフェイルオーバーのあらゆる側面をカバーしているわけではないため、手動の操作も必要だ。

　フェイルオーバーを利用するのは良い方法だが、最も望ましい高可用性の構成方法がクラスタリングであることは間違いない。クラスタでは複数のホストが、通常共有されている仮想マシンを実行するためのフロントエンドとして機能する。ホストのうち1台がダウンしても、サービスは中断しない。仮想マシンがそれ以外のホストで運用されるからだ。

　クラスタリング機能はホストレベルで、仮想化プラットフォームのネイティブ機能を使って、あるいはサードパーティーのソリューションを使って実装できる。

　例えば、マイクロソフトのMicrosoft Virtual Serverでは、WindowsがホストOSであり、マイクロソフトは仮想環境における物理ノードのクラスタリングを、同社のCluster Serviceによって可能にしている。

　一方、VMwareESX Serverは、そうした機能を備えていないが、シマンテックのVeritas Cluster Serviceのようなサードパーティーのソリューションを利用して、そうしたクラスタリングを実現できるようになっている。ヴイエムウェアの親会社のEMCが先ごろレインフィニティを買収したことから、いずれはレインフィニティのRainWall技術を使って、ESX環境におけるクラスタリングをネイティブに実現できるようになることが期待される。

　現在、仮想環境用のクラスタリングソリューションは、成熟しているとはとても考えられないため、企業は導入する前に、あらかじめ本格的なテストを行うべきだろう。

幾つかの難問

　フェイルオーバーとクラスタリング構成は、複数のアーキテクチャを利用していると複雑になる。例えば、仮想マシンをホスト間で移動する場合、仮想マシンは、異なるベンダーの、類似しているが同じではないCPU上で動作することになる可能性がある。また、現在の仮想化プラットフォームは、ライブ移行中にリアルタイムでこうした違いに対処することはできない。

　同様に、使用可能なホスト間でハードウェア構成が異なる場合、VMの仮想ハードウェア割り当て（例えば、4個の仮想CPUを持つなど）が満たされず、移行がまったくできない可能性もある。

　こうした状況全体は近い将来、ベンダーが準仮想化のサポートをどのように実装するかによっては、深刻化するかもしれない。準仮想化は、ホストOSを特別なリングレベルで実行できる新世代のCPUを必要とするからだ。仮想化プラットフォームが、通常のバイナリ変換と準仮想化を同時に実行できなければ、あるいは、両者をシームレスに切り替えることができなければ、新旧の物理サーバを組み合わせて使えなくなってしまう。言い換えれば、高可用性を実現するために、新しい機器を買うたびにハードウェアインフラ全体を一新しなければならなくなるか、あるいは、ホストの統合の仕方を非常に慎重に決めなければならなくなる。

　最後にもう1つ重要な点は、信頼できるストレージアクセスの確保だ。これは間違いなく不可欠なステップであり、通常はいわゆるマルチパス機能によって実現されている。マルチパス機能は、ホストに2つ以上のHBA（ホストバスアダプタ）を装備し、それらを1つ以上のSANに接続できるように設定して、ストレージ管理ソフトウェアを利用することで、障害が発生したリンクではなく、稼働中のリンクを動的に選択して使用するというものだ。

　だが、ソフトウェアの機能がドライバレベルで提供される場合には、制約が生じる。選択する仮想化プラットフォームによっては、そうした機能が得られない場合がある。例えば、VMware ESX Serverの現在のアーキテクチャは、ストレージベンダー製のドライバを組み込むことができず、標準で用意されているドライバは、動的マルチパス機能をサポートしていない。

　一方、VMware ServerやMicrosoft Virtual Serverなど、ホストOS上で動作する仮想化ソリューションを選択する場合は、ホストOSによるOEMドライバのサポートという、常に保証されている機能を利用することになる。