# Session Persistence: Warum ‘Klebende’ Sitzungen im Cluster wichtig sind

TL;DR / Management Summary Ein moderner Applikations-Cluster besteht aus vielen Servern. Ohne Session Persistence (Sticky Sessions) würde jeder Mausklick des Users auf einem anderen Server landen. Für Apps, die Session-Daten im lokalen RAM speichern (z.B. ein gefüllter Warenkorb), führt dies zum sofortigen Datenverlust. Ein Senior Admin nutzt Cookie-basierte Persistence (Layer 7), um den User während seiner gesamten Sitzung an denselben Backend-Server zu binden.

# 1. Das Problem: Die vergessliche Session

Vom Warenkorb zum Error.

1. User meldet sich auf Server A an.
2. Server A speichert die Session-ID im lokalen Speicher.
3. User klickt auf “Kasse”.
4. Loadbalancer leitet die Anfrage an Server B weiter.
5. Server B: “Ich kenne diesen User nicht!” -> Redirect zum Login.

# 2. Methoden der Persistenz

Wie der Balancer sich erinnert.

# 1. Source IP Hash (Layer 4)

Der Balancer berechnet einen Hash aus der IP des Users. Alle Anfragen dieser IP gehen immer an das gleiche Backend.

• Vorteil: Schnell, funktioniert mit allen Protokollen.
• Nachteil: Ungerecht bei Firmennetzwerken. 1000 Mitarbeiter hinter einem Firmen-Proxy nutzen die gleiche öffentliche IP und landen alle auf dem gleichen (überlasteten) Backend-Server.

# 2. Cookie Insertion (Layer 7 - Empfohlen)

Der Loadbalancer fügt der ersten Antwort des Servers ein eigenes Cookie hinzu (z.B. SERVERID=s1).

• Vorgang: Der Browser schickt das Cookie bei jedem weiteren Klick mit. Der Balancer liest das Cookie und weiß sofort: “Ab zu Server 1!”.
• Vorteil: Perfekte Lastverteilung auch hinter Proxies.

# 3. Deep Dive: Stick Tables

Das Gedächtnis des Balancers.

Moderne Loadbalancer (wie HAProxy, Artikel 746) nutzen Stick Tables.

• Funktion: Der Balancer merkt sich im RAM: “User X (ID/Session) ist auf Server 2”.
• Sync: Diese Tabellen können zwischen zwei HA-Loadbalancern (Artikel 563) synchronisiert werden, damit die Persistenz auch bei einem Failover des Balancers erhalten bleibt.

# 4. Day-2 Operations: Session-Dauer & Timeouts

Wann darf der User ‘umziehen’?

Definieren Sie, wie lange eine Sitzung “kleben” bleibt.

• Idle Timeout: Wenn der User 30 Minuten nichts tut, wird die Bindung gelöscht.
• Wichtig: Der Timeout am Loadbalancer sollte identisch oder etwas länger sein als der Session-Lifetime Wert Ihrer Applikation.

# 5. Troubleshooting & “War Stories”

Wenn die Bindung reißt.

# Top 3 Fehlerbilder

1. Symptom: User fliegen sporadisch aus der Applikation.

   • Ursache: Der Browser des Users blockiert Cookies von Drittanbietern oder der Loadbalancer-Cookie Name kollidiert mit der Applikation.
   • Lösung: Cookie-Präfixe ändern (z.B. LB_SRV_ID).

2. Symptom: “Unbalanced Load”. Ein Server hat 90% der User, die anderen 10%.

   • Ursache: Zu lange Persistence-Zeiten (Tage statt Stunden) oder Nutzung von Source-IP-Hashing in Mobilfunknetzen.

3. Symptom: Persistence geht nach einem Gateway-Failover verloren.

   • Fix: State-Synchronisation (pfsync / Stick Table Sync) aktivieren.

# “War Story”: Der “Zufalls”-Logout im WLAN

In einem Unternehmen klagten Mitarbeiter über ständige Logouts in der Zeiterfassung. Die Entdeckung: Das Firmen-WLAN hatte zwei Internet-Ausgänge (Load Balancing, Artikel 573). Der Laptop wechselte beim Bewegen durch das Gebäude ständig die öffentliche IP. Die Ursache: Da der Loadbalancer des Web-Dienstes im Internet auf Source IP Hash eingestellt war, landete der User bei jedem IP-Wechsel auf einem neuen Backend-Server, der ihn nicht kannte. Lösung: Umstellung auf Cookie-basierte Persistence. Ab diesem Moment war die IP-Adresse egal – das Cookie hielt den User auf dem richtigen Server. Lehre: Verlassen Sie sich niemals auf die IP-Adresse zur Identifikation einer Sitzung. Das Cookie ist die einzig wahre ID im Web.

# 6. Monitoring & Reporting

Session-Audit.

# Dashboard Check

Überwachen Sie die Persistence Hit Rate im Loadbalancer.

• KPI: Wie viele User nutzen ein bestehendes Mapping vs. wie viele neue Mappings werden erstellt?

# 7. Fazit & Empfehlung

Sticky Sessions sind die Brücke zwischen alten Applikationen und modernen Clustern.

• Empfehlung: Nutzen Sie Application Cookie Persistence für alle Web-Apps.
• Wichtig: Wenn Sie eine neue Applikation entwickeln, bauen Sie diese Stateless (z.B. via Redis für Sessions). Eine Stateless App braucht keine Sticky Sessions und skaliert wesentlich besser.

# Anhang: Cheatsheet (Methodenvergleich)

# Referenzen

• F5: Session Persistence Basics
• HAProxy: Using Stick Tables
• AWS: Elastic Load Balancing - Sticky Sessions