virtualization.info 日本語

前回 は、仮想データセンタにおけるリソース管理がいかに複雑になるのかを見てきた。しかし、これは仮想化を進めるなかで管理者が対応を迫られる課題の1つに過ぎない。

どのインフラにも共通することだが、仮想マシンの高可用性を実現し、迅速な災害対策と、環境のなかのゲスト、ホスト、ストレージといった不完全な部分に対して信頼性の高いフェイルオーバーを確実に行う作業はさらに細心の注意を要する。

これらの作業を今日行う場合、新たな技術的課題があり、基本的に市場に有効なソリューションがないため、物理サーバ上での作業より複雑になる。

バックアップ

仮想データセンタにおけるバックアップ戦略は、すべてのゲストOSにバックアップエージェントをインストールし、ファイル、パーティション、あるいは仮想ディスク全体をほかにコピーするというように、従来のものと似ている。

このアプローチはうまくいくが、これを仮想環境に適用する場合は深刻なマイナス面がある。どの仮想マシンもホストOSから提供された同じI/Oチャネルを使うため、複数のマシンがバックアップを同時に開始すると、I/Oのボトルネック発生が必至となる。

これを回避するには、管理者が一連のバックアップ計画を慎重に立て、これらの高負荷処理中にゲストOSが絶対にオーバーラップしないよう、各バックアップ処理の間に十分な間隔を入れる必要がある。

残念ながら、この手法は拡張が不可能で、各仮想ディスクに少なくとも3Gバイトの容量があることを考慮すると、仮想マシンがある程度の台数を超えるとバックアップのオーバーラップは回避できない。各仮想ディスクの容量は最低3Gバイトで（さらに、アプリケーションの要件に応じて最大10～20Gバイト以上に達する）、バックアップの実行には数時間を要する場合もある。

また、ゲストOSのバックアップでは、管理者がレストア時にまず空の仮想マシンを作成し、そのなかでまっさらのリカバリCDからブートするといった作業を余儀なくされる。

これに代わるアプローチとしては、ゲストOSに対して透過的な方法で、ホストレベルでバックアップを行う方法がある。

仮想マシンは1つのファイルのなかにすべてがそろっており、ホストOSのファイルシステムをスプレッドシートやピクチャのようにとらえているため、仮想化の初心者だと、そのバックアップは簡単だと思うかもしれないが、多くの場合に好まれるにもかかわらず、実際はこちらの方が格段に難しい。

そもそも仮想マシンは、オープンされていて、プロセスやアプリケーションにロックされたファイル（Microsoft Outlookが持っている「.PST」メールアーカイブをイメージすればよい）のようなものと考えられる。これらのファイルには特殊なアクセス方法が必要で、これらのステータスのイメージを完全に止めておいて（通常スナップショットと呼ばれる処理）から、バックアップ処理を実行する。

この作業は、ホストOSが手伝う場合もあるが、バックアップソフトウェアがオープンされたファイルの処理方法を分かっていて初めて実行できる。たとえば、「Microsoft Windows Server 2003」には「Volume Shadow Service」（VSS）と呼ばれる機能があり、サードパーティーソリューションがこれを呼び出してスナップショットを実行する。

オープンされたファイルの処理方法が分かっても、まだもう1つ難しい問題がある。ライブバックアップの実行だ。仮想マシンは、オープンされたファイルという単純なものではなく、完全なOSが完全な仮想ハードウェア群にアクセスしているイメージだ。

スナップショットを取るときは、仮想メモリや割り込みも含めてすべてが必ずいったん固定さる。これは、仮想技術の世界では電源障害と同様に見なされ、ゲストファイルシステムの構造を破壊する場合もある。

OSが堅牢で電源障害によるデータ破壊がなくても、このアプローチのサポートに乗りだしているベンダーの数は少ない。

「esxRanger」で人気を得たvizioncoreはその1つだ。同製品では、VMware ESX Server上である程度自動化された仮想マシンのライブバックアップが可能となっている。

また、サポートがなくてもこのようなシナリオを試したいという勇敢な方には、Massimiliano Daneri氏が開発した有名な「VMBK」スクリプトがある。これも、VMware ESX Server仮想マシン向けの基本的なライブバックアップを行う。

Microsoftも「Virtual Server 2005」の「Service Pack 1」で同様のサポートを実現しているが、標準の「Microsoft Backup」ではこの作業はできない。

ホットシャットダウン問題の回避策として仮想化ベンダー各社に唯一支持され、一般に受け入れられているのは、動作中の仮想マシンをサスペンドもしくはシャットダウンし、バックアップ実行後にレジュームもしくは再起動するというアプローチだ。

しかし残念ながら、この方法では高可用サービスは提供できず、ミッションクリティカルな仮想マシンには、管理者も従来のエージェントベースのバックアップ方法を使わざるを得ない。

ライブバックアップの問題は、OSの仮想化対応が進めばいずれは解消される。だがそのほかにも、2番目のアプローチもホストのI/Oチャネルに多少負担になることを覚えておいて損はないだろう。

この問題を完全に排除するには、バックアップのポイントをホストからストレージに移す必要がある。ここであれば、仮想化プラットフォームに直接影響を与えず仮想マシンファイルを操作できる。

これまでは、VMwareがこのソリューションの最初の採用者となっていたが、今日では同社の「Consolidated Backup（VCB）」の制限が大きく懸念されている。ESX Serverにしか対応しておらず、実際のサードパーティー製バックアップソリューションのプロキシとしてしか機能せず（顧客は製品ごとに異なるスクリプトのインストールを余儀なくされる）、レストアを実行できないのだ。

ストレージレベルのままで別の手法を使うことはSAN管理ソフトウェアの利用やLUNクローニングの呼び出しを意味するが、たいていの場合、このアプローチでは十分に細かい設定を行うことができない。ストレージ機能がフォーマット済みのLUNをネイティブで認識しないため、1台の仮想マシンを対象にするバックアップができないためだ。

LUNフォーマットの認識は、購入したストレージ管理ソフトウェアと、サポートされるファイルシステムに依存する。

ここではNTFSフォーマットのLUNは認識し、VMware Server for Windowsの仮想マシンはバックアップできるかもしれないが、VMFSはサポートできず、VMware ESX Serverの仮想マシンも同じ状況だ。

LUNフォーマットが認識されなかったり、単純に強化ストレージ管理ソリューションが手元にない場合は、複数の仮想マシンが含まれるLUN全体をクローニングし、必要なのが1つだけでもすべてのレストアを余儀なくされることになる。

フェイルオーバーとクラスタリング

言うまでもなく、仮想データセンタで高可用性（HA）を実現するには仮想マシンのバックアップ以外にも必要なことがある。従来の環境と同じように、クラスタ構造にするか少なくともフェイルオーバー構造を用意したい。

しかし、仮想化のHAは1つだけでなく2つのレベルで行われる場合がある。OSとアプリケーションの災害対策機能に依存してゲストレベルで行うか、ホストレベルで行って新たなタイプの問題に対処するかのいずれかだ。

HAのコンフィギュレーションをゲストレベルでインプリメントするのは、既に物理環境で行っていることとほぼ同じだ。仮想ネットワークインターフェースごとに静的MACアドレスを設定したり、選ばれた仮想化プラットフォームやHAソフトウェアによっては制限があるなど、技術的な問題もいくつかある。

しかし、基本的には仮想クラスタを作成できないケースはなく、最低1ノード以上が仮想マシンで、ほかは物理マシンであるなど、混在するクラスタでも問題はない。

はるかに複雑ながら、それ以上に必要とされるのが、ホストでの高可用性実現だ。

このシナリオでフェイルオーバーなどを考えた場合、1台のホスト上で動作する仮想マシンは別のホストにコピーし、常に同期をとって仮想ディスクや仮想メモリに対する修正をレプリケートする必要がある。

この操作もライブバックアップのところで既に解説した同じ問題を抱えているが、すべてをできるだけ迅速かつ数多く行うという複雑性が加わる。

ここでも主役はvizioncoreで、「esxReplicator」を使えば、一元管理されたストレージの有無にかかわらず、動作中の仮想マシンを1つのVMware ESX Serverから別のものへコピーできる。残念ながら、この製品は本来のフェイルオーバー処理に必要なネットワークの修正には対応していないため、障害を抱えたホストとコールドスタンバイ中のものとは手動で切り替える必要がある。

さらにダイナミックなソリューションはVMware自身が提供しており、ESX Server 3と「VirtualCenter 2」でVMotionベースのフェイルオーバーオプションが提供されている。

vizioncoreのesxReplicatorとは異なり、VMware HAは障害を抱えたホストの仮想マシンを自動的に再起動するが、コンフィギュレーションに関する要求はこちらの方がはるかに高い。VirtualCenterとVMotionが必要で、仮想マシンがファイバチャネルのSANに格納されていないと機能しない。

また、先に説明したPhysical-to-Virtual（P2V）移行ツールのおかげで別のアプローチも可能になっている。

Virtual-to-Virtual移行もできるため、あるホストから別のホストに仮想マシンのコンテンツをレプリケートするようなコンフィギュレーションも可能となっている。

ここでは今のところ「PlateSpin」が選択肢として優れており、Windows OSのライブ移行が可能なほか、この技術の災害対策用途も既に考慮されている。

残念ながら、vizioncore同様、PlateSpinもフェイルオーバーのあらゆる側面に対応するわけではないため、手動での操作が必要な部分も残っている。

フェイルオーバーは優れたソリューションだが、最も望まれるHAコンフィギュレーションがクラスタリングであることは明らかだ。ここでは、複数のホストが一般的に共有される仮想マシンの実行用フロントエンドとして機能する。もしこれらの1つがダウンしても、残りのホストで常に仮想マシンが提供されているため、サービスが中断されることは決してない。

クラスタリング機能は、仮想化プラットフォームのネイティブ機能としてホストレベルで、もしくはサードパーティーソリューションとしてインプリメントできる。

たとえば、Virtual Serverの場合はWindowsがホストOSとなり、Microsoftが同社のCluster Serviceを介した仮想物理ノードのクラスタリングを認めている。

一方、ESX Serverの方にはこのような機能がなく、「Symantec Veritas Cluster Service」のような外部ソリューションにこの部分を依存している。EMC Corporationが先ごろRainfinityを買収したことで、いずれはESXのクラスタリングをネイティブで実行するためにRainwall技術が使われるようになるとの期待が生まれている。

しかし、今日の仮想化用クラスタリングソリューションは熟成レベルにはほど遠く、購入予定者には、採用前に本格的なテストを実施することを強く推奨する。

フェイルオーバーとクラスタリングのコンフィギュレーションも、アーキテクチャによっては複雑になる。仮想マシンを1つのホストから別のホストへ移動すると、異なるベンダーのCPUでサービスが提供される可能性があり、これらが似てはいても同一ではない場合、現行の仮想化プラットフォームではライブ移行時にリアルタイムで違いを吸収することができない。

同様に、利用可能なホストのハードウェアコンフィギュレーションが異なる場合も、仮想マシンの仮想ハードウェアの割り当てが満足に行かず（4つの仮想CPUを搭載したVMを考えると良い）、移行が全く行えない可能性もある。

これは、ベンダー各社が準仮想化のサポートをどのようにインプリメントするかにより、近い将来最悪の状況を招きかねない。

ご存じのように、このアプローチにはホストOSを特殊なリングレベルで実行できる新しい世代のCPUが必要になる。仮想化プラットフォームが通常のバイナリ変換と準仮想化を同時に実行できない、もしくはこれらをシームレスに切りかえられないと、新旧の混在した物理サーバを同時に利用することができず、新しいハードウェアを購入するたびにハードウェアインフラ全体の刷新を余儀なくされる。もしくは、高可用性実現のためにホストの集約方法を慎重に決めざるを得なくなる。

大事なことを言い忘れていたが、ストレージ関連には信頼性の高いI/O経路を与える必要がある。これが最も重要なステップであることは確実だ。

これは、たいていの場合いわゆるマルチパシングによって処理される。複数のSANに接続できるようコンフィギュレーションされた複数のホットバスアダプタがホストに搭載されている場合、ストレージ管理ソフトウェアが障害を起こしたもののなかから動作可能なものを優先してダイナミックに選ぶ方法を把握している。

しかし、ソフトウェア機能がドライバレベルで提供されている場合はいくつか制限がある。

選ぶ仮想化プラットフォームによってはこのような機能がない場合がある。たとえば、VMware ESX Serverの現行アーキテクチャでは、ストレージベンダー各社が自社のドライバを組み込めないようになっており、ダイナミックマルチパシングをサポートしないものが提供されている。

VMware ServerやMicrosoft Virtual Serverなどのホステドソリューションを選ぶときはOEM各社のドライバサポートをOSに依存するが、こちらの方は常に認められている。

＊ご注意：本稿は、昨年英語版サイトで最も閲覧されたニュースのうちの一つとして掲載しております。そのため一部情報が古い可能性もございます。 なお、原文はこちらをご参照ください。