多面的な作業を伴う仮想マシン（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を起動した後、管理者は以下の作業を行う必要がある。
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には現在幾つか制約があり、以下の機能がサポートされていない。
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を特定し、インベントリをリマップする以下のフェイルバックプロセスがスタートするのは、フェイルオーバーが実行された後になる。
次回は、もう1つのベストオプションであるジオクラスタリングを紹介する。
2024年のGW予算は横ばい 賃上げよりも物価高と円安の影響が勝る？――インテージ調査
インテージが全国の15歳から79歳の男女を対象に実施したゴールデンウイークに関する調査...
CNN幹部が語る、メディアビジネスにとってのAIのリスクと機会
生成AIがコンテンツを量産し、真偽の明らかでない情報があふれかえる中、メディアの価値...
「サイト内検索」＆「ライブチャット」売れ筋TOP5（2024年4月）
今週は、サイト内検索ツールとライブチャットの国内売れ筋TOP5をそれぞれ紹介します。
ITmediaはアイティメディア株式会社の登録商標です。
