Azure Site Recovery で Active Directory のDR 環境を構築する｜技術ブログ

2022.09.30

はじめに

今回は、Azure Site Recoveryで、Active Directory Domain ServicesのDisaster Recoveryサイトの構築をご紹介させていただきます。
Azure Site RecoveryでDisaster Recovery構成が取れることは理解していたのですが、Active Directory Domain Servicesでもその構成が取れるのかという疑問からこの記事を書こうと考えておりました。
しかし、実際に構築してみるとこの疑問はすぐに解消されました。なので、Azure Site Recoveryの設定を既定値のままならどんな手順になるのか、またその構築における気づきやポイントなどを書かせて頂くことにしました。
ところで、ここではAzure Site Recoveryの要件等に関しては触れておりません。実際に構築を実施される場合は、以下のサイト等で確認されることをおすすめします。
「Azure リージョン間での Azure VM ディザスターリカバリーに関するサポートマトリックス」
https://learn.microsoft.com/ja-jp/azure/site-recovery/azure-to-azure-support-matrix

この記事に関して

以降、次の略称を用いて記載します。

Azure上の仮想マシンでリージョン間のDRの構成を行いました。
DRを構成したリージョンは、East USとWest US リージョンです。
1台の仮想マシンをドメインコントローラーに昇格し、AD DSを作成しました。
この1台のドメインコントローラーを用いて、AD DSのDRを確認しました。
AD DSの正常性は(※)診断コマンドを実行しその結果で判定しております。
動作確認のための仮想マシンへの接続は、Azure Bastionを使用しました。ただし、Azure Bastion自体の説明はこの記事では省略しております。
画面は、2022年9月時点のものとなります。

ipconfig /all

hostname

net share

dcdiag /v

https://social.technet.microsoft.com/Forums/ja-JP/d995fdc0-0036-48f0-9adf-302c2104886e/

構築環境に関して

以下、構築した環境の説明用に作成した図となります。リージョン名、仮想マシン名、リソースグループ名、および、ASRが自動的に付けたリソースグループ名を記載しております。手順では手動のフェールオーバーを実施しておりますが、リージョンで障害が起きた場合の想定です。フェールバックに関しては検証の実施はしておりますが、この記事には起こしておりません。

ご参考までにですが、レプリケーションとDRのそれぞれの観点からの補足の図も貼っておきます。

フェールオーバー手順の概要

まずは、フェールオーバー前にAD DSが正常に機能している事の確認のため、プライマリサイトのドメインコントローラーに接続しコマンドプロンプトで上記の(※)のコマンドを実行します。

「ipconfig /all」の実行結果例

「hostname」の実行結果例

「net share」の実行結果例

「dcdiag /v」の実行結果例

「dcdiag /v | find "........"」の実行結果例

以降の作業は、Azure Portal (https://portal.azure.com)にサインインして行います。
(1)【 Virtual Machine 】を選んだ後、仮想マシンの一覧から対象の (2)【仮想マシン(例では dc01) 】をクリックします。
そして、設定から (3)【ディザスターリカバリー】をクリックします。

レプリケーション先である (4)【ターゲットリージョン(例では west us リージョン) 】を選択し、 (5)【次へ：詳細設定】 をクリックします。

設定内容は変更せずに既定値のままにして、 (6)【次へ：レプリケーションを確認して開始する】 をクリックします。

画面の確認だけ行い、 (7)【レプリケーションの開始】をクリックします。

しばらくするとレプリケーションが完了となります。次に同期の (8)【状態】がプロテクトになるまで待ちます。

(9)【状態】がプロテクトになるまで待ちます。

(10)【状態】がプロテクトになるまで待ちます。

(11)【状態】がプロテクトになったら、 (12)【テストフェールオーバー】 や (13)【フェールオーバー】が選択可能となります。
この記事ではテストフェールオーバーを省略して (13)【フェールオーバー】を実行しております。テストフェールオーバーで動作確認してから、フェールオーバーを実行することが推奨となっております。

しばらくすると (14)【状態】がフェールオーバー完了となります。

フェールオーバーの完了後、復旧ポイントの変更が可能です。別のタイミングで取得した世代のレプリケーションの状態に変更する場合は、 (15)【復旧ポイントの変更】をクリックすれば変更できます。

復旧ポイントの変更で、(16)【別の世代を選んだ場合】 の画面となります。

選んだ復旧ポイントに変更した状態で、仮想マシンに接続しAD DSの正常性を(※)コマンドで確認します。
正常性の確認が取れれば (17)【コミット】を行うことで、フェールオーバー全体の作業が完了となります。

ASRに関しての補足

ASRの設定後について

ASR設定直後では、同期の状態が完了するまでフェールオーバーの実行はできません。
テストフェールオーバーの実行は省略可能ですが、実行することが推奨されています。

【テストフェールオーバーをしていない時の注意喚起の画面】

フェールオーバー時、復旧ポイントのオプションを選択できます。

この記事では、アプリ整合性の復旧ポイントを指定しております。

【復旧ポイントを選択する画面】

【復旧ポイントのオプションを選択する画面】

フェールバックも同じメニューの中にあります。

項目名としては少しわかりにくいですが、再保護が該当します。

【メニューの中の再保護(フェールバック) 】

テストフェールオーバーの仮想マシンの表示名

テストフェールオーバーを実行すると、テストフェールオーバー先の仮想マシンの表示名がASRによって変更されます。末尾に【 -test 】が付き、今回の環境ならば【 dc01-test 】となります。ただし、変更は表示名のみで実際のコンピュータ名は変更されておりません。

フェールオーバー後の最初の仮想マシンへのログイン

フェールオーバー後、最初の仮想マシンへのログインでは「予期せずシャットダウンされた・・」のダイアログが表示されますが、こちらは仕様となります。

【表示されるダイアログ】

まとめ

クラウド以前の時代にはAD DSのDRサイトと言えば、設計や運用にとても工数が掛かり苦労した経験しか記憶にありません。今回実際にASRを構築してみて分かった事ではありますが、運用環境に対しても負荷も掛からない、しかもテストフェールオーバーの環境まで準備されているようなシステムがAzureのサービスに存在することを再認識させていただきました。
この記事ではASRを使えば、AD DSのDRサイトが簡単に作成できることを示しました。しかもASRの設定は既定値のままでDRサイトが作れてしまう点はとても評価できると感じました。また、繰り返しにはなりますが、本番のフェールオーバーとは別にテストフェールオーバーが出来る設定が標準で準備されているところもASRの高評価になるポイントと思います。
今回のASRは既定の設定のため、フェールオーバー先のリソースグループ名や仮想ネットワーク名もシステムの命名規則で自動的に振られました。設定を既定値にせず、フェールオーバー先にリソースグループや仮想ネットワークを事前に作成することで任意の名称を付ける事も可能です。
対象に仮想マシンが複数ある場合や、もっときめ細かな設定が行いたい場合は、AzureのサービスにあるRecovery Services コンテナーが対応できるようです。また別の機会に、そのサービスを使って複数台のドメインコントローラーでAD DSのDRサイトの構築なども試して見たいと考えております。

他のおすすめ記事はこちら

Azure AD Connect の備忘録

著者紹介

SB C&S株式会社
ICT事業本部技術本部第1技術部 4課
光永正明

Azure Site Recovery で Active Directory のDR 環境を構築する