Guide de dimensionnement de base de données pour XenApp et XenDesktop versions 7.6 à la version actuelle
Clause d’exclusion de responsabilité
Ce document contient des liens vers des sites Web contrôlés par des parties autres que Citrix. Citrix n’est pas responsable du contenu ou de l’utilisation de ces sites Web tiers et n’approuve pas ou n’accepte aucune responsabilité. Citrix vous fournit ces liens uniquement à titre 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 ce que vous choisissez pour votre utilisation est exempt de virus ou d’autres éléments de nature destructrice.
Vue d’ensemble
Un déploiement XenDesktop 7 typique se compose de trois bases de données, comme suit :
- Base de données de configuration du site
Stocke la configuration actuelle et l’état du déploiement XenDesktop - Base de données de surveillance
Stocke les données historiques à afficher dans Director - Journalisation de la configuration Base de données
Suit les modifications de configuration apportées au déploiement 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. Initialement, les trois bases de données ont le même nom. Citrix vous recommande vivement de modifier l’emplacement des bases de données secondaires après la création d’un site.
Un déploiement typique utilise également la base de données temporaire, TempDB, fournie par SQL Server.
Chaque base de données a un but différent et se développe à 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.
Note : Tous les chiffres fournis sont des estimations. Il faut s’attendre à des variations entre les déploiements.
Les différences de taille entre les postes de travail partagés hébergés (HSD) et l’infrastructure de bureau virtuel (VDI) sont également notées dans ce document. Les environnements mixtes devront combiner les estimations des deux types de postes de travail pour générer une estimation de la taille globale de la base de données.
Modifications du document pour XenDesktop 7.6
Ce document a été étendu à la section 7.6 XenDesktop. Cela devait permettre des mises à jour sur les modifications de taille des fonctions ajoutées dans 7.6. Les trois nouvelles fonctionnalités qui ont un impact sur le dimensionnement de la base de données sont les suivantes :
- Connection Leasing : les fichiers de bail 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, VDA et images VDA dans l’environnement
Les informations sur le dimensionnement du tableau ont été mises à jour ci-dessous. La croissance des transactions par seconde et du journal des transactions était semblable dans 7,6 à 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 l’exécution du système.
Son utilisation est caractérisée par :
- La taille maximale est atteinte pendant les heures de pointe lorsque les ouvertures de session des utilisateurs génèrent des informations de session et de connexion à suivre.
- La taille minimale est atteinte lorsqu’il n’y a pas de session active et que les VDA sont tous arrêtés et non enregistrés.
- La taille maximale est atteinte après 48 heures, car la base de données stocke très peu d’informations persistantes. Cela est dû au fait qu’un petit journal des connexions est conservé dans la base de données du site pendant 48 heures.
- La taille de ligne de base de données augmente à mesure que les informations de configuration d’un site augmentent. Cela signifie que davantage 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 pendant l’ouverture de session, car chaque ouverture de session utilisateur nécessite plusieurs transactions individuelles et évolue en fonction du taux de lancement simultané.
- Bruit de fond de faible niveau des transactions de pulsation VDA. Chaque VDA fournit un rythme cardiaque une fois toutes les 5 minutes et cette mise à jour déclenche une transaction sur la base de données.
Impact de la défaillance
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 de créer de nouvelles connexions et reconnexions. Dans les versions précédentes, de nouvelles connexions et reconnexions ne sont pas possibles.
Base de données de contrôle
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 est caractérisée 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 valeur 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.
- La taille maximale peut prendre un certain temps à atteindre, car le système doit atteindre la période de rétention configurée.
- Des niveaux faibles de transactions par seconde se produisent en raison de la nature par lots des mises à jour par le service de surveillance. Il est rare de voir les transactions par seconde passer les 20 transactions par seconde.
- Certaines transactions en arrière-plan causées par des appels de consolidation réguliers du service de surveillance.
- Le traitement du jour au lendemain est effectué pour supprimer les données en dehors de la période de rétention configurée.
Impact de la défaillance
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 au sein de Director.
Base de données de journalisation de la configuration
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 est caractérisée par :
- La taille maximale est difficile à prévoir car elle dépend de l’activité de configuration.
- Toutes les actions, par exemple, la réinitialisation de session, à partir de Director sont consignées dans cette base de données, de sorte qu’il peut y avoir une croissance lente lorsque les administrateurs utilisent Director.
- Transactions minimales se produisant sur la base de données lorsqu’aucune modification de configuration n’est apportée.
- Un faible taux de transaction pendant les 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 stratégie de rétention et ne sont pas supprimées, sauf si elles sont effectuées manuellement par un administrateur.
Impact de la défaillance
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 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 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 de snapshots en lecture. XenDesktop 7 utilise cette fonctionnalité SQL Server pour réduire la contention 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 dépasse pas quelques MBs.
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. XenDesktop, cependant, a tendance à avoir des transactions de courte durée, ce qui permet de garder la taille du magasin de version petite.
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 :
La zone principale de conflit est centrée sur le nombre de fichiers à utiliser. Les anciennes versions de SQL Server, telles que SQL Server 2000, nécessitent plus de fichiers que les versions plus récentes. Pour plus d’informations sur le nombre de fichiers à utiliser, voir :
Isolation de cliché validée en lecture
Citrix recommande que toutes les bases de données XenDesktop 7 utilisent l’isolation de snapshots validés en lecture. Pour plus d’informations, consultez How to Enable Read-Committed Snapshot in 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 exécutée pendant une période de temps qui peut être déconnecté et reconnecté à.
Une connexion est une 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 :
| Utilisateurs | Applications | Type | Taille de crête prévue 7,5 (Mo) | Taille de crête 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 | S.O. | VDI | 30 | 30 |
| 10 000 | S.O. | VDI | 115 | 121 |
| 40 000 | S.O. | 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 7.6 est due au fait que les baux 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 contrôle
Parmi les trois bases de données, on s’attend à ce que la base de données de surveillance devienne la plus importante au fil du temps.
Sa taille dépend de nombreux facteurs, y compris les suivants :
- Nombre d’utilisateurs
- Nombre de sessions
- Nombre de connexions
- Tâches VDI ou HSD
- Période de rétention configurée
Voici 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 vues lors du test de mise à l’échelle XenDesktop. On estime que les estimations sont réalistes.
Toutefois, les clients qui tiennent à jour leur base de données peuvent constater que leur base de données est plus petite que les estimations.
Les utilisateurs HSD sont basés sur 100 utilisateurs par serveur HSD.
Périodes de rétention 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 des données illimité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 plus anciennes que la période de rétention configurée, elles sont supprimées de la base de données.
Taille 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
| Utilisateurs | Type | 1 semaine (Mo) | 1 mois (Mo) | 3 mois (Mo) | 1 an (Mo) |
|---|---|---|---|---|---|
| 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
| 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 |
Notez que les HSD génèrent plus de données au fil du temps en raison de la journalisation des informations d’équilibrage de charge, mais sont initialement d’une taille similaire à celle des postes de travail VDI.
XenDesktop 7.6 Surveillance du dimensionnement de la base de données
Les principaux changements par rapport à 7.5 sont :
- Informations sur les correctifs
Les données ci-dessous sont basées sur 3 correctifs par tâche (VDI ou HSD) - Historique de l’utilisation des applications
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
| Utilisateurs | Type | 1 semaine (Mo) | 1 mois (Mo) | 3 mois (Mo) | 1 an (Mo) |
|---|---|---|---|---|---|
| 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
| Utilisateurs | Type | 1 semaine (Mo) | 1 mois (Mo) | 3 mois (Mo) | 1 an (Mo) |
|---|---|---|---|---|---|
| 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 de journalisation de la configuration
Il est beaucoup plus difficile de fournir des conseils pour dimensionner la base de données de journalisation de la configuration car elle 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 comprennent, par exemple, la fermeture de session et la réinitialisation. Les activités passives, telles que la liste des sessions d’un utilisateur, ne le sont pas.
Le mécanisme utilisé pour déployer des 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 tend à se situer 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 la journalisation de toutes les données de construction de machines virtuelles.
Aucune modification significative n’a été apportée à la base de données de journalisation de la configuration 7.6.
Activité de base de données lors de l’ouverture de session de 100 000 sessions HSD
Pendant les tests d’évolutivité, simulant 100 000 ouvertures de session 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 plus d’une heure
- 100 000 utilisateurs se connectent plus de 2 heures
Ces taux ont été choisis pour fournir des exemples de points de données.
L’environnement comprend :
- 2 Delivery Controller
- 43 tâches HSD VDA
- 3 serveurs SQL, configurés avec les bases de données, conservés dans un groupe de disponibilité Always On
Des détails sur les configurations de serveur 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 du moniteur de performances SQLServer : Bases de données — Fichier (s) journal (s) utilisé (s) Taille (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 cardiaques VDA et Broker Service.
| Tester | Croissance totale de l’ouverture de session (Mo) | Croissance totale de la fermeture de session (Mo) |
|---|---|---|
| 100k sur 1 heure | 1 900 | 1 150 |
| 100k sur 2 heures | 1 900 | 1 150 |
La croissance du log est linéaire sur la période mesurée. Ces données suggèrent que, par ouverture de session utilisateur, le journal des transactions augmente de 20 Ko. Par fermeture de session utilisateur, le journal des transactions augmente de 12 Ko.
Par conséquent, la croissance par jour est de 32 Ko par cycle d’ouverture de session utilisateur et de fermeture de session.
Base de données de contrôle
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.
| Tester | Croissance totale de l’ouverture de session (Mo) | Croissance totale de la fermeture de session (Mo) |
|---|---|---|
| 100 000 sur 1 heure | 670 | 190 |
| 100 000 sur 2 heures | 650 | 220 |
La croissance logarithmique est linéaire sur la période mesurée. Ces données suggèrent que par ouverture de session utilisateur, le journal des transactions augmente de 7 Ko. Par fermeture de session utilisateur, le journal des transactions augmente de 2 Ko.
Par conséquent, la croissance par jour est de 9 Ko par cycle d’ouverture de session utilisateur et de fermeture de session.
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 surveillance de performances suivants :
- SQLServer : Bases de données — Transactions/seconde
- SQLServer : Bases de données — Écriture de transactions/seconde
Base de données du site
Lorsque le système est inactif, il y a 5 transactions/seconde dont 1 Write Transaction/seconde maintient les battements cardiaques VDA et Broker.
Note : Ces chiffres sont des estimations tirées des périodes indiquées. La charge exacte varie en fonction du nombre de lancements simultanés par seconde.
| Tester | Transactions d’ouverture de session par seconde | Transactions d’écriture d’ouverture de session par seconde | Transactions de fermeture de session par seconde | Transactions d’écriture de fermeture de session par seconde |
|---|---|---|---|---|
| 100 000 sur 1 heure | 870 | 310 | 250 | 100 |
| 100 000 sur 2 heures | 475 | 170 | 140 | 60 |
Base de données de contrôle
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. Toutefois, le niveau des transactions est faible. En général, il existe 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 de plus en plus de travaux sont effectués.
Note : Ces chiffres sont des estimations tirées des périodes indiquées.
| Tester | Transactions d’ouverture de session par seconde | Transactions d’écriture d’ouverture de session par seconde | Transactions de fermeture de session par seconde | Transactions d’écriture de fermeture de session par seconde |
|---|---|---|---|---|
| 100 000 sur 1 heure | 4 | 2 | 4 | 2 |
| 100 000 sur 2 heures | 4 | 2 | 3.5 | 2 |
Utilisation UC
Tous les serveurs SQL utilisés pour ce test étaient des serveurs hex-core double avec hyper-threading activé. Les spécifications matérielles exactes sont fournies à la fin de ce document.
Les serveurs étaient connus pour être surdimensionnés pour la charge en cours d’exécution. Cela nous a permis d’identifier les limites et maximums placés sur le matériel. Il est prévu que la charge CPU SQL aurait pu être gérée par un serveur SQL avec un seul quad-core, plutôt qu’un système double hex-core.
Pendant les tests, la CPU système a été surveillée à l’aide du compteur de moniteur de performances Processeur — % Processor Time —_Total.
Réplica principal
Alors que le processeur inactif fonctionnait à 0- 2% de la CPU disponible. Les procédures stockées de consolidation ont provoqué des pics toutes les minutes pendant ~ 1s à 8- 10% de la CPU du système. On s’attend à ce que ce chiffre évolue en fonction de la quantité de données traitées.
Au cours de l’ouverture de session de 100 000 utilisateurs en 1 heure, le processeur a bondi à 7 % et a augmenté linéairement à 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 % à la CPU totale, entraînant les pics atteignant 18 % du CPU.
Pendant la fermeture de session CPU a fonctionné à 3,5%, avec 7% CPU supplémentaire pour les procédures stockées de consolidation. Dans l’ensemble, cela suggère que < 20 % d’un double cœur était nécessaire pour maintenir le taux d’ouverture de session et de fermeture de session.
Remarque : Le Planificateur Windows Server 2012 utilise uniquement les hyper-threads si nécessaire, c’est-à-dire jusqu’à ce que le système atteigne 50 % de charge, il n’exécute qu’un thread par cœur si possible, de sorte qu’une charge de 20 % sur 24 hyper-threads 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 stress lourd et qu’un serveur SQL quad-core unique serait approprié pour les déploiements XenDesktop.
Réplicas secondaires
Les réplicas secondaires ont été trouvés pour configurer 2% CPU pendant l’ouverture de session et 1,5% pendant la fermeture de session. Ceci est à prévoir car, pour la plupart, les réplicas stockent des données à partir du primaire sur leurs disques, et seul le réplica synchrone est impliqué dans les transactions, car le réplica principal ne valide pas une transaction tant que le secondaire l’a reconnu.
Sur la base des recommandations pour que le matériel HA corresponde au réplica principal, cette charge serait très facilement gérée 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, y compris la banque de versions, l’espace pour les jeux de requêtes volumineux et 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. Sur la base des données capturées, il a été surdimensionné pour ce déploiement. Il y avait cependant beaucoup d’espace disque disponible.
Il suit également les indications générales selon lesquelles le nombre de fichiers de base de données TempDB est compris entre un quart et la moitié du nombre de CPU disponibles, mais ne dépasse pas 8 sans savoir qu’il existe une contestation réelle.
Notez qu’un seul fichier journal TempDB est utilisé, car SQL Server ne bénéficie pas de plusieurs fichiers journaux.
Magasin de versions
TempDB contient un magasin de versions pour les versions de lignes liées à l’isolement d’instantané validé en lecture 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 de version (Ko/s)
- SQLServer : Transactions — Taux de génération de versions (Ko/s)
Pour 100 000 ouvertures de session sur une 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 ont été créées puis nettoyées. Pendant la fermeture de session, la plage était de 10 Mo à 21 Mo. En cas d’inactivité, la taille du magasin de versions variait de 1 Mo à 4 Mo.
Le débit de génération de version se situait dans la plage de 250 à 500 Ko pendant l’ouverture de session, de 150 à 400 Ko/s pendant la fermeture de session et de 0 à 250 Ko/s lorsqu’il est inactif.
Le nettoyage de version s’exécute une fois par minute et atteint 2 500 Ko/s pendant 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 disque
Au cours des tests d’ouverture de session, les E/S de disque ont été mesurées avec les compteurs de performance suivants :
- PhysicalDisk — Octets de lecture de disque/seconde
- PhysicalDisk — Octets d’écriture de disque/seconde
- PhysicalDisk — Lectures de disque/seconde
- PhysicalDisk — Écritures de disque/seconde
Les E/S de lecture ont été jugées minimales, car le serveur SQL a pu contenir toutes les données en mémoire, provoquant 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 volume contenant tous les fichiers journaux des transactions.
Les données montrent un motif difficile à placer dans une table. En général, le journal des transactions avait un octet d’écriture 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 s’exécutent, le journal des transactions affichait des pics atteignant 30 Mo/s.
L’analyse des procédures stockées de consolidation montre que parfois les statistiques rendent le plan de requête sous-optimal et qu’une table temporaire se déverse dans TempDB. Cela déclenche les é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) en écriture pour le test d’une heure et de 200 E/S par seconde pour le test de 2 heures. Les pics des procédures stockées de consolidation ajoutent 2 à 300 E/S par seconde lors de l’exécution. Notez que dans un environnement volumineux, 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 à partir des tables en mémoire vers les fichiers de données du volume de données.
Pour plus d’informations sur les points 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 à 1.
Pendant l’ouverture de session, les points de contrôle ont consommé 6 à 7 Mo/s et 500 E/S par seconde en écriture. Pendant la fermeture de session, les points de contrôle ont consommé 7 Mo/s, variant entre 200 et 700 E/S par seconde. Les chiffres varient parce que les bases de données Site et Monitoring ont des quantités différentes de données au point de contrôle.
Maintenance de la base de données
La maintenance de la base de données dans un déploiement important est importante. Si la base de données n’est pas correctement gérée, des pannes de base de données peuvent se produire en raison d’un manque d’espace dans la base de données, par exemple si le journal des transactions est configuré pour autogrow et remplit le disque, ou si le journal des transactions est d’une taille fixe et devient plein.
Maintenance du journal des transactions
Lors de l’utilisation des fonctionnalités de haute disponibilité de SQL Server, par exemple, Groupes de disponibilité Always On ou Mise en miroir de bases de données, les bases de données XenDesktop s’exécutent en mode de journalisation complète des transactions.
En s’exécutant en mode de journalisation complète des transactions, le journal des transactions continue de croître jusqu’à ce qu’une sauvegarde de base de données ou de journal des transactions soit effectuée.
Cela peut provoquer 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 une croissance automatique. Cela provoque 2 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 ait été réduit à zéro.
Citrix recommande que les fichiers journaux soient sauvegardés régulièrement. Cela peut être fait avec des travaux planifiés ou des plans de maintenance.
Vous pouvez également utiliser l’agent SQL Server pour surveiller lorsque la taille utilisée du journal dépasse un seuil et exécuter une tâche de sauvegarde.
Dans les tests d’échelle, un journal de taille fixe de 4 Go a été utilisé, et une alerte a été définie pour sauvegarder le journal dans un autre fichier lorsque le fichier journal a atteint 80 % de volume. Cela a empêché le journal de croître et de consommer tout l’espace disque, et a également arrêté la réduction à zéro de l’espace disque et le blocage de la base de données.
Un exemple de travail 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 performances SQL à utiliser pour l’alerte est :
SQLServer : Bases de données - Percent journal utilisé - CitrixXenDesktopSiteDB
Répétez cette opération pour chacune des 3 bases de données.
La sauvegarde du fichier journal a été jugée avoir un impact minimal sur un environnement XenDesktop en cours d’exécution, il y a une augmentation marginale des temps de courtage, mais pas quelque chose que nous pensons être significatif.
Pour plus d’informations sur la configuration des tâches, voir :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
Lorsque plus de données sont entrées dans la base de données, certains des index commencent à devenir moins complets, c’est-à-dire moins d’enregistrements sont stockés dans chaque page SQL. Une page SQL est de 8 Ko. La base de données augmente ainsi ses besoins de stockage, tant en mémoire que sur disque. En conservant les index, la plénitude de la page peut être augmentée, ce qui réduit les besoins en mémoire de la base de données.
Citrix recommande que les plans de maintenance de la configuration des clients soient exécutés tous les soirs et toutes les semaines pour 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 les fins de semaine.
Cette recommandation évite tout impact sur les performances de la reconstruction d’index volumineux pendant les opérations quotidiennes, en particulier pour une base de données de surveillance de grande taille.
Microsoft recommande que les index soient reconstruits s’ils sont fragmentés de plus de 30 % et réorganisés s’ils sont inférieurs à 30 %. Pour plus d’informations, consultez la documentation Microsoft.
Après réorganisation des index, les statistiques devraient également être mises à jour. Ceci est particulièrement important à mesure que la base de données se développe ; sinon certaines statistiques peuvent être médiocres et SQL peut générer des plans de requête SQL sous-optimaux.
En termes d’espace enregistré, 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 de la page et libéré 300 Mo d’espace.
Scripts tiers
Microsoft
Microsoft recommande la mise à jour des index pour leurs bases de données SQL WSUS à l’aide du script disponible à partir de :
http://gallery.technet.microsoft.com/scriptcenter/6f8cde49-5c52-4abd-9820-f1d270ddea61
En modifiant le « USE SUSDB », ce script peut également être exécuté sur des bases de données XenDesktop. Ce script suit les meilleures pratiques de Microsoft consistant à reconstruire des index fragmentés de plus de 30 % et à réorganiser ceux de moins de 30 %. Il met ensuite à jour les statistiques de la base de données.
Ola Hallengren
Des scripts plus avancés sont également disponibles à partir de :
Ces scripts sont bien considérés dans la communauté SQL Server. Plus précisément, les scripts Index disponibles à partir de :
http://ola.hallengren.com/sql-server-index-and-statistics-maintenance.html
Ces scripts peuvent être utilisés pour un contrôle plus précis sur les niveaux pour réorganiser ou reconstruire les index.
Configuration du serveur de test
Configuration de SQL Server
Le groupe de disponibilité SQL comprend 3 serveurs Dell R720XD spécifiés de manière identique.
Spécification du système :
- 2 CPU Intel Xeon Hex-core E5-2630 fonctionnant à 2,30 GHz avec hyper-threading activé
- 64 GO DE RAM ECC
- PERC H710P Mini avec 1 Go de mémoire cache avec batterie
- 26 disques durs SAS à 10 000 tr/min 300 Go
Les disques ont été divisés en volumes suivants :
- Volume système
- Contenant le système d’exploitation et le fichier de page
- 2 disques comme miroir RAID 1
- Capacité totale 278 Go
- Volume de base de données
- Contenant l’instance SQL Server et les fichiers de données de 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 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 mises à jour Windows actuelles au moment du test (août 2014)
- SQL Server Enterprise 2012 SP2 avec mise à jour cumulative 1
- Modifications 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 Agent SQL Server a été configuré pour démarrer automatiquement
- Configuration du groupe de disponibilité :
- Tous les serveurs ont été placés dans un cluster de basculement Windows
- Un groupe de disponibilité Always On a été configuré dans le cluster
- Les réplicas secondaires ont été configurés pour être commit synchrone, exigeant que les transactions soient validées sur les deux réplicas avant la fin de la transaction
- Le routage du réplica 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 des lames HP BL460c G1. Deux 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 se concentre principalement sur la charge sur les Delivery Controller plutôt que sur les serveurs HSD.
Spécification du système :
- 2 processeurs Intel Xeon L5320 quatre cœurs fonctionnant à 1,86 GHz, non compatibles hyper-thread
- 16 GO DE RAM ECC
- Carte Raid HP Smart Array E200I (pas de cache avec batterie)
- Disque dur SAS de 36 Go ou 72 Go
Logiciel :
- Windows Server 2012 R2 Édition Standard, avec mises à jour Windows actuelles au moment du test (août 2014)
- Citrix XenDesktop 7.6
Dans cet article
- Clause d’exclusion de responsabilité
- Vue d’ensemble
- Modifications du document pour XenDesktop 7.6
- Considérations de haut niveau
- Dimensionnement des bases de données
- Activité de base de données lors de l’ouverture de session de 100 000 sessions HSD
- Utilisation UC
- E/S disque
- Maintenance de la base de données
- Scripts tiers
- Configuration du serveur de test