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.

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.

Um den Wert für die Verzögerung bei der Abmeldung zu aktualisieren, verwenden Sie AWS CLI

Verwenden Sie den modify-target-group-attributesBefehl mit dem deregistration_delay.timeout_seconds Attribut.

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.

Um den Wert für die Dauer des langsamen Starts zu aktualisieren, verwenden Sie AWS CLI

Verwenden Sie den modify-target-group-attributesBefehl mit dem slow_start.duration_seconds Attribut.

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.

Wenn zonenübergreifendes Load Balancing deaktivieren

Sie können das zonenübergreifende Load Balancing für Ihre Application Load Balancer-Zielgruppen jederzeit deaktivieren.

Um den zonenübergreifenden Load Balancing zu deaktivieren, verwenden Sie AWS CLI

Verwenden Sie den modify-target-group-attributesBefehl und setzen Sie das load_balancing.cross_zone.enabled Attribut auffalse.

aws elbv2 modify-target-group-attributes --target-group-arn my-targetgroup-arn --attributes Key=load_balancing.cross_zone.enabled,Value=false

Nachfolgend finden Sie eine Beispielantwort:

{
    "Attributes": [
        {
            "Key": "load_balancing.cross_zone.enabled",
            "Value": "false"
        },
    ]
}

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.

Um den zonenübergreifenden Load Balancing zu aktivieren, verwenden Sie AWS CLI

Verwenden Sie den modify-target-group-attributesBefehl und setzen Sie das load_balancing.cross_zone.enabled Attribut auftrue.

aws elbv2 modify-target-group-attributes --target-group-arn my-targetgroup-arn --attributes Key=load_balancing.cross_zone.enabled,Value=true

Nachfolgend finden Sie eine Beispielantwort:

{
    "Attributes": [
        {
            "Key": "load_balancing.cross_zone.enabled",
            "Value": "true"
        },
    ]
}

Automatische Zielgewichte (ATW)

Automatische Zielgewichte (ATW) überwacht ständig die Ziele, auf denen Ihre Anwendungen ausgeführt werden, und erkennt signifikante Leistungsabweichungen, sogenannte Anomalien. ATWbietet 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, ATW kann automatisch versucht werden, sie zu stabilisieren, indem der Umfang des Datenverkehrs, über den sie weitergeleitet werden, reduziert wird. Dies wird auch als Minimierung von Anomalien bezeichnet. ATWoptimiert kontinuierlich die Verteilung des Datenverkehrs, um die Erfolgsquoten pro Ziel zu maximieren und gleichzeitig die Ausfallrate der Zielgruppe zu minimieren.

Anomalie-Erkennung

ATWBei der Erkennung von Anomalien wird nach allen Zielen gesucht, die eine signifikante Verhaltensabweichung 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 zuerst die Gesundheitschecks bestehen, um Traffic empfangen zu können. Sobald das Ziel das Ziel empfängt, ATW beginnt es 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

ATWDie Erkennung von Anomalien funktioniert unabhängig von den Gesundheitschecks der Zielgruppe. Ein Ziel kann alle Zielgruppen-Gesundheitschecks 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

ATWveröffentlicht kontinuierlich den Status der Anomalieerkennungen, die es an Zielen durchführt. Mit der Taste oder können Sie den aktuellen Status jederzeit einsehen. AWS Management Console AWS CLI

Um die Ergebnisse der Anomalieerkennung anzuzeigen, verwenden Sie AWS CLI

Verwenden Sie den describe-target-healthBefehl, bei dem der Include.member.N Attributwert auf AnomalyDetection gesetzt ist.

Minimierung von Anomalien

ATWDurch die Abschwächung von Anomalien wird der Datenverkehr automatisch von anomalen Zielen weggeleitet, sodass diese die Möglichkeit haben, sich zu erholen.

Schalten Sie die Minimierung von Anomalien ein ATW

Sie können die Minimierung von Anomalien jederzeit aktivieren.

Um die Minimierung von Anomalien zu aktivieren, verwenden Sie AWS CLI

Verwenden Sie den modify-target-group-attributesBefehl mit dem load_balancing.algorithm.anomaly_mitigation Attribut.

Status der Minimierung von Anomalien

Wann immer ATW eine Schadensbegrenzung für ein Ziel durchgeführt wird, können Sie den aktuellen Status jederzeit mithilfe von oder einsehen. AWS Management Console AWS CLI

Um den Status der Minimierung von Anomalien anzuzeigen, verwenden Sie den AWS CLI

Verwenden Sie den describe-target-healthBefehl, bei dem der Include.member.N Attributwert auf gesetzt ist. AnomalyDetection

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 von Load Balancern 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.

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 entschlüsselt 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 zum neuen Ziel.

Für ursprungsübergreifende Anfragen zur gemeinsamen Nutzung von Ressourcen (CORS) müssen einige Browser Stickiness aktivierenSameSite=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 solche, die keine Anfragen stellen. CORS

Um die dauerabhängige Klebrigkeit zu aktivieren, verwenden Sie AWS CLI

Verwenden Sie den modify-target-group-attributesBefehl mit den Attributen undstickiness.enabled. stickiness.lb_cookie.duration_seconds

Verwenden Sie den folgenden Befehl, um auf Dauer basierende Sticky Sessions zu aktivieren.

aws elbv2 modify-target-group-attributes --target-group-arn ARN --attributes Key=stickiness.enabled,Value=true Key=stickiness.lb_cookie.duration_seconds,Value=time-in-seconds

Die Ausgabe sollte in etwa wie folgt aussehen.

     {     
        "Attributes": [
           ...
            {
                 "Key": "stickiness.enabled",
                 "Value": "true"
              },           
              {
                  "Key": "stickiness.lb_cookie.duration_seconds",
                  "Value": "86500"
              
              },
           ...
          ]
      }           

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 ursprungsübergreifenden Resource Sharing (CORS) -Anfragen 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 User-Agent-Version Chromium80 oder höher ist.

Da für die meisten Browser in Bezug auf Cookies eine Größenbeschränkung von 4 KB gilt, unterteilt der Load Balancer Anwendungs-Cookie, die größer als 4 KB sind, in mehrere Cookies. 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.

Um anwendungsbasierte Stickiness zu aktivieren, verwenden Sie den AWS CLI

Verwenden Sie den modify-target-group-attributesBefehl mit den folgenden Attributen:

Verwenden Sie den folgenden Befehl, um anwendungsbasierte Sticky Sessions zu aktivieren.

aws elbv2 modify-target-group-attributes --target-group-arn ARN --attributes Key=stickiness.enabled,Value=true Key=stickiness.type,Value=app_cookie Key=stickiness.app_cookie.cookie_name,Value=my-cookie-name Key=stickiness.app_cookie.duration_seconds,Value=time-in-seconds

Die Ausgabe sollte in etwa wie folgt aussehen.

 
       {
            "Attributes": [
                ...
                {
                    "Key": "stickiness.enabled",
                    "Value": "true"
                },
                {
                    "Key": "stickiness.app_cookie.cookie_name",
                    "Value": "MyCookie"
                },
                {
                    "Key": "stickiness.type",
                    "Value": "app_cookie"
                },
                {
                    "Key": "stickiness.app_cookie.duration_seconds",
                    "Value": "86500"
                },
                ...
            ]
        }  
            
            

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: