重複排除バックアップストレージの意外な盲点
少々専門的な内容です。
エンタープライズ系のバックアップでは、ターゲット型の重複排除ストレージが多く採用されていて、市場での実質的なスタンダードとなっています。それらの製品群では、CPUの高速化や搭載メモリの大容量化そして処理の進化などが進み、重複排除を「インライン」で処理することが常識化してしまっています。そこに疑問を投げかける人はまずいないようです。
『バックアップで大容量のデータ容量が大幅に縮小されバックアップ速度もまずまず高速だから、何が問題なのか?』という質問は当然です。
故障に関することではありません。一言でいうと、『リストアスピードが遅い』のです。
インライン重複排除ストレージの本質的な仕組みのため、現在の装置ではリストアの速度はバックアップ時の速度の「数分の1」になります。多分、この実態を知らないで導入していることは多いと思います。バックアップはリストアとセットで考えるべきなのですが、リストア時の事態が想定されていないことが多そうです。装置メーカー側もこのことを話題にはしませんし。
バックアップ時間を8時間で済むように装置を選定した場合、例えばリストア速度がバックアップ速度の「5分の1」に遅くなると、データのリストアには40時間(約1.7日)かかることになってしまいます。これでは、あまりよいバックアップ装置とは言えません。
(なぜ、リストア速度がバックアップ速度よりもかなり遅くなるかの原因は、このトピックの最後に説明しますが、ちょっと面倒な内容なので飛ばしても構いません。)
リストア速度はバックアップ速度よりもかなり遅くなることを考えずにバックアップの設計を進めてはいけないことを意識すべきです。
ターゲット型重複排除ストレージを調べてみると、その中にもリストアがバックアップ速度と変わらない(遅くならない)製品もありました。しかし日本ではその道の専門家にもあまり知られていません。
例えば、ExaGridという製品ですが、これはインラインとは異なる「Adaptive」型というアーキテクチャを採用してます。その結果、インライン同等のバックアップ速度を実現しながら、リストアもバックアップと同じ速度を実現しているようです。「ポストプロセス」という古いアーキテクチャとは異なっているユニークな製品ですね。内容を調べてみたら、意外と面白い製品でした。リストアも高速というのが、役に立つバックアップといえると思います。
(以下の説明は、あまり正確性を追求しておりませんがご参考まで)
インライン処理では、データをストレージに格納する前に重複排除を行う。バックアップサーバーから送られてきた大量のデータを受ける側(ターゲット型重複排除装置)が自身の内部のストレージ(主にHDD)に保存する前に重複排除処理を行う。そうすると、バックアップ装置に保存されるデータのすべては重複排除された形式(元のデータとは全く異なるそれぞれがユニークな小片の集まり)となる。これをそのまま元の装置(主にプライマリーストレージ)に戻しても使えない。本来の元のデータに戻すため(リストア)には、『rehydrate』、直訳では再水和、という大量の小片群から必要なものを引っ張り出して元のデータ形式に戻すコンピューティング集中型の処理が必要になる。これがリストアで時間が長くかかる原因となる。
データの重複排除というのは、部品と設計図に展開する作業に例えるとイメージしやすいかと思う。バックアップ時には、元のデータ(製品に相当)を重複しないユニークな部品に分解して、その部品がどの場所に使われているかを設計図とする。リストア時には、この設計図をもとにしてばらばらの部品群から必要な部品を見つけ出してもとの製品を組み立てる作業に似ている。これがとてもとても時間がかかる処理になる。
すべての記事をまとめた★カテゴリーごとの全記事一覧★がありますのでご覧ください。
≪ VMに適切な重複排除バックアップストレージの条件 | HOME | 世界データ生成量 ≫