サーバ仮想化環境を構築する目的の1つに、物理マシンのCPUやメモリといったシステムリソースの利用率向上が挙げられる。よくいわれることだが、物理サーバで構築するシステムの場合は、1つのOSで1つのアプリケーションを動かすことが安定運用のコツなので、結果として物理サーバのシステムリソースが大きく余ってしまう。このもったいない状態を、サーバ仮想化によって有効活用しようというのだ。今はやりのエコである。そのエコを追求すると、システムリソースを常に高い利用率に保つようにシステムを構築するのがセオリーである。ただ、そのような環境でバックアップを行ったらどうなるだろう？　バックアップのジョブというのは相当に負荷が掛かるので、システムリソースが不足するケースがよく見受けられる。特に物理マシンに10台以上の仮想マシンが稼働しているような環境で、複数のバックアップを同時に走らせたら、物理マシンやネットワークの負荷も上限に達してしまう。夜間にジョブが終了せずに翌朝の業務開始になっても高負荷状態が続き、本番業務に悪影響を及ぼしてしまうことさえある。

　別の側面の悩みとしては、サーバを集約するということは、さまざまな環境のシステムが1カ所にまとまるということだ。例えばWindows、Linux、UNIXといったOSが混在して1台の物理マシンで稼働することもある。これまでは、環境ごとに詳しいサーバ管理者がいてバックアップシステムも面倒を見ていた。これがサーバ仮想化環境になると、さまざまなOSやアプリケーションをまとめて面倒見なければならなくなり、バックアップのシステムも複雑になってしまう。管理者は複数のシステムにわたる知識が必要になるし、サーバの集約率が上がればバックアップが幅広い環境に適用していないと厄介である。

　サーバ仮想化環境のメリットの1つに、システムの規模の変化に合わせて簡単に仮想マシンを増やせることがある。ただ、そこで気を付けなければならないのは、ソフトウェアのライセンスコストだ。エージェントにライセンス費用が必要なバックアップソフトウェアの場合、仮想マシン単位でコストが掛かってしまう。環境の変化に合わせて仮想マシンを増やして効率化しても、ライセンスコストがかさむようでは効果も半減である。

サーバ集約化が招くバックアップ問題の例

　このように、物理サーバと同じようにバックアップソフトウェアのエージェントを入れるようなバックアップ手法は、簡単に導入することができる半面、サーバ集約の足かせになりかねない。ではどのような環境に適しているのだろう。物理マシン内で稼働している仮想マシンがあまり多くなく、システムリソースに余裕を持たせる設計であれば問題はない。サーバ仮想化環境を試験的に運用するときや、小規模のサーバ集約であればこの手法で十分である。なお、仮想マシン内でデータ重複排除の処理を行うバックアップソフトウェアであれば、システムリソースに長時間負荷を掛けずにバックアップを行うことができるので、集約率の高いサーバ仮想化環境では検討してみるのもよいだろう。「EMC Avamar」やSymantecの「NetBackup 7」と「Backup Exec 2010」などがそのタイプの製品である。

簡単にできる「仮想マシン丸ごとバックアップ」

　ここまでは、サーバ仮想化環境で簡単に導入できるバックアップ方法と注意点について述べてきたが、ここからは、サーバ仮想化環境だからできるバックアップ方法についてVMwareを例に取って説明しよう。VMwareが提供する「VMware VCB（VMware Consolidated Backup）」や最新の仮想化環境であるVMware vSphereにて提供している「vStorage APIs for Data Protection」といった、バックアップを効率的に行う仕組みと連携すれば、仮想マシンを「丸ごとバックアップ」することができる。これはシステムレベルのバックアップを簡単に、しかも仮想マシンに負荷を掛けずに行えるのだ。丸ごとバックアップをする手法といえば、これまでの物理サーバの環境であれば高価なストレージを使ってスナップショット機能などを利用する必要があったが、サーバ仮想化環境であれば比較的簡単に運用できる。

　基本的には、ファイル単位にリストアする目的ではなく、仮想マシン自体に障害が発生した場合に素早く元の状態に戻したい要求に応えるものである。仕組みは下図を参照していただきたいのだが、VCB連携の場合、カプセル化された大きな1つのファイル（VMDK：仮想ディスク）を丸ごとバックアップするので、対象ファイルの数が少なく、容易に環境全体を保護することができる。

VMware VCBを使った仮想マシンの「丸ごとバックアップ」の流れ

　仮想マシンにバックアップのエージェントを入れる必要がないので、物理マシンのシステムリソースに負荷を掛けずに運用が可能である。SAN経由でデータを送ることができるため、LANにも負荷が掛からない。また、エージェントのライセンスコストが必要なくなるので、コストを気にすることなく仮想マシンを増強して集約化することができる。加えて、仮想マシンを丸ごとバックアップするということは、丸ごとリストアで全体を元に戻せるため、いざというときの災害対策としても使うことがある。

　いいことずくめのようにも思える「丸ごとバックアップ」だが、検討するに当たり、幾つか注意することもある。仮想マシンのイメージは、カプセル化された1つの大きなファイルである。バックアップソフトウェアからすれば、日々のデータ変更も差分となるので、結果として毎回フルバックアップと同じデータ量を取ることになる。大量のデータを長時間バックアップするので、データ量とバックアップ時間のサイジングに気を付けよう。バックアップはスナップショットのボリュームから行うので、バックアップ対象のデータと同じサイズの空き領域をストレージ側に用意する必要もある。最新のvStorage APIsでは、CBT（Changed Block Tracking ）という差分ブロック情報を追跡する機能があり、APIに準拠したソフトウェアであればブロック単位での変更個所が特定できる。そのため、VMDKファイルのすべてをバックアップ対象にする必要がなくなり、バックアップやレプリケーションの効率が大幅に向上している。

　また、「丸ごとバックアップ」は基本的にシステム単位でのリストアを目的としているので、ファイル単位でのリストアが難しい。ただ、最近のバックアップソフトウェアによっては、個別のファイル単位でリストアすることも可能である。一般的なリストア方法と同じように扱うことができることを付け加えておく。

　「丸ごとバックアップ」に威力を発揮するのが、ブロックレベルでの重複排除が可能なバックアップソフトウェアやストレージである。毎回フルバックアップを取得しても、保存するデータは日々の差分ブロックとなるので、ストレージ容量を最小限に抑えることができる。VCB連携のバックアップを行うのに適した手法である。

　このように、サーバ仮想化環境のバックアップには大きく2つの方法があり、どれだけ集約化されているかによって使い分けをするのがよいだろう。仮想化環境のインフラを提供するベンダーは、いかにバックアップを効率良く行うことができるかを常に考えているので、さらにサーバの集約化が加速されるのではないかと期待ができる。今後もぜひ仮想化環境のトレンドをウオッチしていただきたい。