Azure Site Recoveryの注目の新機能、Azure―Azure間で仮想マシンのレプリケーション保護が可能に：Microsoft Azure最新機能フォローアップ（33）（2/2 ページ）

やってみて分かる、その“簡単さ”

　ここからは、東日本リージョンで実行中の1台の仮想マシン（前出の画面1）を、別のリージョンにレプリケーションし、テストフェイルオーバーを実行するまでをレポートします。

　既に作成済みのRecovery Servicesコンテナがある場合は、そのコンテナでパブリックプレビュー機能を利用できます。まだ作成していない場合は、Azureポータルの左下にある「More services」をクリックして「Recovery Servicesコンテナ」ブレードを開き、新しいコンテナを作成します。コンテナの準備ができたら、「概要」ブレードの「＋レプリケート」をクリックし、「レプリケーションを有効にする」の「1 ソース」でソース「Azure - プレビュー」を選択して、保護対象の仮想マシンが存在するリージョン（ソースの場所）、デプロイモデル、リソースグループを指定します（画面2）。

画面2　ソースとして新しいシナリオ「Azure - プレビュー」を選択し、Azure仮想マシンのあるリージョンとデプロイモデル、リソースグループを指定する（クリックで拡大）

　「レプリケーションを有効にする」の「2 仮想マシン」に移動し、指定したリソースグループから検索された保護対象にできる仮想マシンがリストされます。ここで、保護対象にする仮想マシンを選択します（画面3）。

画面3　指定したリソースグループが検索され、保護対象にできる仮想マシンがリストされるので、選択する（クリックで拡大）

　「レプリケーションを有効にする」の「3 Settings」に移動するので、ターゲットの場所としてレプリケーション先のAzureリージョンを選択します（画面4）。「ターゲットリソースの作成」をクリックすると、保護対象のリソースグループ、仮想ネットワーク、ストレージアカウントなどに対応したリソースが作成されます（作成されるリソースの名前には「asr」が付く）。

画面4　レプリケーション先となるAzureのリージョンを選択し、「ターゲットリソースの作成」をクリックして、しばらく待つ（クリックで拡大）

　日本のユーザーであれば、「東日本」から「西日本」へレプリケーションしたいと考えると思いますが、筆者は理由があって「東南アジア」を選択しました。その理由は、筆者が最近サインアップしたAzureの1カ月無料試用版は、「西日本」リージョンへの仮想マシンの作成が許可されていなかったからです（これが最初のトライの失敗の理由です）。

　しばらく待つと（数分もかかりません）、「レプリケーションを有効にする」の全ての手順が完了済みとなり（レ点が付く）、「レプリケーションを有効にする」ボタンがクリックできるようになります（画面5）。

画面5　「レプリケーションを有効にする」ボタンをクリックしてレプリケーションを有効化すると、必要な構成が行われ、初期同期がスタートする（クリックで拡大）

　「レプリケーションを有効にする」ボタンをクリックすると、仮想マシンのレプリケーションが有効化され、初期同期がスタートします。その状態は、Recovery Servicesコンテナの「保護されたアイテム｜レプリケートされたアイテム」で確認できます（画面6）。

画面6　「ターゲットリソースの作成」をクリックしたときに準備された東南アジアリージョンのストレージアカウントにVHDが複製、同期される

　レプリケーションが有効になると、「ターゲットリソースの作成」で準備されたリソースグループ内のストレージアカウントに保護対象の仮想マシンのVHDのレプリカが作成され、VHDの内容が転送されます。「レプリケートされたアイテム」でアイテムをさらに開くと、マップ上でレプリケーション元とレプリケーション先の位置関係を視覚的に把握できます（画面7）。「東日本」から「西日本」へのレプリケーションの場合、このマップ上では近すぎて面白みに欠けるかもしれません。

画面7　マップ上でレプリケーションの関係が視覚化されている。青のアイコンがレプリケーション元の東日本リージョンで、破線でつながる緑のアイコンがレプリケーション先の東南アジアリージョン

　初期同期は1時間半ほどで完了し、レプリケーションの状態が「Protected」に変わりました。なお、この時点ではレプリケーション先に仮想マシンは存在しません。レプリケーションされるのは、仮想マシンのVHDだけであり、仮想マシンはフェイルオーバー実行時に初めて作成されることになります。

テストフェイルオーバーを試してみた

　レプリケーションパラメーターの構成や、ネットワークのマッピングがどうなっているのかなど、細かい構成については、本稿では説明を省略します。オンプレミスのHyper-VホストからAzureへのレプリケーションを利用したことがあれば、同じように構成、管理できると思います。クラウドだけで完結するので、オンプレミスとのシナリオよりも、ずっと簡単ということも分かるでしょう。サイト間VPN接続やExpressRoute接続（サポートされています）によるオンプレミスとの接続はフェイルオーバー時にどうなるのかなど、気になる点は幾つかあると思いますが、導入を考えているのならその辺りを含めて検証してみてください。

　AzureはSLA（Service Level Agreement）に基づいて高い稼働率が見込めます。そのため、フェイルオーバーする機会はあまりないかもしれませが、仮にリージョン全体がダウンしたとき、これまではリージョンの復旧を祈りながら待つしかありませんでした。

　Azure Site Recoveryのこの新機能を利用すれば、リージョン全体の障害発生時にも、そのリージョンの復旧を待たずに、レプリカを使って別のリージョンで素早く復旧できるはずです。レプリケーション元とレプリケーション先が同じAzure仮想マシンであり、仮想ネットワークやサブネットも同じ構成です。従来のオンプレミスのサイト間やオンプレミスとAzure間のシナリオよりも、確実にフェイルオーバーを実行できるのではないでしょうか。

　従来のシナリオと同様、テストフェイルオーバーの機能も用意されているので、実行中の仮想マシンに影響を与えることなく、フェイルオーバーを試してみることもできます。テストフェイルオーバーを実行するには、「レプリケートされたアイテム」から「アイテム」を選択し、最新または過去の復旧ポイントを選択するだけです（画面8）。

画面8　復旧ポイントを選択し、テストフェイルオーバーを実行する

　レプリケーション先のリージョンにテスト用の仮想マシンが自動的にデプロイされ、数分で実行中の状態になります（画面9）。なお、テストフェイルオーバーの動作を確認したら、「レプリケートされたアイテム」でアイテムの「…」メニューから「テストフェイルオーバーのクリーンアップ」を実行することを忘れずにしてください。

画面9　レプリケーション先の東南アジアリージョンにテスト用仮想マシン（仮想マシン名に-testが付く）がデプロイされ、数分で実行中の状態になる