Product Documentation

Environnement Delivery Controller

Oct 21, 2016

Dans un déploiement, le Delivery Controller est le composant côté serveur qui est responsable de la gestion de l'accès utilisateur, ainsi que de la négociation et de l'optimisation des connexions. Les contrôleurs fournissent également les services Machine Creation qui créent des images de bureau et de serveur.

Un site doit avoir au moins un Delivery Controller. Après avoir installé le Controller initial et créé un site, vous pouvez ajouter des Controller supplémentaires. Avoir plus d'un Controller dans un site présente deux avantages.
  • Redondance : Il est recommandé qu'un site de production doive toujours disposer d'au moins deux contrôleurs sur des serveurs physiques différents. Si un Controller échoue, les autres peuvent gérer les connexions et administrer le site.
  • Évolutivité : au fur et à mesure que l'activité du site augmente, il en va de même pour l'utilisation de l'UC sur le contrôleur et l'activité de la base de données SQL Server. Les Controller supplémentaires permettent de gérer plus d'utilisateurs et plus de demandes d'applications et de bureaux, et peuvent améliorer la réactivité générale.

Comment les VDA découvrent-ils les Controller

Avant qu'un VDA puisse être utilisé, il doit s'enregistrer (établir la communication) auprès d'un Controller sur le site. Le VDA trouve un Controller en vérifiant une liste de Controller appelée ListofDDCs. La liste ListOfDDCs se compose d'une ou plusieurs entrées DNS ou adresses IP qui pointent le VDA vers des Controller sur le site. Pour assurer l'équilibrage de charge, le VDA répartit automatiquement les connexions de manière équitable entre les Controller dans la liste.

En plus de la liste ListOfDDCs, ListOfSIDs indique les ID de sécurité (SID) de machine qui sont autorisés à contacter le VDA en tant que Controller. La liste ListOfSIDs peut être utilisée pour réduire la charge sur Active Directory ou pour éviter des menaces de sécurité provenant d’un serveur DNS non fiable.

Il est important de s'assurer que les listes ListOfSIDs et ListOfDDCs sur tous les VDA contiennent des informations à jour à mesure que des Controller sont ajoutés et supprimés dans le site. Si les listes ne sont pas mises à jour, un VDA risque de rejeter les sessions qui ont été négociées par un Controller non répertorié. La présence d'entrées non valides peut retarder le démarrage du logiciel système du bureau virtuel. Pour conserver les listes à jour, vous pouvez :
  • Utiliser la fonctionnalité de mise à jour automatique, qui met automatiquement à jour les listes ListOfDDCs et ListOfSIDs à mesure que des Controller sont ajoutés ou supprimés. Par défaut, la mise à jour automatique est activée.
  • auto-gérer : c'est-à-dire mettre à jour manuellement les paramètres de stratégie ou de registre qui identifient les Controller.
Les informations contenues dans les listes ListOfDDCs et ListOfSIDs peuvent provenir de plusieurs endroits dans un déploiement. Le VDA vérifie les emplacements suivants, dans l'ordre, et stoppe au premier dans lequel il trouve les listes :
  1. Un emplacement de stockage persistant dont la maintenance est assurée pour la fonctionnalité de mise à jour automatique. Cet emplacement contient des informations sur le Controller lorsque la fonctionnalité de mise à jour automatique est activée et après que le VDA s'enregistre avec succès pour la première fois après l'installation. (Ce stockage contient également des informations sur la stratégie de la machine, ce qui garantit que les paramètres de stratégie sont conservés après les redémarrages.)

    Pour son enregistrement initial après l'installation, ou lorsque la mise à jour automatique est désactivée, le VDA vérifie les emplacements suivants.

  2. Les paramètres de stratégie (Controller, SID de Controller).
  3. Les informations sur le Controller sous la clé Virtual Desktop Agent dans le Registre. Le programme d'installation de VDA renseigne initialement ces valeurs, en fonction des informations sur le Controller que vous spécifiez lors de l'installation du VDA.
  4. Découverte de Controller basée sur l'unité d'organisation. Ceci est une méthode héritée conservée pour des raisons de rétrocompatibilité.
  5. Le fichier Personality.ini créé par Machine Creation Services.

Si une liste ListOfDDCs spécifie plusieurs Controller, le VDA tente de s'y connecter aléatoirement. La liste ListOfDDCs peut également contenir des groupes de Controller, qui sont désignés par des crochets entourant deux ou plusieurs entrées de Controller. Le VDA tente de se connecter à chaque Controller dans un groupe avant de passer à d'autres entrées dans la liste ListOfDDCs.

La fonctionnalité de mise à jour automatique remplace la fonction CNAME des versions XenDesktop antérieures. Vous pouvez réactiver manuellement la fonction CNAME, si désiré ; cependant, pour que l'alias DNS fonctionne de manière cohérente, vous ne pouvez pas utiliser la fonctionnalité de mise à jour automatique et la fonction CNAME en même temps. Consultez l'article CTX137960 pour plus d'informations sur la réactivation de la fonctionnalité CNAME.

Considérations à prendre en compte lors du choix de la mise à jour automatique ou de l'auto-gestion

Le paramètre de stratégie qui active/désactive la mise à jour automatique est activé par défaut.

Les types de déploiements suivants ne peuvent pas utiliser la mise à jour automatique et doivent être gérés de façon autonome.
  • Déploiements qui utilisent des groupes de Controller.
  • Déploiements qui utilisent des listes ListOfSIDs pour des raisons de sécurité. (Les déploiements qui utilisent ListOfSIDs pour réduire la charge Active Directory peuvent utiliser la mise à jour automatique).
  • Déploiements qui utilisent Provisioning Services sans disque d'écriture conditionnelle.
  • Déploiements qui utilisent le paramètre de stratégie des Controller ou SID de Controller.