Wann Load Balancing Sitzungen unterbricht
Round-Robin sendet jede Anfrage an ein anderes Backend — by Design. Für zustandslose Dienste ist das perfekt. Aber sobald sich ein Benutzer einloggt, einen Warenkorb füllt oder einen Remote Desktop startet, beginnt die Anwendung, Zustand auf einem bestimmten Backend zu halten. Wenn Anfrage Nr. 2 auf einem anderen landet, sieht der Benutzer einen leeren Warenkorb, einen ausgeloggten Bildschirm oder eine eingefrorene RDP-Sitzung.
Session-Persistenz (oder „Affinity“) löst dies, indem ein Benutzer für die Dauer der Sitzung an ein gewähltes Backend gebunden wird. Der Haken: Es gibt keinen einzig richtigen Weg zum Binden. Source-IP funktioniert für Benutzer mit eindeutigen IPs, bricht aber hinter Corporate NAT zusammen. Cookies funktionieren in Browsern, aber nicht für rohes TCP. URL-Parameter-Hash funktioniert für zustandslose URLs, aber nicht für benutzerbezogene Flows. Jede Methode ist irgendwo richtig.
Die Antwort besteht darin, jede Methode zu liefern und pro vService zu wählen.
Die Persistenzmethode pro vService wählen
Jeder vService wählt seine Persistenzmethode aus einem Dropdown — neben seinem Load-Balancing-Algorithmus. Beide Schichten sind unabhängig: Fastest+ für die Backend-Auswahl und ein TR7-Cookie für Affinity wählen, oder Round-Robin mit Source-IP, oder welche Kombination auch immer zur Workload passt. Methodenwahl ist Hot-Swap, kein Neustart.
9 Methoden mitgeliefert
Fünf selbst-persistente Load-Balancing-Algorithmen (source, URI, URL-param, header, RDP-cookie) plus vier explizite Persistenzmethoden (TR7-Cookie, Backend-Cookie, dynamisch, SAM). Deckt jeden häufigen Fall ab.
SAM — volle Cookie-Kontrolle
Session Affinity Manager ermöglicht es Ihnen, die Cookie-Quelle (TR7-generiert oder Backend-generiert), das Sitzungsformat (UUID, IP-Timestamp-Random, IP-Random, Custom) und Sicherheits-Flags (HttpOnly, Secure, SameSite=Strict/Lax) einzustellen — ohne Backend-Code zu berühren.
Kombinierbar mit jedem ADC-Algorithmus
Persistenz läuft auf dem Load-Balancing-Algorithmus auf: Der Algorithmus wählt das Backend für die erste Anfrage; Persistenz fixiert den Rest. Fastest+ für den Kaltstart, Sticky-Cookie für die Sitzung — funktioniert zusammen.
Hot-Swap (kein Neustart)
Die Persistenzmethode bei einem laufenden vService ändern und neue Sitzungen übernehmen sofort die neue Methode. Bestehende fixierte Sitzungen laufen ungestört weiter, bis sie ablaufen.
9 mitgelieferte Session-Persistenz-Methoden
Die Methode wählen, die zum Protokoll, der Client-Population und dem Sitzungsmodell der Anwendung passt. Alle 9 pro vService verfügbar — kein Code, kein Plugin. Neun ist die Zahl der benannten Methoden: Die Dynamic-Hash-Methode bildet ihren Schlüssel aus der Ausdruckssprache — die Schlüssel, auf die Sie Sitzungen binden können, sind also nicht auf neun begrenzt.
Source-IP
Dieselbe Client-IP landet immer auf demselben Backend. Einfach, codefrei, funktioniert für jedes Protokoll. Am besten, wenn Client-IPs vielfältig sind — bricht hinter Shared NAT oder Corporate Proxies zusammen.
URI-Längen-Hash
Hash auf die URL-Länge verteilt die Last nach URL-Komplexität, während identische URLs auf dasselbe Backend fixiert werden. Nützlich für Cache-Affinitäts-Szenarien.
URL-Parameter-Hash
Hash auf einen bestimmten Query-Parameter (z. B. ?user_id, ?session_token). Leitet dieselbe benutzerbezogene Anfrage ohne Cookies an dasselbe Backend weiter.
Header-Hash
Hash auf einen benutzerdefinierten HTTP-Header. Nützlich, wenn der Upstream-Aufrufer Tenant- oder Korrelations-IDs injiziert, oder für headerbasiertes A/B-Routing.
RDP-Cookie
Liest den im Protokoll-Handshake eingebetteten RDP-Sitzungs-Cookie. Erforderlich für RDP-Gateways und Remote-Desktop-Farmen — hält Benutzer nach einem Reconnect auf demselben RDP-Host.
TR7-Cookie
TR7 ADC generiert und verwaltet den Affinity-Cookie selbst — kein Backend-Code erforderlich. Der Operator setzt den Cookie-Namen und ein Max-Idle-Timeout; der ADC liest ihn bei jeder Anfrage, das Backend ignoriert ihn. Einfachste Persistenz, die sich an eine Legacy-App anschließen lässt.
Backend-Cookie
Den eigenen Sitzungs-Cookie der Anwendung für Affinity verwenden — der Operator benennt den Cookie (PHPSESSID, JSESSIONID, app-id oder beliebiger Custom-Name) und TR7 ADC liest den vorhandenen Wert. Keine neuen Cookies hinzugefügt. Richtig, wenn die Anwendung bereits Sitzungen verfolgt und Sie keine zweite Cookie-Schicht aufstaple wollen.
Dynamische Persistenz
Hash-Schlüssel-Persistenztabelle im Speicher gepflegt. Jeder Eintrag bildet einen Schlüssel — eine beliebige Kombination aus Anfrage-Headern, Cookies, Source-IP oder URL-Parametern — auf ein Backend ab. Der Operator setzt die Tabellengröße (10K bis 100M Einträge, Standard 3M) und die Eintrags-Ablaufzeit. Verwenden Sie dies, wenn Persistenzregeln flexibler sein müssen als ein einzelner fester Cookie oder Header.
SAM — Session Affinity Manager
Die erweiterte Cookie-basierte Persistenz-Engine. Wählen Sie, wer den Cookie generiert, das Sitzungs-ID-Format und die Sicherheits-Flags — alles aus der UI, keine Backend-Änderungen. Siehe Details unten.
SAM — Session Affinity Manager
SAM ist TR7s flexibelste Persistenzmethode. Wo ein einfacher Cookie eine Sitzung fixiert, lässt SAM Sie jede Eigenschaft dieses Cookies aus einem Dropdown steuern — ohne Backend-Änderungen, ohne Regelcode zu schreiben.
Zwei Cookie-Quellen
Wählen Sie, wer den Affinity-Cookie generiert: TR7-generiert (Standard — keine Backend-Beteiligung) oder Backend-generiert (den bestehenden Sitzungs-Cookie der Anwendung verwenden). Wechseln Sie zwischen beiden, ohne aktive Sitzungen zu unterbrechen.
Vier Sitzungs-ID-Formate — einschließlich eines weit offenen Custom-Modus
Optionen für das Sitzungsbezeichnerformat: UUID (zufällig 128-bit), IP-Timestamp-Random (nachverfolgbar, zeitgeordnet), IP-Random (anonym innerhalb eines Tenants) oder Custom. Custom-Modus öffnet die gesamte Traffic-Variablenoberfläche — kombinieren Sie beliebige Anfrage-Header, Cookies, URL-Komponenten, TLS-Sitzungsinfo, Source-IP (roh oder maskiert), JWT-Claims, Query-Parameter und sogar Anfrage-Body-Felder mit Operator-definierten Transform-Funktionen (Maskierung, Hashing, Substring-Extraktion, Case-Normalisierung, Verkettung). Dieselbe Variable-und-Transform-Engine treibt auch Dynamic-Persistenz-Hash-Schlüssel an. Echtwelt-Kombinationen finden Sie im Spotlight unten.
Vier Sicherheits-Flag-Kombinationen
Cookie-Sicherheits-Flags: HttpOnly (kein JavaScript-Zugriff — XSS-Schutz), Secure (nur HTTPS), SameSite=Strict (kein Cross-Site-Senden — CSRF-Schutz), SameSite=Lax (kompatibilitätsfreundliche Variante). Nach Bedarf kombinieren.
Operator-konfigurierbar, kein Code
Alles oben Genannte ist ein per-vService-Dropdown im SAM-Panel. Kein benutzerdefinierter Regelcode, keine Backend-Integration, keine separate WAAP-Regel für Cookie-Handling. SAM ist eine Konfiguration, kein Skript.
Jenseits von Cookies und IP — beliebige Traffic-Variablen kombinieren
SAM Custom Format und Dynamic-Persistenz-Hash-Schlüssel akzeptieren jede Traffic-Variable, die TR7 ADC sieht — kombinieren, transformieren, die exakte Persistenzregel erstellen, die Ihre Anwendung benötigt
SAM Custom Format — Echtwelt-Kombinationen
Dynamische Persistenz — Multi-Variable-Hash-Schlüssel
Transform-Funktionen auf jeder Variable
Wenn Persistenz am wichtigsten ist
E-Commerce-Warenkörbe und Checkout
Benutzer fügen Artikel über mehrere Seitenladevorgänge hinzu. Backend-Cookie oder TR7-Cookie hält den Warenkorb-Zustand auf einem Backend — der Checkout sieht nie einen leeren Warenkorb.
Authentifizierte Dashboards
Eingeloggte Sitzungen, bei denen der Berechtigungs-Cache des Benutzers auf einem Backend lebt. SAM mit TR7-generiertem Cookie + HttpOnly + Secure funktioniert ohne Backend-Code-Änderungen.
RDP-Gateways und Remote-Desktop-Farmen
RDP-Sitzungen müssen sich mit demselben Host neu verbinden. RDP-Cookie-Persistenz liest die protokollnative Sitzungs-ID — keine zusätzliche Konfiguration, keine Cookie-Injektion.
Legacy-Apps ohne Session-Management
Anwendungen, die Sitzungen nicht selbst verfolgen. Source-IP- oder URL-Parameter-Persistenz fixiert Benutzer, ohne Code-Änderungen an der Legacy-App zu erfordern.
Häufig gestellte Fragen
Muss ich zwischen Load-Balancing-Algorithmus und Persistenz wählen?
Was ist der Unterschied zwischen TR7-Cookie und SAM?
Was passiert, wenn das fixierte Backend ausfällt?
Kann ich Source-IP-Persistenz hinter einem Corporate NAT verwenden?
Beeinflusst Session-Persistenz WebSocket- und HTTP/2-Verbindungen?
Die Persistenzmethode an die Workload anpassen
Sehen Sie, wie 9 Persistenzmethoden jeden häufigen Fall abdecken — von RDP-Gateways bis Legacy-Apps bis SAM-gesteuerte Cookies.