ストレージのスナップショットでVMwareバックアップどう変わるのか？

VeeamではVer7からHP Storeserv、Storevirtualのストレージスナップショットと連携し、バックアップ/レプリケーションが可能になりました。そして、近日リリース予定のVer8ではNetAppのストレージにも対応予定です。
本記事ではこの機能が実際に何を解決できるのか？を焦点に、ストレージスナップショットからのバックアップ(BfSS)がどのように機能するかを紹介いたします。

まず、バックアップを考える際に必須となることはどのように静止点を作成し一貫性を保持するかということです。従来の物理環境ではアプリケーション－OS－ハードウェア(SAN)という構成でしたが、ここに仮想化層が追加されました。Veeamの場合、仮想マシン単位でのバックアップであり、この仮想化層を考慮して処理を行っており、。この仮想マシン単位の処理を実現するために使用しているものがVMwareのスナップショットです。

Ver7では以下のような方法を使用して静止点作成を行えます。

・Veeam独自のアプリケーションを認識したイメージ処理を使用
→ランタイムなコンポーネントをゲストOS上に配置しVSSによる静止点作成を行います。これによりExchangeやSQLのログ切り捨てなどを実施できます。

・VMware Toolを使用
→Windowsの場合、VSSを使用してファイルシステムレベルの静止点作成が可能です。また事前にプレ/ポストスクリプトを配置して任意の静止点作成を行うことも可能です。
※Ver8ではプレ/ポストスクリプトをVeeamのコンソールから設定、Veeam独自のアプリケーションを認識したイメージ処理と併用が可能になります。
カスタムスクリプトでの静止点作成がより簡単に。【Veeam B&R Ver8新機能予告⑪】

このような手法でVM内の一貫性を確保した後に、VeeamはVMwareのスナップショットをトリガーします。このスナップショットは「一貫性のある状態」を保持しているため、作成後にはゲストOSを静止点を解除することができます。

まずはストレージスナップショットなしの場合です。

オリジナルのVMDKに対して読み書きが行われている状態から

スナップショットを作成することで、デルタファイルに対して読み書きが行われるようになります。オリジナルのVMDKからは読み取りのみを行い、仮想ディスクのブロックが上書きされた場合には、その変更部分をデルタファイルに書き込みます。このようにオリジナルのVMDKは一貫性を保った状態から変更が行われず、安全にバックアップを実施できます。

ただし、このVMwareのスナップショットはトランザクションログではありません。同一のブロックが再度、上書きされた場合には、対象のブロックを上書きします。そのため、作成した当初は小さいですが仮想ディスクに対する変更に応じてサイズは大きくなり、最大でオリジナルと同サイズになります。

したがってVeeamのようにVMwareのCBT機能を利用しており、変更点のみのを読み取る場合にはI/Oが少ないVMであれば、高速なバックアップが可能であるためデルタファイルのサイズは小さく問題になりません。

しかし、I/Oが多いVMの場合には、このデルタファイルが問題になってきます。
まず、シンプロビジョニングなディスクのスペース割り当てがあります。デルタファイルの初期サイズは16 MBで作成され変更に基づいてサイズが大きくなっていきます。この成長の際にスペース割り当てのため、VMDKのメタデータの更新が行われます。これによりクラスタ化されたボリューム(VMFS)では毎回ロックが発生します。これは対象のVMのみに限らず、同一のボリューム上に存在する他のVMに対しても影響を与える恐れがあります。
次にSAN上にあるシンプロビジョニングなVMFSボリュームでの無駄なスペースの消費です。スナップショットを削除した際に、必要なくなったスペースは自動では再利用されないため無駄にスペースを消費することになります。
※VMwareは現在、UNMAP VAAIプリミティブサポートを行っていますが、自動的なプロセスとしては実装されていません。
http://cormachogan.com/2013/11/27/vsphere-5-5-storage-enhancements-part-4-unmap/

最後に当然のことですが、I/O多いVMは、変更ブロックも多いため、バックアップ時間も長くなるという点です。

そして、このようなスナップショットを保持している間の問題に加えて、スナップショットをコミット（削除）する際にも問題が発生します。
コミットを行う際には単純に削除するだけではなく、オリジナルに対してマージを行う必要があります。しかしスナップショットのデルタファイルは書き込みが行われているため、そのままではマージ処理を行うことができません。そのためヘルパースナップショットという補助用のスナップショットを使用します。

基本的にはVMwareはスナップショット削除時に2番目のスナップショットを作成します。全ての書き込みはこのヘルパーにリダイレクトされ、その後オリジナルのVMDKに対してマージを開始します。

この削除時の問題としては、まずマージ処理による余分なI/Oの発生があります。スナップショットのブロックを読み取り、オリジナルへの上書きを行うためデルタファイルのサイズが大きければ大きいほど長時間、ボリュームのパフォーマンスに影響を与えることになります。

そして、マージが完了した後にはヘルパースナップショットをマージする必要があります。ESXi 3.5では単に仮想マシンの全てのI/Oを停止し、ヘルパースナップショットのデルタファイルをマージしていたため、長時間、仮想マシンがフリーズすることがありました。現在では、この問題は改善されI/O停止時間がある程度短くなるまで、追加のヘルパースナップショットを作成、マージという処理を繰り返します。

実際にこの処理に関するパラメータには以下のような2つがあります。
・snapshot.maxIterations : ヘルパースナップショットの作成処理をどれだけ最大繰り返すかといったパラメータです。デフォルトでは10回となっており、これを超えた場合には仮想マシンを強制的にI/O停止し、コミットします。

・snapshot.maxConsolidateTime : ヘルパースナップショットのコミットに必要となるとVMwareが推定したI/O停止時間に関するパラメータです。デフォルトは6秒に設定されています。たとえば、3回のヘルパースナップショットの繰り返しでVMwareが6秒以内にコミットできると確信すれば、コミット処理が開始され仮想マシンのI/Oを停止します。
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2039754

このようにI/Oが集中している仮想マシンの場合には削除時にも、ヘルパースナップショットの繰り返しにより大きな影響が発生する可能性があります。また、代わりに繰り返し数を減らしたとしても仮想マシンのI/O停止時間が長時間化してしまうことが考えられます。

そのため、根本的なことを言ってしまえばI/Oの集中している仮想マシンについてはスナップショットを使用しない方がいいということになりますが、思い出していただきたい点として、仮想環境のバックアップでは仮想化層を意識する必要があり、そのためにはVMwareのスナップショットを使用する必要があります。
したがって、VMwareのスナップショットを使用しつつも、できるだけこれを保持する時間を短くし、デルタファイルを最小でコミットするという処理が必要になってきます。

これを実現した処理がBfSS（ストレージスナップショットからのバックアップ）です。

まず、VMwareのスナップショットを作成するところまでは同一です。

次にVMFSボリューム/NFS共有でマウントしているSAN/NASデバイスと連携し、ストレージのスナップショットを作成します。このSANのスナップショットにはVMのスナップショットが「含まれ」ます。
これにより、VMのスナップショットを瞬時にコミットすることができます。

その後Veeamのプロキシはストレージコントローラを介して直接データを読み込みます。確かにVeeamは未だにVMのスナップショットを作成していますが、数十秒から2，3分のデルタファイルが数時間のデルタファイルよりも小さいことは明らかです。また、SANアレイの場合、スナップショットによるパフォーマンスへの影響は、ほぼなくポインタをリダイレクトしているのみであるため、マージやコミットも発生しません。