Product Documentation

Delivery Controller

Mar 25, 2016

Delivery Controllerは、ユーザーアクセスの管理や接続の仲介と最適化を行うためのサーバー側のコンポーネントです。 また、Controllerは、デスクトップおよびサーバーイメージを作成するMachine Creation Serviceも提供します。

サイトには、1つ以上のControllerが必要です。 1つめのControllerのインストール後、サイトを作成するとき、または後日、さらにControllerを追加できます。 サイトに複数のControllerがあると、以下の2つの利点がもたらされます。

  • 冗長性 — 実務サイトでのベストプラクティスとして、物理サーバー上で動作するControllerを2台以上配置します。 一方のControllerに障害が発生しても、他方のControllerで接続を管理し、サイトを制御できます。
  • スケーラビリティ — サイトのアクティビティが増えるにつれ、Controller上のCPU使用量およびデータベースアクティビティも増えます。 Controllerを追加すると、より多くのユーザーやより多くのアプリケーションやデスクトップ要求を処理できるようになり、制御処理全体を向上させることができます。

各Controllerは、サイトデータベースと直接通信を行います。 複数のゾーンを持つサイトでは、各ゾーンに存在するControllerが、プライマリゾーンにあるサイトデータベースと通信します。

ヒント:サイトの構成後、コンピューター名やControllerのドメインメンバーシップを変更しないでください。

VDAによるControllerの検出方法

VDAを使用するには、そのサイトのControllerに登録(接続を確立)する必要があります。 VDAはListOfDDCsと呼ばれるControllerの一覧をチェックしてControllerを見つけます。 ListOfDDCsは、そのサイトのControllerのDNSエントリまたはIPアドレスで構成されています。 負荷分散のため、VDAは一覧のすべてのControllerで接続を自動的に分散させます。

ListOfDDCsに加えて、ListOfSIDsと呼ばれるControllerのマシンセキュリティID(SID)一覧により、VDAがアクセスできるControllerが指定されます。 ListOfSIDsは、Active Directoryでの負荷を軽減したり、改ざんされたDNSサーバーからのセキュリティ上の脅威を防いだりするために使用できます。

サイト内でControllerの追加や削除に伴って、すべてのVDA上のListOfDDCsおよびListOfSIDsが確実に更新されるようにすることが重要です。 これらの一覧を正しく更新しない場合、一覧にないControllerで仲介されたセッションがVDAで拒否される可能性があります。 また、無効なエントリにより、仮想デスクトップシステムソフトウェアの起動に遅延が生じることがあります。 これらの一覧は、以下の方法で更新できます。

  • 自動更新 — Controllerが追加または削除されたときに、ListOfDDCsおよびListOfSIDsを自動的に更新します。 デフォルトでは、自動更新が有効になっています。
  • 自己管理 — Controllerを識別するためのポリシーやレジストリ設定を手動で更新します。

ListOfDDCsおよびListOfSIDsに含まれている情報は、展開内の複数の場所で参照されます。 VDAは以下の場所を順にチェックして、最初に見つかった一覧を使用します。

  1. 自動更新機能により維持される永続的なストレージ。 自動更新が有効な場合、VDAのインストール直後の初回登録以降では、ここにController情報が格納されます (このストレージには、マシンのポリシー情報も格納されています。これにより、再起動しても、ポリシー設定が保持されます)。インストール直後の初回登録時、または自動更新が無効な場合、VDAは以下の場所をチェックします。
  2. ポリシー設定(Controller、Controller SID)。
  3. レジストリのVirtual Desktop Agentキーの下のController情報。 これらの値は、VDAのインストール時に指定するController情報に基づいて、VDAのインストーラーにより設定されます。
  4. 組織単位ベースのController検出。 これは、後方互換性を維持するための従来の方法です。
  5. Machine Creation Servicesにより作成されるPersonality.iniファイル。

ListOfDDCsに複数のControllerが指定されている場合、VDAはランダムな順序で接続を試行します。 ListOfDDCsには、複数のControllerのエントリを角かっこで囲んだControllerグループを含めることもできます。 VDAは、これらのグループ内の各Controllerへの接続を試行し、その後でほかのエントリを試行します。

Version 7.0より前のXenDesktopをアップグレードした場合は、従来のCNAME機能が自動更新機能に置き換えられます。 必要な場合は手動でCNAME機能を再度有効にすることができますが、DNSエイリアスの整合性に問題が生じるため、自動更新機能とCNAME機能の両方を使用することはできません。 CNAME機能の再有効化について詳しくは、CTX137960を参照してください。

複数のゾーンを持つサイトでVDAがどこに登録を試行するかについて、詳しくは、「ゾーン」の記事を参照してください。

自動更新または自己管理を選択する場合の考慮事項

自動更新機能は、ポリシー設定によりデフォルトで有効になっています。

以下の様なサイトでは自動更新を使用できないため、自己管理を行う必要があります。

  • Controllerグループを使用する展開。
  • セキュリティ上の理由によりListOfSIDsを使用する展開 (Active Directoryの負荷軽減のためにListOfSIDsを使用する場合は自動更新を使用できます)。
  • ライトバックディスクなしでProvisioning Servicesを使用する展開。
  • [Controller]または[コントローラーSID]ポリシー設定を使用する展開。

自動更新

[コントローラーの自動更新を有効にする]ポリシー設定は、Virtual Delivery Agentカテゴリにあります。 自動更新を有効にするには、このポリシー設定を有効にします。これはデフォルトです。 自動更新を無効にするには、このポリシー設定を無効にします。

自動更新が有効な環境でVDAをインストールする場合、VDAのインストール時に指定したいずれかのControllerにVDAが登録されます。 VDAのインストール時に指定したController情報は、インストーラーによりListOfDDCsレジストリ値に書き込まれます。

VDAをControllerに登録すると、登録先のControllerにより環境内のControllerの完全修飾ドメイン名(FQDN)およびセキュリティID(SID)の一覧がVDAに送信されます。 この一覧の内容は、VDAにより自動更新用の永続的なストレージに書き込まれます。 また、各Controllerは90分ごとにサイトのデータベースにアクセスして、Controllerの追加や削除、およびポリシーの変更内容について確認し、登録したVDAに更新情報を送信します。 VDAは、受信した最新の一覧に基づいてすべてのControllerからの接続を受け入れます。

VDAが受信した一覧に登録先のControllerが含まれていない場合(つまりそのControllerがサイトから削除された場合)、一覧のいずれかのControllerにVDAが再登録されます。 VDAの登録または再登録が完了すると、新しい一覧を受信します。

次に例を示します。

  1. 環境内に3つのControllerであるA、B、Cがあります。 VDAをインストールしたときに、そのVDAが(インストール時に指定した)Controller Bに登録されます。
  2. サイトに2つのController(DおよびE)を追加します。 90分以内に、更新された一覧がVDAに送信されます。これにより、VDAはController A、B、C、D、Eからの接続を受け入れるようになります (VDAを再起動するまでは、すべてのController間で負荷分散は行われません)。
  3. サイトからController Bを削除します。 前回のチェック以降にサイトのControllerに変更があったため、90分以内にVDAは更新済みの一覧を受信します。 手順1.でインストールしたVDAはController Bに登録されていましたが、このControllerは一覧から削除されているため現在のController(A、C、D、E)のいずれかに再登録されます。

自己管理

自動更新機能を使用しない場合は、サイトのDelivery Controllerを追加、移動、または削除した後で、そのサイトにある各VDAのCitrixポリシー設定またはレジストリ値を管理者が更新する必要があります。 レジストリの変更は、グループポリシーオブジェクトを使って更新することもできます。

Citrixポリシー設定を使って自己管理するには

  1. [Controller]ポリシー設定で指定した完全修飾ドメイン名値を更新します。 このポリシー設定は、[Virtual Delivery Agent設定]カテゴリにあります。
  2. ListOfSIDsを併用している環境では、[コントローラーSID]ポリシー設定で指定したSID値を更新します。

レジストリを使って自己管理するには

注意:レジストリエディターの使用を誤ると、深刻な問題が発生する可能性があり、Windowsの再インストールが必要になる場合もあります。 レジストリエディターの誤用による障害に対して、Citrixでは一切責任を負いません。 レジストリエディターは、お客様の責任と判断の範囲でご使用ください。 また、レジストリファイルのバックアップを作成してから、レジストリを編集してください。

  1. サイトのすべてのControllerの完全修飾ドメイン名の一覧が設定されているListOfDDCsレジストリキーを更新します (このキーはActive Directoryサイト組織単位に相当します)。スペースで区切って複数の値を入力できます。 Controllerグループは角かっこで囲みます。

    HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent\ListOfDDCs (REG_SZ)

    HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgentにListOfDDCsとFarmGUIDキーの両方がある場合は、ListOfDDCsがControllerの検出に使用されます。FarmGUIDは、VDAのインストール時にサイト組織単位を指定した場合に作成されます。

  2. 必要に応じて、ListOfSIDsレジストリキーを更新します。

    HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent\ListOfSIDs (REG_SZ)

Controllerの追加、削除、または移動

Controllerを追加、削除、または移動するには、「データベース」の記事に記載されているサーバーおよびデータベースの役割権限が必要です。

注:SQLクラスター化またはSQLミラー化インストールのおけるノード上へのControllerのインストールはサポートされていません。

展開環境でデータベースのミラーリングを使用している場合は、以下の点について注意してください。

  • Controllerを追加、削除、または移動する前に、プライマリデータベースとミラーデータベースの両方が実行中であることを確認してください。 また、SQL Server Management Studioでスクリプトを使用している場合は、SQLCMDモードを有効にしてください。
  • Controllerの追加、削除、または移動後にミラーリングを確認するには、get-configdbconnection PowerShellコマンドレットを実行しミラーに対する接続文字列でフェールオーバーパートナーが設定されているか確認します。

Controllerの追加、削除、または移動後の作業

  • 自動更新が有効な場合は、VDAは90分以内に最新のController一覧を受信します。
  • 自動更新が無効な場合は、すべてのVDAについてControllerポリシー設定またはListOfDDCsレジストリキーが更新されていることを確認してください。 Controllerをほかのサイトに移動した後は、両方のサイト上でポリシー設定またはレジストリキーを更新する必要があります。

Controllerの追加

Controllerは、サイトの作成時、または後日、追加できます。 以前のバージョンがインストールされたControllerをこのバージョンのサイトに追加することはできません。

  1. サポートされているオペレーティングシステムが稼動しているサーバーでインストーラーを実行します。 Delivery Controllerコンポーネントと、必要なコアコンポーネントをすべてインストールします。 インストールウィザードを完了します。
  2. サイトをまだ作成していない場合は、Studioを起動します。サイトの作成を促すメッセージが表示されます。  サイトの作成ウィザードの[データベース]ページで[選択]ボタンをクリックし、追加するControllerがインストールされているサーバーのアドレスを追加します。 重要:データベースの初期化スクリプトを生成する計画がある場合は、スクリプトを生成する前に、Controllerを追加してください。
  3. サイトの作成がすでに済んでいる場合は、Studioで、追加のControllerをインストールしたサーバーを指定します。 [展開の変更]をクリックし、サイトアドレスを入力します。

Controllerの削除

Controllerを削除すると、Citrixソフトウェアやそのほかのコンポーネントはアンインストールされませんが、データベースからそのControllerが削除されます。このため、このControllerでは接続の仲介やそのほかのタスクを実行できなくなります。 削除したControllerを、後で元のサイトや別のサイトに追加することができます。 サイトには最低1つのControllerが必要なため、Studioの一覧に表示される最後のControllerを削除することはできません。

サイトからController削除しても、データベースサーバーへのControllerログオンは削除されません。 これは、同じマシン上のほかの製品のサービスで使用されるログオンが削除されるのを防ぐためです。 ログオンが必要ない場合には、手動で削除する必要があります。ログオンの削除には、securityadminサーバーロール権限が必要です。

重要:サイトからControllerを削除するまでは、Active DirectoryでそのControllerを削除しないでください。

  1. Controllerが動作しており、1時間以内にそのControllerがStudioにロードされることを確認してください。 削除するControllerがStudioにロードされたら、メッセージに従ってControllerをシャットダウンしてください。
  2. Studioのナビゲーションペインで、[構成]>[Controller]の順に選択し、削除するControllerを選択します。
  3. [操作]ペインの[Controllerの削除]を選択します。 適切なデータベースロールや権限がない場合は、Controllerを削除するためのスクリプトを生成できます。そのスクリプトの実行をデータベース管理者に依頼してください。
  4. データベースサーバーからControllerのマシンアカウントを削除しなければならない場合があります。 これを行う前に、ほかのサービスがそのアカウントを使用していないことを確認してください。

Studioを使ってControllerを削除した後、実行中のタスクを適切に完了させるためにそのControllerへのトラフィックがしばらく残ることがあります。 Controllerを即座に削除するには、Controllerがインストールされているサーバーをシャットダウンするか、Active Directoryからそのサーバーを削除することをお勧めします。 その後で、サイト内のほかのControllerを再起動します。これにより、削除されたControllerとの通信が行われなくなります。

Controllerの別のゾーンへの移動

サイトに複数のゾーンが含まれている場合、Controllerを別のゾーンに移動できます。 これがVDAの登録などの操作にどのような影響を与えるかについて、詳しくは「ゾーン」の記事を参照してください。

  1. Studioのナビゲーションペインで、[構成]>[Controller]の順に選択し、移動するControllerを選択します。
  2. [操作]ペインの[移動]を選択します。
  3. Controllerの移動先ゾーンを指定します。

Controllerの別のサイトへの移動

このソフトウェアの以前のバージョンで作成されたサイトには、Controllerを移動できません。

  1. StudioのナビゲーションペインでControllerの移動元サイトを開き、[構成]>[Controller]の順に選択し、移動するControllerを選択します。
  2. [操作]ペインの[Controllerの削除]を選択します。 データベースに対する適切な役割や権限がない場合は、Controllerを削除するためのスクリプトを生成できます。そのスクリプトの実行をデータベース管理者など該当する権限を持つユーザーに依頼してください。 サイトには最低1つのControllerが必要なため、Studioの一覧に表示される最後のControllerを削除することはできません。
  3. 移動するControllerでStudioを開き、確認メッセージに応じてサービスをリセットします。さらに、[既存のサイトへ参加]を選択して、移動先サイトのアドレスを入力します。

VDAから別のサイトへの移動

VDAがProvisioning Servicesを使ってプロビジョニングされた場合、または既存のイメージの場合、アップグレード時、またはテストサイトで作成されたVDAイメージを実務環境サイトに移動させる場合に、VDAをほかのサイトに移動(サイト1からサイト2へ)できます。 MCSはListOfDDCsの変更をサポートせずVDAはControllerへの登録をチェックするため、 Machine Creation Services(MCS)を使ってプロビジョニングされたVDAをあるサイトから別のサイトには移動できません。MCSを使ってプロビジョニングされるVDAは、作成されたサイトに割り当てられたListOfDDCsをチェックします。

VDAをほかのサイトに移動するにはインストーラーを使用するか、Citrixポリシーを使用します。

インストーラー:インストーラーを実行して、サイト2のControllerのFQDN(DNSエントリ)を指定してこのControllerを追加します。 重要:Controllerのポリシー設定を使用しない場合にのみ、インストーラーでControllerを指定します。

グループポリシーエディター:次の例では、複数のVDAをほかのサイトに移動します。

  1. サイト1でポリシーを作成して以下のように設定し、そのポリシーをVDA移行を行うデリバリーグループに割り当てます。
    Controller — サイト2の1つまたは複数のControllerのFQDN(DNSエントリ)を指定します。
    Controllerの自動更新を有効にする — 無効に設定します。
  2. デリバリーグループの各VDAは、新しいポリシーの適用後90分以内にアラートを受信します。 VDAは、受信したControllerの一覧を無視して(自動更新が無効なため)、ポリシーで指定されているサイト2のいずれかのControllerを選択します。
  3. VDAがサイト2のControllerへの登録に成功すると、サイト2のListOfDDCsおよびポリシー情報を受け取って、これにより自動更新が有効になります。 サイト1での登録先のControllerがサイト2のControllerによって送信された一覧にはないため、サイト2の一覧のControllerのいずれかにVDAが再登録されます。 これにより、VDAはサイト2からの情報に基づいて自動的に更新されます。

Active Directory OUベースのController検出

このDelivery Controller検出方法は主に後方互換性のためにサポートされており、VDA for Windows Desktop OSでのみ有効です(VDA for Windows Server OSでは使用できません)。 この検出方法では、サイト内のすべてのコンピューターが同じActive Directoryドメインに属しており、Controllerとデスクトップで使用されるドメイン間に相互信頼関係が設定されている必要があります。 この検出方法を使用する場合、各デスクトップのレジストリで組織単位(OU)のGUIDを構成する必要があります。

OUベースのController検出を実行するには、Controller上でPowerShellスクリプトのSet-ADControllerDiscovery.ps1を実行します(このスクリプトは各Controllerの$Env:ProgramFiles\Citrix\Broker\Service\Setup Scriptsフォルダーにあります)。 スクリプトを実行するには、すべての管理タスクを実行できる権限に加えて、親OUでのCreateChild権限が必要です。

Active Directoryを使用してControllerが検出されるように構成する場合は、サイトを作成するときに、対応する組織単位(OU)をActive Directory内に作成する必要があります。 このOUは、環境内のコンピューターが属しているフォレスト内のどのドメインにも作成できます。 ベストプラクティスとしては、サイト内のControllerもこのOUに含まれている方が望ましいですが、これは必須ではありません。 適切な権限を持つドメイン管理者はOUを空のコンテナーとして作成して、そのOUの管理権限をほかのCitrix管理者に委任できます。

スクリプトを実行すると、以下の重要なオブジェクトが作成されます。 これらのオブジェクトは、標準的なActive Directoryオブジェクトです。 スキーマを拡張する必要はありません。

  • Controllerのセキュリティグループ。 サイト内のすべてのControllerのコンピューターアカウントは、このセキュリティグループに属している必要があります。 サイト内のデスクトップは、このセキュリティグループに属しているControllerからのみデータを受け入れます。

    すべてのControllerで、VDAを実行するすべての仮想デスクトップに対する「ネットワーク経由でコンピューターへアクセス」権限が必要です。 このため、Controllerのセキュリティグループにこの権限を追加します。 Controllerにこの権限がない場合、VDAは登録されません。

  • サイトの名前など、サイトに関する情報を含むサービス接続ポイント(SCP)オブジェクト。 [Active Directoryユーザーとコンピューター]管理ツールでサイトOUを確認する場合、SCPオブジェクトを表示するには[表示]メニューの[拡張機能]を有効にする必要があります。
  • サイトのOU内に作成されるRegistrationServicesという名前のコンテナー。 このコンテナーには、サイトの各Controllerについて1つのSCPオブジェクトが含まれます。 Controllerが起動すると、そのSCPの内容が検証され、必要な場合は更新されます。

初回インストール後に複数の管理者でControllerを追加したり削除したりする必要がある場合は、RegistrationServicesコンテナーで子オブジェクトを作成および削除する権限とControllerセキュリティグループでプロパティを書き込む権限が必要です(これらの権限は、Set-ADControllerDiscovery.ps1スクリプトを実行する管理者に自動的に付与されます。)。 これらの権限はドメイン管理者または初回インストール時の管理者が付与できます。また、これを行うためのセキュリティグループを設定することをお勧めします。

サイトOUを使用する場合、以下の項目が適用されます。

  • Active Directoryに情報が書き込まれるのは、この製品をインストールまたはアンインストールするときや、起動したControllerのSCPの情報を更新するとき(Controllerの名前や通信ポートを変更した後など)のみです。 デフォルトでは、Set-ADControllerDiscovery.ps1スクリプトによってサイトOU内のオブジェクトに関する権限が適切にセットアップされ、各ControllerにSCPへの書き込み権限が付与されます。 サイトOU内のオブジェクトの内容は、デスクトップとControllerの間の信頼を確立するために使用されます。 以下の点を確認してください。
    • 許可された管理者のみが、セキュリティグループのアクセス制御リスト(ACL)を使用してControllerのセキュリティグループにコンピューターを追加したり削除したりできること。
    • 許可された管理者と各Controllerのみが、ControllerのSCP内の情報を変更できること。
  • 展開で複製機能を使用する場合、潜在的な遅延による影響について考慮してください。詳しくは、Microsoftのドキュメントを参照してください。 複数のActive Directoryサイトにドメインコントローラーがあるドメイン内でサイトOUを作成する場合は、特に重要になります。 デスクトップやController、ドメインコントローラーの場所によっては、サイトOUを最初に作成したり、Controllerをインストールまたはアンインストールしたり、Controller名や通信ポートを変更したりしたときのActive Directoryの変更内容が、適切なドメインコントローラーに複製されるまでデスクトップ側に反映されない場合があります。 このような遅延が発生するときは、デスクトップがControllerとの接続を確立できないためにユーザーが仮想デスクトップに接続できないなどの問題が発生します。
  • この製品では、Active Directoryの標準のコンピューターオブジェクトの属性を複数使用して、デスクトップを管理します。 環境によっては、デスクトップのActive Directoryレコードに格納されるコンピューターオブジェクトの完全修飾ドメイン名(FQDN)が、接続を行うユーザーに返される接続設定の一部として含まれている場合があります。 この情報がDNS環境の情報と一致していることを確認してください。

OUベースのController検出を使用してControllerをほかのサイトに移動するには、前述のControllerの移動に関する指示に従って操作します。 古いサイトからControllerを削除した後(手順2)、PowerShellスクリプトSet-ADControllerDiscover –syncを実行します。 このスクリプトにより、OUが現在のControllerの一覧と同期されます。 移動先のサイトに参加した後(手順3.)、そのサイトの任意のController上で同じスクリプトを実行します。