◆初めに
本文書では｢Azure｣の｢Site Recovery｣について書いていきます。
内容はAzureからAzureへの移行方法です。
ソースマシンにPHPを仕込み、移行後のリカバリされたマシンでPHPまで表示ができるかどうかってこととその環境までもっていくのに何が必要になるのかを書いていきます
■どんな時に使えるか…
災対になります。例えば東日本に本番環境を配置しておくシステムがあったとして
そのリソースを格納しているデータセンターが災害等で使えなくなった時にこの技術
を使ってスムーズに西日本などの問題ないデータセンターに移行させるって感じです
■ターゲット
｢東日本｣に存在するAzureVMを｢西日本｣に移行する。またサーバの持つ機能も確認したい為、phpを導入しておきます。
つまり、移行作業が終わった後webの確認をし問題なく表示されている事が条件になります。
■レプリケート対象
・(東日本)Azure VM ⇒ (西日本)Azure VM
・仮想NIC
■基本的な環境
以下の画像みたいな感じで、東日本リージョンにVMとリソースグループを配置し、西日本にはリカバリ先となるリソースグループと仮想ネットワークを配置します。
また今回のメインとなる｢Recovery Site container(以下コンテナ)｣も西日本に配置します。
【環境構成】
■作業の流れ
大きく言えば今回の作業は4つのプロセスに別れるかなと思います
【0】.事前環境構築
今回はテスト構築なので東日本リージョンを本番、西日本リージョンを災対環境とします。
【1】.Recovery Services container作成
バックアップ/リストアやフェールオーバーなどの機能を所有しています。｢Recovery Services container｣を作成することで今回のリージョン移行を行います
【2】.レプリケーションアイテムの有効化
コンテナを作成した後は作成したコンテナにレプリケーションするアイテムを登録します。このアイテムには今回のソースマシンの情報を登録しスケジュールでレプリケーションを行います。
【3】.テストフェールオーバー
フェールオーバー前の試験として削除可能なAzureVMを作成したレプリケーションアイテムよりフェールオーバーします。この時点ではソースマシンに手を付けることがないためソースマシンとリカバリマシンが同時起動する状態になります。なのでテスト終了後は削除されます
【4】.フェールオーバー
テストフェールオーバーが成功したレプリケーションアイテムでフェールオーバーを行います。これはテストではない為実行後はソースマシンはシャットダウンされた状態になります。
【環境構成表】
・今回の作業範囲は｢コンテナ｣になりますので上記で記載している赤文字以外のリソースは すべて事前作成しているものとします。
| リソース名 | 東日本 | 西日本 |
|---|---|---|
| リソースグループ | East-RG | 作成 |
| 仮想マシン | East-VM01 | 移行可能 |
| 仮想NIC | East-VM01 | 移行可能 |
| PublicIP | East-VM01 | 作成 |
| 仮想ネットワーク | East-VNET01 (10.0.0.0/24) |
作成 |
| サブネット | East-Sub01 | 作成 |
| NSG | East-nsg01 | 作成 |
| Recovery Services container | なし | 作成(East-BKCON) |
【0】.事前環境構築
<<東日本リソースグループ>>
<<ソースマシンWEB>>
<<西日本リソースグループ>>
【1】.Recovery Services container作成
ソースマシンをレプリケーションするためのコンテナを作成します。これは｢Backup Container｣といい、｢Azure Backup｣と[Azure Site Recovery]の管理コンソール的な役割を持っています。またソースマシンのバックアップイメージやレプリケートアイテムもコンテナで管理しています。
気を付けないといけないのはリカバリマシンを格納するリージョンに配置することです。今回は東日本が仮想本番環境なので西日本に仮想災対環境にしています。
【手順】
1.[Azure Portal]へログインして[+新規]をクリック
2.[Backup and Site Recovery (OMS)]を選択し[作成]をクリック
3.以下の項目を入力し[作成]をクリック
| No | リソース名 | 入力値 |
|---|---|---|
| 1 | 名前 | East-BKCON |
| 2 | サブスクリプション | ??? |
| 3 | リソースグループ | West-RG |
| 4 | 場所 | 西日本 |
<<意味>>
名前：作成する｢コンテナ｣の名前
サブスクリプション：サブスクリプションの指定
リソースグループ：コンテナを作成するリソースグループを指定
場所：リソースグループの場所
4.リソースグループ[West-RG]を表示させ[East-BKCON]をクリック
※現時点で[コンテナ]の作成は終わりましたが次のバックアップ対象のレプリケーションを有効化する為、作業は継続になります。
【2】.レプリケーションアイテムの有効化
作成した[コンテナ]にソースマシンのレプリケーション設定を行います。この作業を行うことで[コンテナ]はソースマシンを認識しレプリケーション対象として保護します。
【手順】
1.[East-BKCON]から[+レプリケート]をクリック
2.[ソース]にて以下の項目を入力
| No | リソース名 | 入力値 |
|---|---|---|
| 1 | ソース | Azure - プレビュー |
| 2 | ソースの場所 | 東日本 |
| 3 | Auzre 仮想マシンのデプロイモデル | リソースマネージャ（デフォルト） |
| 4 | ソースリソースグループ | East-RG |
<<意味>>
ソース：レプリケーション対象（Azureかオンプレミスか）
ソースの場所：ソースマシンのあるリージョン
Auzre 仮想マシンのデプロイモデル ： デプロイモデル（デフォルトのまま）
ソースリソースグループ：ソースマシンの存在するリソースグループを指定
3.[仮想マシンの選択]で表示された[East-VM01]を選択し[OK]をクリック
※複数のマシンの場合はソースマシンの台数分選択します。
4.[設定の構成]にて[ターゲットの場所]を西日本に指定し[カスタマイズ]をクリック
con8.png
5.[ターゲットの設定のカスタマイズ]画面で以下の設定を行い、[OK]をクリック
・ターゲットリソースグループ West-RG レプリケート先のリソースグループを指定
・ターゲット仮想ネットワーク West-VNET01 レプリケート先の仮想ネットワークを指定
※VM設定はデフォルト指定で行っていますが指定することもできます。やらなくてもできるので今回は割愛です。
con9.png
6.[設定の構成]にて[ターゲットリソースの作成]をクリック
※[デプロイ]が始まるので静観します
7.[レプリケーションを有効にする]にて[レプリケーションを有効にする]をクリック
[有効化]が始まるので[手順6]同様に終わるまで静観します
8.[コンテナ]画面から｢レプリケートされたアイテム｣をクリックする
※1.下記画像の[状態]を確認し作業状態を確認する
※2.[状態]が[保護済み]に代わるまで静観すること（レプリケーション有効後、初回の保護が始まります）
※3.レプリケーションアイテムが[保護済み]に変わらない限り次の作業ができません
<<※2 有効化処理中画面>>
現時点では次の作業はまだできていない段階になります。
<<※2 有効化処理終了画面>>
状態が[保護済み]になればレプリケーション終了になります。
【3】.テストフェールオーバー
現時点でようやくフェールオーバーの環境が整いました。本章ではレプリケートアイテムを使用して西日本環境(West-RG)へソースマシンを移行させます。
｢テストフェールオーバー｣と｢フェールオーバー｣の違いは｢テストフェールオーバー｣時は作業終了後｢クリーンアップ｣でフェールオーバー後のマシン（リカバリマシン）を削除しますが、｢フェールオーバー｣は削除しないという事になります。ただ｢テストフェールオーバー」はソースマシンには手を付けません。
【手順】
1.[コンテナ]画面から[レプリケートされたアイテム]を選択
2.ソースマシン[East-VM01]を選択
3.[テストフェールオーバー]を選択
4.[フェールオーバーの方向]にて以下を選択しOKをクリック
・復旧ポイント：最新のアプリ整合性 リストアするポイント
・Azure 仮想ネットワーク： West-VNET01
| No | 項目 | 入力値 |
|---|---|---|
| 1 | 復旧ポイント | 最新のアプリ整合性(YYYYMMDD HH:MM) |
| 2 | 仮想ネットワーク | West-VNET01 |
| ※仮想ネットワークで選択した箇所にフェールオーバーされます。 |
5.画面上に以下の画面が出てくるので赤枠内のリンクをクリック
6.[テストフェールオーバー]画面を静観しすべての項目が[成功]すること確認する
<<手順６．初期画面>>
<<手順６．終了画面>>
7.リソースグループ[West-RG]を表示させリソースグループ内リソースに以下の3つのリソースが追加されていることを確認する
・AzureVM：East-VM01-test(※)
・仮想NIC：East-VM01-testxxxxxxxxxx
※テストフェールオーバーの際は仮想マシンの最後に｢-test｣と表記されます
■テストフェールオーバー終了後確認
テストフェールオーバーにより仮想マシンは無事｢West-RG｣に移行することが出来ましたが、現段階ではマシンが移動しただけです。ここからは手作業で従来の環境に合わせます。
移行できるリソース
・Azure VM
・仮想NIC
移行できないリソース
これらのリソースはフェールオーバー前に事前に作成し、後程手作業で関連付けを行います。
・PublicIP
・VNET/SUBNET
・NSG
■起動確認
リカバリマシンにソースマシンの持っていた機能(PHP)を移行できているかを確認します。ソースマシンの方ではPHPを稼働させていましたのでフェールオーバーが問題なければリカバリマシンでもPHPの表示ができる筈です。
前提 ： PublicIPの付与
<<リカバリマシンの環境>>
⇒hostnameがありません。。。
<<ブラウザでの確認>>
以下のURLにアクセス
http://publicip/index.php
ホストネームは移行前のものが記載されています([-test]がついていません)
<<実際にログイン>>
ホストネームはWEBと同様にソースマシンの名前を示していました！
結論 ：
マシンのリージョン移行を行ったときに引き継がれるのはマシンとNICのみで他のリソースは移行されない。本番の時はチェック必須！
ちなみにこの後は[コンテナアイテム]画面から｢テストフェールオーバーのクリーンアップ｣を行いリカバリマシンの方は削除しています。
【4】.フェールオーバー
上記でフェールオーバーの試験を行いとりあえずのリージョン移行は確認できましたので、次はいよいよガチのフェールオーバーをします。現時点で筆者が気になっているのはソース元と同じだったhostnameと移行後のソースマシンの挙動になります。
【手順】
1.[コンテナ]画面から[レプリケートされたアイテム]を選択
2.ソースマシン[East-VM01]を選択
3.[フェールオーバー]を選択
4.[フェールオーバー]にて以下を選択しOKをクリック
・復旧ポイント：最新のアプリ整合性 リストアするポイント
・Azure 仮想ネットワーク： West-VNET01
・フェールオーバーを開始する前にマシンをシャットダウンします：チェック（デフォルト）
| No | 項目 | 入力値 |
|---|---|---|
| 1 | 復旧ポイント | 最新のアプリ整合性(YYYYMMDD HH:MM) |
| 2 | 仮想ネットワーク | West-VNET01 |
5.以降は[テストフェールオーバー]時と同様に終わるまで静観
6.フェールオーバー終了
7.ソースマシンの確認
※シャットダウンされているかどうか？
⇒停止していました。
8.リカバリマシン確認
※テストフェールオーバー時と差分はなし
⇒コンピュータ名記載なし
⇒PublicIPは付与されていない
9.｢PublicIP｣を付与してWebを確認
※テストフェールオーバー時と差分はなし
10.フェールオーバー完了
◆最後に
ここまで読んで頂きありがとうございます。今回はAzure環境内でリージョンをまたいでの移行方法を書きました。実際のところ｢AzuruからAzure｣の移行はまだプレビュー段階なので今後、仕様が変わる可能性もあるかなと思っています。
でもとりあえず災対環境を作るって考えると事前のリソース作成は必要ですが、スムーズに災対環境への移行がこの｢Site Recovery｣は使えるかなって思います。
今後はもう一つのレプリケート対象である[オンプレミス]から[Azure]をやってみようかと思います。Az⇒Azがプレビューなのにオンプレ⇒Azがプレビューじゃないところを見るとたぶんこっちが本命だと思います。