JDSF | ストレージ管理ソリューション部会 | データ・ストレージに関する総合情報サイト

HOME > ストレージ管理ソリューション部会 > Storage Magazine翻訳記事

仮想サーバがバックアップにもたらす課題

著者：W. Curtis Preston
Storage Magazine 2009年8月号より

仮想サーバはデータセンター内の多くの問題を解決してきたが、同時にバックアップをいっそう困難にしてきた。仮想サーバをバックアップする方法はいくつかあるが、それぞれ固有のメリットとデメリットがある。

　バックアップは、今日の大規模環境におけるVMware環境にとって最も大きな課題だ。通常のバックアップ方式では、多くの環境で、1台のESXサーバ上に置く仮想マシン（VM）の数を限定しなければならないため、仮想サーバで得られるはずの全体的な価値が低下してしまう。さらに問題を複雑にするのは、問題解決が可能なソリューションでは、VMをバックアップするために追加の物理マシンを購入する必要があるということだ。

　しかし、VMware環境を別のストレージに移行しても構わなければ、問題を解決する既存の製品が存在する。それができない場合は、ストレージに依存しない製品が登場するまでの「バンドエイド（応急）処置」として利用できるものがいくつかある。最終的にどのように仮想マシンのバックアップに対処するかにしろ、少なくとも不満を感じているのが自分だけではないことがわかれば多少は安心できるだろう。

問題は物理環境
VMwareのことを考えると、いつも映画「マトリックス」を思い浮かべている自分に気がつく。VMware内で実行されている数百万台のVMは、映画のマトリックスの中で生きている仮想人間たちによく似ている。映画と同じように「マトリックス」（この場合はVMware）に接続すると、ありとあらゆる離れ業を演じることができる。マトリックスでは、空中を飛ぶことができる。VMwareでは、VMが1つの物理マシンから別の物理マシンへ、ほとんど中断なく飛ぶように移行することができる。マトリックスでは、カンフーを習得したり数秒でヘリコプターを飛ばしたりすることができる。VMwareでは、ハイパーバイザのおかげで、仮想マシン用に設計されたわけではないハードウェア上でも仮想マシンを実行することができる。

　しかし、マトリックスの中で人が死ぬと、その人は実世界でも死んでしまう。身体が仮想の痛みと物理的な痛みを区別できないためだ。同様に､VMwareは仮想世界と物理世界間の接続を切断することはできない。1台のESXシステム内で稼働している20のVMは、自分たちを20台の物理サーバだと思っているかもしれないが、実際には1つのI/Oシステムと、多くの場合1つのストレージシステムを備えた1台の物理サーバであるに過ぎない。したがって、バックアップシステムによってそれらが20台の物理サーバであるかのように取り扱われると、すぐにそれらが1台の物理サーバ内で稼働していることに気がつく。

通常のソリューション：仮想性の否定
大半のVMwareユーザは、単に自分の仮想マシンが物理マシンであるかのように振る舞う。私はさまざまなセミナー会場で、約5,000人のユーザに、VMwareのバックアップをどのように処理しているかについて統計をとってきた。いつも、VMwareでサーバを仮想化している人のうちVMware Consolidated Backup（VCB）も使用している人の割合はごくわずかだ。大多数は、物理サーバの場合と同じようにバックアップソフトウェアを使用している。

　そのような方法でバックアップを行うことに何ら問題はない。多くのバックアップ管理者が、VMのバックアップをそのように行っているのは自分だけだと考えて「VMwareバックアップコンプレックス」に陥っているが、実際はそのような人が大多数なのだ。

　VMのバックアップをそのように行い問題なく機能しているなら、心配する必要はない。従来のバックアップ手法の良いところは、プロセスがシンプルであることだ。仮想マシンのバックアップも「本当の」バックアップと同じように動作する。つまり、ファイルレベルのリカバリ、データベースとアプリケーションのエージェント、および増分バックアップを利用できる（下記「仮想マシンの旧式バックアップの改善」を参照）。

仮想マシンの旧式バックアップの改善

従来型のソフトウェアを使用している場合、仮想サーバのバックアップを改善できる方法がいくつかある。

・	バックアップがなるべく重ならないように、フルバックアップは決して重ならないように調整する。
・	フルバックアップの頻度を減らしてみる。たとえば週1回から月1回に減らすなど。ディスクにバックアップしているなら非常に簡単なことだ。
・	最後に、使用しているバックアップアプリケーションで合成バックアップがサポートされている場合は、合成フルバックアップを行うことを検討する。増分バックアップは仮想マシン内で実行するが、フルバックアップはバックアップソフトウェア内で合成する。この機能は、CommVaultのSimpana、EMCのNetWorker、SymantecのVeritas NetBackupといった一般的なバックアップアプリケーションで利用可能だ。

ポイント製品の活用
特にVMのバックアップに対処することを想定して設計された「ポイント製品」がいくつかある。これらをバックアッププロセスに組み込んで、上記の問題の一部に対処できる。Visioncoreは、vRanger Pro製品で早期に市場に参入し、VMwareのバックアップで他のどこよりも長い実績がある。そのほかによく使用される選択肢では、PHD Virtual TechnologiesのesXpressがある。いずれの製品も、VCBの有無にかかわらず、VMDKレベルのフルバックアップと増分バックアップ、およびファイルレベルのリストアが実行できる。しかし、この2つの製品による処理と動作は大きく異なるため、自社の環境に最適な組み合わせを見つける必要がある。いずれの製品でも、ボリュームレベルのバックアップには、増分バックアップではVMDKファイルの一部しか書き込まれないとしても、やはりVMDKファイル全体の読み込みが必要であることに注意が必要だ。

ソース型重複排除
AgigraのAsigra、EMCのAvamar、SymantecのNetBackup PureDiskといった、ソース型重複排除バックアップソフトウェアも使用できる。ソース型重複排除バックアップソフトウェアを使用する第1の方法は、VM上にインストールして、そこで通常のバックアップを実行することだ。とはいえ、ソース型重複排除バックアップでは、通常のバックアップ（増分バックアップであっても）よりも必要なCPUサイクルが少なく済み、I/Oの負荷も低いため、ESXサーバへの影響を大幅に軽減することができる。また、このようにしてバックアップを実行すると、製品に付属する任意のデータベースやアプリケーションエージェントを使用することができる。デメリットは、これ以外にバックアップしていない場合、通常VMの「ベアメタル」リストアができないという点だ。

　一部の製品では、このアプローチをさらに一歩進めて、ESXサーバ自体の中でバックアップを実行し、仮想マシンのリストアに必要な追加のブロックを記録するようにしている。しかしこの手法では、バックアップアプリケーションがすべてのVMDKファイルの中のすべてのブロックを読み込んで、どれが変更されたかを検出する必要がある。この処理は、それらのハッシュをすべて計算して照会するため、CPUのI/Oに大きな影響を与える可能性がある。

CDPアプローチとNear-CDPアプローチ
継続的データ保護（Continuous data protection：CDP）とNear-CDPバックアップ製品は、重複排除ソフトウェアとよく似た形で使用されている。VM上にインストールされて、通常の物理サーバの場合と同じように仮想マシンをバックアップする。そのようなバックアップでは、CPUとI/Oへの影響は非常に小さい。大半のCDPソフトウェアでは、マシン全体のリカバリは実行できないため、VMが損傷したり削除されたりした場合は代替手段が必要だ。

Near-CDP対応のストレージ
これまで紹介した手法にはすべて、メリットより多くはないとしても、同じだけのデメリットがあった。しかし、この他に真剣な検討に値するまったく異なるソリューションがある。VMwareに対応した、Near-CDPバックアップがすでに組み込んでいるストレージシステムを使用する方法だ。（なお、Near-CDPとは、スナップショットとレプリケーションの機能に新しい名前を付けたものに過ぎない。）Dell傘下のEqualLogic、FalconStor Software、およびNetAppの製品はすべてこの機能を備えている。他のストレージベンダも同様の機能を開発中なので、使用しているストレージベンダに確認することをお勧めする。

　考え方は比較的単純だ。VMDKはストレージ上に保存され、それぞれにVMwareのバックアップを指示できるVMware用のツールが用意されている。VMwareに指示を出すと、VCBの場合と同様のスナップショットが作成され、これによりストレージボックスが独自のVMwareスナップショットを作成できる。そのバックアップを別のボックスにレプリケーションすれば、バックアップが完了する。

　ESXサーバ上のCPU負荷は最小限で済む。ストレージ上のI/O負荷も最小限で済む。スナップショットを作成して、その日の新しいブロックを別のシステムにレプリケーションすることにより高性能なブロックレベルの増分バックアップを実行するだけだからだ。（このブロックレベルの増分バックアップを行うのは、どのブロックをコピーするべきか既に知っているストレージであるため、I/Oへの影響は限りなく小さくなる。）この機能を提供するベンダは、これらのバックアップからファイルレベルのリストアを実現する独自の方法も持っている。

　Dell傘下のEqualLogicのシステムは、iSCSI接続であるため、IP経由で仮想マシンと直接通信し、スナップショットを調整することができる。FalconStorでは、すべてのVM内で動作するエージェントが、スナップショットを調整し、さまざまなアプリケーションにとって「適切な処理」を行う。NetAppでは、VMwareのツールを使用してスナップショットを作成する。しかし、本当の意味でNetApp独自といえる特長は、VMwareデータ（本稼働データであっても）の重複排除処理が可能な点だ。NetAppのData ONTAPオペレーティングシステムに含まれる重複排除ツールを使用することにより、冗長なデータブロックをすべて除外できるのだ。

VMバックアップについての結論
現在、VMwareのバックアップを改善するために導入できるテクノロジーはいくつもある。しかし、その多くにはまだ、特に従来型のバックアッププロセスに比べるといくつかのデメリットがある。現時点で最も有効な代替選択肢はおそらく、VMwareのインスタンスをVMware対応のNear-CDP機能を備えたストレージに移行することだろう。あるいは、VMwareがvSphereでこれらのバックアップ問題の一部を解決してくれるかもしれない。

略歴：W. Curtis Prestonは、TechTargetのStorage Media Group編集主幹で、独立系バックアップ専門家でもある。