Guide de dimensionnement de base de données pour XenApp et XenDesktop versions 7.6 jusqu’à 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 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 tout ce que vous choisissez d’utiliser est exempt de virus ou d’autres éléments de nature destructrice.

Présentation

Un déploiement XenDesktop® 7 typique 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 XenDesktop
• Base de données de surveillance Stocke les données historiques pour l’affichage dans Director
• Base de données de journalisation de la configuration Suit les modifications de configuration apportées au déploiement XenDesktop

Par défaut, les bases de données de journalisation de la configuration et de surveillance (les bases de données secondaires) sont situées sur le même serveur que la base de données de configuration de site. Initialement, les trois bases de données ont 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 typique 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. Des variations entre les déploiements sont à prévoir.

Les différences de dimensionnement entre les bureaux 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 bureaux 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 pour couvrir XenDesktop 7.6. Cela a permis des mises à jour sur les modifications de dimensionnement pour les fonctionnalités ajoutées dans la version 7.6. Les trois nouvelles fonctionnalités qui ont un impact sur le dimensionnement de la base de données sont :

• Location de connexion (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 de surveillance
• Surveillance de l’inventaire des correctifs – détails des correctifs Citrix appliqués aux contrôleurs, aux VDA et aux images VDA dans l’environnement

Les informations sur le dimensionnement des tables ont été mises à jour ci-dessous. Les transactions par seconde et la croissance du journal des transactions se sont avérées similaires entre les versions 7.6 et 7.5, de sorte qu’aucune mise à jour n’a été apportée à ces sections.

Considérations générales

Base de données du site

La base de données du site contient les informations de configuration nécessaires au fonctionnement du système.

Son utilisation est caractérisée par :

• La taille maximale est atteinte pendant les heures de pointe, car 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 sessions actives et que tous les VDA sont arrêtés et désenregistrés.
• La taille maximale est atteinte après 48 heures, car la base de données stocke très peu d’informations persistantes. Ceci 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. Autrement dit, plus il y a de travailleurs et d’utilisateurs, plus l’espace de la base de données est consommé.
• Des niveaux élevés de transactions par seconde se produisent lors de l’ouverture de session, car chaque ouverture de session utilisateur nécessite l’exécution de plusieurs transactions individuelles, et l’échelle est basée sur le taux de lancement concurrent.
• Bruit de fond de faible niveau des transactions de pulsation VDA. Chaque VDA envoie une pulsation toutes les 5 minutes et cette mise à jour déclenche une transaction sur la base de données.

Impact d’une 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, le bail de connexion permet d’établir de nouvelles connexions et des reconnexions. Dans les versions antérieures, les nouvelles connexions et les reconnexions ne sont 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 les données 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.
• De faibles niveaux de transactions par seconde se produisent en raison de la nature par lots des mises à jour effectuées par le service de surveillance. Il est rare de voir le nombre de transactions par seconde dépasser la barre des 20 transactions par seconde.
• Certaines transactions en arrière-plan causé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 rétention configurée.

Impact d’une 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 dans 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, effectuées depuis Director sont enregistrées dans cette base de données, ce qui peut entraîner une croissance lente à mesure que les administrateurs utilisent Director.
• Transactions minimales sur la base de données lorsqu’aucune modification de configuration n’est effectuée.
• Un faible taux de transactions pendant les mises à jour, car les mises à jour sont regroupées lorsque cela est possible.
• La 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 rétention et ne sont pas supprimées, sauf si un administrateur le fait manuellement.

Impact d’une 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 est indisponible, 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 est indisponible, 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. Elle est utilisée comme magasin de versions pour l’isolation d’instantané validé en lecture (Read-Committed Snapshot Isolation). 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, elle ne dépasse pas 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. XenDesktop, cependant, a tendance à avoir des transactions de courte durée, ce qui aide à maintenir la taille du magasin de versions 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.

Des conseils sur le dimensionnement et la configuration de la base de données TempDB peuvent être trouvés dans la documentation produit de Microsoft :

https://docs.microsoft.com/fr-fr/sql/relational-databases/databases/tempdb-database?view=sql-server-ver15

Le principal point de contention concerne 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, consultez :

http://www.sqlskills.com/blogs/paul/a-sql-server-dba-myth-a-day-1230-tempdb-should-alwayshave-one-data-file-per-processor-core/

Isolation d’instantané de lecture validée

Citrix recommande que toutes les bases de données XenDesktop 7 utilisent l’isolation d’instantané de lecture validée. Pour plus d’informations, consultez Comment activer l’instantané de 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, y compris le nombre de sessions et de connexions créées au cours d’une journée de travail.

Une session est tout bureau ou application exécuté pendant une période donnée qui peut être déconnecté et reconnecté.

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 du site est basée sur le nombre de VDA et de sessions actives, comme suit :

Chaque application publiée ajoute 110 Ko à la base de données pour stocker chaque icône unique.

Remarque :

L’augmentation de la taille pour la version 7.6 est due au stockage des baux de connexion dans la base de données dans le cadre de la réplication entre les contrôleurs.

Base de données de surveillance

Parmi les trois bases de données, la base de données de surveillance devrait devenir la plus grande 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 à plusieurs points de données. Ces données sont une estimation basée sur les données observées lors des tests de montée en charge de XenDesktop. Les estimations sont considérées comme réalistes.

Cependant, les clients qui maintiennent 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 la 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 la cmdlet 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.

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

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

Notez que les HSD génèrent plus de données au fil du temps en raison de l’enregistrement des informations d’équilibrage de charge, mais qu’ils ont initialement une taille similaire à celle des postes de travail VDI.

Dimensionnement de la base de données de surveillance XenDesktop 7.6

Les principaux changements par rapport à la version 7.5 sont :

• Informations sur les correctifs Les données ci-dessous sont basées sur 3 correctifs par Worker (VDI ou HSD)
• Historique d’utilisation des applications Ceci est principalement pertinent pour les systèmes HSD.

Estimations avec 1 connexion et 1 session par utilisateur pour une semaine de travail de 5 jours

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

Base de données de journalisation de la configuration

Fournir des directives pour le dimensionnement de la base de données de journalisation de la configuration est beaucoup plus difficile car cela 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 journalisées et incluent, par exemple, la déconnexion et la réinitialisation de session. Les activités passives, telles que la liste des sessions d’un utilisateur, ne le sont pas.

Le mécanisme utilisé pour le déploiement des postes de travail a également un impact sur la taille des données journalisées.

Dans les environnements HSD qui n’utilisent pas MCS, la taille de la base de données tend à être 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 la journalisation de toutes les données de construction de VM.

Aucun changement significatif n’a été apporté à la base de données de journalisation de la configuration pour la version 7.6.

Activité de la base de données lors de la connexion de 100 000 sessions HSD

Lors des tests de scalabilité, simulant 100 000 connexions de sessions HSD, la croissance du journal des transactions a été mesurée sous deux taux de connexion, comme suit :

• 100 000 utilisateurs se connectant en 1 heure
• 100 000 utilisateurs se connectant en 2 heures

Ces taux ont été choisis pour fournir des points de données d’exemple.

L’environnement était composé de :

• 2 Delivery Controllers
• 43 workers HSD VDA
• 3 serveurs SQL, configurés avec les bases de données, contenus dans un groupe de disponibilité Always On

Les détails des 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:Databases – Log File(s) Used Size (KB).

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 des pulsations des services VDA et Broker.

La croissance du journal 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. Par déconnexion utilisateur, le journal des transactions augmente de 12 Ko.

Par conséquent, la croissance par jour est de 32 Ko par cycle de connexion/déconnexion utilisateur.

Surveillance de la base de données

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.

La croissance du journal est linéaire sur la période mesurée. Ces données suggèrent que par connexion utilisateur, le journal des transactions augmente de 7 Ko. Par déconnexion utilisateur, le journal des transactions augmente de 2 Ko.

Par conséquent, la croissance quotidienne est de 9 Ko par cycle de connexion/déconnexion 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 performances suivants :

• SqlServer:Bases de données – Transactions/seconde
• SqlServer:Bases de données – Transactions d’écriture/seconde

Base de données du site

Lorsque le système est inactif, il y a 5 transactions/seconde, dont 1 transaction d’écriture/seconde maintient les signaux de vie des VDA et des Brokers.

Remarque : Ces chiffres sont des estimations basées sur les périodes données. La charge exacte varie en fonction du nombre de lancements simultanés par seconde.

Base de données de supervision

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 de transactions est cependant 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 d’activité, la surcharge augmente à mesure que davantage de travail est effectué.

Remarque : Ces chiffres sont des estimations basées sur les périodes données.

Utilisation du CPU

Tous les serveurs SQL utilisés pour ces tests étaient des serveurs double hexacœur 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 par rapport à la charge exécutée. Cela nous a permis d’identifier les limitations et les maximums imposés au matériel. Il est prévu que la charge CPU SQL aurait pu être gérée par un serveur SQL avec un seul quadricœur, plutôt qu’un système double hexacœur.

Pendant les tests, le CPU du système a été surveillé à l’aide du compteur du moniteur de performances Processeur – % Temps processeur – _Total.

Réplique principale

Au repos, le CPU fonctionnait à 0-2% du CPU disponible. Les procédures stockées de consolidation ont provoqué des pics chaque minute pendant environ 1 seconde, atteignant 8-10% du CPU système. On s’attend à ce que cela évolue en fonction de la quantité de données traitées.

Lors de la connexion de 100 000 utilisateurs en 1 heure, le CPU a bondi à 7% et a augmenté linéairement jusqu’à 11% à mesure que davantage de sessions et d’utilisateurs étaient présents dans l’environnement. Notez que les pics des procédures stockées de consolidation ont ajouté 7% au CPU total, faisant atteindre aux pics 18% du CPU.

Lors de la déconnexion, le CPU fonctionnait à 3,5%, avec 7% de CPU supplémentaire pour les procédures stockées de consolidation. Globalement, cela suggère que <20% d’un double hexacœur était nécessaire pour maintenir le taux de connexion et de déconnexion.

Remarque : Le planificateur de Windows Server 2012 a tendance à n’utiliser les hyper-threads que si nécessaire, c’est-à-dire que tant que le système n’atteint pas 50% de charge, il n’exécute qu’un seul thread par cœur lorsque cela est possible, donc une charge de 20% sur 24 hyper-threads s’exécute sur 4,8 cœurs.

Compte tenu de la charge de travail, on estime qu’il s’agit d’un test de stress intense, et qu’un seul serveur SQL quadricœur serait adéquat pour les déploiements XenDesktop.

Répliques secondaires

Les répliques secondaires ont été configurées pour utiliser 2% du CPU pendant la connexion et 1,5% pendant la déconnexion. Cela est prévisible car, pour la plupart, les répliques stockent les données de la réplique principale sur leurs disques, et seule la réplique synchrone est impliquée dans les transactions, car la réplique principale ne valide pas une transaction tant que la réplique secondaire ne l’a pas reconnue.

Selon les recommandations pour que le matériel HA corresponde à la réplique principale, cette charge serait gérée très facilement par un serveur aux spécifications similaires.

Utilisation de la base de données temporaire

La TempDB est utilisée à de nombreuses fins, notamment pour le magasin de versions, l’espace pour les grands ensembles de requêtes et d’autres utilisations de tables temporaires.

Dimensionnement de la TempDB

Dans cette configuration SQL, la TempDB a été configurée pour avoir 8 fichiers de base de données, chacun d’une taille fixe de 5 Go. Cela permet une meilleure utilisation concurrente de la TempDB, mais fournit également beaucoup d’espace et ne déclenche aucun événement d’agrandissement automatique. D’après les données collectées, elle était surdimensionnée pour ce déploiement. Il y avait, cependant, beaucoup d’espace disque disponible.

Elle respecte également les directives générales selon lesquelles le nombre de fichiers de base de données TempDB doit être compris entre un quart et la moitié du nombre de CPU disponibles, sans toutefois dépasser 8 sans qu’il y ait de contention réelle connue.

Notez qu’un seul fichier journal TempDB est utilisé, car SQL Server ne tire pas avantage de plusieurs fichiers journaux.

Magasin de versions

La TempDB contient un magasin de versions pour les versions de lignes liées à l’isolation d’instantané de lecture validée (Read Committed Snapshot Isolation) utilisée par les bases de données XenDesktop.

L’utilisation peut être mesurée par les 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 des versions (Ko/s)

Lors de 100 000 connexions sur 1 heure, la taille du magasin de versions est restée dans la plage de 10 Mo à 30 Mo, avec un effet en dents de scie à mesure que les versions étaient créées puis nettoyées. Lors de la déconnexion, la plage était de 10 Mo à 21 Mo. Au repos, la taille du magasin de versions variait de 1 Mo à 4 Mo.

Le taux de génération des versions était dans la plage de 250 à 500 Ko lors de la connexion ; de 150 à 400 Ko/s lors de la déconnexion, et de 0 à 250 Ko/s au repos.

Le nettoyage des versions s’exécute une fois par minute et a atteint 2 500 Ko/s lors de la connexion, 1 750 Ko/s lors de la déconnexion et 400 Ko/s pendant les périodes d’inactivité.

E/S disque

Pendant les tests de connexion, les E/S disque ont été mesurées à l’aide des compteurs de performance suivants :

• PhysicalDisk – Octets lus par seconde du disque
• PhysicalDisk – Octets écrits par seconde du disque
• PhysicalDisk – Lectures disque/seconde
• PhysicalDisk – Écritures disque/seconde

Les E/S de lecture se sont avérées minimales, car le serveur SQL était capable de conserver toutes les données en mémoire, ce qui a entraîné 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 de transactions.

Les données montrent un modèle difficile à représenter dans un tableau. En général, le journal des transactions avait un débit d’octets d’écriture par seconde de 800 Ko/s pour le test d’une heure et de 400 Ko/s pour le test de deux heures. Une fois par minute, lorsque les procédures stockées de consolidation s’exécutent, le journal des transactions a montré des pics allant jusqu’à 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 une table temporaire déborde 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) en écriture pour le test d’une heure, et de 200 IOPS en écriture pour le test de deux heures. Les pics des procédures stockées de consolidation ajoutent 2 à 300 IOPS en écriture supplémentaires pendant leur exécution. Notez que dans un environnement étendu, les procédures stockées de consolidation s’exécutent en moins d’une seconde.

Lorsque chaque base de données est soumise à un point de contrôle, les données sont synchronisées des tables en mémoire vers les fichiers de données sur le 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 seconde.

Pendant la connexion, les points de contrôle ont consommé 6 à 7 Mo/s et 500 IOPS en écriture. Pendant la déconnexion, les points de contrôle ont consommé 7 Mo/s, avec une plage de 200 à 700 IOPS. Les chiffres varient car les bases de données de site et de surveillance ont des quantités de données différentes à contrôler.

Maintenance de la base de données

La maintenance de la base de données dans un déploiement important est cruciale. Si la base de données n’est pas correctement maintenue, des pannes peuvent survenir en raison d’un manque d’espace de base de données, par exemple, si le journal des transactions est configuré pour s’étendre automatiquement et remplit le disque, ou si le journal des transactions a 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, les groupes de disponibilité Always On ou la mise en miroir de bases de données, les bases de données XenDesktop fonctionnent en mode de journalisation des transactions complète.

En fonctionnant en mode de journalisation des transactions complète, 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 des transactions ne sont pas surveillés car, par défaut, SQL Server configure les fichiers journaux pour s’étendre automatiquement. Cela provoque 2 problèmes :

1. Les fichiers journaux des transactions peuvent consommer beaucoup d’espace disque.
2. Chaque fois que le journal des transactions s’agrandit, il bloque toutes les transactions jusqu’à ce que l’espace du journal ait été mis à zéro.

Citrix recommande que les fichiers journaux soient sauvegardés régulièrement. Cela peut être fait avec des tâches planifiées ou des plans de maintenance.

Alternativement, utilisez l’Agent SQL Server pour surveiller quand la taille utilisée du journal dépasse un seuil et exécutez une tâche de sauvegarde.

Lors des tests de charge, 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 atteignait 80 % de sa capacité. Cela a empêché le journal de croître 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 :

SQLServer:Databases - Percent Log Used - CitrixXenDesktopSiteDB

Répétez cette opération pour chacune des 3 bases de données.

Il a été constaté que la sauvegarde du fichier journal avait un impact minimal sur un environnement XenDesktop en cours d’exécution ; il y a une légère augmentation des temps de courtage, mais nous ne pensons pas que cela soit significatif.

Pour plus de détails sur la configuration des tâches, consultez : https://docs.microsoft.com/fr-fr/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/fr-fr/sql/ssms/agent/alerts?view=sql-server-ver15

Maintenance des index

À mesure que davantage de données sont saisies dans la base de données, certains index deviennent moins remplis, c’est-à-dire 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, tant en mémoire que sur disque. En maintenant les index, le remplissage des pages peut être augmenté, ce qui réduit les exigences de mémoire de la base de données.

Citrix recommande aux clients de configurer des plans de maintenance à exécuter toutes les nuits et toutes les semaines pour maintenir les index. Les plans de maintenance peuvent simplement consister à réorganiser les index pendant la nuit en semaine et à les reconstruire le week-end.

Cette recommandation permet d’éviter tout impact sur les performances lié à la reconstruction d’index volumineux pendant les opérations quotidiennes, en particulier pour une base de données de surveillance importante.

Microsoft recommande de reconstruire les index s’ils sont fragmentés à plus de 30 % et de les réorganiser s’ils le sont à moins de 30 %. Pour plus d’informations, consultez la documentation Microsoft.

Après avoir réorganisé les index, les statistiques doivent également être mises à jour. C’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 é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 SQL WSUS à l’aide du script disponible à l’adresse :

https://learn.microsoft.com/fr-fr/troubleshoot/mem/configmgr/update-management/reindex-the-wsus-database

En modifiant le « USE SUSDB », ce script peut également être exécuté sur les bases de données XenDesktop. Ce script suit les meilleures pratiques de Microsoft en matière de reconstruction des index fragmentés à plus de 30 % et de réorganisation de ceux fragmentés à 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 :

http://ola.hallengren.com/

Ces scripts sont très appréciés dans la communauté SQL Server. Plus précisément, les scripts d’index sont 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 des niveaux de réorganisation ou de reconstruction des index.

Configuration du serveur de test

Configuration de SQL Server

Le groupe de disponibilité SQL était composé de 3 serveurs Dell R720XD configurés de manière identique.

Spécifications du système :

• 2 processeurs Intel Xeon E5-2630 hexacœurs cadencés à 2,30 GHz avec hyper-threading activé
• 64 Go de RAM ECC
• PERC H710P Mini avec 1 Go de cache protégé par batterie
• 26 disques SAS de 300 Go à 10 000 tr/min

Les disques ont été répartis dans les volumes suivants :

• Volume système
  • Contenant le système d’exploitation et le fichier d’échange
  • 2 disques en miroir RAID 1
  • Capacité totale 278 Go
• Volume de la base de données
  • Contenant l’instance SQL Server et les fichiers de données de la base de données
  • 16 disques en bande miroir RAID 10
  • Capacité totale 2 231 Go
• Volume de journaux
  • Contenant les fichiers journaux de la base de données
  • 8 disques en bande miroir RAID 10
  • Capacité totale 1 115 Go
• Logiciel :
  • Windows Server 2012 R2 édition standard, avec les mises à jour Windows actuelles au moment des tests (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 SQL Server Agent a été configuré pour démarrer automatiquement
• Configuration du groupe de disponibilité :
  • Tous les serveurs ont été placés au sein d’un cluster de basculement Windows
  • Un groupe de disponibilité Always On a été configuré au sein du cluster
  • Les réplicas secondaires ont été configurés pour être en validation synchrone, exigeant que les transactions soient validées sur les deux réplicas avant que la transaction ne se termine
  • Le routage des réplicas en lecture seule a été configuré et activé pour le groupe de disponibilité

Serveurs de test Delivery Controller™ et HSD

Les serveurs de test Delivery Controller et HSD fonctionnaient sur la même configuration matérielle, utilisant des lames HP BL460c G1. 2 serveurs ont été utilisés pour les Delivery Controllers, 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 est principalement axée sur la charge des Delivery Controllers, plutôt que sur les serveurs HSD.

Spécifications du système :

• 2 Intel Xeon L5320 quad-core cadencés à 1,86 GHz, non compatibles hyper-threading
• 16 Go de RAM ECC
• Carte RAID HP Smart Array E200I (pas de cache avec batterie de secours)
• Un disque dur SAS de 36 Go ou 72 Go

Logiciel :

• Windows Server 2012 R2 Standard Edition, avec les mises à jour Windows actuelles au moment des tests (août 2014)
• Citrix XenDesktop 7.6