Couche de contrôle de la méthodologie de conception

Note : Ce article a été traduit automatiquement. Clause de non responsabilité

Lire en anglais

La couche de contrôle est la quatrième couche de la méthodologie de conception.

Active Directory

Décision : Conception forestière

Par défaut, les déploiements multi-forêts n’ont pas de relations d’approbation inter-domaines entre les forêts. Un administrateur AD peut établir des relations d’approbation entre les forêts multiples, permettant aux utilisateurs et aux ordinateurs d’une forêt d’authentifier et d’accéder aux ressources d’une autre forêt.

Pour les forêts qui ont des approbations inter-domaines, il est recommandé de configurer les paramètres appropriés pour permettre aux Delivery Controller de communiquer avec les deux domaines. Lorsque les approbations appropriées ne sont pas configurées, plusieurs sites XenDesktop pour chaque forêt doivent être configurés. Cette section décrit les exigences en matière de stockage par produit et fournit des calculs de dimensionnement. Pour plus d’informations, reportez-vous à l’article Citrix :CTX134971— Déploiement réussi de XenDesktop dans un environnement Active Directory complexe

Décision : Structure de l’unité organisationnelle

Les composants d’infrastructure pour un déploiement XenApp et XenDesktop doivent résider dans leurs propres unités d’organisation dédiées, séparant les travailleurs et les contrôleurs à des fins de gestion. En disposant de leurs propres UO, les objets à l’intérieur disposeront d’une plus grande flexibilité de gestion tout en permettant aux administrateurs Citrix d’obtenir un contrôle délégué.

Un exemple de structure d’unité d’organisation Citrix peut être vu ci-dessous.

Image d'unité d'organisation Citrix

Décision : Groupes d’utilisateurs

Dans la mesure du possible, les autorisations et autorisations doivent être attribuées à des groupes d’utilisateurs plutôt qu’à des utilisateurs individuels, éliminant ainsi la nécessité de modifier un grand nombre d’autorisations de ressources et de droits d’utilisateur lors de la création, de la modification ou de la suppression de comptes d’utilisateurs. Exemple d’application d’autorisation :

  • Une application publiée auprès d’un groupe de 1 000 utilisateurs nécessite la validation d’un seul objet pour l’ensemble des 1 000 utilisateurs.
  • La même application publiée sur 1 000 comptes d’utilisateurs individuels nécessite la validation de tous les 1 000 objets.

Database

La majorité des produits Citrix décrits dans ce document nécessitent une base de données. Le tableau suivant décrit l’utilisation par produit :

Dans ce tableau :

  • Y indique Disponible.
  • O indique Facultatif.
Produit Données de configuration Données d’exécution Audit/Modifier les données du journal Données de surveillance
XenDesktop Y Y Y Y
Provisioning Services Y   O  
Lecteur de bureau Y Y Y Y

Décision : Edition

Il existe plusieurs éditions de Microsoft SQL Server 2012 : Express, Web, Standard, Business Intelligence et Enterprise. En fonction des fonctionnalités des différentes éditions SQL Server disponibles, l’édition Standard est souvent utilisée pour héberger les bases de données XenApp et XenDesktop dans des environnements de production.

L’édition Standard offre une quantité suffisante de fonctionnalités pour répondre aux besoins de la plupart des environnements. Pour plus d’informations sur les bases de données prises en charge par les produits Citrix, reportez-vous à la sectionMatrice de prise en charge de la base de données Citrix. Différentes versions de produits Citrix prennent en charge différentes versions du serveur SQL. Par conséquent, il est important de vérifier la matrice de support pour vous assurer que la version du serveur SQL utilisée est compatible avec le produit Citrix déployé.

Décision : Dimensionnement du serveur de base de données

SQL Server doit être dimensionné correctement pour garantir les performances et la stabilité d’un environnement. Étant donné que chaque produit Citrix utilise SQL Server d’une manière différente, aucune recommandation générique de dimensionnement globale ne peut être fournie. Au lieu de cela, les recommandations de dimensionnement du serveur SQL par produit sont fournies ci-dessous.

XenApp et XenDesktop

Les courtiers XenApp et XenDesktop utilisent la base de données comme bus de messages pour les communications des courtiers, le stockage des données de configuration et le stockage des données du journal de surveillance et de configuration. Les bases de données sont constamment utilisées et l’impact sur les performances du serveur SQL peut être considéré comme élevé.

Sur la base des résultats des tests d’évolutivité interne Citrix, la spécification SQL Server suivante pour un serveur hébergeant toutes les bases de données XenDesktop est recommandée :

  • 2 cœurs / 4 Go de RAM pour les environnements jusqu’à 5 000 utilisateurs
  • 4 cœurs / 8 Go de RAM pour les environnements jusqu’à 15 000 utilisateurs
  • 8 cœurs / 16 Go de RAM pour les environnements avec plus de 15 000 utilisateurs

Les fichiers de base de données et les journaux de transactions doivent être hébergés sur des sous-systèmes de disque dur distincts afin de faire face à un nombre élevé de transactions. Par exemple, l’enregistrement de 20 000 postes de travail virtuels pendant une tempête de démarrage de 15 minutes entraîne ~ 500 transactions / seconde et 20 000 utilisateurs se connectent au cours d’une tempête d’ouverture de session de 30 minutes entraîne ~ 800 transactions / seconde sur la base de données du site XenDesktop.

Provisioning Services

En plus des données de configuration statique, les serveurs de provisionnement stockent les informations d’exécution et d’audit dans la base de données. Selon le modèle de démarrage et de gestion, l’impact sur les performances de la base de données peut être considéré comme faible à moyen.

Sur la base de cette catégorisation, une spécification de serveur SQL de 4 cœurs et de 4 Go de RAM est recommandée comme bon point de départ. Le serveur SQL doit être soigneusement surveillé pendant la phase de test et pilote afin de déterminer la configuration optimale du serveur SQL.

Décision : Dimensionnement des instances

Lors du dimensionnement d’une base de données SQL, deux aspects sont importants :

  • Fichier de base de données : contient les données et les objets tels que les tables, les index, les procédures stockées et les vues stockées dans la base de données.
  • Fichier journal des transactions : contient un enregistrement de toutes les transactions et modifications de base de données effectuées par chaque transaction. Le journal des transactions est un composant critique de la base de données et, en cas de défaillance du système, le journal des transactions peut être nécessaire pour ramener la base de données à un état cohérent. L’utilisation du journal des transactions varie en fonction du modèle de récupération de base de données utilisé :
    • Récupération simple : aucune sauvegarde des journaux n’est requise. L’espace journal est automatiquement récupéré, pour garder les besoins en espace petit, éliminant essentiellement la nécessité de gérer l’espace journal des transactions. Les modifications apportées à la base de données depuis la sauvegarde la plus récente ne sont pas protégées. En cas de catastrophe, ces changements doivent être refaits.
    • Restauration complète — Nécessite des sauvegardes de journaux. Aucun travail n’est perdu en raison d’un fichier de données de base de données perdu ou endommagé. Les données de tout moment arbitraire peuvent être récupérées (par exemple, avant une erreur d’application ou d’utilisateur). Une restauration complète est requise pour la mise en miroir de la base de données.
    • Journalisé en bloc — Nécessite des sauvegardes de journaux. Il s’agit d’un complément au modèle de récupération complète qui permet des opérations de copie en bloc hautes performances. Il n’est généralement pas utilisé pour les bases de données Citrix.

Pour plus d’informations, reportez-vous au Microsoft Developer Network —Modèles de récupération SQL Server.

Afin d’estimer les besoins en stockage, il est important de comprendre la consommation d’espace disque pour les entrées de base de données courantes. Cette section décrit les exigences en matière de stockage par produit et fournit des calculs de dimensionnement. Pour plus d’informations, reportez-vous à l’article Citrix :CTX139508— XenDesktop 7.x Database Sizing.

XenDesktop Général

XenApp 7.x et XenDesktop 7.x utilisent trois bases de données distinctes :

  • Base de données de configuration du site : contient des données de configuration statique et d’exécution dynamique
  • Base de données de surveillance — Contient des données de surveillance accessibles via Director
  • Base de données de journalisation de la configuration : contient un enregistrement pour chaque modification administrative effectuée au sein du site (accessible via Studio)

Base de données du site

Étant donné que la base de données d’un site XenApp ou XenDesktop contient des données de configuration statiques et des données d’exécution dynamiques, la taille du fichier de base de données dépend non seulement de la taille physique de l’environnement, mais aussi des modèles utilisateur. Les facteurs suivants ont tous une incidence sur la taille du fichier de base de données :

  • Nombre de sessions connectées
  • Nombre de VDA configurés et enregistrés
  • Nombre de transactions effectuées pendant l’ouverture de session
  • Transactions de pulsation VDA

La taille de la base de données du site est basée sur le nombre de VDA et de sessions actives. Le tableau suivant présente la taille maximale typique de la base de données Citrix observée lors du test de mise à l’échelle de XenApp et XenDesktop avec un nombre d’utilisateurs, d’applications et de méthodes de mise à disposition de postes de travail.

Utilisateurs Applications Types de bureau Taille maximale prévue (Mo)
1,000 50 Partagé hébergé 30
10,000 100 Partagé hébergé 60
100,000 200 Partagé hébergé 330
1,000 S.O. Pool hébergé 30
10,000 S.O. Pool hébergé 115
40,000 S.O. Pool hébergé 390

Note :

Ces informations de dimensionnement sont à titre indicatif seulement. La taille réelle des bases de données peut varier légèrement selon le déploiement en raison de la façon dont les bases de données sont gérées.

Il est difficile de déterminer la taille du journal des transactions pour la base de données du site en raison de facteurs qui peuvent influencer le journal, notamment :

  • Le modèle de récupération de base de données SQL
  • Taux de lancement aux heures de pointe
  • Nombre de postes de travail livrés

Pendant les tests d’évolutivité XenDesktop, Citrix a observé le taux de croissance du journal des transactions à 3,5 Mo par heure lorsque le système est inactif, et un taux de croissance par utilisateur et par jour de ~ 32 Ko. Dans un environnement de grande taille, l’utilisation du journal des transactions nécessite une gestion attentive et une sauvegarde régulière, afin d’éviter une croissance excessive. Cela peut être réalisé au moyen de travaux planifiés ou de plans d’entretien.

Base de données de surveillance

Parmi les trois bases de données, la base de données de surveillance devrait être la plus importante puisqu’elle contient des informations historiques pour le site. Sa taille dépend de nombreux facteurs, notamment :

  • Nombre d’utilisateurs
  • Nombre de sessions et de connexions
  • Nombre de travailleurs
  • Configuration de la période de conservation : les clients Platinum peuvent conserver leurs données pendant plus d’un an (90 jours par défaut). Les clients non-Platinum peuvent conserver leurs données pendant 7 jours maximum (7 jours par défaut).
  • Nombre de transactions par seconde. Le service de surveillance a tendance à exécuter des mises à jour par lots. Il est rare que le nombre de transactions par seconde dépasse 20.
  • Transaction en arrière-plan causée par des appels de consolidation réguliers du service de surveillance.
  • Traitement du jour au lendemain effectué pour supprimer les données en dehors de la période de rétention configurée.

Le tableau suivant montre la taille estimée de la base de données de surveillance sur une période donnée dans différents scénarios. Ces données sont une estimation basée sur les données vues dans les tests d’échelle XenApp et XenDesktop (en supposant une semaine de travail de 5 jours).

Utilisateurs Tapez 1 semaine (Mo) 1 mois (Mo) 3 mois (MB) 1 an (MB)
1,000 HSD 20 70 230 900
10,000 HSD 160 600 1,950 7,700
100,000 HSD 1,500 5,900 19,000 76,000
1,000 VDI 15 55 170 670
10,000 VDI 120 440 1,400 5,500
40,000 VDI 464 1,700 5,400 21,500

Estimations avec 2 connexions et 1 session par utilisateur avec une semaine de travail de 5 jours

Utilisateurs Tapez 1 semaine (Mo) 1 mois (Mo) 3 mois (MB) 1 an (MB)
1,000 HSD 30 100 330 1,300
10,000 HSD 240 925 3,000 12,000
100,000 HSD 2,400 9,200 30,000 119,000
1,000 VDI 25 85 280 1,100
10,000 VDI 200 750 2,500 9,800
40,000 VDI 800 3,000 9,700 38,600

Note :

Les 100 000 tests HSD sont basés sur un environnement de test composé de :

  • 2 contrôleurs de livraison
  • 43 Travailleurs hébergés Shared Desktop
  • 3 serveurs SQL, configurés avec des bases de données stockées dans un groupe de disponibilité Always On.

Pour plus d’informations, consultez l’article de support Citrix —Dimensionnement de la base de données XenDesktop 7.x.

La taille du journal des transactions pour la base de données de surveillance est très difficile à estimer, mais les tests d’évolutivité XenApp et XenDesktop ont montré un taux de croissance d’environ 30,5 Mo par heure lorsque le système est inactif, et un taux de croissance par utilisateur par jour de ~ 9 Ko.

Base de données de journalisation de la configuration

La base de données de journalisation de la configuration est généralement la plus petite des trois bases de données. Sa taille et la taille du journal de transactions associé dépendent des activités administratives quotidiennes lancées à partir de scripts Studio, Director ou PowerShell, donc sa taille est difficile à estimer. Plus les modifications de configuration sont effectuées, plus la base de données grandira. Voici quelques facteurs qui peuvent affecter la taille de la base de données :

  • Nombre d’actions effectuées dans Studio, Director et PowerShell.
  • Transactions minimales qui se produisent sur la base de données lorsqu’aucune modification de configuration n’a lieu.
  • Taux de transaction pendant les mises à jour. Les mises à jour sont groupées chaque fois que possible.
  • Données supprimées manuellement de la base de données. Les données de la base de données de journalisation de la configuration ne sont soumises à aucune stratégie de rétention. Par conséquent, elles ne sont pas supprimées sauf si elles sont effectuées manuellement par un administrateur.
  • Activités qui ont un impact sur les sessions ou les utilisateurs, par exemple la fermeture de session et la réinitialisation.
  • Mécanisme utilisé pour déployer des postes de travail.

Dans les environnements XenApp n’utilisant pas MCS, la taille de la base de données tend à se situer entre 30 et 40 Mo. Pour les environnements MCS, la taille de la base de données peut facilement dépasser 200 Mo en raison de la journalisation de toutes les données de construction de machines virtuelles.

Base de données temporaire

En plus des bases de données Site, Monitoring et Configuration Logging, une base de données temporaire à l’échelle du système (tempdb) est fournie par SQL Server. Cette base de données temporaire est utilisée pour stocker des données d’isolement de cliché validés en lecture. XenApp 7.x et XenDesktop 7.x utilise cette fonctionnalité SQL Server pour réduire la contention de verrouillage sur les bases de données XenApp et XenDesktop. Citrix recommande que toutes les bases de données XenApp 7.x et XenDesktop 7.x utilisent l’isolation de snapshots validés en lecture. Pour plus d’informations, veuillez consulterComment faire pour activer l’instantané validé en lecture dans XenDesktop.

La taille de la base de données tempdb dépendra du nombre de transactions actives, mais en général, elle ne devrait pas augmenter de plus de quelques MB. Les performances de la base de données tempdb n’affectent pas les performances du courtage XenApp et XenDesktop, car toutes les transactions qui génèrent de nouvelles données nécessitent de l’espace tempdb. XenApp et XenDesktop ont tendance à avoir des transactions de courte durée, ce qui permet de garder la taille du tempdb petite.

Le tempdb est également utilisé lorsque les requêtes génèrent de grands ensembles de résultats intermédiaires. Les conseils et la taille du tempdb peuvent être trouvés dans l’article Microsoft TechNetOptimisation des performances de tempdb.

Provisioning Services

La base de données de batterie Provisioning Services contient des données de configuration statique et de journalisation de configuration (piste d’audit). Les exigences de taille d’enregistrement décrites ci-dessous peuvent être utilisées pour aider à dimensionner la base de données :

Élément de configuration Espace DB requis (Ko) Nombre d’éléments (exemple) Total (Ko)
Configuration de la batterie de base 112 - 112
Groupe d’utilisateurs avec accès à la batterie 50 10 250
Site 4 5 20
Collecte de périphériques 10 50 500
Vue de la ferme 4 10 40
Relation entre la vue de la batterie et le périphérique 5 1 5,000
Vue du site 4 5 20
Relation entre l’affichage du site et l’appareil 5 1 5,000
Appareil 2 5,000 10,000
Bootstrap de l’appareil 10 - -
Relation entre le périphérique et le disque 35 1 175,000
Relation de l’imprimante de périphérique 1 - -
Données de personnalité de l’appareil 1 - -
État de l’appareil (au démarrage) 1 5,000 5,000
Propriété personnalisée du périphérique 2 - -
vDisk 1 20 20
Version vDisk 3 5 300
Localisateur de disque 10 1 200
Propriété personnalisée du localisateur de disque 2 - -
Serveur 5 10 50
IP du serveur 2 1 20
État du serveur (au démarrage) 1 20 20
Propriété personnalisée du serveur 2 - -
Magasin de vDisk 8 5 40
Relation entre le magasin vDisk et le serveur 4 1 40
Connexion à XenServer (VirtualHostingPool) 4 - -
Tâche de mise à jour de vDisk 10 10 100
Modification administrative (audit activé) 1 10,000 10,000
Total     211,732KB (~212MB)

Lors de la configuration de la batterie PVS, une base de données avec une taille initiale de fichier de 20 Mo est créée. En raison de la nature des données dans la base de données de la batterie PVS, le journal des transactions ne devrait pas croître très rapidement, sauf si une grande quantité de configuration est effectuée.

Contrairement à XenApp, qui offre également la possibilité de suivre les modifications administratives, les informations associées ne sont pas écrites dans une base de données dédiée mais directement dans la base de données de la batterie Provisioning Services. Afin de limiter la taille de la base de données Provisioning Services, il est recommandé d’archiver les données de piste d’audit selon un calendrier régulier.

Décision : Emplacement de la base de données

XenApp et XenDesktop utilisent trois bases de données différentes : la configuration du site, la surveillance et la journalisation de la configuration. Les trois bases de données peuvent être hébergées sur le même serveur ou sur des serveurs différents. Une configuration idéale serait d’héberger la base de données de surveillance sur un serveur différent des bases de données de configuration du site et de journalisation de la configuration. Il est préférable de séparer la base de données de surveillance car elle enregistre plus de données, les modifications se produisent plus fréquemment et les données ne sont pas considérées comme aussi critiques que les autres bases de données.

Note :

L’emplacement de la base de données de journalisation de la configuration ne peut pas être modifié lorsque la journalisation obligatoire est activée.

Décision : Haute disponibilité

Le tableau suivant met en évidence l’impact sur XenApp, XenDesktop et Provisioning Services en cas de panne de base de données :

Composant Impact de la panne de base de données
Base de données de configuration du site Les utilisateurs ne pourront pas se connecter ou se reconnecter à un poste de travail virtuel. Remarque : Lecache hôte local permet aux utilisateurs disposant de bureaux partagés hébergés, d’applications Windows et navigateur hébergés et de bureaux personnels de se reconnecter à leurs applications et bureaux même lorsque la base de données du site n’est pas disponible.
Base de données de surveillance Director n’affichera pas de données historiques et Studio ne peut pas être démarré. Le courtage des demandes d’utilisateurs entrantes et des sessions utilisateur existantes ne sera pas affecté.
Base de données de journalisation de la configuration Si autoriser les modifications lorsque la base de données est déconnectée a été activée dans les préférences de journalisation XenApp et XenDesktop, une panne de la base de données de journalisation de configuration n’aura aucun impact (sauf si les modifications de configuration ne sont pas enregistrées). Sinon, les administrateurs ne seront pas en mesure d’apporter des modifications à la configuration du site XenApp et XenDesktop. Les utilisateurs ne sont pas touchés.
Base de données de batterie Provisioning Services Lorsque la prise en charge de la base de données hors connexion est activée et que la base de données devient indisponible, le processus de flux utilise une copie locale de la base de données pour récupérer des informations sur le serveur de provisionnement et les équipements cibles pris en charge par le serveur. Cela permet aux serveurs de provisionnement et aux équipements cibles de rester opérationnels. Toutefois, lorsque la base de données est hors ligne, la console et les fonctions de gestion répertoriées ci-dessous deviennent indisponibles : ajout automatique de machines cibles ; création et mises à jour de vDisk ; modifications de mot de passe Active Directory ; démarrage du processus en flux continu ; service de mise à jour d’image ; gestion basée sur PowerShell et MCLI. Si la prise en charge de la base de données hors connexion n’a pas été activée, toutes les fonctions de gestion deviennent indisponibles et le démarrage et le basculement des équipements cibles échouent.

Note :

Veuillez consulter les options HA pour les bases de données tierces (par exemple App-V, SCVMM ou vCenter) avec le fournisseur de logiciels concerné.

Outre les options de redondance de base de données intégrées, Microsoft SQL Server, ainsi que l’hyperviseur sous-jacent (dans les environnements virtuels), offrent un certain nombre de fonctionnalités de haute disponibilité. Ils permettent aux administrateurs de s’assurer que les pannes d’un serveur unique auront un impact minimal (le cas échéant) sur l’infrastructure XenApp et XenDesktop. Les fonctionnalités de haute disponibilité SQL / hyperviseur suivantes sont disponibles :

  • HA de niveau VM : cette option de haute disponibilité est disponible uniquement pour les serveurs SQL virtuels, qui doivent être marqués pour la haute disponibilité au niveau de la couche hyperviseur. En cas d’arrêt inattendu de la machine virtuelle ou de l’hôte de l’hyperviseur sous-jacent, l’hyperviseur essaiera de redémarrer la machine virtuelle immédiatement sur un autre hôte. Bien que le HA de niveau VM puisse réduire les temps d’arrêt dans les scénarios de panne de courant, il ne peut pas se protéger contre la corruption au niveau du système d’exploitation. Cette solution est moins coûteuse que la mise en miroir ou la mise en cluster car elle utilise une fonctionnalité d’hyperviseur intégrée. Toutefois, le processus de basculement automatique est plus lent, car il peut prendre du temps de détecter une panne et de démarrer le serveur SQL virtuel sur un autre hôte. Cela peut interrompre le service aux utilisateurs.
  • Mise en miroir— La mise en miroir des bases de données augmente la disponibilité de la base de données avec basculement presque instantané. La mise en miroir de base de données peut être utilisée pour gérer une base de données de secours ou de mise en miroir unique, pour une base de données principale ou de production correspondante. La mise en miroir de base de données s’exécute soit en mode synchrone en mode haute sécurité, soit en mode asynchrone en mode hautes performances. En mode haute sécurité avec basculement automatique (recommandé pour XenDesktop), une troisième instance de serveur, appelée témoin, est requise, ce qui permet au serveur miroir d’agir en tant que serveur de secours à chaud. Le basculement de la base de données principale vers la base de données miroir se produit automatiquement et s’effectue généralement en quelques secondes. Il est recommandé d’activer l’HA de niveau VM (ou une fonctionnalité de redémarrage automatique similaire) pour au moins le témoin afin de garantir la disponibilité du service SQL en cas d’interruption de plusieurs serveurs.

Note :

Microsoft prévoit de supprimer la mise en miroir en tant qu’option haute disponibilité dans une future version de SQL Server et décourage son utilisation dans le développement du nouveau réseau. Pour plus d’informations, reportez-vous àMise en miroir de bases de données (SQL Server)l’article Microsoft

  • Instances de cluster de basculement AlwaysOn — Le clustering de basculement fournit une prise en charge de haute disponibilité pour toute une instance de Microsoft SQL Server. Un cluster de basculement est une combinaison de deux ou plusieurs nœuds, ou serveurs, utilisant un stockage partagé. Une instance de cluster de basculement AlwaysOn de Microsoft SQL Server, introduite dans SQL Server 2012, apparaît sur le réseau sous la forme d’un seul ordinateur, mais possède des fonctionnalités qui fournissent le basculement d’un nœud à un autre si le nœud actuel devient indisponible. La transition d’un nœud à l’autre est transparente pour les clients connectés au cluster. Les instances de cluster de basculement AlwaysOn nécessitent un groupe de ressources WSFC (Windows Server Failover Clustering). Le nombre de nœuds pris en charge dans le groupe de ressources WSFC dépend de l’édition SQL Server. (Veuillez vous reporter au tableauDécision : Editionci-dessus du présent chapitre.) Pour plus d’informations, reportez-vous à MSDN —Instances de cluster de basculement AlwaysOn (SQL Server).
  • Groupes dedisponibilité AlwaysOn — Grou pes de disponibilité AlwaysOn est une solution de haute disponibilité et de reprise après sinistre de niveau entreprise introduite dans Microsoft SQL Server 2012, qui permet aux administrateurs de maximiser la disponibilité pour une ou plusieurs bases de données utilisateur. Les groupes de disponibilité AlwaysOn exigent que les instances de Microsoft SQL Server résident sur des nœuds WSFC (Windows Server failover clustering). Semblable au clustering avec basculement, un seul nom IP virtuel/réseau est exposé aux utilisateurs de base de données. Contrairement au clustering avec basculement, le stockage partagé n’est pas nécessaire car les données sont transférées à l’aide d’une connexion réseau. La réplication synchrone et asynchrone sur un ou plusieurs serveurs secondaires est prise en charge. Contrairement à la mise en miroir ou la mise en cluster, les serveurs secondaires peuvent être activement utilisés pour traiter les demandes en lecture seule entrantes, les sauvegardes ou les vérifications d’intégrité. Cette fonctionnalité peut être utilisée pour décharger les demandes d’énumération de ressources utilisateur vers un serveur SQL secondaire dans les environnements XenDesktop afin de développer essentiellement une infrastructure SQL Server. Étant donné que les données sur les serveurs secondaires actifs peuvent être retardées de plusieurs secondes par rapport au serveur principal, la fonctionnalité de routage en lecture seule ne peut pas être utilisée pour d’autres demandes de base de données XenDesktop à ce stade. Pour plus d’informations, reportez-vous à MSDN —Groupes de disponibilité AlwaysOn (SQL Server).

Le tableau suivant décrit les fonctionnalités de haute disponibilité recommandées pour les bases de données Citrix :

Dans le tableau :

  • Y indique Recommandé.
  • o indique V able.
  • N indiqué Non pris en charge.
  • T indique uniquement pour les environnements de test.
Composant Niveau VM - HA Mise en miroir Instances de cluster de basculement AlwaysOn Groupes de disponibilité AlwaysOn
Base de données du site T Y o o
Base de données de journalisation de la configuration T o o o
Base de données de surveillance T Y o o
Base de données de batterie Provisioning Services T Y o o
Base de données DesktopPlayer T N o o

Licences Citrix

Citrix offre aux entreprises la flexibilité de plusieurs modèles de licence qui s’harmonisent avec des scénarios d’utilisation courants. Les différents modèles de licence varient en fonction du produit Citrix utilisé, mais peuvent inclure par utilisateur/périphérique et par utilisateur simultané. Plusieurs produits Citrix utilisent le serveur de licences, tandis que d’autres produits nécessitent une licence pour être installés sur le produit lui-même.

Serveur de licences Citrix

  • XenDesktop
  • XenApp
  • Provisioning Services
  • XenServer

Sur le produit :

  • NetScaler
  • NetScaler Gateway

Pour plus d’informations sur les licences XenDesktop 7.x, reportez-vous àCTX128013- XenDesktop Licensing.

Pour plus d’informations sur les licences Microsoft, reportez-vous au document Microsoft —Licence de licences pour la technologie d’infrastructure de bureau virtuel de Microsoft.

Décision : Calibrage

Les tests d’évolutivité interne ont montré qu’un serveur de licences virtuel unique avec deux cœurs et 2 Go de RAM peut émettre environ 170 licences par seconde ou 306 000 licences par demi-heure. Si nécessaire, la spécification du serveur de licences peut être mise à l’échelle pour prendre en charge un plus grand nombre de demandes de licence par seconde.

Décision : Haute Disponibilité

Pour un environnement typique, un serveur de licences unique suffit. Si le serveur de licences devient indisponible, les produits Citrix dépendants entreront dans une période de grâce de 30 jours, ce qui donne plus que suffisamment de temps pour résoudre les problèmes de connectivité et/ou restaurer ou reconstruire le serveur de licences.

Note :

  • Si le serveur de licences et le produit Citrix ne communiquent pas dans les 2 battements cardiaques (5-10 min), le produit Citrix entrera dans un délai de grâce et autorisera les connexions pendant 30 jours maximum. Une fois la communication avec le serveur de licences rétablie, le serveur de licences réconcilie les licences temporaires et réelles.
  • Un enregistrement CNAME dans DNS est un moyen pratique de référencer le serveur de licences. L’utilisation de CNAMEs permet de modifier le nom du serveur de licences sans mise à jour des produits Citrix.

Si une redondance supplémentaire est requise, Citrix prend en charge les solutions de haute disponibilité suivantes pour le serveur de licences.

  • Clustering Windows : les serveurs de cluster sont des groupes d’ordinateurs qui fonctionnent ensemble afin d’augmenter la disponibilité. Le clustering permet au rôle serveur de licences de basculer automatiquement en cas de défaillance. Pour plus d’informations sur le clustering, consultez l’article Citrix Docs —Serveurs de licences en cluster.
  • Duplication du serveur de licences : créez une sauvegarde au niveau de la machine virtuelle du serveur de licences. Cette sauvegarde ne doit pas être stockée sur le même hôte que le serveur de licences. Au lieu de cela, il doit être stocké dans un endroit sûr, comme une solution de stockage hautement disponible, ou sauvegardé sur bande ou disque. Le serveur dupliqué n’est pas actif et restera en veille jusqu’à ce que le serveur de licences actif soit restauré. Si le serveur de licences est restauré à l’aide de cette sauvegarde, toutes les nouvelles licences doivent être téléchargées à nouveau sur le serveur.

Pour plus d’informations, reportez-vous à Citrix eDocs —Présentation de l’architecture des licences.

Chaque méthode permet à un administrateur d’échanger un serveur de licences unique contre un autre sans interruption de service ; en supposant que la modification se produit pendant la période de grâce et que les limitations suivantes sont prises en compte.

  • Les fichiers de licence font référence au serveur spécifié pendant le processus d’allocation. Cela signifie que les fichiers de licence ne peuvent être utilisés que sur un serveur avec les mêmes informations de liaison (nom d’hôte) que le serveur précédemment spécifié.
  • Deux serveurs de licences joints à un domaine Windows ne peuvent pas partager le même nom et être actifs dans l’environnement en même temps.
  • Comme les serveurs de licences ne communiquent pas entre eux, toutes les licences supplémentaires doivent être placées à la fois sur le serveur de licences actif et de sauvegarde.

Décision : Optimisation

Les performances du serveur de licences peuvent être optimisées en réglant le nombre de threads « recevoir » et « traiter ». Si le nombre de threads est trop bas, les requêtes seront mises en file d’attente jusqu’à ce qu’un thread devienne disponible. Inversement, si le nombre de threads est trop élevé, le serveur de licences sera surchargé.

Les valeurs optimales dépendent du matériel du serveur, de la configuration du site et du volume de demande de licence. Citrix recommande de tester et d’évaluer différentes valeurs pour déterminer la configuration appropriée. Définir le nombre maximal de threads de traitement à 30 et le nombre maximal de threads de réception à 15 est un bon point de départ pour les déploiements à grande échelle.

Cette optimisation améliorera la capacité du serveur de licences Citrix à fournir des licences en augmentant sa capacité à recevoir et à traiter les demandes de licence.

Pour plus d’informations, reportez-vous à Citrix Docs —Amélioration des performances en spécifiant l’utilisation du thread.

Contrôleurs de livraison

Décision : Taille du serveur

L’évolutivité du Delivery Controller est basée sur l’utilisation du processeur. Plus les cœurs de processeur sont disponibles, plus un contrôleur peut prendre en charge de postes de travail virtuels. Chaque demande de démarrage, d’enregistrement, d’énumération et de lancement du bureau a un impact sur le processeur du contrôleur. À mesure que la tempête augmente en intensité, l’utilisation du processeur du contrôleur augmentera. Si le CPU atteint un seuil critique, soit environ 80 %, le site devra être mis à l’échelle ou à l’échelle.

L’ajout de cœurs de processeur supplémentaires à un Delivery Controller réduira l’utilisation globale du processeur, permettant ainsi un plus grand nombre de postes de travail pris en charge par un seul contrôleur. Cela n’est vraiment possible que lorsque vous traitez avec des contrôleurs virtualisés, car l’ajout de processeurs virtuels est assez facile et simple. L’autre alternative consiste à ajouter un autre contrôleur dans la configuration du site. Le contrôleur aurait la même configuration que les autres contrôleurs, et la charge serait répartie uniformément entre tous les contrôleurs, ce qui contribuerait à réduire la charge globale sur chaque contrôleur.

Les tests ont montré qu’un Delivery Controller unique, utilisant la configuration suivante, peut prendre en charge plus de 5 000 postes de travail.

Composant Spécifications
Processeur 4 processeurs virtuels
Mémoire 4 GO DE RAM
Réseau Carte réseau virtuelle connectée
Stockage hôte Stockage partagé de 40 Go
Système d’exploitation Windows Server 2012 R2
XenDesktop 7

La formule suivante peut être utilisée pour calculer le nombre de Delivery Controller requis pour un site Citrix.

Nombre d'images des contrôleurs de livraison

Décision : Haute disponibilité

Si le serveur hébergeant le Delivery Controller n’est pas disponible, les utilisateurs ne pourront pas accéder à leurs postes de travail virtuels ou à leurs applications publiées. Par conséquent, au moins deux Delivery Controller (redondance N + 1) doivent être déployés par zone sur différents serveurs physiques pour éviter que ce composant ne devienne un point de défaillance unique. Si un contrôleur échoue, les autres peuvent gérer les connexions et administrer le site.

Les emplacements de tous les Delivery Controller sont spécifiés sur le VDA, ce qui lui permet de basculer automatiquement si la communication avec un Delivery Controller n’est pas disponible. Le VDA vérifie les emplacements suivants, dans l’ordre, s’arrêtant au premier endroit où il trouve le Delivery Controller :

  1. Emplacement de stockage persistant maintenu pour la fonctionnalité de mise à jour automatique. Cet emplacement contient des informations sur le contrôleur lorsque la mise à jour automatique est activée et après l’enregistrement du VDA pour la première fois après l’installation. 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. Paramètres de stratégie (Delivery Controller, Delivery Controller SID).
  3. Les informations du Delivery Controller sous la clé de Registre VDA ListofDDCs. Le programme d’installation du VDA remplit initialement ces valeurs, en fonction des informations spécifiées lors de l’installation du VDA.
  4. Découverte basée sur l’UA. Il s’agit d’une méthode héritée maintenue pour assurer la compatibilité ascendante.
  5. Fichier Personality.ini créé par Machine Creation Services.

Citrix Consulting recommande d’utiliser la fonctionnalité de mise à jour automatique (activée par défaut). Cette fonctionnalité simplifiera la gestion de l’environnement en gardant les VDA à jour lors de l’ajout et de la suppression de Delivery Controller.

Décision : Cache hôte local

Même si la base de données SQL est hautement disponible, il y a le risque de ne pas avoir accès à la base de données si la connexion réseau entre le Delivery Controller et la base de données SQL échoue, ce qui est une préoccupation importante pour les sites qui couvrent des emplacements géographiques.

Pour surmonter ce risque, les Delivery Controller peuvent utiliser la fonctionnalité de cache hôte local qui crée une copie locale de la base de données SQL, utilisée uniquement si le Delivery Controller perd le contact avec la base de données.

Les éléments suivants doivent être pris en compte lors de l’utilisation du cache hôte local :

  • Elections : lorsque les zones perdent le contact avec la base de données SQL, une option se produit pour désigner un Delivery Controller unique comme maître. Tous les Controller restants passent en mode inactif. Un ordre alphabétique simple détermine le gagnant de l’élection.
  • Dimensionnement : lors de l’utilisation du mode cache hôte local, un Delivery Controller unique est responsable de tous les enregistrements VDA, énumérations, lancements et mises à jour. Le Controller élu doit avoir suffisamment de ressources (CPU et RAM) pour gérer la totalité de la charge de la zone. Un contrôleur unique peut évoluer jusqu’à 10 000 utilisateurs, ce qui influence la conception de la zone.
    • RAM : les services de cache de l’hôte local peuvent consommer plus de 2 Go de RAM en fonction de la durée de l’interruption et du nombre de lancements d’utilisateur pendant la panne.
    • CPU : le cache hôte local peut utiliser jusqu’à 4 cœurs dans un seul socket.
    • Stockage : en mode cache de l’hôte local, l’espace de stockage a augmenté de 1 Mo toutes les 2-3 minutes, avec une moyenne de 10 ouvertures de session par seconde.
  • Options d’alimentation : les ressources virtuelles hors tension ne démarrent pas lorsque le Delivery Controller est en mode cache de l’hôte local. Les bureaux virtuels regroupés qui redémarrent à la fin d’une session sont placés en mode de maintenance.
  • Consoles : lorsque vous utilisez le mode cache hôte local, Studio et PowerShell ne sont pas disponibles.

Décision : XML Service Encryption

Dans une session standard, le serveur StoreFront transmet les informations d’identification au service XML Citrix sur un Delivery Controller. Le protocole XML Citrix utilise du texte clair pour échanger toutes les données, à l’exception des mots de passe, qui sont transmis par obfuscation.

Si le trafic entre les serveurs Storefront et les contrôleurs XenDesktop peut être intercepté, il sera vulnérable aux attaques suivantes :

  • Les attaquants peuvent intercepter le trafic XML et voler des informations et des tickets sur les ensembles de ressources.
  • Les attaquants ayant la capacité de craquer l’obfuscation peuvent obtenir les informations d’identification de l’utilisateur.
  • Les attaquants peuvent emprunter l’identité du contrôleur XenDesktop et intercepter les demandes d’authentification.

Pour la plupart des organisations, le trafic XML Citrix sera isolé sur un réseau de centre de données physique ou virtuel dédié, ce qui rend l’interception peu probable. Toutefois, pour des raisons de sécurité, pensez à utiliser le chiffrement SSL pour envoyer des données StoreFront via une connexion HTTP sécurisée.

Décision : Gestion de la charge du système d’exploitation de serveur

Les stratégies de gestion de la charge par défaut sont appliquées à tous les groupes de mise à disposition du système d’exploitation de serveur. Les paramètres par défaut spécifient le nombre maximal de sessions qu’un serveur peut héberger à 250 et ne tiennent pas compte de l’utilisation du processeur et de la mémoire. La limitation du nombre de sessions ne fournit pas une véritable indication de la charge, ce qui peut entraîner une surcharge des groupes de mise à disposition du système d’exploitation de serveur, entraînant une dégradation des performances ou une sous-utilisation des groupes de mise à disposition du système d’exploitation de serveur, entraînant une utilisation inefficace des ressources.

Citrix Consulting recommande de créer des stratégies de gestion de la charge « personnalisées » uniques pour chaque groupe de mise à disposition en fonction des tests de performances et d’évolutivité. Des règles et des seuils différents peuvent être appliqués à chaque groupe de mise à disposition en fonction des différents goulets d’étranglement des ressources identifiés lors du test. Pour plus d’informations sur les configurations de stratégie de gestion de la charge disponibles, reportez-vous à Citrix Docs —Paramètres de stratégie de gestion des charges.

Si des tests adéquats ne peuvent pas être effectués avant la production, Citrix Consulting recommande d’implémenter la stratégie de gestion de la charge « personnalisée » suivante, qui peut être appliquée à tous les serveurs en tant que ligne de base :

  • Utilisation du processeur - pleine charge : 80%
  • Priorité du processus d’utilisation du processeur exclue — inférieure à la normale ou faible
  • Utilisation de la mémoire - pleine charge : 80%
  • Charge de base de l’utilisation de la mémoire — Signaler une charge nulle (MBs) : 786
  • Nombre maximal de sessions — X

La stratégie « Nombre maximal de sessions » est incluse à des fins de plafonnement, ce qui est considéré comme une pratique exemplaire en matière de résilience. Les organisations peuvent choisir une valeur initiale de 250 (indiquée par « X » ci-dessus). Il est fortement recommandé de personnaliser cette valeur et d’autres en fonction des résultats des tests d’évolutivité.

Connecteur Coud

XenApp et XenDesktop Service dans Citrix Cloud utilisent un ensemble de services contenus dans Citrix Cloud Connector. Un ensemble redondant de machines virtuelles Cloud Connector doit être placé dans chaque centre de données/emplacement de ressource contenant des hôtes VDA.

Décision : Taille du serveur

L’évolutivité du Cloud Connector est basée sur l’utilisation du processeur. Plus les cœurs de processeur sont disponibles, plus les postes de travail virtuels qu’un connecteur cloud peut prendre en charge. Chaque demande de démarrage, d’enregistrement, d’énumération et de lancement de bureau affecte le processeur du connecteur cloud. À mesure que la tempête augmente en intensité, l’utilisation du processeur du connecteur de nuage augmentera. Si le CPU atteint un seuil critique, soit environ 80 %, le site devra être mis à l’échelle ou à l’échelle.

Les tests ont montré qu’un seul contrôleur Cloud Connector, utilisant la configuration suivante, peut prendre en charge 5 000 postes de travail.

Composant Spécifications sur place Spécifications hébergées Azure
Nombre de machines virtuelles (avec tolérance de panne N + 1) 3 6 instances standard_A2_V2
Processeurs par machine virtuelle 4 processeurs virtuels 2 vCPU
Mémoire par machine virtuelle 4 GO DE RAM 4 GO DE RAM
Stockage hôte par machine virtuelle 40 Go de stockage partagé 200 Go de stockage temporaire
Système d’exploitation Windows Server 2012 R2 Windows Server 2012 R2

Provisioning Services

Citrix Provisioning Services (PVS) utilise la technologie de diffusion en continu pour simplifier le déploiement des machines virtuelles et physiques. Les ordinateurs sont provisionnés et reprovisionnés en temps réel à partir d’une seule image de disque partagé. Ce faisant, les administrateurs peuvent éliminer complètement la nécessité de gérer et de corriger des systèmes individuels. Au lieu de cela, toute la gestion des images est effectuée sur l’image principale.

Décision : Topologie

Une batterie de serveurs Provisioning Services représente le niveau supérieur de l’infrastructure Provisioning Services, qui peut être décomposée en sites. Tous les serveurs d’approvisionnement d’une batterie partagent la même base de données SQL et le même serveur de licences Citrix.

Chaque site est une entité logique contenant des serveurs de provisioning, des pools vDisk et des collections de machines cibles. Bien que tous les sites d’une batterie partagent la même base de données, les machines cibles ne peuvent basculer que vers d’autres serveurs de provisionnement au sein du même site.

Image de la structure du site PVS

Certains facteurs doivent être pris en compte lors de la détermination de la topologie globale de Provisioning Services :

  • Réseau : les serveurs de provisioning communiquent constamment avec la base de données de la batterie de serveurs pour récupérer les paramètres de configuration du système. Par conséquent, des batteries distinctes doivent être créées pour chaque emplacement physique où résident les machines cibles, sauf si elles sont connectées au serveur de base de données par une connexion rapide et robuste.
  • Administration — Les organisations peuvent avoir besoin de maintenir la séparation des tâches administratives au niveau ministériel, régional ou national. Des batteries de serveurs Provisioning Services supplémentaires ajouteront une certaine complexité à la gestion de l’environnement. Toutefois, cette surcharge est généralement limitée à la configuration initiale, à la création de postes de travail et aux mises à jour d’image.
  • Organisation — Une raison pratique de construire plusieurs sites est due à des changements organisationnels. Par exemple, deux sociétés ont peut-être récemment fusionné par acquisition, mais doivent garder les ressources séparées pendant l’intégration. La configuration de l’organisation pour utiliser des sites distincts est une façon de séparer les entreprises, mais gérée de manière centralisée via la console Provisioning Services.

Créez des sites supplémentaires uniquement si les besoins de l’entreprise le justifient. Un seul site par batterie est plus facile à gérer et ne nécessite aucune configuration supplémentaire.

Décision : Collections de périphériques

Les collections de périphériques permettent de créer et de gérer des groupes logiques de machines cibles. La création de collections de périphériques simplifie la gestion des périphériques en permettant d’effectuer des actions au niveau de la collection plutôt qu’au niveau de la machine cible.

Image de structure de collection de périphériques

Les collections de périphériques peuvent représenter des emplacements physiques, des plages de sous-réseaux, des châssis ou différents services au sein d’une organisation. Les collections peuvent également être utilisées pour séparer logiquement les équipements cibles de production des équipements de test et de maintenance.

Envisagez de créer des collections de périphériques basées sur l’attribution de vDisk afin que l’état de toutes les machines cibles affectées à un vDisk particulier puisse être rapidement identifié.

Décision : Haute disponibilité

Provisioning Services est un composant essentiel de l’infrastructure de bureau virtuel. Les recommandations suivantes devraient être suivies pour éliminer les points de défaillance uniques :

  • Serveur de provisioning : au moins deux serveurs de provisioning doivent toujours être implémentés par site. Une redondance suffisante doit être intégrée à la conception de sorte qu’une défaillance de serveur unique ne réduise pas le nombre total d’équipements cibles pouvant être pris en charge par site. Le fichier de démarrage Provisioning Services doit être configuré pour la haute disponibilité. Jusqu’à quatre serveurs Provisioning Server peuvent être répertoriés dans le fichier de démarrage. Les équipements cibles essaieront de contacter les serveurs dans l’ordre dans lequel ils sont répertoriés. Le serveur qui répond peut ne pas nécessairement être le serveur qui fournira des services de diffusion en continu à l’équipement cible. Si l’équilibrage de la charge est activé, la machine cible peut être réaffectée à un autre serveur du site qui est moins chargé que les autres.
  • vDisks and Storage : pour les magasins vDisk hébergés sur un réseau local, DAS (Direct Attached Storage) ou un réseau SAN (Storage Area Network), la réplication doit être utilisée pour synchroniser les vDisks. Si vous utilisez Network Attached Storage (NAS), assurez-vous que les vDisks sont hébergés sur un partage réseau hautement disponible.
  • Mise en réseau : les serveurs de provisioning doivent avoir des cartes réseau redondantes. Si le serveur de provisioning est déployé en tant que serveur physique, les cartes réseau redondantes doivent être associées et si le serveur de provisioning est déployé en tant que serveur virtuel, l’hyperviseur sous-jacent doit incorporer des cartes réseau redondantes.

Note :

Les machines cibles basculent uniquement vers les cartes réseau qui se trouvent sur le même sous-réseau que la carte réseau de démarrage PXE.

Trivial File Transfer Protocol (TFTP) est un protocole de communication utilisé pour transférer des fichiers de configuration ou de démarrage entre les machines. Les services de provisioning peuvent utiliser TFTP pour distribuer le fichier d’amorçage aux machines cibles. Plusieurs options sont disponibles pour rendre le service TFTP hautement disponible. Certaines des options les plus couramment utilisées sont :

  • DNS Round Robin : une entrée DNS est créée pour le service TFTP avec plusieurs enregistrements A correspondant aux services TFTP exécutés sur les serveurs de provisionnement de la batterie. Cette méthode n’est pas recommandée car l’état du service TFTP n’est pas surveillé. Les clients peuvent potentiellement être envoyés à un serveur qui ne fonctionne pas.
  • Équilibreur de charge matérielle : utilisez un équilibreur de charge matériel, tel que Citrix NetScaler, pour créer des adresses IP virtuelles correspondant aux serveurs de provisioning. NetScaler peut acheminer intelligemment le trafic entre les serveurs de provisioning. Dans le cas où l’un des serveurs devient indisponible, NetScaler arrêtera automatiquement le routage des requêtes TFTP vers ce serveur. C’est la meilleure méthode pour rendre TFTP hautement disponible, mais peut être compliquée à configurer.
  • Plusieurs entrées DHCP Option 66 — Cette méthode est facile à implémenter, mais nécessite un service DHCP qui prend en charge la saisie de plusieurs entrées dans l’option 66. Le serveur DHCP Microsoft permet une entrée de l’option 66, de sorte que cette méthode ne serait pas réalisable dans les environnements avec les services Microsoft DHCP. Si vous utilisez un serveur DHCP ou une appliance non Microsoft, vérifiez auprès du fabricant que plusieurs entrées de l’option 66 sont prises en charge.

Il existe d’autres options disponibles qui peuvent obtenir le même résultat sans avoir à utiliser TFTP :

  • Proxy DHCP — Utilisez le service PXE des serveurs de provisioning pour fournir les informations d’amorçage. Si l’un des serveurs est hors service, le serveur disponible suivant de la batterie peut fournir les informations d’amorçage. Cette méthode nécessite que les serveurs de provisionnement soient sur le même domaine de diffusion que les machines cibles. Si d’autres services PXE sont en cours d’exécution sur le réseau (Altiris, SCCM, etc.), plusieurs VLAN peuvent être nécessaires pour empêcher les services PXE d’interférer les uns avec les autres.
  • Gestionnaire de périphériques d’amorçage : utilisez le Gestionnaire de périphériques d’amorçage pour créer un fichier d’amorçage placé sur le disque dur local ou utilisé comme fichier ISO amorçable. Si le fichier ISO est utilisé, configurez les machines cibles pour qu’elles démarrent à partir du lecteur de CD/DVD -ROM et placez le fichier ISO sur un emplacement réseau partagé hautement disponible ou un stockage local de chaque machine cible. Lorsque l’une ou l’autre des méthodes est utilisée, le service TFTP n’est pas du tout utilisé.

La haute disponibilité doit toujours être intégrée à la conception Provisioning Services. Bien que la haute disponibilité puisse nécessiter des ressources supplémentaires et des coûts accrus, elle offrira un environnement hautement stable, de sorte que les utilisateurs subissent un impact minimal en raison des pannes de service.

Décision : Bootstrap Delivery

Une machine cible lance le processus de démarrage en chargeant d’abord un programme d’amorçage qui initialise la session de streaming entre l’équipement cible et le serveur de provisioning. Il existe trois méthodes dans lesquelles l’équipement cible peut recevoir le programme d’amorçage :

Utilisation des options DHCP

  1. Lorsque l’équipement cible démarre, l’équipement cible envoie une diffusion pour l’adresse IP et les informations de démarrage. DHCP traitera cette demande et fournira une adresse IP ainsi que les paramètres d’option 66 (nom ou adresse IP du serveur TFTP Provisioning Services) et 67 (nom du fichier d’amorçage).

    Note :

    Si vous utilisez un équilibreur de charge pour le service TFTP, l’adresse de l’équilibreur de charge est entrée dans l’option 66.

  2. À l’aide de TFTP, une requête pour le fichier d’amorçage est envoyée de la machine cible au serveur d’approvisionnement. La machine cible télécharge le fichier de démarrage à partir du serveur de provisioning.

  3. L’équipement cible démarre l’image vDisk assignée.

Note :

Nécessite la configuration de l’assistant UDP/DHCP lorsque les cibles ne sont pas sur le même sous-réseau que les serveurs DHCP afin de recevoir des diffusions PXE.

Utilisation des diffusions PXE

  1. Lorsqu’une machine cible démarre à partir du réseau, la machine cible envoie une diffusion pour une adresse IP et des informations de démarrage. DHCP traitera cette demande et fournira une adresse IP. En outre, tous les serveurs d’approvisionnement qui reçoivent la diffusion renvoient les informations sur le serveur d’amorçage et le nom du fichier d’amorçage. La machine cible fusionnera les informations reçues et lancera le processus de démarrage.

  2. À l’aide de TFTP, une requête pour le fichier d’amorçage est envoyée de la machine cible au serveur d’approvisionnement qui a répondu en premier. La machine cible télécharge le fichier de démarrage à partir du serveur de provisioning.

Note :

  • Assurez-vous qu’aucun autre service PXE n’est utilisé sur le même sous-réseau, tel que le service Altiris PXE, ou isolez à l’aide de VLAN, sinon des conflits peuvent se produire avec Provisioning Services.
  • Nécessite la configuration de l’assistant UDP/DHCP lorsque les cibles ne sont pas sur le même sous-réseau que les serveurs DHCP et PVS afin de recevoir des diffusions PXE.

Utilisation du Gestionnaire de périphériques de démarrage : le Gestionnaire de périphériques de démarrage (BDM) crée un fichier de démarrage que les machines cibles obtiennent via un CD/DVD physique, une image ISO montée ou un disque dur virtuel affecté à la machine cible. Une partition BDM peut être mise à niveau de l’une des trois façons suivantes :

  • Par collection
  • Par un groupe de périphériques mis en surbrillance
  • Par un seul appareil

Un résumé des avantages et des inconvénients de chaque mode de livraison est présenté dans le tableau suivant :

Mode de livraison Avantages Inconvénients
Options DHCP Facile à implémenter Nécessite des modifications au service DHCP de production. Le service DHCP ne peut autoriser qu’une seule option 66 entrée. Nécessite un assistant UDP/DHCP pour les cibles sur différents sous-réseaux.
PXE Facile à implémenter Peut interférer avec d’autres services PXE en cours d’exécution sur le même sous-réseau. Nécessite une aide UDP/DHCP pour les cibles sur différents sous-réseaux.
ISO BDM Ne nécessite pas de services PXE ou TFTP Effort supplémentaire requis pour démarrer les équipements cibles physiques. BDM ISO est considéré comme un point de défaillance unique si un seul fichier est utilisé.
Partition BDM La mise à niveau de la partition de démarrage BDM ne nécessite pas PXE, TFTP ou TSB ; elle est considérée comme un chargeur d’amorçage unique, au moment du démarrage, elle trouve automatiquement toutes les informations pertinentes du serveur PVS et n’a pas besoin de services externes fournis par PXE, TFTP ou TSB. Une partition supplémentaire de 8 Mo est créée pour chaque équipement cible.

Note :

Lors de la configuration du fichier d’amorçage, jusqu’à quatre serveurs d’approvisionnement peuvent être répertoriés. L’ordre dans lequel les serveurs de provisioning apparaissent dans la liste détermine l’ordre d’accès aux serveurs de provisioning. Si le premier serveur ne répond pas, le serveur suivant de la liste est contacté.

Décision : Format vDisk

Provisioning Services prend en charge l’utilisation de vDisks dynamiques ou de taille fixe :

  • Disque de taille fixe : pour les vDisks en mode privé, la taille fixe empêche la fragmentation du disque et offre des performances d’écriture améliorées par rapport aux disques dynamiques.
  • Disque dynamique : les disques dynamiques nécessitent moins d’espace de stockage que les disques de taille fixe, mais offrent des performances d’écriture nettement inférieures. Bien que les vDisks en mode partagé n’effectuent pas d’écritures sur le vDisk, le temps nécessaire pour terminer les opérations de fusion vDisk augmentera avec les disques dynamiques. Ce n’est pas une occurrence courante car plus d’environnements choisissent de créer de nouveaux vDisks lors de la mise à jour.

Étant donné que la plupart des lectures seront faites sur le cache système en RAM, il n’y a pas de changement significatif dans les performances lors de l’utilisation de disques de taille fixe ou dynamiques. En outre, les disques dynamiques nécessitent beaucoup moins d’espace de stockage. Par conséquent, les disques dynamiques sont recommandés.

Décision : Réplication vDisk

Les vDisks hébergés sur un stockage local, Direct Attached Storage ou un SAN doivent être répliqués entre les magasins vDisk chaque fois qu’un vDisk est créé ou modifié. Provisioning Services prend en charge la réplication de vDisks à partir de magasins locaux vers le serveur de provisioning, ainsi que la réplication sur plusieurs sites utilisant le stockage partagé. La réplication des vDisks peut être effectuée manuellement ou automatiquement :

  • Manu elle — La réplication manuelle est simple, mais peut prendre du temps, selon le nombre de magasins vDisks et vDisk. Si une erreur se produit pendant le processus de réplication, les administrateurs peuvent les intercepter immédiatement et prendre les mesures appropriées pour les résoudre. Le risque de réplication manuelle est l’incohérence vDisk entre les serveurs de provisioning, ce qui entraîne un équilibrage de charge et un basculement ne fonctionnant pas correctement. Par exemple, si un vDisk est répliqué sur trois serveurs et que l’un des vDisks est mis à jour, ce vDisk n’est plus identique et ne sera pas pris en compte si un basculement de serveur se produit. Même si la même mise à jour est effectuée sur les deux autres vDisks, les horodatages de chacun seront différents, et les vDisks ne sont donc plus identiques.
  • Automatisé — Pour les environnements volumineux, la réplication automatisée est plus rapide que la méthode manuelle en raison du nombre de vDisks et vDisk Stores requis. Certains outils automatisés, tels queMicrosoft DFS-R, prennent en charge la limitation de la bande passante et la compression différentielle à distance croisée (CF-RDC), qui utilisent des heuristiques pour déterminer si les fichiers de destination sont similaires au fichier répliqué. Si tel est le cas, CF-RDC utilisera des blocs de ces fichiers pour minimiser la quantité de données transférées sur le réseau. Le risque de réplication automatisée est que l’administrateur ne surveille généralement pas les événements de réplication en temps réel et ne réagit pas rapidement en cas d’erreur, à moins que l’outil d’automatisation ne dispose d’une fonction d’alerte. Certains outils peuvent être configurés pour redémarrer automatiquement le processus de copie en cas d’échec. Par exemple,Robocopieprend en charge la « reprise de la copie » dans le cas où la connexion réseau est interrompue.

Pour les projets de taille moyenne et grande, utilisez un outil pour automatiser la réplication vDisk. Sélectionnez un outil capable de reprendre les interruptions du réseau, de copier les attributs de fichier et de préserver l’horodatage d’origine.

Note :

L’équilibrage de charge et la haute disponibilité ne fonctionneront pas à moins que les vDisks aient des horodatages identiques.

Décision : Taille du serveur

Généralement, un serveur Provisioning Server est défini avec les spécifications suivantes :

Composant Spécifications
Modèle Virtuelle
Processeur 4 - 8 vCPU
Mémoire 2 Go + (nombre de vDisks * 2 Go)
Réseau Carte réseau 10 Gbit/s
Réseau 40 Go de stockage partagé
Stockage vDisk Selon le nombre d’images/révisions
Système d’exploitation Windows Server 2012 R2

Modèle

Citrix Provisioning Services peut être installé sur des serveurs virtuels ou physiques :

  • Virtuel : offre un provisionnement rapide du serveur, des instantanés pour des scénarios de récupération ou de restauration rapide et la possibilité d’ajuster les ressources du serveur à la volée. Les serveurs de provisionnement virtuel permettent de distribuer des équipements cibles sur un plus grand nombre de serveurs, ce qui contribue à réduire l’impact des défaillances du serveur. La virtualisation permet une utilisation plus efficace des ressources système.
  • Physique : offre des niveaux d’évolutivité supérieurs par serveur que les serveurs virtuels. Les serveurs de provisionnement physique atténuent les risques associés aux machines virtuelles en concurrence pour les ressources d’hyperviseur sous-jacentes. En général, les serveurs de provisionnement virtuel sont préférables lorsque des ressources suffisantes de processeur, de mémoire, de disque et de réseau peuvent être mises à disposition et garanties de disponibilité.

Note :

Pour une haute disponibilité, assurez-vous que les serveurs de provisioning virtuels sont distribués sur plusieurs hôtes de virtualisation. La distribution des serveurs virtuels sur plusieurs hôtes élimine un seul point de défaillance et ne supprime pas la totalité de la batterie Provisioning Services en cas de défaillance de l’hôte.

CPU

Provisioning Services n’est pas gourmand en CPU. Cependant, en allouant le nombre de CPU a un impact sur l’optimisation des flux réseau. Le nombre de flux qu’un serveur Provisioning Services peut exécuter simultanément peut être déterminé par la formule suivante :

Nombre maximal de flux = nombre de ports x nombre de threads ou de ports

Par défaut, le service de diffusion en continu est configuré avec 20 ports réseau séquentiels et 8 threads par port. Par conséquent, par défaut, un serveur de provisioning peut prendre en charge 160 cibles simultanées. Si plus de 160 flux sont requis, Provisioning Services bascule continuellement entre différents équipements cibles en continu

Idéalement, si l’environnement doit prendre en charge plus de 160 cibles simultanées, le nombre de ports et de threads par port peut être ajusté dans la console Provisioning Services. Les meilleures performances sont atteintes lorsque les threads par port ne sont pas supérieurs au nombre de cœurs disponibles sur le serveur de provisioning. Si le serveur de provisioning ne dispose pas de cœurs suffisants, le serveur affiche une utilisation de CPU plus élevée, et les équipements cibles en attente de traitement des demandes ont une latence de lecture plus élevée.

Même si Provisioning Services n’est pas gourmand en CPU, l’allocation de 2 CPU nécessitera une plage de ports réseau contigus plus importante.

  • Petits environnements (jusqu’à environ 500 machines virtuelles), 4 processeurs virtuels sont recommandés.
  • Environnements plus grands, 8 vCPU sont recommandés.

BÉLIER

Le système d’exploitation Windows hébergeant Provisioning Services met en cache partiellement les vDisks en mémoire (cache système) réduisant le nombre de lectures requises à partir du stockage. La lecture à partir du stockage est significativement plus lente que la lecture à partir de la mémoire. Par conséquent, les serveurs Provisioning Server doivent disposer d’une mémoire suffisante pour maximiser les avantages de ce processus de mise en cache.

La formule suivante peut être utilisée pour déterminer la quantité optimale de mémoire à allouer à un serveur de provisionnement :

𝑇𝑜𝑡𝑎𝑙 𝑆𝑒𝑟𝑣𝑒𝑟 𝑅𝐴𝑀 = 2𝐺𝐵 + (# 𝑜𝑓 𝑣𝐷𝑖𝑠𝑘𝑠 ∗ 2𝐺𝐵)

Réseau

Contrairement à la plupart des autres composants XenApp et XenDesktop, Provisioning Services ne goulot pas d’étranglement le processeur. L’évolutivité de Provisioning Services repose sur le débit réseau.

Le tableau suivant indique la quantité approximative de données dont Provisioning Services a besoin pour démarrer différents systèmes d’exploitation :

Système d’exploitation Utilisation moyenne des données de démarrage (Mo)
Windows 10 x64 240
Windows 8 x86 178
Windows 8 x64 227
Windows 7 x86 166
Windows 7 x64 210
Windows 2012 225
Windows 2012R2 232
Windows 2008R2 251
Windows Vista x86 190
Windows Vista x64 240

La détermination du temps nécessaire au démarrage des machines cibles peut être estimée à l’aide de la formule suivante :

Secondes avant l'image de formule de démarrage

Système d’exploitation Nombre de machines virtuelles Débit réseau Temps de démarrage
Windows 10 x64 500 1 Gbit/s 960 Secondes (16 minutes)
Windows 10 x64 500 10 Gbit/s 96 Secondes (1 minute, 36 secondes)

Un réseau de 10 Gbit/s est recommandé pour une utilisation avec Provisioning Services. Si un réseau 10 Gbit/s n’est pas disponible, envisagez l’agrégation de liens pour fournir une bande passante supplémentaire aux serveurs d’approvisionnement ou à un réseau de diffusion physique dédié.

Astuce

Les pare-feu peuvent ajouter de la latence et créer des goulets d’étranglement de bande passante dans les environnements Provisioning Services. Si l’utilisation de pare-feu ne peut pas être évitée, reportez-vous au livre blanc CitrixCTX101810— Ports de communication utilisés par Citrix Technologies, pour obtenir la liste des ports qui doivent être activés pour des fonctionnalités complètes.

Croissance

Au fur et à mesure de la croissance de la batterie, les administrateurs devront décider d’ajouter plus de ressources aux serveurs de provisionnement ou d’ajouter davantage de serveurs de provisionnement à la batterie.

Un certain nombre de facteurs environnementaux doivent être pris en compte pour déterminer si les serveurs Provisioning Server doivent être mis à l’échelle ou dimensionnés :

  • Redondance : la répartition de la charge utilisateur sur d’autres serveurs moins puissants permet de réduire le nombre d’utilisateurs affectés par une seule défaillance du serveur de provisionnement. Si l’entreprise n’est pas en mesure d’accepter la perte d’un seul serveur haute spécification, envisagez de procéder à une mise à l’échelle.
  • D@@élais de basculement : plus les équipements cibles sont connectés à un serveur de provisionnement unique, plus il leur faudra de temps pour basculer en cas de défaillance du serveur. Envisagez la mise à l’échelle pour réduire le temps nécessaire au basculement des machines cibles vers un autre serveur.
  • Capacité du datacenter : le datacenter peut avoir un espace, une alimentation et/ou un refroidissement limités. Dans cette situation, envisagez d’augmenter l’échelle.
  • Coûts matériels — Au départ, il peut être plus rentable de faire évoluer l’échelle. Cependant, il y aura un point où la mise à l’échelle deviendra en fait plus rentable. Une analyse des coûts devrait être effectuée pour en arriver à cette conclusion.
  • Frais d’hébergement — Il peut y avoir des coûts d’hébergement et/ou de maintenance en fonction du nombre de serveurs physiques utilisés. Si c’est le cas, envisagez d’augmenter l’échelle pour réduire le coût à long terme de ces frais généraux.

Décision : Configuration réseau

Comme mentionné précédemment, il est essentiel que le réseau soit dimensionné correctement pour éviter les goulots d’étranglement réseau causant des temps d’accès élevés au disque et affectant directement les performances du bureau virtuel. Le diagramme suivant présente une infrastructure réseau Provisioning Services commune :

Exemple d'image de configuration réseau pvs

La configuration réseau suivante est recommandée pour les sections réseau décrites dans le diagramme :

  • Lienmontante PVS : tous les accès disque depuis les équipements cibles sont transférés via la liaison montante du réseau PVS. Cela signifie que des centaines, voire des milliers d’appareils utiliseront cette connexion réseau. Par conséquent, il est essentiel que cette connexion soit redondante et puisse basculer sans interruption. En outre, Citrix recommande une bande passante minimale de 1 Gbit/s par 500 équipements cibles. Pour les serveurs de provisionnement virtuel, un quota QoS respectif ou une liaison montante réseau physique dédiée doit être configuré pour garantir les meilleures performances.
  • Lienmontante hyperviseur — Utilisée par toutes les machines cibles PVS hébergées sur un hôte hyperviseur particulier. Par conséquent, la redondance avec basculement transparent est fortement recommandée. À moins que les machines cibles exécutent une charge de travail très importante en E/S ou exécutent des tâches intensives en E/S (par exemple, démarrage) simultanément, une bande passante de 1 Gbit/s est suffisante pour cette liaison montante.
  • Liaison montante de la machine virtuelle : tout le trafic réseau d’une machine virtuelle, y compris le trafic de streaming PVS, traverse cette connexion réseau virtuel. À moins que la charge de travail ne soit extrêmement exigeante en E/S, une bande passante de 100 Mbps est suffisante pour gérer même les charges de pointe lors de tâches intensives en E/S, telles que le démarrage à partir de vDisk. Par exemple, un serveur Windows 2012 R2 lit environ 232 Mo pendant une période de 90 secondes à partir du vDisk jusqu’à ce que l’écran d’ouverture de session Windows s’affiche. Pendant cette période, un débit moyen de données de 20,5 Mbps avec des pics allant jusqu’à 90 Mbps peut être observé.

Les paramètres de commutateur suivants sont recommandés pour Provisioning Services :

  • Désactiver Spanning Tree ou Activer PortFast : dans un environnement de commutation, le protocole STP (Spanning Tree Protocol) place les ports dans un état bloqué pendant qu’il transmet les unités de données du protocole Bridged (BPDU) et écoute pour s’assurer que les BPDU ne sont pas dans une configuration de bouclage. Le port n’est pas placé dans un état de transfert tant que le réseau ne converge pas, ce qui, selon la taille du réseau, peut prendre suffisamment de temps pour provoquer des expirations de délai PXE (Preboot Execution Environment). Pour éliminer ce problème, désactivez STP sur les ports de bord connectés aux clients ou activez PortFast.
  • Storm Control - Storm Control est une fonctionnalité disponible sur les commutateurs Cisco qui permet de définir un seuil permettant de supprimer le trafic de multidiffusion, de diffusion ou de monodiffusion. Son but est d’empêcher les expéditeurs malveillants ou erronés d’inonder un réseau local et d’affecter les performances du réseau. Les serveurs PVS peuvent envoyer une grande quantité de trafic par conception qui se situe dans un seuil de contrôle des tempêtes, par conséquent, la fonctionnalité doit être configurée en conséquence.
  • Assistant de diffusion — L’assistant de diffusion est nécessaire pour diriger les diffusions des clients vers des serveurs qui, autrement, ne seraient pas routés. Dans un environnement PVS, il est nécessaire de transférer les demandes de démarrage PXE lorsque les clients ne sont pas sur le même sous-réseau que les serveurs. Si possible, la conception réseau recommandée consiste à disposer de serveurs PVS résidant sur le même sous-réseau que les équipements cibles. Cela atténue le risque de dégradation des services due à d’autres composants d’infrastructure réseau.

Les fonctionnalités d’interface réseau suivantes doivent être prises en considération lors de la sélection d’une interface réseau pour Provisioning Services :

  • Déchargement TCP : le déchargement des tâches d’E/S vers l’interface réseau réduit l’utilisation du processeur et améliore les performances globales du système. Toutefois, les services de streaming PVS peuvent être affectés négativement lorsque le déchargement d’envoi volumineux est activé en raison du travail supplémentaire effectué sur la carte réseau. De nombreuses cartes réseau auront le déchargement de grande taille d’envoi et le déchargement de la somme de contrôle TCP activés par défaut.

Note :

Si Large Send Offload est activé et que le commutateur traversé par le trafic ne prend pas en charge la taille de trame envoyée par le moteur Large Send Offload, le commutateur supprimera le trame provoquant la retransmission des données. Lors de la retransmission, le système d’exploitation segmente les trames au lieu de la carte réseau, ce qui peut entraîner une grave dégradation des performances.

  • Receiver Side Scaling (RSS) : la mise à l’échelle latérale de la réception permet d’équilibrer les paquets reçus d’une carte réseau sur plusieurs processeurs, ce qui permet aux connexions TCP entrantes d’être équilibrées en charge, empêchant ainsi les goulots d’étranglement vers une seule unité centrale. Dans Windows Server 2008 R2 et Windows Server 2012/2012 R2, RSS est activé par défaut.

Note :

Pour plus d’informations sur les meilleures pratiques de mise en réseau PVS, veuillez consulter la sectionMeilleures pratiques pour la configuration du serveur Provisioning Services sur un réseau.

Pour les implémentations Provisioning Services sur des réseaux à faible bande passante (1 Gbit/s ou plus lent), les performances peuvent être améliorées en isolant le trafic en continu d’autres trafic réseau sur le réseau local.

Microsoft ne prend pas en charge l’association de cartes réseau avec Hyper-V sur Windows Server 2008 R2 ; toutefois, des solutions tierces sont disponibles. Microsoft prend en charge l’association de cartes réseau avec Hyper-V sur Windows Server 2012/2012 R2. Toutes les demandes de support concernant l’association avec Hyper-V doivent être adressées au fabricant OEM de la carte réseau.

Décision : Affinité de sous-réseau

L’affinité de sous-réseau Provisioning Services est un algorithme d’équilibrage de charge qui permet de garantir que les équipements cibles sont connectés au serveur de provisionnement le plus approprié. Lors de la configuration de l’affinité de sous-réseau, les options suivantes sont disponibles :

  • Aucun — Ignorer les sous-réseaux ; utilise le serveur le moins occupé.
  • Meilleur effort : utilise la combinaison serveur/carte réseau la moins occupée depuis le même sous-réseau. Si aucune combinaison Serveur/carte réseau n’est disponible dans le sous-réseau, sélectionnez le serveur le moins occupé à partir de l’extérieur du sous-réseau. Si plusieurs serveurs sont disponibles dans le sous-réseau sélectionné, effectuez l’équilibrage de charge entre ces serveurs. Il s’agit du paramètre par défaut.
  • Corrigé— Utilisait la combinaison serveur/carte réseau la moins occupée depuis le même sous-réseau. Effectuez l’équilibrage de charge entre les serveurs de ce sous-réseau. Si aucune combinaison Serveur/carte réseau n’existe dans le même sous-réseau, ne démarrez pas les machines cibles affectées à ce vDisk.

Les exemples suivants illustrent les configurations réseau courantes pour les serveurs de provisionnement physique. Des configurations similaires peuvent être implémentées pour les serveurs de provisionnement virtuel sans compromettre les performances ou les fonctionnalités.

Conception de la lame

Les serveurs de provisioning et les équipements cibles qu’ils prennent en charge résident dans le même châssis. Dans la plupart des cas, le châssis dispose d’un commutateur 10 Gbit/s dédié partagé entre tous les serveurs lames du châssis.

Image de conception du boîtier lame

L’option d’affinité de sous-réseau « Meilleur effort » est utilisée pour conserver le trafic Provisioning Services dans le même châssis. Si le serveur de provisioning devient indisponible, les cibles basculent vers le deuxième serveur de provisioning dans le second châssis, mais le même site Provisioning Services.

Conception de rack

Le deuxième exemple est basé sur une conception de rack qui utilise des commutateurs de rack pour garder le trafic de provisionnement dans le rack.

Image de conception de rack PVS

Contrairement à la conception du châssis lame, la fonction d’affinité de sous-réseau n’est pas utilisée. Au lieu de cela, un site Provisioning Services avec deux serveurs de provisioning sera configuré par rack de serveur. Cela garantira que les machines cibles sont diffusées en continu à partir des serveurs de provisionnement dans le même rack.

Expérience sur le terrain

Fabrication — Une entreprise de fabrication conçoit une solution Provisioning Services pour prendre en charge cinq mille postes de travail virtuels. La compagnie craint que Provisioning Services ne crée un goulot d’étranglement sur le réseau affectant d’autres applications. La société a choisi de construire l’environnement sur des serveurs lames de sorte que le trafic de provisionnement soit contenu dans le boîtier lame et n’ait pas d’impact sur le trafic sur le réseau.

Décision : Read Cache

PVS Accelerator permet à un proxy PVS de résider dans le domaine de contrôle de XenServer sur un hôte où le streaming d’un vDisk Provisioning Services est mis en cache sur le proxy avant d’être transféré à la machine virtuelle. En utilisant le cache, le démarrage ultérieur (ou toute demande d’E/S) de la machine virtuelle sur le même hôte peut être diffusé en continu à partir du proxy plutôt que de diffuser en continu à partir du serveur sur le réseau. PVS Accelerator nécessite davantage de ressources locales sur l’hôte XenServer, mais la diffusion en continu à partir du serveur via le réseau permet d’économiser des ressources, améliorant ainsi efficacement les performances.

Image du cache de lecture PVS

PVS Accelerator est une fonctionnalité XenServer uniquement. L’utilisation de cette technologie intégrée réduit la charge sur le serveur PVS, réduit l’utilisation globale du réseau et réduit le temps nécessaire au démarrage d’une machine virtuelle.

Image de l'accélérateur PVS

Pour plus d’informations sur la relation entre XenServer et Provisioning Services, consultez le blogXenServer et PVS : mieux ensemble.

Décision : Cache d’écriture

Étant donné que l’image principale est en lecture seule, chaque machine virtuelle dispose d’un disque accessible en écriture pour stocker toutes les modifications. L’administrateur doit décider où stocker le disque cache d’écriture.

Serveur PVS — Stockage local

Le stockage local Provisioning Services contient les lecteurs de cache d’écriture pour chaque machine virtuelle cible. Bien qu’il s’agisse du paramètre par défaut, il augmente les besoins en bande passante réseau et augmente l’utilisation du serveur Provisioning Services.

Image de stockage local côté serveur

Serveur PVS — Stockage partagé

Le stockage partagé associé au serveur Provisioning Services contient les lecteurs de cache d’écriture pour chaque machine virtuelle cible. Cette option augmente les besoins en bande passante réseau et augmente l’utilisation du serveur Provisioning Services. Il place également des données temporaires (cache d’écriture) sur un stockage partagé coûteux.

Image de stockage partagé côté serveur

VM — Stockage local

Le stockage local associé à la machine virtuelle contient les lecteurs de cache d’écriture pour chaque machine virtuelle cible. Cette option utilise un stockage local à faible coût et ne consomme pas de ressources supplémentaires sur le serveur Provisioning Services. Toutefois, le stockage local doit être capable de prendre en charge les E/S par seconde de toutes les machines virtuelles de l’hôte.

Image de stockage local de la machine virtuelle

VM — Cache en RAM

La RAM associée à la machine virtuelle contient les lecteurs de cache d’écriture pour chaque machine virtuelle cible. Cette option fournit des performances élevées en raison de la vitesse de la RAM. Toutefois, si le cache RAM manque d’espace, la machine virtuelle deviendra inutilisable. Pour utiliser cette option, des quantités importantes de RAM doivent être allouées à chaque machine virtuelle, ce qui augmente le coût global.

Cache de machine virtuelle dans l'image RAM

VM — Cache dans la RAM avec débordement vers le disque

Une combinaison de RAM et de stockage local est utilisée pour le cache d’écriture. Tout d’abord, les écritures sont stockées dans le cache RAM, offrant des performances élevées. Lorsque le cache RAM est consommé, de grands blocs sont supprimés du cache RAM et placés sur le disque du cache d’écriture de stockage local. Cette option offre des niveaux de performances élevés avec un faible coût de stockage local.

L’utilisation de cette technologie intégrée réduit les E/S par seconde d’écriture de 95 %.

Cache de machine virtuelle dans l'image RAM

Le cache dans la RAM avec le débordement vers le disque est l’option recommandée.

Cache de machine virtuelle dans l'image RAM

Décision : Antivirus

Par défaut, la plupart des produits antivirus analysent tous les fichiers et processus, ce qui a un impact significatif sur les performances de Provisioning Services. Pour plus d’informations sur la façon dont les logiciels antivirus peuvent être optimisés pour Provisioning Services, reportez-vous àCTX124185la section « Meilleures pratiques antivirus Provisioning Services ».

Les logiciels antivirus peuvent causer des problèmes de verrouillage de fichiers sur les serveurs de provisionnement. Le vDisk Store et le cache d’écriture doivent être exclus des analyses antivirus afin d’éviter les problèmes de conflit de fichiers.

Lorsqu’un disque virtuel s’exécute en mode standard et doit être redémarré, il télécharge toutes les définitions de virus précédemment chargées. Cela peut entraîner une dégradation des performances lors du redémarrage de plusieurs équipements cibles à la fois, provoquant souvent une congestion du réseau pendant que l’opération persiste. Dans les cas extrêmes, la machine cible et le serveur de provisioning peuvent devenir lents et consommer plus de ressources que nécessaire. Si le logiciel antivirus le prend en charge, les fichiers de définition doivent être redirigés vers le lecteur de cache d’écriture afin qu’ils soient conservés entre les redémarrages.

Services de création de machines

Machine Creation Services (MCS) utilise la technologie de clonage de disques pour simplifier le déploiement des machines virtuelles. Les ordinateurs sont provisionnés et reprovisionnés en temps réel à partir d’une seule image de disque partagé. Ce faisant, les administrateurs peuvent éliminer la nécessité de gérer et de corriger des systèmes individuels. Au lieu de cela, les administrateurs effectuent toute la gestion des images sur l’image principale.

Décision : Emplacement de stockage

Machine Creation Services permet aux administrateurs de diviser un poste de travail virtuel en plusieurs composants et de stocker ces éléments sur différentes baies de stockage.

Stockage partagé

La première option utilise le stockage partagé pour le disque du système d’exploitation et le disque de différenciation.

Image de stockage partagé MCS

Bien que cette option autorise le partage de l’image principale entre plusieurs hôtes d’hyperviseur, elle impose plus de contraintes à la baie de stockage car elle doit également héberger le disque de différenciation, qui est des données temporaires.

Stockage hybride

La deuxième option utilise le stockage partagé pour le disque du système d’exploitation et le stockage de l’hyperviseur local pour le disque de différenciation.

Image de stockage hybride MCS

Il s’agit de l’option la plus courante qui donne à l’administrateur les avantages du partage de l’image principale sur plusieurs hôtes d’hyperviseur tout en déchargeant des E/S par seconde d’écriture temporaires et coûteuses vers un stockage local de l’hyperviseur.

Stockage IntelliCache XenServer

La troisième option utilise le stockage partagé pour le disque du système d’exploitation et le stockage de l’hyperviseur local pour le disque de différence et le stockage XenServer local pour un cache local du disque du système d’exploitation.

Il s’agit uniquement d’une option pour les implémentations de XenServer. Il offre la même valeur que l’approche de stockage hybride tout en réduisant les E/S par seconde en lecture du stockage partagé. IntelliCache peut coexister avec le cache de lecture basé sur RM de XenServer, si la RAM XenServer est limitée.

Image IntelliCache MCS

Décision : Type de clonage

Machine Creation Services intègre deux types de techniques de clonage.

  • Thin : chaque machine virtuelle du catalogue utilise un seul disque virtuel en lecture seule pour toutes les lectures. Un deuxième disque virtuel, unique pour chaque machine virtuelle, capture toutes les activités d’E/S en écriture.
  • Complet : chaque machine virtuelle du catalogue reçoit une copie complète de l’image du disque maître. Chaque machine virtuelle est entièrement propriétaire du disque, ce qui permet une activité de lecture/écriture. La technologie de clonage complet n’est disponible que pour les postes de travail virtuels personnels, où une machine virtuelle dédiée enregistre toutes les modifications apportées à un disque local.

Les administrateurs doivent tenir compte des éléments suivants lorsqu’ils décident entre les technologies de clonage fin et complet :

  Clone fin Clone complet
Espace de stockage requis A des économies d’espace de stockage maximales. Une image de disque maître unique est partagée sur plusieurs machines virtuelles. Seul le disque de différenciation (écritures) consomme de l’espace, qui continue de croître jusqu’au redémarrage de la machine virtuelle Besoins en espace de stockage élevé. Chaque machine virtuelle reçoit une copie complète de l’image principale. La taille continue de croître au fur et à mesure que des modifications sont apportées à la machine virtuelle.
Sauvegarde/restauration Difficile. De nombreuses solutions tierces de sauvegarde/reprise après sinistre ne prennent pas en charge les disques instantanés ou delta, ce qui rend les machines virtuelles à provisionnement fin difficile/impossible à sauvegarder ou à déplacer vers d’autres baies de stockage. Doucement. La machine virtuelle existe dans un seul disque virtuel, ce qui facilite la sauvegarde et la restauration.
Vitesse de provisionnement Vite. Nécessite uniquement une seule image disque Lent (peut être atténué). Chaque machine virtuelle nécessite une copie complète de l’image principale. Les technologies d’optimisation du stockage peuvent aider à atténuer les effets.
Performance Plus lentement. Une E/S de lecture peut se produire deux fois, une pour le disque maître et une pour le disque de différenciation, ce qui augmente les E/S par seconde en lecture. Plus vite. Tous les lecture/écriture directement sur un seul disque.
Boot Storm Impact élevé. Dans une tempête de démarrage, tous les disques de différence redimensionnent pour contenir toutes les écritures du démarrage de Windows ; en plaçant une charge élevée sur le stockage comme cela se produit à la fois. Faible impact

Décision : Read Cache

Pendant le démarrage et l’ouverture de session, les postes de travail virtuels subissent des niveaux élevés d’E/S par seconde en lecture, ce qui peut peser sur le sous-système de stockage sous-jacent. Lorsqu’ils sont déployés sur Citrix XenServer, les modes VDI partagés et groupés utilisent un cache de lecture basé sur RAM hébergé sur chaque XenServer.

Image du cache de lecture MCS

L’utilisation de cette technologie intégrée réduit les E/S par seconde de 50 à 80 %.

Image de grille de cache de lecture MCS

Décision : Cache d’écriture

En état d’équilibre, les postes de travail virtuels subissent des niveaux élevés d’E/S par seconde en écriture de stockage, ce qui peut peser sur le sous-système de stockage sous-jacent. Les modes VDI partagés et groupés peuvent utiliser un cache d’écriture basé sur RAM en utilisant la RAM de pool non paginée à partir du système d’exploitation des machines virtuelles.

Image du cache d'écriture MCS

L’utilisation de cette technologie intégrée réduit les E/S par seconde d’écriture de 95 %.

Image de grille de cache d'écriture MCS

Sécurité

Selon les exigences de l’organisation, différentes normes de sécurité doivent être mises en œuvre au sein de la solution. Il est conseillé de se référer aux documents suivants :

Clause de non responsabilité

The official version of this content is in English. Some of the Citrix documentation content is machine translated for your convenience only. Citrix has no control over machine-translated content, which may contain errors, inaccuracies or unsuitable language. No warranty of any kind, either expressed or implied, is made as to the accuracy, reliability, suitability, or correctness of any translations made from the English original into any other language, or that your Citrix product or service conforms to any machine translated content, and any warranty provided under the applicable end user license agreement or terms of service, or any other agreement with Citrix, that the product or service conforms with any documentation shall not apply to the extent that such documentation has been machine translated. Citrix will not be held responsible for any damage or issues that may arise from using machine-translated content.

Couche de contrôle de la méthodologie de conception