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.
Zielgruppenattribute für Ihren Application Load Balancer bearbeiten
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.
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 die wenigsten ausstehenden Anfragen oder gewichtete zufällige Routing-Algorithmen verwenden.
Zonenübergreifendes Load Balancing für Application Load Balancer Balancer-Zielgruppen
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)
Automatic Target Weights (ATW) überwacht ständig die Ziele, auf denen Ihre Anwendungen ausgeführt werden, und erkennt signifikante Leistungsabweichungen, sogenannte Anomalien. ATW bietet die Möglichkeit, die Menge des an Ziele weitergeleiteten Datenverkehrs dynamisch anzupassen, indem Datenanomalien in Echtzeit erkannt werden.
Automatic Target Weights (ATW) führt automatisch eine Anomalieerkennung für jeden Application Load Balancer in Ihrem Konto durch. Wenn anomale Ziele identifiziert werden, kann ATW automatisch versuchen, sie zu stabilisieren, indem es den Umfang des Datenverkehrs, den sie weiterleiten, reduziert. Dies wird als Abwehr von Anomalien bezeichnet. ATW optimiert kontinuierlich die Verteilung des Datenverkehrs, um die Erfolgsquoten 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 diesen. 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, die als Anomalien bezeichnet werden, 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. Ziele, die deutlich höhere Werte als ihre Mitbewerber melden, werden dann als anomal eingestuft.
Für die Erkennung von Anomalien sind mindestens drei gesunde Zielpersonen in der Zielgruppe erforderlich. Wenn ein Ziel für eine Zielgruppe registriert ist, muss es die Zustandsprüfungen bestehen, bevor es Traffic empfängt. Sobald das Ziel Traffic empfängt, beginnt ATW mit der Überwachung des Ziels und veröffentlicht kontinuierlich das Ergebnis der Anomalie. Für Ziele ohne Anomalien lautet das Anomalieergebnis. normal Für Ziele mit Anomalien lautet das Anomalieergebnis. anomalous
Die ATW-Anomalieerkennung funktioniert unabhängig von den Gesundheitschecks der Zielgruppe. Ein Ziel kann alle Zustandsprüfungen für die Zielgruppe bestehen, aber aufgrund einer erhöhten Fehlerquote trotzdem als anomal eingestuft werden. Wenn Ziele anomal werden, hat das keinen Einfluss auf den Status ihrer Zielgruppen-Gesundheitschecks.
Status der Erkennung von Anomalien
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.
Minimierung von Anomalien
Die ATW-Abwehr leitet den Verkehr automatisch von anomalen Zielen weg und gibt ihnen so die Möglichkeit, sich zu erholen.
Anforderung
Die ATW-Funktion zur Minimierung von Anomalien ist nur verfügbar, wenn der Algorithmus Weighted Random Routing verwendet wird.
Während der Schadensbegrenzung:
-
ATW passt in regelmäßigen Abständen die Menge des Datenverkehrs an, der zu anomalen Zielen geleitet wird. Derzeit beträgt der Zeitraum alle fünf Sekunden.
-
ATW reduziert die Menge des Datenverkehrs, der zu anomalen Zielen geleitet wird, auf das Minimum, das zur Behebung von Anomalien erforderlich ist.
-
Bei Zielen, die nicht mehr als anomal erkannt werden, wird nach und nach mehr Traffic an sie weitergeleitet, bis sie die Parität mit anderen normalen Zielen in der Zielgruppe erreichen.
Status der Schadensbegrenzung
Sie können überprüfen, ob ATW Abhilfemaßnahmen 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 für Ihren Application Load Balancer
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
-
Ein 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. Der Versuch, Sticky Sessions zu aktivieren, während zonenübergreifendes Load Balancing deaktiviert ist, scheitert.
-
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
AWSALBCORSsowohl ein als auch einAWSALBdauerbasiertes Stickiness-Cookie empfängt, hat der Wert inAWSALBCORSVorrang. -
Anwendungsbasierte Sticky Sessions funktionieren 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 für anfordert WebSockets, ist das in der Verbindung verwendete Ziel das Ziel, das einen HTTP-101-Statuscode zurückgibt, um das WebSockets Verbindungs-Upgrade zu akzeptieren. Nach Abschluss des WebSockets Upgrades wird die auf Cookies basierende Stickiness nicht mehr 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 empfängt, während das Ziel aufgrund einer Abmeldung leer ist, wird die Anfrage an ein fehlerfreies Ziel weitergeleitet.
Typen von Klebrigkeit
Sticky Sessions auf Basis der Dauer
Bei auf Dauer basierenden Sticky Sessions werden Anforderungen mithilfe eines vom Load Balancer generierten Cookies (AWSALB) an dasselbe Ziel in einer Zielgruppe weitergeleitet. 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 abgemeldet 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) müssen einige Browser Stickiness aktivieren. SameSite=None; Secure Um diese Browser zu unterstützen, generiert der Load Balancer immer ein zweites Stickiness-CookieAWSALBCORS, das dieselben Informationen wie das ursprüngliche Stickiness-Cookie sowie das Attribut enthält. SameSite Kunden erhalten beide Cookies, auch Anfragen, die nicht von CORS stammen.
Anwendungsbasierte Sticky Sessions
Anwendungsbasierte Sticky Sessions geben Ihnen die Flexibilität, Ihre eigenen Kriterien für die Client-Ziel-Stickiness 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 4 KB beschränken, teilt der Load Balancer Anwendungscookies, die größer als 4 KB 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 Anwendungscookies, den der Client sieht, beginnt mit „AWSALBAPP-“ und enthält eine Fragmentnummer. Wenn die Größe des Cookies beispielsweise 0-4K ist, sieht der Client AWSALBAPP -0. Wenn die Größe des Cookies 4—8 KB 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, der den Prozess der Einrichtung von Stickiness erneut startet.
-
Legen Sie für die anwendungsbasierte Stickiness-Konfiguration des Load Balancers eine kurze Dauer fest, z. B. 1 Sekunde. Dadurch wird der Application Load Balancer gezwungen, die Stickiness wiederherzustellen, auch wenn das vom Ziel gesetzte Cookie nicht abgelaufen ist.
