Gesundheitschecks für Gateway Load Balancer Balancer-Zielgruppen

Sie können Ihre Ziele bei einer oder mehreren Zielgruppen registrieren. Ihr Gateway Load Balancer beginnt mit dem Routing von Anfragen an ein neu registriertes Ziel, sobald der Registrierungsprozess abgeschlossen ist. Es kann einige Minuten dauern, bis der Registrierungsvorgang abgeschlossen ist und die Zustandsprüfungen beginnen.

Der Gateway Load Balancer sendet in regelmäßigen Abständen eine Anfrage an jedes registrierte Ziel, um dessen Status zu überprüfen. Nach Abschluss jeder Zustandsprüfung schließt der Gateway Load Balancer die Verbindung, die für die Zustandsprüfung hergestellt wurde.

Zustandsprüfungseinstellungen

Sie konfigurieren aktive Zustandsprüfungen für die Ziele in einer Zielgruppe, indem Sie die folgenden Einstellungen verwenden. Wenn die Integritätsprüfungen die angegebene Anzahl UnhealthyThresholdCountaufeinanderfolgender Fehler überschreiten, nimmt der Gateway Load Balancer das Ziel außer Betrieb. Wenn die Zustandsprüfungen die angegebene Anzahl von HealthyThresholdCountaufeinanderfolgenden Erfolgen überschreiten, nimmt der Gateway Load Balancer das Ziel wieder in Betrieb.

Einstellung	Beschreibung
HealthCheckProtocol	Das Protokoll, das der Load Balancer bei der Durchführung von Zustandsprüfungen für Ziele verwendet. Die möglichen Protokolle sind HTTPHTTPS, undTCP. Die Standardeinstellung istTCP.
HealthCheckPort	Der Port, den Gateway Load Balancer bei der Durchführung von Zustandsprüfungen für Ziele verwendet. Der Bereich reicht von 1 bis 65 535. Der Standardwert ist 80.
HealthCheckPath	[HTTP/HTTPShealth checks] Der Pfad zur Integritätsprüfung, der das Ziel auf den Zielen für Zustandsprüfungen ist. Der Standardwert ist /.
HealthCheckTimeoutSeconds	Die Anzahl der Sekunden, in denen keine Antwort von einem Ziel bedeutet, dass die Zustandsprüfung fehlgeschlagen ist. Der Bereich reicht von 2 bis 120. Der Standardwert ist 5.
HealthCheckIntervalSeconds	Der etwaige Zeitraum in Sekunden zwischen den Zustandsprüfungen der einzelnen Ziele. Der Bereich reicht von 5 bis 300. Standardmäßig ist ein Zeitraum von 10 Sekunden festgelegt. Dieser Wert muss größer oder gleich sein HealthCheckTimeoutSeconds. Wichtig Zustandsprüfungen für Gateway Load Balancers sind verteilt und verwenden einen Konsensmechanismus, um den Zustand des Ziels zu bestimmen. Daher sollten Sie damit rechnen, dass die Ziel-Appliances innerhalb des konfigurierten Zeitintervalls mehrere Zustandsprüfungen erhalten.
HealthyThresholdCount	Die Anzahl der aufeinanderfolgenden erfolgreichen Zustandsprüfungen, die erforderlich ist, damit ein fehlerhaftes Ziel als stabil eingestuft wird. Der Bereich liegt zwischen 2 und 10. Der Standardwert ist 5.
UnhealthyThresholdCount	Die Anzahl fortlaufender fehlgeschlagener Zustandsprüfungen, die erforderlich ist, damit ein Ziel als nicht betriebsbereit eingestuft wird. Der Bereich liegt zwischen 2 und 10. Der Standardwert ist 2.
Matcher	[HTTP/HTTPSHealth Checks] Die HTTP Codes, die verwendet werden sollen, wenn geprüft wird, ob ein Ziel erfolgreich reagiert hat. Dieser Wert muss 200–399 betragen.

Zustandsstatus des Ziels

Bevor der Gateway Load Balancer eine Zustandsprüfungsanfrage an ein Ziel sendet, müssen Sie es in einer Zielgruppe registrieren, seine Zielgruppe in einer Listener-Regel angeben und sicherstellen, dass die Verfügbarkeitszone des Ziels für den Gateway Load Balancer aktiviert ist.

Die folgende Tabelle beschreibt die möglichen Werte für den Zustandsstatus eines registrierten Ziels.

Wert	Beschreibung
initial	Der Gateway Load Balancer ist gerade dabei, das Ziel zu registrieren oder die ersten Zustandsprüfungen des Ziels durchzuführen. Zugehörige Ursachencodes: Elb.RegistrationInProgress | Elb.InitialHealthChecking
healthy	Das Ziel ist fehlerfrei. Zugehörige Ursachencodes: Keine
unhealthy	Das Ziel hat nicht auf eine Zustandsprüfung geantwortet oder die Zustandsprüfung ist fehlgeschlagen. Zugehöriger Ursachencode: Target.FailedHealthChecks
unused	Das Ziel wurde nicht für eine Zielgruppe registriert, die Zielgruppe wird nicht in einer Listener-Regel verwendet oder das Ziel befindet sich in einer Availability Zone, die nicht aktiviert ist, oder das Ziel sich im Status „Angehalten“ oder „Beendet“. Zugehörige Ursachencodes: Target.NotRegistered | Target.NotInUse | Target.InvalidState | Target.IpUnusable
draining	Die Registrierung für das Ziel wird aufgehoben, und Connection Draining wird durchgeführt. Zugehöriger Ursachencode: Target.DeregistrationInProgress
unavailable	Die Zielintegrität ist nicht verfügbar. Zugehöriger Ursachencode: Elb.InternalError

Ursachencodes für Zustandsprüfungen

Wenn der Status eines Ziels einen anderen Wert als hatHealthy, werden ein Ursachencode und eine Beschreibung des Problems API zurückgegeben, und die Konsole zeigt dieselbe Beschreibung an. Ursachencodes, die mit Elb beginnen, haben ihren Ursprung auf dem Gateway Load Balancer, und Ursachencodes, die mit Target beginnen, haben ihren Ursprung auf der Seite des Ziels.

Ursachencode	Beschreibung
Elb.InitialHealthChecking	Anfängliche Zustandsprüfungen in Bearbeitung
Elb.InternalError	Zustandsprüfungen aufgrund eines internen Fehles fehlgeschlagen
Elb.RegistrationInProgress	Zielregistrierung wird durchgeführt
Target.DeregistrationInProgress	Zielregistrierung wird aufgehoben
Target.FailedHealthChecks	Zustandsprüfungen fehlgeschlagen
Target.InvalidState	Ziel hat den Status „Angehalten“ Ziel hat den Status „Beendet“ Ziel hat den Status „Beendet oder Angehalten“ Ziel hat den Status „Ungültig“
Target.IpUnusable	Die IP-Adresse kann nicht als Ziel verwendet werden, da sie von einem Load Balancer verwendet wird.
Target.NotInUse	Zielgruppe ist nicht konfiguriert, um Verkehr vom Gateway Load Balancer zu erhalten Ziel ist in einer Verfügbarkeitszone, die nicht für den Gateway Load Balancer aktiviert ist
Target.NotRegistered	Ziel ist nicht in der Zielgruppe registriert

Gateway Load Balancer Ziel-Ausfall-Szenarien

Bestehende Flows: Standardmäßig werden bestehende Flows an dasselbe Ziel weitergeleitet, es sei denn, der Flow läuft ab oder wird zurückgesetzt, unabhängig vom Status und dem Registrierungsstatus des Ziels. Dieser Ansatz erleichtert den Verbindungsverlust und eignet sich auch für Firewalls von Drittanbietern, die aufgrund der hohen Auslastung manchmal nicht in der Lage sind, auf Integritätsprüfungen zu reagieren. CPU Weitere Informationen finden Sie unter Target-Failover.

Neue Flows: Neue Flows werden an ein gesundes Ziel gesendet. Wenn eine Lastausgleichsentscheidung für einen Flow getroffen wurde, sendet der Gateway Load Balancer den Flow an dasselbe Ziel, selbst wenn dieses Ziel fehlerhaft wird oder andere Ziele fehlerfrei werden.

Wenn alle Ziele fehlerhaft sind, wählt der Gateway Load Balancer ein zufälliges Ziel aus und leitet den Datenverkehr für die Dauer des Datenflusses an dieses Ziel weiter, bis es entweder zurückgesetzt wird oder die Zeit abgelaufen ist. Da der Datenverkehr an ein fehlerhaftes Ziel weitergeleitet wird, wird der Datenverkehr unterbrochen, bis das Ziel wieder fehlerfrei ist.

TLS1.3: Wenn eine Zielgruppe mit HTTPS Integritätsprüfungen konfiguriert ist, bestehen ihre registrierten Ziele die Integritätsprüfungen nicht, wenn sie nur TLS 1.3 unterstützen. Diese Ziele müssen eine frühere Version von unterstützenTLS, z. B. TLS 1.2.

Zonenübergreifender Load Balancer: Standardmäßig ist der Load Balancer zwischen Verfügbarkeitszonen deaktiviert. Wenn der zonenübergreifende Load Balancer aktiviert ist, kann jeder Gateway Load Balancer alle Ziele in allen Verfügbarkeitszonen sehen, und sie werden alle gleich behandelt, unabhängig von ihrer Zone.

Entscheidungen über Load Balancing und Zustandsprüfung sind zwischen den Zonen stets unabhängig. Selbst wenn der zonenübergreifende Load Balancer aktiviert ist, ist das Verhalten für bestehende und neue Flows dasselbe wie oben beschrieben. Weitere Informationen finden Sie unter Zonenübergreifendes Load Balancing im Benutzerhandbuch für Elastic Load Balancing.

Zustand der Ziele prüfen

Sie können den Zustand der Ziele, die in Ihren Zielgruppen registriert sind, überprüfen.

Überprüfen des Zustands Ihrer Ziele mithilfe der Konsole

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

2. Wählen Sie im Navigationsbereich unter Load Balancing die Option Load Balancer aus.

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

4. In der Registerkarte Targets (Ziele) gibt die Spalte Status den Status der einzelnen Ziele wider.

5. Wenn der Zielstatus einen anderen Wert als Healthy hat, enthält die Spalte Statusdetails weitere Informationen.

Um den Zustand Ihrer Ziele mit dem zu überprüfen AWS CLI

Verwenden Sie den describe-target-healthBefehl. Die Ausgabe dieses Befehls enthält den Zustand des Ziels. Sie enthält auch einen Ursachencode, wenn der Status einen anderen Wert als Healthy aufweist.

So erhalten Sie E-Mail-Benachrichtigungen über fehlerhafte Ziele

Verwenden Sie CloudWatch Alarme, um eine Lambda-Funktion auszulösen, um Details über fehlerhafte Ziele zu senden. step-by-step Anweisungen finden Sie im folgenden Blogbeitrag: Identifizieren fehlerhafter Ziele Ihres Load Balancers.

Einstellungen für die Zustandsprüfung ändern

Sie können einige Zustandsprüfungseinstellungen für Ihre Zielgruppe ändern.

Ändern von Zustandsprüfungseinstellungen für eine Zielgruppe mithilfe der Konsole

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

2. Wählen Sie im Navigationsbereich unter Load Balancing die Option Load Balancer aus.

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

4. Wählen Sie auf der Registerkarte Gruppendetails im Abschnitt Einstellungen für die Zustandsprüfung die Option Bearbeiten aus.

5. Ändern Sie auf der Seite Einstellungen für die Zustandsprüfung bearbeiten die Einstellungen nach Bedarf und wählen Sie dann Änderungen speichern.

Um die Einstellungen für den Gesundheitscheck für eine Zielgruppe zu ändern, verwenden Sie den AWS CLI

Verwenden Sie den modify-target-groupBefehl.