Conception

La conception d’une solution de virtualisation de bureaux consiste simplement à suivre un processus éprouvé et à aligner les décisions techniques sur les exigences de l’organisation et des utilisateurs. Sans le processus standardisé et éprouvé, les architectes ont tendance à passer aléatoirement d’un sujet à l’autre, ce qui entraîne confusion et erreurs. L’approche recommandée se concentre sur cinq niveaux distincts :

Image de modèle à cinq couches

Identifiées au cours de la section Segmentation utilisateur de la phase d’évaluation, les trois couches supérieures sont conçues pour chaque groupe d’utilisateurs indépendamment. Ces couches définissent les ressources des utilisateurs et la manière dont les utilisateurs accèdent à leurs ressources. Une fois ces trois couches élaborées, les couches de base (contrôle et matériel) sont créées pour l’ensemble de la solution.

Ce processus oriente la réflexion conceptuelle : les décisions prises en amont ont un impact sur les décisions de conception de niveau inférieur.

Couche 0 – Architecture conceptuelle

L’architecture conceptuelle permet de définir les stratégies globales de l’ensemble de la solution en fonction des objectifs métier et de la structure organisationnelle.

Bien que l’architecture conceptuelle d’une organisation va changer au cours des prochaines années, il convient de commencer la phase de conception en définissant les objectifs à long terme dans le cadre des modèles de mise à disposition et de la répartition physique et géographique de la solution.

Décision – Modèle de mise à disposition

Une solution XenDesktop et XenApp peut se présenter sous de nombreuses formes de mise à disposition. Les objectifs métier de l’organisation permettent de choisir la bonne approche. Même si l’infrastructure reste la même pour tous les modèles de mise à disposition, l’étendue de la gestion de l’équipe informatique locale change.

  • Modèle local : tous les composants hébergés à partir du centre de données local de l’organisation. Le modèle local exige que l’équipe informatique locale gère tous les aspects de la solution.

Image de l'architecture locale

  • Cloud public : tous les composants hébergés à partir d’une infrastructure de cloud public utilisant l’infrastructure en tant que service (IaaS). Le modèle de cloud public élimine la gestion du matériel de l’étendue de gestion de l’équipe informatique locale.

Image de l'architecture de cloud public

  • Cloud hybride : une mise en œuvre unique s’exécute à partir d’un centre de données local ainsi que du cloud public. Même si les composants de la solution utilisent différents fournisseurs d’hébergement, la solution entière est une solution unique utilisant le même code et gérée comme une seule entité. L’équipe informatique locale continue de gérer tous les aspects de la solution, à l’exception du matériel associé aux ressources hébergées dans le cloud.

Image de l'architecture de cloud hybride

  • Citrix Cloud : l’offre XenApp and XenDesktop Service de Citrix Cloud divise un déploiement typique en plusieurs domaines de gestion. Les composants de la couche d’accès et de contrôle sont hébergés et gérés dans Citrix Cloud par Citrix, tandis que les composants de la couche de ressources continuent d’être gérés par l’équipe informatique locale, sous la forme d’un modèle de cloud local, public ou hybride. Citrix gère le matériel, le dimensionnement et les mises à jour des composants d’accès et de contrôle, tandis que l’équipe informatique locale gère les ressources. En outre, si le cloud public héberge les ressources, l’équipe informatique locale n’a pas à gérer le matériel des ressources. Citrix Cloud continue d’augmenter le nombre d’offres pour aider à résoudre des cas d’utilisateur spécifiques. Pour plus d’informations sur la gamme complète des offres, consultez les services d’espace de travail dans Citrix Cloud.

Image de l'architecture de Citrix Cloud

Décision – Topologie du site

Un site XenApp et XenDesktop regroupe les bureaux et les applications pour former une entité architecturale et de gestion unique. Toutes les données persistantes et dynamiques du site, y compris la configuration du site, les attributions de bureaux et l’état des sessions, sont stockées dans la base de données d’un site.

Un site peut se trouver sur un seul emplacement, s’étendre sur plusieurs emplacements ou être un emplacement partiel. Grâce à des tests rigoureux, un site XenApp/XenDesktop unique peut prendre en charge 40 000 sessions simultanées ou plus.

Image du site de mise à disposition 1

Image du site de mise à disposition 2

Image du site de mise à disposition 3

Des sites uniques sont subdivisés en zones qui sont souvent associées à des emplacements géographiques. Plusieurs facteurs doivent être pris en compte lors de la détermination de la topologie globale de la solution XenApp et XenDesktop :

  • Tolérance au risque : créez plusieurs sites XenDesktop pour minimiser l’impact d’une panne à l’échelle du site. Par exemple, la corruption de la base de données du site XenDesktop peut affecter la disponibilité à l’échelle du site. Pour de nombreuses organisations, la diminution du risque lié à la mise en œuvre de plusieurs sites l’emporte sur les frais généraux supplémentaires de gestion et l’infrastructure de support nécessaires.

Expérience sur le terrain

Finance : une grande institution financière héberge 10 000 bureaux à partir d’un centre de données unique. Afin de réduire les risques, il a été décidé qu’aucun site ne devrait dépasser 5 000 bureaux. Par conséquent, bien que les bureaux soient connectés par un réseau rapide et redondant, deux sites ont été créés.

  • Sécurité : bien que l’administration déléguée soit disponible, les organisations à haute sécurité peuvent exiger une séparation complète entre les environnements afin de démontrer leur conformité à des accords de niveau de service spécifiques.

Expérience sur le terrain

Vente au détail : une entreprise de vente au détail exige une séparation complète des employés responsables de la gestion des données financières. Pour répondre à cette exigence, deux sites distincts ont été créés au sein du même centre de données : un pour les employés responsables des données financières et un autre pour tous les autres employés.

  • Limites administratives : en raison des exigences de facturation, de remboursement ou de la structure du département informatique, plusieurs sites peuvent être tenus de séparer les limites administratives.

  • Connectivité géographique : bien que la mise en place de zones permet à un seul site de couvrir des emplacements géographiques, une bande passante suffisante doit exister entre la zone satellite et la zone principale pour que la base de données du site puisse capturer les informations relatives à la session. Une latence plus élevée ou des zones plus vastes ont un impact sur les temps de réponse pour l’utilisateur.

Variable XenApp et XenDesktop 7.13 XenApp et XenDesktop 7.11
Latence (ms) 90 250
Demandes simultanées 48 48
Temps de réponse moyen 3.7 7.6
Demandes auprès du broker par seconde 12.6 6.3
Délai requis pour le lancement de 10 000 utilisateurs 13 minutes 26 minutes
Nombre de sessions Nombre maximal de sessions simultanées lancées Bande passante minimale de site à site Latence maximale des boucles de site à site
Moins de 50 20 1 Mbits/s 250 ms
entre 50 et 500 25 1,5 Mbits/s 100 ms
entre 500 et 1 000 30 2 Mbits/s 50 ms
entre 1 000 et 3 000 60 8 Mbits/s 10 ms
Plus de 3 000 60 8 Mbits/s 5 ms

En général, les administrateurs doivent minimiser le nombre de sites et de zones XenDesktop afin de réduire la complexité architecturale et les efforts administratifs.

Décision – Stratégie de gestion des images

Une solution XenApp et XenDesktop nécessite la création et la gestion d’images principales. Les organisations doivent décider rapidement de la stratégie à adopter pour la gestion des images.

Images installées

Une image installée nécessite que l’administrateur installe le système d’exploitation et les applications pour chaque image. Cette approche est simple mais crée une duplication des efforts puisque l’administrateur installe le même système d’exploitation et les mêmes applications de base sur plusieurs images principales.

La maintenance des images principales inclut également la duplication des efforts, car la même version du système d’exploitation et les mêmes applications de base font partie de plusieurs images, chacune nécessitant le même processus de mise à jour.

Images à base de script

Les administrateurs peuvent automatiser de nombreuses tâches associées aux images installées à l’aide d’outils de script ou d’automatisation. De nombreuses installations de systèmes d’exploitation et d’applications prennent en charge la création de scripts automatisés, ce qui réduit l’impact de la duplication des efforts pour l’administrateur dans le cadre des images installées.

Toutefois, l’apprentissage, la création et la maintenance d’une infrastructure de script pour l’ensemble de l’image sont des processus difficiles et fastidieux. L’écriture de scripts sur une compilation entière prend du temps et entraîne souvent des échecs inattendus si les structures de répertoires changent, si les processus prennent trop de temps ou si un nom de fichier est modifié.

Images en couche

Chaque système d’exploitation unique (Windows 10, Windows 2012 R2 et Windows 2016), plate-forme (XenApp/XenDesktop 7.13 VDA, XenApp/XenDesktop 7.14 VDA et XenApp/XenDesktop 7.15 VDA) et application (Microsoft Office, Adobe Acrobat, Google Chrome et Mozilla Firefox) représente une couche. Une image principale correspond à la fusion d’une couche de système d’exploitation, d’une plate-forme et de nombreuses applications.

Une approche d’image en couche élimine la duplication des efforts dans le cadre des images installées et des images à base de script. Chaque couche unique est disponible pour n’importe quelle image principale. Lorsqu’une application nécessite une mise à jour, cette couche reçoit les mises à jour et toutes les images principales utilisant la couche reçoivent la mise à jour. Si une organisation nécessite dix images Windows 10 uniques, chacune des dix images partage la même couche Windows 10. Lorsque l’administrateur doit effectuer une mise à niveau du VDA de la version 7.14 à 7.15 sur dix images, l’administrateur ne met à jour qu’une seule couche de plate-forme.

Initialement, l’approche d’image en couche nécessite plus de temps pour le déploiement, car l’administrateur doit créer la bibliothèque de couches de l’organisation. Cependant, une fois les couches disponibles, le temps de maintenance des images est considérablement réduit.