XenApp et XenDesktop 7.7 : Zones Deep Dive
Cet article va un peu plus loin sur le fonctionnement de la fonctionnalité zones dans XenApp et XenDesktop 7.7, ainsi que sur les implications de la mise en place d’éléments tels que Delivery Controller, connexions hyperviseurs et catalogues de machines dans différentes zones. Il peut être utile de lire d’abord les zones dans la documentation du produit Citrix :https://docs.citrix.com/fr-fr/legacy-archive/xenapp-and-xendesktop.html.
Zones primaires et satellites
Chaque site XenApp et XenDesktop 7.7 possède une zone principale, qui doit inclure la base de données centrale du site et au moins deux Delivery Controller.
Les zones secondaires ou satellites doivent inclure un ou plusieurs VDA, Controller, serveurs StoreFront et serveurs NetScaler Gateway. En fonctionnement normal, les Controller d’une zone satellite communiquent directement avec la base de données centrale du site dans la zone principale.
Les Controller de la zone principale sont supposés avoir une bonne connectivité à la base de données du site et avoir une certaine connectivité à toutes les zones satellites. Mais les éléments de chaque zone satellite ne sont pas supposés avoir une connectivité avec des éléments situés dans d’autres zones satellites.
Éléments pouvant être associés à des zones
Un certain nombre d’éléments différents d’un déploiement XenApp ou XenDesktop peuvent être associés à une zone satellite, ce qui affecte ensuite la façon dont le Site interagit avec ces objets et d’autres objets qui leur sont associés. Les éléments qui peuvent être placés dans des zones satellites sont :
- Machines Controller
- Connexions hyperviseur
- Catalogues de machines
- Passerelles NetScaler
Lorsque les machines Controller sont placées dans une zone satellite, il est alors supposé que ces machines ont une bonne connectivité (locale) aux hyperviseurs et aux machines VDA dans la même zone satellite, et donc le système organise les choses pour préférer utiliser ces Controller pour gérer ces hyperviseurs et ces machines VDA.
La connexion hyperviseur placée dans une zone satellite implique que tous les hyperviseurs gérés via cette connexion hyperviseur sont également supposés résider dans cette zone satellite, et que les Controller de cette zone sont préférés pour être utilisés lors de la communication avec cette connexion hyperviseur.
Un catalogue de machines placé dans une zone satellite implique également que toutes les machines VDA de ce catalogue sont dans la zone satellite, et cela contrôlera également quels Controller sont préférés lors de la tentative d’inscription sur le Site après l’activation du mécanisme de mise à jour automatique de la liste des Controller après la première inscription de chaque VDA.
Les VDA préféreront s’inscrire auprès des Controller dans la même zone locale qu’eux-mêmes, mais ne pourront pas s’enregistrer auprès des Controller dans la zone principale. Les VDA ne s’enregistreront pas auprès des Controller dans d’autres zones satellitaires.
Les instances de NetScaler Gateway peuvent également être associées à des zones, mais cela est fait dans le cadre de la configuration de routage HDX Optimal de StoreFront plutôt que, comme pour les autres éléments décrits ici, dans le cadre de la configuration du site XenApp ou XenDesktop. Lorsqu’une passerelle NetScaler Gateway est associée à une zone, elle est utilisée de préférence lorsque des connexions HDX à des machines VDA dans cette zone sont utilisées.
Limites de qualité de connexion
Les Controller de la zone satellite effectuent les interactions SQL directement avec la base de données du site. Bien que certaines modifications aient été apportées pour minimiser cette interaction SQL, cela impose certaines limites à la qualité de la liaison entre la zone satellite et la zone primaire contenant la base de données. Les limites spécifiques sont de nouveau relatives au nombre de VDA et de sessions utilisateur sur les VDA qui sont déployés dans la zone satellite. Ainsi, les zones satellites avec seulement un petit nombre de VDA et de sessions peuvent fonctionner avec une connexion de mauvaise qualité à la base de données que les zones satellites avec un grand nombre de VDA et de sessions. Voici quelques lignes directrices :
| Nombre de sessions à prendre en charge | Nombre maximal de lancements de session utilisateur final simultané supposé | Bande passante minimale acceptable | Latence maximale acceptable aller-retour |
|---|---|---|---|
| Moins de 50 | 20 | 1 Mbit/s | 250 ms |
| 50 à 500 | 25 | 1,5 Mbit/s | 100 ms |
| 500 à 1 000 | 30 | 2 Mbit/s | 50 ms |
| 1 000 à 3 000 | 60 | 8 Mbit/s | 10 ms |
| Plus de 3 000 | 60 | 8 Mbit/s | 5 ms |
Haute disponibilité avec location de connexion
Dans XenApp et XenDesktop 7.7, la fonctionnalité de location de connexion peut aider à maintenir une haute disponibilité du courtage de nouvelles connexions aux utilisateurs finaux en cas de panne du système. Si vous utilisez des zones, la panne peut être causée par une perte de communication entre une zone satellite et la zone principale (en particulier lorsque la base de données réside dans la zone principale). Dans ce cas, les Controller de la zone satellite basculent en mode location et permettent tout de même aux utilisateurs finaux d’échanger de nouvelles connexions vers les applications et les postes de travail. Toutefois, les VDA sur lesquels ces sessions s’exécutent doivent être accessibles depuis les Controller de la zone satellite. Pour limiter la charge du système de fichiers pour les machines Controller dans les zones satellites, seules les données de location de connexion pour les machines VDA dans cette même zone.
Déploiement de StoreFront
Si vous souhaitez tirer parti de la haute disponibilité du courtage à l’aide de la location de connexion, lorsqu’une zone satellite est isolée de la zone principale, il est nécessaire de déployer une instance StoreFront dans chaque zone satellite. En effet, une instance StoreFront déployée de manière centralisée dans la zone principale ne serait pas nécessairement en mesure de contacter les Controller dans les zones satellites si la connectivité entre les zones principale et satellite est interrompue lors d’une panne.
Nombre de zones
Le nombre de Controller configurés dans le site peut affecter les performances de certaines opérations, telles que l’ajout de nouveaux Controller au site lui-même. Pour éviter cela, il est recommandé de limiter le nombre de zones dans votre site XenApp ou XenDesktop 7.7 à un maximum de 10. Dans XenApp ou XenDesktop 7.11 et versions ultérieures, la limite est de 50.
Paramètres de configuration de bas niveau et réglages
Certains nouveaux éléments de configuration ont été ajoutés aux zones de prise en charge, y compris l’ajout de la définition de zones au niveau du SDK PowerShell, qui fait partie du SDK du service de configuration plutôt que, par exemple, faire partie du SDK du service de courtier. D’autres parties de la configuration de zone peuvent être effectuées dans d’autres kits SDK PowerShell de service FMA, en particulier lorsque des éléments sont associés à des zones, ce qui est fait par le service qui a le plus de propriété de ces objets. Par conséquent, l’appartenance à la zone des catalogues de machines est définie à l’aide du SDK du service de courtier, et l’appartenance à la zone des connexions hyperviseurs est configurée à l’aide du SDK du service hôte.
En outre, un nouveau paramètre de Registre a été ajouté pour permettre le contrôle d’une limitation des lancements simultanés d’utilisateurs finaux ; la partie principale de ceci est à HKLM\Software\Citrix\DesktopServer\ThrottledRequestAddressMaxConcurrentTransactions. Dans certaines situations de test, nous avons constaté que des latences élevées entre les zones satellites et la base de données dans la zone principale, associées à un taux relativement élevé de lancements de connexions d’applications et de postes de travail par les utilisateurs finaux utilisant un Controller dans la zone satellite, pourraient entraîner des retards de lancement en raison d’un retard de lancements antérieurs.
Autres conseils
Certains rapports indiquent que le nœud de zones dans Studio a disparu après la mise à niveau d’un site. Cela peut être dû au fait que le fichier « configuration du rôle » n’a pas pu être importé pendant la mise à niveau. Vous pouvez résoudre ce problème manuellement en important le fichier via le SDK PowerShell :
cd 'C:\Program Files\Citrix\XenDesktopPoshSdk\Module\Citrix.XenDesktop.Admin.V1\Citrix.XenDesktop.Admin\StudioRoleConfig'
Import-AdminRoleConfiguration –Path .\RoleConfigSigned.xml
Cet article a été modifié à partir d’un billet de blog écrit par William Charnell. Pour lire le blog original et voir les commentaires, allez sur https://www.citrix.com/blogs/2016/01/12/deep-dive-xenapp-and-xendesktop-7-7-zones/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+CitrixBlogs+%28Citrix+Blogs%29.