【VMware@SoftLayer】Site Recovery Managerで災害対策編

#前回までのあらすじ
IBMとVMwareが協業しましたね。

SoftLayer上でVMwareを使っていろいろできるかどうか確認するという趣味を持つ私としては嬉しい限りです。

前回までの詳しい流れについてはこちらの記事をご覧ください

#今回やること
VMwareのコンポーネントであるSite Recovery Manager(SRM)をSoftLayer、及びSoftLayerと接続されているオンプレミス環境に導入し、災害対策を想定したサイト切り替えを行ってみたいと思います。

#Site Recovery Managerとは
##概要
Site Recovery Managerは、災害時のシステム復旧を自動化し、迅速なサイト切り替えを実現するVMwareのソリューションです。リカバリ手順をポリシー化し、ボタン1つでポリシーに基づいて自動的にリカバリサイトに切り替えることが可能となっています。

また、テスト機能も提供されており、本番サイトに影響を与えることなく事前にリカバリのテストをすることが可能です。

保護設定の単位は、データストア、ストレージ単位だけでなく、vSphere Replicationと連動させることによって仮想マシン単位で保護することができるようになっています。今回はvSphere Replicationと連携させ、仮想マシン単位の移行を行います。

##vSphere Replicationとの違い
vSphere Replicationも仮想マシンを保護することを目的としたサイト間のレプリケーションを行うソリューションですが、SRMはvSphere Replicationと連携し、より複雑なDRプロセスを自動化することができます。

SRMには、vSphere Replicationにはない以下の特徴があります。

• テストリカバリが可能
  • vSphere Replicationではリカバリ時に仮想マシンがパワーオフになっている必要があります。
• IPアドレスの自動変更
  • vSphere Replicationではリストア後に手動で変更する必要があります。
• スクリプトの実行
  • あらかじめ作成しておいたスクリプトをリカバリ時に実行することができます。
• 仮想スイッチへの接続
  • vSphere Replicationでは接続がOFFでパワーオンされます。
• フェイルバック
  • vSphere Replicationではもう一度逆向きのレプリケーションを再構築する必要があります。

また、実際にサイトを切り替えるステップも、vSphere ReplicationとSRMでは大きな差があります。vSphere Replicationでは以下のステップで仮想マシン1台を切り替えることができます。

一方、SRMでは設定した全ての仮想マシンを以下のステップで切り替えることができます。

仮想マシンが数台ならvSphere Replicationで切り替えることもできるかもしれませんが、大規模なシステムでは一台一台切り替えて設定を変更して…を何度も繰り返すのは大変です。

SRMでは、多くの仮想マシンを一度に切り替え、設定も自動で変更してくれるすばらしいソリューションなのです。

#実装
それでは実際に環境を構築していきます。

現在の構成としては、オンプレミスのデータセンターとSoftLayerの東京DCがVPNで接続されており、それぞれのサイトにvCenterやNSXが入っています。

そこで、それぞれのサイトにSRMを構築し、オンプレミスのデータセンターにあるいくつかの仮想マシンをSoftLayer側に切り替えてみたいと思います。

##インストール
まずはをそれぞれのvCenterに仮想VMを立て、SRMをインストールします。

SRMのシステム要件は以下の通りです。(参考: Site Recovery Manager Document)

コンポーネント	要件
プロセッサ	2.0 GHz 以上の、Intel または AMD x86 プロセッサが 2 つ以上。大規模環境を管理する Site Recovery Manager のデプロイには、2.0 GHz CPU が 4 つ必要です。
メモリ	2GB（最小）。組み込みデータベースを使用する場合は、データベースのコンテンツが増大するに従ってさらにメモリが必要になることがあります。Site Recovery Manager で大規模な環境を管理する場合は、メモリ要件は増大します。
ディスクストレージ	5 GB（最小）。Site Recovery Manager を C: ドライブ以外のドライブにインストールする場合にも、Site Recovery Manager インストーラは C: ドライブに少なくとも 1 GB の空き容量を必要とします。この容量は、インストール パッケージの抽出とキャッシュに必要です。組み込みデータベースを使用する場合は、データベースのコンテンツが増大するに従ってさらにディスク容量が必要 になることがあります。
ネットワーク	Site Recovery Manager サイト間の通信には 1 ギガビットを推奨します。Site Recovery Manager のデプロイと使用、および ESXi ホストの管理には、信頼できるネットワークを使用します。

また、OSはWindowsに対応しています。
細かいバージョン、エディションはこちらをご確認ください。

上記のシステム要件、OS要件に合う仮想マシンを立てたら、次は作成した仮想マシンにインストーラをダウンロードします。

SoftLayerの場合はダウンロードページが用意されておりますので、そちらからダウンロードください。カスタマーポータルの「デバイス」→「管理」→「VMware Licenses」メニューを開き、左上の「page」を選択するとダウンロードページに飛ぶことができます。結構分かりにくいところにあります。

ダウンロードサイトからSRMのインストーラを仮想マシンにダウンロードし、実行します。

ウィザードに従って必要事項を入力し、インストールしてください。

注意点は、データベースサーバーの選択、構築です。組み込みのDBを使用する場合は問題ありませんが、あらかじめ作成したDBを利用する場合、Microsoft SQL、もしくはOracle Serverを要件に合うように構築する必要があります。ちなみに、vCenter Serverのデータベースはデータベースのスキーマ要件が異なるため、使用できません。

インストールが完了すると、登録したvCenterに「サイトリカバリ」のアイコンが追加されます。

##インストール後の設定手順
両サイトのvCneterにインストールが完了した後は、SRMの設定をしていきます。設定項目はWeb Clientで「サイトリカバリ」→「サイト」から各サイトを選択し、「サマリ」タブを見るとSRMの構成ガイドが表示されています。このガイドを見ると、現在どの項目が設定されているのかを一目で確認することができるので、このガイド通りに設定を進めていきます。なお、以下の設定は全て本番サイト上のSRMから設定しました。

##サイトのペアリング
まずは本番サイトのSRMとリカバリサイトのSRMをペアリングします。

サイトを右クリックし、「サイトのペアリング」を選択します。

リカバリサイト(ペアのサイト)のPSCアドレスやSSOの認証情報を入力し、両サイトをペアリングします。

##インベントリマッピングの構成
ここでは、「サイト切り替えを行う際に本番サイトのここからリカバリサイトのここに移す」といったマッピングを構成していきます。リソース、フォルダ、ネットワークを事前にマッピングすることができ、どこからどこに移行するかを設定することができます。

###リソースマッピング

まずは、仮想マシンのリソースをマッピングします。

オンプレミスのリソースプールからSoftLayer上のリソースプールにマッピングしました。また、同時に逆方向のマッピングも作成しておきます。

###フォルダマッピング
移行前、移行先のフォルダを指定したい場合、フォルダもマッピングします。

マッピング先フォルダを自動で作成することも可能です。

ちなみに、特にフォルダの指定がない場合はマッピングしなくてもリカバリプランは実行可能です。

###ネットワークマッピング
最後にネットワークのマッピングを行います。どのネットワークからどのネットワークに移行するのか、ポートグループ単位で指定していきます。

また、リカバリのテストの際には隔離されたポートグループが自動作成され、そのネットワークに移行されるため、安全な環境下でテストを行うことが可能です。

##プレースホルダデータストアの構成
SRMにはアレイベースの保護と仮想マシンごとの保護がありますが、いずれの場合も保護グループ内の仮想マシン用のプレースホルダ仮想マシンをリカバリサイトで作成する必要があります。ここでプレースホルダ仮想マシンとは、仮想マシンファイルのサブセットのことで、SRMはこれを利用してリカバリ先のvCenterに仮想マシンを登録します。もちろんプレースホルダ仮想マシンのファイルサイズはきわめて小さく、仮想マシンの全てのコピーではありません。

このプレースホルダ仮想マシンを置く場所として、プレースホルダデータストアを指定します。双方向の保護を行うためには。ペアの両方のサイトでプレースホルダ データストアを構成する必要があります。

ここで注意点ですが、プレースホルダデータストアには、**「アレイベースレプリケーションを使用してレプリケートされたデータストア」もしくは「vSphere Replicationのレプリケーションターゲットとして利用されているデータストア」は使用してはいけません。**再保護を実行する際に問題が発生することがあるようです。

##保護グループの作成
ここでは、実際に保護の対象とするデータストアや仮想マシンを選択します。

既にレプリケーションが構成されているデータストアや仮想マシンのみを保護グループに含めることができます。まだレプリケーションの構成ができていない場合は、ここを参考に必要なレプリケーションを構成してください。

作成した後、保護グループを選択し、「サマリ」タブなどから保護グループのステータスがOKになっていることを確認しましょう。

保護グループがうまく構成されていない場合、「関連オブジェクト」タブを選択し、仮想マシンの保護ステータス欄を見るとどの設定がうまくいっていないかが分かるようになっているので、ここを参考に構成を修正していきましょう。全ステータスの一覧はこちらにあります。

ちなみにステータスが「未構成」の仮想マシンがある場合、「全て構成」を選択すると自動で保護を構成してくれます。

##リカバリプランの作成
リカバリプランを作成し、リカバリの順序を設定します。

まずはリカバリ先サイト、保護グループ、テストネットワークを指定し、作成を完了します。

次に、仮想マシンごとのリカバリプロパティーを設定します。作成したリカバリプランを選択し、「関連オブジェクト」タブから各仮想マシンを右クリックし、「リカバリの構成」を選択すると、詳細な設定を行うことができます。

「リカバリの構成」では、仮想マシンの起動優先順位、仮想マシンの依存関係、パワーオン前後に実行するスクリプト等の設定が可能です。また、「IPカスタマイズ」では、リカバリされた仮想マシンが移行先サイトで起動される際のIPアドレスの変更ルールを指定することができます。

IPアドレスは手動でNIC毎に変更することも可能ですし、あらかじめ設定したルールに基づいて自動で構成することも可能になっております。

以上でSRMの設定は終了です。ガイドに従って順番に設定していくだけなので、間違えることなく構成できました。

#リカバリのテスト

では作成したリカバリプランをテストしたいと思います。リカバリプランを選択し、「監視」タブから「リカバリプランのテスト」をクリックするとテストを開始することができます。

また、リカバリテスト中はこの画面でどこまでリカバリが進行しているのか確認することができます。

リカバリが無事終了しました。

エラーや警告が出ている場合、「プラン履歴」タブから確認して下さい。きちんと本番サイトからリカバリサイトに移行されていることを確認した後は、「リカバリプランのクリーンアップ」をクリックするとリカバリテストを行う前の状態に戻すことができます。確認が終わったら自動で戻してくれるのはありがたいですね！！

#まとめ
今回はオンプレミスとSoftLayer上にSRMをインストールし、オンプレミスからワンクリックでリカバリサイトに仮想マシンを移行し、優先度順にパワーオンされることが確認できました。

IBMとVMwareの協業により、SoftLayer上でvSphere環境がフルスタックで利用できるようになったため、SoftLayerを利用すれば、既存のvSphere環境のDR環境が全世界に迅速に展開できるようになります。

VMwareを利用したDRは、是非IBM SoftLayerをご利用ください！！