XenApp and XenDesktop

Bases de données

Un site XenApp ou XenDesktop utilise trois bases de données SQL Server :

  • Site : (également appelé Configuration de site) stocke les données de configuration du site, ainsi que les informations sur l’état de la session et la connexion.
  • 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.

Chaque Delivery Controller communique directement avec la base de données du site. L’authentification Windows est requise entre le Controller et les bases de données. Il est possible de déconnecter un Controller ou de le mettre hors tension sans affecter les autres Controller du site. L’unique point de défaillance reste par conséquent la base de données. Si le serveur de base de données échoue, les connexions existantes continuent de fonctionner jusqu’à ce que l’utilisateur ferme sa session ou se déconnecte. Pour plus d’informations sur le comportement de la connexion lorsque la base de données de site devient indisponible, consultez la section Cache d’hôte Local.

Lorsque vous ajoutez un Delivery Controller à un site, veillez à ajouter des informations d’identification d’ouverture de session pour cette machine à n’importe quel réplica SQL Server que vous utilisez pour la haute disponibilité.

Citrix vous recommande de sauvegarder régulièrement les bases de données afin de pouvoir la restaurer en cas de défaillance du serveur de base de données. La stratégie de sauvegarde pour chaque base de données peut différer. Pour obtenir des instructions, consultez l’article CTX135207.

Si votre site contient plus d’une zone, la base de données du site doit toujours se trouver dans la zone principale. Les Controller de chaque zone communiquent avec cette base de données.

Haute disponibilité

Il existe trois solutions de haute disponibilité à considérer pour garantir le basculement automatique :

  • Groupes de disponibilité AlwaysOn (y compris les groupes de disponibilité de base) : cette solution à haute disponibilité et reprise après sinistre introduite dans SQL Server 2012 vous permet d’optimiser la disponibilité pour une ou plusieurs bases de données. Les Groupes de disponibilité AlwaysOn nécessitent que les instances SQL Server résident les nœuds WSFC (Windows Server Failover Clustering). Pour plus d’informations, consultez https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/always-on-availability-groups-sql-server?redirectedfrom=MSDN&view=sql-server-ver15.
  • Mise en miroir de la base de données SQL Server : la mise en miroir de la base de données garantit qu’en cas d’indisponibilité soudaine du serveur de base de données actif, le basculement automatique se produit au bout de quelques secondes seulement, évitant généralement toute gêne pour les utilisateurs. Cette méthode est plus coûteuse que d’autres solutions car les licences complètes de SQL Server sont requises sur chaque serveur de base de données ; vous ne pouvez pas utiliser SQL Server édition Express pour un environnement de mise en miroir.
  • Mise en cluster SQL : la technologie de mise en cluster SQL de Microsoft peut être utilisée pour permettre à un serveur d’assurer automatiquement la reprise des tâches et des responsabilités d’un autre serveur défaillant. Toutefois, cette solution est plus complexe à mettre en place et le basculement automatique est généralement plus lent qu’avec les autres méthodes, comme la mise en miroir SQL.
  • À l’aide des fonctionnalités de haute disponibilité de l’hyperviseur : avec cette méthode, vous déployez la base de données en tant que machine virtuelle et utilisez les fonctionnalités de haute disponibilité de votre hyperviseur. Cette solution est moins coûteuse que la mise en miroir du fait qu’elle utilise votre logiciel d’hyperviseur et que vous pouvez également utiliser l’édition SQL Server Express. Cependant, le processus de basculement automatique est plus lent car il faut un certain temps pour qu’une nouvelle machine démarre pour la base de données, avec le risque d’interrompre le service fourni aux utilisateurs.

La fonctionnalité de cache d’hôte local complète les meilleures pratiques de la haute disponibilité du serveur SQL Server en permettant aux utilisateurs de se connecter et de se reconnecter à leurs applications et bureaux même lorsque la base de données du site n’est pas disponible. Pour plus d’informations, veuillez consulter la section Cache d’hôte local.

Si tous les Controller d’un site échouent, vous pouvez configurer les VDA pour fonctionner en mode haute disponibilité de sorte à ce que les utilisateurs puissent continuer à accéder à leurs bureaux et applications et les utiliser. En mode haute disponibilité, le VDA accepte des connexions ICA directes provenant des utilisateurs, plutôt que des connexions négociées par le Controller. Utilisez cette fonctionnalité uniquement dans les rares cas où la communication avec tous les Controllers échoue. Il ne s’agit pas d’une solution alternative aux autres solutions de haute disponibilité. Pour plus d’informations, veuillez consulter l’article CTX 127564.

Remarque

L’installation d’un Controller sur un nœud dans une installation de mise en cluster SQL ou mise en miroir SQL n’est pas prise en charge.

Installer le logiciel de base de données

Par défaut, l’édition SQL Server Express est installée lorsque vous installez le premier Delivery Controller, si une autre instance SQL Server n’est pas détectée sur ce serveur. Cette mesure par défaut est généralement suffisante pour la preuve de concept ou pour les déploiements pilotes. Toutefois, SQL Server Express ne prend pas en charge les fonctionnalités de haute disponibilité de Microsoft.

L’installation par défaut utilise les comptes de service et autorisations Windows par défaut. Reportez-vous à la documentation Microsoft pour de plus amples informations sur ces défauts, y compris l’ajout de comptes de service Windows au rôle sysadmin. Le Controller utilise le compte de service réseau de cette configuration. Le Controller ne requiert aucun rôle ni autorisation SQL Server supplémentaire.

Le cas échéant, vous pouvez sélectionner Masquer l’instance pour l’instance de base de données. Lors de la configuration de l’adresse de la base de données dans Studio, entrez le numéro de port statique de l’instance plutôt que son nom. Reportez-vous à la documentation Microsoft pour de plus amples informations sur le masquage d’une instance du moteur de base de données SQL Server.

La plupart des déploiements de production, et tout déploiement qui utilise les fonctionnalités de haute disponibilité de Microsoft, utilisent des éditions non-Express prises en charge de SQL Server installées sur des machines autres que le serveur sur lequel le premier Delivery Controller est installé. L’article Configuration système requise répertorie les versions prises en charge de SQL Server. Les bases de données peuvent résider sur une ou plusieurs machines.

Assurez-vous que le logiciel SQL Server est installé avant de créer un site. Vous n’avez pas besoin de créer la base de données, mais si vous le faites, elle doit être vide. La configuration de technologies haute disponibilité de Microsoft est également recommandée.

Utilisez Windows Update pour conserver SQL Server à jour.

Configurer les bases de données à partir de l’assistant de création de site

Indiquez le nom et l’adresse des bases de données (emplacement) sur la page Bases de données dans l’assistant de création de site. Voir Formats d’adresse de base de données. Pour éviter des erreurs lorsque Director interroge le service Monitor, n’utilisez pas d’espaces dans le nom de la base de données de contrôle.

La page Bases de données offre deux options pour configurer les bases de données : automatiquement et à l’aide de scripts. En général, vous pouvez utiliser l’option automatique si vous (utilisateur de Studio et administrateur de Citrix) disposez des privilèges de base de données requis ; veuillez consulter la section Autorisations requises pour configurer les bases de données ci-dessous.

Vous pouvez modifier l’emplacement des bases de données de journalisation de la configuration et de contrôle après la création du site. Voir Modifier l’emplacement des bases de données.

Pour configurer un site pour utiliser une base de données mise en miroir, effectuez les étapes suivantes, puis passez à la procédure de configuration automatique ou à l’aide d’un script.

  1. Installez le logiciel SQL Server sur deux serveurs, A et B
  2. Sur le serveur A, créez la base de données destinée à être utilisée comme base de données principale. Sauvegardez la base de données sur le serveur A, puis copiez-la sur le serveur B.
  3. Sur le serveur B, restaurez le fichier de sauvegarde.
  4. Démarrez la mise en miroir sur le serveur A.

Pour vérifier la mise en miroir après la création du site, exécutez le cmdlet PowerShell get-configdbconnection pour vous assurer que le partenaire de basculement a été défini dans la chaîne de connexion pour le miroir.

Si vous ajoutez, déplacez ou supprimez un Delivery Controller dans un environnement de base de données mise en miroir ultérieurement, consultez l’article Delivery Controller.

Configuration automatique

Si vous possédez les privilèges de base de données requis, sélectionnez l’option Créer et configurer les bases de données à partir de Studio sur la page Bases de données de l’assistant de création de site, puis fournissez les noms et adresses des bases de données principales.

Si une base de données existe sur une adresse spécifiée, elle doit être vide. Si les bases de données n’existent pas sur une adresse spécifiée, vous êtes informé qu’aucune base de données n’a été détectée, puis vous êtes invité à indiquer si vous souhaitez que la base de données soit créée pour vous. Lorsque vous confirmez, Studio crée automatiquement les bases de données, puis applique les scripts d’initialisation pour les bases de données principales et les copies.

Installation à l’aide de scripts

Si vous ne disposez pas des privilèges de base de données requis, un utilisateur avec ces autorisations, tel qu’un administrateur de base de données, doit vous aider. Voici la séquence :

  1. Dans l’assistant de création de site, sélectionnez l’option Générer des scripts. Six scripts sont générés : deux pour chacune des trois de bases de données, un pour chaque base de données principale et un autre pour chaque copie. Vous pouvez indiquer l’emplacement de stockage des scripts.
  2. Donnez ces scripts à votre administrateur de base de données. L’assistant de création de site s’arrête automatiquement à ce stade ; vous serez invité lorsque vous y reviendrez plus tard à continuer la création de site.

L’administrateur de base de données crée alors les bases de données. Chaque base de données doit présenter les caractéristiques suivantes :

  • Utilisez un classement qui se termine par « _CI_AS_KS ». Citrix vous recommande d’utiliser un classement qui se termine par « _100_CI_AS_KS ».
  • Pour des performances optimales, activez l’option Capture instantanée Read Committed de SQL Server. Pour plus d’informations, veuillez consulter l’article CTX 137161.
  • Les fonctionnalités haute disponibilité doivent être configurées, le cas échéant.
  • Pour configurer la mise en miroir, vous devez tout d’abord définir la base de données pour utiliser le modèle de récupération complet (le modèle simple est la valeur par défaut). Sauvegardez la base de données principale dans un fichier et copiez-la sur le serveur miroir. Sur la base de données miroir, restaurez le fichier de sauvegarde sur le serveur miroir. Ensuite, démarrez la mise en miroir sur le serveur principal.

L’administrateur de base de données utilise l’utilitaire de ligne de commande SQLCMD ou SQL Server Management Studio dans le mode SQLCMD pour exécuter chacun des scripts xxx_Replica.sql sur les instances de base de données SQL Server haute disponibilité (si la haute disponibilité est configurée), puis exécute chacun des scripts xxx_Principal.sql sur les instances de base de données SQL Server principales. Consultez la documentation Microsoft sur SQLCMD pour plus de détails.

Lorsque tous les scripts sont terminés, l’administrateur de la base de données donne à l’administrateur Citrix les trois adresses de base de données principale.

Dans Studio, vous êtes invité à continuer la création de site et renvoyé à la page Bases de données. Entrez les adresses. Si l’un des serveurs hébergeant une base de données ne peut pas être contacté, un message d’erreur s’affiche.

Autorisations requises pour configurer les bases de données

Vous devez être un administrateur local et un utilisateur du domaine pour créer et initialiser les bases de données (ou modifier l’emplacement de la base de données). Vous devez également disposer de certaines autorisations SQL Server. Les autorisations suivantes peuvent être explicitement configurées ou acquises par l’appartenance à un groupe Active Directory. Si vos informations d’identification d’utilisateur Studio ne comprennent pas ces autorisations, vous êtes invité à entrer les informations d’identification d’utilisateur SQL Server.

Opération Objectif Rôle de serveur Rôle de base de données
Créer une base de données Créer une base de données vide appropriée dbcreator  
Créer un schéma Créer tous les schémas spécifiques au service et ajouter le premier Controller au site securityadmin* db_owner
Ajouter un Controller Ajouter un Controller (autre que le premier) au site securityadmin* db_owner
Ajouter un Controller (serveur miroir) Ajouter une ouverture de session Controller au serveur de base de données assumant actuellement le rôle de miroir d’une base de données en miroir securityadmin*  
Supprimer Controller Supprimer le Controller du site ** db_owner
Mettre à jour un schéma Appliquer les mises à jour ou correctifs au schéma   db_owner

* Bien qu’il soit plus restrictif techniquement, en pratique, le rôle de serveur securityadmin doit être considéré comme équivalent au rôle de serveur sysadmin.

** Lorsqu’un Controller est supprimé d’un site, soit directement via Desktop Studio, soit à l’aide des scripts générés par Desktop Studio ou SDK, l’ouverture de session du Controller sur le serveur de base de données n’est pas supprimée. Cela évite potentiellement la suppression d’une ouverture de session utilisée par des services autres que XenDesktop sur la même machine. L’ouverture de session doit être supprimée manuellement si elle n’est plus requise ; pour cela, il est nécessaire de disposer du rôle serveur securityadmin.

Lorsque vous utilisez Studio pour effectuer ces opérations, le compte d’utilisateur doit être un membre du rôle de serveur sysadmin.

Formats d’adresse de base de données

Vous pouvez spécifier une adresse de base de données dans l’un des formats suivants :

  • ServerName
  • ServerName\\InstanceName
  • ServerName,PortNumber

Pour un groupe de disponibilité AlwaysOn, spécifiez l’écouteur du groupe dans le champ d’emplacement.

Modifier l’emplacement des bases de données

Après avoir créé un site, vous pouvez modifier l’emplacement des bases de données de journalisation de la configuration et de contrôle. (Vous ne pouvez pas modifier l’emplacement de la base de données du site.) Lorsque vous modifiez l’emplacement d’une base de données :

  • Les données provenant de la base de données précédente ne sont pas importées vers la nouvelle base de données.
  • Les journaux ne peuvent pas être regroupés pour les deux bases de données lors de la récupération des journaux.
  • La première entrée du journal dans la nouvelle base de données indique qu’une modification a été apportée dans une base de données, mais elle n’identifie pas la base de données précédente.

Vous ne pouvez pas modifier l’emplacement de la base de données de journalisation de la configuration lorsque la journalisation obligatoire est activée.

Pour modifier l’emplacement d’une base de données :

  1. Assurez-vous qu’une version prise en charge de Microsoft SQL Server est installée sur le serveur sur lequel vous souhaitez que la base de données réside. Configurez les fonctionnalités de haute disponibilité en fonction de vos besoins.
  2. Sélectionnez une configuration dans le volet de navigation Studio.
  3. Sélectionnez la base de données pour laquelle vous souhaitez spécifier un autre emplacement, puis sélectionnez Modifier la base de données dans le volet Actions.
  4. Spécifiez le nouvel emplacement et le nom de la base de données.
  5. Si vous souhaitez que Studio crée la base de données et que vous possédez les autorisations appropriées, cliquez sur OK. Lorsque vous y êtes invité, cliquez sur OK et Studio crée la base de données automatiquement. Studio tente d’accéder à la base de données à l’aide de vos informations d’identification. Si la tentative échoue, vous êtes invité à entrer les informations d’identification de l’utilisateur de la base de données. Studio télécharge ensuite le schéma de base de données vers la base de données. Les informations d’identification ne sont conservées que durant la création de la base de données.
  6. Si vous ne souhaitez pas que Studio crée la base de données, ou si vous ne disposez pas des autorisations suffisantes, cliquez sur Générer script. Les scripts générés contiennent des instructions permettant de créer manuellement la base de données et une base de données miroir, si nécessaire. Avant le chargement du schéma, assurez-vous que la base de données est vide et qu’au moins un utilisateur est autorisé à accéder et modifier la base de données.

Informations supplémentaires

Le dimensionnement de la base de données du site et la configuration des chaînes de connexion lors de l’utilisation de solutions de haute disponibilité de SQL Server.