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

瞬時のバックアップが実現：スナップショット技術ガイド

著者：Alan Radding
Storage Magazine 2009年10月号より


スナップショット技術は、データバックアップシステムを強化し、RTOとRPOを劇的に短縮するために広く使用されている。しかし、スナップショット技術の実装にはさまざまな形態があり得ること、およびその違いが各自の環境に与えうる影響について知る必要がある。

スナップショットとは一般に、ファイル、ディレクトリ、またはボリュームのセットを特定の時点の状態のまま、コピーしたものを意味する。その名が示すとおり、スナップショットは、特定の瞬間または時点におけるデータセットのイメージを記録するものであり、その点で写真によく似ている。

スナップショット技術は当初、データバックアップにまつわる次のような問題を解決するものとして設計された。

データが大きすぎて、割り当て時間内にバックアップを完了できない
データが、バックアップされていないディレクトリから、バックアップ済み
のディレクトリに移動されたために、バックアップに失敗する
データのバックアップ処理中に書き込みが実行された場合などに、バックアップ済みデータが破損する
バックアップの処理中にアプリケーションパフォーマンスに影響が生じる

こういったバックアップの問題はすべて、スナップショットで解決することができる。しかしスナップショットをバックアップの万能薬と考えるべきではない。スナップショットにも問題がいくつかあるため、回避策を講じる必要がある（下記の「スナップショットの問題」を参照）。

スナップショットの問題

スナップショットの問題が発生するのは、データベースや、電子メール、ERP（エンタープライズリソースプランニング）、CRM（顧客関係管理）といったデータベースを中心に構築されたアプリケーションのように、構造化されたデータが関係する場合だ。大半のスナップショット技術は、構造化データアプリケーションと統合されていないため、スナップショットの作成は、データベースの休止、キャッシュのフラッシュ、書き込みの完了、インデックスとメタデータの更新を待たずに実行される。データがキャッシュ内にあるとき、またはすべての更新が完了する前にスナップショットが作成されると、スナップショットは「crash consistent」にはならず、破損してしまう。

この問題は、構造化データアプリケーションがWindowsサーバ上で実行されており、スナップショット技術がAPIを通じてWindows Volume Shadow Copy Services（VSS）を利用する場合には、多少緩和される。VSSは、特に構造化データアプリケーションに対応するように設計されており、データベースの休止、キャッシュのフラッシュ、および書き込みと更新の完了、という大仕事をすべて、スナップショット作成を開始する前に処理する。

あいにく、LinuxやUNIXオペレーティングシステムに関しては、同等のサービスまたはAPIが存在しない。VMware Inc.は、vCenterストレージAPIを通じて、部分的な解決策を提供している。このAPIでは、スナップショット技術によってvCenterにコマンドが送信され、仮想マシンを休止させた上でスナップショットを作成するよう指示する。この時点では、構造化データアプリケーションが認識されているわけではないため、スナップショットは「crash consistent」とならない可能性がある。

しかし、Windows VSSを使用しなくとも、「crash consistent」となるように構造化データアプリケーションのスナップショットを作成できる、優れた回避策がある。この回避策には、バックアップソフトウェアから構造化データアプリケーションのエージェントを利用できるようにするため、スナップショット技術のAPIと統合可能なバックアップソフトウェアが必要だ｡そのエージェントが、アプリケーションの休止、キャッシュのフラッシュ、書き込みと更新の完了を済ませた上で、バックアップソフトウェアからスナップショット技術にスナップショット作成を開始するという通知を送るように指示する。この回避策は比較的有効な解決方法だ。


スナップショット作成開始に必要な一連の手順：
1. まず、まもなくバックアップが開始するというコマンドを実行する。
2. システムに対し、このコマンドにてその時点で実行中のファイルシステムとアプリを停止する指示が送られる。
3. その後、未完了であったファイルトランザクションがあればすべて完了するように、ファイルシステムのフラッシュが実行される。
4. その後、スナップショットが作成される。
5. 次に、ファイルシステムとアプリケーションがリリースされて通常の処理が再開される。

スナップショット技術の進化は、単なるデータ保護を上回るレベルにまで達している。スナップショット技術を使えば、システム停止を伴わずに、稼働中のデータを危険にさらすことなく、実際のデータでアプリケーションソフトウェアを効率的にテストすることができる。また、データマイニングと電子開示の方法としても理想的だ。さらに、マルウェア、人的エラー、およびデータ破損を防止する災害復旧方法としても、非常に有効で望ましいレベルまで進化している。




スナップショット技術を利用できる領域

一般には、スナップショット作成はストレージシステムの機能と認識されるかもしれないが、スナップショット技術を利用できる領域はストレージシステムだけではない。スナップショット技術は、一般に次のような7種の実装形態で利用できる。

1. サーバ、デスクトップ、およびラップトップのファイルシステム
2. 論理ボリュームマネージャ（LVM）
3. ネットワーク接続型ストレージ（NAS）
4. ストレージアレイ
5. ストレージ仮想化アプライアンス
6. サーバ仮想化ハイパーバイザ
7. SQLデータベース

ファイルシステムベースのスナップショット技術

ファイルシステムベースのスナップショット技術は、Microsoft Corp.のVolume Shadow Copy Services（VistaのShadow Copy）を介してWindows NTFSで、Novell NetWare 4.11以降でNovell Storage Services（NSS）を通じて、SUSE LinuxではNovellのOES-Linuxを通じて、Sun Microsystems Inc.のSolarisおよびApple Mac OS X 10.6（Snow Leopard）ではZettabyte File System（ZFS）を通じて利用できる。

ファイルシステムベースのスナップショット技術の利点の1つは、ファイルシステムに付属しているため、「無料」であることが多い点だ。十分に機能するし、最新のファイルシステムによって非常に使いやすくなっている。短所は、各ファイルシステムを別々に管理する必要があるため、システムの数が増えるに従って煩雑になる可能性があることが挙げられる。また、スナップショットのレプリケーションが必要な場合、各ファイルシステムで各自のスナップショットのレプリケーションが実行されるように設定しなければならない。さらに、作成されるスナップショットの種類、スナップショット作成の頻度、確保すべき容量の大きさ（容量を確保する必要がある場合）、そしてスナップショットの設定、運用、および管理容易性がファイルシステムによって異なることが多い。管理が必要なサーバやファイルシステムの数が増えると、さらに複雑化する。

LVMのスナップショット技術

LVMのスナップショット技術は、Hewlett-Packard (HP) Co.のHP-UX Logical Volume Manager、Linux Logical Volume Manager、およびLinux Enterprise Volume Management System、MicrosoftのLogical Disk Manager for Windows 2000以降、SunのSolaris 10 ZFS、Symantec Corp.のVeritas Volume Manager（Symantec Veritas Storage Foundationの一部）で利用できる。

論理ボリュームマネージャのスナップショット技術は、複数のファイルシステムを横断して実行できる場合がある。例えば、SymantecのVeritas Volume Managerは、大半の一般的なオペレーティングシステムで機能する。また、LVMには通常、ストレージマルチパスとストレージ仮想化の機能も備わっている。

LVMを使用する場合、ライセンス／保守料金はサーバ1台ごとに追加費用がかかることが一般的だ。また、ファイルシステムベースのスナップショットに見られる調整と複雑な実装という問題にも直面する可能性がある。

NASのスナップショット技術

ネットワーク接続型ストレージ（NAS）は実質的に、アプライアンスまたはストレージに統合されたアプライアンス上で動作するよう最適化または特化されたファイルシステムといえる。大半のミッドレンジおよびエンタープライズ向けのNASシステムにはスナップショット作成機能が備わっている。例えば、オープンソースでないいくつかのオペレーティングシステムのものや、Microsoft Windows Storage Serverをベースとした各種NASシステムなどがある。

NASベースのスナップショット作成にはいくつか好ましい点がある。例えば、NASデバイスに接続されている物理サーバと仮想サーバ、デスクトップとラップトップのすべてに適用される共通の基準が用意されていることだ。また、実装、運用、管理が非常に簡単だ。NASベースのスナップショット技術は、Windows Volume Shadow Copy Services（VSS）、およびバックアップサーバとそのエージェントに統合可能な場合が多い。一部のNASベンダはWindows以外の構造化データアプリケーション向けに独自のエージェントを用意している。また、データ重複排除機能を持つデータNASスナップショット技術もあるし（EMC Corp.、FalconStor Software Inc.、およびNetApp）、スナップショット用に確保すべきストレージ容量が最小限で済むシンスナップショットプロビジョニングが可能なものさえある。

しかし、その利便性と豊富な機能には一定の代償が伴う。システムまたは容量ベースで課金されることの多いソフトウェアのライセンスと保守の料金が、非常に高額なのだ。NASシステムは、大半の企業で数が増えていく傾向にあり、それに伴いスナップショットに必要なタッチポイントの数も増えていくため、運用と管理がますます複雑になる。

ストレージアレイベースのスナップショット技術

ストレージアレイベースのスナップショット技術は、大半のブロックストレージアレイのオペレーティングシステムに備わっている。

ストレージアレイオペレーティングシステムに付属するスナップショット技術を使用することの利点は、NASベースのスナップショット技術の利点と同様だ。アレイに接続されている物理サーバと仮想サーバ、デスクトップとラップトップのすべてに適用される共通の基準とタッチポイントが用意されていること、そして実装、運用、管理が非常に簡単なことだ。また、NASと同様に、多くのストレージアレイのスナップショット技術も、Windows VSS、およびバックアップサーバとそのエージェントに統合できる。一部のベンダはWindows以外の構造化データアプリケーション向けに独自のエージェントを用意している。短所は、ライセンスと保守の料金が高額であること、Windows以外の構造化データアプリケーションとの統合が可能でないこと、ストレージシステムの増加に伴い複雑化が進むことが挙げられる。

ストレージ仮想化アプライアンスのスナップショット技術

ストレージ仮想化アプライアンスは、ファイル（NFS）ベースであるF5 Network Inc.のAcopia ARXという例外はあるが、それを除けば基本的にSANベースのものだ。そのほかの仮想化アプライアンス（あるいは仮想化を組み込んだストレージシステム）としては、Cloverleaf Communication Inc.のIntelligent Storage Networking System（iSN）、DataCore Software Corp.のSANsymphonyおよびSANmelody、EMCのCelerra Gatewayブレード、FalconStorのIPStor、Hewlett-PackardのXPシリーズ、Hitachi Data SystemsのUniversal Storage Platform V/VM、IBMのSAN Volume Controller、LSI Corp.のStoreAge Storage Virtualization Manager（SVM）、NetAppのV-Seriesストレージコントローラが挙げられる。

ストレージ仮想化ベースのスナップショット手法には、ストレージアレイベースおよびNASベースのスナップショット技術と同じ利点があるが、そのほかにも利点がある。単一または複数のベンダの複数のストレージシステムに適用される共通の基準と管理ポイントが用意されており、ストレージシステムを少数または単一のイメージに集約することができる。これにより、スナップショットの管理、運用、トレーニングを大幅に簡素化することができる。

ストレージ仮想化ベースのスナップショット技術の短所は、他のものと若干性質が異なる。これらのデバイスでは、パス分割アーキテクチャが備わったものであっても、トランザクションのレイテンシーが長くなるため、最終的にアプリの応答時間が長くなってしまう。また、トラブルシューティングが複雑になるとともに、複数ベンダ間での責任のたらい回しが深刻化するおそれがある。なお、ハードウェアやソフトウェアの追加には費用が伴うが、仮想化ストレージのライセンスや保守の料金が低いことで相殺される可能性がある。

サーバ仮想化ハイパーバイザのスナップショット技術

サーバ仮想化が勢いを増していることにより、ハイパーバイザベースのスナップショット技術の人気も高まってきている。この技術は、Citrix Systems Inc.のXenServer、MicrosoftのHyper-V、SunのxVM Ops Center、VMwareのESXおよびvSphere4といった仮想化ソフトウェアで利用できる。

ハイパーバイザベースのスナップショット技術を使用することの利点はシンプルだ。この技術はハイパーバイザとバンドルされているため、すべての仮想マシン（VM）に同じスナップショット手法が適用されること、MicrosoftのVSSに統合可能であること、および実装、使用、管理が容易であることだ。

この方法の好ましくない点は、スナップショットをハイパーバイザごとに別々に管理しなければならないこと、そしてWindows以外のOSでスナップショット技術を利用する場合、VM全体のイメージしか記録できないことだ。つまり、リストアの際にきめ細かな設定ができず時間がかかり、スナップショットがWindows以外の構造化データに対応せず、一貫性のないイメージが生成されるおそれがある。

SQLデータベースのスナップショット技術

SQLデータベースでは、スナップショットの作成は「スナップショットの分離」と呼ばれる。スナップショットの分離は、OracleやPostgreSQLといったデータベースで、すべてのトランザクションが、逐次化可能な状態であること、および分離され逐次的に実行されているように見えることを確実にするために必要となる。他方で、スナップショットの分離をサポートするが、逐次化のためにスナップショットが必須というわけではないSQLデータベースもある。一般に、SQLデータベースのバックアップ機能は、スナップショットの分離を利用して、「crash consistent」なテーブルのダンプを生成する。

SQLデータベースのスナップショット技術を使用することの主な利点は、データベースのスナップショット、およびデータベースをベースとしたアプリケーションが「crash consistent」となることだ。

しかし、この方法には大きな短所もある。このスナップショット技術は非常に限定されたもので、特定のデータベースとそれに関連付けられたアプリでしか動作しない。ファイルシステム、サーバ上の他のアプリケーション、他のデータベースやサーバでは動作しない。したがって、他のスナップショット技術やデータ保護技術が必要となるため、運用と管理が複雑になる。

さまざまなタイプのスナップショット技術とその仕組み
スナップショット技術には、大きく分けて次の6つのタイプがある。
1. copy-on-write
2. redirect-on-write
3. クローンまたは分割ミラー
4. バックグラウンドコピーを利用したcopy-on-write
5. 増分
6. 継続的データ保護

「スナップショット技術クイックガイド」

 

スナップショット技術

Copy-on-
write(COW)

Redirect-on-write
(ROW)

Clone 又は
split-mirror

COWと
ﾊﾞｯｸｸﾞﾗﾝﾄﾞｺﾋﾟｰ

増分

継続的データ保護
（CDP）

元データとの強い連動性

有 有 無 一部有 （ﾊﾞｯｸｸﾞﾗﾝﾄﾞｺﾋﾟｰが完了するまで） ｵﾘｼﾞﾅﾙｽﾅｯﾌﾟｼｮｯﾄの生成方法に依存

無

容量効率性

有 有 無 無 無 有
（複数のﾎﾟｲﾝﾄｲﾝﾀｲﾑｽﾅｯﾌﾟｼｮｯﾄと比較して）

元データのIOとCPUへの影響

高 中 低 低 低 低

元データコピーの書き込みオーバーヘッド

高 無 無 高 高 高

ロールバックやシンクロバックによる元データ論理障害対策

有 有 有 有 有 有

元データの物理障害への対策

無 無 有 一部有
（ﾊﾞｯｸｸﾞﾗﾝﾄﾞｺﾋﾟｰが完了するまで）		 基礎となるｽﾅｯﾌﾟｼｮｯﾄ手法による 有

copy-on-write（COW）スナップショット

COWでは、スナップショットのためのストレージ容量を確保した上で、確保した容量を使用してボリュームのスナップショット作成を開始する必要がある。COWスナップショットでは、元データがあった場所に関するメタデータのみが保存され、初回の作成時に実際のデータはコピーされない。その結果、スナップショットの作成が事実上瞬時に行われ、スナップショットを記録するシステムへの影響がほとんど発生しない。

その後スナップショットは、元ボリュームを追跡して、書き込みが実行された際に変更されたブロックがないかどうかをチェックする。ブロックが変更されると、元データは上書きされる前に、あらかじめスナップショット用に確保されたストレージ容量にコピーされる。スナップショットが作成された元データブロックは、最初の書き込み要求があったときに1度だけコピーされる。このプロセスにより、スナップショットデータはスナップショットが作成された時刻のものと正確に一致するようになる。このプロセスが「copy-on-write」と呼ばれるのはそのためだ。

変更されていないデータに対する読み取り要求は、元ボリュームに送られる。変更されたデータに対する読み取り要求は、スナップショット内のコピーブロックに送られる。各スナップショットには、スナップショットが最初に作成された時から変更されたデータブロック表すメタデータが含まれる。

copy-on-writeスナップショットの主な利点は、スナップショット用に確保するストレージ容量が、変更されたデータを記録するのに十分な大きさであればよいため、容量効率が非常に高いことだ。しかし、元ボリュームのパフォーマンスが低下するという短所がよく知られている。これは、元データがスナップショットに完全にコピーされるまでは、元ボリュームに対する書き込み要求を完了できないためだ。copy-on-writeに関して注意すべき事項として、各スナップショットにデータの有効な元コピーが必要であることが挙げられる。

redirect-on-write（ROW）スナップショット

redirect-on-writeは、copy-on-writeに似ているが、二重書き込み性能の問題が解消されたものだ。ROWでも、copy-on-writeと同様に、ストレージのスペース効率の高いスナップショット作成が実現する。ROWで二重書き込み性能の問題が解消されているのは、元ボリュームに対する新しい書き込みを、スナップショット用のストレージに直接実施することによる。これにより、書き込み回数が2回から1回に減る。したがって、COWでは元データの1つのコピーをストレージスペースに書き込むことに加えて変更後のデータのコピーが必要であるのに対して、ROWでは変更後のデータのみで済む。

redirect-on-writeでは、元コピーには、ポイントインタイムスナップショットデータが含まれ、スナップショット用ストレージに残るのは変更後のデータとなる。スナップショットが削除されると、やや複雑になる。削除されたスナップショットのデータをコピーして、元ボリュームと一致させる必要がある。作成されたスナップショットの数が増えるにつれて、劇的に複雑化が進み、元データへのアクセス、スナップショットデータと元ボリュームデータの追跡、およびスナップショット削除データの照合が複雑になる。（スナップショットが依存している）元データセットが断片化すると、深刻な問題が発生するおそれがある。

クローンまたは分割ミラースナップショット

クローンまたは分割ミラースナップショットは、データの完全同一コピーを作成するものだ。クローンまたは分割ミラーの元データは、ストレージボリューム、ファイルシステム、または論理ユニット番号（LUN）のいずれであってもよい。クローンの長所は、利用可能性が高いことだ。短所は、データのすべてをコピーしなければならないため、瞬時に実行できないことだ。クローンは、既存の1つの同期ボリュームミラーを2つに分割することにより、瞬時に利用可能となる。しかし、分割ミラーをクローンとして使用する場合、元ボリュームは同期ミラーを失ったことになる。

このスナップショット手法の大きな欠点は、スナップショットそれぞれに、元データと同程度の大きさのストレージ容量が必要であることだ。そのため、特にある時点で複数のスナップショットクローンを稼働させておく必要がある場合などには、コストが高くなる。もう1つの短所は、ミラーコピーへの同時書き込みによるオーバーヘッドが原因で、システムパフォーマンスに影響が生じることだ。

バックグラウンドコピーを利用したcopy-on-writeスナップショット

バックグラウンドコピーを利用したcopy-on-writeでは、COWの瞬時スナップショットデータを、バックグラウンドプロセスを利用して元の場所からスナップショット用ストレージにコピーする。これにより、元データのクローンまたはミラーが作成される。

バックグラウンドコピーを利用したcopy-on-writeは、copy-on-writeの長所を活かすと同時に、短所を最大限に克服しようとしたものだ。COWとクローン作成のハイブリッドと言われることが多い。

増分スナップショット

増分スナップショットは、スナップショットが生成された時に、ソースデータとスナップショットデータに加えられた変更を追跡する。増分スナップショットが生成されると、元のスナップショットデータは更新またはリフレッシュされる。元のスナップショットデータと、その後生成された増分スナップショットにはそれぞれタイムスタンプが付加される。タイムスタンプによって、任意のポイントインタイムスナップショットにロールバックすることが可能になる。増分スナップショットでは、最初のスナップショット作成の後はより高速にスナップショットを作成することができ、元データに比べてごくわずかだけ大きいストレージスペースを用意すれば済む。その結果、スナップショットをより頻繁に作成し、より長期間保持することが可能になる。

増分スナップショットの短所は、最初のスナップショット作成に使用された基盤となるベースライン技術（copy-on-write、redirect-on-write、クローン／分割ミラー、またはバックグラウンドコピーを利用したcopy-on-write）に依存することだ。例えば、クローンを利用した場合は最初のスナップショット作成に時間がかかり、COWを利用した場合は元データへの書き込み性能に関する問題が生じる。

継続的データ保護（CDP）

CDPは、復旧時点目標（RPO）をゼロにし、復旧時間目標（RTO）を瞬時にすることを目指して開発された。この方法は、ローリング災害（人手によって停止できる状態になる前にプライマリデータの問題が自動的にミラーデータの問題となること）が解消される点、および人的エラー、マルウェア、誤操作による削除、およびデータ破損を防止できる点を除けば、同期データミラーリングに似ている。

継続的データ保護は、増分スナップショットを強化したものといえる。元データへの変更があった時に必ずこれを記録してコピーし、タイムスタンプを付加する。実質的に、あらゆる瞬間に増分スナップショットを作成していることになり、非常にきめ細かな復旧が可能になる。CDPの実装例には、時間ベースとイベント（アプリケーションのアップグレードなど）ベースの両方がある。CDPは、完全なストレージスナップショットのジャーナルとして捉えると理解しやすい。

CDPは、電子メール、データベース、およびデータベースに基づくアプリケーションのデータ保護に適した形態だ。あらゆる時点にロールバックできるため、シンプルで迅速な復旧作業が可能になる。CDPが可能なストレージシステム兼仮想化アプライアンスの例として、FalconStorのIPStorが挙げられる。

保護すべきデータは増加の一途を辿る一方で、多くの場合、保護対策に使える時間は短くなるばかりだ。そのような環境で、スナップショットはデータ保護と日常のストレージ運用においてますます大きな役割を果たすようになるだろう。各種スナップショット技術の違いはごく小さなものに見えるかもしれないが、各自の環境でどのように運用できるかによって、実現する保護のレベルと、復旧の速さに大きな影響が生じる可能性がある。

略歴：Marc Staimer氏は、Dragon Slayer Consultingの社長。

STORAGE MAGAZINE 10月号

All Rights Reserved, Copyright 2000 - 2009, TechTarget
*この翻訳記事の翻訳著作権はJDSFが所有しています。
このページに掲載されている記事・写真・図表などの無断転載を禁じます。