nkjmkzk.net

powered by Kazuki Nakajima

Archive for the ‘snapshot’ tag

Deduplication, 圧縮, スナップショットはどう違うのか?

前のエントリで予告したDeduplication, 圧縮, スナップショットの違いについて簡潔にまとめておきます。

Deduplicationと圧縮

例えば10Gbyteの仮想マシンイメージをgzipのようなアルゴリズムで圧縮した場合、10Gbyteのイメージにどれだけ空きスペースが含まれているかによりますが、もし空きスペースがほとんどなければあまり大きな圧縮効果は望めないでしょう。逆にもし10Gbyte中の4Gbyteが空きスペースであったなら、その部分はほとんど圧縮されるので最悪でも6Gbyte程度までは圧縮できるでしょう。ただしこの仮想マシンを10個クローンしたらどうでしょうか。ストレージは6Gbyte x 10 = 60Gbyteの容量を消費してしまいます。実際は同じデータであるにも関わらず、です。このストレージでDeduplication(重複排除)が有効であればどうでしょうか。10Gbyteの仮想マシンイメージを10個作成しても消費する容量は10Gbyteです。先ほどのgzip圧縮と比較するとトータルでこ重複排除の方が容量を節約できています。

ただしここで注意したいのはケースバイケースだということです。前述の仮想マシンイメージのような例は、特にDeduplicationが効果を発揮する環境です。Jeff Bonwick氏も自身のBlogエントリで度々仮想マシンイメージの例を引き合いに出しています。

そしてDeduplicationと圧縮は排他的な関係ではありません。補完し得る関係です。前述のシチューエーションをそれぞれのパターンでまとめてみます。

命題:10Gbyte (空き容量4Gbyte)の仮想マシンイメージを10個クローンする

gzip圧縮のみ

10Gbyteを圧縮して6Gbyteに。6Gbyteを10個クローンして最終的に60Gbyte消費

Deduplicationのみ

10Gbyteを10個クローンするが、10個のクローンはすべてのブロックが一致するはずなので新しいデータ領域は確保されない。最終的に10Gbyte消費

gzip圧縮 + Deduplication

まず10Gbyteを圧縮して6Gbyteに。それを10個クローンするがすべてのブロックが一致するはずなので新しいデータ領域は確保されない。最終的に6Gbyte消費

実際にテストしていませんが、理論的には上記のようになり得ます。要件によっては圧縮とDeduplicationを組み合わせたら最もディスク領域を節約できるケースがあることがわかります。

Deduplicationとスナップショット

Deduplicationとスナップショットは非常に近しい技術だと思います。どちらのコンセプトも「重複するデータの実体は一つしか保持しない」がベースになっています。僕は大きな違いは次の2点だと思っています。

主従関係

スナップショットでは主従関係が存在します。ほとんどのスナップショットの実装ではマスターのイメージがあり、スナップショットとはそのイメージのスレーブとして作成されます。なのでマスターとスレーブは対等な関係ではありません。スレーブは維持するけれどもマスターを削除する、という操作は行うことができません。ZFSのスナップショットでも同様です。

*ZFSでマスターを削除するにはマスターとスレーブの主従関係を逆転させるという選択肢はあります

これはDeduplicationの仕様とは明らかにことなります。前述の仮想マシンイメージの例で言えば、Deduplicationを使って10個の仮想マシンをクローンしてもそのオリジナルとクローンとの間には主従関係はありません。あるのはディスクに格納されているブロックの実体と、それを参照しているカウンタです。どの仮想マシンを削除するのも自由です。例えば大本の仮想マシンイメージを削除するにしてもそのブロックへの参照カウンタが一つ減るだけでスナップショットのように依存関係には縛られません。

コピー速度

ほとんどの実装においてスナップショットの作成は一瞬です。オリジナルイメージのスキャンが行われることもなければ新たなブロックが確保されてデータがコピーされることもありません。これはそもそもストレージ(あるいはボリュームマネージャ)にコピーではなくスナップショットという命令が明示されているからロジックを分けることができます。これはDeduplicationとは異なります。Decuplicationではコピー(あるいはクローン)する際、ユーザからの特別な命令はありません。通常通りファイルのコピーが命ぜられ、ストレージ側は粛々とファイルの構成要素となっているブロックについて一つ一つハッシュをチェックし、重複判定を行って重複していればデータのコピーは行わず参照カウンタをインクリメントして次のブロックに処理を移します。なのでスナップショットのようにどれだけコピー元のサイズが大きくても一瞬で処理を完了させれるような仕組みではなく、サイズが大きければ大きい程、例えば最終的にデータは複製しないにしろ、コピー処理には時間がかかるのが道理です。

ということでそれぞれの技術には得意不得意があり、ケースバイケースで適切な技術を選ぶ必要があると考えられます。

僕が開発しているovmzfsというツールの現在の仕様は、ZFSのスナップショット/クローンを使用して仮想マシンを高速に作成し、圧縮を使用してテンプレートのサイズ削減を行っています。これは検証環境では作業の高速化とストレージリソースの削減に大きく寄与しますが、今回Deduplicationが出てきたことで実装を少し見直さなければと思っています。現在の仕様では仮想マシンはテンプレートをスナップショット/クローンすることで作成しているため、高速に作成できるものの元のテンプレートと依存関係が発生します。すぐに問題とはなりませんが、より複雑な運用、大規模な環境ではもしかすると問題がでてくる可能性もなきにしもあらずです。まだDeduplicationを含むベストプラクティスを確立するには至っていませんが、最終的には適材適所でZFSのDeduplication、圧縮、スナップショットを採用してユーザからは透過的にストレージを最適に利用するツールにできればと思っています。

with one comment

Written by 中嶋 一樹

11月 8th, 2009 at 2:33 pm

Posted in Uncategorized

Tagged with , , , ,