Considérations sur l’évolutivité

Session Recording 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 Session Recording nécessitent peu de ressources supplémentaires au-delà de ce qui est nécessaire pour exécuter XenApp et XenDesktop. Cependant, si vous prévoyez d’utiliser Session Recording pour enregistrer un grand nombre de sessions ou si les sessions que vous prévoyez d’enregistrer peuvent générer des fichiers de session volumineux (par exemple, des applications à forte intensité graphique), prenez en compte les performances de votre système lors de la planification de votre déploiement Session Recording.

Cet article explique comment Session Recording 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 Session Recording est si évolutif

Il y a deux raisons principales pour lesquelles Session Recording est très évolutif par rapport aux produits concurrents :

• Taille de fichier réduite

  Un fichier de session enregistré avec Session Recording est très compact. Il est 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 Session Recording 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 entièrement sans perte et ne présentent aucune pixellisation, ce qui est courant dans la plupart des formats vidéo compacts. Le texte dans les enregistrements est facile à lire pendant la lecture, comme dans les sessions originales. Pour maintenir des tailles de fichier réduites, Session Recording n’enregistre pas les images clés dans les fichiers.

• 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. Cela signifie que 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 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 Session Recording 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 Session Recording activé envoie les données de session enregistrées au serveur Session Recording. Session Recording 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.

Déterminez la quantité de données que vous enverrez à chaque serveur Session Recording et 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 Session Recording typique connecté à un réseau local (LAN) de 100 Mbps avec un espace disque suffisant pour stocker les données enregistrées est capable de traiter des données à environ 5,0 Mbps, en fonction des limites physiques imposées par les IOPS disque et réseau. C’est le débit de traitement. Dans cet exemple, le débit de traitement (5,0 Mbps) est supérieur au débit d’entrée (3,5 Mbps), l’enregistrement des 5 000 sessions Outlook est donc réalisable.

Notez que 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 CAO peut générer un taux d’entrée extrêmement élevé et nécessiter l’utilisation de davantage de serveurs d’enregistrement de session.

Pics d’activité et pannes

L’exemple précédent suppose un débit de données uniforme très 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 », ou lorsqu’ils reçoivent le même e-mail dans leur boîte de réception Outlook en même temps. Le taux de traitement de 5,0 Mbps du serveur d’enregistrement de session est très insuffisant pour faire face à cette demande soudaine.

L’agent d’enregistrement de session exécuté sur chaque VDA utilise Microsoft Message Queuing (MSMQ) pour envoyer les données enregistrées au gestionnaire de stockage exécuté sur le serveur d’enregistrement de session central. Les données sont envoyées selon un mécanisme de stockage et de retransmission, similaire à la façon dont un e-mail est livré entre l’expéditeur, le serveur de messagerie et le destinataire. Si le serveur d’enregistrement de session ou le réseau ne peut pas gérer le débit élevé de données lors d’un pic d’activité, les données de session enregistrées sont temporairement stockées jusqu’à ce que l’arriéré de messages de données soit traité. Le message de données peut être temporairement stocké dans la file d’attente sortante sur le VDA si le réseau est encombré, ou stocké dans la file d’attente de réception du serveur d’enregistrement de session si les données ont traversé le réseau mais que le gestionnaire de stockage est toujours occupé à traiter d’autres messages.

MSMQ sert également de mécanisme de tolérance aux pannes. Si le serveur d’enregistrement de session tombe en panne ou si la liaison est interrompue, les données enregistrées sont conservées 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. L’utilisation de MSMQ vous permet également de mettre un serveur d’enregistrement de session hors ligne pour une mise à niveau ou une maintenance sans interrompre l’enregistrement des sessions existantes 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. Cela limite la durée 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 fragments 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 d’enregistrement de session, 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 pour chaque agent d’enregistrement de session à un niveau approprié (sous l’onglet Connexions dans les propriétés de l’agent d’enregistrement de session). La valeur par défaut de 7 200 secondes (deux heures) signifie que chaque message de données enregistré dispose de deux heures pour atteindre le gestionnaire de stockage avant d’être supprimé et que les fichiers d’enregistrement ne soient endommagés. 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. Dans des conditions normales, le gestionnaire de stockage reçoit et traite les données directement du réseau sans que le message de données ne soit jamais écrit 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 attente, les IOPS disque sont triplées : chaque message doit être écrit sur le disque, lu à partir du disque et écrit dans le fichier. Comme le gestionnaire de stockage est fortement lié aux IOPS, le taux de traitement du serveur d’enregistrement de session diminue jusqu’à ce que l’arriéré de messages soit traité. 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 taux 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 création de serveurs à haute disponibilité. Ces approches incluent l’utilisation d’onduleurs, de cartes réseau doubles, de commutateurs redondants, ainsi que de mémoire et de 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 le traitement des arriérés de messages est coûteux en IOPS. Pour cette raison, concevez chaque serveur d’enregistrement de session avec une capacité de réserve suffisante. 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 est capable de 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 ce nombre à 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 pendant 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 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 arriéré, 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é d’arriéré en intégrant une capacité de réserve et une tolérance aux pannes dans votre déploiement.

Évolutivité de XenApp® et XenDesktop

L’enregistrement de session ne réduit jamais les performances de 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 ignoré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 XenApp et XenDesktop 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 telles que configurées par les stratégies d’enregistrement de session

Si moins de sessions sont enregistrées ou si l’activité de 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 simplement 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 ne sera jamais 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 façon de procéder. Une approche moins invasive consiste à décocher la case 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.

Mise à l’échelle

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 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 une spécification supérieure. 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, il y a peu d’avantages à en ajouter davantage.

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 d’un grand nombre de sessions. Il peut être nécessaire d’ajouter des serveurs supplémentaires pour faire face à la charge. Vous pouvez installer davantage de 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

Une liaison réseau de 100 Mbps est adaptée pour connecter un serveur d’enregistrement de session. Une connexion Ethernet Gigabit peut améliorer les performances, mais n’entraîne pas une performance 10 fois supérieure à celle d’une liaison de 100 Mbps. En pratique, le gain de débit est nettement inférieur.

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, CIFS ou NFS a de sérieuses implications en termes de performances et de sécurité. N’utilisez jamais cette configuration dans un déploiement de production de l’enregistrement de session.

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 (elevator sorting) pendant l’écriture différée (write-back), 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 une alimentation de secours par batterie pour le contrôleur de disque avec cache, ce qui garantit que, 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 performance et de redondance. Le tableau suivant spécifie chacun des niveaux RAID et la pertinence de chaque norme pour l’enregistrement de session.

Le RAID 0 et le RAID 3 sont les niveaux RAID les plus recommandés. Le RAID 1 et le 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 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 sont pas adaptés à l’utilisation avec 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 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 é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 2016, Microsoft SQL Server 2014, Microsoft SQL Server 2012 et Microsoft SQL Server 2008 R2 imposent une limitation de taille de base de données de 10 Go. À 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 sollicitée. 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 XenApp ou XenDesktop.

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.