Méthodologie de conception d’une couche de contrôle

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

Active Directory

Décision : Conception avec forêts

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 différentes forêts, ce qui permet aux utilisateurs et aux ordinateurs d’une forêt d’authentifier les ressources d’une autre forêt et d’y accéder.

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, il est nécessaire de configurer plusieurs sites XenDesktop pour chaque forêt. Cette section décrit les exigences de stockage par produit et fournit des calculs de dimensionnement. Pour plus d’informations, consultez l’article Citrix : CTX134971 – Successfully Deploying XenDesktop in a Complex Active Directory Environment

Décision : Structure des unités d’organisation

Les composants de l’infrastructure d’un déploiement XenApp et XenDesktop doivent résider dans leurs propres unités d’organisation dédiées, ce qui permet de séparer les tâches et les contrôleurs à des fins de gestion. Ainsi, la gestion des objets à l’intérieur des unités sera plus flexible et les administrateurs Citrix pourront bénéficier d’un contrôle délégué.

Un exemple de structure d’unités d’organisation Citrix est présenté ci-dessous.

Image d'unité d'organisation Citrix

Décision : Groupes d’utilisateurs

Dans la mesure du possible, les 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 pour un groupe de 1 000 utilisateurs ne nécessite la validation que d’un seul objet pour les 1 000 utilisateurs.
  • La même application publiée pour 1 000 comptes utilisateur individuels nécessite la validation des 1 000 objets.

Base de données

La majorité des produits Citrix mentionnés dans ce document nécessitent une base de données. Le tableau suivant présente leur utilisation par produit :

Dans ce tableau :

  • Y indique Disponible.
  • O indique Facultatif.
Produit Données de configuration Données d’exécution Données de journal de changements/audit Données de surveillance
XenDesktop O O O O
Provisioning Services O   O  
DesktopPlayer O O O O

Décision : Édition

Il existe plusieurs éditions de Microsoft SQL Server 2012 : Express, Web, Standard, Business Intelligence et Enterprise. Au vu des capacité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 fournit un nombre suffisant 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 avec les produits Citrix, reportez-vous à la Matrice de prise en charge des bases de données Citrix. Différentes versions des produits Citrix prennent en charge différentes versions de SQL Server. Par conséquent, il est important de vérifier la matrice de prise en charge pour vous assurer que la version de SQL Server utilisée est compatible avec le produit Citrix en cours de déploiement.

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 ne peut être fournie. Vous trouverez les recommandations de dimensionnement du serveur SQL par produit ci-dessous.

XenApp et XenDesktop

Les brokers de XenApp et XenDesktop utilisent la base de données comme un bus de messages pour les communications de broker, 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 internes de capacité à monter en charge de Citrix, la spécification SQL Server suivante est recommandée pour un serveur hébergeant toutes les bases de données XenDesktop :

  • 2 cœurs et 4 Go de RAM pour les environnements jusqu’à 5 000 utilisateurs
  • 4 cœurs et 8 Go de RAM pour les environnements jusqu’à 15 000 utilisateurs
  • 8 cœurs et 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 grand nombre de transactions. Par exemple, l’enregistrement de 20 000 bureaux virtuels au cours d’une tempête de démarrage de 15 minutes provoque environ 500 transactions par seconde et 20 000 utilisateurs se connectant au cours d’une tempête de connexion de 30 minutes entraîne environ 800 transactions par seconde sur la base de données de site XenDesktop.

Provisioning Services

Outre les données de configuration statiques, les serveurs de provisioning 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 SQL Server de 4 cœurs et 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 sa configuration optimale.

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, il 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 du journal n’est requise. L’espace du journal est automatiquement récupéré, afin de limiter les besoins en espace, éliminant essentiellement la nécessité de gérer l’espace du 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 sinistre, il est nécessaire de réeffectuer ces modifications.
    • Récupération complète : requiert la sauvegarde des journaux. Aucun travail n’est perdu si un fichier de données de base de données est perdu ou endommagé. Les données sauvegardées à tout point dans le temps peuvent être récupérées (par exemple, avant l’erreur de l’application ou de l’utilisateur). Une récupération complète est requise pour la mise en miroir de bases de données.
    • Journalisation en masse : requiert la sauvegarde des 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 avec des performances élevées. 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 de stockage par produit et fournit des calculs de dimensionnement. Pour plus d’informations, reportez-vous à l’article Citrix : CTX139508 – Dimensionnement des bases de données XenDesktop 7.x.

XenDesktop - Général

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

  • Base de données de configuration de site : contient des données de configuration statiques et d’exécution dynamiques
  • 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 sur le 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 d’utilisation. Les facteurs suivants ont tous un impact sur la taille du fichier de base de données :

  • Le nombre de sessions connectées
  • Le nombre de VDA configurés et enregistrés
  • Le nombre de transactions se produisant lors de l’ouverture de session
  • Transactions de pulsations de VDA

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

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

Remarque

Ces informations sur le dimensionnement ne sont qu’un guide. La taille réelle des bases de données peut varier légèrement par déploiement en raison de la façon dont les bases de données sont maintenues.

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 :

  • Modèle de récupération de base de données SQL
  • Taux de lancement aux heures de pointe
  • Nombre de bureaux mis à disposition

Lors des tests de capacité à monter en charge de XenDesktop, Citrix a observé un taux de croissance du journal des transactions de 3,5 Mo par heure lorsque le système est inactif, et un taux de croissance par utilisateur et par jour d’environ 32 Ko. Dans un environnement de grande taille, l’utilisation des journaux de transactions nécessite une gestion attentive et une sauvegarde régulière, afin d’éviter une croissance excessive. Pour cela, la planification de tâches ou des plans de maintenance peuvent être utiles.

Base de données de contrôle

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

  • Nombre d’utilisateurs
  • Nombre de sessions et de connexions
  • Nombre de tâches
  • Configuration de la période de rétention : 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 un maximum de 7 jours (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 Monitoring Service.
  • Traitement de nuit supprimant les données hors de la période de conservation configurée.

Le tableau suivant montre la taille estimée de la base de données de contrôle sur une période donnée dans différents scénarios. Ces informations sont une estimation basée sur les données observées dans le test de capacité à monter en charge de XenApp et XenDesktop (supposant une semaine de travail de 5 jours).

Utilisateurs Type 1 semaine (Mo) 1 mois (Mo) 3 mois (Mo) 1 an (Mo)
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 sur une semaine de travail de 5 jours

Utilisateurs Type 1 semaine (Mo) 1 mois (Mo) 3 mois (Mo) 1 an (Mo)
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

Remarque

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

  • 2 Delivery Controller
  • 43 tâches de bureau partagé hébergé
  • 3 serveurs SQL, configurés avec des bases de données conservées dans un groupe de disponibilité Always On.

Pour de plus amples informations, consultez l’article de l’assistance Citrix - Dimensionnement de la base de données XenDesktop 7.x.

La taille du journal des transactions pour la base de données de contrôle est très difficile à estimer, mais les tests de capacité à monter en charge de 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 et par jour d’environ 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 des transactions associé dépendent des activités administratives quotidiennes initiées à partir de scripts Studio, Director ou PowerShell. Par conséquent, sa taille est difficile à estimer. Plus de modifications de configuration sont effectuées, plus la base de données s’élargit. 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 autant 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 un administrateur les supprime manuellement.
  • Activités qui ont un impact sur les sessions ou les utilisateurs, par exemple, fermeture de session et réinitialisation.
  • Mécanisme utilisé pour déployer les bureaux.

Dans les environnements XenApp qui n’utilisent pas MCS, la taille de la base de données a tendance à 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 création de machines virtuelles.

Base de données temporaire

En plus des bases de données de site, de contrôle et de journalisation de la configuration, 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 les données d’isolation de capture instantanée en lecture validée. XenApp 7.x et XenDesktop 7.x utilisent 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 capture instantanée en lecture validée. Pour plus d’informations, veuillez consulter l’article Comment faire pour activer la capture instantanée en lecture validée 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 Mo. Les performances de la base de données tempdb n’affectent pas les performances de broker de 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 aide à limiter la taille de tempdb.

tempdb est également utilisé lorsque des requêtes génèrent de grands ensembles de résultats intermédiaires. Vous trouverez des conseils et des informations sur la taille de tempdb dans l’article Microsoft TechNet Optimisation des performances de tempdb.

Provisioning Services

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

Élément de configuration Espace de base de données 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
Collection de périphériques 10 50 500
Vue de la batterie 4 10 40
Relation vue de la batterie-appareil 5 1 5 000
Vue du site 4 5 20
Relation vue du site-appareil 5 1 5 000
Appareil 2. 5 000 10 000
Bootstrap de l’appareil 10 - -
Relation appareil-disque 35 1 175 000
Relation appareil-imprimante 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 de l’appareil 2. - -
vDisk 1 20 20
Version de 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 vDisk 8 5 40
Relation magasin vDisk-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 732 Ko (~212 Mo)

Lors de la configuration de la batterie de serveurs PVS, une base de données dont la taille initiale de fichier est de 20 Mo est créée. En raison de la nature des données de la base de données de batterie de serveurs PVS, le journal des transactions ne devrait pas croître très rapidement, à moins d’une configuration intensive.

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 des bases de données

XenApp et XenDesktop utilise trois bases de données différentes : configuration du site, contrôle et 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 contrôle 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 changements 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.

Remarque

Vous ne pouvez pas modifier l’emplacement de la base de données de journalisation de la configuration 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 d’une 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 bureau virtuel. Remarque : le cache d’hôte local permet aux utilisateurs disposant de bureaux partagés hébergés, d’applications Windows et navigateur hébergées 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 contrôle Director n’affichera aucune donnée historique et Studio ne pourra pas être démarré. La négociation des demandes d’utilisateurs entrantes et des sessions utilisateur existantes ne sera pas affectée.
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é 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 (mais les modifications de configuration ne sont pas enregistrées). Sinon, les administrateurs ne pourront pas apporter de modifications à la configuration du site XenApp et XenDesktop. Les utilisateurs ne sont pas affectés.
Batterie de base de données 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 streaming utilise une copie locale de la base de données pour récupérer les informations relatives au serveur de provisioning et aux machines cibles prises en charge par le serveur. Ce processus permet aux serveurs de provisioning et aux machines cibles de rester opérationnels. Toutefois, lorsque la base de données est hors connexion, 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 ; modification du mot de passe Active Directory ; démarrage du processus de streaming ; service de mise à jour des images ; 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 machines cibles échouent.

Remarque

Veuillez vérifier les options de haute disponibilité pour les bases de données tierces (par exemple, App-V, SCVMM ou vCenter) auprès du 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é. Elles permettent aux administrateurs de s’assurer que les pannes d’un seul serveur auront un impact minimal (le cas échéant) sur l’infrastructure de XenApp et XenDesktop. Fonctionnalités de haute disponibilité SQL/hyperviseur disponibles :

  • Haute disponibilité au niveau des VM : cette option est disponible uniquement pour les serveurs SQL virtuels, qui doivent être marqués pour 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 tente de redémarrer immédiatement la machine virtuelle sur un autre hôte. Bien que la haute disponibilité au niveau des VM puisse minimiser les temps d’arrêt dans les scénarios de panne de courant, elle ne peut pas 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 fonction d’hyperviseur intégrée. Toutefois, le processus de basculement automatique est plus lent, car il peut mettre du temps à détecter une panne et à démarrer le serveur SQL virtuel sur un autre hôte. Cela peut interrompre le service pour les utilisateurs.
  • Mise en miroir : la mise en miroir des bases de données augmente la disponibilité des bases de données avec un basculement presque instantané. La mise en miroir de base de données peut être utilisée pour maintenir une base de données de secours ou de 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 avec une opération synchrone en mode haute sécurité ou une opération asynchrone en mode haute performance. 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. Le basculement de la base de données principale vers la base de données miroir se produit automatiquement et est généralement effectué en quelques secondes. Il est recommandé d’activer la haute disponibilité au niveau des VM (ou une fonctionnalité de redémarrage automatique similaire) pour au moins le témoin afin d’assurer la disponibilité du service SQL en cas de panne de plusieurs serveurs.

Remarque

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

  • Instances de cluster de basculement AlwaysOn : le clustering de basculement fournit une prise en charge haute disponibilité pour l’intégralité d’une instance de Microsoft SQL Server. Un cluster de basculement est une combinaison de deux nœuds ou serveurs, ou plus, utilisant un stockage partagé. Une instance de cluster de basculement AlwaysOn Microsoft SQL Server, introduite dans SQL Server 2012, apparaît sur le réseau en tant qu’ordinateur unique, mais propose des fonctionnalités qui effectuent le basculement d’un nœud à un autre si le nœud actuel devient indisponible. La transition d’un nœud à l’autre nœud 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épendra de l’édition de SQL Server. (Veuillez vous reporter au tableau Décision : Édition de la section précédente de ce chapitre.) Pour plus d’informations, reportez-vous à MSDN : Instances de cluster de basculement AlwaysOn (SQL Server).
  • Groupes de disponibilité AlwaysOn : solution de haute disponibilité et reprise après sinistre introduites dans Microsoft SQL Server 2012 pour permettre aux administrateurs d’optimiser la disponibilité pour une ou plusieurs bases de données utilisateur. Les Groupes de disponibilité AlwaysOn nécessitent que les instances Microsoft SQL Server résident dans des nœuds WSFC (Windows Server Failover Clustering). Comme avec le clustering de basculement, un seul nom IP virtuel/réseau est exposé aux utilisateurs de la base de données. Contrairement au clustering de basculement, le stockage partagé n’est pas requis car les données sont transférées à l’aide d’une connexion réseau. Les réplications synchrone et asynchrone vers un ou plusieurs serveurs secondaires sont toutes les deux prises en charge. Contrairement à la mise en miroir ou au clustering, les serveurs secondaires peuvent être utilisés activement 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, essentiellement, de monter en charge une infrastructure de serveur SQL. É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 une option recommandée.
  • o indique une option viable.
  • N indique une option non prise en charge.
  • T indique une option réservée aux environnements de test.
Composant Haute disponibilité au niveau des VM Mise en miroir Instances de cluster de basculement AlwaysOn Groupes de disponibilité AlwaysOn
Base de données du site T O o o
Base de données de journalisation de la configuration T o o o
Base de données de contrôle T O o o
Batterie de base de données Provisioning Services T O o o
Base de données DesktopPlayer T N o o

Système de licences Citrix

Citrix propose aux entreprises plusieurs modèles de licences qui s’alignent sur les scénarios d’utilisation courants. Les différents modèles de licences varient en fonction du produit Citrix utilisé, mais peuvent inclure les options « par utilisateur/appareil » et « par utilisateur simultané ». Plusieurs produits Citrix utilisent le serveur de licences, tandis que d’autres produits nécessitent qu’une licence soit installée 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 - Système de licences XenDesktop.

Pour plus d’informations sur les licences Microsoft, reportez-vous au document Microsoft : Licensing Microsoft’s Virtual Desktop Infrastructure Technology.

Décision : Dimensionnement

Les tests de montée en charge internes ont montré que le matériel et la configuration de machine virtuelle peut émettre 70 000 licences simultanées : Intel Xeon E5-2650 v3 @ 2,30 GHz 4 processeurs virtuels 8 Go de RAM Windows Server 2016.

Pour de plus amples informations, consultez la section Capacité à monter en charge.

Décision : Haute disponibilité

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

Remarque

  • Si le serveur de licences et le produit Citrix ne communiquent pas dans un délai de 2 pulsations (5 à 10 min), le produit Citrix entre une période de grâce et autorise les connexions jusqu’à 30 jours. Une fois la communication rétablie avec le serveur de licences, celui-ci 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 mettre à jour les 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 clusters sont des groupes d’ordinateurs qui fonctionnent ensemble afin d’augmenter la disponibilité. Le clustering permet au rôle de serveur de licences de basculer automatiquement en cas d’échec. 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 de niveau VM du serveur de licences. Cette sauvegarde ne doit pas être stockée sur le même hôte que le serveur de licences. Elle doit être stockée dans un endroit sûr, tel qu’une solution de stockage hautement disponible, ou sauvegardée sur bande ou sur disque. Le serveur dupliqué n’est pas actif et restera en veille jusqu’à ce qu’il soit nécessaire de restaurer le serveur de licences actif. Si le serveur de licences est restauré à l’aide de cette sauvegarde, toutes les nouvelles licences doivent être de nouveau téléchargées sur le serveur.

Pour plus d’informations, reportez-vous à Citrix eDocs : Présentation de l’architecture de 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 ait lieu pendant la période de grâce et que les limitations suivantes soient prises en compte.

  • Les fichiers de licence référenceront le serveur spécifié pendant le processus d’attribution. 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 spécifié précédemment.
  • Deux serveurs de licences Windows joints à un domaine ne peuvent pas partager le même nom et être actifs dans l’environnement en même temps.
  • Étant donné que 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 sur le serveur de sauvegarde.

Décision : Optimisation

Les performances du serveur de licences peuvent être optimisées en réglant le nombre de threads « réception » et « traitement ». Si le nombre de threads est trop bas, les requêtes seront mises 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 demandes 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 sur 30 et le nombre maximal de threads de réception sur 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 licences.

Pour plus d’informations, reportez-vous au document Citrix Docs : Amélioration des performances en spécifiant l’utilisation de threads.

Delivery Controller

Décision : Dimensionnement du serveur

La capacité à monter en charge d’un Delivery Controller est basée sur l’utilisation du processeur. Plus il y a de cœurs de processeur disponibles, plus le nombre de bureaux virtuels pouvant être pris en charge par un Controller est élevé. Chaque demande de démarrage, d’enregistrement, d’énumération et de lancement de bureau a un impact sur le processeur du Controller. À mesure que la tempête augmente en intensité, l’utilisation du processeur du Controller augmente. Si le CPU atteint un seuil critique (environ 80 %), le site devra soit augmenter sa capacité, soit monter en charge.

L’ajout de cœurs CPU supplémentaires à un Delivery Controller réduira l’utilisation globale du CPU, permettant ainsi la prise en charge d’un plus grand nombre de bureaux par un seul Controller. Cela n’est vraiment réalisable qu’avec des contrôleurs virtualisés, car l’ajout de CPU virtuels est assez facile et simple. L’autre alternative consiste à ajouter un autre Controller à la configuration du site. Le Controller aurait la même configuration que les autres, et la charge serait répartie uniformément sur tous les Controller, contribuant ainsi à réduire la charge globale sur chaque Controller.

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

Composant Spécifications
Processeur 4 processeurs virtuels
Memory 4 Go de RAM
Réseau Carte réseau virtuelle liée
Stockage hôte 40 Go de stockage partagé
OS 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.

Image du nombre de Delivery Controller

Décision : Haute disponibilité

Si le serveur hébergeant le Delivery Controller n’est pas disponible, les utilisateurs ne pourront pas accéder à leurs bureaux virtuels ou 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 Controller é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, et stoppe au premier dans lequel il trouve le Delivery Controller :

  1. Un emplacement de stockage persistant dont la maintenance est assurée pour la fonctionnalité de mise à jour automatique. Cet emplacement contient des informations sur le Controller lorsque la fonctionnalité de mise à jour automatique est activée et après que le VDA s’enregistre avec succès pour la première fois après l’installation. 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, SID de Delivery Controller).
  3. Informations de Delivery Controller sous la clé de Registre VDA ListofDDCs. Le programme d’installation de VDA renseigne initialement ces valeurs, en fonction des informations spécifiées lors de l’installation du VDA.
  4. Découverte basée sur l’unité d’organisation. Ceci est une méthode héritée conservée pour des raisons de rétrocompatibilité.
  5. Le fichier Personality.ini créé par Machine Creation Services.

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 d’hôte local

Même si la base de données SQL est hautement disponible, il existe un risque : 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 couvrant plusieurs emplacements géographiques.

Pour faire face à ce risque, les Delivery Controller peuvent utiliser la fonctionnalité de cache d’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 points suivants doivent être pris en compte lors de l’utilisation du cache d’hôte local :

  • Elections : lorsque les zones perdent le contact avec la base de données SQL, une élection se produit, désignant un Delivery Controller unique comme maître. Tous les Controller restants passent en mode inactif. Un ordre alphabétique simple détermine l’élu.
  • Dimensionnement : lors de l’utilisation du mode de cache d’hôte local, un Delivery Controller unique est responsable de tous les enregistrements, énumérations, lancements et mises à jour de VDA. Le Controller élu doit avoir suffisamment de ressources (CPU et RAM) pour gérer toute la charge de la zone. Un seul Controller peut monter jusqu’à 10 000 utilisateurs, ce qui influence la conception de la zone.
    • RAM : les services de cache d’hôte local peuvent consommer plus de 2 Go de RAM en fonction de la durée de la panne et du nombre de lancements d’utilisateurs pendant la panne.
    • CPU : le cache d’hôte local peut utiliser jusqu’à 4 cœurs dans un seul socket.
    • Stockage : en mode cache d’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 d’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 d’hôte local, Studio et PowerShell ne sont pas disponibles.

Décision : Chiffrement du service XML

Dans une session standard, le serveur StoreFront transmet des 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 masqués.

Si le trafic entre les serveurs Storefront et les Controller 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 de jeu de ressources.
  • Les attaquants ayant la possibilité de déchiffrer le masque peuvent obtenir des informations d’identification de l’utilisateur.
  • Les attaquants peuvent emprunter l’identité du Controller XenDesktop et intercepter les demandes d’authentification.

Pour la plupart des organisations, le trafic XML Citrix est isolé sur un réseau de centres de données physiques ou virtuels dédiés, ce qui rend l’interception improbable. Toutefois, pour des raisons de sécurité, envisagez d’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 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 définissent le nombre maximal de sessions qu’un serveur peut héberger sur 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 de capacité à monter en charge. Différents seuils et règles peuvent être appliqués à chaque groupe de mise à disposition en fonction des différents goulots d’étranglement identifiés lors des tests. 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 Gestion de la charge.

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 comme base de référence :

  • Utilisation du processeur : Pleine charge : 80 %
  • Priorité de processus exclue de l’utilisation UC : Inférieur à la normale ou Faible
  • Utilisation de la mémoire : Pleine charge : 80 %
  • Charge de base d’utilisation mémoire : Signaler une charge de zéro (Mo) : 786
  • Nombre maximum de sessions : X

La stratégie « Nombre maximum de sessions » permet de définir un plafonnement, ce qui est considéré comme une bonne pratique 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 de capacité à monter en charge.

Cloud Connector

Le service XenApp et XenDesktop dans Citrix Cloud utilise 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 ressources contenant des hôtes VDA.

Décision : Dimensionnement du serveur

La capacité à monter en charge de Cloud Connector est basée sur l’utilisation du processeur. Plus il y a de cœurs de processeur disponibles, plus le nombre de bureaux virtuels pouvant être pris en charge par un Cloud Connector est élevé. Chaque demande de démarrage, d’enregistrement, d’énumération et de lancement de bureau a un impact sur le processeur du Cloud Connector. À mesure que la tempête augmente en intensité, l’utilisation du processeur du Cloud Connector augmente. Si le CPU atteint un seuil critique (environ 80 %), le site devra soit augmenter sa capacité, soit monter en charge.

Les tests ont montré qu’un seul Cloud Connector, utilisant la configuration suivante, peut prendre en charge 5 000 bureaux.

Composant Spécifications pour configuration sur site Spécifications pour hébergement 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 processeurs virtuels
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
OS Windows Server 2012 R2 Windows Server 2012 R2

Provisioning Services

Citrix Provisioning Services (PVS) utilise la technologie de streaming pour simplifier le déploiement des machines virtuelles et physiques. Les ordinateurs sont provisionnés et provisionnés à nouveau en temps réel depuis une image disque partagée unique. En se faisant, les administrateurs peuvent complètement éliminer le besoin de gérer et corriger des systèmes individuels. Au lieu de cela, toute gestion d’image est effectuée sur l’image principale.

Décision : Topologie

Une batterie Provisioning Services représente le niveau supérieur de l’infrastructure Provisioning Services, qui peut être subdivisée en sites. Tous les serveurs de provisioning 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 regroupements 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 provisioning situé sur le même site.

Image de structure de site PVS

Certains facteurs doivent être pris en compte lorsque vous déterminez la topologie globale de Provisioning Services :

  • Réseau : les serveurs de provisioning communiquent constamment avec la base de données de batterie 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, à moins qu’elles ne soient connectées au serveur de base de données par une connexion rapide et robuste.
  • Administration : les organisations peuvent devoir séparer les tâches administratives à l’échelle d’un service, d’une région ou d’un pays. Des batteries Provisioning Services supplémentaires ajoutent une certaine complexité à la gestion de l’environnement. Toutefois, cette surcharge est généralement limitée à la configuration initiale, à la création de bureaux et aux mises à jour des images.
  • Organisation : les changements organisationnels sont une raison pratique pour créer plusieurs sites. Par exemple, deux sociétés ont peut-être récemment fusionné par acquisition, mais doivent garder les ressources séparées pendant que l’intégration a lieu. Configurer l’organisation pour qu’elle utilise des sites distincts est un moyen de garder les entreprises séparées tout en les gérant de manière centralisée via la console Provisioning Services.

Créez des sites supplémentaires uniquement si les exigences 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 machines

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

Image de structure de collection de machines

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

Envisagez de créer des collections de machines basées sur l’affectation 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 : il est recommandé de toujours implémenter au moins deux serveurs par site. Une redondance suffisante devrait être intégrée à la conception de sorte que la défaillance d’un seul serveur ne réduise pas le nombre total de machines cibles pouvant être prises en charge par site. Le fichier de démarrage de Provisioning Services doit être configuré pour une haute disponibilité. Jusqu’à quatre serveurs Provisioning Server peuvent être répertoriés dans le fichier de démarrage. Les machines cibles tenteront de contacter les serveurs dans l’ordre dans lequel ils sont répertoriés. Le serveur qui répond n’est pas nécessairement le serveur qui fournira des services de streaming à la machine cible. Si l’équilibrage de 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 stockage local, DAS (Direct Attached Storage) ou un réseau SAN, la réplication doit être utilisée pour synchroniser les vDisks. Si vous utilisez NAS (Network Attached Storage), 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, des 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 intégrer des cartes réseau redondantes.

Remarque

Les machines cibles basculent uniquement vers les cartes d’interface réseau qui se trouvent sur le même sous réseau que la carte d’interface 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 Provisioning Services peuvent utiliser TFTP pour fournir le fichier de bootstrap aux machines cibles. Il existe plusieurs options pour rendre le service TFTP hautement disponible. Voici quelques-unes des options les plus couramment utilisées :

  • Round Robin DNS : 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 provisioning de la batterie. Cette méthode n’est pas recommandée car l’état du service TFTP n’est pas surveillé. Les clients peuvent être envoyés à un serveur qui ne fonctionne pas.
  • Équilibreur de charge matérielle : utilisez un équilibreur de charge matérielle, tel que Citrix NetScaler, pour créer des adresses IP virtuelles correspondant aux serveurs de provisioning. NetScaler peut router intelligemment le trafic entre les serveurs de provisioning. Si l’un des serveurs devient indisponible, NetScaler arrête 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 Option 66 DHCP : 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 seule entrée d’option 66 de sorte que cette méthode ne serait pas possible dans les environnements avec les services DHCP Microsoft. Si vous utilisez un serveur ou une appliance DHCP non Microsoft, vérifiez auprès du fabricant si plusieurs entrées d’option 66 sont prises en charge.

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

  • DHCP Proxy : utilisez le service PXE des serveurs de provisioning pour fournir les informations de bootstrap. Si l’un des serveurs est en panne, le serveur disponible suivant dans la batterie peut fournir les informations de bootstrap. Cette méthode nécessite que les serveurs de provisioning soient sur le même domaine de diffusion que les machines cibles. Si d’autres services PXE s’exécutent 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.
  • Boot Device Manager : utilisez Boot Device Manager pour créer un fichier de bootstrap 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 méthode est utilisée, le service TFTP n’est pas utilisé du tout.

La haute disponibilité doit toujours être intégrée à la conception de Provisioning Services. Bien que la haute disponibilité puisse nécessiter des ressources supplémentaires et des coûts supplémentaires, elle fournira un environnement très stable et les utilisateurs connaîtront un impact minimal en cas de panne de service.

Décision : Mise à disposition de bootstrap

Une machine cible lance le processus de démarrage en chargeant d’abord un programme bootstrap qui initialise la session de streaming entre la machine cible et le serveur Provisioning Services. Il existe trois méthodes avec lesquelles la machine cible peut recevoir le programme bootstrap :

Utilisation des options DHCP -

  1. Lorsque la machine cible démarre, elle envoie une diffusion pour obtenir l’adresse IP et les informations de démarrage. DHCP traite cette demande et fournit une adresse IP ainsi que les paramètres de l’option d’étendue 66 (nom ou adresse IP du serveur TFTP Provisioning Services) et 67 (nom du fichier bootstrap).

    Remarque

    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 demande pour le fichier de bootstrap est envoyée de la machine cible au serveur de provisioning. La machine cible télécharge le fichier de démarrage à partir du serveur de provisioning.

  3. La machine cible démarre l’image vDisk attribuée.

Remarque

Nécessite que UDP/DHCP Helper soit configuré lorsque les cibles ne sont pas sur le même sous-réseau que les serveurs DHCP afin de recevoir les diffusions PXE.

Utilisation des diffusions PXE -

  1. Lorsqu’une machine cible démarre à partir du réseau, elle envoie une diffusion pour obtenir une adresse IP et des informations de démarrage. DHCP traite cette demande et fournit une adresse IP. En outre, tous les serveurs de provisioning qui reçoivent la diffusion renverront les informations sur le serveur de démarrage et le nom du fichier de démarrage. La machine cible fusionne les informations reçues et lance le processus de démarrage.

  2. À l’aide de TFTP, une demande pour le fichier bootstrap est envoyée de la machine cible au serveur de provisioning qui a répondu le premier. La machine cible télécharge le fichier de démarrage à partir du serveur de provisioning.

Remarque

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

Utilisation de Boot Device Manager : Boot Device Manager (BDM) crée un fichier de démarrage que les machines cibles obtiennent via un CD/DVD physique, une image ISO montée ou en tant que disque dur virtuel affecté à la machine cible. Une partition BDM peut être mise à niveau de l’une des trois manières suivantes :

  • Par une collection
  • Par un groupe de machines sélectionnées
  • Par une seul machine

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

Méthodes de mise à disposition Avantages Inconvénients
Options DHCP Facile à mettre en œuvre Nécessite des modifications du service DHCP de production. Le service DHCP peut n’autoriser qu’une entrée d’option 66. Nécessite une aide UDP/DHCP pour les cibles sur différents sous-réseaux.
PXE Facile à mettre en œuvre 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 machines cibles physiques. L’ISO BDM 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 requiert pas PXE, TFTP ni TSB ; elle est considérée comme un bootloader à étape unique, et trouve, au démarrage, toutes les informations liées au serveur PVS et ne requiert pas de services externes fournis par PXE, TFTP ou TSB. Une partition supplémentaire de 8 Mo est créée pour chaque machine cible.

Remarque

Lors de la configuration du fichier bootstrap, jusqu’à quatre serveurs de provisioning peuvent être répertoriés. L’ordre dans lequel apparaissent les serveurs de provisioning détermine l’ordre dans lequel ces derniers sont utilisés. Si le premier serveur ne répond pas, le serveur suivant dans la liste est contacté.

Décision : Format vDisk

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

  • Disque de taille fixe : pour les vDisks en mode privé, la taille fixe empêche la fragmentation du disque et offre de meilleures performances d’écriture sur les 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 effectuer les opérations de fusion de vDisk augmente avec les disques dynamiques. Il ne s’agit pas d’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 s’effectuent sur le cache système dans la RAM, il n’y a pas de changement significatif des performances lors de l’utilisation de disques dynamiques ou fixes. 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 de vDisks

Les vDisks hébergés sur un stockage local, Direct Attached Storage ou 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 des 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 de vDisks peut être effectuée manuellement ou automatiquement :

  • Manuel : la réplication manuelle est simple, mais peut prendre du temps, en fonction du nombre de vDisks et de magasins vDisk. Si une erreur se produit pendant le processus de réplication, les administrateurs peuvent les détecter immédiatement et prendre les mesures appropriées pour les résoudre. La réplication manuelle peut présenter un risque : l’incohérence de vDisks entre les serveurs de provisioning entraîne un fonctionnement incorrect de l’équilibrage de la charge et du basculement. Par exemple, si le vDisk est répliqué sur les disques durs de trois serveurs et que l’un des vDisks est mis à jour, ce vDisk n’est plus identique et ne sera pas considéré si un basculement de serveurs se produit. Même si la même mise à jour est réalisée sur les deux autres vDisks, les horodatages seront différent sur chacun d’eux, et donc les vDisks ne sont plus identiques.
  • Automatisé : pour les environnements de grande taille, la réplication automatisée est plus rapide que la méthode manuelle en raison du nombre de vDisks et de vDisk Stores requis. Certains outils automatisés, tels que Microsoft DFS-R, prennent en charge la limitation de la bande passante et la compression CF-RDC, qui utilisent des méthodes heuristiques pour déterminer si les fichiers de destination sont similaires au fichier en cours de réplication. 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. La réplication automatisée peut présenter un risque : l’administrateur ne surveille généralement pas les événements de réplication en temps réel et ne réagit pas rapidement lorsque des erreurs se produisent, à 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, Robocopy prend 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 de vDisks. Sélectionnez un outil capable d’effectuer une reprise après des interruptions réseau, de copier les attributs de fichier et de conserver l’horodatage d’origine.

Remarque

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

Décision : Dimensionnement du serveur

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

Composant Spécifications
Modèle Virtuel
Processeur 4 - 8 vCPU
Memory 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
OS Windows Server 2012 R2

Modèle

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

  • Virtuel : offre un provisionnement rapide de serveur, des instantanés pour une restauration ou une récupération rapide et la possibilité d’ajuster les ressources du serveur à la volée. Les serveurs de provisioning virtuels permettent de répartir les machines cibles sur un plus grand nombre de serveurs, ce qui réduit l’impact d’une panne de serveur. La virtualisation permet une utilisation plus efficace des ressources système.
  • Physique : offre des niveaux de capacité à monter en charge supérieurs (par serveur) que les serveurs virtuels. Les serveurs de provisioning physiques atténuent les risques associés aux machines virtuelles qui doivent partager les ressources d’hyperviseur sous-jacentes. En général, les serveurs de provisioning virtuels 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.

Remarque

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 éliminera un point de défaillance unique et ne supprimera pas l’ensemble de la batterie Provisioning Services en cas de panne d’un hôte.

UC

Provisioning Services ne sollicite pas fortement le CPU. Cependant, une sous-allocation du 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 = nbre de ports x nbre de threads/port

Par défaut, Streaming Service 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 sans cesse entre différentes machines cibles.

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 plus élevée du processeur et les machines cibles en attente de traitement des demandes ont une latence de lecture plus élevée.

Même si Provisioning Services ne sollicite pas fortement le CPU, l’allocation de 2 CPU nécessitera une plus grande plage de ports réseau contigus.

  • Environnements de petite taille (jusqu’à environ 500 machines virtuelles) : 4 vCPU sont recommandés.
  • Environnements de plus grande taille : 8 vCPU sont recommandés.

RAM

Le système d’exploitation Windows hébergeant Provisioning Services met partiellement en cache les vDisks en mémoire (cache système), ce qui réduit le nombre de lectures requises à partir du stockage. La lecture depuis le stockage est significativement plus lente que la lecture depuis 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 provisioning :

RAM serveur totale = 2 Go + (nbre de vDisks ∗ 2 Go)

Réseau

Contrairement à la plupart des autres composants de XenApp et XenDesktop, Provisioning Services n’entraîne pas de goulot d’étranglement au niveau du processeur. La capacité à monter en charge de Provisioning Services est basée 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 2012 R2 232
Windows 2008 R2 251
Windows Vista x86 190
Windows Vista x64 240

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

Image de la formule pour déterminer le délai de démarrage en secondes

OS Nombre de VM Débit réseau Temps de démarrage
Windows 10 x64 500 1 Gbit/s 960 secondes (16 minutes)
Windows 10 x64 500 10 Gbits/s 96 secondes (1 minute, 36 secondes)

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

Conseil

Les pare-feu peuvent ajouter de la latence et créer des goulots 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 Citrix CTX101810 — Ports de communication utilisés par Citrix Technologies, pour obtenir la liste des ports qui doivent être activés pour une fonctionnalité complète.

Croissance

À mesure que la batterie de serveurs se développe, les administrateurs devront décider s’ils doivent ajouter davantage de ressources aux serveurs de provisioning ou ajouter d’autres serveurs de provisioning à la batterie.

Un certain nombre de facteurs doivent être pris en compte pour déterminer si les serveurs Provisioning Server doivent être augmentés ou montés en charge :

  • Redondance : la répartition de la charge utilisateur sur des serveurs supplémentaires moins puissants permet de réduire le nombre d’utilisateurs affectés par la panne d’un seul serveur de provisioning. Si l’entreprise n’est pas en mesure d’accepter la perte d’un seul serveur à haute spécification, envisagez une montée en charge.
  • Délais de basculement : plus il y a de machines cibles connectées à un seul serveur de provisioning, plus leur basculement sera long en cas de panne du serveur. Envisagez de réduire le temps nécessaire au basculement des machines cibles vers un autre serveur.
  • Capacité du centre de données : le centre de données peut disposer d’un espace, d’une alimentation et/ou d’un refroidissement limités. Dans ce cas, envisagez une augmentation de la capacité.
  • Coûts du matériel : initialement, il peut être plus rentable d’augmenter la capacité. Cependant, il y aura un moment où la montée en charge deviendra réellement plus rentable. Une analyse des coûts devrait être effectuée pour prendre cette décision.
  • Coûts de l’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 tel est le cas, envisagez de procéder à une augmentation de la capacité afin de 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 qui augmentent les temps d’accès au disque et affectent directement les performances du bureau virtuel. Le diagramme suivant décrit une infrastructure réseau Provisioning Services courante :

Image d'un exemple de configuration réseau pvs

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

  • Liaison montante PVS : tous les accès au disque à partir des machines cibles seront transférés via la liaison montante du réseau PVS. Cela signifie que des centaines, voire des milliers de machines 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 machines cibles. Pour les serveurs de provisioning virtuels, un quota QoS respectif ou une liaison montante de réseau physique dédiée doit être configuré pour garantir les meilleures performances.
  • Liaison montante hyperviseur : utilisée par toutes les machines cibles PVS hébergées sur un hôte d’hyperviseur particulier. Par conséquent, la redondance avec basculement transparent est fortement recommandée. À moins que les machines cibles n’exécutent une charge de travail très intensive d’E/S ou exécutent simultanément des tâches intensives d’E/S (au démarrage, par exemple), une bande passante de 1 Gbit/s est suffisante pour cette liaison montante.
  • Liaison montante machine virtuelle : tout le trafic réseau d’une machine virtuelle, y compris le trafic de streaming PVS, traverse cette connexion réseau virtuelle. À moins que la charge de travail soit extrêmement exigeante en E/S, une bande passante de 100 Mbit/s est suffisante pour gérer même les pics de charge pendant les tâches intensives d’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 de données moyen de 20,5 Mbit/s avec des pics allant jusqu’à 90 Mbit/s 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 des BPDU (Bridged Protocol Data Units) 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 délais d’expiration PXE (Preboot Execution Environment). Pour éliminer ce problème, désactivez STP sur les edge-ports 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 pour supprimer le trafic de multidiffusion, de diffusion ou de monodiffusion. Son but est d’empêcher les expéditeurs malveillants ou accidentels d’inonder un réseau local et d’affecter les performances du réseau. Les serveurs PVS peuvent envoyer une grande quantité de trafic se situant à l’intérieur d’un seuil Storm Control. 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 ne seraient pas routés sinon. Dans un environnement PVS, il est nécessaire de transférer les demandes de démarrage PXE lorsque les clients ne se trouvent pas sur le même sous-réseau que les serveurs. Si possible, il est recommandé de concevoir un réseau avec des serveurs PVS résidant sur le même sous-réseau que les machines cibles. Cela atténue le risque de dégradation des services causé par d’autres composants de l’infrastructure réseau.

Les fonctionnalités d’interface réseau suivantes doivent être prises en compte 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 sur 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 lorsque le déchargement d’envoi volumineux est activé en raison de la charge supplémentaire placée sur la carte réseau. Le déchargement d’envoi volumineux et le déchargement de somme de contrôle TCP sont activés par défaut sur de nombreuses cartes réseau.

Remarque

Si le déchargement d’envoi volumineux est activé et que le commutateur traversé par le trafic ne prend pas en charge la taille d’image envoyée par le moteur de déchargement d’envoi volumineux, le commutateur supprimera la trame provoquant la retransmission de 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.

  • Receive Side Scaling (RSS) : RSS permet d’équilibrer les paquets reçus depuis une carte réseau sur plusieurs CPU, ce qui permet d’équilibrer la charge des connexions TCP entrantes, ce qui empêche les goulots d’étranglement au niveau d’un seul CPU. Dans Windows Server 2008 R2 et Windows Server 2012/2012 R2, RSS est activé par défaut.

Remarque

Pour plus d’informations sur les meilleures pratiques de mise en réseau PVS, veuillez consulter Meilleures pratiques de 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 lents), les performances peuvent être améliorées en isolant le trafic de streaming depuis un autre 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 requêtes de support concernant l’association avec Hyper-V doivent être adressées au fabricant OEM de carte réseau.

Décision : Subnet Affinity

Dans Provisioning Services, Subnet Affinity est un algorithme d’équilibrage de charge qui permet de s’assurer que les machines cibles sont connectées au serveur de provisioning le plus approprié. Lors de la configuration de Subnet Affinity, les options suivantes sont disponibles :

  • None : ignore les sous-réseaux et utilise le serveur le moins occupé.
  • Best Effort : utilise la combinaison serveur le moins occupé/carte d’interface réseau au sein du même sous-réseau. Si aucune combinaison serveur/carte d’interface réseau n’est disponible dans le sous-réseau, sélectionnez le serveur le moins occupé à l’extérieur de ce sous-réseau. Si plusieurs serveurs sont disponibles dans le sous-réseau sélectionné, procédez à l’équilibrage de charge entre ces serveurs. C’est le réglage par défaut.
  • Fixed : utilise la combinaison serveur le moins occupé/carte d’interface réseau au sein du même sous-réseau. Procédez à l’équilibrage de charge entre les serveurs de ce sous-réseau. Si aucune combinaison serveur/carte d’interface réseau n’existe dans le même sous-réseau, ne démarrez pas les machines cibles attribuées à ce vDisk.

Les exemples suivants présentent des configurations réseau courantes pour les serveurs de provisioning physiques. Des configurations similaires peuvent être implémentées pour les serveurs de provisioning virtuels sans compromettre les performances ou les fonctionnalités.

Conception lame

Les serveurs de provisioning et les machines 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 avec boîtier lame

L’option « Best Effort » de Subnet Affinity est utilisée pour maintenir 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 du second châssis, mais sur le même site Provisioning Services.

Conception rack

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

Image de conception rack PVS

Contrairement à la conception avec châssis lame, la fonction Subnet Affinity 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 garantit que les machines cibles sont diffusées en streaming à partir de serveurs de provisioning situés 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 bureaux virtuels. La société craint que le trafic de streaming de Provisioning Services crée un goulot d’étranglement sur le réseau, affectant ainsi d’autres applications. L’entreprise a choisi de créer l’environnement sur des serveurs lames afin que le trafic de provisioning soit contenu dans le boîtier lame et n’ait pas d’impact sur le trafic du réseau.

Décision : Cache de lecture

PVS-Accelerator permet à un proxy PVS de résider dans le domaine de contrôle de XenServer sur un hôte sur lequel le streaming d’un vDisk Provisioning Services est mis en cache sur le proxy avant d’être transmis à la machine virtuelle. À l’aide du cache, chaque démarrage ultérieur (ou toute demande d’E/S) de la machine virtuelle sur le même hôte peut être streamé depuis le proxy plutôt que streamé depuis le serveur via le réseau. PVS Accelerator nécessite plus de ressources locales sur l’hôte XenServer, mais le streaming depuis le serveur via le réseau économise les ressources, ce qui améliore les performances.

Image de 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 PVS Accelerator

Pour de plus amples informations sur la relation entre XenServer et Provisioning Services, consultez le blog XenServer and PVS: Better Together.

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 de 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 sur l’hôte.

Image de stockage local de VM

VM — Cache dans la RAM

La RAM associée à la machine virtuelle contient les lecteurs de cache d’écriture pour chaque machine virtuelle cible. Cette option offre des performances élevées en raison de la vitesse de la RAM. Toutefois, si le cache de la RAM manque d’espace, la machine virtuelle devient 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.

Image de cache VM dans la RAM

VM — Cache dans la RAM avec débordement sur 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é, les blocs volumineux sont retirés du cache RAM et placés sur le disque de cache d’écriture du stockage local. Cette option offre des niveaux élevés de performances avec le faible coût du stockage local.

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

Image de cache VM dans la RAM

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

Image de cache VM dans la 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 à CTX124185 - Provisioning Services Antivirus Best Practices.

Un logiciel antivirus peut provoquer des problèmes de verrouillage de fichiers sur les serveurs de provisioning. Le vDisk Store et le cache d’écriture doivent être exclus des analyses antivirus afin d’éviter les problèmes de contention 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 machines cibles à la fois, provoquant souvent une congestion du réseau pendant la durée de l’opération. 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 permet, 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.

Machine Creation Services

Machine Creation Services (MCS) utilise la technologie de clonage de disque pour simplifier le déploiement des machines virtuelles. Les ordinateurs sont provisionnés et provisionnés à nouveau en temps réel depuis une image disque partagée unique. En se faisant, les administrateurs peuvent éliminer le besoin de gérer et 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 bureau 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 sur plusieurs hôtes hyperviseurs, elle est plus contraignante pour la baie de stockage, car elle doit également héberger le disque de différenciation, c’est-à-dire 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 permet à l’administrateur de partager l’image principale entre plusieurs hôtes de l’hyperviseur tout en déchargeant les E/S par seconde d’écriture temporaires coûteuses vers un stockage d’hyperviseur local bon marché.

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érenciation et le stockage XenServer local pour un cache local du disque du système d’exploitation.

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

Image MCS IntelliCache

Décision : Type de clonage

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

  • Léger : 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 propriétaire du disque, ce qui permet les activités de lecture/écriture. La technologie de clonage complet n’est disponible que pour les bureaux virtuels personnels, avec lesquels 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 léger et de clonage complet :

  Clone léger Clone complet
Espace de stockage requis Économise le plus l’espace de stockage. Une seule image de disque principale est partagée entre plusieurs machines virtuelles. Seul le disque de différenciation (écritures) consomme de l’espace, qui continue de croître jusqu’à ce que la machine virtuelle redémarre Besoins élevés en espace de stockage. Chaque machine virtuelle reçoit une copie complète de l’image principale. La taille continue de croître à 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 snapshot/delta, ce qui rend les machines virtuelles à provisioning léger difficiles/impossibles à sauvegarder ou à déplacer vers d’autres baies de stockage. Facile. La machine virtuelle existe au sein d’un seul disque virtuel, ce qui facilite la sauvegarde et la restauration.
Vitesse de provisioning Rapide. Ne nécessite qu’une seule image disque Lent (peut être amélioré). Chaque machine virtuelle nécessite une copie complète de l’image principale. Les technologies d’optimisation du stockage peuvent contribuer à atténuer les effets.
Les performances Plus lent. Une E/S en lecture peut se produire deux fois, l’une pour le disque principal et l’autre pour le disque différentiel, ce qui augmente les E/S par seconde en lecture. Plus rapide. Toutes les lectures/écritures effectuées directement sur un seul disque.
Tempête de démarrage Impact élevé. Dans une tempête de démarrage, tous les disques de différenciation sont redimensionnés pour contenir toutes les écritures du démarrage de Windows, ce qui place une charge élevée sur le stockage car tout se produit simultanément. Faible impact.

Décision : Cache de lecture

Pendant le démarrage et l’ouverture de session, les bureaux virtuels connaissent des niveaux élevés d’E/S par seconde en lecture de stockage, 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é et regroupé utilisent un cache de lecture basé sur RAM hébergé sur chaque XenServer.

Image de cache de lecture MCS

L’utilisation de cette technologie intégrée réduit le nombre d’E/S par seconde en lecture de 50 à 80 %.

Image de grille de cache de lecture MCS

Décision : Cache d’écriture

En mode de fonctionnement, les bureaux virtuels connaissent 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 la RAM en utilisant la RAM regroupée non paginée du système d’exploitation des machines virtuelles.

Image de cache d'écriture MCS

L’utilisation de cette technologie intégrée réduit le nombre d’E/S par seconde en é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 :

Méthodologie de conception d’une couche de contrôle