Citrix Virtual Apps and Desktops : zones, latence et performances de courtage

Zones

Les déploiements qui couvrent des sites très dispersés connectés par un réseau WAN peuvent être confrontés à des problèmes de latence et de fiabilité du réseau.
Plutôt que de créer plusieurs sites, dont chacun nécessite sa propre base de données SQL Server Site à gérer séparément, vous pouvez configurer des zones au sein d’un seul site.

Impact de la latence sur les performances de négociation

Les utilisateurs finaux lancent des ressources tous les jours. Grâce à l’ajout de zones, les utilisateurs peuvent désormais utiliser des liens à latence plus élevée tant qu’il existe un broker local.
La latence supplémentaire a un impact sur l’expérience de l’utilisateur final. Pour la plupart des tâches effectuées par les utilisateurs, ils constatent la lenteur attendue liée aux allers-retours entre les brokers satellites et la base de données SQL.

Les sessions de courtage présentent un problème, car il est nécessaire de choisir le VDA le moins chargé sur lequel lancer une application.
Il se produit dans le cadre d’une transaction de base de données et nécessite un instantané de toutes les charges actuelles sur les VDA au sein du groupe de mise à disposition.
Un verrou est supprimé sur tous les travailleurs d’un groupe de mise à disposition, ce qui empêche les autres utilisateurs (provoque la sérialisation) d’utiliser les mêmes verrous. Il attend également et bloque les changements d’état du travailleur (tels que les événements de session).

Avec une faible latence, le délai entre la prise des verrous et leur libération est faible. Cependant, à mesure que la latence augmente, la durée pendant laquelle les verrous sont maintenus augmente, et donc le temps nécessaire pour négocier les sessions augmente.

Nous avons examiné différents types de latences et de taux de lancement.
Les latences sont les temps d’aller-retour (RTT) et ont été basées sur les statistiques de latence IP de Verizon . La plupart des RTT sont inférieures aux valeurs maximales répertoriées, mais nous voulions nous assurer que nous faisions des tests avec des RTT utiles.

Les temps aller-retour de 10 millisecondes (ms) couvrent la plupart des retards entre pays, 45 ms pour l’Amérique du Nord, l’Europe et le Japon, 90 ms pour la zone transatlantique, 160 ms pour le transpacifique, l’Amérique latine et l’Asie-Pacifique et 250 ms pour la zone EMEA vers l’Asie-Pacifique.

Nous avons effectué des tests avec différents types de requêtes simultanées, couvrant des valeurs de 12 à 60 par incréments de 12.

Remarque : les sessions VDA sont simulées, car les tests sont axés sur l’impact de la latence sur le broker. Pour ce test, il existe 57 VDA au sein d’un groupe de mise à disposition. Chaque test a tenté de lancer 10 000 utilisateurs.

Résultats RTT à 10 ms          
Demandes simultanées 12 24 36 48 60
Temps de réponse moyen (secondes) 0.9 1.4 1.6 2.1 2.6
Demandes auprès du broker par seconde 14 17.8 22.9 23.2 22.9
Erreurs (%age) 0 0 0 0 0
Il est temps de lancer 10 000 utilisateurs 11m 57s 9m 24s 7m 16s 7m 11s 7m 17s

Comme prévu, 10 ms sont suffisamment rapides pour gérer les charges placées sur le système, et aucune erreur ne s’est produite. C’est le moyen le plus rapide de lancer des utilisateurs. Au taux de lancement maximal de 60 utilisateurs simultanés, les temps de réponse moyens étaient de 2,6 secondes, soit 7 minutes et 17 secondes pour lancer les 10 000 utilisateurs.

Résultats RTT à 45 ms          
Demandes simultanées 12 24 36 48 60
Temps de réponse moyen (secondes) 1.7 3.1 4.3 6.4 7.3
Demandes auprès du broker par seconde 7.1 7.8 8.4 7.5 8.2
Erreurs (%age) 0 0 0 0.01 0.01
Il est temps de lancer 10 000 utilisateurs 23m 28s 21m 19s 19m 51s 22m 15s 20m 19s

Avec 45 ms, les résultats étaient toujours bons. À des taux de lancement très élevés, un ou deux utilisateurs ont constaté une erreur.

Remarque : L’impact de la sérialisation peut être vu sur les temps de réponse, avec une augmentation de 1,7 secondes à 7,3 secondes pour broker une session. Le temps total nécessaire pour négocier 10 000 utilisateurs était de 20 à 23 minutes.

Résultats RTT à 90 ms          
Demandes simultanées 12 24 36 48 60
Temps de réponse moyen (secondes) 2.9 6.4 9.5 12.9 16.2
Demandes auprès du broker par seconde 4.1 3.7 3.8 3.7 3.7
Erreurs (%age) 0 0 0 0.01 0.01
Il est temps de lancer 10 000 utilisateurs 40m 30s 44m 29s 44m 11s 44m 55s 45m 04s

Les résultats de 90 ms comportaient peu d’erreurs.
L’impact des transactions en cas de latence devient plus évident, les utilisateurs constatant un temps moyen acceptable de 2,9 secondes pour négocier une session avec 12 demandes simultanées, passant à 16,2 secondes, un temps inacceptable pour le courtage d’une session avec 60 demandes simultanées.
Dans ce cas, il est plus avantageux de courter les utilisateurs à un taux inférieur. Il a fallu 40 à 45 minutes pour lancer les 10 000 utilisateurs.

Résultats RTT à 160 ms          
Demandes simultanées 12 24 36 48 60
Temps de réponse moyen (secondes) 5.7 11.4 17.3 23.2 28.0
Demandes auprès du broker par seconde 2.1 2.1 2.1 2.1 2.1
Erreurs (%age) 0 0 0.12 4.0 17.7
Il est temps de lancer 10 000 utilisateurs 1 h 19min 0s 1 h 19m 27s 1 h 19m 55s 1 h 20m 26s S/O

Avec les 160 ms, nous commençons à voir des erreurs importantes se produire avec des taux de lancement plus élevés, avec 4 % d’erreurs pour 48 demandes et 17,7 % d’erreurs pour 60 demandes, ainsi que des temps de réponse approchant les 30 secondes.
Toutefois, jusqu’à 36 demandes, le taux d’erreur est de 0,1 % avec un temps de courtage moyen de 17 secondes.

Remarque : Il est difficile d’évaluer le temps de lancement de 60 demandes, car il est difficile de prendre en compte 17 % d’échec.

Compte tenu de cette latence, nous vous recommandons de ne pas transmettre 24 demandes simultanées. De plus, la taille du site peut être un facteur : le lancement de 1 000 utilisateurs prendrait environ 8 minutes. Cela passerait à 1 heure et 20 minutes pour 10 000 utilisateurs. Nous ne recommandons donc pas un site de grande taille avec un tel niveau de latence par rapport à la base de données.

Résultats RTT à 250 ms          
Demandes simultanées 12 24 36 48 60
Temps de réponse moyen (secondes) 9.3 15.4 26.7 - -
Demandes auprès du broker par seconde 1.3 1.6 1.3 - -
Erreurs (%age) 0 0 4.6 42.8 99.0
Il est temps de lancer 10 000 utilisateurs 2h 8m 33s 1h 46m 52s 2h 3min 46s S/O S/O

Avec une latence aussi élevée, de nombreux délais d’attente se sont produits à des taux de lancement simultanés plus élevés. Sur 48 demandes, 42,8 % des demandes ont échoué. À 60 demandes, les délais d’attente étaient si courants que le site était inutilisable, 99 % des demandes ayant échoué. Les seuls taux de lancement acceptables étaient 12 et 24 demandes. Il serait difficile de recommander le déploiement d’un site de grande taille avec un tel niveau de latence : le lancement de 1 000 utilisateurs a pris 13 minutes avec 12 demandes simultanées et 11 minutes avec 24 demandes simultanées. Cela prendrait jusqu’à 2 heures et 8 minutes pour 10 000 utilisateurs.

Limitation des demandes

Si vous devez travailler avec une latence élevée et que vous constatez que trop de délais d’attente se produisent, une clé de registre a été ajoutée à XenApp et XenDesktop 7.7 pour lui permettre de gérer uniquement un nombre fixe de demandes de courtage simultanées. StoreFront réessaiera les demandes dépassant la limite après quelques secondes. Cela permet d’annuler les demandes, réduisant ainsi les files d’attente de verrouillage. Cependant, certains utilisateurs peuvent finir par voir des délais de lancement prolongés, car ils n’ont toujours pas de chance et leur demande est toujours annulée.

La clé est un DWORD et doit être stockée dans :HKEY_LOCAL_MACHINE\Software\Citrix\DesktopServer\ThrottledRequestAddressMaxConcurrentTransactions

Si la clé n’existe pas, aucune limite n’est imposée aux demandes de courtage.

Remarque : La clé étant attribuée à chaque Delivery Controller, le nombre total de demandes sur le SQL Server doit être réparti entre les contrôleurs distants.

Résumé

Le courtage fonctionne sur la latence, mais cette latence doit être prise en compte pour le dimensionnement d’une zone distante. Si une zone est grande, il peut tout de même être souhaitable de conserver une base de données locale pour cette zone. Si la zone est petite, l’utilisation d’une zone distante peut fonctionner correctement et réduire les coûts de gestion sans affecter l’expérience de l’utilisateur final.

Nous recommandons que vos zones aient un RTT inférieur à 250 ms ; au-delà, vous devriez envisager de configurer différents sites.

Cet article a été modifié à partir d’un billet de blog écrit par Chris Gilbert. Pour lire le blog original et voir les commentaires, rendez-vous sur https://www.citrix.com/blogs/2016/02/09/zones-latency-and-brokering-performance-2/.

Citrix Virtual Apps and Desktops : zones, latence et performances de courtage