こんにちは。 SB C&S の市島です。
私は VMware 製品のプリセールスエンジニアチームに所属しており、主に VMware EUC製品 を担当しております。
今回は、 VMware Horizon Cloud on Microsoft Azure (以下、Horizon Cloud on Azureと記載)の初回環境構築時に重要なポイントについてお伝えします。

■Horizon Cloud on Azureの環境構築方法

Horizon Cloud on Azureは管理コンソールでパラメータ情報を入力するだけで、お客様のAzureインフラストラクチャ上に仮想デスクトップ環境に必要なコンポーネント(Pod)を自動展開します。Pod ManagerやUAGなどのPodに必要なサーバーの展開・設定が自動で行われ、1時間程度で環境作成が完了します。

従来のオンプレミスHorizonを利用する場合は、

1. お客様自身で管理されているネットワークやオンプレミスの物理サーバーを準備
2. VMware vSphere環境(サーバー仮想化環境)を構築
3. Horizonの管理ソフトウェアをインストールするWindows Server、SQL DBなどを準備
4. Horizonの管理ソフトウェア(接続サーバーやセキュリティサーバーなど)をインストール

といった作業を経てやっとHorizonが利用できるようになりますので、自動ですぐに展開できるHorizon Cloud on Azureはとても革新的なサービスかと思います。

ただし、この自動展開は"事前の環境準備が完了している"ことが重要です。パラメータ値や事前のAzure環境の準備を誤っていると、自動での展開も途中で失敗してしまいます。

今回のブログではお客様からよくお問い合わせ頂く大事な内容をピックアップし、初回環境構築時に特に注意してチェック頂きたい7つのポイントとしてお伝えします。

※本ブログ作成時点の確認した情報で記載しています。最新情報や詳細要件は必ずVMwareのドキュメントをご確認下さい。
<新しいポッドのデプロイに対する VMware Horizon Cloud Service on Microsoft Azure 要件チェックリスト>
https://docs.vmware.com/jp/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.getstarted15/GUID-5F69086E-E061-48F3-93D9-9705B8B5FD8A.html

1. Active Directoryドメイン環境の構成

Horizon Cloud on Azure を使用する際は、オンプレミスHorizonと同様にActive Directory (AD) ドメイン環境の準備が必須です。AD サーバー(ドメインコントローラー)は新規にAzure上に構築するか、お客様のオンプレミス環境にある既存のAD サーバーを使用します。
既存のオンプレミス ADサーバーを使用したい場合は、IPsec-VPNやAzure Express Routeを使用してAzureのネットワークとお客様オンプレミス環境を接続する必要があります。また、この場合Azure上の仮想マシンとして既存ADサーバーのレプリカサーバーを作成する構成も多いです。

せっかくAzureのクラウドに移行を進めるのでAzureサービスを活用したい、といった場合はAzure Active Directory Domain Servicesを使用した構成もHorizon Cloud on Azureでサポートされています。この場合、ADサーバーのWindows Server仮想マシンの管理をお客様で行わなくてすみます。
※Azure Active Directoryのみでは構成ができませんのでご注意下さい。

次に、ADドメインのアカウント・グループの準備が必要です。
4種類のアカウント・グループがHorizon Cloud on Azureでは必要です。

1. ドメインバインド アカウント(メインと補助の2つ)
Horizon CloudがAD ドメイン内のオブジェクト検索を実行するために使用するアカウントです。Horizon Cloud on AzureのPod初期展開時にお客様のADドメインと連携する際に使用します。ドメインバインド アカウントはADドメインの各オブジェクトに対しての読み取りが可能な権限が必要です。このアカウントはメイン用と補助用として、2つのアカウントが必要です。

2. ドメイン参加アカウント
Horizon Cloudが展開する仮想デスクトップ用の仮想マシンに対してSysprepを実行しドメインに参加させるために使用するアカウントです。ADドメインに対してコンピュータを参加/削除する権限などが必要です。

※注意
ドメインバインド アカウントとドメイン参加アカウントは、パスワードの期限切れによってHorizon Cloud on Azureのシステムに支障を発生させないため、パスワードを無期限にすることが推奨されています。セキュリティポリシーとして無期限にすることができない場合は、有効期限に達する前にHorizon Cloudに登録したアカウント情報を更新する必要があります。
その他、アカウントに必要な権限などの詳細情報は、以下VMwareのドキュメントをご確認下さい。
<Horizon Cloud の運用に必要なサービス アカウント>
https://docs.vmware.com/jp/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-5F0B52F6-CD79-447B-B1C6-6ED2AF71BBA7.html

3. Horizon Cloud の管理者グループ
Horizon Cloud の管理者グループです。Horizon Cloud管理者グループは、Horizon Cloudの管理コンソールにログインをして管理操作を行うユーザーアカウントとを含むグループです。Podの初回デプロイ後は、管理者がHorizon Cloud管理コンソールにログインする際にMy VMwareアカウントとHorizon Cloud の管理者グループに所属するADアカウントでの２段階ログインが必要になります。
また、ドメイン参加 アカウントはこのグループに所属させます。

4. 利用者アカウント・グループ
ユーザーはこのユーザーアカウントでHorizon Cloud on Azureの仮想デスクトップにログインします。既存ADサーバーを活用する場合はすでに必要なアカウントが作成されているかと思いますが、PoC目的で新たにADサーバーを構築している場合はアカウントの作成が必要です。

2. ネットワークの準備 (Azure IaaS環境のネットワーク)

次に、ネットワークの準備です。事前準備として最も重要なポイントです。

Horizon Cloud on Azureはお客様のAzure IaaS環境上に仮想マシンを展開します。そのため、ネットワーク構成はお客様自身が事前に設計する必要があります。Horizon Cloud on Azureの基本的な構成として、以下のネットワークサブネットの確保が必要です。

• 管理サブネット ・・・ /27以上
• DMZ サブネット・・・ /28以上
• 仮想マシン(テナント)サブネット・・・ /27以上 (推奨は/24〜/22)

特に仮想マシンサブネットは仮想デスクトップ用仮想マシンの数が許容出来る必要がありますので、大量の仮想マシンを展開する予定がある場合は、IPアドレスが枯渇しないようにサブネットの考慮が必要です。なお、このサブネットに他の仮想マシンなどをお客様が展開することはサポートされませんのでご注意下さい。
上記Azureの上のサブネットは、Podのデプロイ時に値を指定することで自動作成することが可能ですが、VNetは事前にお客様自身がAzure Portalにログインして作成する必要があります。

また、Horizon Cloud on Azureの管理コンポーネントや仮想デスクトップ以外にも、Active Directoryドメインコントローラーやファイルサーバー、お客様の業務アプリケーション用のサーバーなどが接続するネットワークも必要です。オンプレミスのファイルサーバーや業務アプリケーションにAzure上の仮想デスクトップからアクセスする場合も、IPsec-VPNやAzure Express Routeを使用してどのようなルートでアクセスするか検討が必要となります。

このように、Horizon Cloud on Azureの仮想デスクトップ環境と既存システムとの接続を考慮しどういったネットワーク構成にするか、全体構成を事前に検討することが重要です。

さらに、VNet作成後に忘れがちな作業を1点お伝えします。
Horizon Cloud on Azureの展開された仮想マシンがドメイン参加やインターネット接続を行うため、DNSサーバーの名前解決が必要です。VNetの規定設定ではAzure上のDNSサーバーを参照してしまうため、ADサーバーの参照ができません。
Azure PortalのVNetの設定で[DNSサーバー]の設定項目を開き、ADサーバーのIPアドレスを参照するように変更します。

3. Horizon CloudとAzureの連携に必要なID・Keyの準備

Horizon Cloudがお客様のAzureテナント上にPodを展開するため、事前に連携設定が必要となります。連携設定にはAzureテナントのIDやKeyの情報が必要となります。以下、4つのID・Keyが必要になりますので事前に確認・作成します。

• Subscription ID ・・・ Microsoftとお客様の契約に基づくAzureの請求ID
• Directory ID・・・お客様のAzure ADを識別するID
• Application ID ・・・Azure ADテナント内で、アプリ(サービスプリンシパル)を一意に識別するID
• Application Key ・・・サービスプリンシパルの暗号化に使用されるパスワード

※Application ID・Keyを発行するにはAzure ADの[アプリの登録]からアプリ(サービスプリンシパル)を新規に登録し、登録したアプリ(サービスプリンシパル)に必要なサブスクリプションのロールを割り当てる必要があります。

4. Azureサブスクリプション vCPUクォーターの確認

Azure では意図しない過剰なリソース使用を防ぐため、リージョンやVMインスタンスのシリーズごとにvCPUクォータ(制限)が設定されています。クォータを超えた仮想マシンの起動はできないため、Horizon Cloud on Azureで必要な仮想マシンが展開・起動できるようにvCPUクォータの上限を上げておく必要があります。

<Azure Portalのクォータ設定画面>

特に、新たに契約したAzureサブスクリプションではリージョンのvCPU合計のクォータが少ない値になっている場合があり、その場合Horizon Cloud on AzureのPod ManagerやUAGなどの管理コンポーネントも展開できず、Podの展開途中で失敗してしまいますので注意して下さい。

vCPUクォーターの上限引き上げは、Azure PortalからAzure(Microsoft)のサポートに依頼します。

5. FQDNとSSL証明書

Horizon Cloud on AzureのPod展開時に、Unified Access Gateway (UAG)のFQDNとSSL証明書が必要です。
ユーザーはこのFQDNを指定して、仮想デスクトップにアクセスします。例えば、外部UAGを展開しインターネットからアクセス出来る環境を構成する場合、UAGのFQDNに対して名前解決が出来るように外部ドメインの取得とレコードの追加が必要です。

また、このFQDNと一致するPEM形式のSSL証明書もPodの展開時に必要です。このSSL証明書は、自署名証明書を使用できないため、認証局(CA)で発行された証明書を準備する必要があります。
（AD証明書サービスなど認証局を自分で準備し、その認証局から発行した証明書であればアップロードして使用することは可能です）

このFQDN(ドメイン)とSSL証明書は、Azure DNSやAzure App Service証明書などのAzureのサービスを使用して作成することも可能です。費用請求や管理をAzureにまとめることができます。

【補足】

SSL証明書を発行するとPFX形式のファイルで出力される場合があります。Horizon Cloud on AzureではPEM形式のSSL証明書が必要なため、OpenSSLなどを使用してファイル形式を変換する必要があります。

#PFX形式ファイルからPEM形式ファイルへの変換出力コマンド例
>openssl pkcs12 -in "既存の証明書ファイル(.pfx)" -out "変換後の証明書ファイル.pem" -nodes

※Windows 10でも、Windows OSで実行できるOpenSSLをインストールすることで上記方法は利用可能です。

6. ライセンス

Horizon Cloud on Azureを利用するには「Horizon Universal」のライセンスが必要です。公開デスクトップ/公開アプリケーション(RDSH)のみの利用の場合は、少し安価な「Horizon Apps Universal」のライセンスでもOKです。（Windows 10 EnterpriseマルチセッションOSは「Horizon Apps Universal」のライセンスで利用できます）

またVMwareのライセンス以外にも、Microsoftの提供する「Azureサブスクリプション」と「Windowsのライセンス」が必要です。

「Azureサブスクリプション」は、Azure上で仮想マシンやネットワーク、データーベースのサービスなどを利用するために必要です。
Azureの利用料は基本的にご利用した分の従量課金となりますが、一部の仮想マシンはAzure Reserved VM Instancesを使用することでコストを抑えることが可能です。Azure Reserved VM Instancesは1年間または3年間分の利用を事前契約することで、従量課金の24時間/365日利用と比較してコストを抑えることができます。
Pod ManagerやUAGなどの管理コンポーネントや、24時間/365日の起動を予定している仮想デスクトップ/ファームの仮想マシンはAzure Reserved VM Instancesの利用を検討しても良いかと思います。

「Windowsのライセンス」はAzure上でWindows仮想デスクトップを利用する場合に必要なMicrosoftのライセンスです。
基本的には、Windows 10 Enterprise E3/E5 やMicrosoft 365 E3/E5 などのWindows Virtual Desktop (WVD) の利用権を持つライセンスを用意する必要があります。最新情報は下記MicrosoftのWVDの価格に関するページや当社営業担当までご相談下さい。
<Windows Virtual Desktop の価格>
https://azure.microsoft.com/ja-jp/pricing/details/virtual-desktop/

7. ユニバーサルブローカー、またはシングルポッドブローカーの選択

2020年7月以降にHorizon Cloud on AzureのPodを新規展開した場合、仮想デスクトップのプール/ファーム作成前に"ユニバーサルブローカー(Universal Broker)"か"シングルポッドブローカー(Single-Pod Broker)"のどちらを使用するか、選択する必要があります。

ユニバーサルブローカーは2020年7月の機能更新により新たにHorizon Cloud on Azure使用可能になった、Horizonのマルチクラウド仮想デスクトップ割当を実現するVMware 提供のGSLB(Global Server Load Balancing)サービスです。
シングルポッドブローカーは従来の方式です。

従来、例えばAzureの東日本リージョンと西日本リージョンそれぞれにユーザーが利用する仮想デスクトップ環境(Pod)を用意した場合、ユーザーの接続先FQDN(UAGのFQDN)もPod毎に別々のものになってしまいます。
ユニバーサルブローカーを使用することで、ユーザーは1つのFQDNにアクセスするだけで適切なリージョンの仮想デスクトップにアクセスできるようになります。

ユニバーサルブローカーはとても魅力的な機能ですが、本ブログ作成時ではいくつかの機能制限があるため、利用する場合は注意が必要です。
お客様のご要件を満たす機能がユニバーサルブローカーで対応していない場合シングルポッドブローカーを選択する必要があります。

※ユニバーサルブローカーの制限事項はVMwareのドキュメントをご確認下さい。
<Universal Broker の既知の制限>
https://docs.vmware.com/jp/VMware-Horizon-Cloud-Service/services/hzncloudmsazure.admin15/GUID-26FA255F-D0A3-48B4-8B4B-C8B9F9852A05.html

また、現時点のリリースではブローカー選択後の変更ができません。一度ユニバーサルブローカーを選択してしまうと、一部機能がご利用しているHorizon Cloudテナントで利用できなくなってしまうため初回選択時はご注意下さい。
事前にどのような機能をHorizon Cloud on Azureで利用するか検討してから、ブローカー方式を選択することをおすすめします。

■まとめ

Horizon Cloud on Azureの環境構築に大事な7つのポイントをご紹介致しました。
以外と考慮すべきポイントが多いな、と思われた方もいらっしゃるのではないでしょうか？
簡単にすぐHorizonの仮想デスクトップ環境を展開・構築できるのがHorizon Cloud on Azureのメリットですが、そのメリットを享受するにはしっかりとした環境準備が必要です。本ブログがお客様のHorizon Cloud on Azure導入時に少しでもお役に立てば幸いです。

本ブログでは今後もHorizon Cloud on Azureを始め、VMware EUC製品の情報を発信していきますので引き続きご確認頂けると幸いです。

---

VMware の各種製品情報や SB C&S が提案する仮想化ソリューションについての情報はこちらから