Load Balancer - Sessionpersistenz
Verwenden Sie Sessionpersistenz mit einem Load Balancer, um alle Anforderungen von einem einzelnen logischen Client an einen einzelnen Backend-Webserver weiterzuleiten.
Sessionpersistenz ist eine Methode zur Weiterleitung aller Anforderungen von einem einzelnen logischen Client zu einem einzelnen Backend-Webserver. Backend-Server, die Caching zur Verbesserung der Performance oder zur Aktivierung von Anmeldesessions oder Warenkörben verwenden, können von Sessionpersistenz profitieren.
Sie aktivieren Sessionpersistenz, wenn Sie einen Load Balancer erstellen oder wenn Sie ein Backend-Set erstellen. Sie können auch ein vorhandenes Backend-Set bearbeiten, um die Sessionpersistenzkonfiguration zu aktivieren, zu deaktivieren oder zu ändern.
Sticky-Cookies
Der Load-Balancer-Service bietet zwei sich gegenseitig ausschließende cookiebasierte Konfigurationen zum Aktivieren von Sessionpersistenz:
IP-adressgesteuerte Sessionpersistenz
Einige Produkte bieten Sessionpersistenzsupport ohne Cookies. Diese Produkte hängen von der IP-Adresse der eingehenden Anforderung ab. ISP-Proxys und Firmen-Exit-Gateways können viele Anforderungen von einer einzelnen IP-Adresse ausgeben. In diesem Fall kann ein einzelner Backend-Server hohem Trafficvolumen unterliegen. Ihre Backend-Server können überlastet werden (einer nach dem anderen), selbst wenn effektives Load Balancing möglich ist.
Eine weitere Schwachstelle von IP-Adressen-gesteuerter Sessionpersistenz besteht darin, dass sich die ursprüngliche IP-Adresse ändern kann. In diesem Fall kann die Sessionpersistenz verloren gehen oder die Anforderung zum falschen Backend-Server umgeleitet werden.
Stickiness für Anwendungscookies
Um die Sessionpersistenz für Anwendungscookies zu konfigurieren, geben Sie einen Cookienamen an und entscheiden, ob Sie für nicht verfügbare Server Fallback deaktivieren möchten.
Der Load-Balancer-Service aktiviert die Sessionpersistenz (Stickiness) für Anwendungscookies, wenn ein Backend-Server einen Set-Cookie-Antwortheader mit einem erkannten Cookienamen sendet. Der Cookiename muss mit dem Namen übereinstimmen, der in der Konfiguration des Backend-Sets angegeben ist. Wenn in der Konfiguration ein Match-All-Muster ('*') angegeben wurde, aktiviert jedes vom Server festgelegte Cookie die Sessionpersistenz. Wenn die Sessionpersistenz nicht von einem Backend-Server aktiviert wird, hält sich der Service an die Load Balancing Policy, die beim Erstellen des Load Balancers angegeben wurde.
Anforderungen:
- Der Load Balancer muss im HTTP-Modus ausgeführt werden, um serverseitige, cookiegesteuerte Sessionpersistenz zu unterstützen.
- Der Clientrechner muss Cookies akzeptieren, damit die Sessionpersistenz für Load Balancer funktioniert.
Der Load-Balancer-Service berechnet einen Hashwert des konfigurierten Cookies und anderer Anforderungsparameter und sendet den Wert in einem Cookie an den Client. Mit dem im Cookie gespeicherten Wert kann der Service spätere Clientanforderungen an den richtigen Backend-Server weiterleiten. Wenn Ihre Backend-Server die definierten Cookies ändern, berechnet der Service den Wert des Cookies neu und sendet es erneut an den Client.
Es wird empfohlen, Cookie-Daten als undurchsichtige Entity zu behandeln. Nicht in Ihren Anwendungen verwenden.
Der Backend-Server kann die Persistenz des Anwendungscookies durch Löschen des Sessionpersistenzcookies stoppen. Wenn Sie das Match-All-Muster verwendet haben, werden alle Cookies gelöscht. Sie können Cookies löschen, indem Sie einen Set-Cookie-Antwortheader mit einem vergangenen Ablaufdatum senden. Der Load-Balancer-Service leitet spätere Anforderungen mithilfe der konfigurierten Load Balancing Policy weiterzu.
Stickiness für Load-Balancer-Cookies
Wenn Sie Stickiness für Load-Balancer-Cookies konfigurieren, fügt der Load Balancer ein Cookie in die Antwort ein. Die innerhalb des Cookies konfigurierten Parameter aktivieren Session-Stickiness. Diese Methode ist nützlich, wenn Sie Anwendungen und Web-Backend-Services verwenden, die ihre eigenen Cookies nicht erzeugen können.
Um Sessionpersistenz für Load-Balancer-Cookies zu konfigurieren, geben Sie Folgendes an:
- Den Cookienamen.
Wenn Sie keinen Cookienamens angeben, wird der Standardname
X-Oracle-BMC-LBS-Routeverwendet.Hinweis
Stellen Sie sicher, dass der Cookiename, der auf den Backend-Anwendungsservern verwendete wird, von dem im Load Balancer verwendeten Cookiename abweicht. Um die Wahrscheinlichkeit eines Namenskonflikts zu minimieren, wird empfohlen, ein Präfix wieX-Oracle-OCI-zu verwenden.Wenn sowohl ein Backend-Server als auch der Load Balancer Cookies mit dem gleichen Namen einfügen, kann das Client- oder Browserverhalten variieren, je nachdem, welcher Domainwert mit dem Cookie verknüpft ist. Wenn der Name und die Domainwerte des
Set-cookie-Headers, der von einem Backend-Server generiert wird, und desSet-cookie-Headers, der vom Load Balancer generiert wird, identisch sind, werden sie vom Client oder Browser als ein und dasselbe Cookie behandelt. Der Client gibt in späteren Anforderungen nur einen der Cookiewerte zurück. Wenn beideSet-cookie-Namen identisch sind, die Domainnamen jedoch unterschiedlich sind, werden sie vom Client oder Browser als zwei unterschiedliche Cookies behandelt. - Die Domain, in der das Cookie gültig ist. Der vom Load Balancer eingefügte
Set-cookie-Header enthält ein Domainattribut mit dem angegebenen Wert.Für dieses Attribut gibt es keinen Standardwert. Wenn Sie einen Wert angeben, fügt der Load Balancer nicht das Domainattribut in den
Set-cookie-Header ein.Hinweis
- In RFC 6265 - HTTP State Management Mechanism wird das Client- und Browserverhalten beschrieben, das zur Anwendung kommt, wenn das Domainattribut im
Set-cookie-Header vorhanden bzw. nicht vorhanden ist.Wenn der Wert des
Domain-Attributs imSet-cookie-Headerexample.comlautet, nimmt der Client beim Senden von HTTP-Anforderungen anexample.com,www.example.comundwww.abc.example.comdas gleiche Cookie in denCookie-Header auf. Wenn das AttributDomainnicht vorhanden ist, gibt der Client das Cookie nur für die Domain zurück, an die die ursprüngliche Anforderung gesendet wurde. - Stellen Sie sicher, dass dieses Attribut den richtigen Domainwert angibt. Wenn das
Domain-Attribut imSet-cookie-Header die Domain nicht enthält, an welche die ursprüngliche Anforderung gestellt wurde, lehnt der Client oder Browser das Cookie möglicherweise ab. Wie in RFC 6265 angegeben, akzeptiert der Client Cookies mit demDomain-Attributwertexample.comoderwww.example.com, die vonwww.example.comgesendet wurden. Cookies mit demDomain-Attributabc.example.comoderwww.abc.example.com, das vonwww.example.comgesendet wurde, werden dabei nicht akzeptiert.
- In RFC 6265 - HTTP State Management Mechanism wird das Client- und Browserverhalten beschrieben, das zur Anwendung kommt, wenn das Domainattribut im
- Den URI-Pfad, in dem das Cookie gültig ist. Der vom Load Balancer eingefügte
Set-cookie-Header enthält einPath-Attribut mit dem angegebenen Wert.Clients nehmen das Cookie nur dann in eine HTTP-Anforderung auf, wenn der Pfadteil der
request-urimit demPath-Attribut des Cookies übereinstimmt oder ein Unterverzeichnis davon ist.Der Standardwert lautet `/`.
- Den Zeitraum, in dem das Cookie gültig ist. Der vom Load Balancer eingefügte
Set-cookie-Header enthält einMax-Age-Attribut mit dem angegebenen Wert.Der angegebene Wert muss mindestens eine Sekunde sein. Für dieses Attribut ist kein Standardwert vorhanden. Wenn Sie keinen Wert angeben, fügt der Load Balancer das
Max-Age-Attribut nicht in denSet-cookie-Header ein. Im Allgemeinen behält der Client oder Browser das Cookie, wie vom Client definiert, bis zum Ende der aktuellen Session bei. - Ob der
Set-cookie-Header dasSecure-Attribut enthalten soll. DasSecure-Attribut weist den Client oder Browser an, das Cookie nur mit einem sicheren Protokoll zu senden.Hinweis
Wenn Sie dieses Feld auf TRUE setzen, können Sie das entsprechende Backend-Set keinem HTTP-Listener zuweisen.
- Ob der
Set-cookie-Header dasHttpOnly-Attribut enthalten soll. DasHttpOnly-Attribut begrenzt den Geltungsbereich des Cookies auf HTTP-Anforderungen. Dieses Attribut weist den Client oder Browser an, das Cookie auszulassen, wenn der Zugriff auf Cookies über Nicht-HTTP-APIs ermöglicht wird. Beispiel: Es sorgt dafür, dass das Cookie nicht in JavaScript-Kanälen verwendet werden kann. - Ob Sie für nicht verfügbare Server Fallback deaktivieren möchten.
Pfadroutenregeln haben Vorrang, um den Ziel-Backend-Server zu bestimmen. Der Load Balancer prüft, ob Session-Stickiness für den Backend-Server aktiviert ist und ob die Cookiekonfiguration für das Ziel gültig ist. Ungültige Cookies werden vom System ignoriert.
Fallback
Der Load-Balancer-Service leitet Traffic von einem persistenten Sessionclient standardmäßig an einen anderen Backend-Server weiter, wenn der ursprüngliche Server nicht verfügbar ist. Sie können das Backend-Set so konfigurieren, dass dieses Fallback-Verhalten deaktiviert wird. Wenn Sie Fallback deaktivieren, ist die Anforderung nicht erfolgreich, und es wird ein HTTP 502-Code vom Load Balancer zurückgegeben. Der Service gibt solange einen HTTP 502-Code zurück, bis der Client kein persistentes Sessioncookie mehr präsentiert.
Wenn Fallback deaktiviert ist, können Cookies mit einem Ablaufdatum in der fernen Zukunft liegen, einen Clientausfall verursachen.
Der Load-Balancer-Service betrachtet einen Server, der als drain markiert ist, für vorhandene persistierte Sessions verfügbar. Neue Anforderungen, die nicht Teil einer vorhandenen persistenten Session sind, werden nicht an diesen Server gesendet.