Concepts avancés

Bases de données SQL Server et Citrix

Microsoft SQL Server est un composant important de tout déploiement Citrix Virtual Apps and Desktops. Planifier et comprendre les interactions Citrix SQL est très utile pour vous et votre organisation dans le maintien d’un environnement Citrix sain et performant. L’absence de haute disponibilité SQL Server et de ressources de calcul abondantes a un effet négatif sur l’expérience utilisateur et le temps de disponibilité de l’infrastructure Citrix.

Résumé de la base de données

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

Site : (également connu sous le nom de Configuration du site) stocke la configuration du site en cours d’exécution, ainsi que les données dynamiques liées au courtage, telles que l’état actuel de la session, la connexion, la charge et les informations d’état du VDA.

Journalisation de la configuration : (également appelée Journalisation) stocke des informations sur les modifications de 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.

Dans les versions précédentes de Citrix Virtual Apps and Desktops, telles que XenApp et XenDesktop 7.6, la base de données requise pour Citrix Virtual Apps and Desktops a été créée en tant que base de données unique lors de la configuration initiale du site (via Studio ou en exécutant des scripts sur SQL Server). Après l’installation, l’administrateur pourrait le scinder en différentes bases de données pour améliorer les performances ou se conformer aux consignes de sauvegarde/sécurité.

Avec les versions plus récentes de Citrix Virtual Apps and Desktops, vous pouvez créer les bases de données lors de la configuration initiale du site, ainsi que via Studio, ou en exécutant des scripts sur SQL Server. Votre base de données est automatiquement divisée en trois bases de données distinctes.

Pour les environnements avec de grandes bases de données de surveillance, une configuration idéale serait d’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, voir Database Sizing Guidance ou page 97 du manuel VDI.

Chaque mise à jour cumulative (CU) pour la version de service à long terme (LTSR) contient des correctifs au schéma de base de données SQL. Par exemple, consultez CTX230536. Pour protéger au mieux votre environnement contre les problèmes inattendus, assurez-vous que vous disposez d’un processus de mise à niveau régulière de votre environnement vers la dernière CU. Assurez-vous également que la surveillance appropriée du serveur SQL et de la base de données sont en place pour détecter les événements de défaillance et les problèmes liés à l’utilisation élevée des ressources et à l’espace libre.

Interaction Citrix avec SQL

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

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

Énumération : après l’authentification réussie via Citrix ADC 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 les ressources sont identifiées, des informations supplémentaires, telles que les noms des applications, des postes de travail, des icônes, sont extraites de la base de données.

Lancement : Lorsque l’utilisateur sélectionne l’application ou le bureau à lancer, StoreFront lance une demande de lancement au Delivery Controller. Ensuite, le Delivery Controller contacte la base de données du site sur le serveur SQL pour sélectionner le VDA approprié à envoyer l’utilisateur.

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

Recommandations de base de données

Pour s’assurer qu’une panne de serveur SQL a un impact minimal sur l’infrastructure Citrix Virtual Apps and Desktops, les clients peuvent choisir parmi les options de haute disponibilité suivantes prises en charge par Citrix :

  • Groupes de disponibilité AlwaysOn
  • Clustering de basculement AlwaysOn
  • Groupes de disponibilité de base
  • Hyperviseur HA *

Remarque :

Bien que Citrix prenne en charge Hypervisor HA, il n’est pas recommandé de l’utiliser dans des environnements hébergeant des applications EHR, où la disponibilité est de la plus haute importance.

Citrix et Epic 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é de la base de données ne sont pas nécessaires pour l’établissement de sessions utilisateur final. Par exemple, si vous envisagez d’utiliser le groupe de disponibilité SQL Always-On 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 la base de données du site. Les périodes de conservation varient en fonction des besoins de l’organisation, mais il est courant de conserver sept jours de sauvegardes complètes et d’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 le stockage disponible sur votre serveur SQL.

Alignez votre modèle de récupération pour les bases de données Citrix avec les exigences de l’approche de haute disponibilité que vous adoptez.

Conformément à la recommandation de Microsoft, les clients doivent configurer des plans de maintenance qui s’exécutent tous les soirs et toutes les semaines pour gérer 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 à 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 %. Consultez la section Maintenance des bases de données.

Cache d’hôte local

Pour tenir compte des scénarios dans lesquels la base de données devient indisponible, Citrix a ajouté la fonctionnalité Local Host Cache (LHC) à la plate-forme Citrix Virtual Apps and Desktops 7.x (7.12 et versions ultérieures, y compris XenApp et XenDesktop 7.15 LTSR). L’activation de cette option permet aux utilisateurs d’applications publiées de se connecter si la communication entre Delivery Controller et la base de données de configuration du site Citrix est interrompue. Si SQL est configuré dans une architecture hautement disponible, telle que Always On, Mirroring ou Clustering, cette fonctionnalité offre une tolérance de pannes supplémentaire lorsqu’une panne SQL complète survient ou que la connectivité réseau est interrompue.

Cela ne doit pas être considéré comme une alternative à la haute disponibilité SQL, car la fonctionnalité de gestion de site n’est pas disponible pendant une panne SQL et le processus de basculement n’est pas instantané. En cas de panne SQL, la fonctionnalité de courtage est perdue jusqu’à ce qu’elle ait été transférée au LHC et que les VDA aient été réenregistrés. Ce scénario est également rencontré lors de la transition vers le mode normal de fonctionnement lorsque la connectivité/disponibilité SQL est restaurée.

Local Host Cache conserve une copie des données de site statiques dans une base de données locale SQL Express LocalDB 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 continu les enregistrements VDA et les demandes de courtage de session.

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

En raison de la variation de la taille des déploiements de membres de la communauté Epic, il est recommandé de travailler en étroite collaboration avec Citrix pour déterminer les ressources supplémentaires nécessaires à l’utilisation du LHC.

  • Considérations sur la capacité à monter en charge
    • Les limites maximales documentées pour le LHC dans XenApp et Xendesktop 7.15 sont de 10 000 VDA dans une zone unique et de 40 000 VDA dans un déploiement multi-zone. Dans un environnement Citrix Virtual Apps, l’évolutivité du LHC et de la zone 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 maximums publiés. Pour cette architecture, nous vous recommandons d’envisager des zones supplémentaires si votre nombre de sessions attendu dépasse 10 000 et/ou si votre taux d’ouverture de session est supérieur à 10 utilisateurs par seconde.
  • Dimensionnement du Delivery Controller : lorsque LHC est actif, le Delivery Controller (DC) principal élu par zone gère tous les enregistrements VDA, énumérations, lancements et mises à jour.
    • RAM : les services de cache de l’hôte local peuvent consommer 2 Go plus de RAM en fonction de la durée de l’interruption et du nombre de lancements d’utilisateur pendant la panne.
    • CPU : En raison de la charge CPU supplémentaire sur le contrôleur de domaine choisi, des cœurs supplémentaires doivent être considérés pour compenser.

    Une configuration d’UC de Controller, notamment le nombre de cœurs disponibles pour SQL Server Express LocalDB, affecte directement les performances de cache d’hôte local, encore plus 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 la base de données LocalDB puisse utiliser plusieurs cœurs (jusqu’à 4), elle est limitée à un seul socket. Ajouter plus de sockets, par exemple, avoir 4 sockets avec 1 cœur chacune, 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 cache de l’hôte local, 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 d’implémenter l’une des stratégies SQL HA recommandées. Le tableau suivant fait état de ces effets :

Composant 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 à un poste de travail virtuel. Remarque : Le cache hôte local (LHC) permet aux utilisateurs disposant de bureaux partagés hébergés, d’applications Windows et navigateur hébergés et de bureaux personnels de se reconnecter à leurs applications et postes de travail même lorsque la base de données du site n’est pas disponible. En mode LHC, les données de surveillance ne sont pas collectées et les modifications de configuration ne peuvent pas être apportées au Site.
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 d’utilisateurs entrantes et des sessions utilisateur existantes n’est pas affecté.
Base de données de journalisation de la configuration Si Autoriser les modifications lorsque la base de données est déconnectée a été activée dans les préférences de journalisation Citrix Virtual Apps and Desktops, une panne de la base de données de journalisation de configuration n’a aucun impact (sauf les modifications de configuration ne sont pas enregistrées). Sinon, les administrateurs ne peuvent pas apporter de modifications à Citrix Virtual Apps and Desktops.

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 d’une manière différente et que chaque client a des modèles d’utilisation différents, aucune recommandation générique de dimensionnement globale ne peut être fournie. Au lieu de cela, les recommandations de dimensionnement du serveur SQL par produit sont fournies ci-dessous, et les performances doivent être soigneusement surveillées 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 provisionnés avec un minimum de 4 vCPU et 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 vCPU et 16 Go de RAM. Pour plus d’informations sur les concepts de dimensionnement de base de données SQL pour les déploiements Citrix Virtual Apps and Desktops 7.x, consultez le document 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.

Gardez à l’esprit que la base de données de surveillance varie en taille en fonction des paramètres de rétention des données. XenApp et XenDesktop 7.15 LTSR dispose de plus d’options que 7.6 LTSR, une fois que la capacité de capturer des données granulaires de performances VDA a été ajoutée au produit. 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 CU pour Citrix Virtual Apps and Desktops LTSR. Ces UC ne contiennent que des mises à jour de sécurité et des corrections de bogues, sans nouvelles fonctionnalités introduites. Citrix recommande d’exécuter les CU les plus récentes, car elles corrigent les problèmes identifiés dans le produit. Certains de ces correctifs sont liés à SQL. Ils abordent les problèmes, tels que le verrouillage, les blocages, les procédures de magasin, qui ont été identifiés par Citrix ou nos clients. Par exemple, il existe un certain nombre de correctifs liés à SQL dans les UC XenApp 7.6 jusqu’à CU5. La recommandation serait de passer en revue la section Problèmes résolus pour chaque CU et de rechercher SQL dans la page.

Problème résolu

Remarque :

LC8477 a été publié en 7.6 CU5 et 7.17

Références supplémentaires

Contribué par Henry Vernov, ingénieur système principal.

Bases de données SQL Server et Citrix