課題を解決

わかるSRM(VMware Site Recovery Manager)(4/4)

2018/05/14

柔軟なサイト切り替えを実現するSRMの機能

SRM5で新しく実装された機能に、「計画済みの移行」とフェイルバック機能がある。
この機能により、本番サイトが使用不可能に陥るような状況だけでなく、輪番停電などの限定的な災害や、被災訓練といった状況を想定した柔軟な対応が可能となった。また、VMware NSX®と併用すると、リカバリプランの作成と実行を簡素化し、リカバリにかかる時間を短縮できる。

計画済みの移行

SRMでは、「計画済みの移行」と「災害復旧」という2つのサイトの切り替え手法が選択できる。「計画済みの移行」は本番サイトが正常に使用可能状況での切り替えを指す。「計画済みの移行」を実行した場合には本番サイトで一度データの同期を行った後に仮想マシンをシャットダウンし、再度データの変更差分を同期してからの切り替えを実行する。こうすることで、災対サイトでの仮想マシンの起動、システムの稼働を確実に行うことが可能となる。
対して「災害復旧」では本番サイトが使用不可能であるという前提に基づくため、その時点の状態のまま災対サイトでの起動を実施する。

フェイルバック

特に「計画済みの移行」を行った場合など、後から本番サイトに切り戻しを行いたい、という要件も考えられる。アレイベースのレプリケーションを行った場合に限るが、SRMではフェイルバックの機能を実装した。
災対サイトへの切り替え後、「再保護」を実行した上でフェイルバックを行うことが可能となっている。

例:フェイルバック操作の実行

最初はサイトA が保護サイトで サイト B がリカバリサイトと定義する。リカバリプランに基づいて復旧が実行されると、サイトAがサイトBに移行。サイ トAを保護サイトとしてリストアするには、フェイルバックを実行。

  1. 仮想マシンをサイトAからサイトBに複製する
  2. 再保護を実行。前のリカバリサイトであるサイトBが保護サイトになる。Site Recovery Managerは、保護情報を使用してサイト B の保護を確立。サイトAがリカバリサイトとなる
  3. サイト B の保護された仮想マシンをサイト A に復旧する計画移行を実行。
  4. 2度目の再保護を実行。サイトAが保護サイトとなりサイトBがリカバリーサイトとなる
図10 : フェイルバック実行の流れ

図10 : フェイルバック実行の流れ

 

先述したリハーサルと併用すれば、システム変更時にはリハーサルのみ、半期に1回は実際に切り替えて業務継続訓練を行う、といった運用もリスクや負荷を抑えながら実行することが可能となる。

VMware NSXとの併用

  • Site Recovery Manager は、vCenter Server の境界にまたがる新しい NSX 論理スイッチを使用することで、リカバリプランの作成時にサイト間でネットワーク リソースを自動的にマッピングできる。これにより運用コストが削減され、保護にかかる時間が短縮できる。
  • フェイルオーバー後、IP アドレス、セキュリティ グループ、ファイアウォール設定、およびエッジ構成などを含むネットワークおよびセキュリティの設定は、リカバリされた仮想マシン上で維持される。これにより、リカバリにかかる時間がさらに短縮される。

新しいSite Recovery Manager 8.1

Site Recovery Manager 8.1(以下SRM 8.1)がリリースされた。SRM 8.1では、VMware Cloud on AWSを通じて、オンプレミスとクラウド間のディザスタリカバリを可能し、vCenter Serverで設定が可能になった。またSRM8.1は、AWS上のサイトを複雑な設定を必要とせずに、ディザスタリカバリのテストも実施できる。このように、ハイブリッドなプラットフォームで災害対策が可能になった。

まとめ ~SRMの導入判断~

SRMはシンプルながら確実に災害時の業務復旧ができる強力なソリューションだが、導入にあたっては以下の点を考慮に含めて検討していただきたい。

  • 対象となるシステム重要度のレベル分けと、各レベルにおけるRPO/RTOの検討
  • ストレージアレイによるデータレプリケーションを導入する場合、その費用、運用負荷
  • データを同期するために必要なネットワーク帯域とその敷設工事費用とランニングコスト
  • システムの特性を考慮した業務復旧手順
  • 災対サイトに準備可能なハードウェアリソース
  • SRMのライセンス(保護対象となる仮想マシン数 25台につき1ライセンス)

仮想化基盤の災害対策にあたっては、上記のような様々な観点からSRMを利用する、手動で行う、再構築する、といった手段を選択することが望ましい。

全ての仮想マシンをSRMで保護することも技術的には可能だが、その際に必要とするストレージやネットワーク、企業として復旧を優先すべきシステムとそうでないシステムへの投資バランス、運用負荷などを考慮していくと必ずしも全ての仮想マシンに対してSRMが必須、ということにはならないと考える。

冒頭で述べた、「システムの仮想化そのものが災害対策として利用できる」という点を活かして最適な災害対策手法を選定していただきたい。

おすすめ資料ダウンロード

この記事を読んだ人がよく読む記事

最新の「課題を解決」

人気の記事

関連情報

VMware 認定ディストリビューター情報

TOP