Oracle Cloud Infrastructure-Dokumentation

Health Check Policys für Network Load Balancer

Sie können die Verfügbarkeit von Backend-Servern für einen Network Load Balancer bestimmen, indem Sie Health Checks einrichten und verwenden.

Ein Health Check ist ein Test, mit dem die Verfügbarkeit von Backend-Servern bestätigt wird. Bei einem Health Check kann es sich um eine Anforderung oder einen Verbindungstest handeln. Der Load Balancer wendet die Health Check Policy in einem angegebenen Zeitintervall an, um die Backend-Server fortlaufend zu überwachen. Wenn ein Server die Health-Check-Bedingungen nicht erfüllt, nimmt der Load Balancer den Server vorübergehend aus der Rotation. Sobald der Server die Health-Check-Bedingungen erfüllt, lässt ihn der Load Balancer wieder zurück in die Rotation.

Sie konfigurieren die Health Check Policy, wenn Sie einen Network Load Balancer erstellen. Sie können die Health Check Policy auch konfigurieren, wenn Sie ein Backend-Set für einen vorhandenen Load Balancer erstellen oder bearbeiten. Im Folgenden finden Sie eine Zusammenfassung der Protokolle, die Sie mit Ihrer Health Check Policy verwenden können:

  • Health Checks auf TCP-Ebene versuchen, eine TCP-Verbindung mit den Backend-Servern herzustellen. Die Antwort wird anhand des Verbindungsstatus validiert.

    Wenn es nicht sinnvoll ist, eine Anforderung für das Protokoll zu erstellen, mit dem Sie arbeiten, müssen Sie die Anforderungsdaten nicht angeben. In diesem Fall gilt das Backend als fehlerfrei, wenn die TCP-Verbindung erfolgreich hergestellt wird.

  • Bei Health Checks auf HTTP-Ebene werden Anforderungen über eine bestimmte URI an die Backend-Server gesendet. Die Reaktion wird anhand des Statuscodes oder der zurückgegebenen Entitydaten (Hauptteil) validiert.
  • Health Checks auf HTTPS-Ebene senden Anforderungen über eine bestimmte URI an die Backend-Server und validieren die Antwort basierend auf dem Statuscode oder den Entitydaten (Text), die über ein sicheres und verschlüsseltes HTTPS-Protokoll zurückgegeben werden.
  • Bei Health Checks auf UDP-Ebene wird eine einzelne Anforderung an den Backend-Server gesendet und die Antwort (sofern empfangen) mit den angegebenen Antwortdaten abgeglichen.
  • Bei Health Checks auf DNS-Ebene werden Anforderungen mit UDP oder TCP an die Backend-Server gesendet. Der Health Check verwendet auch den Abfragenamen und die zugehörigen Informationen, die Sie für die DNS-Antwort vom Backend-Server angeben möchten.

Der Service stellt anwendungsspezifische Health-Check-Funktionen zur Verfügung, mit denen Sie die Verfügbarkeit erhöhen und das Wartungsfenster der Anwendung reduzieren können.

Sie können die folgenden Verwaltungsaufgaben für Health Check Policys ausführen:

Health-Check-Protokoll für die Anwendung oder den Service konfigurieren

Wenn Sie einen HTTP-Service ausführen, müssen Sie einen Health Check auf HTTP-Ebene konfigurieren. Wenn Sie einen Health Check auf TCP-Ebene für einen HTTP-Service ausführen, erhalten Sie möglicherweise keine richtige Antwort. Der TCP-Handshake kann erfolgreich sein und darauf hinweisen, dass der Service hochgefahren ist, obwohl der HTTP-Service falsch konfiguriert ist oder andere Probleme aufweist. Auch wenn der Health Check in Ordnung zu sein scheint, können bei Kunden Transaktionsfehler auftreten. Beispiel:

  • Der Backend-HTTP-Service hat Probleme bei der Kommunikation mit der Health-Check-URL, und die Health-Check-URL gibt 5XX Nachrichten zurück. Ein HTTP-Health-Check fängt die Nachricht von der Health-Check-URL ab und markiert den Service als heruntergefahren. In diesem Fall ist ein TCP-Health-Check-Handshake erfolgreich, und der Service wird als fehlerfrei markiert, obwohl der HTTP-Service nicht verwendet werden kann.
  • Der Backend-HTTP-Service antwortet aufgrund von Autorisierungsproblemen oder nicht konfiguriertem Inhalt mit 4XX-Nachrichten. Ein TCP-Health Check erkennt diese Fehler nicht.

Zustandsindikatoren

Der Network Load Balancer-Service stellt Zustandsindikatoren bereit, die über die Health Check Policys den allgemeinen Zustand der Network Load Balancer und deren Komponenten melden. In der Konsole können Sie auf der Seite "Liste" und Details Zustandsindikatoren für Load Balancer, Backend-Sets und Backend-Server anzeigen. Sie können diese Informationen auch mit der API abrufen.

Zustandsindikatoren haben vier Ebenen. Die folgende Tabelle enthält die allgemeine Bedeutung der einzelnen Ebenen:

Ebene Farbe Beschreibung
OK Grün Keine Maßnahme erforderlich.

Die Ressource funktioniert wie erwartet.
Warnung Gelb Bei einigen Reportingentitys sind Maßnahmen erforderlich.

Die Ressource funktioniert nicht mit maximaler Effizienz, oder die Ressource ist unvollständig und muss weiter bearbeitet werden.
Kritisch Rot Einige oder alle Reportingentitys erfordern sofortige Maßnahmen.

Die Ressource funktioniert nicht, oder ein unerwarteter Fehler steht unmittelbar bevor.
Unbekannt Grau Der Zustand kann nicht ermittelt werden.

Die Ressource antwortet nicht oder befindet sich im Übergang und könnte später in einen anderen Status wechseln.

Die genaue Bedeutung der einzelnen Ebenen variiert zwischen den folgenden Komponenten:

Zustand verwenden

Auf höchster Ebene gibt der Zustand des Network Load Balancers den Zustand der zugehörigen Komponenten an. Die Zustandsindikatoren stellen Informationen bereit, die Sie möglicherweise benötigen, um einen Drilldown durchzuführen und ein vorhandenes Problem zu untersuchen. Häufig auftretende Probleme, die mithilfe der Zustandsindikatoren erkannt und korrigiert werden können, sind unter anderem:

Ein Health Check ist falsch konfiguriert.

In diesem Fall werden alle Backend-Server für mindestens einen der betroffenen Listener als fehlerhaft gemeldet. Wenn Ihre Untersuchung ermittelt, dass die Backend-Server keine Probleme aufweisen, enthält ein Backend-Set wahrscheinlich einen falsch konfigurierten Health Check.

Ein Listener ist falsch konfiguriert.

Alle Zustandsindikatoren der Backend-Server melden OK, doch der Network Load Balancer übergibt keinen Traffic an einem Listener.

Der Listener könnte wie folgt konfiguriert sein:

  • Er überwacht den falschen Port.
  • Er verwendet das falsche Protokoll.
  • Er verwendet die falsche Policy.

Wenn Sie bei Ihrer Untersuchung feststellen, dass der Listener nicht fehlerhaft ist, prüfen Sie die Konfiguration der Sicherheitsliste.

Eine Sicherheitsregel ist falsch konfiguriert.

Mithilfe von Zustandsindikatoren können Sie zwei Fälle falsch konfigurierter Sicherheitsregeln diagnostizieren:

  • Alle Entitystatusindikatoren melden OK, aber der Traffic fließt nicht (wie bei falsch konfigurierten Listenern). Wenn der Listener nicht fehlerhaft ist, prüfen Sie die Konfiguration der Sicherheitsregeln.
  • Alle Entityzustände werden als fehlerhaft gemeldet. Sie haben die Health-Check-Konfiguration geprüft, und die Services werden auf den Backend-Servern korrekt ausgeführt.

    In diesem Fall enthalten die Sicherheitsregeln möglicherweise nicht den IP-Bereich für die Quelle der Health-Check-Anforderungen. Sie finden die Quell-IP des Health Checks auf der Seite Details für jeden Backend-Server. Sie können auch die API verwenden, um die IP im FeldsourceIpAddress des Objekts HealthCheckResult zu suchen.

    Hinweis

    Die Quell-IP für Health-Check-Anforderungen stammt aus einer Compute-Instanz, die vom Network Load Balancer-Service verwaltet wird.

Mindestens ein Backend-Server wird als fehlerhaft gemeldet.

Möglicherweise ist ein Backend-Server fehlerhaft, oder der Health Check ist falsch konfiguriert. Den entsprechenden Fehlercode finden Sie im Feld Status auf der Seite Details des Backend-Servers. Sie können auch die API verwenden, um den Fehlercode im Feld healthCheckStatus des Objekts HealthCheckResult zu suchen.

Weitere Fälle, in denen sich der Zustand als nützlich erweisen könnte:

Der Zustand wird alle drei Minuten aktualisiert. Es ist keine feinere Granularität verfügbar.

Der Zustand enthält keine historischen Zustandsdaten.

Best Practices für Health Checks

Konfigurieren Sie das Health-Check-Protokoll so, dass es mit der Anwendung oder dem Service übereinstimmt. Wenn Sie einen HTTP-Service ausführen, müssen Sie einen Health Check auf HTTP-Ebene konfigurieren. Wenn Sie einen Health Check auf TCP-Ebene für einen HTTP-Service ausführen, erhalten Sie möglicherweise keine richtige Antwort. Der TCP-Handshake kann erfolgreich sein und darauf hinweisen, dass der Service hochgefahren ist, obwohl der HTTP-Service falsch konfiguriert ist oder andere Probleme aufweist. Auch wenn der Health Check in Ordnung zu sein scheint, können bei Kunden Transaktionsfehler auftreten.

Beispiel:

  • Der Backend-HTTP-Service hat Probleme bei der Kommunikation mit der Health-Check-URL, und die Health-Check-URL gibt 5XX Nachrichten zurück. Ein HTTP-Health-Check fängt die Nachricht von der Health-Check-URL ab und markiert den Service als heruntergefahren. In diesem Fall ist ein TCP-Health-Check-Handshake erfolgreich, und der Service wird als fehlerfrei markiert, obwohl der HTTP-Service nicht verwendet werden kann.
  • Der Backend-HTTP-Service antwortet aufgrund von Autorisierungsproblemen oder nicht konfiguriertem Inhalt mit 4XX-Nachrichten. Ein TCP-Health Check erkennt diese Fehler nicht.

Häufige Nebenwirkungen einer Fehlkonfiguration von Health Checks

Im Folgenden werden häufige Nebenwirkungen der Fehlkonfiguration von Health Checks aufgeführt. Diese Aufstellung kann zur Behebung von Problemen dienen.

  • Falscher Port

    In diesem Szenario werden alle Backend-Server als fehlerhaft gemeldet. Wenn die Backend-Server keine Probleme aufweisen, haben Sie möglicherweise den Port falsch festgelegt. Der Port muss horchen und zulässigen Traffic auf dem Backend haben.

    OCI-Loggingfehler: errno":"EHOSTUNREACH","syscall":"connect".

  • Falscher Pfad

    In diesem Szenario werden alle Backend-Server als fehlerhaft gemeldet. Wenn die Backend-Server keine Probleme aufweisen, haben Sie möglicherweise den Pfad für den HTTP-Health Check falsch festgelegt. Er muss mit einer tatsächlichen Anwendung auf dem Backend-Server übereinstimmen. In diesem Fall können Sie einen curl-Test von einem System im selben Netzwerk aus durchführen.

    Beispiel: 

    $ curl -i http://10.0.0.5/health

    Der konfigurierte Statuscode ist in der Antwort im OCI-Loggingfehler enthalten: 

    "msg":"invalid statusCode","statusCode":404,"expected":"200".
  • Falsches Protokoll

    In diesem Szenario werden alle Backend-Server als fehlerhaft gemeldet. Wenn die Backend-Server keine Probleme aufweisen, haben Sie das Protokoll möglicherweise falsch festgelegt. Es muss mit dem im Backend horchenden Protokoll übereinstimmen. Beispiel: Es werden nur TCP- und HTTP-Health Checks unterstützt. Wenn der Backend-Server HTTPS verwendet, verwenden Sie TCP als Protokoll.

    OCI-Loggingfehler:

    "code":"EPROTO","errno":"EPROTO".
  • Falscher Statuscode

    In diesem Szenario werden alle Backend-Server als fehlerhaft gemeldet. Wenn die Back-End-Server keine Probleme aufweisen, haben Sie möglicherweise bei einem HTTP-Health Check den Statuscode falsch festgelegt, sodass er mit dem vom Backend zurückgegebenen tatsächlichen Statuscode übereinstimmt. Ein häufiges Szenario ist, dass ein Backend einen 302 zurückgibt, während 200 erwartet wird. Dieses Ergebnis ist wahrscheinlich darauf zurückzuführen, dass das Backend zu einer Anmeldeseite oder einem anderen Speicherort auf dem Server weiterleitet. In diesem Szenario können Sie das Backend entweder korrigieren, um den erwarteten Code zurückzugeben, oder in der Health-Check-Konfiguration den Wert 302 verwenden.

    OCI-Loggingfehler:

    "msg":"invalid statusCode","statusCode":XX,"expected":"200"

    Dabei ist XX der zurückgegebene Statuscode.

  • Falsches Muster des regulären Ausdrucks

    Alle Backend-Server werden als fehlerhaft gemeldet. Wenn die Backend-Server keine Probleme aufweisen, haben Sie möglicherweise ein falsches, mit dem Body konsistentes Muster des regulären Ausdrucks festgelegt, oder das Backend gibt nicht den erwarteten Body zurück. In diesem Szenario können Sie entweder das Backend so ändern, dass es dem Muster entspricht, oder das Muster so korrigieren, dass es dem Backend entspricht. Im Folgenden finden Sie einige spezifische Musterbeispiele.

    • Beliebiger Inhalt - ".*"
    • Eine Seite, die den Wert "Status:OK:" zurückgibt - "Status:OK:".*"
    • OCI-Loggingfehler: "response match result: failed"
  • Falsch konfigurierte Netzwerksicherheitsgruppen, Sicherheitslisten oder lokale Firewall

Alle oder einige Backend-Server werden als fehlerhaft gemeldet. Wenn die Backend-Server keine Probleme haben, haben Sie möglicherweise die NSGs, Sicherheitslisten oder lokalen Firewalls wie firewalld, iptables oder SELiinux falsch konfiguriert. In diesem Szenario können Sie einen curl- oder netcat-Test von einem System aus verwenden, das demselben Subnetz und derselben NSG wie die Balancer-Instanz gehört:

Beispiel: 

$ curl -i http://10.0.0.5/health TCP: ex: nc -zvw3 10.0.05 443.

Sie können die lokale Firewall mit dem folgenden Befehl prüfen: 

firewall-cmd --list-all --zone=public.

Wenn in der Firewall die erwarteten Regeln fehlen, können Sie den Service beispielsweise mit dem folgenden Befehlssatz hinzufügen (in diesem Beispiel für HTTP-Port 80): 

  • firewall-cmd --zone=public --add-service=http
  • firewall-cmd --zone=public --permanent --add-service=http

Health Check-Protokoll für Ihre Anwendung oder Ihren Service konfigurieren

Der Service stellt anwendungsspezifische Health-Check-Funktionen zur Verfügung, mit denen Sie die Verfügbarkeit erhöhen und das Wartungsfenster der Anwendung reduzieren können.

Wenn Sie einen HTTP-Service ausführen, müssen Sie einen Health Check auf HTTP-Ebene konfigurieren. Wenn Sie einen Health Check auf TCP-Ebene für einen HTTP-Service ausführen, erhalten Sie möglicherweise keine richtige Antwort. Der TCP-Handshake kann erfolgreich sein und darauf hinweisen, dass der Service hochgefahren ist, obwohl der HTTP-Service falsch konfiguriert ist oder andere Probleme aufweist. Auch wenn der Health Check in Ordnung zu sein scheint, können bei Kunden Transaktionsfehler auftreten. Beispiel:

  • Der Backend-HTTP-Service hat Probleme bei der Kommunikation mit der Health-Check-URL, und die Health-Check-URL gibt 5XX Nachrichten zurück. Ein HTTP-Health-Check fängt die Nachricht von der Health-Check-URL ab und markiert den Service als heruntergefahren. In diesem Fall ist ein TCP-Health-Check-Handshake erfolgreich, und der Service wird als fehlerfrei markiert, obwohl der HTTP-Service nicht verwendet werden kann.
  • Der Backend-HTTP-Service antwortet aufgrund von Autorisierungsproblemen oder nicht konfiguriertem Inhalt mit 4XX-Nachrichten. Ein TCP-Health Check erkennt diese Fehler nicht.

DNS-Integritätsprüfung

Der Network Load Balancer-Service unterstützt die DNS-Zustandsprüfung für TCP- und UDP-Transport sowohl für IPv4- als auch für IPv6-Backend-Server. Die DNS-Zustandsprüfung für DNS-Resolver-Backend-Server ist eine Verbesserung gegenüber TCP- oder UDP-basierten Prüfungen, da sie prüft, ob das DNS-Protokoll für die DNS-Resolver-Backend-Server funktionsfähig ist. Diese Protokolle verwenden das base64-Format, um die Anforderungs- und Antwortnachrichten anzugeben. Das kann bei der Erstellung von DNS-Anforderungen und -Antworten schwierig sein. Außerdem können in der Antwortnachricht mehrere gültige Antworten und RCODE vorhanden sein, z.B. NOERROR(0) und NXDOMAIN(3). Die Behandlung all dieser Szenarien mit dem standardmäßigen TCP- oder UDP-Health Check ist nicht möglich.

Wenn Sie ein Backend-Set erstellen, entweder während der ersten Network Load Balancer-Erstellung oder beim Hinzufügen eines Backend-Sets zu einem vorhandenen Network Load Balancer, müssen Sie die folgenden protokollspezifischen Konfigurationen angeben, wenn Sie die DNS-Zustandsprüfung verwenden:

  • Abfragename: Geben Sie einen DNS-Domainnamen für die Abfrage an.
  • Abfrageklasse: Wählen Sie eine der folgenden Optionen aus:
    • IN: Internet (Standard)
    • CH: Chaos
  • Abfragetyp: Wählen Sie eine der folgenden Optionen aus:
    • A: Gibt einen Hostnamen an, der der der IPv4-Adresse entspricht. (Standard)
    • AAAA: Gibt einen Hostnamen mit der entsprechenden IPv6-Adresse an.
    • TXT: Gibt ein Textfeld an.
  • Zulässige Antwortcodes: Wählen Sie mindestens eine der folgenden Optionen aus:
    • RCODE:0 NOERROR-DNS-Abfrage erfolgreich abgeschlossen.
    • RCODE:2 SERVFAIL Der Server konnte die DNS-Anforderung nicht abschließen.
    • RCODE:3 NXDOMAIN-Domainname ist nicht vorhanden.
    • RCODE:5 REFUSED Der Server weigerte sich, die Abfrage zu beantworten.