Azure で DR を検討している際にオンプレミス間の接続の冗長性も考慮する必要があります
Private Endpoint を利用していると DNS フォワーダーの設定が必要になります
では、この 2 つを合わせて「障害時に備えて DNS フォワーダーをどうするのか」を確認してみます
想定シナリオ
今回想定しているシナリオは下記のような Azure-オンプレミス 間を冗長化しているケースです
ついでに Hub となる Vnet も冗長化しています
想定している障害としては Primary ExpressRoute 回線が切断された場合です
---
title: Azure Vnet からオンプレ接続までのネットワーク構成
---
graph TB;
%%グループとサービス
subgraph Vnet1[Privamary Vnet]
DNS1["Primary DNS Server"]
end
EX1{{"Primary ExpressRoute 回線"}}
subgraph Vnet2[Secondary Vnet]
DNS2["Secondary DNS Server"]
end
EX2{{"Secondary ExpressRoute 回線"}}
subgraph OnPrem[オンプレ]
DNSC["オンプレ DNS Server"]
end
%%サービス同士の関係
Vnet1 --> EX1
Vnet2 --> EX2
EX1 -- ここの障害を想定 --> OnPrem
EX2 --> OnPrem
DNSC --> OnPrem
%%サブグラフのスタイル
classDef VnetG fill:none,color:#0a0,stroke:#0a0
class Vnet1,Vnet2,EX1,EX2 VnetG
classDef SCP fill:#e83,color:#fff,stroke:none
class DNS1,DNS2,DNSC SCP
通常時は オンプレ DNS は Primary DNS サーバーにフォワードしていますが、Primary DNS サーバーが切断された場合には Secondary DNS サーバーにフォワードされるかを確認します
オンプレミス DNS Server として Windows Server を使用します
ざっくり手順
- 環境構築
- フォワーダー設定
- フォワーダーの順番を確認
- 疑似障害発生
1. 環境構築
環境構築はシナリオを簡略化して下記のように構築します
---
title: Azure Vnet からオンプレ接続までのネットワーク構成
---
graph TB;
%%グループとサービス
subgraph Vnet1[Privamary Vnet]
DNS1["Azure DNS Private Resolver"]
PE1["Private Endpoint1"]
end
EX1{{"Vnet Peering"}}
subgraph zone1["Azure DNS Private Zone"]
A1["A Record"]
end
subgraph Vnet2[Secondary Vnet]
DNS2["Azure DNS Private Resolver"]
end
EX2{{"Vnet Peering"}}
subgraph OnPrem[オンプレを想定した Vnet]
DNSC["オンプレ DNS Server"]
end
%%サービス同士の関係
Vnet1 --> EX1
Vnet2 --> EX2
EX1 --> OnPrem
EX2 --> OnPrem
DNSC --> OnPrem
zone1 -.-> Vnet1
%%サブグラフのスタイル
classDef VnetG fill:none,color:#0a0,stroke:#0a0
class Vnet1,Vnet2,EX1,EX2 VnetG
classDef SCP fill:#e83,color:#fff,stroke:none
class DNS1,DNS2,DNSC SCP
オンプレミスを想定した Vnet を作成し、ExpressRoute の代わりに Vnet Peering を利用しています
またフォワーダーの設定変更がわかりやすいように Private Endpoint + DNS Zone を片側にだけ用意し名前解決結果が異なるようにしています
Private Endpoint は Storage Account に接続しています
上記の構成を Bicep で用意しています
Azure_Bicep/Blog/windns_forwader at main · NakayamaKento/Azure_Bicep
2. フォワーダー設定
フォワーダーの設定は下記のように行います
※これも Bicep デプロイ時に構成されるようにしています
|
|
フォワーダーを使用する を見ると、フォワーダーの設定は複数指定できることがわかります
複数指定した場合は、指定した順番にフォワードされるようです
3. フォワーダーの順番を確認
環境ができたので VM に実際にログインして動作を確認してみます
DNS のインストール、フォワーダーの設定はちゃんとできてました（安心
Private Endpoint を設定している Storage Account の名前解決をしてみます
ちゃんとフォワードされているようで、Private IP アドレスが返ってきました
DNS ログを見ると詳細は置いておいて、1番目のフォワーダーにフォワードされていることがわかります
4. 疑似障害発生
では、一番目のフォワーダーとの通信ができなくなったという状況を想定してみます
単純に Vnet Peering を切断してみます
---
title: 疑似障害。Peering を切断
---
graph TB;
%%グループとサービス
subgraph Vnet1[Privamary Vnet]
DNS1["Azure DNS Private Resolver"]
PE1["Private Endpoint1"]
end
EX1{{"Vnet Peering"}}
subgraph zone1["Azure DNS Private Zone"]
A1["A Record"]
end
subgraph Vnet2[Secondary Vnet]
DNS2["Azure DNS Private Resolver"]
end
EX2{{"Vnet Peering"}}
subgraph OnPrem[オンプレを想定した Vnet]
DNSC["オンプレ DNS Server"]
end
%%サービス同士の関係
Vnet1 x-.-x EX1
Vnet2 --> EX2
EX1 x-.-x OnPrem
EX2 --> OnPrem
DNSC --> OnPrem
zone1 -.-> Vnet1
%%サブグラフのスタイル
classDef VnetG fill:none,color:#0a0,stroke:#0a0
class Vnet1,Vnet2,EX1,EX2 VnetG
classDef SCP fill:#e83,color:#fff,stroke:none
class DNS1,DNS2,DNSC SCP
念のため DNS キャッシュをクリアして再度 名前解決をしてみます
結果を見ると、Public IP アドレスが返されています
DNS ログを見ると、2番目のフォワーダーにフォワードされていることがわかります
まとめ
Windows Server の DNS フォワーダーの設定を確認しました
フォワーダーを複数設定していると上に書かれているフォワーダーが優先的に利用されます
DR 対策として Azure 側を東西で準備することは多いと思いますが、オンプレミス側の DNS サーバーの設定も忘れずに行いましょう！
