DAG ミラーリング監視サーバーとしての Microsoft Azure VM の使用
製品: Exchange Server 2013
Exchange Server 2013 では、データセンターの自動フェールオーバーのためのデータベース可用性グループ (DAG) にあるメールボックス データベースの構成が可能です。 この構成では、次の 3 つの物理的な場所 (メールボックス サーバー用の 2 つのデータセンターと、DAG のミラーリング監視サーバーを配置する第 3 の場所) が別個に必要です。 現在 2 つの物理的な場所のみがある組織は、DAG のミラーリング監視サーバーの役割をする Microsoft Azure ファイル サーバーの仮想マシンを使用して、データセンターの自動フェールオーバーを活用することもできます。
この記事では、Microsoft Azure での DAG 監視の配置に焦点を当て、サイトの回復性の概念に精通しており、既に 2 つのデータセンターにまたがる完全に機能する DAG インフラストラクチャがあることを前提としています。 DAG インフラストラクチャがまだ構成されていない場合は、最初に次の記事を確認することをお勧めします。
Microsoft Azure への変更
この構成では、複数サイト VPN が必要です。 サイト間の VPN 接続を使用して、組織のネットワークを Microsoft Azure に接続することは常に可能です。 ただし、以前、Azure は 1 つのサイト間 VPN のみをサポートしていました。 3 つのデータセンター全体に DAG とそのミラーリング監視を構成するには複数のサイト間 VPN が必要であったため、Azure 仮想マシンでの DAG ミラーリング監視の配置は最初は不可能でした。
2014 年 6 月、組織が複数のデータセンターを 1 つの Azure 仮想ネットワークに接続できるようにする、複数サイト VPN のサポートが Microsoft Azure に導入されました。 この変更により、2 つのデータセンターを持つ組織が、DAG 監視サーバーを配置するために Microsoft Azure を 3 番目の場所として使用することも可能になりました。 Azure での複数サイト VPN 機能の詳細については、「複数サイト VPN の構成」を参照してください。
注:
この構成では、監視サーバーをデプロイするために Azure 仮想マシンとマルチサイト VPN が使用され、Azure Cloud Witness は使用されません。
Microsoft Azure ファイル サーバーのミラーリング監視
次の図は、DAG のミラーリング監視としての Microsoft Azure ファイル サーバーの使用の概要です。 Azure 仮想ネットワーク、データセンターを Azure 仮想ネットワークに接続する複数サイト VPN、および Azure 仮想マシンに展開されたドメイン コントローラーとファイル サーバーが必要です。
注:
1 つの Azure 仮想マシンを DAG のミラーリング監視の目的に使用し、ファイルのミラーリング監視共有をドメイン コントローラーに配置することは、技術的に可能です。 ただし、この構成により、不要な特権の昇格が発生します。 そのため、1 つの Azure VM をお勧めします。
Microsoft Azure での DAG ミラーリング監視サーバー
.png "Azure での Exchange DAG 監視の概要")
Microsoft Azure 仮想マシンを DAG のミラーリング監視に使用するために最初に必要なことは、サブスクリプションの取得です。 Azure サブスクリプションを取得する最善の方法については、「Azure の購入方法」を参照してください。
Azure サブスクリプションを作成したら、次の手順を順番に実行する必要があります。
- Microsoft Azure 仮想ネットワークを準備する
- 複数サイト VPN を構成する
- 仮想マシンを構成する
- DAG のミラーリング監視を構成する
注:
この記事におけるガイダンスの大部分は Microsoft Azure の構成に関することです。 したがって、該当する箇所には Azure ドキュメントへのリンクが使用されます。
前提条件
Exchange の高可用性とサイト復元の展開をサポートできる 2 つのデータセンター。 詳細については、「 高可用性とサイトの回復性の計画」を参照してください。
各サイトの VPN ゲートウェイの NAT の背後にないパブリック IP アドレス
Microsoft Azure と互換性がある各サイト内の VPN デバイス。 互換性のあるデバイスの詳細については、「サイト間VPN Gateway接続の VPN デバイスと IPsec/IKE パラメーターについて」を参照してください。
DAG の概念と管理に精通していること
Windows PowerShell に精通していること
フェーズ 1: Microsoft Azure 仮想ネットワークを準備する
Microsoft Azure ネットワークの構成は、展開プロセスの最も重要な部分です。 このフェーズの最後には、マルチサイト VPN を介して 2 つのデータセンターに接続されている、完全に機能する Azure 仮想ネットワークがあります。
DNS サーバーを登録する
この構成では、オンプレミス サーバーと Azure VM 間の名前解決が必要であるため、独自の DNS サーバーを使用するように Azure を構成する必要があります。 Azure 仮想ネットワークのリソースの名前解決に関する 記事では、Azure での名前解決の概要について説明します。
DNS サーバーを登録するには、次のようにします。
Azure portalで、[ネットワーク] に移動し、[新規] を選択します。
[ NETWORK SERVICES>VIRTUAL NETWORK>REGISTER DNS SERVER] を選択します。
DNS サーバーの名前と IP アドレスを入力します。 名前は管理ポータルで使用される論理名であり、DNS サーバーの実際の名前と一致する必要はありません。
他に追加する DNS サーバーがある場合は、手順 1 ～ 3 を繰り返します。
注:
登録する DNS サーバーは、ラウンド ロビン方式では使用されません。 Azure VM では、一覧表示されている最初の DNS サーバーが使用され、最初の DNS サーバーが使用できない場合にのみ追加のサーバーが使用されます。
手順 1 ~ 3 を繰り返して、Microsoft Azure のドメイン コントローラーに使用する IP アドレスを追加します。
Azure にローカル (オンプレミス) ネットワーク オブジェクトを作成する
次に、以下を実行して Microsoft Azure でのデータセンターを表す論理ネットワーク オブジェクトを作成します。
Azure portalで、[ネットワーク] に移動し、[新規] を選択します。
[ネットワーク サービス>] [仮想ネットワーク][ローカル ネットワーク>の追加] の順に選択します。
最初のデータセンターのサイト名と、そのサイトの VPN デバイスの IP アドレスを入力します。 この IP アドレスは、NAT の背後にない静的パブリック IP アドレスである必要があります。
次の画面で、最初のサイトの IP サブネットを指定します。
2 つ目のサイトに対して手順 1 から 4 を再パターン化します。
Azure 仮想ネットワークを作成する
次の手順を実行して、VM によって使用される Azure 仮想ネットワークを作成します。
Azure portalで、[ネットワーク] に移動し、[新規] を選択します。
[ NETWORK SERVICES>VIRTUAL NETWORK>CUSTOM CREATE] を選択します。
[仮想ネットワークの詳細] ページで、仮想ネットワークの名前を指定してから、ネットワークの地理的な場所を選択します。
[DNS サーバーと VPN 接続] ページで、既に登録した DNS サーバーが DNS サーバーとして一覧表示されることを確認します。
[サイト間接続] の下で、 [サイト間 VPN の構成] チェック ボックスを選択します。
重要
この設定では、マルチサイト VPN の設定に必要な構成の変更が防止されるため、[ ExpressRoute の使用] を選択しないでください。
[ローカル ネットワーク] で、構成した 2 つのオンプレミス ネットワークのいずれかを選択します。
[Virtual Network アドレス空間] ページで、Azure 仮想ネットワークに使用する IP アドレス範囲を指定します。
チェックポイント: ネットワーク構成の確認
この時点で、[ネットワーク] に移動すると、[仮想ネットワーク] で構成した仮想ネットワーク、[ローカル ネットワーク] で構成したローカル サイト、および [DNS サーバー] で登録した DNS サーバーが表示されています。
フェーズ 2: 複数サイト VPN を構成する
次の手順では、オンプレミスのサイトに VPN ゲートウェイを確立します。 この手順を実行するには、次の操作を行う必要があります。
- Azure ポータルを使用して、いずれかのサイトに VPN ゲートウェイを確立する。
- 仮想ネットワークの構成設定をエクスポートする。
- 複数サイト VPN 用に構成ファイルを変更する。
- 更新された Azure のネットワーク構成をインポートする。
- Azure のゲートウェイの IP アドレスと事前共有キーを記録する。
- オンプレミスの VPN デバイスを構成する。
複数サイト VPN の構成の詳細については、「複数サイト VPN の構成」を参照してください。
最初のサイトに VPN ゲートウェイを確立する
仮想ゲートウェイを作成するときは、最初のオンプレミス サイトに接続するように既に指定されています。 仮想ネットワーク ダッシュボードに移動すると、ゲートウェイが作成されていないことがわかります。
Azure 側で VPN ゲートウェイを確立するには、「VPN Gateway」を参照してください。
重要
この記事の「仮想ネットワーク ゲートウェイを開始する」セクションの手順のみを実行し、それ以降のセクションは実行しないでください。
仮想ネットワーク構成の設定をエクスポートする
現在、Azure 管理ポータルでは、複数サイト VPN の構成はできなくなっています。 この構成では、仮想ネットワークの構成設定を XML ファイルにエクスポートしてから、そのファイルを変更する必要があります。 「Azure porta を使用して仮想ネットワーク (クラシック) を作成する」の手順に従って設定をエクスポートします。
複数サイト VPN 用にネットワークの構成設定を変更する
任意の XML エディターでエクスポートしたファイルを開きます。 オンプレミスのサイトへのゲートウェイ接続が、「ConnectionsToLocalNetwork」セクションに一覧表示されます。 XML ファイルでその用語を検索すると、セクションが見つかります。 構成ファイルのこのセクションは、次の例のようになります (ローカル サイト用に作成したサイト名の例は "Site A" です)。
<ConnectionsToLocalNetwork>
<LocalNetworkSiteRef name="Site A">
<Connection type="IPsec" />
</LocalNetworkSiteRef>
2 番目のサイトを構成するには、「ConnectionsToLocalNetwork」セクションの下に別の「LocalNetworkSiteRef」セクションを追加します。 更新された構成ファイルのセクションは次の例のようになります (2 番目のローカル サイトのサイト名の例は "Site B" です)。
<ConnectionsToLocalNetwork>
<LocalNetworkSiteRef name="Site A">
<Connection type="IPsec" />
<LocalNetworkSiteRef name="Site B">
<Connection type="IPsec" />
</LocalNetworkSiteRef>
更新された構成設定ファイルを保存します。
仮想ネットワークの構成設定をインポートする
構成ファイルに追加した 2 番目のサイト参照によって、Microsoft Azure がトリガーされ、新しいトンネルが作成されます。 「Azure portalを使用して仮想ネットワーク (クラシック) を作成する」の手順に従って、更新されたファイルをインポートします。 インポートが完了すると、仮想ネットワーク ダッシュボードに、両方のローカル サイトへのゲートウェイ接続が表示されます。
Azure ゲートウェイの IP アドレスと事前共有キーを記録する
新しいネットワーク構成設定がインポートされると、仮想ネットワーク ダッシュボードに Azure ゲートウェイの IP アドレスが表示されます。 両方のサイトの VPN デバイスがこの IP アドレスに接続します。 参照用にこの IP アドレスを記録します。
また、作成されたトンネルごとに事前共有 IPsec/IKE キーを取得する必要もあります。 これらのキーと Azure ゲートウェイ IP アドレスを使用して、オンプレミスの VPN デバイスを構成します。
事前共有キーを取得するには、PowerShell を使用する必要があります。 PowerShell を使用して Azure を管理することに慣れていない場合は、「Azure PowerShell」を参照してください。
Get-AzureVNetGatewayKey コマンドレットを使用して、事前共有キーを抽出します。 このコマンドレットは、トンネルごとに 1 回ずつ実行します。 次の例は、仮想ネットワーク "Azure Site" とサイト "Site A" と "Site B" の間のトンネルのキーを抽出するために実行する必要があるコマンドを示しています。この例では、出力は別のファイルに保存されます。 または、これらのキーを他の PowerShell コマンドレットにパイプライン処理したり、これらのキーをスクリプトで使用できます。
Get-AzureVNETGatewayKey -VNetName "Azure Site" -LocalNetworkSiteName "Site A" > C:\Keys\KeysForTunnelToSiteA.txt
Get-AzureVNETGatewayKey -VNetName "Azure Site" -LocalNetworkSiteName "Site B" > C:\Keys\KeysForTunnelToSiteB.txt
オンプレミスの VPN デバイスを構成する
Microsoft Azure は、サポートされる VPN デバイスに VPN デバイス構成スクリプトを提供します。 VPN デバイスに適したスクリプトの仮想ネットワーク ダッシュボードの [VPN デバイス スクリプトの ダウンロード ] リンクを選択します。
ダウンロードするスクリプトには、仮想ネットワークを設定するときに構成した最初のサイトの構成設定があり、そのまま使用して、そのサイトの VPN デバイスを構成できます。 たとえば、仮想ネットワークの作成時にサイト A を LOCAL NETWORK として指定した場合、VPN デバイス スクリプトをサイト A に使用できます。ただし、サイト B の VPN デバイスを構成するには、それを変更する必要があります。具体的には、2 番目のサイトのキーと一致するように事前共有キーを更新する必要があります。
たとえば、サイトにルーティングとリモート アクセス サービス (RRAS) VPN デバイスを使用している場合は、次の手順を実行する必要があります。
- 任意のテキスト エディターで、構成スクリプトを開きます。
- セクションを
#Add S2S VPN interface見つけます。 - このセクションで、 Add-VpnS2SInterface コマンドを検索します。 SharedSecret パラメーターの値が、VPN デバイスを構成しているサイトの事前共有キーと一致することを確認します。
他のデバイスでは、より多くの検証が必要な場合があります。 たとえば、Cisco デバイスの構成スクリプトでは、ローカル IP アドレスの範囲を使用して ACL ルールを設定します。 構成スクリプトを使用する前に、構成スクリプトにあるローカル サイトに対するすべての参照を確認する必要があります。
チェックポイント: VPN の状態を確認する
この時点で、両方のサイトが VPN ゲートウェイを介して Azure 仮想ネットワークに接続されています。 PowerShell で次のコマンドを実行すると、複数サイト VPN の状態を検証できます。
Get-AzureVnetConnection -VNetName "Azure Site" | Format-Table LocalNetworkSiteName, ConnectivityState
両方のトンネルが稼働している場合、このコマンドの出力は次のようになります。
LocalNetworkSiteName ConnectivityState
-------------------- -----------------
Site A Connected
Site B Connected
また、Azure 管理ポータルで仮想ネットワークのダッシュボードを表示すると、接続を確認できます。 両方のサイトの STATUS 値は [ 接続済み] と表示されます。
注:
接続が正常に確立されてから Azure 管理ポータルに状態の変化が表示されるまで数分かかることがあります。
フェーズ 3: 仮想マシンを構成する
このデプロイには、少なくとも 2 つの仮想マシン (ドメイン コントローラーと DAG 監視として機能するファイル サーバー) を Microsoft Azure に作成する必要があります。
「クイック スタート: Azure portalで Windows 仮想マシンを作成する」の手順に従って、ドメイン コントローラーとファイル サーバー用の仮想マシンを作成します。 仮想マシンの設定を指定する際は、 [地域/アフィニティ グループ/仮想ネットワーク] について、作成した仮想ネットワークを必ず選択してください。
Azure PowerShellを使用して、ドメイン コントローラーとファイル サーバーの両方に優先 IP アドレスを指定します。 VM の優先 IP アドレスを指定する場合は、VM を更新する必要があります。そのためには、VM の再起動が必要です。 次の例では、Azure-DC と Azure-FSW の IP アドレスをそれぞれ 10.0.0.10 と 10.0.0.11 に設定します。
Get-AzureVM Azure-DC | Set-AzureStaticVNetIP -IPAddress 10.0.0.10 | Update-AzureVM Get-AzureVM Azure-FSW | Set-AzureStaticVNetIP -IPAddress 10.0.0.11 | Update-AzureVM注:
優先 IP アドレスを持つ VM は、そのアドレスの使用を試みます。 ただし、そのアドレスが別の VM に割り当てられている場合、優先 IP アドレス構成の VM は起動しません。 この問題を回避するには、使用する IP アドレスが別の VM に割り当てられていないことを確認します。 詳細については、「Azure portalを使用して仮想マシンのプライベート IP アドレスを構成する」を参照してください。
組織で使用している基準を使用して、Azure のドメイン コントローラー仮想マシンをプロビジョニングします。
Exchange DAG のミラーリング監視の前提条件を持つファイル サーバーを準備します。
役割と機能の追加ウィザードまたは Install-WindowsFeature コマンドレットを使用して、ファイル サーバーロールを追加します。
ローカル管理者グループに、Exchange Trusted Subsystem ユニバーサル セキュリティ グループを追加します。
チェックポイント: 仮想マシンの状態を確認する
この時点で、仮想マシンが稼働し、両方のオンプレミスのデータセンターにあるサーバーと通信できるはずです。
- Azure のドメイン コントローラーがオンプレミスのドメイン コントローラーにレプリケートしていることを確認します。
- 名前ごとに Azure のファイル サーバーにアクセスし、Exchange サーバーから SMB 接続を確立できることを確認します。
- Azure のファイル サーバーから、名前によって Exchange サーバーにアクセスできることを確認します。
フェーズ 4: DAG のミラーリング監視を構成する
最後に、新しいミラーリング監視サーバーを使用するように DAG を構成する必要があります。 既定では、Exchange は、ミラーリング監視サーバー上のファイル共有監視パスとして C:\DAGFileShareWitnesses を使用します。 カスタム ファイル パスを使用している場合は、特定の共有のミラーリング監視ディレクトリも更新する必要があります。
Exchange 管理シェル に接続します。
DAG 用にミラーリング監視サーバーを構成するには、次のコマンドを実行します。
Set-DatabaseAvailabilityGroup -Identity DAG1 -WitnessServer Azure-FSW
詳細については、次の記事を参照してください。
チェックポイント: DAG のファイル共有監視を検証する
この時点で、DAG 監視として Azure 上のファイル サーバーを使用するように DAG を構成しました。 構成を検証するには次のようにします。
次のコマンドを実行して、DAG の構成を検証します。
Get-DatabaseAvailabilityGroup -Identity DAG1 -Status | Format-List Name, WitnessServer, WitnessDirectory, WitnessShareInUseWitnessServer パラメーターが Azure 上のファイル サーバーに設定されていること、WitnessDirectory パラメーターが正しいパスに設定されていること、WitnessShareInUse パラメーターに [プライマリ] が表示されていることを確認します。
DAG に偶数のノードがある場合、ファイル共有監視が構成されます。 次のコマンドを実行して、クラスターのプロパティにあるファイル共有監視の設定を検証します。 SharePath パラメーターの値は、ファイル サーバーを指し示し、正しいパスを表示する必要があります。
Get-ClusterResource -Cluster MBX1 | Get-ClusterParameter | Format-List次に、次のコマンドを実行して、「ファイル共有監視」クラスター リソースの状態を確認します。 [クラスター リソースの 状態] に [オンライン] と表示されます。
Get-ClusterResource -Cluster MBX1最後に、ファイル エクスプローラーでフォルダーを確認し、サーバー マネージャーで共有を確認して、ファイル サーバーで共有が正常に作成されていることを確認します。