仮想マシンの災害復旧計画を策定する（前編）

VMwareで仮想マシンの遠隔フェイルオーバーを実現する唯一の選択肢

多面的な作業を伴う仮想マシン（VM）の災害復旧。そのアプローチはさまざまあるが、そのベストオプションとしてはSite Recovery Managerとジオクラスタリングの2つが挙げられる。

　仮想マシン（VM）の災害復旧は、VMをプライマリサイトからリモートロケーションにフェイルオーバーするための多面的な作業だ。現在、仮想マシン環境の災害復旧には、幾つかのアプローチがある。その1つは、VMのフェイルオーバーを自動化する米VMwareのソフトウェア「vCenter Site Recovery Manager（SRM）」だ。その他に、自動フェイルオーバーをサポートする地理的に分散した「クラスタリング（ジオクラスタリング）サービスがある。このサービスはVM以外の復旧もできる。また、VMをさまざまなレベルで復旧できる標準的なデータ保護パッケージを利用することも可能だ。それらのパッケージは、SRMやジオクラスタリングと比較すれば手作業の部分が多くなるが、コスト的には有利だ。

　VMwareのSRMによる自動復旧は、データストアのデータをサイト間でコピーするため、アレイまたはSAN（Storage Area Network）レプリケーションに大きく依存する。SRMは、保護サイトとDR（ディザスタリカバリ）サイトの双方のSRMサーバまたはVM上で実行するが、同時にリモートサイトでvCenterが実行している必要がある。

　SRMを起動した後、管理者は以下の作業を行う必要がある。

• データストアレプリケーションの確立
• レプリケートされたデータストアの確認
• 保護されるVMの選択
• VMハードウェアのリマップ
• データ復旧計画の策定

　IPネットワーキングでは、リモートサイトのIPアドレスをプライマリサイトと同一にできないため、IPアドレスの再割り当てが必要になる。IPアドレスはVMで実行するアプリケーションやOSに割り当てられるものもあれば、vCenter ServerやSRMを実行するサーバなどのVMwareハイパーバイザーインタフェースに割り当てられるものもある。リモートサイトに立ち上げたVMを実行するためには、IPアドレスを変更しなければならない。

　また、複数の復旧プランを定義できるため、管理者は特定のフェイルオーバーをどのマシンに適用するか選択できる。代替可能な複数の復旧計画により、多様なフェイルオーバー機能を実現し、部分的な障害、例えば、保護サイトの特定のデータストアやESXホストのダウンなどに対応できる復旧オプションを用意することも可能になる。

　VMwareのSRMには幾つかの利点がある。ローカルサイトでDRテストを実行する機能をサポートしているため、管理者は既存の復旧計画を修正してこのテスト機能を組み込める。また、SRMは必要に応じて可能なかぎり多くの、あるいは少ない復旧計画を立てることが可能だ。例えば、サイトが全滅した場合の復旧プランや、個別のインフラがダウンした場合の復旧計画などが考えられる。

　VMwareの「High Availability（HA）」はESXフェイルオーバー機能を提供するが、ローカルサイトでのフェイルオーバーのみに限られる。リモートサイトへのフェイルオーバーを考える場合は、SRMが唯一の選択肢だ。もっとも、全てのインフラのダウンがSRMによるリモートサイトへの自動フェイルオーバーを必要する「災害」であるとは限らない。

　VMwareのSRMには現在幾つか制約があり、以下の機能がサポートされていない。

• Raw Device Modeデータ
• Multi-LUNデータストア
• 自動フェイルバック

　VMはFibre Channel（FC）に少なくとも2つの方法でアクセスできる。1つは通常のVMハイパーバイザーSCSIデータアクセスで、VMware定義のVMクラスタファイルシステム（VMFSデータストア）に仮想化されている。もう1つはRaw Device Modeのアクセスで、VMが実際にストレージなどをリンクするFCポートのハードウェアとコントロールを持つ。Raw Device Modeデータの非サポートは、このデータを保持するVMのフェイルオーバーが複雑になり、自動化しにくいことを意味する。SRMはこのデータのレプリケーションを監視せず、フェイルオーバー時にこのデータをアクティブなVMアクセシビリティへ自動的にプロモートしない。それらのステップは全て手動か、データセンター側でスクリプトを書かなければならない。

　Raw Device Modeは通常、パフォーマンス集約型VMに適用される。特殊なアプリケーションであることが多いため、仮想化されることは少ない。ところが、こうしたアプリケーションはクリティカルな特性を持つことが多く、災害復旧計画ではしばしば重要視される。システム管理者やデータセンターの関心は、それらのインフラやサーバがどれだけ仮想化されているかによって変わる。データセンターが完全にVMに移行すれば、当然その関心も高まるだろう。ちなみに、VMwareはSRMのβ版でRaw Device Modeをサポートしていない。それでもフェイルバックは可能だが、SRMフェイルオーバーの一環としてフェイルバックを実行するためには、管理者によってSRMを再構成する必要がある。

　フェイルオーバーがスケジュール化されることはないが、フェイルオーバー後のフェイルバックは通常スケジュール化されるアクティビティだ。プライマリサイトをオンラインに復旧し、インフラを修復してデータセンターの機能を回復させるまでには、それなりに時間がかかる。こうした時間のかかる作業はスケジュール化されるので、その過程でフェイルバックプロセスもスケジュール化できる。

　フェイルバックの復旧計画を事前に準備しておくことは可能だが、SRMは保護されたデータストアがレプリケートされたことを確認するために、ストレージのレプリケーションアクティビティをチェックする。そのため、SRMに対して保護されたデータストアとVMを特定し、インベントリをリマップする以下のフェイルバックプロセスがスタートするのは、フェイルオーバーが実行された後になる。

• データストアレプリケーションの確立
• 保護されたデータストアの特定
• 保護されたVMの選択
• サイトインベントリのリマップ
• ファイルバック復旧計画の作成

　次回は、もう1つのベストオプションであるジオクラスタリングを紹介する。

この記事の著者

関連記事

• 

  【Q＆A】サーバ仮想化が災害復旧計画に与える影響とは

• 

  仮想化で「保険としてのバックアップサイト」も戦力化する大阪ガス

• 

  【事例】アクティブ・アクティブの災害対策サイトを構築した安川電機の事例

• 

  早期復興を見据えた事業継続計画（BCP）と災害対策

• 

  米国CIOお薦めの「クラウドで災害復旧＆事業継続計画」

• 

  災害復旧において最も陥りやすい失敗

• 

  災害時に混乱しない災害復旧計画のポイント

• 

  災害時に備えた事業継続プラン策定のノウハウ