よくわかるVMware SRMとは?

一般的なITの災害対策

災害対策システムの導入にあたっては、RPO(Recovery Point Objective:目標復旧ポイント)、RTO(Recovery Time Objective:目標復旧時間)の検討が必須となる。RPO、RTOともに短時間での復旧を目指すと、高度な技術や製品が必要となるため実現に必要なコストは非常に大きくなる。 そのため、企業に与えるインパクトの観点から、システムの重要度、かけられるコストを検討し、RPO、RTOを決定することが必須である。 短時間のRPOを実現するソリューションとして、現在最も主流なのはストレージアレイの機能によるレプリケーションである。ネットワーク環境次第で、ほぼリアルタイムのコピーを実現することも可能である。 一方、短時間のRTOを実現するためには、従来の物理環境の場合、被災時の復旧マニュアルを整備し、対応しているケースが一般的だった。このマニュアルには、誰が、どのような手順で復旧させるのかを予め決めておき、それに従って手作業で復旧させるというものである。

VMware vSphere基盤における災害対策

VMware vSphere®基盤上の仮想システムにおいてもこの2点は例外ではない。RPO=データの保護に関しては、仮想環境でも物理環境と同様に考える必要がある。一方、RTO=システムの復旧に関しては、仮想化によって大きく改善することができる。

システムを仮想化しておくことで仮想マシンの複製、移動が容易になるほか、物理サーバに依存せずにシステムを稼働させることができるようになるため、データの保護ができていれば、被災時のシステム復旧の効率、負荷が大幅に軽減される。そのため、仮想化を導入することで一定の災害対策とすることができるということである。実際、災害時への対応を目的として仮想化を導入したというユーザも多い。

近年、基幹システムを含めた多くのシステムの仮想化が急速に進んでいるが、被災時の復旧を、より短時間、より低コストで実現することが同時に求められている。

以下、vSphere基盤上の仮想マシンに対し、被災時のシステム復旧を自動化し、短時間での業務復旧を実現する、 VMware Site Recovery Manager®(以下 SRM)に関して紹介していく。

VMware Site Recovery Manager 概要

SRMは、災害時のシステム復旧を自動化し、迅速なサイト切り替えを実現するVMwareのソリューションである。リカバリ手順をポリシー化し、ボタン1つでポリシーに基づいて自動的にリカバリサイトに切り替えることが可能だ。また、テスト機能も提供され、本番サイトに影響を与えることなく事前にリカバリのテストをするできる。保護設定の単位は、データストア、ストレージ単位だけでなく、VMware vSphere® Replication™と連動させることによって仮想マシン単位で保護することができる。
SRMの利用目的と主な特徴は以下の通り。

利用目的

  • vSphere基盤上の仮想マシンの、災害時における災対サイトでの復旧プロセスの自動化
  • 災害時を想定した復旧訓練
  • サイト間での計画的なシステムの移行

特徴

  • ストレージアレイ、もしくはESXi/ESXサーバでのレプリケーションと連携
  •  復旧手順を自動化できる
  • 被災時の復旧を1オペレーションで実現
  • 本番環境に影響を与えないリハーサル機能
  • vSphere Web Clientから管理可能

SRMは、災対サイトにおけるシステム復旧の手順を自動化し、オペレーションを簡素化することで短時間での復旧を実現するソリューションである。システム規模にも依存するが、数十分~数時間程度で復旧した実績を持っている。
アレイベースのレプリケーションとサーバベースのレプリケーションでは実現可能な機能の違いがある。ポイントは以下の2点である。

  • RPOはアレイベースの場合リアルタイムも可能、サーバベースの最短RPOは15分(但し、vSANを利用した場合においては、5分まで短縮することが可能)
  • ストレージアレイを利用した場合、フェイルバックの自動化が可能

保護対象のシステムの要件を満たす手法を選択する事が可能となっている。

SRMの導入にあたっては、以下の前提条件を満たす必要がある。

  • バージョンによる注意点
    SRM、VMware vCenter® 、vSphere Replicationは、両サイトで同じバージョンにする
  • コンポーネントの互換性による注意点
    導入に当たっては、VMwareのサイトからSRMとvCenterの互換性、vCenterとvSphere Replicationの互換性、ESXiとvCenterの互換性を確認する

図1:アレイベースのデータレプリケーションを利用したSRM実行環境

図1:アレイベースのデータレプリケーションを利用したSRM実行環境

サーバベースのレプリケーションを利用する場合

  • 両サイトにvCenter Server で管理されたvSphere基盤がそれぞれ存在する
  • レプリケーションに必要なサーバコンポーネントがデプロイ可能である

以下に、SRMにおけるサーバベースのレプリケーションを利用した際の全体像を示す。図2:サーバベースのデータレプリケーションを利用したSRM実行環境

図2:サーバベースのデータレプリケーションを利用したSRM実行環境

サーバベースを実行する際には、アレイベースよりも必要なサーバが多くなるが、これらはOVFファイル形式で提供され、vSphere Web Clientの管理画面から展開が可能となっている。各コンポーネントの名称と役割は以下の通り。

  • vRMS(vSphere Replication Management Server):保護のフレームワークを作成
  • vRS(vSphere Replication Server):災対サイトにてレプリケーションされたデータを受け取り、反映させる
  • vRA(vSphere Replication Agent):各ESXi/ESXサーバで、データの変更差分を送るためのエージェント

また、ストレージアレイのレプリケーションが不要となるため全体のコストとしては抑えられる。そのため、従来よりも災害対策の実現にあたっての障壁は低くなるだろう。

アレイベースとサーバベースレプリケーションの併用の場合

アレイベースレプリケーションで構成する仮想マシンにはアレイベースの保護グループを作成し、サーバベースのレプリケーションで構成する仮想マシンには サーバベースの保護グループを作成する。保護グループにレプリケーションタイプを混在させることはできない。アレイベースの保護グループとサーバベースの保護グループを同じリカバリプランに混在させることができる。図3:アレイベースとサーバベースのデータレプリケーションを併用したSRM実行環境

図3:アレイベースとサーバベースのデータレプリケーションを併用したSRM実行環境

SRMの構築概要

SRMの利用にあたっては、vSphere Web Clientを用い、vCenter Serverのメニューからアクセスする。SRM環境の構築は以下の手順で行う。アレイベース、サーバベースのどちらも大きな違いはない。(以下は概略。詳細は管理ガイドを参照)

  1. 保護サイトとリカバリサイトのペアリング
  2. コンポーネントの構成
    1. アレイマネージャの構成
    2. vRMS、vRSの構成
  3. インベントリマッピングの構成
  4. 保護グループの作成
  5. リカバリプランの作成
  6. リカバリプランのテスト/実行

いずれの作業も日本語のウィザードに従って行うことができ、構築を容易にしている。

保護サイトとリカバリサイトのペアリング

SRMでは、本番サイトを保護サイト、災対サイトをリカバリサイトと呼び、予めペアを構成しておく必要がある。

コンポーネントの構成

  • アレイベースの場合:アレイマネージャの構成
    先述したSRAを利用し、SRMサーバからストレージアレイを操作できるよう、構成を行う。通常は、初期構築時に1回のみ実行する。
  • サーバベースの場合:vRMS、vRSの構成
    vSphere Web ClientからSRMプラグインを利用してvRMS、vRSを展開していく。展開後にデータベース、vCenter Serverなどの情報を登録していく。

インベントリマッピングの構成

この項目は実施を推奨するオプションである。本番サイトにおける仮想マシンのインベントリ設定(フォルダ、ネットワーク、リソースプール)を、災対サイトで復旧した際にどうするのかのデフォルト設定を行う。インベントリマッピングを作成していない場合には、仮想マシンごとに個別に設定していく必要があるので注意が必要である。

保護グループの作成

SRMでは仮想マシンを保護グループ単位で保護、復旧させる。アレイベースの場合、保護対象となる全ての仮想マシンは1つのデータストアグループ内に保存されている必要がある。データストアグループとは、仮想マシンを構成するファイルが複数のLUNおよびVMFSにまたがることがあるため、SRM上で統合管理するためのグループである。図4 : データストアグループと保護グループ

図4 : データストアグループと保護グループ

ここまでが環境設定である。ここから、被災時の復旧プロセスを具体的に作成していく。

リカバリプランの作成

前ステップで構成した保護グループを対象に、実際のリカバリプランを作成していく。1つのリカバリプランに複数の保護グループを含めること、もしくは1つの保護グループを異なる複数のリカバリプランの対象とすることが可能である。図5 : リカバリプランの作成イメージ

図5 : リカバリプランの作成イメージ

リカバリプランはウィザードから作成することができる。ウィザードを完了すると、標準的な復旧手順がデフォルトのリカバリプランとして作成される。このプランを、自社の復旧計画に基づいてカスタマイズしていくことで復旧手順として確立することができる。下図は、リカバリプランの一例である。図6:リカバリプラン

図6:リカバリプラン

リカバリプランでは仮想マシンだけでなくストレージの同期、切り離しなどの制御も実施する。この時ストレージごとにコマンドや作業が異なるため、前述のSRAが必要となるのである。

デフォルトで作成されたリカバリプランでは、保護グループ内の仮想マシン全ての優先順位が「レベル3」として構成される。優先順位は、レベル1~5の5段階で定義される。
リカバリプラン実行時には、優先順位が高いグループの仮想マシンから起動する。上位の優先度に属する仮想マシンの全てが起動か失敗するまでは、下位の優先度の仮想マシンは起動しない。また、各優先度のグループ内においては、全ての仮想マシンが同時に起動するように試みられるが、仮想マシン同士の依存関係を定義することも可能になっており、より確実な業務システムの復旧が可能となっている。
下図に、優先順位のレベルと仮想マシンの起動順序のイメージを示す。図7 : 優先順位のレベルと仮想マシンの起動順序のイメージ

図7 : 優先順位のレベルと仮想マシンの起動順序のイメージ

リカバリプランのテスト/実行

作成したリカバリプランによって正しく業務復旧が出来るのかどうか、当然テストする必要がある。また、災害対策においてはシステムの変更時や半期ごとなど、定期的に切り替えテストを実施し、いざという時に正しく復旧できることを確認しておくことも非常に重要である。
SRMでは作成したリカバリプランのリハーサルを行う機能を備えている。この時、本番サイトで稼働中の仮想マシンには影響を与えずにリハーサルが可能なことがSRM大きなメリットの一つと言える。
リハーサルの実施は、作成したリカバリプランを選択し、管理画面左上部の「テスト」ボタンを押すだけでよい。テストの進捗状況は管理画面上の「ステップ完了」のステータスで確認することができる。図8:リカバリプランのリハーサル実行中の進捗状況

図8:リカバリプランのリハーサル実行中の進捗状況

リハーサルの実行結果は管理画面上、およびHTMLレポートとして確認することができる。図9:リカバリプランのリハーサル実行結果、HTMLレポート

図9:リカバリプランのリハーサル実行結果、HTMLレポート

この手順はリハーサルだけでなく、実際の切り替えオペレーションとほぼ同じであり、いざという時のオペレーションに戸惑うこともないようになっている。

詳細な要件への対応

リカバリサイトにおいてネットワーク環境が違うためIPアドレスを変更したい、仮想マシンをカスタマイズしてから起動したい、といった要件に対応するためにSRMでは個別のコマンドを追加する機能を実装している。
特にIPアドレスの変更が必要となるケースは多いため、そのための機能を予め実装している。
GUIによるIPアドレス設定が可能なほか、大規模環境においてもCSVファイルで定義されたIPアドレスへの変更を一元的に行うことができるため、災対サイトで利用するネットワーク体系への対応が容易となる。

その他、個別のコマンド実行なども可能となっている。詳細は管理ガイドを参照していただきたい。

柔軟なサイト切り替えを実現する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が必須、ということにはならないと考える。

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