Considérations relatives à l’évolutivité

L’enregistrement de session est un système hautement évolutif qui gère des milliers ou des dizaines de milliers de sessions. L’installation et l’exécution de l’enregistrement de session nécessitent peu de ressources supplémentaires au-delà de ce qui est nécessaire pour exécuter Citrix Virtual Apps and Desktops™ ou Citrix DaaS (anciennement service Citrix Virtual Apps and Desktops). Cependant, nous vous recommandons tout de même de prendre en compte les performances de votre système si vous prévoyez d’enregistrer de nombreuses sessions. Ou bien, les sessions que vous prévoyez d’enregistrer pourraient générer des fichiers de session volumineux (par exemple, des applications graphiquement intenses).

Cet article explique comment l’enregistrement de session atteint une évolutivité élevée et comment vous pouvez tirer le meilleur parti de votre système d’enregistrement au coût le plus bas.

Pourquoi l’enregistrement de session est très évolutif

Il existe deux raisons principales pour lesquelles l’enregistrement de session est très évolutif par rapport aux produits concurrents :

• Taille de fichier réduite

  Un fichier de session enregistré avec l’enregistrement de session est très compact. Il est de plusieurs ordres de grandeur plus petit qu’un enregistrement vidéo équivalent réalisé avec des solutions de capture d’écran. La bande passante réseau, l’espace disque et les IOPS disque nécessaires pour transporter/stocker un fichier de session enregistré sont généralement au moins 10 fois inférieurs à ceux d’un fichier vidéo équivalent.

  La petite taille des fichiers de session enregistrés signifie un rendu plus rapide et plus fluide des images vidéo. Les enregistrements sont également sans perte et ne présentent aucune pixellisation, ce qui est courant dans la plupart des formats vidéo compacts. Le texte des enregistrements est facile à lire pendant la lecture, comme dans les sessions originales. Pour maintenir des tailles de fichier réduites, l’enregistrement de session n’enregistre pas les images clés dans les fichiers. L’enregistrement de session peut supprimer les paquets H.264 lors de l’enregistrement de sessions comportant des vidéos en cours d’exécution, réduisant ainsi la taille des fichiers d’enregistrement. Pour utiliser cette fonctionnalité, définissez HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\SmartAuditor\Agent\DropH264Enabled sur 1 sur l’agent d’enregistrement de session et définissez la valeur de Utiliser le codec vidéo pour la compression sur Pour les régions en évolution active.

  

• Faible traitement requis pour générer des fichiers

  Un fichier de session enregistré contient les données du protocole ICA® pour une session qui est extraite virtuellement dans son format natif. Le fichier capture le flux de données du protocole ICA utilisé pour communiquer avec l’application Citrix Workspace™. Il n’est pas nécessaire d’exécuter des composants logiciels de transcodage ou d’encodage coûteux pour modifier le format des données en temps réel. La faible quantité de traitement est également importante pour l’évolutivité du VDA. Elle garantit que l’expérience de l’utilisateur final est maintenue lorsque de nombreuses sessions sont enregistrées à partir du même VDA.

  De plus, seuls les canaux virtuels ICA qui peuvent être lus sont enregistrés, ce qui entraîne une optimisation supplémentaire. Par exemple, les canaux d’imprimante et de mappage de lecteur client ne sont pas enregistrés. Ces canaux peuvent générer de grands volumes de données sans aucun avantage pour la lecture vidéo.

Estimer les débits d’entrée et de traitement des données

Le serveur d’enregistrement de session est le point de collecte central des fichiers de session enregistrés. Chaque machine exécutant un VDA de système d’exploitation multi-session avec l’enregistrement de session activé envoie les données de session enregistrées au serveur d’enregistrement de session. L’enregistrement de session peut gérer de grands volumes de données et tolérer les pics et les pannes. Mais il existe des limites physiques à la quantité de données qu’un seul serveur peut gérer.

Tenez compte de la quantité de données que vous envoyez à chaque serveur d’enregistrement de session. Estimez la rapidité avec laquelle les serveurs peuvent traiter et stocker les données. Le débit auquel votre système peut stocker les données entrantes doit être supérieur au débit d’entrée des données.

Pour estimer votre débit d’entrée de données, effectuez le calcul suivant :

1. Multipliez le nombre de sessions enregistrées par la taille moyenne de la session.
2. Divisez le produit par la durée pendant laquelle vous enregistrez les sessions.

Par exemple, vous pourriez enregistrer 5 000 sessions Microsoft Outlook de 20 Mo chacune sur une journée de travail de 8 heures. Dans ce cas, le débit d’entrée de données est d’environ 28 Mbps (5 000 sessions multipliées par 20 Mo, divisées par 8 heures, divisées par 3 600 secondes par heure, et multipliées par 8 pour la conversion en Mbps). Un serveur Session Recording typique connecté à un réseau local de 100 Mbps avec un espace disque suffisant pour stocker les données enregistrées peut traiter les données à environ 5,0 Mbps. Ce débit est le débit de traitement basé sur les limites physiques imposées par les IOPS du disque et du réseau. Dans l’exemple, le débit de traitement (5,0 Mbps) est inférieur au débit d’entrée (28 Mbps), il est donc impossible d’enregistrer les 5 000 sessions Outlook.

La quantité de données par session varie considérablement en fonction de ce qui est enregistré. D’autres facteurs tels que la résolution de l’écran, la profondeur de couleur et le mode graphique ont également un impact. Une session où un logiciel de CAO est exécuté génère probablement un enregistrement beaucoup plus volumineux qu’une session où l’utilisateur envoie et reçoit des e-mails dans Outlook. Par conséquent, l’enregistrement du même nombre de sessions de CAO peut générer un débit d’entrée élevé et nécessiter l’utilisation de davantage de serveurs Session Recording.

Pics et pannes

L’exemple précédent suppose un débit de données uniforme simple, mais n’explique pas comment le système gère les courtes périodes d’activité plus élevée, appelées pics d’activité. Un pic d’activité peut se produire lorsque tous les utilisateurs se connectent en même temps le matin, connu sous le nom de « coup de feu de 9 heures ». Il peut également se produire lorsqu’ils reçoivent le même e-mail dans leur boîte de réception Outlook en même temps. Le débit de traitement de 5,0 Mbps du serveur Session Recording est très insuffisant pour faire face à cette demande soudaine.

L’agent Session Recording exécuté sur chaque VDA utilise Microsoft Message Queuing (MSMQ) pour envoyer les données enregistrées au Storage Manager exécuté sur le serveur Session Recording central. Les données sont envoyées selon un mécanisme de stockage et de retransmission, similaire à la manière dont un e-mail est livré entre l’expéditeur, le serveur de messagerie et le destinataire. Si le serveur Session Recording ou le réseau ne peut pas gérer un débit élevé de données lors de pics d’activité, les données enregistrées sont temporairement stockées. Le message de données peut être temporairement stocké dans la file d’attente sortante sur le VDA si le réseau est encombré. L’autre cas est que les données ont traversé le réseau mais que le Storage Manager est occupé à traiter d’autres messages. Dans ce cas, le message de données est stocké dans la file d’attente de réception du serveur Session Recording.

MSMQ sert également de mécanisme de tolérance aux pannes. Si le serveur Session Recording tombe en panne ou si le lien est rompu, les données enregistrées restent dans la file d’attente sortante de chaque VDA. Lorsque la panne est résolue, toutes les données en file d’attente sont envoyées ensemble. MSMQ vous permet également de mettre un serveur hors ligne pour une mise à niveau ou une maintenance sans interrompre l’enregistrement de session et sans perdre de données.

La principale limitation de MSMQ est que l’espace disque pour le stockage temporaire des messages de données est fini. Cette limitation détermine la durée maximale d’un pic d’activité, d’une panne ou d’un événement de maintenance avant que les données ne soient finalement perdues. Le système global peut continuer après une perte de données, mais dans cette situation, les enregistrements individuels présentent des blocs de données manquants. Un fichier avec des données manquantes est toujours lisible, mais seulement jusqu’au point où les données ont été perdues pour la première fois. Notez ce qui suit :

• L’ajout d’espace disque supplémentaire à chaque serveur, en particulier au serveur Session Recording, et sa mise à disposition pour MSMQ peut augmenter la tolérance aux pics d’activité et aux pannes.

• Il est important de configurer le paramètre Durée de vie du message (Message Life) pour chaque agent Session Recording à un niveau approprié (sous l’onglet Connexions dans les propriétés de l’agent Session Recording). La valeur par défaut est de 7 200 secondes (deux heures). Cela signifie que chaque message de données enregistré dispose de deux heures pour atteindre le Storage Manager avant que celui-ci ne le supprime et n’endommage le fichier d’enregistrement. Avec plus d’espace disque disponible (ou moins de sessions à enregistrer), vous pouvez choisir d’augmenter cette valeur. La valeur maximale est de 365 jours.

L’autre limitation de MSMQ est que lorsque les données s’accumulent, il y a des IOPS disque supplémentaires dans la file d’attente pour lire et écrire les messages de données. Normalement, le Storage Manager reçoit et traite les données directement depuis le réseau, sans que les messages de données ne soient jamais écrits sur le disque. Le stockage des données implique une seule opération d’écriture sur le disque qui ajoute le fichier de session enregistré. Lorsque les données sont en retard, les IOPS disque sont triplées : chaque message doit être écrit sur le disque, lu depuis le disque et écrit dans le fichier. Comme le Storage Manager est fortement lié aux IOPS, le débit de traitement du serveur Session Recording diminue jusqu’à ce que l’arriéré de messages soit effacé. Pour atténuer les effets de ces IOPS supplémentaires, adoptez les recommandations suivantes :

• Assurez-vous que le disque sur lequel MSMQ stocke les messages est différent des dossiers de stockage des fichiers d’enregistrement. Même si le trafic de bus IOPS est triplé, la baisse du débit de traitement réel n’est jamais aussi sévère.

• Planifiez les pannes uniquement pendant les heures creuses. En fonction des contraintes budgétaires, suivez les approches reconnues pour la construction de serveurs à haute disponibilité. Ces approches incluent l’utilisation d’une alimentation sans interruption (UPS), de cartes réseau doubles, de commutateurs redondants, et de mémoire et disques remplaçables à chaud.

Concevoir pour une capacité de réserve

Le débit des données de session enregistrées est peu susceptible d’être uniforme, des rafales et des pannes peuvent survenir, et la suppression des arriérés de messages est coûteuse en IOPS. Pour cette raison, concevez chaque serveur Session Recording avec une grande capacité de réserve. L’ajout de serveurs supplémentaires ou l’amélioration des spécifications des serveurs existants, comme décrit dans les sections ultérieures, vous apporte toujours une capacité supplémentaire. La règle générale est de faire fonctionner chaque serveur Session Recording à un maximum de 50 % de sa capacité totale. Dans l’exemple précédent, si le serveur peut traiter 5,0 Mbps, visez à ce que le système ne fonctionne qu’à 2,5 Mbps.

Arriérés et lecture en direct

La lecture en direct se produit lorsqu’un réviseur ouvre un enregistrement de session pour le lire alors que la session est toujours active. Pendant la lecture en direct, l’agent Session Recording responsable passe en mode de diffusion en continu pour cette session. Les données d’enregistrement sont envoyées immédiatement au Storage Manager sans mise en mémoire tampon interne. Étant donné que le fichier d’enregistrement est constamment mis à jour, le lecteur peut continuer à être alimenté avec les dernières données de la session en direct. Cependant, les données envoyées de l’agent au Storage Manager passent par MSMQ, de sorte que les règles de mise en file d’attente décrites précédemment s’appliquent. Un problème peut survenir dans ce scénario. Lorsque MSMQ est en retard, les nouvelles données enregistrées disponibles pour la lecture en direct sont mises en file d’attente comme tous les autres messages de données. Le réviseur peut toujours lire le fichier, mais la visualisation des dernières données enregistrées en direct est retardée. Si la lecture en direct est une fonctionnalité importante pour les réviseurs, assurez une faible probabilité d’arriéré. Vous pouvez concevoir une capacité de réserve et une tolérance aux pannes dans votre déploiement.

Évolutivité du système

Session Recording ne réduit jamais les performances des sessions et n’arrête jamais les sessions en réponse aux arriérés de données enregistrées. Le maintien de l’expérience utilisateur final et l’évolutivité sur un seul serveur sont primordiaux dans la conception du système Session Recording. Si le système d’enregistrement devient irréversiblement surchargé, les données de session enregistrées sont supprimées. L’enregistrement des sessions ICA a un faible impact sur les performances et l’évolutivité des VDA. L’ampleur de l’impact dépend de la plateforme, de la mémoire disponible et de la nature graphique des sessions enregistrées. Avec la configuration suivante, vous pouvez vous attendre à un impact sur l’évolutivité d’un seul serveur compris entre 1 % et 5 %. En d’autres termes, si un serveur peut héberger 100 utilisateurs sans Session Recording installé, il peut héberger 95 à 99 utilisateurs après l’installation :

• Serveur 64 bits avec 8 Go de RAM exécutant un VDA de système d’exploitation multi-session
• Toutes les sessions exécutant des applications de productivité Office, telles qu’Outlook et Excel
• L’utilisation des applications est active et soutenue
• Toutes les sessions sont enregistrées comme configuré par les stratégies Session Recording

Avec moins de sessions enregistrées ou une activité de session moins soutenue et plus sporadique, l’impact est moindre. Souvent, l’impact sur l’évolutivité est négligeable et la densité d’utilisateurs par serveur reste la même. Comme mentionné précédemment, le faible impact résulte des exigences de traitement simples des composants Session Recording sur chaque VDA. Les données enregistrées sont extraites de la pile de sessions ICA et envoyées telles quelles au serveur Session Recording via MSMQ. Il n’y a pas d’encodage coûteux des données.

Il y a une légère surcharge liée à l’utilisation de Session Recording même lorsqu’aucune session n’est enregistrée. Si vous n’allez pas enregistrer de sessions à partir d’un serveur particulier, vous pouvez désactiver l’enregistrement sur ce serveur. La suppression de Session Recording est une solution. Une approche moins invasive consiste à décocher la case Activer l’enregistrement de session pour cette machine VDA sous l’onglet Session Recording dans les Propriétés de l’agent Session Recording. Si l’enregistrement de session est requis à l’avenir, cochez à nouveau cette case.

Mesure du débit

Vous pouvez mesurer le débit des données de session enregistrées du VDA émetteur vers le serveur Session Recording récepteur. Une approche simple et efficace consiste à observer la taille des fichiers d’enregistrement et le taux auquel l’espace disque sur le serveur Session Recording est consommé. Le volume de données écrites sur le disque reflète fidèlement le volume de trafic réseau généré. L’outil Moniteur de performances Windows (perfmon.exe) dispose de compteurs système standard que vous pouvez observer en plus de certains compteurs fournis par Session Recording. Les compteurs peuvent être utilisés pour mesurer le débit et identifier les goulots d’étranglement et les problèmes système. Le tableau suivant présente certains des compteurs de performances les plus utiles.

Matériel du serveur d’enregistrement de session

Vous pouvez augmenter la capacité de votre déploiement en sélectionnant soigneusement le matériel du serveur d’enregistrement de session. Vous avez deux choix : la mise à l’échelle verticale (en augmentant la capacité de chaque serveur) ou la mise à l’échelle horizontale (en ajoutant d’autres serveurs). Dans les deux cas, votre objectif est d’augmenter l’évolutivité au coût le plus bas.

Évolutivité verticale

Lors de l’examen d’un seul serveur d’enregistrement de session, tenez compte des meilleures pratiques suivantes pour garantir des performances optimales pour les budgets disponibles. Le système dépend des IOPS qui peuvent assurer un débit élevé de données enregistrées du réseau vers le disque. Il est donc important d’investir dans le matériel réseau et disque approprié. Pour un serveur d’enregistrement de session hautes performances, un processeur double ou un processeur double cœur est recommandé, mais peu de gains sont obtenus avec des spécifications plus élevées. Une architecture de processeur 64 bits est recommandée, mais un type de processeur x86 convient également. 4 Go de RAM sont recommandés, mais là encore, l’ajout de mémoire supplémentaire n’apporte que peu d’avantages.

Évolutivité horizontale

Même avec les meilleures pratiques de mise à l’échelle verticale, il existe des limites de performances et d’évolutivité qui peuvent être atteintes avec un seul serveur d’enregistrement de session lors de l’enregistrement de nombreuses sessions. Il peut être nécessaire d’ajouter des serveurs supplémentaires pour répondre à la charge. Vous pouvez installer plusieurs serveurs d’enregistrement de session sur différentes machines pour que les serveurs d’enregistrement de session fonctionnent comme un pool d’équilibrage de charge. Dans ce type de déploiement, les serveurs d’enregistrement de session partagent le stockage et la base de données. Pour distribuer la charge, pointez les agents d’enregistrement de session vers l’équilibreur de charge responsable de la répartition de la charge de travail.

Capacité réseau

Une liaison réseau de 100 Mbit/s convient pour connecter un serveur d’enregistrement de session. Une connexion Ethernet Gb peut améliorer les performances, mais n’entraîne pas des performances 10 fois supérieures à celles d’une liaison de 100 Mbit/s. En pratique, le gain de débit est moindre.

Assurez-vous que les commutateurs réseau utilisés par l’enregistrement de session ne sont pas partagés avec des applications tierces susceptibles de concurrencer la bande passante réseau disponible. Idéalement, les commutateurs réseau sont dédiés à l’utilisation avec le serveur d’enregistrement de session. Si la congestion du réseau s’avère être le goulot d’étranglement, une mise à niveau du réseau est un moyen relativement peu coûteux d’augmenter l’évolutivité du système.

Stockage

L’investissement dans le matériel de disque et de stockage est le facteur le plus important pour l’évolutivité du serveur. Plus les données peuvent être écrites rapidement sur le disque, plus les performances globales du système sont élevées. Lors de la sélection d’une solution de stockage, accordez plus d’attention aux performances d’écriture qu’aux performances de lecture.

Stockez les données sur un RAID ou un SAN.

Remarque :

Le stockage de données sur un NAS, basé sur des protocoles de fichiers tels que SMB et NFS, peut avoir des implications en matière de performances et de sécurité. Utilisez la dernière version du protocole en place pour éviter les implications en matière de sécurité et effectuez des tests de montée en charge pour garantir des performances adéquates.

Pour une configuration de lecteur local, visez un contrôleur de disque avec mémoire cache intégrée. La mise en cache permet au contrôleur d’utiliser le tri ascenseur lors de l’écriture différée. Cela minimise le mouvement des têtes de disque et garantit que les opérations d’écriture sont terminées sans attendre la fin de l’opération physique du disque. Cela peut améliorer considérablement les performances d’écriture à un coût supplémentaire minimal. Cependant, la mise en cache soulève le problème de la perte de données après une panne de courant. Pour garantir l’intégrité des données et du système de fichiers, envisagez un système de batterie de secours pour le contrôleur de disque de mise en cache.

Envisagez d’utiliser une solution de stockage RAID appropriée. Il existe de nombreux niveaux RAID disponibles en fonction des exigences de performance et de redondance. Le tableau suivant spécifie chacun des niveaux RAID et l’applicabilité de chaque norme à l’enregistrement de session.

Les RAID 0 et RAID 3 sont les niveaux RAID les plus recommandés. Les RAID 1 et RAID 5 sont des normes populaires mais ne sont pas recommandés pour l’enregistrement de session. Le RAID 10 offre certains avantages en termes de performances, mais il est trop coûteux pour le gain supplémentaire.

Décidez du type et des spécifications des disques durs. Les disques IDE/ATA et les disques externes USB ou Firewire ne conviennent pas à l’enregistrement de session. Le choix principal se fait entre SATA et SCSI. Les disques SATA offrent des taux de transfert raisonnablement élevés à un coût par Mo réduit par rapport aux disques SCSI. Cependant, les disques SCSI offrent de meilleures performances et sont plus courants dans les déploiements de serveurs. Les solutions RAID de serveur prennent principalement en charge les disques SCSI, mais certains produits RAID SATA sont désormais disponibles. Lors de l’évaluation des spécifications des produits de disques durs, tenez compte de la vitesse de rotation du disque et des autres caractéristiques de performance.

Étant donné que l’enregistrement de milliers de sessions par jour peut consommer des quantités importantes d’espace disque, vous devez choisir entre la capacité globale et les performances. D’après l’exemple précédent, l’enregistrement de 5 000 sessions Outlook sur une journée de travail de 8 heures consomme environ 100 Go d’espace de stockage. Pour stocker 10 jours d’enregistrements (soit 50 000 fichiers de session enregistrés), vous avez besoin de 1 000 Go (1 To). Cette pression sur l’espace disque peut être atténuée en raccourcissant la période de rétention avant d’archiver ou de supprimer les anciens enregistrements. Si 1 To d’espace disque est disponible, une période de rétention de sept jours est raisonnable, garantissant que l’utilisation de l’espace disque reste autour de 700 Go, avec 300 Go restants comme tampon pour les jours de forte activité. Dans l’enregistrement de session, l’archivage et la suppression de fichiers sont pris en charge avec l’utilitaire ICLDB. Il a une période de rétention minimale de deux jours. Vous pouvez planifier une tâche en arrière-plan à exécuter une fois par jour pendant les heures creuses. Pour plus d’informations sur les commandes ICLDB et l’archivage, consultez Gérer vos enregistrements de base de données.

L’alternative à l’utilisation de disques et de contrôleurs locaux est d’utiliser une solution de stockage SAN basée sur l’accès disque au niveau bloc. Pour le serveur d’enregistrement de session, le tableau de disques apparaît comme un lecteur local. Les SAN sont plus coûteux à configurer, mais comme le tableau de disques est partagé, les SAN ont l’avantage d’une gestion simplifiée et centralisée. Il existe deux principaux types de SAN : Fibre Channel et iSCSI. iSCSI est essentiellement SCSI sur TCP/IP et gagne en popularité par rapport à Fibre Channel depuis l’introduction de l’Ethernet Gb.

Évolutivité de la base de données

Le volume de données envoyé à la base de données d’enregistrement de session est faible car la base de données ne stocke que les métadonnées des sessions enregistrées. Les fichiers des sessions enregistrées eux-mêmes sont écrits sur un disque séparé. Généralement, chaque session enregistrée ne nécessite qu’environ 1 Ko d’espace dans la base de données, à moins que l’API d’événements d’enregistrement de session ne soit utilisée pour insérer des événements consultables dans la session.

Les éditions Express de Microsoft SQL Server (2019, 2017, 2016, 2014, 2012 et 2008 R2) imposent une limitation de taille de base de données de 10 Go. À raison de 1 Ko par session d’enregistrement, la base de données peut cataloguer environ 4 000 000 de sessions. Les autres éditions de Microsoft SQL Server n’ont pas de restrictions de taille de base de données et sont limitées uniquement par l’espace disque disponible. À mesure que le nombre de sessions dans la base de données augmente, les performances de la base de données et la vitesse des recherches ne diminuent que de manière négligeable.

Si vous n’effectuez pas de personnalisations via l’API d’événements d’enregistrement de session, chaque session enregistrée génère quatre transactions de base de données : deux au début de l’enregistrement, une lorsque l’utilisateur se connecte à la session en cours d’enregistrement, et une lorsque l’enregistrement se termine. Si vous utilisez l’API d’événements d’enregistrement de session pour personnaliser les sessions, chaque événement consultable enregistré génère une transaction. Étant donné que même le déploiement de base de données le plus simple peut gérer des centaines de transactions par seconde, la charge de traitement sur la base de données est peu susceptible d’être excessive. L’impact est suffisamment léger pour que la base de données d’enregistrement de session puisse s’exécuter sur le même SQL Server que d’autres bases de données, y compris la base de données du magasin de données Citrix Virtual Apps and Desktops.

Si votre déploiement d’enregistrement de session nécessite que plusieurs millions de sessions enregistrées soient cataloguées dans la base de données, suivez les directives de Microsoft en matière d’évolutivité de SQL Server.