Bail de connexion
Important :
Le cache d’hôte local (LHC) est la solution de haute disponibilité préférée pour XenApp et XenDesktop, au lieu du bail de connexion. Consultez Cache d’hôte local pour plus de détails.
- Dans cette version, lors d’une nouvelle installation de XenApp et XenDesktop®, le bail de connexion est désactivé par défaut.
- Le bail de connexion ne sera plus fourni, à compter de la version actuelle suivant cette version de service à long terme XenApp et XenDesktop 7.15.
Pour garantir que la base de données du Site est toujours disponible, Citrix® recommande de commencer par un déploiement SQL Server tolérant aux pannes en suivant les meilleures pratiques de haute disponibilité de Microsoft. Cependant, des problèmes et interruptions réseau peuvent empêcher les Delivery Controller d’accéder à la base de données, ce qui empêche les utilisateurs de se connecter à leurs applications ou bureaux.
La fonctionnalité de bail de connexion complète les meilleures pratiques de haute disponibilité de SQL Server en permettant aux utilisateurs de se connecter et de se reconnecter à leurs applications et bureaux les plus récemment utilisés, même lorsque la base de données du Site n’est pas disponible.
Bien que les utilisateurs puissent disposer d’un grand nombre de ressources publiées, ils n’en utilisent souvent que quelques-unes régulièrement. Lorsque vous activez le bail de connexion, chaque Controller met en cache les connexions utilisateur à ces applications et bureaux récemment utilisés pendant les opérations normales (lorsque la base de données est disponible).
Les baux générés sur chaque Controller sont téléchargés vers la base de données du Site pour une synchronisation périodique avec les autres Controllers du Site. En plus des baux, le cache de chaque Controller contient des informations sur les applications, les bureaux, les icônes et les workers. Le bail et les informations associées sont stockés sur le disque local de chaque Controller. Si la base de données devient indisponible, le Controller passe en mode de connexion par bail et « rejoue » les opérations mises en cache lorsqu’un utilisateur tente de se connecter ou de se reconnecter à une application ou un bureau récemment utilisé depuis StoreFront.
Les connexions sont mises en cache pour une période de bail de deux semaines. Ainsi, si la base de données devient indisponible, les bureaux et applications que l’utilisateur a lancés au cours des deux semaines précédentes restent accessibles à cet utilisateur via StoreFront. Cependant, les bureaux et applications qui n’ont pas été lancés au cours de la période de bail de deux semaines précédentes ne sont pas accessibles lorsque la base de données est indisponible. Par exemple, si un utilisateur a lancé une application pour la dernière fois il y a trois semaines, son bail a expiré, et cet utilisateur ne peut pas lancer cette application si la base de données devient indisponible maintenant. Les baux pour les sessions d’application ou de bureau actives ou déconnectées de longue durée sont prolongés afin qu’ils ne soient pas considérés comme expirés.
Par défaut, le bail de connexion affecte l’ensemble du Site ; cependant, vous pouvez révoquer tous les baux pour des utilisateurs spécifiques, ce qui les empêche d’accéder à des applications ou des bureaux lorsque le Controller est en mode de connexion par bail. Plusieurs autres paramètres de registre s’appliquent par Controller.
Considérations et limitations
Bien que le bail de connexion puisse améliorer la résilience des connexions et la productivité des utilisateurs, il existe des considérations liées à la disponibilité, au fonctionnement et aux performances d’autres fonctionnalités.
Le bail de connexion est pris en charge pour les applications et bureaux hébergés sur serveur, ainsi que pour les bureaux statiques (attribués) ; il n’est pas pris en charge pour les bureaux VDI en pool ou pour les utilisateurs auxquels aucun bureau n’a été attribué lorsque la base de données devient indisponible.
Lorsque le Controller est en mode de connexion par bail :
-
Les administrateurs ne peuvent pas utiliser Studio, Director ou la console PowerShell.
-
Le contrôle d’espace de travail n’est pas disponible. Lorsqu’un utilisateur se connecte à Citrix Receiver™, les sessions ne se reconnectent pas automatiquement ; l’utilisateur doit relancer l’application.
-
Si un nouveau bail est créé immédiatement avant que la base de données ne devienne indisponible, mais que les informations de bail n’ont pas encore été synchronisées sur tous les contrôleurs, l’utilisateur pourrait ne pas être en mesure de lancer cette ressource après que la base de données soit devenue indisponible.
-
Les utilisateurs d’applications et de bureaux hébergés sur serveur peuvent utiliser plus de sessions que leurs limites de session configurées. Par exemple :
- Une session peut ne pas être itinérante lorsqu’un utilisateur la lance à partir d’un appareil (en se connectant en externe via NetScaler® Gateway) lorsque le contrôleur n’est pas en mode de bail de connexion, puis se connecte à partir d’un autre appareil sur le réseau local lorsque le contrôleur est en mode de bail de connexion.
- La reconnexion de session peut échouer si une application est lancée juste avant que la base de données ne devienne indisponible ; dans de tels cas, une nouvelle session et une nouvelle instance d’application sont lancées.
-
Les bureaux statiques (attribués) ne sont pas gérés par l’alimentation. Les VDA qui sont éteints lorsque le contrôleur passe en mode de bail de connexion restent indisponibles jusqu’à ce que la connexion à la base de données soit restaurée, à moins que l’administrateur ne les mette manuellement sous tension.
-
Si le prélancement de session et la persistance de session sont activés, les nouvelles sessions de prélancement ne sont pas démarrées. Les sessions prélancées et persistantes ne seront pas terminées selon les seuils configurés tant que la base de données est indisponible.
-
La gestion de la charge au sein du Site peut être affectée. Les connexions basées sur le serveur sont acheminées vers le VDA le plus récemment utilisé. Les évaluateurs de charge (et en particulier, les règles de nombre de sessions) peuvent être dépassés.
-
Le contrôleur n’entrera pas en mode de bail de connexion si vous utilisez SQL Server Management Studio pour mettre la base de données hors ligne. Utilisez plutôt l’une des instructions Transact-SQL suivantes :
- ALTER DATABASE <database-name> SET OFFLINE WITH ROLLBACK IMMEDIATE
- MODIFIER LA BASE DE DONNÉES <database-name> METTRE HORS LIGNE AVEC RESTAURATION APRÈS <seconds>
L’une ou l’autre de ces instructions annule toutes les transactions en attente et entraîne la perte de connexion du contrôleur avec la base de données. Le contrôleur passe alors en mode de bail de connexion.
Lorsque le bail de connexion est activé, il existe deux brefs intervalles pendant lesquels les utilisateurs ne peuvent pas se connecter ou se reconnecter : (1) du moment où la base de données devient indisponible jusqu’à ce que le contrôleur entre en mode de bail de connexion, et (2) du moment où le contrôleur passe du mode de bail de connexion à celui où l’accès à la base de données est entièrement restauré et où les VDA se sont réenregistrés.
Si vous configurez une valeur d’itinérance de session non par défaut, la reconnexion de session revient à sa valeur par défaut lorsqu’un contrôleur entre en mode de bail de connexion. Pour plus de détails, consultez Bail de connexion et itinérance de session.
Consultez l’article Zones pour plus d’informations sur l’emplacement de stockage des données de location de connexion.
Configurer et déployer
Lors de la configuration de votre déploiement pour prendre en charge la location de connexion :
- Les VDA doivent être au minimum en version 7.6, et les catalogues de machines et les groupes de mise à disposition qui utilisent ces machines doivent être à ce niveau minimum (ou une version ultérieure prise en charge).
- Les exigences de taille de la base de données du site augmenteront.
- Chaque contrôleur nécessite un espace disque supplémentaire pour les fichiers de bail mis en cache.
Vous pouvez activer ou désactiver la location de connexion à partir du SDK PowerShell ou du registre Windows. À partir du SDK PowerShell, vous pouvez également supprimer les baux actuels. Les cmdlets PowerShell suivantes affectent la location de connexion ; consultez l’aide de la cmdlet pour plus de détails.
- Set-BrokerSite -ConnectionLeasingEnabled $true
|$false - Active ou désactive la location de connexion. Par défaut = $true - Get-BrokerServiceAddedCapability - Affiche « ConnectionLeasing » pour le contrôleur local.
- Get-BrokerLease - Récupère tous les baux actuels ou un ensemble filtré de baux.
- Remove-BrokerLease - Marque un ou un ensemble filtré de baux pour suppression.
- Update-BrokerLocalLeaseCache – Met à jour le cache de location de connexion sur le contrôleur local. Les données sont resynchronisées lors de la prochaine synchronisation.