Considérations sur la capacité à monter en charge

L’enregistrement de session est un système hautement évolutif qui gère des milliers, voire des dizaines de milliers de sessions. L’installation et l’exécution de l’enregistrement de session nécessitent quelques ressources supplémentaires au-delà des éléments de base nécessaires à l’exécution de Citrix Virtual Apps and Desktops ou Citrix DaaS (anciennement Citrix Virtual Apps and Desktops Service). Cependant, nous vous recommandons toujours de prendre en compte les performances de votre système si vous prévoyez d’enregistrer un grand nombre de sessions. Les sessions que vous prévoyez d’enregistrer peuvent également produire des fichiers de session volumineux (par exemple, des applications exigeant d’importantes ressources graphiques).

Cet article explique comment vous pouvez optimiser la capacité à monter en charge de l’enregistrement de session et comment vous pouvez tirer le meilleur parti de votre système d’enregistrement à moindre coût.

Capacité à monter en charge de l’enregistrement de session

Il y a deux raisons principales pour lesquelles l’enregistrement de session est plus performant que les produits concurrents :

• Taille des fichiers

  Un fichier de session enregistrée créé avec l’enregistrement de session est très compact. Il est beaucoup plus petit qu’un enregistrement vidéo équivalent effectué avec des solutions de capture de données d’écran. La bande passante réseau, l’espace disque et le nombre d’E/S par seconde de disque nécessaires au transport et au stockage de chaque fichier de session enregistrée sont généralement au moins 10 fois inférieur qu’avec un fichier vidéo équivalent.

  La petite taille des fichiers de sessions enregistrées permet un rendu plus rapide et plus fluide des images vidéo. Les enregistrements sont également sans aucune perte et ne présentent pas la pixelisation souvent observée dans la plupart des formats vidéo compacts. Le texte des enregistrements est aussi facile à lire que pendant les sessions d’origine. Pour obtenir des fichiers de petite taille, l’enregistrement de session n’enregistre pas les trames clés à l’intérieur des fichiers. L’enregistrement de session peut ignorer les paquets H.264 lors de l’enregistrement de sessions qui ont des vidéos en cours d’exécution et ainsi réduire 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 Utiliser codec vidéo pour la compression sur Pour les zones changeant constamment.

  

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

  Un fichier de session enregistrée contient les données du protocole ICA d’une session, extraites virtuellement dans leur 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 coûteux de transcodage ou d’encodage pour modifier le format des données en temps réel. La faible quantité de traitement est également importante pour la capacité à monter en charge du VDA et garantit que l’expérience de l’utilisateur final reste satisfaisante 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 est un facteur d’optimisation supplémentaire. Par exemple, les canaux de mappage des imprimantes et des lecteurs clients ne sont pas enregistrés car ils peuvent générer des volumes élevés de données sans bénéfice 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 central de collecte des fichiers de sessions enregistrées. Chaque ordinateur qui exécute un VDA avec OS multi-session alors que l’enregistrement de session est activé envoie des données de sessions enregistrées au serveur d’enregistrement de session. L’enregistrement de session peut gérer des volumes élevés de données et tolérer les rafales et les défaillances, mais il existe des limites physiques quant à la quantité de données qu’un serveur peut gérer.

Considérez le volume de données que vous envoyez à chaque serveur d’enregistrement de session et la rapidité des délais de traitement et de stockage de ces données par les serveurs. Le taux auquel votre système peut stocker les données entrantes doit être supérieur au taux d’entrée des données.

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

1. Multipliez le nombre de sessions enregistrées par la taille moyenne des sessions.
2. Divisez le produit par la durée d’enregistrement des sessions.

Par exemple, vous pouvez enregistrer 5 000 sessions Microsoft Outlook de 20 Mo chacune sur une durée de 8 heures par jour ouvrable. Dans ce cas, le taux d’entrée des données est d’environ 3,5 Mbit/s (5 000 sessions x 20 Mo, divisé par 8 heures, divisé par 3 600 secondes par heure). Un serveur d’enregistrement de session standard connecté à un réseau local de 100 Mbit/s avec suffisamment d’espace disque pour stocker les données enregistrées peut traiter les données à une vitesse d’environ 5,0 Mbit/s. Ce taux correspond au taux de traitement en fonction des limites physiques imposées par le nombre d’E/S par seconde sur le disque et le réseau. Dans l’exemple, le taux de traitement (5,0 Mbit/s) est supérieur au taux d’entrée (3,5 Mbit/s), ce qui rend possible l’enregistrement des 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 des couleurs et le mode graphique ont également un impact. Une session dans laquelle une application CAO est en cours d’exécution génère probablement un enregistrement beaucoup plus important qu’une session au cours de laquelle l’utilisateur envoie et reçoit des e-mails dans Outlook. Par conséquent, l’enregistrement du même nombre de sessions CAO peut générer un taux d’entrée élevé et nécessiter l’utilisation d’un plus grand nombre de serveurs d’enregistrement de session.

Rafales et défaillances

L’exemple précédent suppose un débit uniforme simple de données, mais n’explique pas comment le système traite de courtes périodes d’activité plus élevée, appelées rafales. Une rafale peut se produire lorsque tous les utilisateurs se connectent à la même heure le matin, appelée la pointe de 9 heures, ou lorsqu’ils reçoivent le même courrier électronique simultanément dans leur boîte de réception Outlook. Le taux de traitement de 5,0 Mbit/s du serveur d’enregistrement de session est très insuffisant pour faire face à cette demande soudaine.

L’agent d’enregistrement de session s’exécutant sur chaque VDA utilise Microsoft Message Queuing (MSMQ) pour envoyer des données enregistrées au Gestionnaire de stockage s’exécutant sur le serveur central d’enregistrement de session. Les données sont envoyées selon une méthode de stockage et de transfert similaire à la manière dont un e-mail est transmis 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 taux élevé de données dans une rafale, les données enregistrées sont temporairement stockées. Le message de données peut être stocké temporairement dans la file d’attente sortante sur le VDA si le réseau est encombré. Il se peut également que les données aient traversé le réseau mais que le Gestionnaire de stockage soit toujours 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 d’enregistrement de session.

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 défaillance est résolue, toutes les données mises en file d’attente sont envoyées ensemble. L’utilisation de MSMQ vous permet également de mettre un serveur hors connexion pour la mise à niveau ou la maintenance sans interrompre l’enregistrement de session ni perdre de données.

La principale limitation de MSMQ est que l’espace disque pour le stockage temporaire des messages de données n’est pas infini. Cette limitation limite le temps que peut durer une rafale, une défaillance ou un événement de maintenance avant que les données ne soient perdues. Le système global peut continuer après la perte de données, mais dans ce cas, des morceaux de données manquent dans les enregistrements individuels. Un fichier avec des données manquantes est toujours lisible, mais seulement jusqu’au point où les données ont été perdues. Tenez compte de ce qui suit :

• L’ajout d’espace disque à chaque serveur, en particulier au serveur d’enregistrement de session, et sa mise à disposition pour MSMQ peuvent augmenter la tolérance aux rafales et aux défaillances.

• Il est important de configurer le paramètre Durée de validité des messages pour chaque agent d’enregistrement de session sur un niveau approprié (sous l’onglet Connexions dans Propriétés de l’Agent d’enregistrement de session). La valeur par défaut est 7 200 secondes (deux heures). Cela signifie que chaque message de données enregistré dispose de deux heures pour atteindre le Gestionnaire de stockage avant qu’il ne soit ignoré et que les fichiers d’enregistrement 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 365 jours.

Autre limitation de MSMQ : lorsque les données en attente s’accumulent, un nombre d’E/S par seconde supplémentaire est nécessaire 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 du réseau directement sans que le message de données soit é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ée. Lorsque les données s’accumulent, le nombre d’E/S par seconde du disque triple : chaque message doit être écrit sur le disque, lu sur le disque et écrit dans un fichier. Le Gestionnaire de stockage étant fortement lié aux E/S par seconde, le taux de traitement du serveur d’enregistrement de session diminue jusqu’à ce que la file d’attente des messages soit vide. Pour atténuer les effets de ces E/S par seconde supplémentaires, adoptez les recommandations suivantes :

• Assurez-vous que le disque sur lequel MSMQ stocke les messages est différent des dossiers de stockage de fichiers d’enregistrement. Même si le trafic des bus E/S par seconde triple, la baisse du taux de traitement réel n’est jamais aussi forte.

• Planifiez les arrêts aux heures creuses seulement. Si votre budget vous le permet, suivez des approches courantes pour créer des serveurs à haute disponibilité. Ces approches incluent l’utilisation d’UPS (Uninterruptible Power Supply), de cartes réseau doubles, de commutateurs redondants, de mémoire et de disques remplaçables à chaud.

Prévoir la capacité de réserve

Il est peu probable que le taux de données des sessions enregistrées soit uniforme, des rafales et des défaillances peuvent se produire, et le traitement des messages en attente consomme beaucoup d’E/S par seconde. Pour cette raison, concevez chaque serveur d’enregistrement de session avec beaucoup de capacité de réserve. Ajoutez d’autres serveurs ou améliorez la spécification des serveurs existants, comme décrit dans les sections suivantes, pour une capacité supplémentaire. La règle générale consiste à exécuter 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 Mbit/s, configurez le système pour qu’il s’exécute uniquement à 2,5 Mbit/s. Au lieu d’enregistrer 5 000 sessions Outlook qui génèrent 3,5 Mbit/s sur un serveur d’enregistrement de session, réduisez ce nombre à 3 500 sessions qui génèrent seulement 2,5 Mbit/s.

Files d’attente et lecture active

Un réviseur peut ouvrir un enregistrement de session pour le lire alors que la session est toujours active, cela s’appelle la lecture active. Pendant la lecture active, l’agent d’enregistrement de session responsable de la session passe en mode streaming pour cette session. Les données d’enregistrement sont immédiatement envoyées 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 active. Toutefois, les données envoyées par l’agent au Gestionnaire de stockage le sont via MSMQ, donc les règles de mise en file d’attente décrites précédemment s’appliquent. Un problème peut se produire dans ce scénario. Lorsque MSMQ accumule un retard, les nouvelles données enregistrées disponibles pour la lecture active 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 active est une fonctionnalité importante pour les réviseurs, minimisez la probabilité de retard. Vous pouvez concevoir une capacité de réserve et une tolérance aux pannes dans votre déploiement.

Scalabilité du système

L’enregistrement de session ne réduit jamais les performances de session et n’arrête jamais les sessions en réponse à des retards de données enregistrées. Il est primordial de préserver l’expérience utilisateur final et la capacité à monter en charge d’un seul serveur lors de la conception du système d’enregistrement de session. Si le système d’enregistrement devient surchargé de façon irréversible, les données de session enregistrées sont supprimées. L’impact de l’enregistrement des sessions ICA sur les performances et la capacité à monter en charge des VDA est faible. L’importance 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 de 1 % à 5 % sur la capacité à monter en charge d’un serveur unique. En d’autres termes, si un serveur peut héberger 100 utilisateurs sans que l’enregistrement de session soit installé, il peut héberger 95 à 99 utilisateurs après l’installation :

• Serveur 64 bits avec 8 Go de RAM exécutant un VDA avec OS multi-session
• Toutes les sessions exécutant des applications de productivité Office, telles que Outlook et Excel
• L’utilisation des applications est active et soutenue
• Toutes les sessions sont enregistrées selon la configuration des stratégies d’enregistrement de session

Si moins de sessions sont enregistrées ou si l’activité est moins soutenue et plus sporadique, l’impact est moindre. Dans de nombreux cas, l’impact sur la capacité à monter en charge est négligeable et la densité utilisateur 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 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 de codage coûteux des données.

Il y a une surcharge mineure de l’utilisation de l’enregistrement de session même lorsqu’aucune session n’est enregistrée. Si vous n’allez pas enregistrer de session à 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ésactiver la case à cocher Activer l’enregistrement de session pour cette machine VDA sous l’onglet Enregistrement de session dans Propriétés de l’Agent d’enregistrement de session. Si l’enregistrement de session est nécessaire à l’avenir, réactivez cette case à cocher.

Mesure du débit

Vous pouvez mesurer le débit des données de session enregistrées depuis le VDA d’envoi vers le serveur d’enregistrement de session de réception. Une approche simple et efficace consiste à observer la taille des fichiers d’enregistrement et la fréquence à laquelle l’espace disque sur le serveur d’enregistrement de session est consommé. Le volume de données écrites sur le disque reflète étroitement le volume de trafic réseau généré. L’Analyseur de performances Windows (perfmon.exe) propose des 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 de 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 : mettre à niveau (en augmentant la capacité de chaque serveur) ou monter en charge (en ajoutant plus de serveurs). En faisant l’un ou l’autre des choix, votre objectif est d’augmenter la capacité à monter en charge au moindre coût.

Augmentation de la capacité

Si vous envisagez un serveur d’enregistrement de session unique, tenez compte des meilleures pratiques suivantes pour garantir des performances optimales selon le budget disponible. Le système dépend des opérations d’E/S par seconde qui peuvent garantir un débit élevé de données enregistrées depuis le réseau sur le disque. Il est donc important d’investir dans le matériel de réseau et de disque approprié. Pour un serveur d’enregistrement de session hautes performances, un processeur double ou double cœur est recommandé, mais une spécification plus élevée n’a pas beaucoup d’intérêt. L’architecture de processeur 64 bits est recommandée, mais un type de processeur x86 convient également. 4 Go de RAM est recommandé mais encore une fois, il y a peu d’avantages à en ajouter plus.

Montée en charge

Même avec les meilleures pratiques de montée en charge, il existe des limites de performances et de capacité 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 des serveurs d’enregistrement de session supplémentaires sur des ordinateurs différents de manière à ce que les serveurs d’enregistrement de session fonctionnent en tant que 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 répartir la charge, dirigez les agents d’enregistrement de session vers l’équilibreur de charge responsable de la répartition de la charge de travail.

Capacité du réseau

Une liaison réseau de 100 Mbps convient aux connexions à un serveur d’enregistrement de session. Une connexion Ethernet en Go peut améliorer les performances, mais ne se traduira pas par des performances de dix fois supérieures à une liaison 100 Mbit/s. En pratique, le gain de débit est moindre.

Veillez à ce que les commutateurs réseau utilisés par l’enregistrement de session ne soient pas partagés avec des applications tierces qui pourraient lui disputer la bande passante réseau disponible. Dans le meilleur des cas, les commutateurs réseau sont dédiés au 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 la capacité à monter en charge du système.

Stockage

Investir dans du matériel de disque et de stockage est le facteur le plus important de la capacité à monter en charge des serveurs. Plus vite les données peuvent être écrites sur disques, plus élevées sont les performances du système dans son ensemble. Lorsque vous sélectionnez une solution de stockage, donnez priorité aux performances d’écriture plutôt qu’aux performances de lecture.

Stockez les données sur un contrôleur RAID ou un réseau SAN.

Remarque :

Le stockage des données sur un serveur NAS basé sur des protocoles basés sur des fichiers tels que SMB et NFS, peut avoir d’importantes répercussions sur les performances et la sécurité. Utilisez la dernière version du protocole pour éviter toute incidence sur la sécurité et effectuez des tests de scalabilité pour garantir des performances adéquates.

Pour une configuration de lecteur local, recherchez un contrôleur de disque avec mémoire cache intégré. La mise en cache permet au contrôleur d’utiliser le tri en ascenseur pendant la réécriture. Cela permet de minimiser le mouvement de la tête de disque et garantit que les opérations d’écriture sont terminées sans attendre la fin de l’opération du disque physique. Cela peut améliorer considérablement les performances d’écriture à un coût supplémentaire minime. 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 d’utiliser une fonction de sauvegarde sur batterie pour le contrôleur de disque de mise en cache.

Envisagez d’utiliser une solution de stockage RAID appropriée. De nombreux niveaux de RAID sont disponibles en fonction de vos exigences en matière de performances et de redondance. Le tableau suivant spécifie chacun des niveaux de RAID et la manière dont chaque norme est applicable à l’enregistrement de session.

RAID 0 et RAID 3 sont les niveaux de RAID les plus recommandés. RAID 1 et RAID 5 sont des normes populaires, mais ne sont pas recommandés pour l’enregistrement de session. 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 de la spécification des unités de disque. Les lecteurs IDE/ATA et les lecteurs USB ou Firewire externes ne conviennent pas à l’enregistrement de session. Vous avez principalement le choix entre SATA et SCSI. Les disques SATA offrent des débits de transfert raisonnablement élevés à un coût par Mo réduit par rapport aux disques SCSI. Toutefois, 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 maintenant disponibles. Lors de l’évaluation des spécifications des produits d’unités de disque, tenez compte de la vitesse de rotation du disque et d’autres caractéristiques de performance.

Étant donné que l’enregistrement de milliers de sessions par jour peut consommer beaucoup d’espace disque, vous devez choisir entre la capacité globale et les performances. Dans 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 (c’est-à-dire 50 000 fichiers de sessions enregistrées), vous avez besoin de 1 000 Go (1 To). Vous pouvez atténuer cette pression sur l’espace disque en raccourcissant la période de rétention avant l’archivage ou la suppression d’anciens enregistrements. Si 1 To d’espace disque est disponible, une période de rétention de sept jours est raisonnable, cela garantit que l’utilisation de l’espace disque reste autour de 700 Go, avec 300 Go restant en mémoire tampon pour les jours plus intenses. Dans l’enregistrement de session, l’archivage et la suppression des fichiers sont pris en charge avec l’utilitaire ICLDB. Ces fonctions ont une période de conservation minimale de deux jours. Vous pouvez planifier une tâche en arrière-plan pour qu’elle s’exécute une fois par jour à une heure creuse. Pour plus d’informations sur les commandes ICLDB et l’archivage, reportez-vous à la section Gérer vos enregistrements de base de données.

L’alternative à l’utilisation d’un lecteur local et de contrôleurs consiste à utiliser une solution de stockage SAN basée sur l’accès au disque au niveau du bloc. Sur le serveur d’enregistrement de session, la grappe de disques apparaît en tant que lecteur local. La configuration des SAN est plus coûteuse, mais à mesure que la grappe de disques est partagée, les SAN présentent 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 Gb Ethernet.

Capacité à monter en charge de la base de données

Le volume de données envoyées à la base de données d’enregistrement de session est minime car celle-ci ne stocke que les métadonnées sur les sessions enregistrées. Pour leur part, les fichiers des sessions enregistrées sont inscrits sur un autre disque. 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 de l’enregistrement de session soit utilisé pour insérer des événements avec possibilité de recherche dans la session.

Les éditions Express de Microsoft SQL Server 2019, Microsoft SQL Server 2017, Microsoft SQL Server 2016, Microsoft SQL Server 2014, Microsoft SQL Server 2012 et Microsoft SQL Server 2008 R2 imposent une limite 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 sessions. D’autres éditions de Microsoft SQL Server n’ont pas de restrictions de taille de base de données et ne sont limitées que par la quantité d’espace disque disponible. À mesure que le nombre de sessions augmente dans la base de données, les performances de la base de données et la vitesse des recherches ne diminuent que faiblement.

Si vous ne faites pas de personnalisations par le biais de l’API d’événements de l’enregistrement de session, chaque session enregistrée génère quatre transactions sur la base de données : deux au démarrage de l’enregistrement, une lorsque l’utilisateur se connecte aux sessions actuellement enregistrées et une à l’arrêt de l’enregistrement. Si vous utilisez l’API d’événements de l’enregistrement de session pour personnaliser des sessions, chaque événement avec possibilité de recherche enregistré génère une transaction. Puisque même le déploiement de base de données le plus élémentaire est en mesure de traiter des centaines de transactions par seconde, la charge de traitement sur la base de données n’est pas considérée comme étant excessivement sollicitée. L’impact est assez minime 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, notamment la base de données du magasin central de Citrix Virtual Apps and Desktops.

Si votre déploiement d’enregistrement de session nécessite de cataloguer plusieurs millions de sessions enregistrées dans la base de données, suivez les consignes de Microsoft pour la montée en charge de SQL Server.