Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Bearbeiten Sie die Zielgruppenattribute für Ihren Application Load Balancer
Nachdem Sie eine Zielgruppe für Ihren Application Load Balancer erstellt haben, können Sie deren Zielgruppenattribute bearbeiten.
Zielgruppenattribute
Verzögerung der Registrierungsaufhebung
Elastic Load Balancing stoppt das Senden von Anforderungen an Ziele, deren Registrierung aufgehoben wird. Standardmäßig wartet Elastic Load Balancing 300 Sekunden, bevor die Registrierungsaufhebung abgeschlossen wird. So können laufende Anforderungen an das Ziel abgeschlossen werden. Um die Zeitdauer zu ändern, die Elastic Load Balancing wartet, müssen Sie den Wert für die Verzögerung der Registrierungsaufhebung anpassen.
Der ursprüngliche Zustand eines Ziels, dessen Registrierung aufgehoben wird, lautet draining. Nach Ablauf der Verzögerung der Registrierungsaufhebung wird die Registrierungsaufhebung abgeschlossen und der Zustand es Ziels lautet unused. Wenn das Ziel Teil einer Auto-Scaling-Gruppe ist, kann es beendet und ersetzt werden.
Falls ein Ziel, dessen Registrierung aufgehoben wird, keine aktiven Anforderungen und keine aktiven Verbindungen aufweist, wird der Aufhebungsprozess von Elastic Load Balancing sofort abgeschlossen, ohne auf das Verstreichen der Verzögerung für die Registrierungsaufhebung zu warten. Auch wenn die Zielregistrierung aufgehoben wurde, wird bis zum Ablauf des Timeouts der Verzögerung der Registrierungsaufhebung draining als Status des Ziels angezeigt. Nach Ablauf des Timeouts wechselt das Ziel in einen unused-Zustand.
Wenn ein Ziel, dessen Registrierung aufgehoben wird, die Verbindung beendet, bevor die Verzögerung der Registrierungsaufhebung abgelaufen ist, erhält der Client eine 500-Level-Fehlerantwort.
Weiterleitungsalgorithmus
Ein Routing-Algorithmus ist eine Methode, die vom Load Balancer verwendet wird, um zu bestimmen, welche Ziele Anfragen erhalten. Der Rundkehlchen Der Routing-Algorithmus wird standardmäßig verwendet, um Anfragen auf Zielgruppenebene weiterzuleiten. Der am wenigsten ausstehende Anfragen und gewichtet nach dem Zufallsprinzip Je nach den Anforderungen Ihrer Anwendung sind auch Routing-Algorithmen verfügbar. Eine Zielgruppe kann jeweils nur einen aktiven Routing-Algorithmus haben, der Routing-Algorithmus kann jedoch bei Bedarf aktualisiert werden.
Wenn Sie Sticky Sessions aktivieren, wird der ausgewählte Routing-Algorithmus für die anfängliche Zielauswahl verwendet. Zukünftige Anfragen desselben Clients werden unter Umgehung des ausgewählten Routing-Algorithmus an dasselbe Ziel weitergeleitet. Wenn Sie den Zieloptimierer aktiviert haben, kann der Routing-Algorithmus nur Round-Robin-Algorithmen verwendet werden.
Hin- und Rückspiel
-
Der Round-Robin-Routing-Algorithmus leitet Anfragen gleichmäßig an gesunde Ziele in der Zielgruppe weiter, und zwar in sequentieller Reihenfolge.
-
Dieser Algorithmus wird häufig verwendet, wenn die eingegangenen Anfragen eine ähnliche Komplexität aufweisen, die registrierten Ziele eine ähnliche Verarbeitungsfähigkeit aufweisen oder wenn Sie Anfragen gleichmäßig auf die Ziele verteilen müssen.
Am wenigsten ausstehende Anfragen
-
Der Routing-Algorithmus für die wenigsten ausstehenden Anfragen leitet Anfragen an die Ziele mit der geringsten Anzahl laufender Anfragen weiter.
-
Dieser Algorithmus wird häufig verwendet, wenn die eingegangenen Anfragen unterschiedlich komplex sind und die registrierten Ziele sich in ihrer Verarbeitungsfähigkeit unterscheiden.
-
Wenn ein Load Balancer, der unterstützt HTTP/2 verwendet Ziele, die nur unterstützen HTTP/1.1, es konvertiert die Anfrage in mehrere HTTP/1.1 Anfragen. In dieser Konfiguration behandelt der Algorithmus für die am wenigsten ausstehenden Anfragen jede HTTP/2 Anfrage als mehrere Anfragen.
-
Bei der Verwendung WebSockets, das Ziel wird mit dem Algorithmus für die am wenigsten ausstehenden Anfragen ausgewählt. Nachdem das Ziel ausgewählt wurde, stellt der Load Balancer eine Verbindung zum Ziel her und sendet alle Nachrichten über diese Verbindung.
-
Der Routing-Algorithmus für Anfragen, der am wenigsten aussteht, kann nicht im langsamen Startmodus verwendet werden.
Nach dem Zufallsprinzip gewichtet
-
Der gewichtete Zufalls-Routing-Algorithmus leitet Anfragen gleichmäßig an gesunde Ziele in der Zielgruppe weiter, und zwar in zufälliger Reihenfolge.
-
Dieser Algorithmus unterstützt die Abschwächung von Anomalien mit automatischen Zielgewichten (ATW).
-
Der Algorithmus für gewichtetes zufälliges Routing kann nicht im langsamen Startmodus verwendet werden.
-
Der Algorithmus für gewichtetes zufälliges Routing kann nicht bei langwierigen Sitzungen verwendet werden.
Modus des langsamen Hochfahrens
Standardmäßig beginnt ein Ziel mit dem Empfang seines vollständigen Anteils an Anfragen, sobald es bei einer Zielgruppe registriert ist und die anfängliche Zustandsprüfung bestanden hat. Der Modus des langsamen Hochfahrens bietet Zielen mehr Zeit zum Warmlaufen, bevor der Load Balancer ihnen den vollständigen Anteil an Anfragen sendet.
Nachdem Sie das langsame Hochfahren für eine Zielgruppe aktiviert haben, wechseln die Ziele in den Modus des langsamen Hochfahrens, wenn sie von der Zielgruppe als fehlerfrei eingestuft werden. Ein Ziel im Modus des langsamen Hochfahrens beendet diesen, wenn die konfigurierte Dauer des langsamen Hochfahrens abgelaufen ist oder das Ziel fehlerhaft ist. Der Load Balancer erhöht linear die Anzahl von Anfragen, die er im Modus des langsamen Hochfahrens an ein Ziel senden kann. Nachdem ein fehlerfreies Ziel den Modus des langsamen Hochfahrens beendet hat, kann der Load Balancer diesem den vollständigen Anteil von Anfragen senden.
Überlegungen
-
Wenn Sie das langsame Hochfahren für eine Zielgruppe aktivieren, gehen die bei der Zielgruppe registrierten fehlerfreien Ziele nicht in den Modus des langsamen Hochfahrens über.
-
Wenn Sie das langsame Hochfahren für eine leere Zielgruppe aktivieren und dann mit einer einzigen Registrierungsoperation auf ein Ziel anwenden, dann gehen diese Ziele nicht in den Modus des langsamen Hochfahrens über. Neu registrierte Ziele gehen nur dann in den Modus des langsamen Hochfahrens über, wenn mindestens ein fehlerfreies Ziel vorhanden ist, das sich nicht im Modus des langsamen Hochfahrens befindet.
-
Wenn Sie die Registrierung eines Ziels im Modus des langsamen Hochfahrens aufheben, beendet das Ziel den Modus des langsamen Hochfahrens. Wenn Sie dasselbe Ziel erneut registrieren, wechselt es in den Modus des langsamen Hochfahrens, wenn es von der Zielgruppe als fehlerfrei eingestuft wird.
-
Wenn ein Ziel im Modus des langsamen Hochfahrens fehlerhaft ist, beendet das Ziel den Modus des langsamen Hochfahrens. Wenn das Ziel dann fehlerfrei ist, wechselt es wieder in den Modus des langsamen Hochfahrens.
-
Sie können den langsamen Startmodus nicht aktivieren, wenn Sie den verwenden am wenigsten ausstehende Anfragen oder gewichtet nach dem Zufallsprinzip Routing-Algorithmen.
Gesundheitseinstellungen
Standardmäßig überwachen Application Load Balancer den Zustand von Zielen und leiten Anfragen an fehlerfreie Ziele weiter. Wenn der Load Balancer jedoch nicht über genügend fehlerfreie Ziele verfügt, sendet er automatisch Datenverkehr an alle registrierten Ziele (Fail-Open). Sie können die Zielgruppen-Integritätseinstellungen für Ihre Zielgruppe ändern, um die Schwellenwerte für DNS-Failover und Routing-Failover zu definieren. Weitere Informationen finden Sie unter Zustand der Zielgruppe.
Cross-zone Lastenausgleich
Die Knoten für Ihren Load Balancer verteilen Anforderungen von Clients auf registrierte Ziele. Wenn zonenübergreifendes Load Balancing aktiviert ist, verteilt jeder Load Balancer-Knoten den Datenverkehr gleichmäßig auf die registrierten Ziele in allen registrierten Availability Zones. Wenn zonenübergreifendes Load Balancing deaktiviert ist, verteilt jeder Load Balancer-Knoten den Datenverkehr gleichmäßig nur auf die registrierten Ziele in seiner Availability Zone. Dies könnte verwendet werden, wenn zonale Ausfalldomänen regionalen vorzuziehen sind, um sicherzustellen, dass eine fehlerfreie Zone nicht von einer fehlerhaften Zone beeinträchtigt wird, oder um die allgemeine Latenz zu verbessern.
Bei Application Load Balancern ist der zonenübergreifende Load Balancing immer auf Load Balancer-Ebene aktiviert und kann nicht ausgeschaltet werden. Für Zielgruppen wird standardmäßig die Load-Balancer-Einstellung verwendet. Sie können die Standardeinstellung jedoch überschreiben, indem Sie den zonenübergreifenden Load Balancing auf Zielgruppenebene explizit ausschalten.
Überlegungen
-
Die Zielgruppenbindung wird nicht unterstützt, wenn zonenübergreifendes Load Balancing deaktiviert ist.
-
Lambda-Funktionen als Ziele werden nicht unterstützt, wenn zonenübergreifendes Load Balancing deaktiviert ist.
-
Beim Versuch, das zonenübergreifende Load Balancing über die
ModifyTargetGroupAttributes-API zu deaktivieren, wenn bei Zielen der ParameterAvailabilityZoneaufallgesetzt ist, tritt ein Fehler auf. -
Bei der Registrierung von Zielen ist der
AvailabilityZone-Parameter erforderlich. Spezifische Availability Zone-Werte sind nur zulässig, wenn zonenübergreifendes Load Balancing deaktiviert ist. Andernfalls wird der Parameter ignoriert und alsallbehandelt.
Bewährte Methoden
-
Planen Sie für jede Zielgruppe genügend Zielkapazität für alle Availability Zones ein, die Sie voraussichtlich nutzen werden. Wenn Sie nicht genügend Kapazität für alle teilnehmenden Availability Zones einplanen können, empfehlen wir Ihnen, das zonenübergreifende Load Balancing aktiviert zu lassen.
-
Wenn Sie Ihren Application Load Balancer mit mehreren Zielgruppen konfigurieren, stellen Sie sicher, dass alle Zielgruppen innerhalb der konfigurierten Region an denselben Availability Zones teilnehmen. Dadurch soll verhindert werden, dass eine Availability Zone leer ist, während das zonenübergreifende Load Balancing deaktiviert ist, da dies für alle HTTP-Anfragen, die in die leere Availability Zone gelangen, einen 503-Fehler auslöst.
-
Vermeiden Sie das Erstellen leerer Subnetze. Application Load Balancer stellen zonale IP-Adressen über DNS für die leeren Subnetze zur Verfügung, was 503-Fehler bei HTTP-Anfragen auslöst.
-
Es kann vorkommen, dass eine Zielgruppe mit deaktiviertem zonenübergreifendem Load Balancing über genügend geplante Zielkapazität pro Availability Zone verfügt, aber alle Ziele in einer Availability Zone fehlerhaft werden. Wenn es mindestens eine Zielgruppe mit ausschließlich fehlerhaften Zielen gibt, werden die IP-Adressen der Load Balancer-Knoten aus dem DNS entfernt. Sobald die Zielgruppe mindestens ein fehlerfreies Ziel hat, werden die IP-Adressen im DNS wiederhergestellt.
Wenn zonenübergreifendes Load Balancing deaktivieren
Sie können das zonenübergreifende Load Balancing für Ihre Application Load Balancer-Zielgruppen jederzeit deaktivieren.
Zonenübergreifendes Load Balancing aktivieren
Sie können das zonenübergreifende Load Balancing für Ihre Application Load Balancer-Zielgruppen jederzeit aktivieren. Die Einstellung für das zonenübergreifende Load Balancing auf Zielgruppenebene hat Vorrang vor der Einstellung auf Load-Balancer-Ebene.
Automatische Zielgewichte (ATW)
Automatische Zielgewichte (ATW) überwachen ständig die Ziele, auf denen Ihre Anwendungen ausgeführt werden, und erkennen signifikante Leistungsabweichungen, sogenannte Anomalien. ATW bietet die Möglichkeit, die Menge des zu Zielen geleiteten Datenverkehrs durch Erkennung von Datenanomalien in Echtzeit dynamisch anzupassen.
Automatic Target Weights (ATW) erkennt automatisch Anomalien für jeden Application Load Balancer in Ihrem Konto. Wenn anomale Ziele identifiziert werden, kann ATW automatisch versuchen, sie zu stabilisieren, indem es die Menge des Traffics, an die sie weitergeleitet werden, reduziert, was als Anomalieabwehr bezeichnet wird. ATW optimiert kontinuierlich die Verkehrsverteilung, um die Erfolgsraten pro Ziel zu maximieren und gleichzeitig die Ausfallraten der Zielgruppen zu minimieren.
Überlegungen:
-
Die Anomalieerkennung überwacht derzeit HTTP 5xx-Antwortcodes, die von Ihren Zielen kommen, und Verbindungsfehler zu Ihren Zielen. Die Anomalieerkennung ist immer aktiviert und kann nicht ausgeschaltet werden.
-
ATW wird nicht unterstützt, wenn Lambda als Ziel verwendet wird.
Anomalie-Erkennung
Die ATW-Anomalieerkennung überwacht alle Ziele, die eine signifikante Abweichung im Verhalten von anderen Zielen in ihrer Zielgruppe aufweisen. Diese Abweichungen, sogenannte Anomalien, werden ermittelt, indem die prozentualen Fehler eines Ziels mit den prozentualen Fehlern anderer Ziele in der Zielgruppe verglichen werden. Bei diesen Fehlern kann es sich sowohl um Verbindungsfehler als auch um HTTP-Fehlercodes handeln. Zielpersonen, die deutlich höhere Werte als ihre Mitbewerber melden, werden dann als anomal eingestuft.
Für die Erkennung von Anomalien sind mindestens drei gesunde Ziele in der Zielgruppe erforderlich. Wenn ein Ziel bei einer Zielgruppe registriert wird, muss es die Gesundheitschecks bestehen, bevor es Traffic empfängt. Sobald das Ziel anfängt, Traffic zu empfangen, beginnt ATW mit der Überwachung des Ziels und veröffentlicht kontinuierlich das Ergebnis der Anomalie. Bei Zielen ohne Anomalien lautet das Ergebnis der Anomalie normal. Bei Zielen mit Anomalien lautet das Ergebnis der Anomalie anomalous.
Die Erkennung von ATW-Anomalien funktioniert unabhängig von den Gesundheitschecks der Zielgruppe. Ein Ziel kann zwar alle Gesundheitschecks der Zielgruppe bestehen, aber aufgrund einer erhöhten Fehlerquote trotzdem als anomal eingestuft werden. Werden Ziele anomal, wirkt sich das nicht auf den Status der Zielgruppen-Gesundheitschecks aus.
Status der Erkennung einer Anomalie
Sie können den aktuellen Status der Anomalieerkennung einsehen. Die folgenden Werte sind möglich:
-
normal— Es wurden keine Anomalien festgestellt. -
anomalous— Es wurden Anomalien festgestellt.
Minderung von Anomalien
Die Abwehr von ATW-Anomalien leitet den Verkehr automatisch von anomalen Zielen weg und gibt ihnen die Möglichkeit, sich zu erholen.
Anforderung
Die Funktion zur Abschwächung von Anomalien von ATW ist nur verfügbar, wenn Sie die Nach dem Zufallsprinzip gewichtet Routing-Algorithmus.
Während der Schadensbegrenzung:
-
ATW passt die Menge des Verkehrs, der an anomale Ziele weitergeleitet wird, regelmäßig an. Derzeit erfolgt der Zeitraum alle fünf Sekunden.
-
ATW reduziert die Menge des Datenverkehrs, der zu anomalen Zielen geleitet wird, auf das Mindestvolumen, das zur Abwehr von Anomalien erforderlich ist.
-
Bei Zielen, die nicht mehr als anomal erkannt werden, wird nach und nach mehr Verkehr zu ihnen geleitet, bis sie die Parität mit anderen normalen Zielen in der Zielgruppe erreicht haben.
Status der Schadensbegrenzung
Sie können überprüfen, ob ATW eine Schadensbegrenzung für ein Ziel durchführt. Die folgenden Werte sind möglich:
yes— Die Schadensbegrenzung ist im Gange.no— Die Schadensbegrenzung ist nicht im Gange.
Sticky Sessions
Standardmäßig leitet ein Application Load Balancer jede Anforderung getrennt an ein registriertes Ziel weiter, basierend auf dem ausgewählten Load-Balancing-Algorithmus. Sie können jedoch das Feature „Sticky Session“ (auch als gebundene Sitzungen bezeichnet) verwenden, damit der Load Balancer die Sitzung eines Benutzers an ein bestimmtes Ziel binden kann. So wird sichergestellt, dass alle Anforderungen, die während der Sitzung vom Benutzer gesendet werden, an dasselbe Ziel weitergeleitet werden. Dieses Feature ist nützlich für Server, die Zustandsinformationen verwalten, um Clients eine kontinuierliche Erfahrung zu bieten. Um Sticky Sessions zu verwenden, muss der Client Cookies unterstützen.
Application Load Balancer unterstützen sowohl dauerbasierte Cookies als auch anwendungsbasierte Cookies. Sticky Sessions werden auf Ebene der Zielgruppe aktiviert. Sie können für Ihre Zielgruppen eine Kombination aus auf Dauer basierenden Sticky Sessions, anwendungsbasierten Sticky Sessions und keine Sticky Sessions verwenden.
Bei der Verwaltung von Sticky Sessions ist es besonders wichtig festzulegen, wie lange der Load Balancer die Anforderung des Benutzers an das gleiche Ziel leiten soll. Wenn Ihre Anwendung über ein eigenes Sitzungscookie verfügt, können Sie anwendungsbasierte Sticky Session verwenden. Das Sitzungscookie der Load-Balancer-Sitzung hält dann die durch das Sitzungscookie der Anwendung festgelegte Dauer ein. Wenn Ihre Anwendung kein eigenes Sitzungscookie hat, können Sie auf Dauer basierende Sticky Sessions verwenden, um ein Load-Balancer-Sitzungscookie mit einer von Ihnen angegebenen Dauer zu generieren.
Der Inhalt der von Load Balancern generierten Cookies wird mit einem rotierenden Schlüssel verschlüsselt. Sie können vom Load Balancer generierte Cookies nicht entschlüsseln oder ändern.
Bei beiden Stickiness-Typen setzt der Application Load Balancer den Ablauf der von ihm generierten Cookies nach jeder Anforderung zurück. Wenn ein Cookie abläuft, ist die Sitzung keine Sticky Session mehr und der Client sollte das Cookie aus seinem Cookiespeicher entfernen.
Voraussetzungen
-
Und HTTP/HTTPS Load Balancer.
-
Mindestens eine funktionierende Instance in jeder Availability Zone.
Überlegungen
-
Sticky Sessions werden nicht unterstützt, wenn zonenübergreifendes Load Balancing deaktiviert ist. Versuche, Sticky Sessions zu aktivieren, während der zonenübergreifende Load Balancing deaktiviert ist, schlagen fehl.
-
Bei anwendungsbasierten Cookies müssen die Namen der Cookies für jede Zielgruppe einzeln angegeben werden. Bei dauerbasierten Cookies ist
AWSALBjedoch der einzige Name, der für alle Zielgruppen verwendet wird. -
Wenn Sie mehrere Ebenen von Application Load Balancern nutzen, können Sie mit anwendungsbasierten Cookies Sticky Sessions auf allen Ebenen aktivieren. Mit dauerbasierten Cookies können Sie Sticky Sessions jedoch nur auf einer Ebene aktivieren, weil
AWSALBder einzige verfügbare Name ist. -
Wenn der Application Load Balancer beide empfängt
AWSALBCORSund einAWSALBauf Dauer basierendes Stickiness-Cookie, der Wert inAWSALBCORSwird Vorrang haben. -
Application-based Stickiness funktioniert nicht bei gewichteten Zielgruppen.
-
Wenn Sie über eine Weiterleitungsregel mit mehreren Zielgruppen verfügen und für mindestens eine Sticky Sessions aktiviert sind, müssen Sie die Stickiness der Zielgruppe aktivieren.
-
WebSocket Verbindungen sind von Natur aus klebrig. Wenn der Client ein Verbindungs-Upgrade anfordert zu WebSockets, das Ziel, das einen HTTP 101-Statuscode zurückgibt, um das Verbindungs-Upgrade zu akzeptieren, ist das Ziel, das in WebSockets Verbindung. Nach dem WebSockets Das Upgrade ist abgeschlossen, die auf Cookies basierende Stickiness wird nicht verwendet.
-
Application Load Balancer verwenden das
Expires-Attribut im Cookie-Header anstelle desMax-Age-Attributs. -
Application Load Balancer unterstützen keine Cookie-Werte, die URL-codiert sind.
-
Wenn der Application Load Balancer eine neue Anfrage erhält, während das Ziel aufgrund einer Deregistrierung überlastet ist, wird die Anfrage an ein fehlerfreies Ziel weitergeleitet.
-
Dauerhafte Sitzungen werden nicht unterstützt, wenn der Target Optimizer aktiviert ist.
Typen von Stickiness
Duration-based Klebrigkeit
Duration-based Stickiness leitet Anfragen mithilfe eines vom Load Balancer generierten Cookies an dasselbe Ziel in einer Zielgruppe weiter (AWSALB). Das Cookie wird verwendet, um die Sitzung dem Ziel zuzuordnen. Wenn Ihre Anwendung kein eigenes Sitzungscookie hat, können Sie Ihre eigene Dauer der Sticky Sessions angeben und festlegen, wie lange Ihr Load Balancer die Anforderung des Benutzers konsistent an dasselbe Ziel weiterleiten soll.
Wenn ein Load Balancer eine Anforderung von einem Client erhält, leitet er die Anforderung (basierend auf der Grundlage des ausgewählten Algorithmus) an ein Ziel weiter und generiert ein Cookie namens AWSALB. Er codiert Informationen über das ausgewählte Ziel, verschlüsselt das Cookie und schließt das Cookie in die Antwort an den Client ein. Das vom Load Balancer generierte Cookie hat eine eigene Dauer der Gültigkeit von 7 Tagen. Dieses Ablaufdatum ist nicht konfigurierbar.
Bei nachfolgenden Anforderungen sollte der Client das AWSALB-Cookie enthalten. Wenn der Load Balancer eine Anforderung von einem Client erhält, die das Cookie enthält, erkennt er es und leitet die Anforderung an dasselbe Ziel weiter. Wenn das Cookie vorhanden ist, aber nicht dekodiert werden kann oder wenn es sich auf ein Ziel bezieht, das deregistriert wurde oder fehlerhaft ist, wählt der Load Balancer ein neues Ziel aus und aktualisiert das Cookie mit Informationen über das neue Ziel.
Für CORS-Anfragen (Cross-Origin Resource Sharing) benötigen einige Browser SameSite=None; Secure um Klebrigkeit zu ermöglichen. Um diese Browser zu unterstützen, generiert der Load Balancer immer ein zweites Stickiness-Cookie, AWSALBCORS, das dieselben Informationen wie das ursprüngliche Stickiness-Cookie enthält, sowie das SameSite Attribut. Clients erhalten beide Cookies, auch Nicht-CORS-Anfragen.
Application-based Klebrigkeit
Application-based Klebrigkeit gibt Ihnen die Flexibilität, Ihre eigenen Kriterien für die Kundenbindung festzulegen. Wenn Sie die anwendungsbasierte Stickiness aktivieren, leitet der Load Balancer die erste Anforderung auf der Grundlage des ausgewählten Algorithmus an ein Ziel innerhalb der Zielgruppe weiter. Es wird erwartet, dass das Ziel ein benutzerdefiniertes Anwendungscookie setzt, das dem im Load Balancer konfigurierten Cookie entspricht, um Stickiness zu aktivieren. Dieses benutzerdefinierte Cookie kann jedes Cookie-Attribut enthalten, das von der Anwendung benötigt wird.
Wenn der Application Load Balancer das benutzerdefinierte Anwendungscookie vom Ziel empfängt, generiert er automatisch ein neues verschlüsseltes Anwendungscookie zum Erfassen von Stickiness-Informationen. Dieses vom Load Balancer generierte Anwendungscookie erfasst Stickiness-Informationen für jede Zielgruppe, für die anwendungsbasierte Sticky Sessions aktiviert sind.
Das vom Load Balancer generierte Anwendungscookie kopiert nicht die Attribute des vom Ziel gesetzten benutzerdefinierten Cookies. Es hat eine eigene Dauer der Gültigkeit von 7 Tagen. Dieses Ablaufdatum ist nicht konfigurierbar. In der Antwort an den Client validiert der Application Load Balancer nur den Namen, mit dem das benutzerdefinierte Cookie auf Zielgruppenebene konfiguriert wurde, und nicht den Wert oder das Ablaufattribut des benutzerdefinierten Cookies. Solange der Name übereinstimmt, sendet der Load Balancer in der Antwort beide Cookies an den Client: das vom Ziel gesetzte benutzerdefinierte Cookie und das vom Load Balancer generierte Anwendungscookie.
Bei nachfolgenden Anforderungen müssen die Clients beide Cookies zurücksenden, um die Stickiness aufrechtzuerhalten. Der Load Balancer entschlüsselt das Anwendungscookie und prüft, ob die konfigurierte Dauer der Stickiness noch gültig ist. Anschließend werden die im Cookie enthaltenen Informationen verwendet, um die Anforderung an dasselbe Ziel innerhalb der Zielgruppe zu senden, um die Stickiness aufrechtzuerhalten. Der Load Balancer leitet das benutzerdefinierte Anwendungscookie auch über einen Proxy an das Ziel weiter, ohne es zu überprüfen oder zu ändern. In nachfolgenden Antworten werden der Ablauf des vom Load Balancer generierten Anwendungs-Cookies und die im Load Balancer konfigurierte Dauer der Stickiness zurückgesetzt. Um die Stickiness zwischen Client und Target aufrechtzuerhalten, sollten das Cookie und die Dauer der Stickiness nicht ablaufen.
Wenn ein Ziel ausfällt oder fehlerhaft ist, leitet der Load Balancer keine Anforderungen mehr an dieses Ziel weiter und wählt basierend auf dem ausgewählten Load Balancing-Algorithmus ein neues fehlerfreies Ziel aus. Der Load Balancer behandelt die Sitzung jetzt als dem neuen fehlerfreien Ziel „angeheftet“ und leitet Anforderungen auch dann an dieses neue fehlerfreie Ziel, wenn das fehlerhafte Ziel wieder funktionsfähig ist.
Bei CORS-Anforderungen (Cross-Origin Resource Sharing) fügt der Load Balancer die SameSite=None; Secure-Attribute nur dann dem vom Load Balancer generierten Anwendungs-Cookie hinzu, um Stickiness zu aktivieren, wenn die Benutzeragent-Version Chromium80 oder höher ist.
Da die meisten Browser die Größe von Cookies auf 4K beschränken, teilt der Load Balancer Anwendungscookies, die größer als 4K sind, in mehrere Cookies auf. Application Load Balancer unterstützen Cookies mit einer Größe von bis zu 16 KB und können daher bis zu 4 Shards erstellen, die an den Client gesendet werden. Der Name des Anwendungs-Cookies, den der Client sieht, beginnt mit „AWSALBAPP-“ und enthält eine Fragmentnummer. Wenn die Cookie-Größe beispielsweise 0—4 K beträgt, sieht der Client AWSALBAPP-0. Wenn die Cookie-Größe 4-8k beträgt, sieht der Client AWSALBAPP-0 und AWSALBAPP-1, und so weiter.
Manuelle Neuverteilung
Wenn beim Hochskalieren die Anzahl der Ziele erheblich zunimmt, besteht die Gefahr einer ungleichmäßigen Lastverteilung aufgrund von Stickiness. In diesem Szenario können Sie die Last mithilfe der folgenden zwei Optionen neu auf Ihre Ziele verteilen:
-
Legen Sie für das von der Anwendung generierte Cookie ein Ablaufdatum fest, das vor dem aktuellen Datum und der aktuellen Uhrzeit liegt. Dadurch wird verhindert, dass Clients das Cookie an den Application Load Balancer senden, wodurch der Prozess zur Feststellung der Stickiness erneut gestartet wird.
-
Legen Sie eine kurze Dauer für die anwendungsbasierte Stickiness-Konfiguration des Load Balancers fest, z. B. 1 Sekunde. Dadurch wird der Application Load Balancer gezwungen, die Stickiness wiederherzustellen, auch wenn das vom Ziel gesetzte Cookie noch nicht abgelaufen ist.
WAR HTTP/2 Verhalten bei der Verkehrsinspektion
Standardmäßig, wenn Sie Application Load Balancer mit integrieren AWS WAF, AWS WAF inspiziert HTTP/2 Anfragen sofort unter Verwendung der verfügbaren Anforderungsdaten. Dieser Inspektionsmodus unterstützt bidirektionale Streaming-Anwendungen, bei denen der Server antworten muss, bevor der Client das Senden der Anforderungsdaten abgeschlossen hat, wodurch Timeouts in Kommunikationsszenarien in Echtzeit vermieden werden.
Sie können den Application Load Balancer so konfigurieren, dass er akkumuliert HTTP/2 Datenrahmen vorher AWS WAF führt eine Inspektion durch. Diese Konfiguration hilft dabei, Sicherheitslücken zu verhindern, bei denen Angreifer bösartige Nutzlasten auf mehrere verteilen HTTP/2 Datenrahmen. Verwenden Sie diese Option für Standardanwendungen mit Anfragen und Antworten, bei denen Clients vollständige Anforderungsdaten übertragen, bevor sie Antworten erwarten, um Folgendes sicherzustellen AWS WAF prüft die gesamte Nutzlast der Anfrage.
HTTP/2 RST_STREAM-Fehlerweiterleitung
Standardmäßig, wenn ein HTTP/2 oder das gRPC-Ziel beendet einen Stream, indem es einen sendet RST_STREAM Bei einem Frame mit einem Fehler gibt der Load Balancer eine HTTP 502-Antwort (Bad Gateway) an den Client zurück. Dadurch wird der spezifische Fehler ausgeblendet, den das Ziel gemeldet hat.
Wenn Sie die RST_STREAM-Fehlerweiterleitung aktivieren, leitet der Load Balancer stattdessen die des Ziels weiter RST_STREAM Fehlercode für die folgenden Fehlercodes an den Downstream-Client: REFUSED_STREAM, CANCEL, ENHANCE_YOUR_CALM, und INTERNAL_ERROR. Dadurch können gRPC und HTTP/2 Clients beobachten genau den Fehler, den das Ziel zurückgegeben hat, und reagieren darauf. Dieses Attribut gilt nur für Zielgruppen, die das verwenden HTTP2 oder GRPC Protokollversion, und sie ist standardmäßig deaktiviert.
