Product Documentation

Location de connexions

Jul 25, 2017

Important : LHC (cache d'hôte local) est la solution haute disponibilité XenApp et XenDesktop recommandée, plutôt que la location de connexion. Voir la section Cache d'hôte local. La location de connexion ne sera pas incluse à la version actuelle de XenApp et XenDesktop après la prochaine version Long Term Service Release.

Pour vous assurer que la base de données du site est toujours disponible, Citrix recommande de commencer par un déploiement SQL Server ayant une tolérance aux pannes en suivant la haute disponibilité des meilleures pratiques de Microsoft. Cependant, les problèmes et les interruptions réseau peuvent empêcher les Delivery Controller d'accéder à la base de données, ce qui fait que des utilisateurs ne vont pas pouvoir se connecter à leurs applications ou bureaux.

La fonctionnalité de location de connexion 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 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 posséder un nombre important de ressources publiées disponibles, ils n'utilisent souvent que quelques-unes régulièrement. Lorsque vous activez la location de connexion, chaque Controller met en cache les connexions utilisateur vers les applications et bureaux utilisés récemment lors d'opérations normales (lorsque la base de données est disponible).

Les baux générés sur chaque Controller sont téléchargées vers la base de données du site pour la synchronisation périodique vers d'autres Controller du site. Outre le bail, chaque Controller du cache contient l'application, le bureau, l'icône et les informations du travailleur. 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 entre en mode de connexion de location et « relit » les opérations de mise en cache lorsqu'un utilisateur tente de se connecter ou se reconnecter à une application ou d'un bureau récemment utilisé(e) depuis StoreFront.

Les connexions sont mises en cache pour une période de bail de deux semaines. Par conséquent, si la base de données devient non disponible, les bureaux et les applications qui ont été lancés par l'utilisateur dans les deux semaines précédentes restent accessibles pour cet utilisateur via StoreFront. Toutefois, des bureaux et des applications qui n'ont pas été lancés pendant la dernière période de bail de deux semaines ne sont pas accessibles lorsque la base de données n'est pas disponible. Par exemple, si une application a été lancée par un utilisateur il y a trois semaines, son bail a expiré et l'application ne peut pas être lancée par cet utilisateur si la base de données devient désormais indisponible. Les baux de sessions actives de longue durée, ou d'application de déconnexion ou de sessions de bureaux sont étendus afin de ne pas être considérés comme expiré.

Par défaut, la location de connexion affecte l'ensemble du site ; cependant, vous pouvez révoquer tous les baux pour certains utilisateurs, ce qui leur évite d'accéder à des applications ou des bureaux lorsque le Controller se trouve en mode de connexion louée. Plusieurs autres paramètres du Registre s'appliquent sur une base de Controller.

Considérations et limitations

Tandis que la location de connexion peut améliorer la résilience de connexion et la productivité des utilisateurs, il existe des considérations relatives à la disponibilité, opération, et performances d'autres fonctionnalités.

La location de connexion est prise en charge pour les applications et les bureaux hébergés sur le serveur et les bureaux statiques (attribués) ; elle n'est pas prise en charge pour les bureaux VDI regroupés ou pour les utilisateurs qui n'ont pas été attribués à un bureau lorsque la base de données devient indisponible.

Lorsque le Controller se trouve en mode de connexion loué :
  • Les administrateurs ne peuvent pas utiliser Studio, Director, ou la console PowerShell.
  • Le contrôle de l'espace de travail n'est pas disponible. Lorsqu'un utilisateur ouvre une session sur Citrix Receiver, les sessions ne sont pas automatiquement reconnectées, l'utilisateur doit redémarrer l'application.
  • Si un nouveau bail est créé avant que la base de données ne devienne indisponible, mais que les informations de bail n'ont pas encore été synchronisées entre les Controller, l'utilisateur peut ne pas être en mesure de démarrer cette ressource après que la base de données soit devenue indisponible.
  • Les utilisateurs d'applications et de bureaux hébergés sur le serveur peuvent utiliser plus de sessions que leurs limites de session configurées. Par exemple :
    • Une session ne peut pas itinérer lorsqu'un utilisateur la démarre à partir d'une machine (connexion au travers de NetScaler Gateway) lorsque le Controller ne se trouve pas en mode de connexion loué puis se connecte à partir d'une autre machine sur le réseau local où le contrôleur se trouve en mode de connexion loué.
    • La reconnexion de session peut échouer si une application démarre juste avant que la base de données ne devienne indisponible ; dans ce cas, une nouvelle session et instance d'application sont lancées.
  • L'alimentation des bureaux statiques (attribués) n'est pas gérée. Les VDA qui sont mis hors tension lorsque le Controller entre en mode de connexion loué restent indisponibles tant que la connexion à la base de données n'est pas restaurée, sauf si l'administrateur les place 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és. Le pré-lancement de session et la persistance de session ne seront pas terminés selon les seuils configurés alors que la base de données n'est pas disponible.
  • La gestion de la charge dans le site peut être affectée. Les connexions de serveur sont routées vers le VDA le plus récemment utilisé. Les calculateurs de charge (et plus particulièrement les règles du nombre de sessions) risquent d'être dépassés.
  • Le Controller n'entrera pas en mode de connexion louée si vous utilisez SQL Server Management Studio pour mettre la base de données hors connexion. Au lieu de cela, utilisez l'une des instructions Transact-SQL suivantes :
    • ALTER DATABASE <database-name> SET OFFLINE WITH ROLLBACK IMMEDIATE
    • ALTER DATABASE <database-name> SET OFFLINE WITH ROLLBACK AFTER <seconds>

    Les deux instructions annulent toutes les transactions en attente et provoquent la perte de sa connexion à la base de données par le Controller. Le Controller entre alors en mode de connexion louée.

Lorsque la location de connexion est activée, il existe deux brefs intervalles de temps pendant lesquels les utilisateurs ne peuvent pas se connecter ou se reconnecter : (1) du moment où la base de données devient indisponible au moment où le Controller entre en mode de connexion louée, et (2) du moment où le Controller change d'un mode de connexion louée au moment où l'accès à la base de données est entièrement restauré et les VDA ont se sont réinscrits.

Si vous configurez une valeur autre que la valeur par défaut d'itinérance de session, la reconnexion de session retourne à sa valeur par défaut lorsqu'un Controller entre en mode de location de connexion. Pour de plus amples informations, consultez la section Location de connexion et itinérance de session.

Consultez l'article Zones pour de plus amples informations sur l'emplacement où les données de location de connexion sont conservées.

Pour de plus amples informations, consultez la rubrique Considérations à prendre en compte lors de la conception d'une location de connexion XenDesktop 7.6.

Configurer et déployer

Lors de la configuration de votre déploiement pour prendre en charge la location de connexion :
  • La version des VDA doit être de 7.6 au minimum et les catalogues de machines et groupes de mise à disposition qui utilisent ces machines doivent être à ce niveau minimum (ou une version ultérieure prise en charge).
  • La taille de la base de données du site augmentera.
  • Chaque Controller a besoin de plus d'espace disque pour la mise en cache des fichiers du bail.

La location de connexion est activée par défaut.

Vous pouvez activer ou désactiver la location de connexion à partir du kit de développement PowerShell ou du Registre. Depuis le kit de développement PowerShell, vous pouvez également supprimer des baux d'en cours. Les applets de commande PowerShell suivantes affectent la location des connexions ; voir l'aide de l'applet de commande pour plus de détails.
  • Set-BrokerSite -ConnectionLeasingEnabled $true|$false - Active ou désactive la fonction de location de connexion. Valeur par défaut = $true
  • Get-BrokerServiceAddedCapability - Place « ConnectionLeasing » à l'emplacement spécifié pour le Controller local.
  • Get-BrokerLease - Récupère l'ensemble (ou une série filtrée) des baux actuels.
  • Remove-BrokerLease - Marque un bail ou une série filtrée de baux pour suppression.
  • Update-BrokerLocalLeaseCache – Met à jour le cache de location de connexion sur le Controller local. Les données sont resynchronisées lors de la prochaine opération de synchronisation.