Oracle Cloud Infrastructure - Dokumentation

Häufige Nebenwirkungen einer Fehlkonfiguration von Health Checks bei Load Balancern

Erfahren Sie mehr über häufige Nebenwirkungen, die mit einer falschen Konfiguration der Health Checks des Load Balancers verbunden sind.

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 ein Port sein, der horcht und Traffic auf dem Backend zulässt.

    OCI-Loggingfehler: errno:EHOSTUNREACH, syscall:connect

  • Falscher Pfad

    In diesem Szenario werden alle Backend-Server als fehlerhaft gemeldet. Wenn die Backend-Server keine Probleme haben, haben Sie möglicherweise den Pfad für den HTTP-Health Check falsch festgelegt. Er muss mit einer tatsächlichen Anwendung im Backend übereinstimmen. In diesem Szenario können Sie das Utility curl verwenden, um von einem System im selben Netzwerk aus zu testen. Beispiel: $ curl -i http://backend_ip_address/health

    Sie erhalten den konfigurierten Statuscode in der Antwort im OCI-Loggingfehler: "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 Ihr Backend HTTPS, verwendet, müssen Sie TCP als Protokoll verwenden.

    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 gängiges Szenario ist, wenn ein Backend einen 302-Statuscode zurückgibt, Sie jedoch einen 200-Statuscode erwarten. 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 so korrigieren, dass der erwartete Code zurückgegeben wird, oder in der Health-Check-Konfiguration Code 302 verwenden.

    OCI-Loggingfehler: msg:invalid statusCode, statusCode:nnn,expected:200, wobei nnn der zurückgegebene Statuscode ist.

  • Falsches Regex-Muster

    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 aufweisen, haben Sie möglicherweise die Netzwerksicherheitsgruppen, Sicherheitslisten oder lokalen Firewalls wie firewalld, iptables oder SELinux falsch konfiguriert. In diesem Szenario können Sie mit dem Utility curl oder netcat einen Test von einem System aus durchführen, das demselben Subnetz und derselben Netzwerksicherheitsgruppe wie die Load-Balancer-Instanz angehört: Beispiel: $ curl -i http://backend_ip_address/health TCP und nc -zvw3 backend_ip_address 443.

Sie können die lokale Firewall mit dem folgenden Befehl prüfen: firewall-cmd --list-all --zone=public.. Wenn in Ihrer 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