Ce article a été traduit automatiquement. (Clause de non responsabilité)
Guide de dimensionnement des bases de données pour XenApp et XenDesktop, versions 7.6 à la version actuelle
Avertissement
Ce document contient des liens vers des sites Web contrôlés par des parties autres que Citrix. Citrix n’est pas responsable et n’approuve ni n’accepte aucune responsabilité quant au contenu ou à l’utilisation de ces sites Web tiers. Citrix ne vous fournit ces liens que pour des raisons de commodité, et l’inclusion de tout lien n’implique pas l’approbation par Citrix du site Web lié. Il est de votre responsabilité de prendre des précautions pour vous assurer que tout ce que vous choisissez d’utiliser est exempt de virus ou d’autres éléments de nature destructrice.
Vue d’ensemble
Un déploiement typique de XenDesktop 7 se compose de trois bases de données, comme suit :
- Base de données de configuration de site
Stocke la configuration et l’état actuels du déploiement de XenDesktop - Base de données de surveillance
Stocke les données historiques à afficher dans Director - Base de données de journalisation des configurations
Suit les modifications de configuration apportées au déploiement de XenDesktop
Par défaut, les bases de données de journalisation et de surveillance de la configuration (bases de données secondaires) se trouvent sur le même serveur que la base de données de configuration du site. Au départ, les trois bases de données portent le même nom. Citrix vous recommande de modifier l’emplacement des bases de données secondaires après avoir créé un site.
Un déploiement type utilise également la base de données temporaire, TempDB, fournie par SQL Server.
Chaque base de données a un objectif différent et croît à un rythme différent.
Ce document fournit des informations sur chaque base de données et met en évidence les principales considérations à prendre en compte lors du dimensionnement des bases de données pour prendre en charge XenDesktop 7.
Remarque : Tous les chiffres fournis sont des estimations. Il faut s’attendre à des variations entre les déploiements.
Les différences de taille entre les bureaux partagés hébergés (HSD) et l’infrastructure de bureaux virtuels (VDI) sont également mentionnées dans ce document. Les environnements mixtes devront combiner les estimations des deux types d’ordinateurs de bureau pour générer une estimation de la taille globale de la base de données.
Modifications apportées aux documents pour XenDesktop 7.6
Ce document a été étendu pour couvrir la version 7.6 de XenDesktop. Cela avait pour but de permettre des mises à jour sur les modifications de taille pour les fonctionnalités ajoutées dans la version 7.6. Les trois nouvelles fonctionnalités qui influent sur le dimensionnement des bases de données sont les suivantes :
- Connection Leasing : les fichiers de location compressés sont stockés dans la base de données du site
- Surveillance de l’utilisation des applications : les détails de toutes les applications utilisées dans l’environnement sont stockés dans la base de données du moniteur
- Surveillance de l’inventaire des correctifs : détails des correctifs Citrix appliqués aux Controller, aux VDA et aux images VDA de l’environnement
Les informations sur la taille des tables ont été mises à jour ci-dessous. Les transactions par seconde et la croissance du journal des transactions étaient considérées comme similaires entre 7,6 et 7,5, de sorte qu’aucune mise à jour n’a été apportée à ces sections.
Considérations de haut niveau
Base de données du site
La base de données du site contient des informations de configuration pour le fonctionnement du système.
Son utilisation se caractérise par :
- La taille maximale est atteinte pendant les heures de pointe, car les connexions des utilisateurs génèrent des informations de session et de connexion à suivre.
- La taille minimale est atteinte lorsqu’aucune session n’est active et que les VDA sont tous arrêtés et non enregistrés.
- La taille maximale est atteinte au bout de 48 heures, car la base de données ne stocke que très peu d’informations persistantes. Cela est dû au fait qu’un petit journal des connexions est maintenu dans la base de données du site pendant 48 heures.
- La taille de référence de la base de données augmente à mesure que les informations de configuration d’un site augmentent. En d’autres termes, un plus grand nombre de travailleurs et d’utilisateurs consomment plus d’espace dans la base de données.
- Des niveaux élevés de transactions par seconde se produisent lors de l’ouverture de session, car chaque connexion utilisateur nécessite l’exécution de plusieurs transactions individuelles et évolue en fonction du taux de lancement simultané.
- Bruit de fond faible généré par les transactions liées au rythme cardiaque du VDA. Chaque VDA émet un battement de cœur toutes les 5 minutes et cette mise à jour déclenche une transaction sur la base de données.
Impact de l’échec
Une panne de la base de données du site rend le système impossible à gérer et à surveiller. Les connexions existantes sont maintenues. Dans XenDesktop 7.6, Connection Leasing permet d’établir de nouvelles connexions et reconnexions. Dans les versions précédentes, les nouvelles connexions et reconnexions n’étaient pas possibles.
Base de données de surveillance
La base de données de surveillance contient des informations historiques sur le site. Ces informations sont utilisées par Director pour afficher des informations historiques.
Son utilisation se caractérise par :
- La taille maximale est contrôlée par la période de rétention configurée, comme suit :
- Pour les clients non Platinum, la durée par défaut est de 7 jours, avec une période maximale de 7 jours.
- Pour les clients Platinum, la valeur par défaut est de 90 jours, sans période maximale.
- L’atteinte de la taille maximale peut prendre un certain temps, car le système doit atteindre la période de rétention configurée.
- De faibles niveaux de transactions par seconde se produisent en raison de la nature groupée des mises à jour effectuées par le Service de surveillance. Il est rare de voir des transactions par seconde dépasser la barre des 20 transactions par seconde.
- Certaines transactions en arrière-plan provoquées par des appels de consolidation réguliers du Service de surveillance.
- Un traitement nocturne est effectué pour supprimer les données en dehors de la période de conservation configurée.
Impact de l’échec
Une panne de la base de données de surveillance empêche la collecte de données pour le site, ce qui signifie que les données ne sont pas visibles dans Director.
Base de données d’enregistrement des configurations
La base de données de journalisation de la configuration contient un journal historique de toutes les modifications de configuration apportées au site. Ces informations sont utilisées pour générer des rapports ou pour être affichées dans Studio.
Son utilisation se caractérise par :
- La taille maximale est difficile à prévoir car elle dépend du niveau d’activité de configuration.
- Toutes les actions, par exemple la réinitialisation de session, effectuées par Director sont enregistrées dans cette base de données. La croissance peut donc être lente à mesure que les administrateurs utilisent Director.
- Les transactions effectuées sur la base de données sont minimes lorsqu’aucune modification de configuration n’est apportée.
- Un faible taux de transaction lors des mises à jour, car les mises à jour sont groupées dans la mesure du possible.
- Suppression manuelle des données. Les données de la base de données de journalisation de la configuration ne sont soumises à aucune politique de conservation et ne sont pas supprimées à moins qu’un administrateur ne le fasse manuellement.
Impact de l’échec
L’impact d’une panne de la base de données de journalisation de la configuration dépend de la configuration du site, comme suit :
- Si le site n’autorise pas les modifications lorsque la base de données de journalisation de la configuration n’est pas disponible, il n’est pas possible de reconfigurer le déploiement de XenDesktop.
- Si le site autorise les modifications lorsque la base de données de journalisation de la configuration n’est pas disponible, des modifications de configuration non suivies peuvent être apportées au déploiement de XenDesktop.
Base de données temporaire
La base de données temporaire est une base de données à l’échelle du système fournie par SQL Server. Il est utilisé comme magasin de versions pour l’isolation des snapshots en lecture validée. XenDesktop 7 utilise cette fonctionnalité de SQL Server pour réduire les conflits de verrouillage dans les bases de données XenDesktop.
La taille du magasin de versions dépend du nombre de transactions actives. En général, cependant, il ne s’agit pas de plus de quelques Mo.
Les performances de TempDB ont un impact sur les performances du courtage XenDesktop, car toutes les transactions qui génèrent de nouvelles données nécessitent de l’espace TempDB. Cependant, XenDesktop a tendance à avoir des transactions de courte durée, ce qui permet de réduire la taille du magasin de versions.
La base de données temporaire est également utilisée lorsque les requêtes génèrent de grands ensembles de résultats intermédiaires.
Vous trouverez des conseils sur le dimensionnement et la configuration de TempDB dans la documentation produit de Microsoft :
Le principal sujet de discorde concerne le nombre de fichiers à utiliser. Les anciennes versions de SQL Server, telles que SQL Server 2000, nécessitent davantage de fichiers que les versions plus récentes. Pour plus d’informations sur le nombre de fichiers à utiliser, consultez :
Isolation des instantanés en lecture validée
Citrix recommande que toutes les bases de données XenDesktop 7 utilisent l’isolation par capture instantanée en lecture validée. Pour plus d’informations, consultez Comment activer un instantané en lecture validée dans XenDesktop.
Dimensionnement des bases de données
La taille des bases de données dépend d’un certain nombre de facteurs clés, notamment le nombre de sessions et de connexions créées au cours d’une journée de travail.
Une session est un poste de travail ou une application en cours d’exécution pendant un certain temps et auquel il est possible de se déconnecter puis de se reconnecter.
Une connexion est chaque fois qu’un utilisateur se connecte à une session. La déconnexion ferme la connexion, mais pas la session. Lorsqu’un utilisateur se reconnecte, cela crée une nouvelle connexion à une session existante.
Base de données du site
La taille maximale de la base de données de site est basée sur le nombre de VDA et de sessions actives, comme suit :
| Les utilisateurs | Demandes | Tapez | Taille maximale prévue 7,5 (Mo) | Taille maximale prévue 7,6 (Mo) |
|---|---|---|---|---|
| 1 000 | 50 | HSD | 30 | 31 |
| 10 000 | 100 | HSD | 60 | 198 |
| 100 000 | 200 | HSD | 330 | 752 |
| 1 000 | N/A | VDI | 30 | 30 |
| 10 000 | N/A | VDI | 115 | 121 |
| 40 000 | N/A | VDI | 390 | 426 |
Chaque application publiée ajoute 110 Ko à la base de données pour stocker chaque icône unique.
Remarque :
L’augmentation de la taille de la version 7.6 est due au fait que les contrats de location de connexion sont stockés dans la base de données dans le cadre de la réplication entre les Controller.
Base de données de surveillance
Parmi les trois bases de données, la base de données de surveillance devrait devenir la plus importante au fil du temps.
Sa taille dépend de nombreux facteurs, notamment les suivants :
- Nombre d’utilisateurs
- Nombre de sessions
- Nombre de connexions
- Travailleurs VDI ou HSD
- Période de rétention configurée
Vous trouverez ci-dessous des estimations de la taille de la base de données à un certain nombre de points de données. Ces données sont une estimation basée sur les données obtenues lors des tests d’échelle de XenDesktop. Les estimations sont considérées comme réalistes.
Les clients qui gèrent leur base de données peuvent toutefois constater que celle-ci est plus petite que les estimations.
Le nombre d’utilisateurs HSD est calculé sur la base de 100 utilisateurs par serveur HSD.
Périodes de conservation maximales
La quantité maximale de données conservées est contrôlée par licence, comme suit :
- Les clients non-Platinum peuvent conserver jusqu’à 1 semaine (7 jours) de données.
- Les clients Platinum peuvent conserver un nombre illimité de données ; la valeur par défaut est de 3 mois (90 jours).
Les périodes de rétention peuvent être ajustées à l’aide de l’applet de commande Set-MonitorConfiguration .
Une fois que les données sont antérieures à la période de conservation configurée, elles sont supprimées de la base de données.
Dimensionnement de la base de données de surveillance XenDesktop 7.5
Estimations avec 1 connexion et 1 session par utilisateur avec une semaine de travail de 5 jours
| Les utilisateurs | Tapez | 1 semaine (Mo) | 1 mois (Mo) | 3 mois (MB) | 1 an (MB) |
|---|---|---|---|---|---|
| 1 000 | HSD | 151 | 70 | 230 | 900 |
| 10 000 | HSD | 2 830 | 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
| Les 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 |
Notez que les disques durs génèrent davantage de données au fil du temps en raison de la journalisation des informations d’équilibrage de charge, mais leur taille initiale est similaire à celle des postes de travail VDI.
Dimensionnement de la base de données de surveillance XenDesktop 7.6
Les principales modifications par rapport à la version 7.5 sont les suivantes :
- Informations sur le correctif
Les données ci-dessous sont basées sur 3 correctifs par Worker (VDI ou HSD) - Historique d’utilisation de l’application
Ceci est principalement pertinent pour les systèmes HSD.
Estimations avec 1 connexion et 1 session par utilisateur avec une semaine de travail de 5 jours
| Les utilisateurs | Tapez | 1 semaine (Mo) | 1 mois (Mo) | 3 mois (MB) | 1 an (MB) |
|---|---|---|---|---|---|
| 1 000 | HSD | 151 | 605 | 1 966 | 7 865 |
| 10 000 | HSD | 2 830 | 11 301 | 36 712 | 146 834 |
| 100 000 | HSD | 7 194 | 28 585 | 92 758 | 370 841 |
| 1 000 | VDI | 13 | 49 | 157 | 622 |
| 10 000 | VDI | 117 | 409 | 1 287 | 5 090 |
| 40 000 | VDI | 460 | 1 610 | 5 058 | 19 999 |
Estimations avec 2 connexions et 1 session par utilisateur avec une semaine de travail de 5 jours
| Les utilisateurs | Tapez | 1 semaine (Mo) | 1 mois (Mo) | 3 mois (MB) | 1 an (MB) |
|---|---|---|---|---|---|
| 1 000 | HSD | 159 | 635 | 2 063 | 8 251 |
| 10 000 | HSD | 2 904 | 11 599 | 37 684 | 150 718 |
| 100 000 | HSD | 7 940 | 31 572 | 102 465 | 409 672 |
| 1 000 | VDI | 21 | 79 | 253 | 1 008 |
| 10 000 | VDI | 191 | 708 | 2 258 | 8 974 |
| 40 000 | VDI | 759 | 2 805 | 8 941 | 35 532 |
Base de données d’enregistrement des configurations
Il est beaucoup plus difficile de fournir des conseils pour le dimensionnement de la base de données de journalisation de la configuration, car celle-ci varie considérablement en fonction de l’activité quotidienne de Director et de la taille du site configuré.
Les activités qui ont un impact sur les sessions ou les utilisateurs sont enregistrées et incluent, par exemple, la fermeture et la réinitialisation des sessions. Les activités passives, telles que la liste des sessions d’un utilisateur, ne le sont pas.
Le mécanisme utilisé pour déployer les postes de travail a également un impact sur la taille des données enregistrées.
Dans les environnements HSD qui n’utilisent pas MCS, la taille de la base de données est généralement comprise entre 30 Mo et 40 Mo.
Pour les environnements MCS, la taille de la base de données peut facilement dépasser 200 Mo en raison de l’enregistrement de toutes les données de génération de machines virtuelles.
Aucune modification significative n’a été apportée à la version 7.6 de la base de données de journalisation de la configuration.
Activité de la base de données lors de l’ouverture de session de 100 000 sessions HSD
Lors des tests d’évolutivité, simulant 100 000 connexions à des sessions HSD, la croissance du journal des transactions a été mesurée selon deux taux d’ouverture de session, comme suit :
- 100 000 utilisateurs se connectent en 1 heure
- 100 000 utilisateurs se connectent en 2 heures
Ces taux ont été choisis pour fournir des exemples de points de données.
L’environnement comprenait :
- 2 contrôleurs de livraison
- 43 travailleurs HSD VDA
- 3 serveurs SQL, configurés avec les bases de données, regroupés dans un groupe de disponibilité Always On
Les détails relatifs à la configuration des serveurs sont fournis à la fin de ce document.
Croissance du journal des transactions
La croissance du journal des transactions pour toutes les bases de données a été surveillée à l’aide du compteur de performance SQLServer:Databases — Taille du ou des fichiers journaux utilisés (Ko).
Base de données du site
Lorsque le système est inactif, le journal des transactions augmente de 3,5 Mo par heure. Il s’agit d’une combinaison de battements de cœur de VDA et de Broker Service.
| Testez | Croissance totale du nombre d’ouvertures de session (Mo) | Croissance totale des déconnexion (Mo) |
|---|---|---|
| 100 km en 1 heure | 1 900 | 1 150 |
| 100 km en 2 heures | 1 900 | 1 150 |
La croissance logarithmique est linéaire sur la période mesurée. Ces données suggèrent que, par connexion utilisateur, le journal des transactions augmente de 20 Ko. Le journal des transactions augmente de 12 Ko par utilisateur déconnecté.
Par conséquent, la croissance par jour est de 32 Ko par cycle de connexion/déconnexion de l’utilisateur.
Base de données de surveillance
Lorsque le système est inactif, le journal des transactions augmente de 30,5 Mo par heure. Il s’agit d’une combinaison de procédures stockées de consolidation et de mises à jour de l’index de charge HSD VDA.
| Testez | Croissance totale du nombre d’ouvertures de session (Mo) | Croissance totale des déconnexion (Mo) |
|---|---|---|
| 100 000 en 1 heure | 670 | 190 |
| 100 000 en 2 heures | 650 | 220 |
La croissance logarithmique est linéaire sur la période mesurée. Ces données suggèrent que le journal des transactions augmente de 7 Ko par connexion utilisateur. Le journal des transactions augmente de 2 Ko par utilisateur qui se déconnecte.
Par conséquent, la croissance par jour est de 9 Ko par cycle de connexion/déconnexion de l’utilisateur.
Transactions par seconde
La croissance du journal des transactions pour toutes les bases de données a été surveillée à l’aide des compteurs de performance suivants :
- SQL Server : bases de données — Transactions/seconde
- SQL Server : bases de données — Transactions d’écriture par seconde
Base de données du site
Lorsque le système est inactif, il y a 5 transactions par seconde, dont 1 transaction d’écriture par seconde maintient les battements de cœur du VDA et du Broker.
Remarque : Ces chiffres sont des estimations tirées des périodes données. La charge exacte varie en fonction du nombre de lancements simultanés par seconde.
| Testez | Transactions d’ouverture de session par seconde | Transactions d’ouverture de session et d’écriture par seconde | Transactions de fermeture de session par seconde | Transactions d’écriture et de fermeture de session par seconde |
|---|---|---|---|---|
| 100 000 en 1 heure | 870 | 310 | 250 | 100 |
| 100 000 en 2 heures | 475 | 170 | 140 | 60 |
Base de données de surveillance
Lorsque le système est inactif, les procédures stockées de consolidation s’exécutent une fois par minute et génèrent des transactions. Le niveau des transactions est toutefois faible. En général, il y a 2 à 3 transactions et 1 transaction d’écriture pour chaque procédure stockée de consolidation, et 3 procédures stockées de consolidation sont exécutées. Pendant les périodes actives, les frais généraux augmentent au fur et à mesure que le travail est effectué.
Remarque : Ces chiffres sont des estimations tirées des périodes données.
| Testez | Transactions d’ouverture de session par seconde | Transactions d’ouverture de session et d’écriture par seconde | Transactions de fermeture de session par seconde | Transactions d’écriture et de fermeture de session par seconde |
|---|---|---|---|---|
| 100 000 en 1 heure | 4 | 2 | 4 | 2 |
| 100 000 en 2 heures | 4 | 2 | 3,5 | 2 |
Utilisation du processeur
Tous les serveurs SQL utilisés pour ce test étaient des serveurs à double cœur hexadécimaux avec l’hyper-threading activé. Les spécifications matérielles exactes sont fournies à la fin de ce document.
Les serveurs étaient connus pour être surdimensionnés par rapport à la charge à exécuter. Cela nous a permis d’identifier les limites et les maximums imposés au matériel. On s’attend à ce que la charge du processeur SQL ait pu être gérée par un SQL Server doté d’un seul système quadricœur, plutôt que d’un système à double cœur hexagonal.
Pendant les tests, le processeur du système a été surveillé à l’aide du compteur de performance Processeur – % de la durée du processeur – \ _Total.
Réplique principale
Pendant l’inactivité, le processeur fonctionnait à 0 à 2 % du processeur disponible. Les procédures stockées de consolidation provoquaient des pics toutes les minutes pendant environ 1 seconde à 8 à 10 % du processeur du système. Cela devrait évoluer en fonction de la quantité de données traitées.
Lors de l’ouverture de session de 100 000 utilisateurs en 1 heure, le processeur est passé à 7 % et a augmenté de façon linéaire à 11 % à mesure que davantage de sessions et d’utilisateurs étaient présents dans l’environnement. Notez que les pics de procédures stockées de consolidation ont ajouté 7 % au processeur total, ce qui a fait que les pics ont atteint 18 % du processeur.
Lors de la fermeture de session, le processeur tournait à 3,5 %, avec 7 % de processeur supplémentaire pour les procédures stockées de consolidation. Dans l’ensemble, cela suggère que <20 % d’un double cœur hexagonal étaient nécessaires pour maintenir le taux d’ouverture et de fermeture de session.
Remarque : Le planificateur Windows Server 2012 a tendance à n’utiliser les hyperthreads que si nécessaire. En d’autres termes, jusqu’à ce que le système atteigne 50 % de charge, il n’exécute qu’un seul thread par cœur dans la mesure du possible, donc une charge de 20 % sur 24 hyperthreads s’exécute sur 4,8 cœurs.
Compte tenu de la charge de travail, on pense qu’il s’agit d’un test de résistance intensif et qu’un seul serveur SQL quadricœur serait suffisant pour les déploiements de XenDesktop.
Répliques secondaires
Il a été constaté que les répliques secondaires configuraient 2 % du processeur lors de l’ouverture de session et 1,5 % lors de la fermeture de session. Il fallait s’y attendre car, dans la plupart des cas, les répliques stockent les données du serveur principal sur leurs disques, et seule la réplique synchrone est impliquée dans les transactions, car la réplication principale ne valide aucune transaction tant que le réplica secondaire n’en a pas accusé réception.
Sur la base des recommandations visant à ce que le matériel HA corresponde à la réplique principale, cette charge serait gérée très facilement par un serveur spécifié de la même manière.
Utilisation temporaire de la base de données
Le TempDB est utilisé à de nombreuses fins, notamment pour le stockage des versions, l’espace pour les grands ensembles de requêtes et pour d’autres utilisations de tables temporaires.
Dimensionnement TempDB
Dans cette configuration SQL, TempDB a été configuré pour avoir 8 fichiers de base de données, chacun d’une taille fixe de 5 Go. Cela permet une meilleure utilisation simultanée de TempDB, mais fournit également beaucoup d’espace et ne déclenche aucun événement de croissance automatique. D’après les données saisies, il était surdimensionné pour ce déploiement. Il y avait cependant suffisamment d’espace disque disponible.
Il respecte également les directives générales selon lesquelles le nombre de fichiers de base de données TempDB représente entre un quart et la moitié du nombre de processeurs disponibles, mais ne dépassant pas 8 sans savoir qu’il existe un véritable conflit.
Notez qu’un seul fichier journal TempDB est utilisé, car SQL Server ne bénéficie pas de plusieurs fichiers journaux.
Boutique de versions
TempDB contient un magasin de versions pour les versions de lignes liées à l’isolation des instantanés en lecture validée utilisée par les bases de données XenDesktop.
L’utilisation peut être mesurée à l’aide des compteurs de performance suivants :
- SQLServer:Transactions – Taille du magasin de versions (Ko)
- SQLServer:Transactions – Taux de nettoyage des versions (Ko/s)
- SQLServer:Transactions – Taux de génération de versions (Ko/s)
Lors d’une connexion de 100 000 personnes en 1 heure, la taille du magasin de versions est restée comprise entre 10 Mo et 30 Mo, avec un effet de dent de scie au fur et à mesure que les versions étaient créées puis nettoyées. Lors de la fermeture de session, la plage était comprise entre 10 Mo et 21 Mo. En cas d’inactivité, la taille du magasin de versions était comprise entre 1 Mo et 4 Mo.
Le taux de génération de versions était compris entre 250 et 500 Ko lors de l’ouverture de session, entre 150 et 400 Ko/s lors de la fermeture de session et entre 0 et 250 Ko/s en mode veille.
Le nettoyage de version s’exécute une fois par minute et a atteint 2 500 Ko/s lors de l’ouverture de session, 1 750 Ko/s pendant la fermeture de session et 400 Ko/s pendant les périodes d’inactivité.
E/S sur disque
Au cours des tests de connexion, les E/S du disque ont été mesurées à l’aide des compteurs de performance suivants :
- PhysicalDisk : lecture du disque (octets/seconde)
- PhysicalDisk — Écriture sur disque (octets/seconde)
- PhysicalDisk — Lectures du disque/seconde
- PhysicalDisk — Ecritures sur disque/seconde
Les E/S de lecture se sont révélées minimes, car le serveur SQL était capable de conserver toutes les données en mémoire, ce qui entraînait très peu d’activité de lecture sur le système.
En raison de la disposition des bases de données et du système de stockage, les volumes ont été divisés, un volume contenant tous les fichiers de données et un second contenant tous les fichiers journaux de transactions.
Les données montrent un schéma difficile à situer dans un tableau. En général, le journal des transactions affichait un octet d’écriture par seconde de 800 Ko/s pour le test d’une heure et de 400 Ko/s pour le test de 2 heures. Une fois par minute, lorsque les procédures stockées de consolidation étaient exécutées, le journal des transactions affichait des pics allant jusqu’à 30 Mo/s.
L’analyse des procédures stockées de consolidation montre que les statistiques rendent parfois le plan de requêtes sous-optimal et qu’une table temporaire se répand dans TempDB. Cela déclenche des écritures dans le journal des transactions pour TempDB.
Ce transfert de données se traduit par un état stable de 300 opérations d’entrée/sortie par seconde (IOPS) d’écriture pour le test d’une heure et de 200 IOPS d’écriture pour le test de 2 heures. Les pics des procédures stockées de consolidation ajoutent 2 à 300 IOPS en écriture supplémentaires pendant l’exécution. Notez que dans un environnement de grande taille, les procédures stockées de consolidation s’exécutent pendant moins d’une seconde.
Lorsque chaque base de données est cochée, les données sont synchronisées entre les tables en mémoire et les fichiers de données du volume de données.
Pour plus d’informations sur le point de contrôle SQL, consultez http://technet.microsoft.com/enus/.
Ces points de contrôle sont des périodes d’activité très courtes, généralement inférieures à une seconde.
Lors de l’ouverture de session, les points de contrôle consommaient entre 6 et 7 Mo/s et 500 IOPS en écriture. Lors de la fermeture de session, les points de contrôle consommaient 7 Mo/s, soit entre 200 et 700 IOPS. Les chiffres varient car les bases de données Site et Monitoring contiennent des quantités de données différentes au point de contrôle.
Entretien des bases de données
La maintenance des bases de données dans un déploiement de grande envergure est importante. Si la base de données n’est pas correctement gérée, des pannes de base de données peuvent survenir en raison du manque d’espace dans la base de données, par exemple, si le journal des transactions est configuré pour croître automatiquement et remplit le disque, ou si le journal des transactions est de taille fixe et devient plein.
Maintenance du journal des transactions
Lorsque vous utilisez les fonctionnalités de haute disponibilité de SQL Server, telles que les groupes de disponibilité Always On ou la mise en miroir de bases de données, les bases de données XenDesktop s’exécutent en mode journalisation complète des transactions.
En mode journalisation complète des transactions, le journal des transactions continue de croître jusqu’à ce qu’une sauvegarde de la base de données ou du journal des transactions soit effectuée.
Cela peut entraîner des problèmes si les fichiers journaux de transactions ne sont pas surveillés car, par défaut, SQL Server configure les fichiers journaux pour qu’ils grandissent automatiquement. Cela entraîne deux problèmes :
- Les fichiers journaux de transactions peuvent consommer beaucoup d’espace disque.
- Chaque fois que le journal des transactions augmente, il bloque toutes les transactions jusqu’à ce que l’espace du journal soit remis à zéro.
Citrix recommande de sauvegarder régulièrement les fichiers journaux. Cela peut se faire au moyen de travaux planifiés ou de plans de maintenance.
Vous pouvez également utiliser l’agent SQL Server pour contrôler quand la taille du journal utilisé dépasse un certain seuil et exécuter une tâche de sauvegarde.
Lors des tests d’échelle, un journal de taille fixe de 4 Go a été utilisé et une alerte a été configurée pour sauvegarder le journal dans un autre fichier lorsque le fichier journal était plein à 80 %. Cela a empêché le journal de grossir et de consommer tout l’espace disque, et a également empêché la mise à zéro de l’espace disque et le blocage de la base de données.
Un exemple de tâche exécuterait un script tel que :
BACKUP LOG [CitrixXenDesktop-SiteDB] TO DISK = N'D:\LogBackup\CitrixXenDesktopSiteDB.bak' WITH NOFORMAT, NOINIT, COMPRESSION, NAME = N'Site-Transaction Log Backup', SKIP, NOREWIND, NOUNLOAD
Le compteur de performance SQL à utiliser pour l’alerte est le suivant :
SQL Server : Bases de données - Journal des pourcentages utilisés - CitrixXenDesktopSiteDB
Répétez cette opération pour chacune des 3 bases de données.
La sauvegarde du fichier journal s’est révélée avoir un impact minimal sur un environnement XenDesktop en cours d’exécution. Les délais de courtage augmentent légèrement, mais ce n’est pas quelque chose que nous pensons être significatif.
Pour plus de détails sur la configuration des tâches, consultez : https://docs.microsoft.com/en-us/sql/ssms/agent/create-a-job?view=sql-server-ver15
Pour plus de détails sur la configuration des alertes, consultez : https://docs.microsoft.com/en-us/sql/ssms/agent/alerts?view=sql-server-ver15
Maintenance de l’index
Au fur et à mesure que de plus en plus de données sont saisies dans la base de données, certains index commencent à devenir moins complets, ce qui signifie que moins d’enregistrements sont stockés dans chaque page SQL. Une page SQL fait 8 Ko. Cela entraîne une augmentation des besoins de stockage de la base de données, à la fois en mémoire et sur disque. Le maintien des index permet d’augmenter le taux de remplissage des pages, ce qui réduit les besoins en mémoire de la base de données.
Citrix recommande aux clients de configurer les plans de maintenance de manière à ce qu’ils soient exécutés tous les soirs et toutes les semaines afin de gérer les index. Les plans de maintenance peuvent simplement consister à réorganiser les index pendant la nuit pendant la semaine et à reconstruire les index le week-end.
Cette recommandation évite tout impact sur les performances lié à la reconstruction de tout index volumineux au cours des opérations quotidiennes, en particulier pour une base de données de surveillance volumineuse.
Microsoft recommande de reconstruire les index s’ils sont fragmentés à plus de 30 % et de les réorganiser s’ils sont inférieurs à 30 %. Pour plus d’informations, consultez la documentation Microsoft.
Après la réorganisation des index, les statistiques doivent également être mises à jour. Cela est particulièrement important à mesure que la base de données s’agrandit. Dans le cas contraire, certaines statistiques peuvent être médiocres et le SQL risque de générer des plans de requêtes SQL sous-optimaux.
En termes d’espace économisé, le script Microsoft ci-dessous a été exécuté sur une base de données de surveillance de 1,2 Go. Il a amélioré le remplissage des pages et libéré 300 Mo d’espace.
Scripts tiers
Microsoft
Microsoft recommande de mettre à jour les index de ses bases de données WSUS SQL à l’aide du script disponible auprès de :
En modifiant le paramètre « USE SUSDB », ce script peut également être exécuté sur des bases de données XenDesktop. Ce script suit les meilleures pratiques de Microsoft qui consistent à reconstruire les index fragmentés à plus de 30 % et à réorganiser ceux dont la taille est inférieure à 30 %. Il met ensuite à jour les statistiques de la base de données.
Ola Hallengren
Des scripts plus avancés sont également disponibles auprès de :
Ces scripts sont très appréciés par la communauté SQL Server. Plus précisément, les scripts d’index sont disponibles auprès de :
http://ola.hallengren.com/sql-server-index-and-statistics-maintenance.html
Ces scripts peuvent être utilisés pour contrôler plus finement les niveaux afin de réorganiser ou de reconstruire les index.
Configuration du serveur de test
Configuration de SQL Server
Le groupe de disponibilité SQL est composé de 3 serveurs Dell R720XD spécifiés de manière identique.
Spécification du système :
- 2 processeurs Intel Xeon E5-2630 hexagonaux cadencés à 2,30 GHz avec Hyper-Threading activé
- 64 GO DE RAM ECC
- PERC H710P Mini avec 1 Go de cache alimenté par batterie
- 26 disques durs SAS de 300 Go à 10 000 tr/min
Les disques ont été répartis dans les volumes suivants :
- Volume du système
- Contient le système d’exploitation et le fichier de page
- 2 disques en tant que miroir RAID 1
- Capacité totale 278 Go
- Volume de base de données
- Contenant les fichiers de données de l’instance SQL Server et de la base de données
- 16 disques sous forme de bande miroir RAID 10
- Capacité totale 2 231 Go
- Volume du journal
- Contenant les fichiers journaux de la base de données
- 8 disques sous forme de bande miroir RAID 10
- Capacité totale 1 115 Go
- Logiciel :
- Windows Server 2012 R2 édition standard, avec les dernières mises à jour de Windows au moment des tests (août 2014)
- SQL Server Enterprise 2012 SP2 avec mise à jour cumulative 1
- Changements de configuration
- SQL Server a été configuré pour utiliser un maximum de 61 440 Mo
- Le confinement de la base de données a été activé sur toutes les instances SQL
- Le service SQL Server Agent a été configuré pour démarrer automatiquement
- Configuration du groupe de disponibilité :
- Tous les serveurs ont été placés dans un cluster Windows Failover
- Un groupe Always On Availability a été configuré au sein du cluster.
- Les répliques secondaires ont été configurées pour être validées de manière synchrone, ce qui nécessite que les transactions soient validées sur les deux répliques avant la fin de la transaction
- Le routage des répliques en lecture seule a été configuré et activé pour le groupe de disponibilité
Delivery Controller et serveurs de test HSD
Le Delivery Controller et les serveurs de test HSD fonctionnaient sur la même configuration matérielle, à l’aide de lames HP BL460c G1. 2 serveurs ont été utilisés pour les Delivery Controller et 43 serveurs ont fourni la charge de travail HSD simulée.
Remarque : Bien que ces serveurs soient relativement anciens, la charge de travail sur les serveurs HSD est faible, car la simulation de session vise principalement à placer la charge sur les Delivery Controller, plutôt que sur les serveurs HSD.
Spécification du système :
- 2 processeurs Intel Xeon L5320 quadricœurs cadencés à 1,86 GHz, non compatibles avec la technologie Hyper-Thread
- 16 GO DE RAM ECC
- Carte RAID HP Smart Array E200I (pas de cache alimenté par batterie)
- Un disque dur SAS de 36 Go ou 72 Go
Logiciel :
- Windows Server 2012 R2 Édition Standard, avec les dernières mises à jour de Windows au moment des tests (août 2014)
- Citrix XenDesktop 7.6
Dans cet article
- Avertissement
- Vue d’ensemble
- Modifications apportées aux documents pour XenDesktop 7.6
- Considérations de haut niveau
- Dimensionnement des bases de données
- Activité de la base de données lors de l’ouverture de session de 100 000 sessions HSD
- Utilisation du processeur
- E/S sur disque
- Entretien des bases de données
- Scripts tiers
- Configuration du serveur de test