Oracle Cloud Infrastructure-Dokumentation

Health Checks

Health Checks für Load Balancer sind Tests, um die Verfügbarkeit von Backend-Servern zu bestätigen.

Diese Tests werden je nach Protokoll in Form einer Anfrage oder eines Verbindungsversuchs durchgeführt. Die Health Check Policy enthält ein Zeitintervall, das Sie angeben, um sicherzustellen, dass die Backend-Server kontinuierlich überwacht werden. Wenn ein Server einen Health Check nicht bestanden hat, nimmt der Load Balancer den Server vorübergehend aus der Rotation. Wenn der Server später einen nachfolgenden Health Check durchläuft, gibt die LB diesen Backend-Server an die Ausgleichsrotation zurück.

Die Health Check Policy wird konfiguriert, wenn Sie ein Backend-Set erstellen. Sie können Health Checks auf TCP- oder HTTP-Ebene für die Backend-Server konfigurieren. Bei Backend-Sets, die mit SSL konfiguriert sind, verwenden die Health Checks auch die SSL-Verschlüsselung.

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

  • 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.

Konfigurieren Sie Ihr Health-Check-Protokoll so, dass es Ihrer Anwendung oder Ihrem Service entspricht. Wenn Sie einen HTTP-Service ausführen, konfigurieren Sie einen Health Check auf HTTP-Ebene. 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 keine Fehler zurückgibt, können Transaktionsfehler auftreten.

Beispiele:

  • Der Backend-HTTP-Service hat Probleme bei der Kommunikation mit der Health-Check-URL, und die Health-Check-URL gibt 5nn-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 HTTP-Backend-Service antwortet aufgrund von Autorisierungsproblemen oder nicht konfiguriertem Inhalt mit 4nn-Nachrichten. Ein TCP-Health-Check erkennt diese Fehler nicht.

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.

Zustandsindikatoren werden verwendet, um den allgemeinen Zustand eines Load Balancers und seiner Backend-Server/-Sets zu melden. Mögliche Statuswerte sind: ok, warning, critical, unknown. Der Zustand wird alle drei Minuten aktualisiert. Es ist keine feinere Granularität verfügbar. Historische Gesundheitsdaten wurden nicht angegeben.

Load Balancer-Zustandsprobleme interpretieren

Auf der höchsten Ebene gibt der Load Balancer-Zustand den Status der zugehörigen Komponenten an. Die Zustandsindikatoren stellen Informationen bereit, die Sie möglicherweise einen Drilldown durchführen und weitere untersuchen müssen. Im Folgenden finden Sie einige häufig auftretende Probleme, die mithilfe der Zustandsindikatoren erkannt und korrigiert werden können.

Health Check falsch konfiguriert

Alle Backend-Server für mindestens einen der betroffenen Listener werden als fehlerhaft gemeldet. Wenn Sie bei der Untersuchung feststellen, dass die Backend-Server keine Probleme aufweisen, enthält ein Backend-Set wahrscheinlich einen falsch konfigurierten Health Check.

Listener falsch konfiguriert

Alle Zustandsindikatoren der Backend-Server melden OK, der Load Balancer übergibt bei einem Listener aber keinen Traffic. Der Listener kann so konfiguriert werden, dass er auf dem falschen Port horcht, das falsche Protokoll verwendet oder die falsche Policy verwendet. Wenn Sie bei der Untersuchung feststellen, dass der Listener nicht fehlerhaft ist, prüfen Sie die Konfiguration der Sicherheitsregeln.

Sicherheitsregel falsch konfiguriert

Mithilfe von Statusanzeigen können Sie diese Fälle von falsch konfigurierten Sicherheitsregeln diagnostizieren:

  • Alle Zustandsindikatoren 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 Gesundheitsstatusindikatoren gelten als ungesund. Sie haben die Health-Check-Konfiguration geprüft, und die Services werden ordnungsgemäß auf den Backend-Servern ausgeführt. In diesem Fall enthalten die Sicherheitsregeln möglicherweise nicht den IP-Bereich für die Quelle der Health-Check-Anforderungen. Die Quell-IP für Health Check-Anforderungen gehört zu einer Compute-Instanz, die vom Load Balancing-Service verwaltet wird.

Hinweis

Der Traffic kann auch wegen falsch konfigurierter Routentabellen in den Compute-Instanzen blockiert werden.

Backend-Server fehlerhaft

Möglicherweise ist ein Backend-Server fehlerhaft, oder der Health Check ist falsch konfiguriert. Um den entsprechenden Fehlercode anzuzeigen, prüfen Sie das Statusfeld in den Details des Backend-Servers über die Konsole oder CLI.

Häufige Nebenwirkungen einer Load-Balancer-Fehlkonfiguration

Es ist bekannt, dass Fehlkonfigurations-Szenarien regelmäßig auftreten. Diese Seite hilft bei der Fehlerbehebung.

Falscher Port
In diesem Szenario werden alle Backend-Server als fehlerhaft gemeldet. Wenn Sie bestätigt haben, dass es keine Probleme mit den Backend-Servern gibt, haben Sie den Port möglicherweise falsch festgelegt. Traffic muss zulässig sein, und das Backend muss auf diesem Port horchen.
Falscher Pfad

In diesem Szenario werden alle Backend-Server als fehlerhaft gemeldet. Wenn Sie bestätigt haben, dass es keine Probleme mit den Backend-Servern gibt, haben Sie möglicherweise den Pfad für den HTTP-Health Check falsch festgelegt. Es muss mit einer tatsächlichen Anwendung im Backend übereinstimmen.

Mit dem curl-Utility können Sie einen Test von einem System im selben Netzwerk aus ausführen. Beispiel: curl -i http://backend_ip_address/health.

Sie erhalten den konfigurierten Statuscode in der Antwort: 
"msg":"invalid statusCode","statusCode":404,"expected":"200"
Falsches Protokoll

In diesem Szenario werden alle Backend-Server als fehlerhaft gemeldet. Wenn Sie bestätigt haben, dass es keine Probleme mit den Backend-Servern gibt, haben Sie bei einem HTTP-Health Check möglicherweise einen Fehler beim Festlegen des Statuscodes gemacht. Er muss mit dem tatsächlichen Statuscode übereinstimmen, der vom Backend zurückgegeben wird. Eine typische Nichtübereinstimmung ist, wenn ein Backend einen 302-Statuscode zurückgibt, während ein 200-Statuscode erwartet wird. Dies wird häufig dadurch verursacht, dass das Backend Sie zu einer Anmeldeseite oder einem anderen Speicherort auf dem Server weiterleitet. Sie können das Backend entweder als erwarteten Code zurückgeben oder in der Health-Check-Konfiguration den Wert 302 verwenden.

Fehlermeldung: msg:invalid statusCode, statusCode:nnn,expected:200 (wobei nnn den tatsächlich zurückgegebenen Statuscode darstellt).

Falsches Muster des regulären Ausdrucks

In diesem Szenario werden alle Backend-Server als fehlerhaft gemeldet. Wenn Sie bestätigt haben, dass es keine Probleme mit den Backend-Servern gibt, haben Sie möglicherweise ein Muster für den regulären Ausdruck festgelegt, das nicht mit dem Body konsistent ist, 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.

Fehlermeldung: response match resulte: failed.

Falsch konfigurierte Sicherheitsregeln

In diesem Szenario werden alle oder einige Backend-Server als fehlerhaft gemeldet. Wenn Sie bestätigt haben, dass es keine Probleme mit den Backend-Servern gibt, haben Sie möglicherweise die Netzwerksicherheitsgruppen, Sicherheitslisten oder lokalen Firewall (wie Firewalld, iptables oder SELinux) falsch konfiguriert.

In diesem Szenario können Sie mit dem curl- oder netcat-Utility einen Test von einem System aus ausführen, das sich in demselben Subnetz und derselben Netzwerksicherheitsgruppe (NSG) wie die Load-Balancer-Instanz befindet: Beispiel: curl -i http://backend_ip_address/health TCP or nc -zvw3 backend_ip_address 443.

Lokale Firewalls können mit dem folgenden Befehl verifiziert werden: firewall-cmd --list-all --zone=public. Wenn die erwarteten Regeln in der Firewallkonfiguration fehlen, fügen Sie den erforderlichen Service hinzu. Beispiel: So fügen Sie HTTP-Port 80 hinzu:

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