ASP.NET est connu pour développer des applications Web à fort trafic. Bon nombre de ces applications sont déployées dans plusieurs emplacements géographiques. Ce déploiement multisite est effectué soit à des fins de reprise après sinistre, soit pour gérer le trafic régional en rapprochant l'application ASP.NET de l'utilisateur final.
Dans le cas d'une reprise après sinistre, il existe généralement un site actif et un site passif. Le site passif devient actif dès que le site actif tombe en panne pour une raison quelconque. Dans d'autres cas, deux sites ou plus peuvent tous être actifs mais gérer le trafic plus près de leur région (par exemple, New York, Londres et Tokyo).
NCache Détails NCache Docs Fournisseur d'état de session ASP.NET
ASP.NET conserve les informations spécifiques à l'utilisateur dans son objet d'état de session sur le serveur Web. Lorsque l'utilisateur accède à l'application ASP.NET pour la première fois, son état de session est créé et y reste tant que l'utilisateur utilise activement l'application. Par défaut, après 20 minutes d'inactivité de l'utilisateur, ASP.NET fait expirer cette session.
L'objet d'état de session ASP.NET est stocké en mémoire sur le serveur Web (InProc), sur n'importe quel serveur (StateServer), dans une base de données SQL Server ou dans un magasin tiers à l'aide de l'architecture SSP.
L'option tierce est généralement un cache distribué en mémoire comme NCache, est un endroit idéal pour stocker l'état de la session. Les raisons sont des performances plus rapides, une plus grande évolutivité et une meilleure fiabilité de l'état de session ASP.NET grâce à la réplication de session. Vous trouverez ci-dessous un exemple de la façon dont vous pouvez spécifier une option de stockage de session personnalisée dans le fichier web.config, ce qui entraîne NCache en tant que stockage d'état de session ASP.NET :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
<sessionState cookieless ="false" regenerateExpiredSessionId="true" mode="Custom" customProvider="NCacheSessionProvider" timeout="60" sessionIDManagerType="Alachisoft.NCache.Web.SessionStateManagement.CustomSessionIdManager, Alachisoft.NCache.SessionStateManagement"> <providers> <add name ="NCacheSessionProvider" type="Alachisoft.NCache.Web.SessionState.NSessionStoreProvider" sessionAppId="demoApp" cacheName="demoClusteredCache" writeExceptionsToEventLog="false" asyncSession="false" enableLogs="false"/> </providers> </sessionState> |
Déploiement multi-sites actif-passif
Mais, si votre application s'exécute dans un déploiement multisite, la question que vous devez vous poser est de savoir quoi faire à propos de Session ASP.NET Stockage d'état. Si vous avez déployé votre application ASP.NET dans une configuration multisite active-passive, tous vos états de session ASP.NET sont créés et stockés dans le site actif. Le site passif n'a pas de données de session. Ainsi, si le site actif tombe en panne et que tout le trafic est redirigé vers le site passif, tous les utilisateurs perdront soudainement leurs sessions et devront recommencer. Vous pouvez éviter cela en utilisant le NCache Topologie de pont.
Une fois que vous créez un Pont entre les sites actif et passif, le site actif commence à soumettre tous les ajouts, mises à jour et suppressions d'objets d'état de session ASP.NET au pont. Le pont les réplique de manière asynchrone sur le WAN vers le site passif. L'architecture Bridge ne bloque pas les opérations actives du site, vous ne constatez donc aucune dégradation des performances. Le seul problème que vous devez garder à l'esprit est que, puisque le pont se réplique de manière asynchrone, il peut y avoir des sessions dans la "file d'attente de réplication" qui n'atteindront pas le site passif si le site actif s'arrête brusquement. Mais c'est généralement un nombre insignifiant. En savoir plus sur NCache Topologie de pont et toutes les situations où cela vous est bénéfique.
NCache Détails NCache Docs Propriétés du fournisseur d'état de session ASP.NET
Déploiement multi-sites actif-actif
Si votre application ASP.NET est déployée simultanément sur deux sites actifs ou plus, vous devez éviter de répliquer État de session ASP.NET à tous les sites pour économiser sur le coût de la bande passante. Cependant, vous souhaitez probablement pouvoir acheminer une partie du trafic vers d'autres sites pour gérer les situations de débordement.
Alternativement, vous devrez peut-être arrêter l'un des sites pour maintenance sans aucune interruption pour les utilisateurs. Dans ce cas, vous pouvez utiliser la fonctionnalité de stockage d'état de session ASP.NET multisite dans NCache. La fonctionnalité vous permet de gérer ces cas et de spécifier dans le web.config pour générer des identifiants de session avec un préfixe d'emplacement pour le site "principal" de cette session. Ensuite, même si cette demande de session est acheminée vers un autre site, ce site sait où trouver cette session.
Les sessions ne se déplacent pas de leur emplacement principal même si l'utilisateur demande un itinéraire vers l'autre site. Mais l'autre site peut accéder à cette session depuis son site « principal ». Chaque site spécifie ses sites "primaires" et tous les autres comme sites "secondaires". Voici les étapes à suivre pour atteindre cet objectif :
- Ajoutez une entrée dans web.config. Il est nécessaire de générer l'ID de session ASP.NET de la même manière sur tous les serveurs et sites. Vous pouvez utiliser l'utilitaire genmackeys disponible avec NCache installation pour générer les clés.
1<machineKey validationKey ="A01D6E0D1A5D2A22E0854CA612FE5C5EC4AECF24"decryptionKey ="ACD8EBF87C4C8937" validation ="SHA1"/> - Pour activer l'affinité d'emplacement d'un identifiant de session, ajoutez la configuration mentionnée ci-dessous :
123456<configSections><section name="ncache" type="Alachisoft.NCache.Web.SessionStateManagement.NCacheSection,Alachisoft.NCache.SessionStateManagement, Version=x.x.x.x, Culture=neutral, PublicKeyToken=CFF5926ED6A53769"/></configSections><ncache><sessionLocation><primaryCache id="London_Cache" sid-prefix="LDNC"/><secondaryCache id="NewYork_Cache" sid-prefix="NYKC"/><secondaryCache id="Tokyo_Cache" sid-prefix="TKYC"/></sessionLocation></ncache> - Spécifiez le gestionnaire d'ID de session personnalisé à l'aide de l'attribut sessionIDManagerType de l'élément sessionState dans web.config.
12345678910111213141516171819202122232425262728293031<<sessionStatecookieless ="false"regenerateExpiredSessionId="true"mode="Custom"customProvider="NCacheSessionProvider"timeout="60" sessionIDManagerType="Alachisoft.NCache.Web.SessionStateManagement.CustomSessionIdManager, Alachisoft.NCache.SessionStateManagement"><providers><add name ="NCacheSessionProvider"type="Alachisoft.NCache.Web.SessionState.NSessionStoreProvider"sessionAppId="demoApp"cacheName="demoClusteredCache"writeExceptionsToEventLog="false"asyncSession="false"enableLogs="false"/></providers></sessionState>
Veuillez noter que dans l'exemple ci-dessus, la section de chaque site sera différente, ce qui signifie que chaque site aura son propre "principal" et considérera tous les autres sites comme "secondaires".
NCache Détails NCache Docs ASP.NET Core Sessions
ASP.NET génère sid (id de session) dans un format spécifique afin que le préfixe sid puisse faire partie de session-id. Cet ID de session aide ASP.NET à connaître l'origine de l'état de session ASP.NET afin d'accéder au cache de ce site. Avec cette configuration, si vous acheminez des demandes d'un site à un autre pour débordement, l'autre site récupère l'état de session ASP.NET à partir de son site « principal » d'origine, car il fait partie de l'ID de session en tant que préfixe d'emplacement. Il minimise votre consommation de bande passante WAN et vous ne payez que pour le trafic de débordement.
L'autre situation est lorsque vous voulez faire tomber un site. Vous pouvez rediriger tout le trafic du site vers d'autres sites sans fermer les serveurs de cache de ce site ; vous pouvez arrêter les serveurs Web. Attendez ensuite que tous les objets d'état de session ASP.NET existants expirent une fois que leurs utilisateurs ont cessé d'utiliser l'application. Une fois le trafic redirigé, fermez simplement les serveurs de cache. Avec cela, vos utilisateurs ne ressentiront aucun temps d'arrêt. Regardez comment NCache vous aide à atteindre cet objectif. Téléchargez une version d'essai complète de 60 jours de NCache.