HA und automatische Skalierung für ASP.NET Web Forms-Anwendungen auf AWS

Wenn Sie Ihre älteren ASP.NET Web Forms-Anwendungen zu migrieren AWS, ist das Erreichen einer hohen Verfügbarkeit von entscheidender Bedeutung. Sie können Amazon EC2 Auto Scaling Scaling-Gruppen und Load Balancer verwenden, um den Datenverkehr auf mehrere EC2 Instances zu verteilen. Viele ASP.NET Web Forms-Anwendungen sind jedoch stark vom Sitzungsstatus abhängig, wodurch sie von Natur aus statusbehaftet sind. Standardmäßig speichert der Server die generierte Sitzung IDs im Speicher und sendet die ID über ein Cookie zurück an den Client. Dieser Ansatz wird problematisch, wenn Sie versuchen, dieselbe Anwendung auf mehreren EC2 Instanzen auszuführen, da jede Instanz ihren eigenen Sitzungsstatus beibehält, was zu inkonsistenten Benutzererfahrungen und potenziellem Datenverlust führt.

Um dieser Herausforderung zu begegnen und sicherzustellen, dass Ihre migrierte ASP.NET Web Forms-Anwendung unter Beibehaltung des Sitzungsstatus nahtlos über mehrere Instanzen hinweg skaliert werden kann, haben Sie zwei Hauptoptionen: die Aktivierung von Sticky-Sitzungen oder die Verwendung von gemeinsam genutztem Backing-Speicher.

Aktivieren Sie Sticky Sessions für den &ALB

Bei Aktivierung können Sie Application Load Balancers so konfigurieren AWS, dass sie Sticky-Sitzungen, auch Sitzungsaffinität genannt, verwenden. Wenn Sie Sticky Sessions aktivieren, leitet der Application Load Balancer nachfolgende Anfragen von demselben Client an dieselbe EC2 Instance weiter. Dadurch wird sichergestellt, dass der Sitzungsstatus des Benutzers während seiner gesamten Interaktionen mit der Anwendung erhalten bleibt.

Dieser Ansatz bietet eine einfache Lösung, weist jedoch Einschränkungen in Bezug auf Skalierbarkeit und Fehlertoleranz auf. Wenn eine EC2 Instanz ausfällt oder nicht mehr verfügbar ist, ist die Sticky-Sitzung unterbrochen und der Sitzungsstatus des Benutzers geht verloren. Darüber hinaus können Sticky Sessions zu einer ungleichmäßigen Lastverteilung zwischen den Instanzen führen und möglicherweise zu Ressourcenkonflikten oder zu einer Unterauslastung führen, was die Fähigkeit der Anwendung zur effektiven Skalierung einschränkt. Aus diesen Gründen empfehlen wir, stattdessen einen gemeinsamen Backing-Store als Sitzungsspeicher zu verwenden.

Verwenden Sie einen gemeinsamen Backing-Store als Sitzungsspeicher

Der empfohlene Ansatz für die Migration von statusbehafteten ASP.NET Web Forms-Anwendungen zu AWS ist die Verwendung eines gemeinsamen Backing-Speichers für den Sitzungsspeicher. Anstatt sich auf den In-Memory-Sitzungsstatus einzelner EC2 Instances zu verlassen, kann die Anwendung Sitzungsdaten in einer hochverfügbaren und skalierbaren Speicherlösung wie Amazon DynamoDB, Amazon Relational Database Service (Amazon RDS) für SQL Server oder Amazon ElastiCache (Redis OSS) speichern.

Wenn Sie einen gemeinsamen Backing-Store verwenden, entkoppeln Sie den Sitzungsstatus von einzelnen EC2 Instances, sodass die Anwendung nahtlos auf mehrere Instances skalieren kann, ohne Sitzungsdaten zu verlieren. Dieser Ansatz verbessert auch die Fehlertoleranz, da Sitzungsdaten unabhängig von den Anwendungsinstanzen bestehen bleiben. Dadurch wird sichergestellt, dass Benutzersitzungen auch bei einem Ausfall der Instanz oder bei Skalierungsereignissen nicht verloren gehen.

So konfigurieren Sie Ihre ASP.NET Web Forms-Anwendung so, dass sie Redis als gemeinsamen Backing-Store für den Sitzungsspeicher verwendet:

1. Erstellen Sie eine neue Sicherheitsgruppe für den Cluster. Die Sicherheitsgruppe muss eingehende Anfragen an Redis zulassen, das den TCP-Port 6379 verwendet.

2. Starten Sie einen neuen Redis-Cluster. Stellen Sie sicher, dass Sie die Sicherheitsgruppe angeben, die Sie im ersten Schritt erstellt haben.

3. Rufen Sie die Endpunktadresse der Instanz ab, die Sie gerade erstellt haben. Sie müssen einige Minuten warten, bis der Cluster gestartet wird, bevor die Adresse verfügbar wird.

4. Ändern Sie die web.config Datei und fügen Sie die folgende Konfiguration hinzu:

   <sessionState mode="Custom" customProvider="RedisStateStore">
     <providers>
       <add name="RedisStateStore" type="Microsoft.Web.Redis.RedisSessionStateProvider"
            host="[YourRedisClusterEndpoint]"
            accessKey=""
            ssl="true" />
     </providers>
   </sessionState>

   [YourRedisClusterEndpoint]Ersetzen Sie durch den entsprechenden Wert für Ihren ElastiCache (Redis OSS) -Cluster.

Durch die Implementierung eines gemeinsamen Backing-Speichers für den Sitzungsspeicher können Sie Ihrer migrierten ASP.NET Web Forms-Anwendung Hochverfügbarkeit, Skalierbarkeit und Fehlertoleranz bieten. AWS Dieser Ansatz entspricht den Cloud-nativen Best Practices und gewährleistet eine nahtlose Benutzererfahrung, selbst wenn Ihre Anwendung über mehrere EC2 Instanzen oder Availability Zones skaliert wird. Darüber hinaus bietet er eine robustere und zuverlässigere Lösung als Sticky Sessions und ermöglicht es Ihrer Anwendung, die Skalierbarkeit und Belastbarkeit der Infrastruktur voll auszuschöpfen. AWS