Bases de données SQL Server et CVAD

Microsoft SQL Server est un élément important de tout déploiement de Citrix Virtual Apps and Desktops (CVAD). Planifier et comprendre les interactions Citrix SQL est très bénéfique pour vous et votre organisation afin de maintenir un environnement Citrix sain et performant. L’absence de haute disponibilité de SQL Server et de ressources informatiques importantes aura un effet négatif sur l’expérience utilisateur et la disponibilité de l’infrastructure Citrix.

Résumé de base de données

Trois bases de données sont requises/créées lors du déploiement de Citrix Virtual Apps and Desktops :

Site : (également connu sous le nom de configuration du site) stocke la configuration du site en cours, ainsi que les données dynamiques relatives au courtage, telles que l’état actuel de la session, la connexion, le chargement et les informations sur l’état de Virtualy Delivery Agent (VDA).

Journalisation de la configuration : (également appelée Journalisation) stocke des informations sur les modifications apportées à la configuration du site et les activités administratives. Cette base de données est utilisée lorsque la fonction Journalisation de la configuration est activée (valeur par défaut=activée).

Contrôle : stocke les données utilisées par Director, telles que les informations de session et de connexion.

Lorsque Citrix Virtual Apps and Desktops est installé, les administrateurs créent les bases de données lors de la configuration initiale du site (via Studio ou en exécutant des scripts sur SQL Server) et elles sont divisées en trois bases de données distinctes.

Pour les environnements dotés de bases de données de surveillance volumineuses, la configuration idéale consiste à héberger la base de données de surveillance sur un serveur différent des bases de données de configuration du site et de journalisation de la configuration. Il enregistre plus de données, les changements se produisent plus fréquemment et les données ne sont pas considérées comme aussi critiques que les autres bases de données. Pour plus d’informations, consultez l’article Comment modifier l’emplacement de la base de données de surveillance et de journalisation de la configuration.

Assurez-vous de disposer d’un processus permettant de mettre régulièrement à niveau votre environnement vers la dernière mise à jour cumulative (CU) lorsque vous exécutez des versions LTSR (Long Term Service Release). Les CU contiennent souvent des correctifs liés au SQL. En outre, assurez-vous qu’une surveillance appropriée des serveurs SQL et des bases de données est en place pour détecter les défaillances et les problèmes tels que l’utilisation élevée des ressources, l’espace disque libre, etc.

Interaction entre Citrix et SQL

Citrix Virtual Apps and Desktops Brokers (Delivery Controllers) utilise la base de données comme bus de messages pour les communications avec les courtiers, le stockage des données de configuration, de surveillance et d’audit. Les bases de données sont constamment utilisées et peuvent consommer d’importantes ressources de calcul sur le serveur SQL.

Par exemple, l’énumération des ressources (ressources identifiées et présentées à l’utilisateur), le lancement de ressources et les étapes de démarrage de session nécessitent que Citrix Delivery Controller interagisse avec le serveur SQL.

Énumération : après une authentification réussie via NetScaler et StoreFront, le Delivery Controller contacte la base de données du site Citrix pour vérifier quelles applications sont disponibles pour l’utilisateur, en fonction des informations d’identification AD. Lorsque des ressources sont identifiées, des informations supplémentaires (telles que les noms des applications, des bureaux, des icônes, etc.) sont extraites de la base de données.

Lancement : lorsque l’utilisateur sélectionne l’application ou le poste de travail à lancer, StoreFront lance une demande de lancement au Delivery Controller. Le Delivery Controller contacte ensuite la base de données du site sur le serveur SQL pour sélectionner le VDA approprié vers lequel envoyer l’utilisateur.

Initialisation de session : après le démarrage de la session, le VDA est en contact avec le Delivery Controller pour écrire les informations de session dans la base de données du site.

Recommandations de base de données

Pour garantir qu’une panne de SQL Server ait un impact minimal sur l’infrastructure Citrix Virtual Apps and Desktops, les clients peuvent choisir parmi les options de base de données à haute disponibilité suivantes prises en charge par Citrix :

• Instances de cluster de basculement AlwaysOn SQL Server
• Groupes de disponibilité SQL Server AlwaysOn (y compris les groupes de disponibilité de base)
• Mise en miroir de base de données SQL Server

Citrix (et Epic pour les environnements de santé) recommandent d’utiliser la même approche de haute disponibilité pour les trois bases de données, même si la journalisation de la configuration et la surveillance de la disponibilité des bases de données ne sont pas requises pour l’établissement de sessions utilisateur final. Par exemple, si vous envisagez d’utiliser les groupes de disponibilité SQL AlwaysOn comme stratégie HA, utilisez-le pour les trois objets de base de données.

Nous vous recommandons également d’effectuer une sauvegarde quotidienne complète des bases de données Citrix elles-mêmes, en particulier de la base de données du site. Les périodes de conservation varient en fonction des exigences de l’organisation, mais il est courant de conserver sept jours de sauvegardes complètes et au moins un mois de sauvegardes hebdomadaires. Les calendriers de sauvegarde des journaux de transactions doivent être basés sur une combinaison des normes de votre organisation et du taux de croissance du journal des transactions par rapport à la quantité de stockage disponible que vous devez allouer. Assurez-vous de surveiller l’espace de stockage disponible sur votre serveur SQL.

Adaptez votre modèle de restauration des bases de données Citrix aux exigences de l’approche de haute disponibilité que vous adoptez.

Conformément aux recommandations de Microsoft, les clients doivent configurer des plans de maintenance à exécuter tous les soirs et toutes les semaines afin de maintenir les index de base de données. Les plans de maintenance peuvent simplement consister à réorganiser les index pendant la nuit pendant la semaine et à les reconstruire le week-end.

Cette recommandation évite tout impact sur les performances lié à la reconstruction de grands index au cours des opérations quotidiennes, en particulier pour une base de données de surveillance volumineuse. 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 %.

Cache d’hôte local

Pour tenir compte des scénarios dans lesquels la base de données devient indisponible, Citrix fournit la fonctionnalité Local Host Cache (LHC) avec Citrix Virtual Apps and Desktops. L’activation de cette option permet aux utilisateurs d’applications et de bureaux publiés de se connecter en cas d’interruption de la communication entre les Delivery Controllers et la base de données de configuration du site Citrix. Si SQL est configuré dans une architecture hautement disponible, telle que AlwaysOn ou Mirroring, cette fonctionnalité offre une tolérance aux pannes supplémentaire en cas de panne complète de SQL ou d’interruption de la connectivité réseau.

Cela ne doit pas être considéré comme une alternative à la haute disponibilité SQL, car la fonctionnalité de gestion du site n’est pas disponible en cas de panne SQL et le processus de basculement n’est pas instantané. En cas de panne de SQL, la fonctionnalité de courtage est perdue jusqu’à ce qu’elle soit transférée au LHC et que les VDA soient réenregistrés. Ce scénario se produit également lors du retour au mode de fonctionnement normal lorsque la connectivité/la disponibilité SQL est rétablie.

Le cache d’hôte local conserve une copie des données statiques du site dans une base de données SQL Express LocalDB locale sur chaque Delivery Controller et s’appuie sur ces données lors d’une panne de base de données pour prendre en charge en permanence les enregistrements VDA et les demandes de courtage de session.

Pour les sites CVAD comportant plusieurs zones, un LHC distinct existera pour chaque zone. Les Delivery Controllers de la zone conservent les données dynamiques spécifiques à leur zone dans la base de données SQL Express locale.

Considérations relatives à la conception du cache d’hôte local

En raison des nombreuses variables qui caractérisent les déploiements en entreprise, il est recommandé de travailler en étroite collaboration avec Citrix afin de déterminer les ressources supplémentaires requises pour utiliser le LHC.

• Considérations sur la capacité à monter en charge
  • Les limites maximales documentées pour le LHC au CVAD 2203 LTSR sont de 10 000 VDA dans une zone unique et de 40 000 VDA dans un déploiement multizone. Dans un environnement CVAD, l’évolutivité du LHC et des zones dépend du taux d’ouverture de session et du nombre d’utilisateurs. Par conséquent, l’évolutivité réelle observée dans votre environnement peut être inférieure aux valeurs maximales publiées. Pour cette architecture, nous vous recommandons d’envisager des zones supplémentaires si le nombre de sessions prévu dépasse 10 000 et/ou si votre taux de connexion est supérieur à 10 utilisateurs par seconde.
• Dimensionnement du Delivery Controller : lorsque le LHC est actif, le Delivery Controller (DC) principal élu par zone gère tous les enregistrements, les énumérations, les lancements et les mises à jour des VDA.
  • RAM : les services du LHC peuvent consommer plus de 2 Go de RAM en fonction de la durée de la panne et du nombre de lancements par les utilisateurs pendant la panne.
  • Processeur : en raison de la charge supplémentaire du processeur sur le contrôleur de domaine sélectionné, des cœurs supplémentaires doivent être envisagés pour compenser.

  La configuration du processeur d’un contrôleur, en particulier le nombre de cœurs disponibles pour SQL Server Express LocalDB, affecte directement les performances du cache d’hôte local, plus encore que l’allocation de mémoire. Cette charge de l’UC est observée uniquement au cours de la période de panne lorsque la base de données ne peut pas être contactée et que le service High Availability Service est actif.

  Bien que le LocalDB puisse utiliser plusieurs cœurs (jusqu’à 4), il est limité à un seul socket. L’ajout de sockets supplémentaires, par exemple 4 sockets dotés d’un cœur chacun, n’améliore pas les performances. Citrix vous recommande plutôt d’utiliser plusieurs sockets avec plusieurs cœurs. Au cours des tests Citrix, une configuration 2x3 (2 sockets, 3 cœurs) a fourni de meilleures performances que les configurations 4x1 et 6x1.

• Stockage : en mode LHC, l’utilisation du stockage augmente d’environ 1 Mo toutes les 2 à 3 minutes, en supposant une moyenne de 10 ouvertures de session par seconde. La consommation de stockage augmente par rapport au taux d’ouverture de session.

Pour plus d’informations, consultez l’article Cache d’hôte local .

Effets d’une panne de base de données

En cas de panne totale de la base de données, presque toutes les fonctions critiques du Delivery Controller sont affectées, ce qui souligne l’importance de concevoir et de mettre en œuvre l’une des stratégies SQL HA recommandées. Le tableau suivant décrit ces effets :

Component	Impact d’une panne de base de données
Base de données de configuration du site	Les utilisateurs ne peuvent pas se connecter ou se reconnecter à une application ou à un bureau virtuel (sans le LHC).
Base de données de contrôle	Director n’affiche aucune donnée historique et Studio ne peut pas être démarré. Le courtage des demandes des utilisateurs entrants et des sessions utilisateur existantes n’est pas affecté.
Base de données de journalisation de la configuration	Si l’option Autoriser les modifications lorsque la base de données est déconnectée a été activée dans les préférences de journalisation de Citrix Virtual Apps and Desktops, une interruption de la base de données de journalisation de la configuration n’a aucun impact (si ce n’est que les modifications de configuration ne sont pas enregistrées). Dans le cas contraire, les administrateurs ne seront pas en mesure d’apporter des modifications à l’environnement CVAD.

Remarque : Reportez-vous à la section Ce qui n’est pas disponible en cas de panne et aux autres différences pour plus de détails sur ce sujet.

Recommandation de dimensionnement SQL

Le serveur SQL doit être dimensionné correctement pour garantir les performances et la stabilité d’un environnement. Étant donné que chaque produit Citrix utilise SQL Server de manière différente et que chaque client a des modèles d’utilisation différents, aucune recommandation de dimensionnement générique et globale ne peut être fournie. Au lieu de cela, des recommandations de dimensionnement de SQL Server par produit sont fournies ci-dessous, et les performances doivent être surveillées attentivement pendant le déploiement afin de valider les hypothèses de dimensionnement.

Pour un environnement SQL hébergeant uniquement des bases de données liées à Citrix, les serveurs SQL doivent être équipés d’un minimum de 4 processeurs virtuels et de 8 Go de RAM pour un maximum de 10 000 utilisateurs. Pour les déploiements plus importants ou les déploiements avec des taux d’ouverture de session élevés, nous recommandons un minimum de 8 processeurs virtuels et 16 Go de RAM. Pour plus d’informations sur les concepts de dimensionnement des bases de données SQL pour les déploiements de Citrix Virtual Apps and Desktops, consultez la section Dimensionnement de la base de données Citrix XenDesktop 7.x. Cet article contient également des informations sur les caractéristiques de la charge de travail, telles que le taux de croissance estimé du journal des transactions.

N’oubliez pas que la taille de la base de données de surveillance varie en fonction des paramètres de conservation des données. De plus, les versions les plus récentes du produit proposent davantage d’options et de points de données qui consomment plus d’espace (par exemple, LTSR 2203 contre LTSR 1912). Pour plus d’informations sur la configuration de ces paramètres, voir Surveillance des paramètres de stratégie et prise en compte dans les calculs de dimensionnement de la base de données.

Mises à jour et correctifs CU

Plusieurs fois par an, Citrix publie des mises à jour cumulatives (CU) pour Citrix Virtual Apps and Desktops LTSR. Ces CU ne contiennent que des mises à jour de sécurité et des corrections de bogues, aucune nouvelle fonctionnalité n’étant introduite. Citrix recommande d’exécuter les dernières UC, car elles résolvent les problèmes identifiés dans le produit. Certains de ces correctifs sont liés au langage SQL. Ils répondent aux problèmes qui ont été identifiés en interne par Citrix ou ses clients (par exemple, le verrouillage, les blocages ou les procédures stockées). Nous sommes conscients que l’application de mises à jour complètes aux environnements CVAD demande du temps et une planification appropriée (en particulier pour les situations critiques 24 h/24 et 7 j/7), mais Citrix recommande vivement de rester aussi à jour que possible sur les unités de traitement afin d’optimiser l’intégrité et les performances globales.

Documentation la plus récente

Ce document souligne l’importance du langage SQL avec les environnements CVAD, y compris la stratégie HA et diverses considérations. Il ne s’agit pas d’une documentation exhaustive sur les recommandations Citrix et SQL. Pour plus de détails et des informations actualisées, veuillez consulter les documents suivants :

Bases de données CVAD

Cache d’hôte local Citrix

Dimensionnement de la base de données Citrix XenDesktop 7.x