DRサイトはなぜ必要？
BCP/DR（事業継続計画/災害復旧）への取り組み
以前から大企業を中心に進められていましたが、そのニーズが急速に高まったのは、2011年3月11日の東日本大震災の発生以降のことです。地震や津波による直接的な被害に加え、その後に発生した電力不安も、多くの企業にBCP/DR対策を真剣に考え直させるきっかけとなりました。
従来から、ミッションクリティカルなシステムは、IT機器やネットワーク、電源などを二重化して保護する対策がよく採られてきましたが、単一サイト内で行える対策は、大規模な自然災害や広域停電への備えとしては不十分です。
では、どのような対策が必要になるのでしょうか。もしも、数時間のシステムダウンが事業の存続にかかわるような損害につながることが予想される場合は、サイトがダウンしても業務を継続できる仕組みが必要です。その仕組みが、データの遠隔コピーを活用したDRサイトなのです。
DRサイトの基本的な考え方
まず、保護サイトと同じ構成のDRサイトを遠隔地に用意します。次に、保護サイトのデータが自動的にDRサイトにコピーされるようにします。そして、保護サイトがダウンしたら、DRサイトが業務を引き継ぐ（フェイルオーバーする）ようにします。
なお、日立のエンタープライズストレージとミッドレンジストレージは、サーバを介さずにストレージ間でデータをコピーするレプリケーション機能を備えています。
●ＤＲサイトの基本的考え方
だれが復旧させる？DRの落とし穴
だれがどの段階でフェイルオーバーを実行するかという点が問題
DRサイトの基本的な考え方は上記のとおりですが、だれがどの段階でフェイルオーバーを実行するかという点が問題となります。もちろん、その答えは必要に応じて自動的にフェイルオーバーが実行されるようにすることです。
もしも、復旧手続きを手作業で行う必要があるとしたら、復旧までに余計な時間がかかってしまいますし、オペレーションミスや稼働確認の見落としなどでDRサイトがうまく機能しない恐れがあります。また、災害時は交通機関のマヒや道路の渋滞などで、運用担当者がオペレーションできない状態になるかもしれません。
そのため、稼働状況の監視から障害発生箇所に応じた復旧手続きの実行、稼働確認までを自動化しておかないと、せっかくのDRサイトが絵に描いた餅になってしまいかねないのです。
●復旧手続きを自動化しておかないと・・・
仮想化で可用性確保の要件が変化
「クラスタウェア」と呼ばれるソフトウェアがフェイルオーバー
冒頭で、障害に対処するための二重化システムに触れましたが、こうしたシステムでは「クラスタウェア」と呼ばれるソフトウェアがフェイルオーバーを担っています。クラスタウェアは、アプリケーションとサーバの稼働状況を監視し、必要に応じてアプリケーションやサーバを再起動し、サーバ自体に障害が発生している場合は待機しているサーバを立ち上げます。
しかし、仮想化環境が普及して複雑化した現在のシステムでは、クラスタウェアだけで可用性を確保することが難しくなっています。ひと口に仮想化環境と言っていますが、ハイパーバイザ―ひとつ取っても、VMware vSphere®やHyper-V®、Xen Server、KVMなどの種類があり、仮想マシンはそれぞれのハイパーバイザ―の制御下にあります。そのため、仮想マシンをフェイルオーバーさせるには、クラスタウェアとハイパーバイザ―が連携しなければなりません。
また、各ハイパーバイザ―に対応した管理製品には、仮想マシンと物理サーバの稼働状況を監視して、必要に応じて仮想マシンを再起動したり、物理サーバが故障した場合は別な物理サーバで仮想マシンを起動させるツールが用意されています。しかし、そうしたツールはアプリケーションの稼働状況監視や、リカバリー機能をサポートしておらず、アプリケーションを最初から立ち上げ直さざるを得ないため、保存されていないデータは再入力しなければなりません。
これらに加えて、DRサイトの構築においては、サイト全体の可用性を監視して、サイト間でフェイルオーバーする別な仕組みも必要になります。
すなわち、仮想化環境下でDRサイトを構築するには、アプリケーション、仮想マシン／物理サーバ、サイトの各監視対象に対応したツールを組み合わせる必要があるのです。しかも、それぞれのツールが独立した状態で存在していては、DRサイトの構築や運用が困難になります。お互いに連携する仕組みを持ち、管理の一元化が可能なソリューションが求められているのです。
●仮想化技術とＤＲ対応により要件が複雑化
日立、シマンテック、CTCの3社で業務自動復旧を検証
仮想化環境下のDRニーズ
こうした仮想化環境下のDRニーズに対応するために、日立、株式会社シマンテック、伊藤忠テクノソリューションズ株式会社（CTC）の3社は、業務自動復旧を実現するDRソリューションの検証を共同で行っています。
3社が検証したソリューションは、仮想化環境としてVMware vSphere®を利用するシステムに対応するもので、アプリケーションの保護をシマンテックの「Symantec™ ApplicationHA」（以下、ApplicationHA）で、仮想マシン／物理サーバの保護を「VMware High Availability」（以下、VMware HA）で、サイトの保護を「VMware vCenter Site Recovery Manager」（以下、VMware SRM）と日立ストレージのリモートレプリケーション機能で分担する構成になっています（表1）。
これらのツールは、以下のように連携します。
●ApplicationHA、VMware HA、VMware SRM、日立ストレージの連携で仮想化環境下のアプリケーションを保護
まず、アプリケーションを監視するApplicationHAは、仮想マシン上で動作し、アプリケーションに障害が発生した場合は、その再起動を試みます。また、ApplicationHAはアプリケーションの稼働状況をVMware HAに通知しており、通知が一定期間とだえるとVMware HAが仮想マシンの復旧を図ります。
VMware HAは、仮想マシンと物理サーバ（ESX/ESXiサーバ）を監視し、仮想マシン上のOSが停止している場合は仮想マシンの再起動を、物理サーバに障害が発生している場合は影響を受ける仮想マシンを別の物理サーバで起動します。
そして、DRサイト構築でかなめとなるのがVMware SRMで、このツールはサイト間の仮想マシンのリカバリー計画、テスト、実行を担います。VMware SRMとApplicationHAは、プラグインの「ApplicationHA SRM Component」によって連携されており、サイト間のフェイルオーバー実行後は、このプラグインを通じてApplicationHAによるアプリケーション監視が再開されます。また、VMware SRMには重要なプラグインがもう1つあります。日立ストレージのリモートレプリケーション機能を制御する「Hitachi Storage Replication Adapter」がそれです。このプラグインの働きにより、VMware SRMで設定した仮想マシンのリカバリー計画に基づいて、サイト間コピーが自動的に実施されます。
以上のように、各レベルを担当するツールが密に連携することで、どのレベルで障害が発生した場合でも、アプリケーションの可用性が保たれます。実際、3社による動作検証では、「仮想マシン上のアプリケーション障害」、「仮想マシンの障害」、「物理サーバの障害」、「サイト障害」のすべてのケースにおいて、アプリケーションの復旧が確認されました。
さらに、構築・運用が容易な点もこのソリューションの特筆すべき点です。例えば、ApplicationHAは、仮想マシンごとにインストールする必要がありますが、インストール作業はVMware環境の管理コンソールである「VMware vSphere Client」から一括して行えます。また、ApplicationHAによって監視されるアプリケーションの稼働状況の確認、制御もVMware vSphere Clientの画面で一元管理することが可能です。
業務の継続性を高い次元で担保しつつ、運用・管理を簡素化する今回のソリューションは、安心して導入できる真のDRソリューションと言えるでしょう。
●表1:仮想化環境向けDRソリューションの主要なコンポーネント
