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.
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.
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.
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.
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.
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.
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.
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.
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.
Hash auf einen bestimmten Query-Parameter (z. B. ?user_id, ?session_token). Leitet dieselbe benutzerbezogene Anfrage ohne Cookies an dasselbe Backend weiter.
Hash auf einen benutzerdefinierten HTTP-Header. Nützlich, wenn der Upstream-Aufrufer Tenant- oder Korrelations-IDs injiziert, oder für headerbasiertes A/B-Routing.
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 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.
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.
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.
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 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.
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.
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.
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.
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.
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
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.
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-Sitzungen müssen sich mit demselben Host neu verbinden. RDP-Cookie-Persistenz liest die protokollnative Sitzungs-ID — keine zusätzliche Konfiguration, keine Cookie-Injektion.
Anwendungen, die Sitzungen nicht selbst verfolgen. Source-IP- oder URL-Parameter-Persistenz fixiert Benutzer, ohne Code-Änderungen an der Legacy-App zu erfordern.
Sehen Sie, wie 9 Persistenzmethoden jeden häufigen Fall abdecken — von RDP-Gateways bis Legacy-Apps bis SAM-gesteuerte Cookies.