StorageやPrivate CloudのSnapshotと、バックアップ

Top / テクニカルノート / StorageやPrivate CloudのSnapshotと、バックアップ

#contents(): { "base" : 指定されたデザイン名のファイルが存在しません。 }

ユーザ自身によるデータ保護構造の設計、バックアップなどの勧め

プライベートクラウドサービスは様々な手法を用いてデータを保護するよう設計されることがありますが、物理的な機器の破損による物理的破壊と、ソフトウェアのバグ、人為的なミスなどの論理的破壊の両方を担保する事はできません。

たとえば、2箇所に完全に同期してデータを保存する場合、ハードウェアの物理的な障害には耐えられますが、ソフトウェアのバグや人為的なミスなどの論理的な破壊は、2箇所のデータが同時に破損されてしまいます。一方で、バックアップやスナップショットレプリケーションは、バックアップを取る間隔(これをRPO、Recovery Point Objectiveと言います)があり、ソフトウェアのバグや人為的なミスによる破壊に気がついた直後(RPOで定めた時間よりも早い時間)にバックアップから取り出せばデータの救出は可能ですが、物理破損の時も必ずRPOで定めた時間の分データが巻戻る、すなわち「時系列で考えると必ず失うデータがある」ことになります。

参考≫テクニカルノート/Snapshot Replicationとは

参考≫テクニカルノート/時空に拡張されるCAP定理：落ちず、速く、確実なサーバをどう作るのか？

それぞれのサービスには特色があり、組み合わせによって様々な要件を満たす冗長性担保やバックアップなどのデータ保護ができます。裏返せば、一つ一つのクラウドサービスは、一般に、そこに記載されている内容以上のバックアップや冗長性は存在していません。冗長性は様々な層により担保されていたり、いなかったりもしますし、バックアップもほとんどのサービスでは組み合わせをしない限りは、取得されていません。

ユーザ自身の手できちんとしたデータ保護の構造を設計をするべきです。

Snapshotとは

スナップショットとは、その瞬間、つまりその「時点」のストレージのイメージを文字通り「スナップショット」を行う事で、いつでもその時点のデータを取り出すことができる仕組みです。

実装は様々ですが、スナップショットはストレージの「差分を保持」することにより実現をする技術のため、ある時点のスナップショットを取ったからといって、スナップショット時点のデータと、今現在のデータ、つまり単純計算で2倍のデータを保持しているわけではなく、あくまでその後の差分だけを保持しているため、ストレージ容量の節約に放っています。

snapshot.png 

しかしこの特性は、論理的な破壊には強いものの、物理的な破壊には弱い側面があります。したがって、これを実装しているストレージ装置自体が冗長しているなどハード的な担保がされている必要があります。

Private CloudがもつSnapshot機能

HRPC(High Response Private Cloud)やVMPC(VMware Private Cloud)、SSPC(Solaris SPARC Private Cloud)は、それぞれ、スナップショットの機能を持ちますが、それぞれ特性が異なります。

バッキングストア方式のスナップショット(HRPC、VMPCのSnapshot)

HRPCとVMPCのスナップショットは、バッキングストア方式のスナップショットといって、概ね次の様な構造を持ちます。

スナップショットの取得

  1. 現在のストレージイメージを保持し、新規の差分ストレージイメージを作成する
  2. 以後、書き込みは新しいストレージイメージに書き、読み込みは差分ストレージイメージにデータがあればそれを使い、なければ1のストレージイメージを利用する。

この方式は、新規の差分ストレージイメージを作る際に「一瞬」の停止が伴います。

スナップショットの個数が増え、差分のイメージファイルができるほどリードアクセスが遅くなるため、一般にシステム的な制限があり、無闇にスナップショットが取れないようにできています。

またスナップショットから長い時間がたつと、差分ファイルが巨大になり、下記の削除処理に時間を要するようになります。

スナップショットの削除

実装により異なりますが、一例です。

  1. 差分イメージを現イメージに対してマージ(統合、結合)処理を行う
    • ただしマージ中にハードリセットなどが起きた場合にデータ破損がないように、元のデータを「破壊せず」にマージ処理を行うため、何らかの単位(差分ファイルのファイルサイズなど)でデータを2倍使う実装の場合があります。そのため、ストレージの空き容量には十分な注意が必要になります。
  2. マージ処理が完了したら、バッキングストアを開放(＝削除)する。

VMPCの場合、統合処理が完了しない限り、次の処理には進めないような実装のため、スナップショットの削除＝マージ処理には、それなりの時間が必要になります。

HRPCの場合、統合処理を受け付け、裏で処理をが開始されるため、一見スナップショットの削除が高速に見えますが、実際にはバックグラウンドで統合処理が進みます。

一見、HRPCの方が良いように見えますが、この特性の違いはスナップショットレプリケーションなど連続処理をする場合、レプリケーションシステムが、本当のスナップショット終了時刻がわからないため、相応しいRPO時間を見つけることが難しい問題も孕みます。

参考≫マニュアル/High Response Private Cloud/仮想マシンを管理する/スナップショットを削除する

Copy on Write方式のFSがもつsnapshot(SSPCやEnterprise Storage、Backup Storage、infini-cloud.net)

CoW形式のFSが持つSnapshotの場合、レコードサイズ単位で内部的に新旧のツリー構造を持ち、どちらのツリーを手繰るかで現在の状態のデータなのか、スナップショットのデータなのかを判定しています。

この構造のため、スナップショット作成にかかるコストはほぼなく、上位層のアプリケーションが検知できるレベルの瞬間停止はほぼありません。

スナップショットの削除の場合も、マージ処理は行われず、ツリー構造で不要になったデータの消し込み作業が行われるため、ストレージ容量が一次的に多量に必要になるなどという問題はありません。

ただし、ツリー構造で不要になったデータのスキャンが走るため、空き容量の回収はゆっくりと行われていきます。

参考≫ 「デザインパターン/Solaris SPARC Private Cloud(SSPC)コンパチビリティガイド」におけるZFSに変更する場合、リソースはどの程度の余裕が必要ですか？

Private CloudPrivate Cloud
StorageStorage
NetworkNetwork