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.
Gesundheitschecks für Network Load Balancer Balancer-Zielgruppen
Sie können Ihre Ziele bei einer oder mehreren Zielgruppen registrieren. Der Load Balancer leitet Anfragen an ein neu registriertes Ziel weiter, sobald der Registrierungsprozess abgeschlossen ist und die Ziele die ersten Zustandsprüfungen bestanden haben. 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 Traffic und Zielgruppen mit aktivierter Sperrfunktion nicht unterstützt. Weitere Informationen finden Sie unter Sticky Sessions.
Wenn ein Ziel fehlerhaft wird, sendet der Load Balancer eine Nachricht TCP RST für Pakete, die auf den mit dem Ziel verknüpften Client-Verbindungen empfangen wurden, es sei denn, das fehlerhafte Ziel führt dazu, dass der Load Balancer nicht geöffnet wird.
Wenn Zielgruppen kein fehlerfreies Ziel in einer aktivierten Availability Zone haben, entfernen wir die IP-Adresse für das entsprechende Subnetz aus, DNS sodass Anfragen nicht an Ziele in dieser Availability Zone 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 Balancer 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 Integritätsprüfungen konfiguriert ist, bestehen die HTTPS Integritätsprüfungen der registrierten Ziele 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.
Bei Anfragen zur HTTP HTTPS Integritätsprüfung enthält der Host-Header die IP-Adresse des Load Balancer-Knotens und den Listener-Port, nicht die IP-Adresse des Ziels und den Port für die Integritätsprüfung.
Wenn Sie Ihrem Network Load Balancer einen TLS Listener hinzufügen, führen wir einen Listener-Konnektivitätstest durch. Da durch die TLS Kündigung auch eine TCP Verbindung beendet wird, 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 Listener registriert sind. TLS 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 Dienst kann die Verfügbarkeit des Ziels anhand von Tests ohne UDP Systemstatus an Ihrer Zielgruppe getestet werden. Sie können jeden verfügbaren Integritätscheck (TCP,HTTP, oderHTTPS) und jeden Port auf Ihrem Ziel verwenden, um die Verfügbarkeit eines UDP Dienstes 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 Dienst zu verbessern, konfigurieren Sie den Dienst, der den Integritätsprüfport überwacht, sodass er den Status Ihres UDP Dienstes verfolgt und die Zustandsprüfung nicht besteht, falls der Dienst 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 UnhealthyThresholdCountaufeinanderfolgende Fehler überschreiten, nimmt der Load Balancer das Ziel außer Betrieb. Wenn die Zustandsprüfungen HealthyThresholdCountaufeinanderfolgende Erfolge überschreiten, nimmt der Load Balancer das Ziel wieder in Betrieb.
| Einstellung | Beschreibung | Standard |
|---|---|---|
|
HealthCheckProtocol |
Das Protokoll, das der Load Balancer für die Zustandsprüfungen der Ziele verwendet. Die möglichen Protokolle sind HTTPHTTPS, undTCP. Die Standardeinstellung ist das TCP Protokoll. Wenn der Zieltyp ist |
TCP |
|
HealthCheckPort |
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. |
|
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 liegt zwischen 2 und 120 Sekunden. Die Standardwerte sind 6 Sekunden für HTTP und 10 Sekunden für TCP HTTPS Integritätsprüfungen. |
6 Sekunden für HTTP Integritätsprüfungen und 10 Sekunden für TCP HTTPS Integritätsprü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. WichtigZustandsprü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. Um die Auswirkungen auf Ihre Ziele zu verringern, wenn Sie HTTP Integritätsprüfungen verwenden, verwenden Sie ein einfacheres Ziel für die Ziele, z. B. eine statische HTML Datei, oder wechseln Sie zu TCP Integritätsprüfungen. |
30 Sekunden |
|
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. |
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. |
2 |
|
Matcher |
[HTTP/HTTPSHealth Checks] Die HTTP Codes, die verwendet werden sollen, wenn geprüft wird, ob ein Ziel erfolgreich reagiert hat. 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 |
|---|---|
|
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: |
|
Das Ziel ist fehlerfrei. Zugehörige Ursachencodes: Keine |
|
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: |
|
Die Registrierung für das Ziel wird aufgehoben, und Connection Draining wird durchgeführt. Zugehöriger Ursachencode: |
|
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: |
|
Die Zielintegrität ist nicht verfügbar. Zugehöriger Ursachencode: |
|
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: |
Ursachencodes für Zustandsprüfungen
Wenn der Status eines Ziels einen anderen Wert als hatHealthy, werden ein API Ursachencode und eine Beschreibung des Problems zurückgegeben, und die Konsole zeigt dieselbe Beschreibung in einem Tooltip 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 |
|---|---|
|
Anfängliche Zustandsprüfungen in Bearbeitung |
|
Zustandsprüfungen aufgrund eines internen Fehles fehlgeschlagen |
|
Zielregistrierung wird durchgeführt |
|
Zielregistrierung wird aufgehoben |
|
Zustandsprüfungen fehlgeschlagen |
|
Ziel hat den Status „Angehalten“ Ziel hat den Status „Beendet“ Ziel hat den Status „Beendet oder Angehalten“ Ziel hat den Status „Ungültig“ |
|
Die IP-Adresse kann nicht als Ziel verwendet werden, da sie von einem Load Balancer verwendet wird. |
|
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 |
|
Ziel ist nicht in der Zielgruppe registriert |
