Sitzungspersistenz (Sticky Sessions)

Sitzungspersistenz, auch bekannt als Sticky Sessions, ist eine Lastverteilungstechnik, die von Proxys verwendet wird, um sicherzustellen, dass alle Anfragen eines bestimmten Clients während der gesamten Dauer seiner Sitzung konsistent an denselben Backend-Server weitergeleitet werden.

Dieser Mechanismus begegnet der Herausforderung, die zustandsbehaftete Anwendungen in einer Lastverteilungsumgebung darstellen. Viele Webanwendungen speichern sitzungsspezifische Daten (z. B. Warenkorbinhalte, Benutzerauthentifizierungsstatus, personalisierte Einstellungen) auf dem Server. Ohne Sitzungspersistenz könnte eine nachfolgende Anfrage eines Clients vom Lastverteiler an einen anderen Backend-Server geleitet werden. Wenn dieser Server die Sitzungsdaten des Clients nicht enthält, geht der Sitzungsstatus verloren, was zu Fehlern führt, eine erneute Authentifizierung erfordert oder den Client zwingt, seine Interaktion neu zu starten. Sticky Sessions verhindern dies, indem sie einen Client an einen bestimmten Server "binden", sobald eine Erstverbindung hergestellt wurde.

Wie Sitzungspersistenz funktioniert

Proxys implementieren Sitzungspersistenz mit verschiedenen Methoden, hauptsächlich indem sie einen Client identifizieren und diesen Client dann einem bestimmten Backend-Server zuordnen.

Methoden zur Client-Identifikation

IP-Hash (Quell-IP-Hashing)

Diese Methode verwendet die IP-Adresse des Clients als Schlüssel, um den Backend-Server zu bestimmen. Der Proxy hasht die IP-Adresse des Clients und verwendet den resultierenden Wert, um einen Server aus dem verfügbaren Pool auszuwählen. Dies stellt sicher, dass alle Anfragen, die von derselben IP-Adresse stammen, an denselben Server geleitet werden.

• Mechanismus: hash(client_ip) % number_of_servers
• Vorteile: Einfach zu implementieren, keine clientseitigen Cookies oder Anwendungsmodifikationen erforderlich.
• Nachteile:
  • Lastungleichgewicht: Wenn viele Clients dieselbe öffentliche IP teilen (z. B. hinter einem NAT-Gateway, Unternehmensnetzwerk), kann dieser einzelne Server überlastet werden.
  • Serverausfall: Wenn der zugewiesene Server ausfällt, geht die Sitzung des Clients verloren, und nachfolgende Anfragen werden an einen neuen Server geleitet (wobei die Persistenz möglicherweise verloren geht, wenn die Hash-Berechnung auf einen anderen Server zeigt oder der Proxy neu evaluiert).
  • Dynamische IPs: Clients mit dynamischen IP-Adressen können ihre Sitzung verlieren, wenn sich ihre IP während der Sitzung ändert.

Cookie-basierte Persistenz

Dies ist eine weit verbreitete und flexiblere Methode. Der Proxy oder die Anwendung fügt ein Cookie in den Browser des Clients ein. Dieses Cookie enthält Informationen, die vom Proxy verwendet werden, um nachfolgende Anfragen an den richtigen Backend-Server weiterzuleiten.

Proxy-generierte Cookies

Der Proxy selbst injiziert ein Cookie in die HTTP-Antwort, bevor er sie an den Client sendet. Dieses Cookie enthält typischerweise einen Bezeichner für den Backend-Server, der die ursprüngliche Anfrage verarbeitet hat. Bei nachfolgenden Anfragen liest der Proxy dieses Cookie und leitet den Client an den identifizierten Server weiter.

• Mechanismus: Proxy fängt Antwort ab, fügt Set-Cookie: PROXY_SESSION_ID=server_id Header hinzu. Bei nachfolgenden Anfragen liest Proxy Cookie: PROXY_SESSION_ID=server_id und leitet an server_id weiter.
• Vorteile: Erfordert keine Anwendungsmodifikation, transparent für die Anwendung.
• Nachteile:
  • Serverausfall: Wenn der identifizierte Server ausfällt, geht die Sitzung des Clients verloren. Der Proxy muss die Anfrage dann an einen neuen Server leiten und das Cookie aktualisieren, oder der Client erfährt einen Fehler.
  • Cookie-Verwaltung: Erfordert, dass Client-Browser Cookies akzeptieren und senden.

Anwendungsgenerierte Cookies

Die Backend-Anwendung selbst erstellt und verwaltet ein Sitzungs-Cookie (z. B. JSESSIONID für Java-Anwendungen, PHPSESSID für PHP). Der Proxy ist so konfiguriert, dass er dieses spezifische Anwendungs-Cookie inspiziert und dessen Wert (oder einen Teil davon) verwendet, um den Ziel-Backend-Server zu bestimmen. Der Proxy könnte den Cookie-Wert hashen oder einen darin eingebetteten Server-Bezeichner extrahieren.

• Mechanismus: Anwendung setzt Set-Cookie: APP_SESSION_ID=unique_session_id. Proxy liest Cookie: APP_SESSION_ID=unique_session_id und verwendet diesen Wert zur Zuordnung zu einem Server.
• Vorteile: Nutzt bestehende Anwendungs-Sitzungsverwaltung, potenziell robuster bei der Identifizierung eindeutiger Sitzungen.
• Nachteile: Erfordert Proxy-Konfiguration, um anwendungsspezifische Cookie-Formate zu verstehen. Serverausfall führt zu Sitzungsverlust.

Header-basierte Persistenz

Weniger verbreitet als IP-Hash- oder Cookie-basierte Methoden, verwendet dieser Ansatz einen benutzerdefinierten HTTP-Header, um Sitzungs- oder Serveridentifikationsinformationen zu übertragen. Der Client oder ein zwischengeschalteter Proxy könnte diesen Header einfügen.

• Mechanismus: Proxy liest X-Server-ID: server_123 oder X-Client-Session: abcdef und leitet entsprechend weiter.
• Vorteile: Kann in spezifischen API-Gateway- oder Microservices-Architekturen nützlich sein.
• Nachteile: Erfordert spezifische Client- oder Upstream-Proxy-Kooperation zum Einfügen von Headern. Nicht geeignet für Standard-Webbrowser ohne clientseitiges Scripting.

Vergleich der Sticky-Session-Methoden

Warum Sitzungspersistenz wichtig ist

• Unterstützung zustandsbehafteter Anwendungen: Essentiell für Anwendungen, die Sitzungsdaten lokal auf dem Server speichern (z. B. E-Commerce-Warenkörbe, Anmeldesitzungen, mehrstufige Formulare).
• Benutzererfahrung: Verhindert Sitzungsverlust, erneute Anmeldungen oder Fortschrittsverlust, was zu einer reibungsloseren Benutzererfahrung führt.
• Vereinfachung des Anwendungsdesigns: Reduziert den Bedarf an komplexen verteilten Sitzungsverwaltungslösungen (z. B. externe Sitzungsspeicher wie Redis oder Memcached), wodurch Anwendungen einfacher bleiben können.

Nachteile und Überlegungen

• Lastungleichgewicht: Der Hauptnachteil. Wenn ein Server eine unverhältnismäßig hohe Anzahl von "sticky" Clients verarbeitet, kann er überlastet werden, während andere Server unterausgelastet bleiben. Dies kann die Vorteile der Lastverteilung zunichtemachen.
• Auswirkungen bei Serverausfall: Wenn ein Server mit aktiven Sticky Sessions ausfällt, verlieren alle Clients, die derzeit an diesen Server "gebunden" sind, ihre Sitzungsdaten. Dies kann zu einer verschlechterten Benutzererfahrung oder Dienstunterbrechung für diese Clients führen.
• Skalierbarkeitsprobleme: Kann die horizontale Skalierung erschweren. Das Hinzufügen oder Entfernen von Backend-Servern kann bestehende Sticky Sessions stören und erfordert eine sorgfältige Verwaltung während Skalierungsvorgängen.
• Ressourcenverbrauch: Die Aufrechterhaltung der Persistenz-Zuordnung (z. B. in einer Nachschlagetabelle) verbraucht Ressourcen auf dem Proxy.
• Overhead der Cookie-Verwaltung: Bei Cookie-basierten Methoden entsteht ein geringer Overhead beim Setzen und Lesen von Cookies für jede Anfrage.

Konfigurationsbeispiele

Nginx (Open Source)

Nginx kann Sticky Sessions mithilfe der ip_hash-Direktive oder fortgeschrittenerer Cookie-basierter Methoden mit kommerziellen Modulen oder Drittanbieter-Modulen wie nginx-sticky-module-ng implementieren.

IP-Hash

http {
    upstream backend {
        ip_hash;
        server backend1.example.com;
        server backend2.example.com;
        server backend3.example.com;
    }

    server {
        listen 80;
        location / {
            proxy_pass http://backend;
        }
    }
}

In diesem Beispiel stellt ip_hash; sicher, dass Anfragen von derselben Client-IP-Adresse konsistent an denselben Server in der backend-Upstream-Gruppe weitergeleitet werden.

Cookie-basiert (unter Verwendung des sticky-Moduls – typischerweise Nginx Plus oder Drittanbieter)

Bei Verwendung von Nginx Plus oder einem kompatiblen Drittanbieter-Modul:

http {
    upstream backend {
        # Using a proxy-generated cookie named "route"
        # The value is a route ID assigned by Nginx to the server.
        sticky route $cookie_route;
        server backend1.example.com route=A;
        server backend2.example.com route=B;
        server backend3.example.com route=C;
    }

    server {
        listen 80;
        location / {
            proxy_pass http://backend;
        }
    }
}

Hier konfiguriert sticky route $cookie_route; Nginx, ein Cookie namens route für die Sitzungspersistenz zu verwenden. Nginx setzt dieses Cookie mit einem Wert (A, B oder C), der dem ursprünglich gewählten Backend-Server entspricht.

Alternativ kann sticky learn verwendet werden, um anwendungsgenerierte Cookies zu lernen:

http {
    upstream backend {
        # Learn from the application's JSESSIONID cookie
        sticky learn
               create=$upstream_cookie_JSESSIONID
               lookup=$cookie_JSESSIONID
               zone=client_sessions:1m; # Shared memory zone for session data
        server backend1.example.com;
        server backend2.example.com;
        server backend3.example.com;
    }

    server {
        listen 80;
        location / {
            proxy_pass http://backend;
        }
    }
}

Diese Konfiguration versucht, das vom Backend-Anwendung gesetzte JSESSIONID-Cookie zu lernen. Wenn das Cookie vorhanden ist, verwendet Nginx dessen Wert, um nachfolgende Anfragen an den Server weiterzuleiten, der es ursprünglich gesetzt hat.

HAProxy

HAProxy bietet robuste Sticky-Session-Funktionen, die sowohl IP-basierte als auch Cookie-basierte Methoden unterstützen.

IP-Hash (Quell-IP-Hashing)

frontend http_front
    bind *:80
    default_backend http_back

backend http_back
    balance source  # Uses client's IP address
    server backend1 192.168.1.10:80 check
    server backend2 192.168.1.11:80 check
    server backend3 192.168.1.12:80 check

Die Direktive balance source weist HAProxy an, die Quell-IP-Adresse des Clients für die Lastverteilung zu verwenden, was effektiv Sticky Sessions bereitstellt.

Proxy-generiertes Cookie

frontend http_front
    bind *:80
    default_backend http_back

backend http_back
    balance roundrobin
    cookie SERVERID insert indirect nocache  # Insert a cookie named SERVERID
    server backend1 192.168.1.10:80 cookie S1 check
    server backend2 192.168.1.11:80 cookie S2 check
    server backend3 192.168.1.12:80 cookie S3 check

Hier weist cookie SERVERID insert indirect nocache HAProxy an, ein Cookie namens SERVERID in die Antwort des Clients einzufügen. Die cookie S1, cookie S2 usw. in jeder Serverzeile geben den Wert an, den HAProxy für diesen Server verwenden soll. HAProxy verwendet dieses Cookie dann, um nachfolgende Anfragen weiterzuleiten. indirect bedeutet, dass das Cookie nur gesetzt wird, wenn der Client noch keines hat, und nocache verhindert, dass Caching-Proxys Antworten mit dem Set-Cookie-Header cachen.

Anwendungsgeneriertes Cookie

frontend http_front
    bind *:80
    default_backend http_back

backend http_back
    balance roundrobin
    appsession JSESSIONID len 52 timeout 3h # Use the JSESSIONID cookie
    server backend1 192.168.1.10:80 check
    server backend2 192.168.1.11:80 check
    server backend3 192.168.1.12:80 check

Die Direktive appsession JSESSIONID len 52 timeout 3h konfiguriert HAProxy, nach einem Cookie namens JSESSIONID zu suchen (üblich für Java-Anwendungen). len 52 gibt die Länge der zu berücksichtigenden Sitzungs-ID an, und timeout 3h legt fest, wie lange HAProxy die Sitzungs-zu-Server-Zuordnung speichert, wenn das Cookie in einer Anfrage nicht vorhanden ist. Diese Methode erfordert, dass die Anwendung das JSESSIONID-Cookie setzt.