Windows Virtual Desktop (WVD) ネットワーク アーキテクチャ

Windows Virtual Desktop (WVD) を導入する際に、先ず検討の対象となるのがネットワークの構成です。ネットワークは、後から変更するのが難しいので、最初にキチンと設計しておきたいところです。

そこで、今回は、大規模な展開にも対応できるオススメ構成を考えてみました!

ジャジャーーーン!

・1つのAzureADテナントで構成しています。
・Azureネットワークの大原則である、ハブ&スポークにて構成しています。
・スポークあたり、1000VM以下で構成。5000VMを目処に増設していきます。
・サブスクあたり、ANFアカウントを1つ作成し、スポークに対してボリュームを提供する。
・ユーザーあたり、50IOPSとした場合、9175人ほどをボリュームに収容可能
・ユーザー割り当ては”グループ”で行うこと
・よくある要件として、オンプレに”Web Proxy”を設置しています。

【スポークネットワークのコンポーネント】

Session Host
場所:スポークネットワークに展開
役割:VDI用VM
注意:ANFの制限のため、1000VM(Peering先含む)以下で展開すること
ローリングアップデート台数を考慮すること

NSG
場所:Session Hostと同じサブネットに展開
役割:Session Hostからの社内サーバー向けの通信を制御

UDR
場所:Session Hostと同じサブネットに展開
役割:オンプレ向けの通信をExpressRoute Gatewayにルーティングする
Session Hostからの”デフォルトルート”をAzure Firewallにルーティングする

Peering
場所:ハブとスポークの間
役割:ハブネットワークとスポークネットワークを接続する

Private Link + Azure Monitor Private Link Scope
場所:Session Hostと同じサブネットに展開
役割:WVD(HostPool)のログをプライベートネットワーク経由でLog Analyticsにわたす

Azure NetApp Files
場所:Session Hostと同じ仮想ネットワークに展開
役割:ユーザープロファイルを保存するファイルサーバー※SKU:Standardを選択すること
注意:1000VM(Peering先含む)以下の環境に展開すること

【ハブネットワークのコンポーネント】

ExpressRoute Gateway
場所:ハブネットワークに展開
役割:オンプレ環境との接続に必要。オンプレ側のIPセグメント情報をUDRにわたす
注意:オンプレで利用しているIPセグメントをBGPで広報させること

Azure Firewall
場所:ハブネットワークに展開
役割:Session Hostからのインターネット(デフォルトルート)向けの通信を制御
注意:特に、M365を利用する場合、ポート上限に注意

Active Directory
場所:ハブネットワークに展開
役割:AzureADへのユーザー同期とSession Hostへのサインイン時の認証
注意:オンプレでも可能だが、Session Hostの近くに展開すること

AzureAD Connect
場所:ハブネットワークに展開
役割:Active DirecoryからAzureADに対してユーザー情報をわたす
注意:オンプレでも可能だが、Active Direcoryの近くに展開すること





ここからは、3つの通信経路を実現するための設定を見ていきます!

①WVDに必要な通信 [Session Host → NSG → UDR → Azure Firewall]
②Microsoft365 向けの通信 [Session Host → NSG → UDR → Azure Firewall]
③Webアクセス向けの通信 [Session Host → NSG → UDR → ER Gateway]

※WVDにおいて、インターネットからのインバウンド通信はありません。
※WVDに必要な通信についてはこちら

Session Host
PACファイルを利用し、M365向け通信をオンプレ(Web Proxy)経由にならないよう除外する

【PACファイル作成方法】

先ず、PACファイルを生成するためのPowerShellスクリプトをダウンロード
PowerShellにて”Get-PacFile.ps1″を実行して下さい。※赤字のみ環境に合わせて変更

.\Get-PacFile.ps1 -Type 2 -Instance Worldwide -TenantName Contoso -ClientRequestId b10c5ed1-bad1-445f-b386-b919946339a7 -DefaultProxySettings “PROXY 192.168.0.250:8080” > O365.pac

NSG
WVDに必要な通信、KMS、vNet間、オンプレ、Web(M365含む)通信を許可
※追加で必要な通信は適宜追加して下さい。

UDR
デフォルトルートを”Azure Firewall”に向け、ゲートウェイからのルート伝達を有効にする。

Peering
リモートゲートウェイを有効にすることで、オンプレへのルートを確保する。

Azure Firewall
WVDに必要な通信、KMS、M365通信を許可
※Azure Firewallを経由することでパブリックIPを固定化できる。

Session Hostのルーティングテーブルを確認

・オンプレ(192.168.0.0/16)向けのルートがER Gatewayに向いている。
※PACファイルにより、Webアクセスは、オンプレ(Web Proxy)を経由する。

・デフォルトルートがAzure Firewallに向いている。
※WVD&M365向け通信


大規模環境に影響しそうな制限事項

・テナントあたり、最大200のアプリケーショングループ(最大200HostPool)
・アプリケーショングループあたり、50以下のアプリケーション登録を推奨
・サブスクリプション[Instance(物理ホスト) / UserID / hour]あたりのAPI要求制限
読み取り=12,000 書き込み=1,200 削除=15,000
・サブスクリプションあたり、5,000VM以下を推奨(シングル/マルチセッション問わず)
・サブスクリプションあたり、最大2,000のロール割り当て(ユーザー割り当てに影響)
・Azure Portal(ARM Template)からSession Hostを1度のデプロイで作成できる最大VM数
可用性セットなし=399VM。可用性セットあり=200VM
・AzureADテナントあたり、50以上のアプリケーショングループの作成不可
・アプリケーショングループあたり、50以下のアプリケーション公開を推奨
・FSLogix 1ユーザーあたりのIOPS(参考値):通常時=10 サインイン/サインアウト時=50
・Azure NetApp Filesにアクセス可能なIP数=1,000IP (Peer接続先のIP含む)