Das Affinitätsfeature von Content Based Routing (CBR) ordnet eine Client-IP-Adresse einem Back-End-Server zu. Die Affinität wird hergestellt, wenn die Ziel-IP-Adresse eines Pakets mit dem Cluster übereinstimmt,
der Zielport mit dem Load-Balancer-Port übereinstimmt und die
Quellen-IP-Adresse passt.
Informationen zu diesem Vorgang
Bei bestehender Affinität werden alle Pakete an denselben Back-End-Server gesendet. Wenn die Affinität durch das Herunterfahren oder Entfernen eines Servers unterbrochen wird, kommt es zu einer Unterbrechung der gesamten Affinität und damit aller Verbindungen
zu diesem Server. In der Befehlszeile oder auf GUI-Clients werden auch keine Verbindungsinformationen ausgegeben. Es wird nur die Anzahl der aktiven Affinitätssätze verwendet.
Mit dieser Herangehensweise wird eine feste Affinität etabliert, die für Load Balancer effizienter ist. Die
Affinitätsmethode bewirkt, verglichen mit der Verbindungsweiterleitung, eine geringere Speicherbelegung und CPU-Belastung.
Avoid trouble: Da
beim Entfernen eines Affinitätsdatensatzes auch Verbindungen unterbrochen werden,
sollte bei einer Migration von
Load Balancer for IPv4 auf Load Balancer for IPv4 and IPv6 der maximale Wert für "staletimeout" auch als neuer
Wert für die Einstellung "stickytime"
für Load Balancer for IPv4 and IPv6
verwendet werden.
gotcha
Legen Sie für die Komponente CBR die Affinität
als aktive Cookie-Affinität, passive Cookie-Affinität oder URI-Affinität fest.
- Aktive Cookie-Affinität
- Ermöglicht die Verteilung von Webdatenverkehr mit Affinität zu einem Server basierend auf den von
Load Balancer generierten Cookies. Wenn eine Regel für aktive Cookie-Affinität aktiviert wurde, wird der Lastausgleich für neue Clientanforderungen mit Standrad-CBR-Algorithmen
durchgeführt. Aufeinanderfolgende Anforderungen eines Clients werden dabei an den zu Beginn ausgewählten
Server gesendet. Der ausgewählte Server
ist als Cookie in der Antwort an den Client gespeichert. Solange die zukünftigen
Anforderungen des Clients das Cookie enthalten und jede Anforderung innerhalb der
Haltezeit empfangen wird, bleibt der Client an den anfänglichen
Server gebunden.
Die Haltezeit wird in der Regel für CGIs oder
Servlets verwendet, die den Clientstatus auf dem Server speichern. Der Status
wird durch eine Cookie-ID identifiziert (dies sind Server-Cookies).
Der Clientstatus ist nur auf dem ausgewählten Server gespeichert. Der
Client benötigt also das Cookie von diesem Server, um diesen Status zwischen Anforderungen
zu wahren.
- Passive Cookie-Affinität
- Ermöglicht die Verteilung von Webdatenverkehr mit Affinität zu einem Server basierend auf den von den Servern generierten Identifizierungscookies.
Wird passive Cookie-Affinität aktiviert ist, wählt Load Balancer
den Server ausgehend von dem im HTTP-Header der Clientanforderung enthaltenen Cookienamen
aus.
Findet Load Balancer einen Server, in dessen Cookiewert der Cookiename des Clients
enthalten ist, wählt Load Balancer diesen Server für die Anforderung aus. Wenn in der Clientanforderung kein Cookiename gefunden
wird oder dieser in keinem der Server-Cookie-Werte enthalten ist, wird der Server mit Hilfe
der vorhandenen Serverauswahlmethoden oder der gewichteten RoundRobin-Methode
ausgewählt.
- URI
- Bei Verwendung der URI-Affinität kann die Arbeitslast des Webdatenverkehrs so auf Caching-Proxy-Server verteilt werden,
dass auf den einzelnen Servern unterschiedlicher Inhalt im Cache gespeichert werden kann.
Auf diese Weise vergrößern Sie effektiv die Cachekapazität Ihrer Site, da eine redundante Zwischenspeicherung von
Inhalten auf mehreren Maschinen vermieden wird. Dies ist nützlich in Szenarien,
in denen Ihre Website ein mittleres Clientdatenvolumen mit den verschiedensten Inhalten
unterstützt und Sie einen großen, auf mehrere Server verteilten Cache bevorzugen.
Der Standardwert für die Affinitätsoption ("affinity") ist none (keine).