スナップショット・レプリケーション
目的
スナップショット・レプリケーションはスナップショット機能を利用し、差分を転送することで、2つのデータストアを遅延同期する仕組みです。
HRPC Xenタイプや、Enterprise Storage/Backup Storageなどで、2つのシステム間でデータ同期する為に使われています。
物理破壊からの保全だけでなく、遅延するが故に論理的なオペレーションミスなどからの救出にも役に立ちます。
また、この2つのシステムを地理的に離した拠点にした場合、ディザスタリカバリサイトにも使う事ができる技術です。
まずはストレージのスナップショットの仕組みを知るため、下記の参考ドキュメントを参照してください。
参考≫ テクニカルノート/スナップショットとは？(StorageやPrivate CloudのSnapshot)
スナップショットレプリケーションは、データのスナップショット差分を、プライマリ(ソース)からセカンダリ(ディスティネーション)にコピーしていくことで、2つのストレージ間でデータの「遅延型同期」を実現する手法です。
この技術をプライベート基盤に組み込むことにより、仮想マシンのレプリカ(レプリケーションによってできるコピーイメージのこと)を定期的にとることができます。
本ページでは「バッキングストア型」のスナップショットを持った、ストレージレプリケーションを中心に記載します。
■スナップショットレプリケーション図
1.初期同期（Initial synchronization）
まずスナップショットを取得します。このスナップショットは、ハイパバイザ層やストレージ層の機能により行います。ハイパバイザ層で行う場合は、内部でFreeze処理(ライトバックキャッシュをディスクの書き込む処理)が実行されます。ストレージ層で行う場合は、ストレージ側で自律してスナップショットを行います(※コラム)。
バッキングストア型でもCopy On Write型でも、スナップショットを取得したことにより、それは静止点となるため、リードオンリーで読むことができ、リードロックなどが外れます。
初期同期では、リードオンリーになった大きなイメージを、転送先(Target)となるストレージにコピーします。
従って、このとき大きなネットワーク転送が発生するため、二つのストレージ間の帯域(と実際のストレージ速度)に応じて、とても長い時間がかかります。
2.スナップショットの作成〜差分転送(Snapshot Incremental transfer)
初期同期が完了した後、RPOに応じた定期的な間隔でスナップショットを作成します。
スナップショットを取得することにより、差分が保存されたバッキングストア領域がさらに作られ、今までの部分は静止点となってリードオンリーで読むことができます。
この差分のみがターゲットに転送されることで、全転送を避け、データ同期を少ない量で効率的に行う事ができます。
Copy on Writeの場合は、前回のスナップショット点と今回のスナップショット点が共に静止点のため、ディスクイメージの差分を取得することが内的に可能になります。それを転送します。
3. スナップショットの摘要（Target Data Merge）
スナップショットの転送が完了すると、プライマリストレージでもセカンダリストレージでも、その前(正確には世代のリテンション数より前)のスナップショットが不要になる為、削除します。バッキングストア型のスナップショットの場合、マージ(合成処理)が行われる為、この処理はプライマリにもセカンダリにも、大きなストレージIOを発生させ、しかも長い時間がかかります。
なお、バッキングストア型のスナップショットは、実際にマージする際にバッキングストアのサイズの2倍程度の容量は必要になります。
CoW型のファイルシステムの持つスナップショットの場合は、ブロックポインターの世代の消し込みが必要になるだけなので、新たな容量を利用しません。マージ処理も発生しませんが、ブロックポインタの世代の消し込みが発生するため、大きなストレージのIOを発生させます。
4.継続的なレプリケーション（Ongoing replication）
2〜3のスナップショットの作成と転送のプロセスは、RPO毎に定期的に繰り返されます。このようにして、ストレージの変更がターゲットに反映され、データの同期が継続的に行われます。
コラム
スナップショットはハイパバイザ層で行うべきか？
ストレージ層で行うべきなのか？
スナップショット・レプリケーションははハイパバイザ層で行うべきか？ストレージ層で行うべきなのか？これはどちらにも、一長一短があります。
ハイパバイザで行われる場合、一般には収容する仮想マシンの中でFreeze処理が走るため、その瞬間RAMにあるキャッシュの書き出し処理が走ります。このため、スナップショットの時にシステムのもたつきが発生してします。
これは静止点を仮想サーバまで含めた意味で、なるべく整合性を担保させたいという設計思想に基づきます。しかし仮に、仮想マシンスタック、仮想マシン-ハイパバイザ間のメッセージング処理、ハイパバイザのストレージ仮想化ソフトウェアなどのうち、どこかにバグがあった場合(たとえばハイパバイザの管理OSや、TypeIIの場合、親OSのメモリリソースが枯渇している時など)、システムは意図しない動作をする事があり、正常に機能しないことになりますし、フリーズのフックポイントでロックファイルを除去するプログラムを書くことができる製品もあるため、システムが複雑になり、どこかでタイムアウトするまでストールする可能性さえあります。
逆に、ストレージシステム側で自律型で行うものは、「仮想OSのファイルシステムは如何なる時点でリセットされてもジャーナルやロギングなどの機能で復元可能であるべきだ」という前提から、むしろここで余計なことをせず、その瞬間のディスクイメージを確実に保護すべきだという設計思想となっています。
どちらのシステムも一長一短ありますが、Enterprise Storageの自律型スナップショットレプリケーションは下の考え方をしており、HRPCのXenタイプやVMPCの場合は、上の考えで実装されています。
なお、ハイパバイザ層と記載していますが、厳密に言えば、狭義ではハイパバイザではなくストレージの仮想化層が行っています。VMware Private Cloudではストレージ仮想化層はハイパバイザ製品に統合されていますが、Solaris SPARC Private Cloudではストレージ仮想化層はZFSを用いた別の枠組みを利用し、HRPC XenはXenハイパバイザではなく、tapdiskというストレージ仮想化層、HRPC KVMでは選んだストレージトポロジにより行う層が異なっています。
