仮想サーバー・バックアップ事情

著者:George Crump
Storage Magazine 2013年9月号より

 

仮想サーバーのバックアップはかつて場当たり的で、かつネットワークを圧迫する処理だった。しかし、バックアップ・アプリケーションの進化により、仮想化されたサーバー特有のニーズに応えられるようになった。この記事の中に、あなたがバックアップ・アプリに求めているものが見つかるはずだ。

 

サーバーの仮想化が、過去5年間でデータセンターに導入された最も重要なテクノロジーのひとつであることは疑うべくもない。仮想化によって、ネットワーク、ストレージ、さらにはサーバー自身の基盤設計に関する考え方が、ほぼ全てにわたってガラリと変わった。データ保護は、仮想環境への移行において最も大きく影響を受けたシステム運用の柱のひとつである。仮想化基盤のデータ保護における課題は、仮想化マシン専用のバックアップとリカバリーに特化した新興のベンダーが登場するきっかけとなった。

 

仮想化がバックアップにもたらした影響

仮想化以前の時代、アプリケーションは専用のサーバー上で稼動し、サーバー上にある全てのリソース(ストレージ、メモリ、CPU、ネットワーク)にアクセスしていた。そのアプリケーションのバックアップが始まると、バックアップは、データをサーバーからバックアップ先へとコピーするという目前の作業を完逐するために、ほとんどの場合、全ての有効なリソースを使っていた。

仮想化はこの状況を変えた。リソースは今や個別のアプリケーションを稼動している複数の仮想マシン(VM)間で共有されている。バックアップの仕組みが、この新たな現実に対応していない場合、たった一台のサーバーから、全てのVMが自分たちの全データを同時に送り始めるかも知れない。それにより、ハイパーバイザがメモリーリソースを使い果たして、サーバークラッシュにつながる可能性が出てくる。少なくとも、CPUとネットワークリソースの払底によりパフォーマンスは低下する。

 

初期のVMバックアップ対応

VMバックアップの「黎明期」、ほとんどのデータセンターでは、VMをスタンドアローン・サーバーのように保護していた。管理者は、同時に1つか2つのバックアップしか走らないように、バックアップのスケジュールを調整したものだった。このことは、IT管理者が既存のバックアップ・アプリケーションを使い続けられる、という事を意味していた。しかし、仮想化は成長を続け、VMの密度も増加したために、スケジュールによる調整は破綻し、代替の手段が必要になった。

 

仮想化バックアップの利点

データ保護のパフォーマンスに対するマイナスの影響はあったものの、仮想化は独自の様々な利点をもたらした。「サーバー」は今やカプセル化され、数千、場合によっては数百万の小さなファイルの代わりに、ひとつの大きなファイルになった。そして、このファイルは、ホスト間のVMのライブマイグレーションや、自動リソース調整のような機能を実現するために設置されている仮想化クラスター経由で、複数のサーバーからアクセスできるようになっている。

これによって、代替サーバーからこの「ファイル」(即ちサーバー)へのアクセスは、かなり楽になった。さらに、大抵のハイパーバイザは自身のクラスター・ファイルシステムにスナップショット機能を組み込んでいたため、プライマリ・ホストサーバーのリソースやパフォーマンスに影響を与えずに、代替サーバーからスナップショットやデータ保護が実行できた。要するに、ここにオフホスト・バックアップの機能が誕生したのだ。

これがきっかけとなり、Nakivo Inc.、PHD Virtual TechnologiesVeeam SoftwareVizioncore Inc.(Questに買われた後、Dellに買収された)などの会社が立ち上がった。彼らは、上記の機能を活用、発展させて、仮想サーバーを粒度レベルでリカバリーできる機能を作った。

仮想サーバー・バックアップの黎明期、目前の作業をこなすために、バックアップソフトウェアがハイパーバイザと行えるやりとりの種類は限られていた。結果として、ハイパーバイザが変更もしくはアップグレードされると、バックアップ・アプリケーションとの互換性問題が持ち上がった。これは、小さなバックアップベンダーにとっては許容可能なリスクだったが、エンタープライズ向けソフトウェアを提供する大手ベンダーは、VM専用のバックアップ機能を備えることに慎重な姿勢を示した。こうして従来のバックアップ・アプリがもたもたしている間に、新興のベンダーはVMwareのデータ保護において早々と大差をつけることができた。

今日、ハイパーバイザベンダーは、バックアップソフトウェア会社がコードベースの一部として利用できる形で、APIセットを提供している。これが意味するものは、少なくとも理論的には、バックアップのアプリケーションはハイパーバイザのプログラムが修正されても動くという事であり、バックアップ・アプリケーションのプログラム修正の量が最小限に抑えられる、という事だ。

 

VMバックアップの現在

APIセットが使えるおかげで、古参ベンダー、VM専用ベンダーにかかわらず、ほとんどのベンダーがオフホストVMバックアップを提供できるようになっている。この機能は今やVMデータ保護の基本条件と考えられるものだ。しかし、オフホスト・バックアップのさらに先に、ITプランナーが検討すべきVM特有の機能が存在する。

 

・エージェント・バックアップ VS. エージェントフリー・バックアップ

エージェントは、バックアップ処理を支援するためにVMにインストールされるソフトウェアである。前述したAPIによってオフホスト・バックアップが可能になっても、いくつかのベンダーは未だにVMにインストールしたエージェントに依存している。エージェントは(データベースやemailデータの粒度別バックアップ・リカバリを可能にするために)アプリケーション検知の支援に使われたり、ロー・バックアップのパフォーマンスを加速するのに使われたりすることがある。

 

エージェントフリー・バックアップ製品は、仮想マシンにプログラムをインストールはしないが、それでも粒度別にアプリケーション・データをリカバリーすることができる。とはいえ、バックアップされたVMのイメージは別のVMとしてマウントしなければならず、そこからデータをコピーしなければならない。いくつかのエージェントフリー・バックアップ製品は、VMイメージをマウントすることなく、Microsoft ExchangeやSQL Server、Oracleなどの著名なデータタイプから粒度別のデータコンポーネントを、読み取り、検索し、抽出するための「ヘルパー」アプリケーションを作っている。

 

・変更ブロックのバックアップ

ハイパーバイザのAPIは、VMwareのChanged Block Tracking(CBT)のようなバックアップソフトウェアに、前回のバックアップから仮想マシンのイメージファイルのどの部分が変わったのかを理解させる機能を次々と付加している。これは、バックアップ実行の頻度向上を可能にする重要な機能である。この機能により、データ転送量は最小化され、結果としてVM損壊時のデータ損失の低減につながる。

 

・リストア機能の拡張

リストアも仮想化環境の中で大幅に改善されている。最初に、ハイパーバイザAPIを利用してVMイメージ全体を戻さなくても、オフホスト・バックアップはほとんど、リカバリーが必要なファイル単体か一連のファイルだけを戻すことができる。また、いくつかのベンダーはCBTを利用して変更ブロックのリストアを提供している。例えば、もし大規模なデータベースが損壊した場合、変更ブロック・リカバリーによって、データベースが最後に変更された部分だけを戻せばよい。

リストアは、リカバリーデバイスから直接VMを実行可能な、よく「インプレース・リカバリー(即時復旧)」と呼ばれる製品において、さらに機能拡張が進んでいる。インプレース・リカバリーを使えば、ネットワークを経由のデータ転送は不要で、しかもVMとそのデータは、ものの数分で運用を再開できる。この機能を一時間毎のCBTバックアップと組み合わせれば、多くの会社にとって事業継続のソフトウェアを別に持つ必要がなくなる。

いくつかのベンダーは、この機能をクラウドに拡張している。実際に「即時」リカバリーに使われるデータが、遠隔のデータセンターの中にある訳だ。このアーキテクチャーの場合、データのバックアップはローカルで行われ、それがクラウドに複製されるため、稼動サイトが災害に遭った際のリカバリーソリューションとして位置づけられる。この方法はローカルのデータ保護と可用性の課題を解決するだけでなく、DRへの備えも提供するのである。

インプレース・リカバリーと変更ブロック・リカバリーには、それぞれ一長一短がある。インプレース・リカバリーの場合、どうしてもVMの保存先をプライマリストレージに戻さなければならない時が来るだろう。また、バックアップ・デバイスがプライマリーストレージ・デバイス並みのパフォーマンスと冗長性を持つことは、まずありえない。これは、前述のクラウド・リカバリーのモデルについて、特に言えることだ。その一方でCBTリカバリーは、ダウンタイムが先に発生するものの、VM全体を移行するのにかかるもっと長い時間が不要だ。理想をいえば、ITプランナーはどちらの手法にも対応している製品をさがすべきである。

 

・テープ・サポート

最初はディスクにしか対応していなかったVM専用アプリケーションの世界に、テープ対応が入ってきているのは、やや意外かも知れない。しかし、テープは安価で、持ち運びができ、VMの長期保存には最適である。テープは、ディスクの高速バックアップとリストアの補強としてはうってつけだ。テープによって、ディスクへの投資は低く抑えられ、ディスクを最も緊急を要するリカバリー用として限定できるからだ。ディスクのみの環境であっても、テープ対応については充分に検討を行うべきだ。長期保存用のストレージの節約と、VMをテープに「一時保管」(しておき、いつでもテープからリカバリー)できる能力は、大きな利益をもたらしてくれるだろう。

 

・物理サーバー・サポート

バックアップ・アプリケーション間の大きな差別化要因は、物理サーバーをバックアップする能力である。新参のVM専用バックアップ・アプリの多くはVMにしか対応していない。多くのデータセンターが100%のサーバー仮想化を目指して格闘しているが、その大半は目標からはほど遠い。これが意味するところは、VM専用のアプリを選択したならば、最低でも2つの異なるバックアップ・リカバリ処理と付き合うのを覚悟せよ、という事だ。

従来のエンタープライズ・ソリュージョンの大半は、物理及び仮想のサーバー保護をサポートしているが、機能的には前述したVM専用の機能の面で劣っている場合が多い。あなたは、単一のデータ保護製品という贅沢か、それぞれの長所を利用するために2つの製品を運用するかの間で選択を迫られるかもしれない。一般的に、どれだけ多くの基幹データが、物理システム上にあるかが決め手になる。

 

VMバックアップのベースライン

仮想サーバー・バックアップの状況は、ここ数年で大幅に改善された。これは、安定したAPIセットを提供し、画期的な機能や基盤との連携を可能にした、VMwareのようなベンダーの貢献によるところが大きい。これらの機能はバックアップを改善しているだけでなく、事業継続と災害復旧のアプリケーションを別個に持つことを不要にする役割も果たしている。

 

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

 

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