Zustandsprüfungen für Ihre Zielgruppen

Sie können Ihre Ziele bei einer oder mehreren Zielgruppen registrieren. Der Load Balancer beginnt, Anfragen auf ein neu registriertes Ziel umzuleiten sobald die Registrierung abgeschlossen ist. Es kann einige Minuten dauern, bis der Registrierungsvorgang abgeschlossen ist und die Zustandsprüfungen gestartet werden.

Network Load Balancers verwenden aktive und passive Zustandsprüfungen, um zu ermitteln, ob ein Ziel für die Verarbeitung von Anforderungen verfügbar ist. Standardmäßig leitet jeder Load Balancer-Knoten Anfragen nur an störungsfreie Ziele in seiner Availability Zone weiter. Wenn das zonenübergreifende Load Balancing aktiviert ist, leitet jeder Load Balancer-Knoten Anforderungen an störungsfreie Ziele in allen aktivierten Availability Zones weiter. Weitere Informationen finden Sie unter Zonenübergreifendes Load Balancing.

Mit passiven Zustandsprüfungen beobachtet der Load Balancer, wie Ziele auf Verbindungen reagieren. Passive Zustandsprüfungen ermöglichen dem Load Balancer, ein fehlerhaftes Ziel zu erkennen, bevor es von den aktiven Zustandsprüfungen als fehlerhaft gemeldet wird. Sie können passive Zustandsprüfungen nicht deaktivieren, konfigurieren oder überwachen. Passive Zustandsprüfungen werden für UDP-Verkehr und Zielgruppen mit aktivierter Stickiness nicht unterstützt. Weitere Informationen finden Sie unter Sticky Sessions.

Wenn ein Ziel fehlerhaft wird, sendet der Load Balancer ein TCP RST für Pakete, die auf den mit dem Ziel verknüpften Client-Verbindungen empfangen werden, es sei denn, das fehlerhafte Ziel veranlasst den Load Balancer zum Fail-Open.

Wenn Zielgruppen in einer aktivierten Availability Zone kein fehlerfreies Ziel haben, entfernen wir die IP-Adresse für das entsprechende Subnetz vom DNS, so dass in dieser Availability Zone keine Anfragen an Ziele weitergeleitet werden können. Beim Load Balancer erfolgt ein Fail-Open, wenn alle Ziele gleichzeitig die Zustandsprüfungen in allen aktivierten Availability Zones nicht bestehen. Network Load Balancers können auch nicht geöffnet werden, wenn Sie eine leere Zielgruppe haben. Der Effekt des Fail-Open ist, dass der Datenverkehr zu allen Zielen in allen aktivierten Availability Zones zugelassen wird, unabhängig von ihrem Zustand.

Wenn eine Zielgruppe mit HTTPS-Zustandsprüfungen konfiguriert ist, schlagen ihre registrierten Ziele Zustandsprüfungen fehl, wenn sie nur TLS 1.3 unterstützen. Diese Ziele müssen eine frühere Version von TLS unterstützen, z. B. TLS 1.2.

Bei HTTP- oder HTTPS-Zustandsprüfungsanforderungen enthält der Host-Header anstelle der IP-Adresse des Ziels und des Zustandsprüfungs-Ports die IP-Adresse des Load Balancer-Knotens und des Listener-Ports.

Wenn Sie Ihrem Network Load Balancer einen TLS-Listener hinzufügen, führen wir einen Test der Listener-Konnektivität durch. Da das Beenden von TLS auch eine TCP-Verbindung beendet, wird eine neue TCP-Verbindung zwischen Ihrem Load Balancer und Ihren Zielen hergestellt. Daher werden die TCP-Verbindungen für diesen Test möglicherweise von Ihrem Load Balancer an die Ziele gesendet, die bei Ihrem TLS-Listener registriert sind. Sie können diese TCP-Verbindungen identifizieren, da sie die Quell-IP-Adresse Ihres Network Load Balancer haben und die Verbindungen keine Datenpakete enthalten.

Bei einem UDP-Service kann die Verfügbarkeit des Ziels mithilfe von Zustandsprüfungen, die nicht auf UDP basieren, an Ihrer Zielgruppe getestet werden. Sie können jede verfügbare Zustandsprüfung (TCP, HTTP oder HTTPS) und jeden Port auf Ihrem Ziel verwenden, um die Verfügbarkeit eines UDP-Services zu überprüfen. Wenn der Service, der die Zustandsprüfung empfängt, fehlschlägt, wird Ihr Ziel als nicht verfügbar betrachtet. Um die Genauigkeit der Zustandsprüfungen für einen UDP-Service zu verbessern, konfigurieren Sie den Service, der den Port für die Zustandsprüfung abhört, auf eine Weise, dass der Zustand Ihres UDP-Service nachverfolgt und die Zustandsprüfung failt, wenn der Service nicht verfügbar ist.

Zustandsprüfungseinstellungen

Sie können aktive Zustandsprüfungen für die Ziele in einer Zielgruppe mit den folgenden Einstellungen konfigurieren. Wenn die Integritätsprüfungen die UnhealthyThresholdAnzahl aufeinanderfolgender Fehler überschreiten, nimmt der Load Balancer das Ziel außer Betrieb. Wenn die Integritätsprüfungen die HealthyThresholdAnzahl aufeinanderfolgender Erfolge überschreiten, nimmt der Load Balancer das Ziel wieder in Betrieb.

Einstellung	Beschreibung	Standard
HealthCheckProtokoll	Das Protokoll, das der Load Balancer für die Zustandsprüfungen der Ziele verwendet. Möglichen Protokolle sind HTTP, HTTPS und TCP. Das Standardprotokoll ist TCP. Wenn der Zieltyp alb ist, sind die unterstützten Zustandsprüfungsprotokolle HTTP und HTTPS.	TCP
HealthCheckHafen	Der Port, den der Load Balancer für die Zustandsprüfungen der Ziele verwendet. Standardmäßig wird der Port verwendet, auf dem jedes Ziel Datenverkehr vom Load Balancer empfängt.	Port, auf dem jedes Ziel Datenverkehr vom Load Balancer empfängt.
HealthCheckPfad	[HTTP/HTTPS-Zustandsprüfungen] 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 liegt zwischen 2 und 120 Sekunden. Die Standardwerte sind 6 Sekunden für HTTP- und 10 Sekunden für TCP- und HTTPS-Zustandsprüfungen.	6 Sekunden für HTTP- und 10 Sekunden für TCP- und HTTPS-Zustandsprüfungen.
HealthCheckIntervalSeconds	Der etwaige Zeitraum in Sekunden zwischen den Zustandsprüfungen der einzelnen Ziele. Der Bereich liegt zwischen 5 und 300 Sekunden. Standardmäßig ist ein Zeitraum von 30 Sekunden festgelegt. Wichtig Zustandsprüfungen für Network Load Balancers sind verteilt und verwenden einen Konsensmechanismus, um den Zustand des Ziels zu bestimmen. Daher erhalten Ziele mehr als die konfigurierte Anzahl von Zustandsprüfungen. Wenn Sie die Auswirkungen auf Ihre Ziele bei HTTP-Zustandsprüfungen reduzieren möchten, verwenden Sie ein einfacheres Ziel bei den Zielen, z. B. eine statische HTML-Datei, oder wechseln Sie zu TCP-Zustandsprüfungen.	30 Sekunden
HealthyThresholdZählen	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.	5
UnhealthyThresholdZählen	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.	2
Matcher	[HTTP/HTTPS-Zustandsprüfungen] Die HTTP-Codes, die verwendet werden, um ein Ziel auf eine erfolgreiche Antwort zu überprüfen. Der Bereich liegt zwischen 200 und 599. Der Standard ist 200–399.	200-399

Zustandsstatus des Ziels

Bevor der Load Balancer eine Zustandsprüfungsanforderung an ein Ziel sendet, müssen Sie dieses Ziel in einer Zielgruppe registrieren, die Zielgruppe in einer Listener-Regel spezifizieren und sicherstellen, dass die Availability Zone des Ziels für den Load Balancer aktiviert ist.

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

Wert	Beschreibung
initial	Der Load Balancer befindet sich im Prozess der Registrierung eines Ziels oder der Durchführung der anfänglichen Zustandsprüfungen für das Ziel. Zugehörige Ursachencodes: Elb.RegistrationInProgress | Elb.InitialHealthChecking
healthy	Das Ziel ist fehlerfrei. Zugehörige Ursachencodes: Keine
unhealthy	Das Ziel hat auf eine Integritätsprüfung nicht geantwortet, hat die Integritätsprüfung nicht bestanden oder das Ziel befindet sich im Status „Gestoppt“. Zugehöriger Ursachencode: Target.FailedHealthChecks
draining	Die Registrierung für das Ziel wird aufgehoben, und Connection Draining wird durchgeführt. Zugehöriger Ursachencode: Target.DeregistrationInProgress
unhealthy.draining	Das Ziel hat auf die Zustandsprüfungen nicht geantwortet oder hat die Zustandsprüfungen nicht bestanden und tritt in eine Übergangsfrist ein. Das Ziel unterstützt bestehende Verbindungen und akzeptiert während dieser Übergangszeit keine neuen Verbindungen. Zugehöriger Ursachencode: Target.FailedHealthChecks
unavailable	Die Zielintegrität ist nicht verfügbar. Zugehöriger Ursachencode: Elb.InternalError
unused	Das Ziel ist nicht bei einer Zielgruppe registriert, die Zielgruppe wird nicht in einer Listener-Regel verwendet oder das Ziel befindet sich in einer Availability Zone, die nicht aktiviert ist. Zugehörige Ursachencodes: Target.NotRegistered | Target.NotInUse | Target.InvalidState | Target.IpUnusable

Ursachencodes für Zustandsprüfungen

Wenn der Status eines Ziels einen anderen Wert als Healthy aufweist, gibt die API einen Ursachencode und eine Beschreibung des Problems zurück und die Konsole zeigt die gleiche Beschreibung in einer QuickInfo an. Beachten Sie, dass Ursachencodes, die mit Elb beginnen, ihren Ursprung auf dem Load Balancer und Grundcodes, die mit Target beginnen, ihren Ursprung auf der Ziel-Seite haben.

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 Load Balancer zu erhalten Ziel ist in einer Availability Zone, die nicht für den Load Balancer aktiviert ist
Target.NotRegistered	Ziel ist nicht in der Zielgruppe registriert

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 Amazon EC2-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 aus, um deren Detailseite zu öffnen.

4. Im Detailbereich werden die Gesamtzahl der Ziele sowie die Anzahl der Ziele für jeden Zustand angezeigt.

5. In der Registerkarte Ziele gibt die Spalte Zustandsstatus den Status der einzelnen Ziele wider.

6. Wenn der Status einen anderen Wert als Healthy hat, enthält die Spalte Details zum Zustand weitere Informationen.

Um den Zustand Ihrer Ziele zu überprüfen, verwenden Sie AWS CLI

Verwenden Sie den Befehl describe-target-health. 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.

Ändern der Zustandsprüfungseinstellungen für eine Zielgruppe

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

Ändern von Zustandsprüfungseinstellungen für eine Zielgruppe 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 Load Balancer aus.

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

4. Wählen Sie in der Registerkarte Health checks (Zustandsprüfungen) die Option Edit (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 die Zustandsprüfung für eine Zielgruppe zu ändern, verwenden Sie AWS CLI

Verwenden Sie den Befehl modify-target-group.