自身によるデータ保護設計、バックアップ計画の勧め
プライベートクラウドサービスは様々な手法を用いてデータを保護するよう設計されています。しかし、物理的な機器の破損による物理的破壊と、ソフトウェアのバグ、人為的なミスなどの論理的破壊の全てを担保するには、データ保護設計が必要です。
HAなどの機能で、2箇所に完全に同期してデータを保存する場合、ハードウェアの物理的な障害には耐えることができます。しかし、ソフトウェアのバグや人為的なミスなどの論理的な破壊は、2箇所のデータが同時に破壊されてしまいます。
一方で、バックアップやスナップショット・レプリケーションは、バックアップを取る間隔(これをRPO、Recovery Point Objectiveと呼ぶ)があり、ソフトウェアのバグや人為的なミスにより、破壊に気がついた直後(RPOで定めた時間よりも早い時間)バックアップから取り出せば、データの救出が可能です。しかし、物理破損の時も必ずRPOで定めた時間の分データが巻戻るため、「時系列で考えると必ず失うデータがある」ことになります。
参考≫テクニカルノート/Snapshot Replicationとは
参考≫テクニカルノート/時空に拡張されるCAP定理：落ちず、速く、確実なサーバをどう作るのか？
それぞれのサービスには特色があり、組み合わせによって冗長性担保やデータ保護ができます。裏返せば、一つ一つのクラウドサービスは、そこに記載されている内容以上のバックアップや冗長性は存在していません。冗長性は様々な層により担保され、バックアップも、ほとんどのサービスで、別途、組み合わせることを前提にデザインされています。時系列と、データ重要度に合わせて、ちょうど良いバックアップを選ぶ必要があります。
Snapshotとは
スナップショットとは、その瞬間、つまりその「時点」のストレージのイメージを文字通り「スナップショット」を行う事で、いつでもその時点のデータを取り出すことができる仕組みです。
実装は様々ですが、スナップショットはストレージの「差分を保持」することにより実現をする技術のため、ある時点のスナップショットを取得したからといって、スナップショット時点のデータと、今現在のデータ、つまり単純計算で2倍のデータを保持しているわけではなく、あくまでその後の差分だけを保持しているため、ストレージ容量の節約になっています。
しかしこの特性は、論理的な破壊には強いものの、物理的な破壊には弱い側面があります。したがって、これを実装しているストレージ装置自体が冗長しているなどハード的な担保がされている必要があります。
Private CloudがもつSnapshot機能
HRPC(High Response Private Cloud)やVMPC(VMware Private Cloud)、SSPC(Solaris SPARC Private Cloud)は、それぞれ、スナップショットの機能を持ちますが、それぞれ特性が異なります。
バッキングストア方式のスナップショット(HRPC、VMPCのSnapshot)
HRPCとVMPCのスナップショットは、バッキングストア方式のスナップショットといって、概ね次の様な構造を持ちます。
スナップショットの取得
- 現在のストレージイメージを保持し、新規の差分ストレージイメージを作成する
- 以後、書き込みは新しいストレージイメージに書き、読み込みは差分ストレージイメージにデータがあればそれを使い、なければ1のストレージイメージを利用する。
この方式は、新規の差分ストレージイメージを作る際に「一瞬」の停止が伴います。
スナップショットの個数が増え、差分のイメージファイルができるほどリードアクセスが遅くなるため、一般にシステム的な制限があり、無闇にスナップショットが取れないようにできています。
またスナップショットから長い時間がたつと、差分ファイルが巨大になり、下記の削除処理に時間を要するようになります。
スナップショットの削除
実装により異なりますが、一例です。
- 差分イメージを現イメージに対してマージ(統合、結合)処理を行う
- ただしマージ中にハードリセットなどが起きた場合にデータ破損がないように、元のデータを「破壊せず」にマージ処理を行うため、何らかの単位(差分ファイルのファイルサイズなど)でデータを2倍使う実装の場合があります。そのため、ストレージの空き容量には十分な注意が必要になります。
- マージ処理が完了したら、バッキングストアを開放(＝削除)する。
VMPCの場合、統合処理が完了しない限り、次の処理には進めないような実装のため、スナップショットの削除＝マージ処理には、それなりの時間が必要になります。
HRPCの場合、統合処理を受け付け、裏で処理をが開始されるため、一見スナップショットの削除が高速に見えますが、実際にはバックグラウンドで統合処理が進みます。
一見、HRPCの方が良いように見えますが、この特性の違いはスナップショットレプリケーションなど連続処理をする場合、レプリケーションシステムが、本当のスナップショット終了時刻がわからないため、相応しいRPO時間を見つけることが難しい問題も孕みます。
参考≫マニュアル/High Response Private Cloud/仮想マシンを管理する/スナップショットを削除する
Copy on Write方式のFile Systemがもつスナップショット
当社サービスでは、下記のサービスで利用されています。
参考≫ 「サポート情報/マニュアル/Storage/ZFSの特徴
スナップショットの取得
CoW(Copy on Write)形式のFS(File System)が持つSnapshotの場合、内部的にはレコードサイズ単位で新旧のツリー構造を持ち、どちらのツリーを手繰るかで現在の状態のデータなのか、スナップショットのデータなのかを判定しています。この構造のため、スナップショット作成にかかるコストはほぼなく、上位層のアプリケーションが検知できるレベルの瞬間停止はほぼありません。
スナップショットの削除
スナップショットの削除の場合、ツリー構造で不要になったデータの消し込み作業が行われるため、マージのためにストレージ容量が一次的に必要になる事はありません。しかしながら、ツリー構造で不要になったデータのスキャンが走るため、空き容量の回収はゆっくりと行われていきます。
容量の計算
ファイルシステムがサポートするスナップショットは強力で、便利な機能でですが、かわりに容量は多めに取る必要があります。
参考≫ 「サポート情報/マニュアル/Storage/ZFSの特徴
たとえば、次のような状態を考えてみましょう。
- 4月1日 スナップショット作成
- 4月2日 スナップショット作成 ファイルEを追加した。
- 4月3日 スナップショット作成 ファイルAを削除した。
- 4月4日 現在 ファイルBを書き替えている。
このとき、ストレージは次のように使われています。時系列は説明の都合上、下から上に連なってると見てください。
ここで、利用容量referencedはそれぞれ利用容量となりますが、縦に積まれたものは「すべて同じディスクエリアを参照」しています。したがって、現在の合計の利用容量(referenced)が、全体の容量130GBとなりますが、これは(論理的に下位の)スナップショットを含めた容量です。
4月4日現在のusedは、現在、ファイルBが20GB書き替えてしまったためで、CoWの性質上、別の場所に20GB作られています。つまり、現時点にしか存在しないデータはB'=20GBになるため、利用容量(used)は、20GBです。
スナップショットのusedはどうなるのでしょうか？使っている容量はreferencedにでますが、共通している領域も含まれます。usedは、その時点にしか含まれていないデータとなるため、この状態ではどのスナップショットも0GBとなっています。
ここで、4月2日Snapshotを消してみましょう。usedが0なので、これの行為により解放される領域はありません。
しかし、4月1日Snapshotのusedの容量をみると、消す前がused=0GBだったのに対し、used=30GBとなっています。4月2日Snapshotを消したことにより、4月1日Snapshotにしか存在しないデータとしてファイルA=30GBがある為です。
実際のシステムではこのように単純ではなく、レコードサイズの単位で書き換えが行われています。したがって、Copy on Writeのファイルシステムで、スナップショットが撮られている場合、容量計算は非常に難しく、予測が極めて難しい部分となります。
データ領域の解放は、最後のスナップショットにデータがある場合、スナップショットの削除時に発生します。実際のデータ解放は、IO速度の状況に合わせて遅延して行われる為、容量の解放は、少しづつ行われていきます。
このように、スナップショットの作成と削除を容易にした分、容量に十分の余裕をもつ必要があります。
