柔軟なサイト切り替えを実現するSRMの機能
SRM5で新しく実装された機能に、「計画済みの移行」とフェイルバック機能がある。
この機能により、本番サイトが使用不可能に陥るような状況だけでなく、輪番停電などの限定的な災害や、被災訓練といった状況を想定した柔軟な対応が可能となった。また、VMware NSX®と併用すると、リカバリプランの作成と実行を簡素化し、リカバリにかかる時間を短縮できる。
計画済みの移行
SRMでは、「計画済みの移行」と「災害復旧」という2つのサイトの切り替え手法が選択できる。「計画済みの移行」は本番サイトが正常に使用可能状況での切り替えを指す。「計画済みの移行」を実行した場合には本番サイトで一度データの同期を行った後に仮想マシンをシャットダウンし、再度データの変更差分を同期してからの切り替えを実行する。こうすることで、災対サイトでの仮想マシンの起動、システムの稼働を確実に行うことが可能となる。
対して「災害復旧」では本番サイトが使用不可能であるという前提に基づくため、その時点の状態のまま災対サイトでの起動を実施する。
フェイルバック
特に「計画済みの移行」を行った場合など、後から本番サイトに切り戻しを行いたい、という要件も考えられる。アレイベースのレプリケーションを行った場合に限るが、SRMではフェイルバックの機能を実装した。災対サイトへの切り替え後、「再保護」を実行した上でフェイルバックを行うことが可能となっている。
例：フェイルバック操作の実行
最初はサイトA が保護サイトで サイト B がリカバリサイトと定義する。リカバリプランに基づいて復旧が実行されると、サイトAがサイトBに移行。サイ トAを保護サイトとしてリストアするには、フェイルバックを実行。
- 仮想マシンをサイトAからサイトBに複製する
- 再保護を実行。前のリカバリサイトであるサイトBが保護サイトになる。Site Recovery Managerは、保護情報を使用してサイト B の保護を確立。サイトAがリカバリサイトとなる
- サイト B の保護された仮想マシンをサイト A に復旧する計画移行を実行。
- 2度目の再保護を実行。サイトAが保護サイトとなりサイトBがリカバリサイトとなる
図9 フェイルバック実行の流れ
先述したリハーサルと併用すれば、システム変更時にはリハーサルのみ、半期に１回は実際に切り替えて業務継続訓練を行う、といった運用もリスクや負荷を抑えながら実行することが可能となる。
VMware NSXとの併用
Site Recovery Manager は、vCenter Server の境界にまたがる新しい NSX 論理スイッチを使用することで、リカバリプランの作成時にサイト間でネットワーク リソースを自動的にマッピングできる。これにより運用コストが削減され、保護にかかる時間が短縮できる。
フェイルオーバー後、IP アドレス、セキュリティ グループ、ファイアウォール設定、およびエッジ構成などを含むネットワークおよびセキュリティの設定は、リカバリされた仮想マシン上で維持される。これにより、リカバリにかかる時間がさらに短縮される。
VMware Cloud on AWSによる災害対策の実現
リカバリサイトとして、オンプレミスのvSphere環境だけでなく、VMwareベースのクラウドを利用して、ハイブリッドなプラットフォームによる災害対策を実現することも可能だ。その結果、オンプレミスのみの場合に比べて、リカバリサイトの運用コスト・負荷を削減することができる。以下、 VMware Cloud on AWSによるリカバリサイトを前提に、2つの具体的なソリューションについて紹介する。
VMware Site Recovery for VMware Cloud on AWS
VMware Site Recovery for VMware Cloud on AWSは、SRMをVMware Cloud on AWSのアドオンとして利用できるソリューションだ。事前にライセンスを購入すれば、VMware Cloud on AWSの管理コンソールから、SRMとReplication Serverをデプロイすることができる。オンプレミス版のようにOVFファイルから展開する必要はなく、簡単な操作のみでリカバリサイトを構築できるのが特徴だ。リカバリサイトとしてVMware Cloud on AWSを用いること以外は、オンプレミス版でサーバベースのレプリケーションを構築した場合と同等の機能とRPOを実現している。ただし、アレイベースのレプリケーションに対応していないことや、ウォームスタンバイ方式のためVMware Cloud on AWS上に管理コンポーネントを起動しておく必要があり、リソースに対するコストが発生する点には注意が必要だ。
VMware Cloud Disaster Recovery
VMware Cloud Disaster Recoveryは、クラウドサービスとしてディザスタリカバリを提供する、DRaaS(Disaster Recovery as a Service)ソリューションだ。具体的には、障害をトリガーとして、クラウドストレージからVMware Cloud on AWSにホストを展開し、リカバリサイトへのフェイルオーバーを行う。リカバリサイトの最新の状態はクラウドストレージに記録され、保護サイトの復旧が確認できたら、フェイルバックを行い、保護サイト側に仮想マシンを戻す。この他、複数世代のスナップショット、復旧ポイントの柔軟な定義、ファイル/フォルダ単位でのデータ復旧、暗号化や上書き禁止による不正なデータ改竄の防止に対応していることなどが特徴として挙げられる。
Site Recoveryとの大きな違いは、VMware Cloud on AWSにホストをオンデマンドに展開するため、リソースのコストを削減できることだ。コストを抑えてディザスタリカバリしたい場合はCloud Disaster Recoveryが、安定したインフラ上で迅速に復旧したい場合はSite Recoveryが適している。
図10 VMware Cloud Disaster Recover と VMware Cloud on AWS
まとめ ～SRMの導入判断～
SRMはシンプルながら確実に災害時の業務復旧ができる強力なソリューションだが、導入にあたっては以下の点を考慮に含めて検討していただきたい。
- 対象となるシステム重要度のレベル分けと、各レベルにおけるRPO/RTOの検討
- ストレージアレイによるデータレプリケーションを導入する場合、その費用、運用負荷
- データを同期するために必要なネットワーク帯域とその敷設工事費用とランニングコスト
- システムの特性を考慮した業務復旧手順
- 災対サイトに準備可能なハードウェアリソース
- SRMのライセンス（保護対象となる仮想マシン数 25台につき1ライセンス）
仮想化基盤の災害対策にあたっては、上記のような様々な観点からSRMを利用する、手動で行う、再構築する、といった手段を選択することが望ましい。
全ての仮想マシンをSRMで保護することも技術的には可能だが、その際に必要とするストレージやネットワーク、企業として復旧を優先すべきシステムとそうでないシステムへの投資バランス、運用負荷などを考慮していくと必ずしも全ての仮想マシンに対してSRMが必須、ということにはならないと考える。
冒頭で述べた、「システムの仮想化そのものが災害対策として利用できる」という点を活かして最適な災害対策手法を選定していただきたい。