Microsoft Azure Resource Manager仮想化環境
お使いの環境でMicrosoft Azure Resource Managerを使用して仮想マシンをプロビジョニングする場合は、このガイダンスに従ってください。
これを行うには、以下に関する知識が必要です:
- Azure Active Directory:https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-create-new-tenant
- 同意フレームワーク:https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-register-app
- サービスプリンシパル:https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals
制限事項
Azure Resource Managerを使用する場合は、以下の制限事項を考慮します:
- この製品は、Windows仮想デスクトップ(WVD)環境でVDAをサポートしていません。WVDでのサポートが必要な場合、Citrix Virtual Apps and DesktopsサービスまたはCitrix Virtual Apps and Desktops Standard for Azureサービスを使用してください。
Azureのオンデマンドプロビジョニング
MCSを使用してAzure Resource Managerでマシンカタログを作成する場合、Azureのオンデマンドプロビジョニング機能は次のことを実現します。
- ストレージコストを削減する。
- カタログ作成を高速化する。
- 仮想マシン(VM)の電源操作を高速化する。
管理者にとっては、ホスト接続とMCSマシンカタログを作成する際に、オンデマンドプロビジョニングとStudioで手順に違いはありません。相違点は、Azureでリソースを作成し管理する方法とそのタイミング、Azure PortalでのVMの可視性です。
MCSがカタログを作成したとき、プロビジョニングプロセス中にAzureにVMが作成されました。
Azureのオンデマンドプロビジョニングでは,VMは,プロビジョニング完了後,Citrix Virtual Apps and Desktopsで電源投入操作が開始されたときにのみ作成されます。Azure Portalでは、実行中のVMのみが表示されます。(Studioでは、VMは実行中かどうかに関係なく表示されます)。
MCSカタログを作成すると、Azure Portalにリソースグループ、ネットワークセキュリティグループ、ストレージアカウント、ネットワークインターフェイス、基本イメージ、IDディスクが表示されます。Azure Portalでは、Citrix Virtual Apps and DesktopsがVMの電源投入操作を開始するまで、そのVMは表示されません。その後、StudioではVMのステータスがオンに変わります。
- プールされたマシンの場合、オペレーティングシステムのディスクとライトバックキャッシュは、VMが存在する場合にのみ存在します。プールされたマシンにより、マシンを定期的に(たとえば、勤務時間外に)シャットダウンする場合はストレージを大幅に節約できます。
- 専用マシンでは、VMの初回電源投入時にオペレーティングシステムのディスクが作成されます。このディスクは、マシンが削除されるまでストレージに残ります。
VMの電源オフのアクションを開始すると、AzureでVMが削除されます。そのVMは、Azureポータルには表示されなくなります。Studioでは、VMのステータスはオフに変わります。
オンデマンドプロビジョニング前に作成されたカタログ
Citrix Virtual Apps and DesktopsでのAzureのオンデマンドプロビジョニング機能のサポート開始(2017年半ば)前に作成されたマシンカタログがある場合、それらのカタログ内のVMは、実行中であるかどうかにかかわらずAzure Portalに表示されます。これらのVMをオンデマンドマシンに変換することはできません。
オンデマンドプロビジョニングの強化されたパフォーマンスとストレージコスト上の利点を活用するには、MCSを使用してカタログを作成してください。
Azure Managed Disks
Azure托管磁盘は従来のストレージアカウントを使用する代わりに,MCSで作成したマシンカタログで使用できる柔軟なディスク記憶域システムです。
Managed Disks機能により、ストレージアカウントの作成と管理の複雑さが解消されます。ディスクの作成と管理のために、シンプルで可用性の高いソリューションが備えられています。Managed Disksは、VMと同様にマスターイメージとして使用できます。Managed Disksを使用すると、マシンカタログの作成および更新時間を改善できます。詳しくは、Managed Disksの詳細を参照してください。
デフォルトでは、マシンカタログはManaged Disksを使用します。このデフォルトはカタログを作成するときに上書きできます。
Managed Disksの使用
Studioでマシンカタログを作成すると、カタログ作成ウィザードの[マスターイメージ]ページに、Managed DisksとVMおよびVHDが表示されます。すべてのAzureリージョンがManaged Disksの機能をサポートしているわけではありません。カタログのホスト接続に表示されているリージョンについては、Managed Disksが一覧に表示されます。
カタログの作成時間は、画像とカタログが同じリージョンにある場合に最適化されます。
Managed Disksの機能は現在、Azureリージョン間におけるディスクのコピーをサポートしていません。MCSがカタログをプロビジョニングする場所以外のリージョンでイメージを選択すると、そのイメージは従来のストレージアカウントのVHDにコピーされます。イメージがカタログのリージョンに表示され、Managed Disksに変換されて戻されます。
カタログ作成ウィザードの[ストレージとライセンスの種類]ページで、Managed Disksの代わりに従来のストレージアカウントを使用するチェックボックスをオンにすることもできますManaged DisksをサポートしていないAzureリージョンでプロビジョニングしている場合は、このチェックボックスをオンにすることはできません。
Azure Resource Managerへの接続の作成
接続を作成するウィザードについて詳しくは、「接続とリソース」を参照してください。以下の情報は、Azure Resource Managerの接続に固有の詳細を扱っています。
注意事項:
- サービスプリンシパルには、サブスクリプションの投稿者の役割が付与されている必要があります。
- 最初の接続を作成するときに、必要な権限付与を求めるプロンプトがAzureで表示されます。その後の接続でも認証は必要ですが、Azureでは以前の同意が記憶され、このプロンプトは再表示されません。
- 認証に使用されるアカウントは、サブスクリプションの共同管理者である必要があります。
- 認証に使用されるアカウントは、サブスクリプションのディレクトリのメンバーである必要があります。注意すべき2つのタイプのアカウントがあります。「職場または学校」と「個人用Microsoftアカウント」です。詳しくは、CTX219211を参照してください。
既存のMicrosoftアカウントは、サブスクリプションのディレクトリのメンバーとして追加することで使用できます。ただし、ユーザーが以前にディレクトリのリソースの1つにゲストアクセスを許可されていた場合は、複雑になることがあります。その場合、必要な権限を与えないディレクトリにプレースホルダーエントリが存在し、エラーが返されます。
このアクセスの問題を解決するには、ディレクトリからリソースを削除して、明示的に追加し直します。ただし、そのアカウントがアクセスできる他のリソースに対して意図しない影響を与えるため、このオプションは注意深く実行してください。
- 特定のアカウントが実際にメンバーであるときにディレクトリゲストとして検出されるという既知の問題があります。アカウントがゲストとして検出される問題は、通常、古い確立済みのディレクトリアカウントで発生します。回避策:アカウントをディレクトリに追加します。これにより適切なメンバーシップ値が取得されます。
- リソースグループはリソースのコンテナにすぎず,そのリージョン以外のリージョンのリソースを含んでいます。リソースグループのリージョンに表示されているリソースを利用しようとした場合に、リソースグループが混乱の元になる可能性があります。
- ネットワークとサブネットが、必要な数のマシンをホストするのに十分な大きさであることを確認してください。ネットワークサイズの設定にはある程度先見の明が必要ですが、Microsoftがアドレススペースの容量に関するガイダンスを用意しており、適切な値を指定できるようサポートしています。
Azure Resource Managerへのホスト接続を確立するには、次の2通りの方法があります:
- Azure Resource Managerを認証してサービスプリンシパルを作成する。
- 以前作成されたサービスプリンシパルからの詳細を使ってAzure Resource Managerに接続する。
Azure Resource Managerを認証してサービスプリンシパルを作成する
始める前に、以下の項目について確認してください。
- サブスクリプションのAzure Active Directoryテナントにユーザーアカウントがあること。
- Azure ADのユーザーアカウントが、リソースのプロビジョニングに使用するAzureサブスクリプションの共同管理者でもあること。
サイトのセットアップまたは接続およびリソースの追加ウィザードで以下を行います。
- [接続]ページで、接続の種類に[Microsoft Azure]を選択します。お使いのAzure Cloud環境を選択します。
- [接続の詳細]ページで、AzureサブスクリプションIDと接続の名前を入力します。接続名に指定できる文字数は1~64文字であり、空白スペースのみにしたり英数字以外の文字を含めたりすることはできません。サブスクリプションIDおよび接続名を入力すると、[新規作成]ボタンが有効になります。
- Azure Active Directoryアカウントのユーザー名とパスワードを入力します。
- [サインイン]をクリックします。
- [承認]をクリックして、表示された権限をCitrix Virtual Apps and Desktopsに付与します。Citrix Virtual Apps and Desktopsによって、指定されたユーザーの代わりにAzure Resource Managerリソースを管理することを許可するサービスプリンシパルが作成されます。
- [承認]をクリックすると、Studioの[接続]ページに戻ります。Azureの認証が完了すると、[新規作成]および[既存を使用]が[接続済み]に置き換わり、Azureサブスクリプションへの正常な接続を示す緑色のチェックマークが表示されます。
- 仮想マシンの作成にどのツールを使用するかを指定し、[次へ]をクリックします。(Azureの認証が完了し、必要な権限の付与を承認しない限り、ウィザードのこのページより先に進むことはできません)。
リソースには領域とネットワークが含まれます。
- [リージョン]ページで領域を選択します。
- [ネットワーク]ページで1~64文字のリソース名を入力して、Studioで領域とネットワークの組み合わせを特定できるようにします。リソース名を空白スペースのみにすることはできず、英数字以外の文字を含めることもできません。
- 仮想ネットワークとリソースグループのペアを選択します複数の仮想ネットワークを同じ名前にすることが可能なため、ネットワーク名とリソースグループをペアリングすると一意の組み合わせになります。前のページで仮想ネットワークがないリージョンを選択していると、そのページに戻ります。仮想ネットワークがあるリージョンを選択します。
- ウィザードを完了します。
以前作成されたサービスプリンシパルからの詳細を使ってAzure Resource Managerに接続する
手動でサービスプリンシパルを作成するには、Azure Resource Managerサブスクリプションに接続して、後述のPowerShellコマンドレットを使用します。
前提条件:
- $SubscriptionId:VDAをプロビジョニングするサブスクリプションのAzure Resource Manager
SubscriptionID
。 - $AADUser:サブスクリプションのADテナントに対するAzure ADユーザーアカウント。
$AADUser
をサブスクリプションの共同管理者にしてください。 - $ApplicationName:Azure AD内で作成されるアプリケーションの名前。
- $ApplicationPassword:アプリケーションのパスワード。このパスワードは、ホスト接続を作成するときのアプリケーションシークレットとして使用します。
サービスプリンシパルを作成するには、次の手順に従ってください。
Azure Resource Managerサブスクリプションに接続します。
Login-AzureRmAccount
サービスプリンシパルを作成するAzure Resource Managerサブスクリプションを選択します。
Select-AzureRmSubscription -SubscriptionID $SubscriptionId
ADテナントでアプリケーションを作成します。
$AzureADApplication = New-AzureRmADApplication -DisplayName $ApplicationName -HomePage "https://localhost/$ApplicationName" -IdentifierUris https://$ApplicationName -Password $ApplicationPassword
サービスプリンシパルを作成します。
New-AzureRmADServicePrincipal -ApplicationId $AzureADApplication.ApplicationId
サービスプリンシパルに役割を割り当てます。
New-AzureRmRoleAssignment -RoleDefinitionName Contributor -ServicePrincipalName $AzureADApplication.ApplicationId –scope /subscriptions/$SubscriptionId
PowerShellコンソールの出力ウィンドウから、ApplicationIdをメモします。このIDは、ホスト接続を作成するときに使用します。
サイトのセットアップまたは接続およびリソースの追加ウィザードで以下を行います。
- [接続]ページで、接続の種類として[Microsoft Azure]を選択し、Azure環境を選択します。
- [接続の詳細]ページで、AzureサブスクリプションIDと接続の名前を入力します。(接続名に指定できる文字数は1~64文字であり、空白スペースのみにしたり英数字以外の文字を含めたりすることはできません。
- [既存を使用]をクリックします。サブスクリプションID、サブスクリプション名、認証URL、管理URL、ストレージのサフィックス、Active Directory IDまたはテナントID、アプリケーションID、および既存のサービスプリンシパルのアプリケーションシークレット。詳細を入力すると、[OK]ボタンが有効になります。[OK]をクリックします。
- 仮想マシンの作成にどのツールを使用するかを指定し、[次へ]をクリックします。入力したサービスプリンシパルの詳細は、Azureサブスクリプションへの接続に使用されます([既存を使用] オプションで有効な詳細を入力しない限り、ウィザードの次のページに進めません)。
リソースには領域とネットワークが含まれます。
- [リージョン]ページで領域を選択します。
- [ネットワーク]ページで1~64文字のリソース名を入力して、Studioで領域とネットワークの組み合わせを特定できるようにします。リソース名を空白スペースのみにすることはできず、英数字以外の文字を含めることもできません。
- 仮想ネットワークとリソースグループのペアを選択します(複数の仮想ネットワークを同じ名前にすることが可能なため、ネットワーク名とリソースグループをペアリングすると一意の組み合わせになります)。前のページで仮想ネットワークのない領域を選択した場合は、前のページに戻って仮想ネットワークのある領域を選択する必要があります。
- ウィザードを完了します。
Azure Resource Managerマスターイメージを使用してマシンカタログを作成する
これは、「マシンカタログの作成」のガイダンスを補完する情報です。
マスターイメージは、マシンカタログの仮想マシンの作成に使用されることになるテンプレートです。マシンカタログを作成する前に、Azure Resource Managerでマスターイメージを作成します。マスターイメージの一般的な情報については、「マシンカタログの作成」を参照してください。
Studioでのマシンカタログを作成する場合は、以下を確認してください。
- [オペレーティングシステム]ページと[マシン管理]ページには、Azure固有の情報は含まれていません。「マシンカタログの作成」のガイダンスに従ってください。
- [マスターイメージ]ページで、リソースグループを選択します。コンテナ内で、マスターイメージとして使用するAzure VHDまで移動します。VHDにはCitrix VDAがインストールされている必要があります。仮想マシンにVHDが接続されている場合、仮想マシンを停止する必要があります。
[ストレージとライセンスの種類]ページは、Azure Resource Managerマスターイメージを使用しているときのみ表示されます。
ストレージの種類(StandardまたはPremium)を選択します。ストレージの種類によって、[仮想マシン]ページで提供されるマシンのサイズが変わります。これらのストレージの種類はどちらも、単一のデータセンター内でデータの複数の同期コピーを作成します。Azureのストレージの種類およびストレージの複製について詳しくは、以下のドキュメントを参照してください:
- https://docs.microsoft.com/en-us/azure/storage/common/storage-introduction
- https://docs.microsoft.com/en-us/azure/virtual-machines/premium-storage-performance
- https://docs.microsoft.com/en-us/azure/storage/common/storage-redundancy
既存のオンプレミスのWindows Serverライセンスを使用するかを選択します。既存のオンプレミスのWindows Serverイメージを使用する場合にそのように選択すると、Azure Hybrid Use Benefits(HUB)が利用されます。詳しくは、https://azure.microsoft.com/pricing/hybrid-use-benefit/を参照してください。
HUBにより、Azureでの仮想マシン実行のコストを基本計算料金まで引き下げることができます。Azureギャラリーからの追加のWindows Serverライセンスの価格は無料です。HUBを使用するためのオンプレミスのWindows ServerイメージをAzureに用意する必要があります。Azureギャラリーのイメージはサポートされません。オンプレミスのWindows Clientライセンスは、現在サポートされていません。
プロビジョニングされた仮想マシンがHUBを正常に利用しているかどうかを確認します。PowerShellコマンド「
Get-AzureRmVM -ResourceGroup MyResourceGroup -Name MyVM
」を実行し、ライセンスの種類がWindows_Server
であることを確認します。詳しくは、https://docs.microsoft.com/en-us/azure/virtual-machines/windows/hybrid-use-benefit-licensing/を参照してください。[仮想マシン]ページで、作成する仮想マシンの数を指定します。少なくとも1つは指定してください。マシンのサイズを選択します。マシンカタログを作成した後で、マシンのサイズを変更することはできません。後で他のサイズに変更したくなった場合は、カタログを削除してから、同じマスターイメージを使用したカタログを作成し、希望のマシンサイズを指定します。
仮想マシンの名前に、ASCII以外の文字や特殊文字を含めることはできません。
(MCSを使用する場合)[リソースグループ]ページで、リソースグループを作成するか、既存のグループを使用するかを選択します。
リソースグループを作成する場合は、[次へ]をクリックします。
既存のリソースグループを使用する場合は、[使用可能なプロビジョニングリソースグループ]ボックスの一覧からグループを選択します。カタログで作成しているマシンを収容するのに十分なグループを選択してください。少なすぎると、Studioにメッセージが表示されます。後でカタログにさらにVMを追加する予定がある場合は、必要最小限よりも多く選択しておくことをお勧めします。カタログが作成された後、カタログにリソースグループをさらに追加することはできません。
詳しくは、「Azureリソースグループ(#azure-resource-groups)」を参照してください。
- [ネットワークカード]ページ、[コンピューターアカウント]ページ、および[概要]ページには、Azure固有の情報は含まれていません。「マシンカタログの作成」のガイダンスに従ってください。
ウィザードを完了します。
マシンカタログを削除する
Azure Resource Managerマシンカタログを削除すると、関連するマシンとリソースグループを保持するように指定しても削除されます。
Azureリソースグループ
Azureプロビジョニングのリソースグループは、アプリケーションとデスクトップをユーザーに提供するVMをプロビジョニングする方法を提供します。StudioでMCSマシンカタログを作成するときに既存の空のAzureリソースグループを追加するか、新しいリソースグループを作成します。
Azureリソースグループについて詳しくは、Microsoft社のドキュメントを参照してください。
要件
各リソースグループは、最大240のVMを保持できます。カタログを作成するリージョンには、十分な数の空のリソースグループがなければなりません。マシンカタログを作成するときに既存のリソースグループを使用する場合は、カタログに作成されるマシンの数を収容するのに十分な数の使用可能なグループを選択します。たとえば、カタログ作成ウィザードで500台のマシンを指定する場合は、少なくとも3つの使用可能なプロビジョニングリソースグループを選択します。
マシンカタログが作成された後、そのカタログにリソースグループを追加することはできません。したがって、後でカタログに追加する可能性のあるマシンを収容するのに十分な数のリソースグループを追加しておいてください。
- ホスト接続と同じリージョンに空のリソースグループを作成します。
- MCSカタログごとにリソースグループを作成する場合は、ホスト接続に関連付けられているAzureサービスプリンシパルを設定します。このプリンシパルには、リソースグループを作成および削除する権限が必要です。既存の空のリソースグループを使用する場合は、ホスト接続に関連付けられているAzureサービスプリンシパルに、それらの空のリソースグループでの投稿者の権限が必要です。
- [新規作成]オプションを使用してStudioでホスト接続を作成すると、作成したサービスプリンシパルにサブスクリプションスコープの投稿権限が設定されます。または、[既存を使用]オプションを使用して接続を作成し、既存のサブスクリプションスコープのサービスプリンシパルの詳細を指定することもできます。[新規作成]オプションを使用して、Studioでサービスプリンシパルを作成します。このプリンシパルには、新しいリソースグループの作成と削除、または既存の空のリソースグループへのプロビジョニングに必要な権限が設定されます。
スコープが狭いサービスプリンシパルは、PowerShellを使用して作成する必要があります。さらに、スコープが狭いサービスプリンシパルを使用するときは、PowerShellまたはAzure Portalを使用して、MCSがVMをプロビジョニングする各カタログ用の空のリソースグループを作成する必要があります。
ホスト接続にスコープが狭いサービスプリンシパルを使用していて、カタログ作成ウィザードの[マスターイメージ]ページにマスターイメージリソースグループが表示されない場合は、使用しているスコープが狭いサービスプリンシパルに、マスターイメージリソースグループを一覧表示するための
Microsoft.Resources/subscriptions/resourceGroups/read
権限がないことが原因と考えられます。ウィザードを閉じ、この権限を設定してサービスプリンシパルを更新してから(手順については、ブログの投稿を参照)、ウィザードを再起動します。Azureでの更新がStudioに反映されるまで最大10分かかることがあります。
Azureサービスプリンシパルについて
Azure Resource Managerでマシンをプロビジョニングするには、プラグインにAzureサブスクリプションへのアクセス権限を付与する必要があります。これらのアクセス権限は、関連するAzureリソースへのアクセス権限が割り当てられているサービスプリンシパルを介して付与されます。サービスプリンシパルは、ユーザーアカウントと同じ基本的な目的を果たします。このサービスプリンシパルは、Azureリソースに対する認証とアクセス許可の資格情報を提供するAzure Active Directory IDをプラグインに提供します。ユーザーアカウントと同様に、サービスプリンシパルは役割ベースのアクセス制御(RBAC)を使用して設定されます。
権限の定義方法に応じて、サービスプリンシパルは次のように分類されます:
サブスクリプションスコープのサービスプリンシパル
スコープが狭いサービスプリンシパル
サブスクリプションスコープのサービスプリンシパル
サブスクリプションスコープのサービスプリンシパルは、サブスクリプション内のすべてのリソースに対する投稿者の権限を持っているため、作成と管理を容易に行うことができます。Citrix Studioでは、サブスクリプションスコープのサービスプリンシパルの作成プロセスを自動化するか、PowerShellで手動で作成することができます。これらのプリンシパルにより、Azure Resource ManagerプラグインでAzureリソースグループを作成し、リソースの管理を完全に自動化できます。欠点は、プラグインが管理を担当するリソースとは無関係な、サブスクリプション内のリソースに対する権限がプラグインにあることです。
投稿者の役割を使用すると、サブスクリプション内のすべてのリソースの作成、削除、読み取り、および書き込みをプラグインで行うことができます。権限はAzure Active Directory内のオブジェクトには拡張されず、サブスクリプションスコープのサービスプリンシパルで他のユーザーまたはサービスプリンシパルにリソースへのアクセスを許可することもできません。
スコープが狭いサービスプリンシパル
スコープが狭いサービスプリンシパルを使用すると、Azure Resource Managerプラグインから、ユーザーが定義した限定されたリソースセットにアクセスできます。Azureでは、リソースグループを作成するには、サブスクリプションスコープの権限が必要です。スコープが狭いサービスプリンシパルを使用する場合、プラグインではリソースグループを作成できません。サービスプリンシパルに加えて、マシンをプロビジョニングするカタログごとに、リソースグループのプールを提供する必要があります。
Citrix Studioでは、スコープが狭いサービスプリンシパルまたはカタログの作成はサポートされていません。これらのタスクはいずれもPowerShellを使用して実行する必要があります。ただし、一度作成したカタログは、マシンの追加や削除など、Studioの他のカタログと同様に管理できます。ある時点で、既存のスコープが狭いサービスプリンシパルを新しいリソースグループのプールで使用する場合は、PowerShellを使用してサービスプリンシパルに権限を明示的に追加する必要があります。
Azureサブスクリプションのアクセス要件の定義
次のセクションの技法と例は、一般的な要件を示しており、固有の状況に応じて変更する必要があります。
以下の場合は、サブスクリプションスコープのサービスプリンシパルの使用を検討してください:
最もシンプルな管理エクスペリエンスを必要としている。
PowerShellの使用を避けて、Citrix Studioですべてを管理したい。
Azureサブスクリプションが、1つのCitrix Virtual Apps and Desktopsサービス専用となっている。
Citrix Virtual Apps and Desktopsのインストールの概念実証を行っている。
Citrix Virtual Apps and Desktops管理者が、Azureサブスクリプションスコープで投稿者にアクセスさせている。
以下の場合は、スコープが狭いサービスプリンシパルを使用することを検討してください:
Azureサブスクリプションが複数の無関係なサービスをホストしている。
Azure管理者が、役割に応じて異なるサブスクリプションの権限を持っている。
会社が、非常に細かいレベルでのアクセス制御を必要とするセキュリティ基準を設けている。
スコープが狭いサービスプリンシパルを作成するための既存のプロセスがある。
ヒント:
プライマリサブスクリプションの一部として請求される子サブスクリプションを作成し、プライマリサブスクリプションのデフォルトのAzure Active Directoryを参照できます。この設定で、関連のないリソースへのアクセスを制御する別のメカニズムを使用できます。
スコープが狭いサービスプリンシパルのカタログの計画
スコープが狭いサービスプリンシパルのカタログを作成する前に、ホストする初期および将来的な数の仮想マシンに必要なリソースグループの数を判断します。Machine Creation Servicesの制限により、カタログの作成後にリソースグループを追加することはできません。
リソースグループプールごとに1つのカタログのプロビジョニング
Azure Resource Managerプラグインでは、各リソースグループに必要なインフラストラクチャを作成します。リソースグループは、ストレージアカウント、セキュリティグループ、ネットワークインターフェイス、仮想マシンなどで構成されます。ストレージアカウントは、マシンがカタログに追加される場合に必要に応じて作成されます。つまり、カタログのサイズは、リソースグループプールとAzureサブスクリプションクォータのサイズによって設定された上限まで大きくなる可能性があります。ストレージアカウントを作成すると、カタログを削除しない限り削除されることはありません。どの仮想マシンも削除できるため、ストレージアカウントが空になる可能性があります。仮想マシンは使用可能なストレージアカウントにランダムに分散される傾向があるため、このような状況はまれです。ストレージアカウントを意図的に空にするには、ストレージアカウントのコンテンツを検査することによって、マシンを単純に繰り返し選択する必要があります。
Azureでは、リソースグループ内の仮想マシンの数は800に制限されていますが、Azure Resource Managerプラグインでは異なる基準が使用されます。標準のAzureディスクには、1秒あたりのI/O操作(IOPS)が500という制限があり、標準のストレージアカウントのIOPS制限は20,000です。このため、プラグインは40台以下のマシンをストレージアカウントにプロビジョニングします。この制限は、標準ストレージとプレミアムストレージの両方に適用されます。さらに、プラグインでは、1つのリソースグループに19個以下のストレージアカウントを作成します。
したがって、マシンの最大数に基づいてリソースグループ数を計算する基本的な式は次のとおりです:
リソースグループの数=上限(マシンの最大数/(40 * 19))
Azure资源管理器プラグインは,リソースグループのプールを排他的に使用することを前提としています。指定されたリソースグループには、ユーザーが作成したリソースはありません。
Azureの役割ベースのアクセス制御( RBAC)の基礎。
Azureリソースへのアクセスは、特定のスコープでサービスプリンシパルにRBACの役割を割り当てることによって許可されます。スコープには、サブスクリプション、リソースグループ、または特定のリソースを指定できます。リソースはコンテインメント階層に配置され、役割によって定義された権限は、適用されるスコープの下位のすべてのリソースに適用されます。サブスクリプションに適用される役割は、サブスクリプション内のすべてのリソースに適用されます。リソースグループに適用される役割は、そのリソースグループに含まれるすべてのリソースに適用されます。
Azureリソース階層が意味するのは、サブスクリプションスコープの権限を持つサービスプリンシパルだけがリソースグループを作成できるということです。プラグインのようなアプリケーションは、論理グループに対してオンデマンドでリソースグループを作成してリソースを管理できないため、最適ではありません。サブスクリプション全体に対する広範な権限を持っていない限り、これに該当します。
Azureには組み込みの役割が多数用意されており、カスタム役割の定義もサポートしています。Azure RBACのカスタムロールについて詳しくは、「Azureリソースのカスタム役割」を参照してください。
サブスクリプションスコープのサービスプリンシパルの作成
この例では、サブスクリプションスコープのサービスプリンシパルを作成する方法を説明します。詳細情報を利用して、Citrix StudioでAzure接続を作成できます。既存のサービスプリンシパルを使用するか、Azure接続をPowerShellで手動で作成するかを選択します。
参数([string] applicationName美元= " SubscriptionScopeSP", [Parameter(Mandatory=$true)][string]$applicationPassword, [Parameter(Mandatory=$true)][string]$subscriptionId ) $application = New-AzureRmADApplication -DisplayName $applicationName -HomePage "https://localhost/$applicationName" ` -IdentifierUris "https://$applicationName" -Password $applicationPassword New-AzureRmADServicePrincipal -ApplicationId $application.ApplicationId # Wait for the service principal to become available Start-Sleep -s 60 New-AzureRmRoleAssignment -RoleDefinitionName Contributor -ServicePrincipalName $application.ApplicationId ` -scope "/subscriptions/$subscriptionId" Write-Host ("Application ID: " + $application.ApplicationId)
スコープが狭い基本のサービスプリンシパルの作成
このセクションでは、リソースグループスのコープで権限が割り当てられる、スコープが狭い最もシンプルなサービスプリンシパルを作成するプロセスについて説明します。
Azure Resource Managerプラグインには、以下のリソースに対する権限が必要です:
マスターイメージVHD
マシンの仮想ネットワーク
マシンをプロビジョニングするリソースグループ
スクリプトを簡略化するため、リソースグループのスコープで投稿者のアクセスを許可できると仮定します。Azure Resource Managerプラグインには、イメージVHDが格納されるリソースグループ、仮想ネットワークを含むリソースグループ、およびマシンがプロビジョニングされるリソースグループプールに対する投稿者の権限があります。
param( [string]$applicationName = "BasicNarrowScopeSP", [Parameter(Mandatory=$true)][string]$applicationPassword, [Parameter(Mandatory=$true)][string]$subscriptionId, [Parameter(Mandatory=$true)][string[]]$resourceGroups ) $application = New-AzureRmADApplication -DisplayName $applicationName -HomePage "https://localhost/$applicationName" ` -IdentifierUris "https://$applicationName" -Password $applicationPassword New-AzureRmADServicePrincipal -ApplicationId $application.ApplicationId # Wait for the service principal to become available Start-Sleep -s 60 New-AzureRmRoleAssignment -RoleDefinitionName Citrix-Network-Usage-Reader -ServicePrincipalName $application.ApplicationId ` -scope "/subscriptions/$subscriptionId/" foreach ($rg in $resourceGroups) { New-AzureRmRoleAssignment -RoleDefinitionName Contributor -ServicePrincipalName $application.ApplicationId ` -scope "/subscriptions/$subscriptionId/resourcegroups/$rg" } Write-Host ("Application ID: " + $application.ApplicationId)
カスタム役割を使用したスコープが狭いサービスプリンシパルの作成
Azureには、組み込みのRBAC役割の大規模なセットが付属しています。直前のセクションの投稿者の役割をCitrixで使用します。前述のように、Azure Resource Managerプラグインで、厳密に必要とされるよりもわずかに広範な権限を付与しました。このセクションでは、カスタム役割を定義して権限を絞ります。必要に応じて、より多くのカスタム役割を使用し、イメージおよびネットワークリソースに直接役割を適用して、アクセスをロックできます。
注:
必要な権限は変更となる可能性があります。
リソースグループのスコープで仮想ネットワークおよびマスターイメージへのアクセスを許可するカスタム役割を定義するには、以下の権限を使用します。
マスターイメージVHD。
カタログ作成の場合:
Microsoft.Storage/storageAccounts/read
Microsoft.Storage/storageAccounts/listKeys/action
今後のCitrixスタジオのサポートにて:
- Microsoft.Resources/subscriptions/resourceGroups/read
マシンの仮想ネットワーク:
Microsoft.Network/virtualNetworks/read
Microsoft.Network/virtualNetworks/subnets/join/action
プロビジョニングされたマシンのリソースグループ。
以下の権限を持つ別のカスタムロールを作成することもできますが、例をシンプルにするために、引き続きマシンリソースグループに対して投稿者の役割を使用します。これらのリソースグループには、Azure Resource Managerプラグインによって作成されていないリソースは含まれていません。投稿者の役割を使用すると、プラグインに対する変更のために、サービスプリンシパルに変更を行う必要性が低くなります:
Microsoft.Compute/virtualMachines/*
Microsoft.Network/networkInterfaces/*
Microsoft.Network/networkSecurityGroups/*
Microsoft.Resources/deployments/*
Microsoft.Resources/subscriptions/resourceGroups/read
Microsoft.Storage/storageAccounts/*
Microsoft.Storage/storageAccounts/listKeys/action
Citrix Virtual Apps and Desktopsカスタムアクセス権役割。
先にJSONで定義してカスタム役割を作成します:
{ "Name": "Citrix-Custom-Reader", "Description": "Grants access to Citrix XenDesktop images and virtual networks.", "Actions": [ "Microsoft.Storage/storageAccounts/read", "Microsoft.Storage/storageAccounts/listKeys/action", "Microsoft.Network/virtualNetworks/read", "Microsoft.Network/virtualNetworks/subnets/join/action" ], "NotActions": [ ], "AssignableScopes": [ "/subscriptions/" ] }
JSON定義を参照して役割を作成します:
New-AzureRmRoleDefinition -InputFile citrix-custom-reader.json
サービスプリンシパルを作成するときに新しいカスタム役割を使用します:
param( [string]$applicationName = "NarrowScopeSP", [Parameter(Mandatory=$true)][string]$applicationPassword, [Parameter(Mandatory=$true)][string]$subscriptionId, [Parameter(Mandatory=$true)][string[]]$machineResourceGroups, [Parameter(Mandatory=$true)][string]$imageResourceGroup, [Parameter(Mandatory=$true)][string]$networkResourceGroup ) $application = New-AzureRmADApplication -DisplayName $applicationName -HomePage "https://localhost/$applicationName" ` -IdentifierUris "https://$applicationName" -Password $applicationPassword New-AzureRmADServicePrincipal -ApplicationId $application.ApplicationId # Wait for the service principal to become available Start-Sleep -s 60 New-AzureRmRoleAssignment -RoleDefinitionName Citrix-Network-Usage-Reader -ServicePrincipalName $application.ApplicationId ` -scope "/subscriptions/$subscriptionId/" foreach ($rg in $machineResourceGroups) { New-AzureRmRoleAssignment -RoleDefinitionName Contributor -ServicePrincipalName $application.ApplicationId ` -scope "/subscriptions/$subscriptionId/resourcegroups/$rg" } New-AzureRmRoleAssignment -RoleDefinitionName Citrix-Custom-Reader -ServicePrincipalName $application.ApplicationId ` -scope "/subscriptions/$subscriptionId/resourcegroups/$imageResourceGroup" New-AzureRmRoleAssignment -RoleDefinitionName Citrix-Custom-Reader -ServicePrincipalName $application.ApplicationId ` -scope "/subscriptions/$subscriptionId/resourcegroups/$networkResourceGroup" Write-Host ("Application ID: " + $application.ApplicationId)
Citrix Virtual Apps and DesktopsのAzure接続の作成。
既存のサービスプリンシパルを使用して、Citrix StudioでCitrix Virtual Apps and DesktopsのAzure接続を作成すると合理的です。PowerShellで接続を作成することも同様に合理的です。
PowerShellで接続を作成する例を以下に示します:
param( [string]$connectionName = "AzureConnection", [Parameter(Mandatory=$true)][string]$applicationId, [Parameter(Mandatory=$true)][string]$applicationPassword, [Parameter(Mandatory=$true)][string]$subscriptionId, [Parameter(Mandatory=$true)][string]$subscriptionName, [Parameter(Mandatory=$true)][string]$tenantId ) Add-PsSnapin Citrix* $customProperties = @" "@ $connection = New-Item -ConnectionType "Custom" -CustomProperties $customProperties -HypervisorAddress @("https://management.azure.com/") ` -Path @("XDHyp:\Connections$connectionName") -Persist -PluginId "AzureRmFactory" -Scope @() ` -SecurePassword (ConvertTo-SecureString -AsPlainText -Force $applicationPassword) -UserName $applicationId New-BrokerHypervisorConnection -HypHypervisorConnectionUid $connection.HypervisorConnectionUid
この時点で、StudioまたはPowerShellのいずれかを使用して、接続にリソースを追加します。
Citrix Virtual Apps and Desktopsのカタログの作成。
次の例では、Citrix PowerShellスナップインを使用して、Citrix Virtual Apps and Desktopsのカタログを作成します。
スコープが狭いサービスプリンシパルでは、Azure Resource Managerプラグインでリソースグループを作成できないため、以下の操作を行う必要があります:
リソースグループのプールを作成します。
リソースグループのプール内のすべてのリソースグループに、サービスプリンシパルの権限を割り当てます。
プロビジョニングスキームの作成時に、リソースグループの各リソースグループをカスタムプロパティにリストします。
このカスタムプロパティはResourceGroupsという名前で、値はリソースグループ名のコンマ区切りリストとなっています。このカスタムプロパティを定義する方法の例を次の例に示します。
注:
カスタムプロパティには、マシン用のリソースグループのみが表示されます。イメージまたは仮想ネットワークが配置されている1つ以上のリソースグループは含まれていません。これらが指定されている場合、Azure Resource Managerプラグインはこれらのリソースグループにマシンをプロビジョニングしようとするため、意図しない動作が発生する可能性があります。
この例では、xd-sales-1とxd-sales-2という名前の2つのリソースグループにマシンがプロビジョニングされます:
Add-PsSnapin Citrix * #主办单位名称是the name of the Azure connection resources that should be used for this catalog $hostingUnitName = "AzureHostingUnit" $domain = "citrix.local" $controllerAddress = ("ddc." + $domain) $adminAddress = ($controllerAddress + ":80") $catalogName = "catalog-name" $network = "network-resource-group.resourcegroup\network-name" $subnet = "subnet-name" $serviceOffering = "Standard_A4" $template = "image-resource-group.resourcegroup\imagestorage.storageaccount\images.container\image-name.vhd" $customProperties = @" "@ $identityPool = New-AcctIdentityPool -AdminAddress $adminAddress -AllowUnicode -Domain $domain ` -IdentityPoolName $catalogName -NamingScheme "vm-#" -NamingSchemeType "Numeric" -Scope @() $brokerCatalog = New-BrokerCatalog -AdminAddress $adminAddress -AllocationType "Random" -IsRemotePC $False ` -MinimumFunctionalLevel "L7_9" -Name $catalogName -PersistUserChanges "Discard" -ProvisioningType "MCS" -Scope @() ` -SessionSupport "MultiSession" Write-Host $brokerCatalog $provScheme = New-ProvScheme -AdminAddress $adminAddress -CleanOnBoot -CustomProperties $customProperties ` -HostingUnitName $hostingUnitName -IdentityPoolName $catalogName ` -MasterImageVM "XDHyp:\HostingUnits$hostingUnitName\image.folder$template.vhd" ` -NetworkMapping @{"0"="XDHyp:\HostingUnits$hostingUnitName\virtualprivatecloud.folder$network.virtualprivatecloud$subnet.network"} ` -ProvisioningSchemeName $catalogName -Scope @() -SecurityGroup @() ` -ServiceOffering "XDHyp:\HostingUnits$hostingUnitName\serviceoffering.folder$serviceOffering.serviceoffering" Write-Host $provScheme Set-BrokerCatalog -AdminAddress $adminAddress -Name $catalogName -ProvisioningSchemeId $provScheme.ProvisioningSchemeUid Add-ProvSchemeControllerAddress -AdminAddress $adminAddress.com -ControllerAddress $controllerAddress -ProvisioningSchemeName $catalogName
この時点で、Citrix Studioのカタログページの更新、マシンの追加、他のカタログと同様のマシンの管理を行うことができます。
Studioでマシンカタログのリソースグループを構成する
カタログ作成ウィザードの[リソースグループ]ページでは、リソースグループを作成するか、既存のグループを使用するかを選択できます。「Azure Resource Managerマスターイメージを使用してマシンカタログを作成する」を参照してください。
マシンカタログを削除したときのリソースグループへの影響:
マシンカタログを作成するときにCitrix Virtual Apps and Desktopsでリソースグループを作成した場合は、その後でそのカタログを削除すると、それらのリソースグループとそれらのリソースグループ内のすべてのリソースも削除されます。
マシンカタログを作成するときに既存のリソースグループを使用した場合は、その後でそのカタログを削除すると、それらのリソースグループのすべてのリソースは削除されますが、リソースグループは削除されません。
注意事項、制限事項、およびトラブルシューティング
既存のリソースグループを使用する場合,カタログ作成ウィザードの[リソースグループ]ページの使用可能なリソースグループの一覧は自動更新されません。したがって、このウィザードページを開き、Azureでリソースグループの権限を作成または追加した場合、その変更はウィザードの一覧に反映されません。最新の変更を表示するには、ウィザードの[マシン管理]ページに戻り、ホスト接続に関連するリソースを再選択するか、ウィザードを閉じて再起動します。Azureでの変更がStudioに反映されるまで最大10分かかることがあります。
1つのリソースグループは、1つのマシンカタログでのみ使用する必要があります。ただし、これは強制されません。たとえば、カタログを作成するときに10個のリソースグループを選択しましたが、カタログに1台のマシンしか作成しなかったとします。選択したリソースグループのうち9つは、カタログの作成後も空のままです。それらのリソースグループは、将来の容量拡張時に使用するかもしれないので、そのカタログに関連付けられたまま残されます。カタログが作成された後、カタログにリソースグループを追加することはできないため、将来の拡張について計画する必要があります。ただし、別のカタログが作成された場合、これらの9つのリソースグループが使用可能な一覧に表示されます。現在、Citrix Virtual Apps and Desktopsでは、どのリソースグループがどのカタログに割り当てられているかを把握していません。それを監視するのは管理者の責任です。
接続で、さまざまなリージョンの空のリソースグループにアクセスできるサービスプリンシパルが使用されている場合、それらはすべて利用可能な一覧に表示されます。マシンカタログを作成するリージョンと同じリージョンのリソースグループを選択してください。
トラブルシューティング:
カタログ作成ウィザードの[リソースグループ]ページの一覧にリソースグループが表示されません。
サービスプリンシパルで、一覧に表示するリソースグループに適切な権限が適用されていることが必要です。上記の「要件」のセクションを参照してください。
以前に作成したマシンカタログにマシンを追加する場合、すべてのマシンがプロビジョニングされるわけではありません。
カタログを作成した後でカタログにマシンを追加する場合は、最初にそのカタログ用に選択したリソースグループのマシン容量(グループあたり240個)を超えないようにしてください。カタログが作成された後にリソースグループを追加することはできません。既存のリソースグループが収容できる以上のマシンを追加しようとすると、プロビジョニングが失敗します。
たとえば、300のVMと2つのリソースグループを持つマシンカタログを作成したとします。リソースグループは、最大480のVM(240 * 2)を収容できます。後で200のVMをカタログに追加しようとすると、リソースグループの容量を超えます(現在の300のVM + 200の新しいVM = 500ですがリソースグループは480しか保持できません)。