JDSF | ストレージ管理ソリューション部会 | データ・ストレージに関する総合情報サイト

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

帰ってきたCDP

著者W. Curtis Preston
Storage Magazine 2010年8月号より

数年前にCDP製品が初めて登場したとき、その利点は明らかだったが、実装などの問題により、CDPへの関心はすぐに薄れた。だが今、CDPは復活しつつあり、データバックアップの未来を担う可能性がある。

継続的データ保護（CDP）とその関連製品は、バックアップの未来である。数年前に初めて登場したときは確かに宣伝倒れだった。しかし、そのとき、CDPが何十年もの間バックアップシステムやリカバリシステムにつきまとってきたほとんどすべての主要な問題を解決し、従来のバックアップシステムには到底不可能な復旧時間目標（RTO）と復旧時点目標（RPO）を実現するべく設計されているのも事実である。現在のCDP製品は、最初に出荷されたとき製品が抱えていた大半の欠点に対応している。CDPのブームは去ったかもしれないが、実際には、これまで以上に強力な製品になっている。

数年前は、ストレージ見本市のブースが1つおきにCDPベンダで占められていたような感じで、CDPの長所を絶賛する技術関係の記事が引きも切らなかった。しかし、そうした記事を信じたり、CDP製品を購入したりした者はほとんどいなかった。CDPは「Customers Didn't Purchase（顧客は買わなかった）」の略だ、とジョークを言う専門家もいた。CDPは完全な失敗に終わったため、当初のCDPベンダは結局、2社しか生き残れなかった。他のCDPベンダは、たとえ、まったくといっていいほど顧客がいなくても、それでもこのCDP製品に可能性を感じていたもっと大きな企業に買収された。

CDP 1.0が失敗した理由

CDPがそれほどすばらしいアイデアだったのなら、なぜ誰も購入しなかったのか？いくつかの理由が考えられる。

第1に、CDPを扱う企業のほとんどは新興企業だった。当然のことながら、新興企業や新興企業の製品に、金や時間、エネルギーを投資しても、結局は倒産してしまうのではないか、と懸念された。残念ながら、こうした懸念は現実のものとなった。Asempra Technologies、Double-Take Software、FilesX、Kashya、Mendocino Software、Revivio、Storactive、XOsoftはいずれも他の企業に買収され、（すべてではないが）一部は、買収後も結局、CDP製品がほとんど売れず、苦境に立たされた。

CDPは、導入するのも大変だった。技術的には、従来のバックアップシステムと並行して利用することが可能だったが、そうするだけの予算や時間がある人はほとんどいなかった。そのため、既存のバックアップシステムをCDPで置き換えるには、そうするだけの正当な理由が必要だった。だが、CDPはこれまで使い慣れてきたものとはあまりに違いすぎたため、完全に理解するのが困難で、従来のバックアップシステムを置き換えるのは難しかった。

もう1つ、CDPがユーザのニーズを十分に果たせないことが、たびたびあったのも大きな問題だった。例を挙げると、ほとんどのCDP製品は、現場のデータコピーとリモートのデータコピーの両方を処理することはできなかったので、ユーザはしばしばどちらかを選択しなければなければならなかった。つまり、日々のシステムリカバリと災害時のディザスタリカバリ（DR）用の製品が必要ということだ。また、バックアップしているアプリケーションに関する情報を持たないCDP製品も多かった。CDPベンダは、ストレージアレイと同じでアプリケーションを理解する必要はないと主張した。おそらく技術的にはその通りだったのだろうが、ユーザはそれまでのような安心感を得られなかった。彼らは、アプリケーションを認識してくれるCDP製品を求めていた。また、CDPには、従来のバックアップ製品やスナップショットよりはるかに大きな容量のストレージが必要だったので、保持期間をあまり長くすることができず、長期保持のために別のソリューションを用意しなければならなかった。

最後に、多くの人にとってCDPは、バックアップ業界のスター・トレックだった。素晴らしいアイデアだが、時代を先取りしすぎていたのだ。スター・トレックは、おそらく初めて放送されたときに完全には理解されなかったからだろうが、3シーズン放送されたところで、放送が打ち切られた。これと同様に、CDPは混乱を招くソリューションであり、たいていの製品は、CDPと違ってバックアップ方法を全面的に変更しなくても、バックアップやリカバリのニーズを満たせる、と多くの人は考えた。

Near-CDPとは？

初めて登場したとき、CDP製品は大いに話題になり、マーケティング部門は大喜びした。しかし、データの継続保護製品を提供する企業は他にもあり、こうした企業も自社製品にCDPという名称を使いたがった。

KashyaやRevivioなどのCDPベンダはこれに反対し、スナップショットはCDPではないと主張した。また、スナップショットの場合、特定の時点に復旧できるだけだが、CDPはどの時点にも復旧できると指摘した。そうしたわけでnear-CDPという新語が造られ、スナップショットを提供するベンダは、CDPブームにある程度乗ることができた。

だが、それから何年も経ったが、near-CDPという用語はまだ、業界団体であるStorage Networking Industry Association (SNIA)の用語集に追加されていない。こだわる人は、厳密にCDPか、そうでないかのどちらかだと主張するが、やはりnear-CDPという言い方が、レプリケーション機能を持つスナップショットを表現するのに最適な語だと考える人もいる。

near-CDPシステムは、従来のバックアップシステムとの共通点よりもCDPとの共通点のほうが多い。CDPやnear-CDPシステムは、変更されたブロックだけをバックアップシステムに転送する。フルバックアップを繰り返すわけではなく、あるファイルで数バイトしか変更箇所がなければ、数バイトだけリカバリシステムに送られる。また、変更されたブロックのリカバリシステムへの転送は、夜間のバッチ処理で一気に行うのではなく、一日を通じて常に行っている。CDPとnear-CDPはどちらも、リアルタイムでデータをリカバリし、実装にもよるが、数秒から1時間で復元ポイントを作成できる。

CDPとNear-CDPの大きな違いはただ1つ。CDPはRPOがゼロ（または、ほぼゼロ）で、アプリケーションを認識したスナップショットを前もって作成する必要がないことだ。だが、たいていのCDPユーザはそれでもスナップショットを作成し、それらのスナップショットまで復旧する。クラッシュして復旧が必要になった最近の復元ポイントよりも、パフォーマンスが安定していた既知の時点を好むためだ。そのため、CDP対near-CDPの論争は、ほとんど意味を成さないようにも見える。

生まれ変わったCDP

現在は、成功しているCDP製品がいくつかあるが、何が変わったのか？おそらく最も重要な変化は、今日のCDP製品のほとんどは大手バックアップベンダが提供していることだろう。実際、主だったバックアップソフトウェア企業のほとんどがCDP製品を販売している。ユーザは、まったく馴染みのない枠組みやバックアップベンダを受け入れなくても、CDPの機能を手に入れられる。

CDPが復活したもう1つの大きな理由は、初めて市場に登場したときと比べて、CDP製品が大きく進歩したことだ。たとえば、もう現場のデータコピーとリモートのデータコピーのいずれかで悩む必要はない。1つの製品で両方が可能なのだ。

また、現在成功しているCDPシステムは、バックアップしているデータに関しても以前より多くの情報を取得している。Microsoft ExchangeやOracleおよびSQL Serverなど、多くの人気アプリケーションとの統合を実現している。真のCDP製品は、スナップショットなど作成する必要がなく、どの時点にでも復旧できるが、この人気アプリケーションとの統合により、アプリケーションやバックアップシステムの管理者は、データのコピーが整っていたことが明らかな時点の復元ポイントを作成できる。もちろん、復旧作業でこうした既知の良好な復元ポイントを利用しないこともあるだろうが、そうした復元ポイントがあるとわかっていれば安心できる。

また、スター・トレックと同様に、今はCDPの時代、つまり「次世代」*1なのかもしれない。一部のサーバは、ここ数年で飛躍的な成長を遂げ、こうした大型サーバのRTOとRPOは以前より厳しくなった。企業の基幹業務に不可欠な300テラバイトのデータベースについて考えてみよう。そうしたデータベースは、何百万人もの人が1年中休みなくこのデータベースのサービスを利用している可能性がある。データベースのバックアップシステムは、データをまったく失わずに瞬時にリカバリする必要があるが、こんなことができるのはCDPだけだ。

米国の35州と欧州連合（EU）が制定したデータ漏洩通知法の影響も考えられる。この法律により、多くの企業は、バックアップテープに個人情報を安全に転送できるよう、暗号化システムを追加しなければならなくなった。だが、暗号化システムは費用が高くついたり、バックアップに時間がかかったり、暗号化キーの管理が必要になったりする可能性がある。その点、CDPであれば、企業はバックアップ用テープに手を触れることもなく、現場やリモート環境にデータのコピーを保管できるので、暗号化そのものを避けることができる

サーバの仮想化はここ数年で、ずいぶん普及し始めた。そして、CDPはこの技術に役立つ可能性がある。容量が十数テラバイトから数十テラバイトのデータストレージを備えた個別サーバはそれほどないかもしれないが、VMwareやMicrosoftのHyper-V、Citrix SystemsのXenServerが使用するストレージはそれぐらいの大容量の可能性がある。仮想マシンのイメージを保持している15テラバイトのストレージアレイが突然消失したらどうなるか考えてみよう。何十または何百もの仮想マシンが削除されてしまう可能性がある。しかも、従来の方法でそれらの仮想マシンのバックアップと復旧を行うのは、バックアップシステムの設計者が思う以上に困難な作業だ。物理は敵だ。1台の物理マシン上の20台の仮想マシンが、バックアップ中は、1台の物理マシンのように動作するのだから。

だが、物理が敵だとすれば、CDPは親友だ。優れたCDP製品は、仮想マシンにかかる負荷が標準的なウイルス対策ソフトウェアパッケージと同程度で、データをまったく消失せずに瞬時に1台またはすべての仮想マシンを復旧できる。サーバ仮想化の普及だけでも、CDP復活のお膳立ては整ったと考えられる。

CDPの製品サンプル

AppAssure Software：Replay 4

Atempo：Live Backup

CA Technologies：CA ARCserve Replication

Cofio Software：AIMstor CDP

EMC：RecoverPoint

FalconStor Software：FalconStor Continuous Data Protector

IBM：Tivoli Storage Manager FastBack

InMage：DR-Scout

Symantec：NetBackup RealTime

Vision Solutions：Double-Take Backup

CDPの仕組み

SNIAは、CDPを以下のように定義している。「データの変更を絶えず捕捉または追跡し、変更箇所を元のデータとは別に保存して、過去のどの時点の復元ポイントも有効にする方法で……データの変更はたえず捕捉され……別の場所に保存され……（RPOは）任意で、実際に復旧する前に設定する必要がない」

上記の定義に「スナップショット」という言葉が見当たらないことに留意してほしい。確かに現在のCDPシステムの多くは、既知の復元ポイントをあらかじめ作成できるが、そうする必要はない。CDPと見なされるには、スナップショットをとった時点だけでなく、どの時点にも復旧できることが条件となる。

CDPシステムは、データ分岐や書き込みの分割から始まる。プライマリストレージへの書き込みは、2つのパスに「分岐」または「分割」される。それぞれの書き込みは、オリジナルの転送先だけでなく、CDPシステムにも送られる。データ分岐ツールは、保護されたホストのエージェントの場合もあるし、ストレージネットワークのどこかに配置することもできる。データ分岐ツールは、ホストのエージェントとして稼働中、ホストシステムにはほとんど、あるいはまったく影響を与えない。「負荷の高い作業」はすべて他の場所で行われるからだ。ストレージネットワークにデータ分岐ツールを挿入するCDP製品は、Brocade Communications SystemsのStorage Application Services APIやCisco SystemsのMDSシリーズとSANTapサービス機能、EMC CLARiiONのビルトイン式の分割機能といった、専用のストレージシステムを利用できる。データ分岐ツールを置く場所を選べるCDPシステムもある。

ユーザは次に、ボリューム、ならびに同一時点への復旧が必要なホストの整合性グループ（コンシステンシーグループ）を設定する必要がある。CDPシステムのなかには、複数の整合性グループを含み、犠牲を払うことなく複数の粒度（グラニュラリティ）レベルを作成する「グループのグループ」を作成できるものもある。ユーザは、Oracleをバックアップモードにしたり、WindowsのVolume Shadow Copy Service（VSS）スナップショットを実行したりするなど、保護されたホスト上でアプリケーションレベルのスナップショットを作成してもよい（ただし、すでに述べたが、スナップショットは必要ない）。こうしたアプリケーションレベルのスナップショットを単に保持するだけのCDPシステムもあれば、スナップショットの実行支援を提供するCDPシステムもある。CDPシステムがアプリケーションレベルのスナップショットを一元化して保持してくれれば、それらが大いに役立つことがあるので、非常に便利だ。

それぞれの書き込みは、最初のリカバリデバイスに転送される。最初のリカバリデバイスは、データセンター内の他の場所にある別のアプライアンスやストレージアレイであるのが一般的だ。保護されているデータの近くに転送されるので、同じタイミングか、ごくわずかな時間差で書き込みのレプリケーションが作成できる。CDPシステムが同期レプリケーションをサポートしていても、たいていのユーザは、非同期レプリケーションを選んで、生産システムの性能に影響が及ばないようにしている。可能な場合にはCDPシステムが同期レプリケーションを行う、適応型のレプリケーションモードをサポートしている場合もあるが、多くの作業が遂行されているときは、デフォルトの非同期設定になっている。

データは、リカバリボリュームとリカバリジャーナルの2カ所に保存される。リカバリボリュームは保護されているボリュームの複製で、リカバリ中、保護ボリュームの代わりに利用される。リカバリジャーナルは、すべての書き込みのログを保護ボリュームで行われた順番に保存し、リカバリ中は、リカバリボリュームをロールフォワードまたはロールバックするのに利用される。リカバリボリュームへの転送前にすべての書き込みを保存する高速バッファとして利用される場合もある。こうした設計のおかげで、リカバリジャーナルに、保護ボリュームと同等かそれ以上の速度を持つストレージさえ利用できれば、リカバリボリュームを比較的安いストレージ上に配置できる。

第1のリカバリデバイスにコピーされたデータは、リモート環境に複製を作成できる。WANリンクの動作の問題があるため、CDPシステムは、利用可能帯域幅の違いに対処する必要がある。したがって、こうした条件が変わったときに、「遅れて」や「追いつく」といった動作が可能でなければならない。一部のシステムでは、遅延時間の許容範囲（数秒～1時間以上）を設定できる。設定した遅延時間は、複製されたシステムのRPOに反映される。CDPシステムは、すべての書き込みを1つの大きなバッチにして送信する。個別のブロックがその間に数回変更された場合には、最後に行われた変更のみが「ライト・フォールディング」というプロセスで送信されるように指定できる。これは明らかに、ディザスタリカバリコピーのリカバリの粒度レベルが、現場のリカバリシステムと異なることを意味するが、機能しているシステムとそうでないシステムの差、ということも言える。

今日のCDPは、ビルトインの長期保存用ストレージにもなる。短い時間帯（たとえば、毎日午後12時00分～午後12時00分30秒）を選んで、それらの復元ポイントを管理するのに必要なブロックだけを保存し、その間に変更されたブロックは削除するようCDPシステムに指示することができる。アプリケーションレベルのスナップショットをとるユーザは通常、整合性が保てるよう、このスナップショットの復元ポイントを、システムに指示を与えた復元ポイントと一致するよう調整する。関係のない変更を削除するので、CDPシステムのデータ保持期間はかなり長くなる。データ保持期間をもっと長くするために、これらの復元ポイントの1つをテープにバックアップし、有効期限が切れたらディスクから削除することも可能だ。多くの企業は、すべての変更を数日間保存する、1週間ほどは復元ポイントを1時間ごとに保存する、その後は1日1回のペースで復元ポイントを保存した後、90日ほど経過したらテープにコピーを保存する、という3つのアプローチをすべて利用している。

CDPの真に驚くべき点は、復旧処理の方法だ。CDPシステムは、希望の時点までロールフォワードしたりロールバックしたりして、リカバリやテストに論理ユニット番号（LUN）を使う必要があるいかなるアプリケーションにも、瞬時にLUNを示すことができる。（前述したように、多くのユーザは、整合性のあるアプリケーションイメージを作成した時点までリカバリボリュームをロールバックする。これは、イメージ作成時点から現在までの間に行われた変更は保存されないことを意味するにもかかわらず、クラッシュリカバリのプロセスを経るよりも、既知の整合性のあるイメージにロールバックするほうを好むユーザが多い）

製品によって、リストアしたLUNは、（ロールフォワードまたはロールバックされた）実際のリカバリボリュームや、主にリストアのテスト用の仮想ボリューム、あるいはその中間の何かである可能性がある。この最後のケースでは、実際にはバックグラウンドでロールフォワードやロールバックが行われているのに、すでにこれらのロールフォワードやロールバックが終わっているかのように、リカバリボリュームがアプリケーションに示される。同一のリカバリボリュームから同時に複数の復元ポイントを示せるシステムもある。

元の本番システムが復旧したら、リカバリプロセスは逆方向で進められる。リカバリボリュームは、元の場所にデータを複製して元の本番ボリュームを再作成するのに使用される。（システムが単純にダウンしただけで、置き換えが不要な場合はたいてい、機能停止後に発生した変更のみを送って、現時点まで更新することが可能だ）。元のボリュームが最新の状態になれば、アプリケーションを元の場所に戻して、逆方向のレプリケーションができる。

CDPによる標準的な復旧のシナリオと従来のバックアップシステムの復旧プロセスを比較してみれば、CDPがバックアップおよびリカバリの未来像である理由がよく分かるはずだ。

筆者略歴：W. Curtis Prestonは、TechTargetのStorage Media Groupの編集主幹で、独立系バックアップ専門家でもある。

*1訳注：CDPの次世代とスタートレックの新シリーズThe Next Generationをかけている。