Zielgruppen für Ihre Application Load Balancer - Elastic Load Balancing
WeiterleitungskonfigurationZieltypIP-AdresstypProtokollversionRegistrierte ZieleZielgruppenattributeRouting-AlgorithmenAutomatische Zielgewichte (ATW)Verzögerung der RegistrierungsaufhebungModus des langsamen Hochfahrens

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.

Zielgruppen für Ihre Application Load Balancer

Zielgruppen leiten Anforderungen an einzelne registrierte Ziele, z. B. EC2-Instances, über das Protokoll und die Port-Nummer, die Sie angeben, weiter. Sie können ein Ziel bei mehreren Zielgruppen registrieren. Sie können Zustandsprüfungen pro Zielgruppe konfigurieren. Zustandsprüfungen werden auf allen Zielen ausgeführt, die bei einer Zielgruppe registriert sind, welche in einer Listener-Regel für Ihren Load Balancer abgegeben ist.

Jede Zielgruppe wird verwendet, um Anfragen an ein oder mehrere registrierte Ziele weiterzuleiten. Beim Erstellen der jeweiligen Listener-Regeln geben Sie eine Zielgruppe und Bedingungen an. Wenn die Bedingung einer Regel erfüllt ist, wird der Datenverkehr an die entsprechende Zielgruppe weitergeleitet. Sie können unterschiedliche Zielgruppen für verschiedene Arten von Anfragen erstellen. Erstellen Sie beispielsweise eine Zielgruppe für allgemeine Anfragen und andere Zielgruppen für Anfragen an die Microservices für Ihre Anwendung. Sie können für jede Zielgruppe nur einen Load Balancer verwenden. Weitere Informationen finden Sie unter Application-Load-Balancer-Komponenten.

Sie definieren Zustandsprüfungseinstellungen für Ihren Load Balancer pro Zielgruppe. Jede Zielgruppe verwendet die standardmäßigen Zustandsprüfungseinstellungen, es sei denn, Sie überschreiben diese, wenn Sie die Zielgruppe erstellen, oder ändern sie später. Nachdem Sie eine Zielgruppe in einer Regel für einen Listener angegeben haben, überwacht der Load Balancer kontinuierlich den Zustand aller mit der Zielgruppe registrierten Ziele, die in einer Availability Zone vorhanden sind, die für den Load Balancer aktiviert ist. Der Load Balancer leitet Anfragen an die registrierten Ziele weiter, die fehlerfrei sind.

Inhalt

Weiterleitungskonfiguration

Ein Load Balancer leitet standardmäßig mithilfe des Protokolls und der Portnummer, die Sie beim Erstellen der Zielgruppe angegeben haben, Anfragen an die Ziele weiter. Alternativ können Sie den für Weiterleitung von Datenverkehr zu einem Ziel verwendeten Port überschreiben, wenn Sie es bei der Zielgruppe registrieren.

Zielgruppen unterstützen die folgenden Protokolle und Ports:

  • Protocols (Protokolle): HTTP, HTTPS

  • Ports: 1-65535

Wenn eine Zielgruppe mit dem HTTPS-Protokoll konfiguriert ist oder HTTPS-Zustandsprüfungen verwendet, verwenden TLS-Verbindungen zu den Zielen die Sicherheitseinstellungen aus der ELBSecurityPolicy-2016-08-Richtlinie. Der Load Balancer stellt TLS-Verbindungen mit den Zielen her, wobei er die auf den Zielen installierten Zertifikate verwendet. Der Load Balancer überprüft diese Zertifikate nicht. Daher können Sie selbstsignierte Zertifikate oder Zertifikate verwenden, die abgelaufen sind. Da sich der Load Balancer und seine Ziele in einer Virtual Private Cloud (VPC) befinden, wird der Verkehr zwischen dem Load Balancer und den Zielen auf Paketebene authentifiziert, sodass kein Risiko von man-in-the-middle Angriffen oder Spoofing besteht, selbst wenn die Zertifikate auf den Zielen nicht gültig sind. Für den ausgehenden Datenverkehr AWS gilt nicht der gleiche Schutz, und es sind möglicherweise zusätzliche Schritte erforderlich, um den Datenverkehr weiter zu sichern.

Zieltyp

Wenn Sie eine Zielgruppe erstellen, legen Sie ihren Zieltyp fest, wodurch festgelegt wird, welchen Zieltyp Sie beim Registrieren von Zielen bei dieser Zielgruppe angeben. Nachdem Sie eine Zielgruppe erstellt haben, können Sie ihren Zieltyp nicht mehr ändern.

Die folgenden Zieltypen sind möglich:

instance

Die Ziele werden nach Instance-ID angegeben.

ip

Die Ziele sind IP-Adressen.

lambda

Das Ziel ist eine Lambda-Funktion.

Wenn der Zieltyp ip ist, können Sie IP-Adressen von einem der folgenden CIDR-Blöcke angeben:

  • Die Subnetze der VPC für die Zielgruppe

  • 10.0.0.0/8 (RFC 1918)

  • 100.64.0.0/10 (RFC 6598)

  • 172.16.0.0/12 (RFC 1918)

  • 192.168.0.0/16 (RFC 1918)

Wichtig

Sie können keine öffentlich weiterleitungsfähigen IP-Adressen angeben.

Mit allen unterstützten CIDR-Blöcken können Sie die folgenden Ziele bei einer Zielgruppe registrieren:

  • Instances in einer VPC, die durch Peering mit der Load-Balancer-VPC verbunden sind (dieselbe Region oder eine andere Region).

  • AWS Ressourcen, die über IP-Adresse und Port adressierbar sind (z. B. Datenbanken).

  • Lokale Ressourcen, die AWS über eine AWS Direct Connect oder eine Site-to-Site-VPN-Verbindung verknüpft sind.

Anmerkung

Bei Application Load Balancern, die in einer lokalen Zone bereitgestellt werden, müssen sich die ip-Ziele in derselben lokalen Zone befinden, um Datenverkehr empfangen zu können.

Weitere Informationen finden Sie unter Was sind AWS Local Zones?

Wenn Sie Ziele unter Verwendung einer Instance-ID angeben, wird Datenverkehr an Instances unter Verwendung der primären privaten IP-Adresse weitergeleitet, die in der primären Netzwerkschnittstelle für die Instance angegeben ist. Wenn Sie Ziele unter Verwendung von IP-Adressen angeben, können Sie den Datenverkehr über eine beliebige private IP-Adresse aus einer oder mehreren Netzwerkschnittstellen an eine Instance weiterleiten. Auf diese Weise können mehrere Anwendungen auf eine Instance denselben Port verwenden. Jede Netzwerkschnittstelle kann über eine eigene Sicherheitsgruppe verfügen.

Wenn der Zieltyp der Zielgruppe lambda lautet, können Sie eine einzelne Lambda-Funktion registrieren. Wenn der Load Balancer eine Anfrage für eine Lambda-Funktion empfängt, ruft er die Lambda-Funktion auf. Weitere Informationen finden Sie unter Lambda-Funktionen als Ziele.

Sie können Amazon Elastic Container Service (Amazon ECS) als Ziel für Ihren Application Load Balancer konfigurieren. Weitere Informationen finden Sie unter Creating an Application Load Balancer im Amazon Elastic Container Service-Benutzerhandbuch für AWS Fargate.

IP-Adresstyp

Wenn Sie eine neue Zielgruppe erstellen, können Sie den IP-Adresstyp Ihrer Zielgruppe auswählen. Dadurch wird die IP-Version gesteuert, die für die Kommunikation mit Zielen und die Überprüfung ihres Status verwendet wird.

Application Load Balancer unterstützen sowohl IPv4- als auch IPv6-Zielgruppen. Die Standardauswahl ist IPv4.

Überlegungen

  • Alle IP-Adressen innerhalb einer Zielgruppe müssen denselben IP-Adresstyp haben. Sie können beispielsweise kein IPv4-Ziel bei einer IPv6-Zielgruppe registrieren.

  • IPv6-Zielgruppen können nur mit dualstack-Load-Balancern verwendet werden.

  • IPv6-Zielgruppen unterstützen Ziele vom Typ „IP“ und „Instance“.

Protokollversion

Standardmäßig senden Application Load Balancer Anforderungen über HTTP/1.1 an Ziele. Sie können die Protokollversion verwenden, um Anforderungen mit HTTP/2 oder gRPC an Ziele zu senden.

In der folgenden Tabelle sind die Ergebnisse für die Kombinationen aus Anforderungsprotokoll und Zielgruppen-Protokollversion zusammengefasst.

Anforderungsprotokoll Protokollversion Ergebnis
HTTP/1.1 HTTP/1.1 Herzlichen Glückwunsch
HTTP/2 HTTP/1.1 Herzlichen Glückwunsch
gRPC HTTP/1.1 Fehler
HTTP/1.1 HTTP/2 Fehler
HTTP/2 HTTP/2 Herzlichen Glückwunsch
gRPC HTTP/2 Erfolg, wenn Ziele gRPC unterstützen
HTTP/1.1 gRPC Fehler
HTTP/2 gRPC Erfolg bei einer POST-Anforderung
gRPC gRPC Herzlichen Glückwunsch
Überlegungen zur gRPC-Protokollversion

  • Das einzige unterstützte Listener-Protokoll ist HTTPS.

  • Der einzige unterstützte Aktionstyp für Listener-Regeln ist forward.

  • Die einzigen unterstützten Zieltypen sind instance und ip.

  • Der Load Balancer analysiert gRPC-Anfragen und leitet gRPC-Aufrufe basierend auf dem Paket, dem Dienst und der Methode an die entsprechenden Zielgruppen weiter.

  • Der Load Balancer unterstützt unäres, clientseitiges Streaming, serverseitiges Streaming und bidirektionales Streaming.

  • Sie müssen eine benutzerdefinierte Zustandsprüfungsmethode mit dem Format /package.service/method bereitstellen.

  • Sie müssen die gRPC-Statuscodes angeben, die verwendet werden, um ein Ziel auf eine erfolgreiche Antwort zu überprüfen.

  • Sie können keine Lambda-Funktionen als Ziel verwenden.

Überlegungen zur HTTP/2-Protokollversion

  • Das einzige unterstützte Listener-Protokoll ist HTTPS.

  • Der einzige unterstützte Aktionstyp für Listener-Regeln ist forward.

  • Die einzigen unterstützten Zieltypen sind instance und ip.

  • Der Load Balancer unterstützt Streaming von Clients. Der Load Balancer unterstützt kein Streaming zu den Zielen.

Registrierte Ziele

Ihr Load Balancer dient als zentraler Kontaktpunkt für Clients und verteilt eingehenden Datenverkehr an die fehlerfreien registrierten Ziele. Sie können jedes Ziel bei einer oder mehreren Zielgruppen registrieren.

Wenn die Nachfrage nach Ihrer Anwendung steigt, können Sie zusätzliche Ziele bei einer oder mehreren Zielgruppen registrieren, um die Nachfrage zu bewältigen. Der Load Balancer leitet den Traffic an ein neu registriertes Ziel weiter, sobald der Registrierungsprozess abgeschlossen ist und das Ziel die erste Zustandsprüfung bestanden hat, unabhängig vom konfigurierten Schwellenwert.

Wenn die Nachfrage nach Ihrer Anwendung sinkt oder Sie Ihre Ziele warten müssen, können Sie die Registrierung von Zielen bei Ihren Zielgruppen aufheben. Bei der Aufhebung der Registrierung eines Ziels wird es aus Ihrer Zielgruppe entfernt. Ansonsten hat dies keine Auswirkungen auf das Ziel. Der Load Balancer stoppt das Weiterleiten von Anfragen an ein Ziel, sobald die Registrierung des Ziels aufgehoben wird. Das Ziel wechselt in den Zustand draining, bis laufende Anfragen abgeschlossen wurden. Sie können das Ziel erneut bei der Zielgruppe registrieren, wenn es bereit ist, wieder Anfragen zu erhalten.

Wenn Sie Ziele nach Instance-ID registrieren, können Sie Ihren Load Balancer mit einer Auto-Scaling-Gruppe verwenden. Nachdem Sie eine Zielgruppe einer Auto-Scaling-Gruppe angefügt haben, registriert Auto Scaling Ihre Ziele bei der Zielgruppe für Sie, wenn es sie startet. Weitere Informationen finden Sie unter Anhängen eines Load Balancers an Ihre Auto-Scaling-Gruppe im Benutzerhandbuch zu Amazon EC2 Auto Scaling.

Einschränkungen

  • Es ist nicht möglich, IP-Adressen eines anderen Application Load Balancers in derselben VPC zu registrieren. Wenn der andere Application Load Balancer sich in einer VPC befindet, die durch Peering mit dem Load Balancer verbunden ist, können Sie die IP-Adressen registrieren.

  • Sie können Instances nicht nach Instance-ID registrieren, wenn sie sich in einer VPC befinden, die mit der Load-Balancer-VPC gekoppelt ist (dieselbe Region oder eine andere Region). Sie können diese Instances nach IP-Adresse registrieren.

Zielgruppenattribute

Die folgenden Zielgruppenattribute werden unterstützt, wenn die Zielgruppe vom Typ instance oder ip ist:

deregistration_delay.timeout_seconds

Die Zeit, die Elastic Load Balancing wartet, bevor die Registrierung eines Ziels aufgehoben wird. Der Bereich liegt zwischen 0 und 3 600 Sekunden. Der Standardwert beträgt 300 Sekunden.

load_balancing.algorithm.type

Der Lastausgleichsalgorithmus bestimmt, wie der Load Balancer Ziele beim Routing von Anforderungen auswählt. Der Wert ist round_robinleast_outstanding_requests, oderweighted_random. Der Standardwert ist round_robin.

load_balancing.algorithm.anomaly_mitigation

Nur verfügbar, wenn load_balancing.algorithm.type istweighted_random. Zeigt an, ob die Minimierung von Anomalien aktiviert ist. Der Wert ist entweder on oder off. Der Standardwert ist off.

load_balancing.cross_zone.enabled

Gibt an, ob zonenübergreifendes Load Balancing aktiviert ist. Der Wert ist entweder true, false oder use_load_balancer_configuration. Der Standardwert ist use_load_balancer_configuration.

slow_start.duration_seconds

Der Zeitraum in Sekunden, in dem der Load Balancer für ein neu registriertes Ziel einen linear zunehmenden Anteil des Datenverkehrs an die Zielgruppe sendet. Der Bereich liegt zwischen 30 und 900 Sekunden (15 Minuten). Die Standardwert ist 0 Sekunden (deaktiviert).

stickiness.enabled

Gibt an, ob Sticky Sessions aktiviert sind. Der Wert ist entweder true oder false. Der Standardwert ist false.

stickiness.app_cookie.cookie_name

Der Name der Anwendungs-Cookies. Der Name des Anwendungs-Cookies darf nicht die folgenden Präfixe haben: AWSALB, AWSALBAPP oder AWSALBTG. Sie sind für die Verwendung durch den Load Balancer reserviert.

stickiness.app_cookie.duration_seconds

Die Ablaufzeit anwendungsbasierter Cookies in Sekunden. Nach Ablauf dieses Zeitraums wird das Cookie als veraltet eingestuft. Der Mindestwert ist 1 Sekunde und der Maximalwert ist 7 Tage (604800 Sekunden). Die Standardwert ist 1 Tag (86 400 Sekunden).

stickiness.lb_cookie.duration_seconds

Die Ablaufzeit der auf Dauer basierenden Cookies in Sekunden. Nach Ablauf dieses Zeitraums wird das Cookie als veraltet eingestuft. Der Mindestwert ist 1 Sekunde und der Maximalwert ist 7 Tage (604800 Sekunden). Die Standardwert ist 1 Tag (86 400 Sekunden).

stickiness.type

Die Art der „Sticky Sessions“. Die möglichen Werte sind lb_cookie und app_cookie.

target_group_health.dns_failover.minimum_healthy_targets.count

Die Mindestanzahl von Zielen, die fehlerfrei sein müssen. Wenn die Anzahl der fehlerfreien Ziele unter diesem Wert liegt, markieren Sie die Zone im DNS als fehlerhaft, sodass der Datenverkehr nur an fehlerfreie Zonen weitergeleitet wird. Die möglichen Werte sind off oder eine ganze Zahl von 1 bis zur maximalen Anzahl von Zielen. Falls off, wird DNS-Failaway deaktiviert, was bedeutet, dass jede Zielgruppe unabhängig zum DNS-Failover beiträgt. Der Standardwert ist 1.

target_group_health.dns_failover.minimum_healthy_targets.percentage

Der Mindestprozentzatz der Ziele, die fehlerfrei sein müssen. Wenn der Prozentsatz fehlerfreier Ziele unter diesem Wert liegt, markieren Sie die Zone im DNS als fehlerhaft, sodass der Datenverkehr nur an fehlerfreie Zonen weitergeleitet wird. Die möglichen Werte sind off oder eine ganze Zahl von 1 bis zur maximalen Anzahl von Zielen. Falls off, wird DNS-Failaway deaktiviert, was bedeutet, dass jede Zielgruppe unabhängig zum DNS-Failover beiträgt. Der Standardwert ist 1.

target_group_health.unhealthy_state_routing.minimum_healthy_targets.count

Die Mindestanzahl von Zielen, die fehlerfrei sein müssen. Wenn die Anzahl fehlerfreier Ziele unter diesem Wert liegt, senden Sie Datenverkehr an alle Ziele, einschließlich nicht fehlerfreier Ziele. Der Bereich reicht von 1 bis zur maximalen Anzahl von Zielen. Der Standardwert ist 1.

target_group_health.unhealthy_state_routing.minimum_healthy_targets.percentage

Der Mindestprozentzatz der Ziele, die fehlerfrei sein müssen. Wenn der Prozentsatz fehlerfreier Ziele unter diesem Wert liegt, senden Sie Datenverkehr an alle Ziele, einschließlich nicht fehlerfreier Ziele. Die möglichen Werte sind off oder eine Ganzzahl von 1 bis 100. Der Standardwert ist off.

Das folgende Zielgruppenattribut wird unterstützt, wenn der Zielgruppentyp lambda ist:

lambda.multi_value_headers.enabled

Gibt an, ob die Anfrage- und Antwort-Header, die zwischen dem Load Balancer und der Lambda-Funktion ausgetauscht werden, Arrays von Werten oder Zeichenfolgen enthalten. Die möglichen Werte sind true oder false. Der Standardwert ist false. Weitere Informationen finden Sie unter Header mit mehreren Werten.

Routing-Algorithmen

Ein Routing-Algorithmus ist die Methode, mit der der Load Balancer bestimmt, welche Ziele Anfragen erhalten. Der Round-Robin-Routing-Algorithmus wird standardmäßig verwendet, um Anfragen auf Zielgruppenebene weiterzuleiten. Je nach den Anforderungen Ihrer Anwendung sind auch die am wenigsten ausstehenden Anfragen und gewichtete zufällige Routing-Algorithmen verfügbar. Eine Zielgruppe kann jeweils nur über einen aktiven Routing-Algorithmus verfügen, 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. Künftige Anfragen von demselben Client werden an dasselbe Ziel weitergeleitet, wobei der ausgewählte Routing-Algorithmus umgangen wird.

Rundenturnier

  • Der Round-Robin-Routing-Algorithmus leitet Anfragen gleichmäßig in einer sequentiellen Reihenfolge an gesunde Ziele in der Zielgruppe weiter.

  • Dieser Algorithmus wird häufig verwendet, wenn die eingehenden 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 an laufenden Anfragen weiter.

  • Dieser Algorithmus wird häufig verwendet, wenn die eingehenden Anfragen unterschiedlich komplex sind und die Verarbeitungskapazität der registrierten Ziele unterschiedlich ist.

  • Wenn ein Load Balancer, der HTTP/2 unterstützt, Ziele verwendet, die nur HTTP/1.1 unterstützen, konvertiert er die Anfrage in mehrere HTTP/1.1-Anfragen. In dieser Konfiguration behandelt der Algorithmus für die wenigsten ausstehenden Anfragen jede HTTP/2-Anfrage als mehrere Anfragen.

  • Bei Verwendung wird WebSockets das Ziel anhand des Algorithmus für die wenigsten ausstehenden Anfragen ausgewählt. Nach der Auswahl stellt der Load Balancer eine Verbindung zum Ziel her und sendet alle Nachrichten über diese Verbindung.

  • Der Routing-Algorithmus für die wenigsten ausstehenden Anfragen kann nicht im langsamen Startmodus verwendet werden.

Zufällig gewichtet

  • Der gewichtete Zufalls-Routing-Algorithmus leitet Anfragen gleichmäßig und in zufälliger Reihenfolge an gesunde Ziele in der Zielgruppe weiter.

  • Dieser Algorithmus unterstützt die Minimierung von ATW-Anomalien (Automatic Target Weights).

  • Der Algorithmus für gewichtetes zufälliges Routing kann nicht im langsamen Startmodus verwendet werden.

Ändern Sie den Routing-Algorithmus einer Zielgruppe

Sie können den Routing-Algorithmus für Ihre Zielgruppe jederzeit ändern.

Um den Routing-Algorithmus mit der neuen Konsole zu ändern

  1. Öffnen Sie die Amazon EC2-Konsole unter https://console.aws.amazon.com/ec2/.

  2. Wählen Sie im Navigationsbereich unter Load Balancing die Option Target Groups (Zielgruppen) aus.

  3. Wählen Sie den Namen der Zielgruppe aus, um deren Detailseite zu öffnen.

  4. Wählen Sie auf der Detailseite der Zielgruppen auf der Registerkarte Attribute die Option Bearbeiten aus.

  5. Wählen Sie auf der Seite Zielgruppenattribute bearbeiten im Abschnitt Verkehrskonfiguration unter Load Balancing Algorithm die Optionen Round Robin, Least Outstanding Requests oder Weighted Random aus.

  6. Wählen Sie Änderungen speichern aus.

Um den Routing-Algorithmus mit dem zu ändern AWS CLI

Verwenden Sie den Befehl modify-target-group-attributes zusammen mit dem Attribut load_balancing.algorithm.type.

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 Ziele 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, 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

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

Um den Status der Anomalieerkennung mithilfe der Konsole anzuzeigen

  1. Öffnen Sie die Amazon EC2-Konsole unter https://console.aws.amazon.com/ec2/.

  2. Wählen Sie im Navigationsbereich unter Load Balancing die Option Target Groups (Zielgruppen) aus.

  3. Wählen Sie den Namen der Zielgruppe aus, um deren Detailseite zu öffnen.

  4. Wählen Sie auf der Detailseite der Zielgruppen die Registerkarte Ziele aus.

  5. In der Tabelle Registrierte Ziele können Sie den Anomaliestatus der einzelnen Ziele in der Spalte mit den Ergebnissen der Anomalieerkennung einsehen.

    Wenn keine Anomalien festgestellt wurden, lautet das Ergebnis. normal

    Wenn Anomalien festgestellt wurden, lautet das Ergebnis. anomalous

Um die Ergebnisse der Anomalieerkennung anzuzeigen, verwenden Sie AWS CLI

Verwenden Sie den Befehl describe-target-health, wobei der Include.member.N Attributwert auf gesetzt ist. AnomalyDetection

Minimierung von Anomalien

Wichtig

Die Funktion zur Minimierung von Anomalien von ATW ist nur verfügbar, wenn der Algorithmus Weighted Random Routing verwendet wird.

Die ATW-Abschwächung leitet den Verkehr automatisch von anomalen Zielen weg und gibt ihnen so die Möglichkeit, sich zu erholen.

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.

Schalten Sie die ATW-Abschwächung von Anomalien ein

Sie können die Minimierung von Anomalien jederzeit aktivieren.

Um die Minimierung von Anomalien mithilfe der Konsole zu aktivieren

  1. Öffnen Sie die Amazon EC2-Konsole unter https://console.aws.amazon.com/ec2/.

  2. Wählen Sie im Navigationsbereich unter Load Balancing die Option Target Groups (Zielgruppen) aus.

  3. Wählen Sie den Namen der Zielgruppe aus, um deren Detailseite zu öffnen.

  4. Wählen Sie auf der Detailseite der Zielgruppen auf der Registerkarte Attribute die Option Bearbeiten aus.

  5. Stellen Sie sicher, dass auf der Seite Zielgruppenattribute bearbeiten im Abschnitt Verkehrskonfiguration unter Load Balancing-Algorithmus die Option Weighted Random ausgewählt ist.

    Hinweis: Wenn der gewichtete Zufallsalgorhythmus anfänglich ausgewählt ist, ist die Anomalieerkennung standardmäßig aktiviert.

  6. Stellen Sie sicher, dass unter Minimierung von Anomalien die Option Minimierung von Anomalien aktivieren ausgewählt ist.

  7. Wählen Sie Änderungen speichern aus.

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

Verwenden Sie den Befehl modify-target-group-attributes zusammen mit dem Attribut load_balancing.algorithm.anomaly_mitigation.

Status der Minimierung von Anomalien

Immer wenn ATW eine Risikominderung an einem Ziel durchführt, können Sie den aktuellen Status jederzeit mit dem oder anzeigen. AWS Management Console AWS CLI

Um den Status zur Behebung von Anomalien mithilfe der Konsole einzusehen

  1. Öffnen Sie die Amazon EC2-Konsole unter https://console.aws.amazon.com/ec2/.

  2. Wählen Sie im Navigationsbereich unter Load Balancing die Option Target Groups (Zielgruppen) aus.

  3. Wählen Sie den Namen der Zielgruppe aus, um deren Detailseite zu öffnen.

  4. Wählen Sie auf der Detailseite der Zielgruppen die Registerkarte Ziele aus.

  5. In der Tabelle Registrierte Ziele können Sie den Status der einzelnen Ziele zur Minimierung von Anomalien in der Spalte Minderung wirksam einsehen.

    Wenn die Schadensbegrenzung nicht im Gange ist, lautet der Status. yes

    Wenn die Schadensbegrenzung im Gange ist, lautet der Status. no

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

Verwenden Sie den Befehl describe-target-health, wobei der Attributwert auf gesetzt ist. Include.member.N AnomalyDetection

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.

So aktualisieren Sie den Wert für die Verzögerung der Registrierungsaufhebung mithilfe der Konsole

  1. Öffnen Sie die Amazon EC2-Konsole unter https://console.aws.amazon.com/ec2/.

  2. Wählen Sie im Navigationsbereich unter Load Balancing die Option Target Groups (Zielgruppen) aus.

  3. Wählen Sie den Namen der Zielgruppe aus, um deren Detailseite zu öffnen.

  4. Wählen Sie auf der Registerkarte Gruppendetails im Abschnitt Attribute die Option Bearbeiten aus.

  5. Ändern Sie auf der Seite Attribute bearbeiten den Wert für Abmeldeverzögerung nach Bedarf.

  6. Wählen Sie Änderungen speichern.

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

Verwenden Sie den Befehl modify-target-group-attributes zusammen mit dem Attribut deregistration_delay.timeout_seconds.

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.

So aktualisieren Sie den Wert für die Dauer des langsamen Hochfahrens mithilfe der Konsole

  1. Öffnen Sie die Amazon EC2-Konsole unter https://console.aws.amazon.com/ec2/.

  2. Wählen Sie im Navigationsbereich unter Load Balancing die Option Target Groups (Zielgruppen) aus.

  3. Wählen Sie den Namen der Zielgruppe aus, um deren Detailseite zu öffnen.

  4. Wählen Sie auf der Registerkarte Gruppendetails im Abschnitt Attribute die Option Bearbeiten aus.

  5. Ändern Sie auf der Seite Attribute bearbeiten den Wert von Dauer des langsamen Hochfahrens nach Bedarf. Um den Modus des langsamen Hochfahrens zu deaktivieren, legen Sie als Dauer 0 fest.

  6. Wählen Sie Änderungen speichern aus.

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

Verwenden Sie den Befehl modify-target-group-attributes zusammen mit dem Attribut slow_start.duration_seconds.