Azure Site Recoveryを使ってオンプレミスのサーバをAzureへ移行してみた!

Azure Site Recoveryを使ってオンプレミスのサーバをAzureへ移行してみた!

(2019年7月31日掲載)

目次

皆さん、こんにちは!
Microsoft Azureの提案と導入を担当しているエキスパートSEの中山です。

今回は、オンプレミスや他のクラウドのサーバをAzureへ移行するツールとして知られているAzure Site Recoveryを試してみたいと思います。

ここで皆さんは、Windows Server 2008 および Windows Server 2008 R2 のサポートが2020年1月14日をもって終了するのをご存知でしょうか?

マイクロソフトでは、Windows Server 2008 および Windows Server 2008 R2 についてAzureに移行した場合は、さらに3年間のセキュリティアップデートを無償で提供するとアナウンスしています。そのため、諸事情により、すぐにはサーバをアップグレードできないお客さまは、サーバをAzureに移行するという選択肢もございますので、是非、Azure Site Recoveryの利用をご検討ください!

1.Azure Site Recoveryとは?

Azure Site Recovery(ASR)は本来、災害対策用のバックアップサイトをAzure上で提供する機能です。例えば、オンプレミスの物理サーバや仮想マシンのディザスタリカバリとして、災害時はAzure上でサーバをすみやかに復旧できる仕組みを提供します。これを応用して、Azure Site Recoveryはオンプレミスの物理サーバおよび仮想マシンをAzureへ移行するツールとしても活用できます。

Azure Site Recoveryには主に以下の2つの機能があります。

レプリケーション:物理サーバや仮想マシンのディスクをまるごとAzureに同期する。

フェールオーバー:Azureに同期されたディスクを使って、Azure上に仮想マシンを作成する。

2.検証環境の説明

検証は、Windows Server 2008 R2を使っているお客さまが、Azureへサーバを移行するシナリオとします。まずは、オンプレミスのサーバ(移行元サーバ)を、Azure上のサーバ(移行先サーバ)へ移行するための検証環境を用意します。

オンプレミス環境は VMware仮想基盤としますが、老朽化した環境を再現するため、バージョンは、vCenter Server 5.5 / vSphere 5.5 を使いました。

移行元サーバは、Windows Server 2008 R2 Standard 64bit SP1(Windows Updateは適用済み)がインストールされた VMware仮想マシンとします。

f:id:bw-sb-test-02:20190729155426p:plain

なお、検証環境では以下が既に完了している状態とします。

※ASRの構築自体については本記事では触れません。

  • オンプレミス環境のVMware仮想基盤の構築

  • Azure Site Recoveryのセットアップ

  • 構成サーバ兼プロセスサーバの構築(マイクロソフト社から提供されている構成サーバのOVFテンプレートをデプロイしました)

  • 構成サーバをASRへ登録

  • 移行元サーバへのモビリティサービスとAzure VMエージェントのインストール

3.検証の実施

オンプレミスのサーバをAzureへ移行するには、レプリケーションが完了した後にフェールオーバーを実施します。

f:id:bw-sb-test-02:20190730115243p:plain

3.1 事前準備

まずは移行元サーバで以下の設定を確認する必要があります。

  • リモートデスクトップの許可

  • Windowsファイアウォールの設定

Azureへ移行した後にWindowsログオンできるようにするため、リモートデスクトップの許可は必須となります。

さらに検証では、移行先サーバがping応答できるようにWindowsファイアウォールの設定を行いました。

3.2 レプリケーションの有効化

レプリケーションを行うために、ASRで移行元サーバのレプリケーションを有効にします。

AzureポータルのRecovery Services コンテナー設定画面で、「レプリケートされたアイテム」-「レプリケート」をクリックします。

(1)ソースを設定します。

移行元であるオンプレミスの情報を設定します。以下は設定例です。

f:id:bw-sb-test-02:20190729155500p:plain

(2)ターゲットを設定します。

移行先であるAzureの情報を設定します。以下は設定例です。

f:id:bw-sb-test-02:20190729155517p:plain

(3)移行元の仮想マシンを選択します。

オンプレミスにある仮想サーバの一覧が表示されますので、その中から移行元サーバを選択します。本検証では、Windows Server 2008 R2 を選択します。

f:id:bw-sb-test-02:20190729155534p:plain

(4)レプリケーションのプロパティを設定します。

ここで、移行先サーバのディスク種別(SSDやHDD)を選択します。以下は設定例です。

f:id:bw-sb-test-02:20190729155549p:plain

(5)レプリケーションポリシーを選択します。

以下は設定例です。

Windows Server 2008のレプリケーションはアプリケーション整合性復旧ポイントには対応していませんので、アプリ整合性スナップショットの頻度の設定は、[オフ(0分)] にする必要があります。

f:id:bw-sb-test-02:20190729155601p:plain

ここまで設定した後、「レプリケーションを有効にする」をクリックして、レプリケーションが完了するまで待ちます。レプリケーションが完了すると、状態が「プロテクト」になり、いつでもフェールオーバーできます。

f:id:bw-sb-test-02:20190729155619p:plain

3.3 フェールオーバーの実施

フェールオーバーの実施にあたり、移行先サーバについて仮想マシンの設定を行います。以下が設定可能な項目です。

  • 仮想マシン名(コンピューター名ではありません)

  • リソースグループ

  • 仮想マシンのサイズ

  • 可用性セットの有無

  • 接続先の仮想ネットワークとサブネット

  • ネットワークインターフェイスのIPアドレス設定

f:id:bw-sb-test-02:20190729155633p:plain

仮想マシンのサイズについては、移行元サーバはvCPUが2コア、メモリが4GBなので、デフォルトで Standard_A2_v2 になっていました。これをBやDシリーズなどに変更可能です。

それではフェールオーバーを行ってみましょう。

フェールオーバーの手順は、下記画面の「フェールオーバー」をクリックして、復旧ポイントを指定するだけです。本検証では、テストフェールオーバーで行いました。

フェールオーバーを実行すると、数分で仮想マシンが作成されました。この仮想マシンが移行先サーバです。

f:id:bw-sb-test-02:20190729155644p:plain

3.4 事後作業

フェールオーバー後は、移行先サーバに対する事後作業が必要です。思いつくものとして以下があります。

  • NTPサーバの設定、時刻合わせ

  • モビリティサービスのアンインストール

  • VMware Toolsのアンインストール

    ※フェールオーバー後にVMToolsのサービスは無効になっていましたが、念のため。

  • ページファイルの場所を一時ディスクへ変更

  • ネットワークセキュリティグループの設定

  • パブリックIPアドレスの付与(必要であれば)

4.検証結果

4.1 ネットワークアクセス

Azure上の疎通確認用サーバを使って、移行先サーバへのpingおよびリモートデスクトップ接続(RDP)を行ってみます。

f:id:bw-sb-test-02:20190729155659p:plain

ここで、移行元サーバのネットワーク設定情報は以下の通り、スタティック設定としています。

IPアドレス:192.168.209.210

サブネットマスク:255.255.255.240

デフォルトゲートウェイ:192.168.209.209

優先DNSサーバー:192.168.209.194

代替DNSサーバー:インターネット上のリゾルバサーバ

ネットワークアダプタ:VMXNET3

Azureへの移行にあたり、Azure側ネットワークと移行先サーバの設定を下記の4パターンで試したところ、全てのパターンでpingとリモートデスクトップ接続(RDP)ともにネットワークアクセスができました。

ただし、フェールオーバー後にネットワークアクセスできるまでに数分かかりました。

いずれのパターンにおいても、移行先サーバのOS上のネットワークプロパティ設定は「DHCP」になっており、ネットワークアダプタは「Microsoft Hyper-V Network Adapter」ではなく、「Microsoft Virtual Machine バス ネットワーク アダプター」になっていました。

f:id:bw-sb-test-02:20190729155715p:plain

※1 移行元サーバと同一のIPアドレス(192.168.209.210)をスタティックで設定しようとしたところエラーになりました。理由としては、Azureではホストアドレスの若番4番目からしか設定できないためです。

4.2 ディスク構成

Azureへの移行にあたり、ディスク構成では以下の2点が重要です。

  • データディスクのドライブレターが変わっていないこと

  • Azureの一時ディスクが空きドライブレターに割り当てられていること

移行先サーバでデータディスクのドライブレターが変わってしまうと、インストールされているアプリケーションに影響が出てしまいます。

また、Azureの仮想マシンには一時ディスクが存在し、デフォルトはDドライブになっています。一時ディスクは仮想マシンが停止したときに中身のデータが消失しますので、データディスクとしては使えません。

そこで、移行元サーバのディスク構成をいくつか変えて、移行先サーバのディスク構成をOS上で確認してみました。結果は以下の通りです。

f:id:bw-sb-test-02:20190729155730p:plain

f:id:bw-sb-test-02:20190729155740p:plain

f:id:bw-sb-test-02:20190729155831p:plain

どのパターンでも、データディスクのドライブレターは変わらず、一時ディスクのドライブレターは空きのドライブレターがうまく割り当てられました。

5.まとめ

ASRはフェールオーバーが簡単にでき、ネットワーク接続やディスク構成ともうまく移行先の状態に合わせてくれるため、使い勝手がよく、便利なツールだと思いました。

ただし、移行元サーバと移行先サーバではMACアドレスは変更になりますのでご注意ください。

実際の移行にあたっては、十分なアプリケーション動作確認が必要かと思いますが、ASRはAzureへの移行において有効なツールとなりますので、機会があれば是非試してみてください。

それでは、また!

あわせて読みたい関連記事

◾︎de:code 2019で明らかになったWindows Virtual Desktopの全貌!

◾︎Azure AD のセルフサービスパスワードリセットを試してみた!実施編

◾︎Azure AD のセルフサービスパスワードリセットを試してみた!準備編