・概要

　バックアップサーバがVMwareデータストアを直接マウントしてVMDKファイルをバックアップする。この方法が可能なのはNFSデータストアのみ。SANストレージのデータストアの場合はVMFS（Virtual Machine File System）となるため、バックアップサーバから直接マウントすることはできない。

・特徴

　VMDKファイル単位のバックアップ／リストアが可能。ただし、バックアップデータの整合性が取りにくい。また、ゲストOSの実際の使用量に関わらず、VMDKファイル全体を常にフルバックアップすることになる。少しの変更でも、常にフルバックアップとなるため容量効率が悪い。例えばゲストOSが50Gバイトを使用している場合でも、VMDKファイルが100Gバイトあれば毎回100Gバイトをバックアップすることになる。小規模であれば問題にならないケースもあるが、大規模になっていくとバックアップ／リストア時間、容量とも増大する。なお、ヴイエムウェアはこの方法を推奨していない。

3．ストレージのコピー機能　（システムバックアップ用途）

・概要

　ストレージのコピー機能（スナップショット、クローン、レプリケーションなど）を使用して、LUまたはボリュームの複製を筐体内や筐体間で行うバックアップ方法。

・特徴

　ストレージの機能を使うバックアップ方式。変更ブロックのみがコピー対象になるので、高速なバックアップが可能である。ただし、一般的にバックアップ／リストアは、ストレージのLUまたはボリューム単位となる。よって、仮想マシン単位でのバックアップ／リストアを行うためには、1つのLUまたはボリュームに対して1つの仮想マシンを配置した設計が必要になり、ストレージの容量効率が悪くなる。

　RDM（Raw Device Mapping）の領域は、コピー先の領域をバックアップサーバが直接マウントしてバックアップすることも可能である。SANストレージのデータストアの場合、VMFSのため、テープ装置へのD2D2Tバックアップは困難になる。一般的には整合性が取りづらく、スケジュール、世代管理が困難である。ただし、ストレージベンダーがそれらを自動化する専用ソフトウェアを提供している場合がある。ソフトウェアによっては、1つのボリュームに複数の仮想マシンが含まれる場合でも、個々の仮想マシン単位でリストアを行ったり、ゲストOS内のファイルレベルのリストアが可能なものもある。専用ソフトウェアを使用せず、管理者による手動実行やスクリプトによるバッチ処理を作成するのは、複雑になるので推奨しない。

VMware環境のバックアップデータの整合性

　ここで、バックアップデータの整合性について考えてみよう。仮想環境は物理環境とは異なり、データの整合性という観点で複数のレイヤーを考慮する必要がある。

図2　VMware環境のバックアップレイヤー

　上位のレイヤーから、

1. データベースなどのデータ
2. ゲストOSのファイルシステム
3. VMDKファイル
4. VMFS／NASのファイルシステム

となる。VMDKファイルのバックアップやストレージのコピー機能によるバックアップでは、これらのレイヤーの整合性を考慮する必要がある。

　まず、1．データベースなどの整合性を取るためには、物理環境と同様にバックアップモードの実行やアプリケーションの停止が必要になる。その後、2．ゲストOSのファイルシステムをフラッシュする必要がある。データ領域であれば、アンマウントすることも可能だが、OSのシステム領域はアンマウントすることができない。そして、3．VMDKファイルへの書き込みを停止するために、仮想マシンのスナップショットを実行する必要がある。その際、ゲストOSがWindowsの場合は、VMware ToolsのSYNCドライバまたはVSS連携機能でゲストOSのファイルシステムが静止されるので、“ある程度”の整合性は取れていると考えてよい。残念ながらLinuxのVMware Toolsにはその機能はない。なお、4．VMFS／NASのファイルシステムは、VMware ESXサーバからアンマウントすることは事実上難しいので、ほとんどのケースで考慮しない。以上から、下記の流れでバックアップする必要がある。ここまで考えないと、整合性の取れたバックアップとはいえない。

　仮想マシンをオンラインでバックアップ取得するためには、上記の整合性について考慮する必要がある。実は、オンラインでの仮想マシンバックアップは、ヴイエムウェアもOSベンダーも完全には保証していない。オンラインでのシステムバックアップは「突然のシステム電源ダウン」と同じである。オンラインバックアップした仮想マシンをリストアして起動すると、Windowsの場合は停止理由について求められる画面が表示され、Linuxの場合はFSCKが実行される。そのため、100％の整合性を担保したい場合は、仮想マシンを停止してバックアップする必要がある。しかし、毎回停止するというのは運用の要件を満たせない場合が多いので、通常の運用ではオンラインでバックアップし、システムに変更があったときなど、不定期で仮想マシンを停止してバックアップするという運用を推奨する。

VMware環境のバックアップの課題のまとめ

　VMware環境のバックアップで、ゲストOS内のファイル単位のリストアと、仮想マシン単位のシステムリストアの両方を行いたい場合は、従来のバックアップ方法を2パターン実施し取得する必要がある。だが、そうすると、ゲストOS内のファイルとVMDKファイル内の同じデータを、形を変えて2重取りしていることになる。VMDKバックアップが毎回フルバックアップになることも合わせ、バックアップ時間と容量が肥大化する。大規模になれば、ゲストOSからネットワークバックアップをすることによるVMware ESXサーバとLANの負荷も増大する。よって、時間、容量、負荷が課題になる。これら3つの課題をどう解決するかが重要だ。

　これら3つの課題が大きいので、災害対策や運用の効率化など、潜在的な課題に対処する余裕がないというのが現状ではないだろうか。

　第1回ではVMware環境のバックアップにおける課題について説明した。第2回、第3回では、こうした課題を解決する上で効率の良い最新のバックアップ技術を紹介する他、最適なバックアップ製品を選定するポイントを説明する。第4回では、バックアップ製品の機能比較、最終回の第5回ではコスト比較を行う。最終回までお付き合いいただきたい。

木島 亮（きじま りょう）

伊藤忠テクノソリューションズ　クロスファンクショングループ

ITエンジニアリング室　プラットフォーム技術部　ストレージ基盤技術課

2002年、伊藤忠テクノソリューションズ（CTC）入社。
HAクラスタやLinuxの担当を経て、現在、ストレージ／バックアップを担当する。
2008年から、仮想環境上のデータ保護や可用性ついて、技術検証やセミナーを実施し、社内外への啓蒙を行っている。
趣味はウォーキング。12カ月で22キロやせました。