この記事は更新から24ヶ月以上経過しているため、最新の情報を別途確認することを推奨いたします。

こんにちはDXソリューション統括部の村松です。

前回「Horizon Cloud on Azure での仮想デスクトップ環境管理は超簡単」という記事にてHorizon Cloud on Azure(以下”HoA”)を紹介させていただきましたが、いざHoAを展開しようとすると多くの”つまずきポイント”があります。(私もつまずきました…)
そこで今回はHoA構築時に遭遇する主な“つまずきポイント”およびその回避策を紹介していこうと思います。

つまずきポイント1：サブスクリプションのvCPUコア数の上限

Azureサブスクリプションでは利用できるvCPUコア数に上限が設けられております。HoA展開においてはセッションホストはもちろんのこと、管理サーバとしてポッドマネージャ、UAG、ジャンプボックスなどの仮想マシンがデプロイされ、多くのvCPUコアが消費されます。
その際にAzureサブスクリプションのvCPUコアの上限に達してしまうと、リソース不足で展開時にエラーとなってしまいます。

そのため展開前にHoAから展開する仮想マシンの数や種類から必要なvCPUコア数(*1)を見積もり、サブスクリプションで利用可能なvCPUコア数と上限を確認してください。その際に利用可能なvCPUコア数が足りない場合はサブスクリプションのサポートリクエストからvCPUコア数の上限引き上げを依頼してください。(*2)

(*1)管理サーバ(ポッドマネージャ、UAG、ジャンプボックス)としてデプロイされる仮想マシンの種類については以下のドキュメントを参照
Microsoft Azure の Horizon Cloud ポッドに対する Microsoft Azure 仮想マシンの要件

(*2)vCPUコア数の上限引き上げじたいは追加コストはかかりません。

 

つまずきポイント2：Unified Access Gateway 用証明書

HoAではクライアントがセッションホストに接続する際はUnified Access Gateway 経由で接続します。Unified Access Gateway 経由でクライアントが接続するためには、SSL証明書が必要になります。

SSL証明書のCN(コモンネーム)はユーザがUnified Access Gatewayにアクセスする際のFQDNである必要があります。

また証明書は、公的な認証局(CA)で発行されたもので、以下のようにCA証明書、SSL証明書、秘密鍵が1つに含まれるPEM 形式である必要があります。

—–BEGIN CERTIFICATE—–
…. (your primary SSL certificate)
—–END CERTIFICATE—–
—–BEGIN CERTIFICATE—–
…. (the intermediate CA certificate)
—–END CERTIFICATE—–
—–BEGIN CERTIFICATE—–
…. (the trusted root certificate)
—–END CERTIFICATE—–
—–BEGIN RSA PRIVATE KEY—–
…. (your server key from mycaservercertkeyrsa.pem)

—– END RSA PRIVATE KEY—–

 

つまずきポイント3：仮想ネットワーク

事前にHoAを展開する仮想ネットワークを作成しておく必要があります。
HoA展開時にその仮想ネットワークを指定すると以下のサブネットが自動的に作成されます。
そのため、仮想ネットワーク作成の際はHoA用に自動で作成されるサブネット
およびその他の関連サーバ(AD,ファイルサーバ、VPNゲートウェイ)用のサブネットのアドレス範囲を考慮の上、仮想ネットワークのアドレス空間を設定してください。

HoA用に自動で展開されるサブネットとアドレス範囲

• 管理サブネット　/27以上
• 仮想マシン(テナント)サブネット　/27以上 推奨は/24～/22
• DMZ サブネット　/28以上(外部UAGが有効な場合のみ)

またサブネットは事前に手動で作成しておき、それをHoA用のサブネットとして指定することもできます。その際は「管理サブネット」にMicrosoft.Sqlへのサービスエンドポイントを有効にしてください。

出典元：Microsoft Azure で Horizon Cloud ポッド用の既存のサブネットを使用する場合

 

つまずきポイント4：DNSサーバ

事前に作成した仮想ネットワークの参照先のDNSサーバーは内部と外部の両方の名前解決ができる必要があります。
それぞれの名前解決の要件は以下の通りとなります。

• 内部の名前解決：ADのSRVレコード、Aレコードが登録されていること
• 外部の名前解決：Horizon Cloudの制御プレーン、HoA展開時にデプロイされるPostgresSQL DataBaseのFQDNを名前解決できること

これらの要件がみたされていないと展開時にADサーバの登録や展開後のセッションホストのドメイン参加に失敗します。

ADを運用している環境では内部のクライアント、サーバが参照するDNSサーバをADとしていることがほとんどかと思います。

(いわゆるActiveDirectory統合DNS)
そのような環境ではADに対して外部の名前解決もできるようにフォワーダー先として外部のDNSサーバを指定する必要があります。しかしセキュリティの制約上「既存のADを外部に通信させたくない」といった場合もあるかと思います。そのような場合は既存のオンプレミス側とAzure側のネットワークでサイト間VPN(もしくはExpressRoute)接続し、双方のAD間でサイト間レプリケーションを構成し、Azure側サイトのADのみにフォワーダー設定を行うことで既存のADに設定変更を加えることなく、要件を満たすことができます。(*3)

(*3)AzureのIaaSでADを展開した場合はデフォルトでフォワーダー先のDNSサーバとしてAzure既定のDNSサーバ(168.63.129.16)が設定されます。

 

以上がHoA展開時に遭遇する主な”つまずきポイント”とその回避策でした。
HoA展開に”つまずく”要因としては展開先のAzure環境で事前の設定が不足していたり、連携させる既存のインフラ環境がHoAの要件を満たしていない場合がほとんどです。今回紹介した内容以外にもHoAの要件は多々存在するので、HoA展開前はVMwareが公開しているHoAの要件チェックリストも合わせてご覧ください。

新しいポッドのデプロイに対する VMware Horizon Cloud Service on Microsoft Azure 要件チェックリスト

 

以上　今回はここまでとなります。またの機会にお会いしましょう！