HOME > ストレージ管理ソリューション部会 > Storage Magazine翻訳記事

スナップショットで即データ保護

George Crump
Storage Magazine 2015年11月号より

スナップショットとレプリケーションは、人気の高いデータ保護ツールだが、自社の環境に合わせて正しくツールを選ぶことが成功への鍵だ。

新しいバックアップ

ITプロフェッショナルは、自社仮想環境のデータ保護方式として、ますますスナップショットに頼るようになってきた。スナップショットは、数秒で静止したデータのセカンダリ・インスタンスを作ってくれる。このインスタンスはバックアップやレプリケーション、さらには別の仮想マシン（VM）を起動する際のベースとしても利用できる。

そうは言っても、データ保護の手段としてスナップショットに頼るとき、そこには２つの課題が存在する。第一に、スナップショットはインスタンスであって、フルコピーではないということ。第二に、スナップショットは、VM、ハイパーバイザ、バックアップ・ソフトウェア、ストレージアレイのいずれにも実装できてしまうということ。そのため、どこでスナップショットの起動をかけ、どこで管理するかを決めるのに戸惑うユーザーもいるだろう。この記事を読めば、スナップショットにおける継承性の弱点の克服方法と、あなたのデータセンターに最適なスナップショットを選ぶ方法がわかるだろう。

そもそもスナップショットって何だ？

スナップショットは、オリジナルのデータセットからある瞬間のインスタンスを生成する際の、ストレージデバイス上のデータ構成方法を利用している。ほとんどのファイルシステムやストレージシステムは、データを構成する方法として2層構成を採用している。第1層はメタデータである。メタデータ層とは、ディスク上の実際の場所を指し示す小さなカタログ（目録）のことだ。このディスク上の実際の場所が第2層となる。

スナップショットは、第2層の物理データを全部コピーする代わりに、第1層のメタデータだけをコピーする。コピーはほとんど瞬時に行われ、使われるストレージ容量もごくわずかだ。スナップショットに使われた部分のブロックはリードオンリーになる。次に、スナップショット・マネージャーがメタデータのコピーを２つ保持することになる。ひとつは、本番のアプリケーションが引き続き更新していく稼動(アクティブ)コピー、もうひとつは、バックアップ、レプリケーションなど、その他のアプリケーションによって使われる静的コピーである。スナップショットの数が増えるのにつれて、メタデータ・コピーの数も増える。

スナップショット技術の重要な差別化ポイントは、本番アプリケーションやユーザーによるデータのブロックの変更をどのように扱うか、というところだ。スナップショットは一般に、自身の整合性を保ちながら変更を管理する方法として、二つの方法のうちどちらかを使っている。ひとつめの方式では、古いデータを新しい別の場所へとコピーして、当該スナップショットのメタデータは、古いブロックへのアクセスが可能になるように更新される。ふたつめの方式では、変更されたブロックを新しい場所に書き、稼動メタデータ・コピーも更新される。もちろん、各製品はそれぞれに特徴を持っているが、一般化して言うと、この二つの方式のいずれかに分類される。

どちらの場合でも、スナップショット・データセットにとって、オリジナルのデータセットがアクセス可能であることが絶対的な条件であり、スナップショットの数が増え、これらのスナップショットを保持する時間が経過するにしたがって、ストレージ容量の消費も増えて行く。

スナップショットとレプリケーションを組み合わせると

スナップショットはオリジナルのデータセットに依存しているために、そのデータセットがストレージ基盤やサイト障害により失われた場合、スナップショットも同時に失われる。このような脆弱性を抱えていては、データ破損や不慮のファイル削除に対する復旧用途にスナップショットを使うのは限界がある。

とはいえ、スナップショットはブロックレベルで変更を追跡しているので、この技術を使えばデータを効率よく複製することができる。スナップショット・ベースのレプリケーションは、オリジナルのスナップショットから変更されたブロックだけをコピーする。1回目のデータ・レプリケーションさえ済めば、この技術を使った小さいブロックの転送は、WANで接続された別地点のデータセンターを更新するのにはうってつけだ。またこのシナリオでは、スナップショットはセカンダリ・システムに常駐するので、プライマリ・システムのデータに依存せずにすむ。

スナップショットがこの依存関係から解き放たれ、データ保護の様々な用途で使われるためには、レプリケーションと組み合わせることは必須である。スナップショットの脆弱性をカバーするもうひとつの方法は、オフサイトのシステムのほかにプライマリ・データセンターのセカンダリ・システムにスナップショットをコピーすることだ。そうすることで、もしプライマリ・ストレージシステムが障害を起こしても、オンサイトのセカンダリ・システムが全ての保護データを使って高速復旧できる。災害からの復旧には、オフサイトに退避した全ての保護データを使えばよい。選択したスナップショット・マネージャーの種類によっては、セカンダリ・システムのほうが安価になり、コスト削減につながる可能性もある。

スナップショット・マネージャーとは

スナップショット・マネージャーとは、スナップショットを起動しメタデータの複数のコピーを管理するソフトウェアである。稼動データセットの変更にあわせて、これらのコピーの更新を行っている。スナップショット・マネージャーは、何かのシステムの一部になっていることが多い。その何かとは、アプリケーション、ファイルシステム、ハイパーバイザ、ソフトウェア定義のストレージ・プラットフォーム、物理ストレージアレイ、などだ。これらの個々の実装にはそれぞれ固有の利点があり、多くのデータセンターが、自社のデータ保護と復旧の目標に合わせて製品を選択し、結果的にはいくつかの製品を混在して使う傾向にある。

アプリケーション・スナップショット

いくつかのアプリケーションは、自身が作成したデータ用にスナップショットおよびレプリケーションジョブを生成・管理する機能を持っている。また、サードパーティのスナップショットやレプリケーション・ユーティリティーは、多くの場合特定のアプリケーション向けに作られている。範囲は限られるものの、これらの製品はアプリケーションを認識するという利点を持っている。これらは複数の特定プロセスを監視する機能を持っているので、アプリケーションを静止状態に移行させた後も、データベースが引き続き稼動していることを確認できる。これらのプロセスのひとつが応答しなくなったときは、スナップショットによって自動復旧が起動できる。アプリケーション認識機能を持っているスナップショット方式のもうひとつの利点は、これらの製品がほとんど全てのセカンダリ・ストレージデバイスにデータを複製できることだ。これによって、全体のストレージコストが下がることもある。これらの製品の欠点は、サポートする製品が限定されている点で、そのためデータセンターによっては、アプリケーションごとに別々なスナップショット処理が必要になる場合もあるだろう。

ファイルシステム・スナップショット

最近、スナップショット機能を組み込んだファイルシステムが増えてきている。このスナップショットの方式は、アプリケーション・スナップショットとよく似ているが、こちらはひとつのアプリケーションだけでなく、全ファイルシステム上で稼動するものだ。ここは重要で、これによりファイルシステムのAPIを使って、アプリケーションを静止させてスナップショットをとることができる。これらのスナップショットは、複数のアプリケーション上で動作する。ただし、対応しているOSと仮想マシンには制限がある。このことは、システム環境における個々のOSに、OS独自のスナップショットが入っていなければならない、ということを意味する。さらに、大半のファイルシステム・スナップショットは中央での一元管理ができない。各サーバーのスナップショット・スケジュールは個々に管理・監視しなければならない。大規模なデータセンターでは、監視すべきスナップショットの数が数百にのぼる、という事態もありえないことではない。

ハイパーバイザ・スナップショット

仮想環境では、スナップショットはハイパーバイザ・レベルで起動できるので、スナップショット管理はずっと簡単になる。個々の仮想マシンやアプリケーションでスナップショットを実行・監視する代わりに、管理はハイパーバイザに集約される。例えば、VMwareのスナップショットはvCenterの中から管理できる。アプリケーション・スナップショットやファイルシステム・スナップショットと同様、どのメーカーのセカンダリ・ストレージシステムでもスナップショットとレプリケーションのターゲットにすることができる。スナップショットがハイパーバイザ・レベルで実装されているためである。

上記の三つの技術（アプリケーション・スナップショット方式、ファイルシステム・スナップショット方式、ハイパーバイザ・スナップショット方式）は通常、スナップショットの数と経過時間が増えるにつれてパフォーマンスの問題が表面化してくる。そこで登場するのが、ストレージ基盤のスナップショット方式である。

ストレージ基盤のスナップショット

最もよく使われているのは、ストレージ基盤経由のスナップショット方式で、通常ストレージハードウェアによって実行される。ストレージ基盤のスナップショットを使うことにはいくつかの利点がある。第一は、スナップショットはボリュームまたはシステム単位で起動できる点。そのため、前述の方式に比べ管理すべきスナップショット・ジョブが少なくて済む。第二には、ほとんどの場合、専用のストレージプロセッサーが各種のメタデータテーブルを処理してくれているおかげで、さほどパフォーマンスが低下せずにスナップショットを保持できる点だ。

ハードウェアベースのスナップショット方式の欠点は、レプリケーションのターゲットがベンダー指定の製品に限定されることだ。多くの場合、ソースとターゲットのストレージシステムは、同一のハードウェアベンダー製でなければならない。ただし最近は、セカンダリ・ターゲットとして、ベンダーが自社のポートフォリオ内のより安価なシステムの使用を認めるケースが増えてきた。
もうひとつの欠点は、データセンターに複数のストレージシステムがある場合、それぞれのストレージシステムが固有のスナップショット・マネージャーを持っていて、別々に監視しなければならない点だ。

スナップショットとレプリケーションをサポートしているソフトウェア定義のストレージ（SDS）であれば、複数のシステムに対してひとつの共通なエンジンを提供することで、この二つの欠点を解決できる。結果として、管理は単一のインターフェースへと集約される。

バックアップアプリケーション・スナップショット

バックアップ・アプリケーションには、二通りのスナップショットの使い方がある。ひとつは、バックアップ・ソフトウェアがスナップショットを実行・管理するものだ。もうひとつは、バックアップ・ソフトウェアが他のデバイスがもつスナップショット機能を起動し、そのスナップショットの管理を行うものだ。最初の使い方では、バックアップ・アプリケーションが、前述した他の方式のスナップショット機能を実質的に全て代替してくれる。二つ目の使い方では、バックアップ・ソフトウェアがスナップショット・データの管理・連携・整理を行う。

この二つ目の使い方が非常に面白い。この使い方だと、各種ベンダーから出ている最上のスナップショット技術を使うことができる。また、スナップショットの中から効率よくデータを探し出す機能もついている。この使い方の課題は、ストレージ製品のサポートに制限があることだが、サポートする製品が増えるにつれ、この使い方は極めて魅力的なものになる可能性を秘めている。

あなたの仮想環境に最適のスナップショットを選ぶ

多くのデータセンターでは、複数のスナップショット方式を使う必要があるだろう。例えば、アプリケーション認識機能が非常に重要になる場合がある。その場合、アプリケーション個別のスナップショット方式を使って、基幹系アプリ用スナップショットを管理するのは、それなりにやる価値があることかもしれない。

また、ほとんどの大規模データセンターでは、ファイルシステム・スナップショットやハイパーバイザ・スナップショットは、パフォーマンスについての懸念がある、というたったひとつの理由により、使われることはないだろう。大企業では一般的に、ネイティブのストレージシステムか、バックアップ・ソフトウェアが持っているスナップショット機能を使っている。それでも、ファイルシステムやハイパーバイザが持っているスナップショット機能は必要だ。ストレージシステムのスナップショットやバックアップ・ソフトウェア・スナップショットがそれらを組み込むことによって、正確なスナップショット・データをキャプチャできるからだ。

スナップショット方式を選択する際には、最初は最も広い範囲をカバーするものを選び、問題が起きたときに、それを解決する機能を持ったスナップショット方式を買い足すのがよいだろう。

著者略歴：George Crumpは、ストレージと仮想化を専門とするITアナリスト企業Storage Switzerlandの社長である。