Considérations sur 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. Cependant, si vous prévoyez d’utiliser l’enregistrement de session pour enregistrer de nombreuses sessions ou si les sessions que vous prévoyez d’enregistrer peuvent générer des fichiers de session volumineux (par exemple, des applications graphiquement intenses), tenez compte des performances de votre système lors de la planification de votre déploiement d’enregistrement de session.

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 si évolutif

Il y a 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 et stocker chaque fichier d’enregistrement de session 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 permet 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 et 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 car ils peuvent générer de grands volumes de données sans aucun avantage pour la lecture vidéo.

Estimer les taux 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 rafales 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 et de la rapidité avec laquelle les serveurs peuvent traiter et stocker ces 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, multipliez le nombre de sessions enregistrées par la taille moyenne de chaque session enregistrée et divisez 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 3,5 Mbps. (5 000 sessions multipliées par 20 Mo divisées par 8 heures, divisées par 3 600 secondes par heure.) Un serveur d’enregistrement de session typique connecté à un réseau local (LAN) de 100 Mbps avec un espace disque suffisant pour stocker les données enregistrées peut traiter les données à environ 5,0 Mbps, en fonction des limites physiques imposées par les IOPS du disque et du réseau. Ce débit est le débit de traitement. Dans l’exemple, le débit de traitement (5,0 Mbps) est supérieur au débit d’entrée (3,5 Mbps), de sorte que l’enregistrement des 5 000 sessions Outlook est réalisable.

La quantité de données par session varie considérablement en fonction de ce qui est enregistré, tandis que 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 exécutant un logiciel de CAO où l’activité graphique est constamment élevée génère probablement un enregistrement beaucoup plus volumineux qu’une session dans laquelle l’utilisateur final envoie et reçoit des e-mails dans Microsoft 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 plusieurs serveurs d’enregistrement de session.

Pics d’activité et pannes

The previous example assumes a simple uniform throughput of data but does not explain how the system deals with short periods of higher activity, known as bursts. A burst might occur when all users log on at the same time in the morning, known as the 9 o’clock rush, or when they receive the same email in their Outlook inbox at once. The 5.0 Mbps processing rate of the Session Recording Server is highly inadequate at dealing with this sudden demand.

The Session Recording Agent running on each VDA uses Microsoft Message Queuing (MSMQ) to send recorded data to the Storage Manager running on the central Session Recording Server. The data is sent in a store-and-forward manner similar to how an email is delivered between the sender, mail server, and receiver. If the Session Recording Server or the network cannot handle the high rate of data in a burst, the recorded session data is temporarily stored until the backlog of data messages is cleared. The data message might be temporarily stored in the outgoing queue on the VDA if the network is congested, or stored on the Session Recording Server’s receiving queue if the data has traversed the network but the Storage Manager is still busy processing other messages.

MSMQ also serves as a fault tolerance mechanism. If the Session Recording Server goes down or the link is broken, recorded data is held in the outgoing queue on each VDA. When the fault is rectified, all queued data is sent together. The use of MSMQ also allows you to take a Session Recording Server offline for upgrade or maintenance without interrupting the recording of existing sessions and losing data.

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 des données ne soient finalement perdues. Le système global peut continuer à fonctionner après une perte de données, mais dans cette situation, les enregistrements individuels présentent des morceaux 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 :

• Adding more disk space to each server, especially the Session Recording Server, and making it available to MSMQ can increase the tolerance to bursts and faults.

• It is important to configure the Message Life setting for each Session Recording Agent to an appropriate level (on the Connections tab in Session Recording Agent Properties). The default value of 7,200 seconds (two hours) means that each recorded data message has two hours to reach the Storage Manager before it is discarded and recording files are damaged. With more disk space available (or fewer sessions to record), you can choose to increase this value. The maximum value is 365 days.

The other limitation with MSMQ is that when data backlogs, there is extra disk IOPS in the queue to read and write data messages. Under normal conditions, the Storage Manager receives and processes data from the network directly without the data message ever being written to disk. Storing the data involves a single write operation to disk that appends the recorded session file. When data is backlogged, the disk IOPS is tripled: each message must be written to disk, read from disk, and written to file. As the Storage Manager is heavily IOPS bound, the processing rate of the Session Recording Server drops until the backlog of messages is cleared. To mitigate the effects of this extra IOPS, adopt the following recommendations:

• 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.

• N’effectuez les pannes planifiées qu’en dehors des heures de pointe. En fonction des contraintes budgétaires, suivez les approches reconnues pour la construction de serveurs à haute disponibilité. Ces approches incluent l’utilisation d’onduleurs (UPS), de cartes réseau doubles (NIC), de commutateurs redondants, et de mémoire et disques remplaçables à chaud.

Concevoir pour une capacité de réserve

Le débit de données des sessions enregistrées est peu susceptible d’être uniforme, des pics d’activité et des pannes peuvent survenir, et la résorption des arriérés de messages est coûteuse en IOPS. Pour cette raison, concevez chaque serveur d’enregistrement de session 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 d’enregistrement de session à 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. Au lieu d’enregistrer 5 000 sessions Outlook qui génèrent 3,5 Mbps sur un seul serveur d’enregistrement de session, réduisez à 3 500 sessions qui ne génèrent qu’environ 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 d’enregistrement de session responsable de la session passe en mode de diffusion en continu pour cette session, et les données d’enregistrement sont envoyées immédiatement au Gestionnaire de stockage 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 Gestionnaire de stockage transitent 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 l’affichage des dernières données enregistrées en direct est retardé. Si la lecture en direct est une fonctionnalité importante pour les réviseurs, assurez une faible probabilité de retard en concevant une capacité de réserve et une tolérance aux pannes dans votre déploiement.

Évolutivité de Citrix Virtual Apps™ et Desktops

L’enregistrement de session ne réduit jamais les performances de la session et n’arrête jamais les sessions en réponse aux retards de données enregistrées. Le maintien de l’expérience utilisateur final et de l’évolutivité d’un seul serveur est primordial dans la conception du système d’enregistrement de session. Si le système d’enregistrement devient irréversiblement surchargé, les données de session enregistrées sont supprimées. Des tests d’évolutivité approfondis effectués par Citrix révèlent que l’impact de l’enregistrement des sessions ICA sur les performances et l’évolutivité des serveurs Citrix Virtual Apps et Desktops est faible. L’ampleur de l’impact dépend de la plate-forme, 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 l’enregistrement de session 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 d’enregistrement de session

Si moins de sessions sont enregistrées ou si l’activité de la session est moins soutenue et plus sporadique, l’impact est moindre. Dans de nombreux cas, 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 est dû aux exigences de traitement simples des composants d’enregistrement de session installés sur chaque VDA. Les données enregistrées sont extraites de la pile de sessions ICA et envoyées telles quelles au serveur d’enregistrement de session 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 l’enregistrement de session même lorsqu’aucune session n’est enregistrée. Bien que l’impact soit faible, si vous êtes certain qu’aucune session n’est enregistrée à partir d’un serveur particulier, vous pouvez désactiver l’enregistrement sur ce serveur. La suppression de l’enregistrement de session est une solution. Une approche moins invasive consiste à désélectionner la case à cocher Activer l’enregistrement de session pour cette machine VDA sous l’onglet Enregistrement de session dans les propriétés de l’agent d’enregistrement de session. Si l’enregistrement de session est requis à l’avenir, cochez à nouveau cette case.

Mesure du débit

Il existe différentes façons de mesurer le débit des données de session enregistrées du VDA émetteur au serveur d’enregistrement de session récepteur. L’une des approches les plus simples et les plus efficaces consiste à observer la taille des fichiers enregistrés et le taux de consommation de l’espace disque sur le serveur d’enregistrement de session. 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 d’une gamme de compteurs système standard qui peuvent être observés en plus de certains compteurs fournis par l’enregistrement de session. 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 utilisé pour le 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 plus de serveurs). En faisant l’un ou l’autre de ces choix, votre objectif est d’augmenter l’évolutivité au coût le plus bas.

Montée en charge

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. Cela garantit un débit élevé de données enregistrées du réseau vers le disque. Il est donc important d’investir dans du matériel réseau et de 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.

Extension 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 faire face à 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, dirigez les agents d’enregistrement de session vers l’équilibreur de charge responsable de la distribution de la charge de travail.

Capacité réseau

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

Assurez-vous que les commutateurs réseau utilisés par l’enregistrement de session ne sont pas partagés avec des applications tierces qui pourraient 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 ensemble de disques locaux contrôlés soit en RAID par un contrôleur de disque local, soit en tant que 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 termes de performances et de sécurité. Utilisez la dernière version du protocole en place pour éviter les implications de sécurité et effectuez des tests de mise à l’échelle 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 pendant l’écriture différée, ce qui 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. La mise en cache soulève cependant 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 avec cache, ce qui garantit qu’en cas de perte de courant, le cache est maintenu et les données sont écrites sur le disque lorsque l’alimentation est finalement rétablie.

Envisagez d’utiliser une solution de stockage RAID appropriée. Il existe de nombreux niveaux RAID disponibles en fonction des exigences de performances et de redondance. Le tableau suivant spécifie chacun des niveaux RAID et leur applicabilité à 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 standards populaires mais ne sont pas recommandés pour l’enregistrement de session. Le RAID 10 offre certains avantages en termes de performances mais 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’utilisation dans 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 l’équivalent de 10 jours d’enregistrements (soit 50 000 fichiers de sessions enregistrées), 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 par l’utilitaire ICLDB et ont 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, la baie de disques apparaît comme un lecteur local. Les SAN sont plus coûteux à configurer, mais comme la baie de disques est partagée, 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

La base de données d’enregistrement de session nécessite Microsoft SQL Server 2019, Microsoft SQL Server 2017, Microsoft SQL Server 2016, Microsoft SQL Server 2014, Microsoft SQL Server 2012 ou Microsoft SQL Server 2008 R2. Le volume de données envoyé à la base de données 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 sont eux-mêmes é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, sauf si l’API d’événements d’enregistrement de session est 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 aucune restriction 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 enregistrée 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 serveur SQL 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.