Neues in API7 Enterprise 3.2.9: Verbesserte Health Check-Konfiguration

Einführung in die neuen Health-Check-Funktionen

In Version 3.2.9 von API7 Enterprise wurde das Konfigurationserlebnis für Health-Checks umfassend optimiert.

1. Zuvor verstreute Konfigurationselemente wurden logisch zusammengefasst, wie z. B. die Einstellungen für Sonden und die Kriterien für die Bestimmung gesunder und ungesunder Knoten, wodurch sie strukturierter wurden.

2. Einige abstrakte Konfigurationsnamen wurden in intuitivere und semantische Ausdrücke umgewandelt, sodass Benutzer relevante Parameter direkt über ein Formular eingeben können, wodurch die praktischen Auswirkungen der Konfigurationen klarer werden.

3. Während der Konfiguration von Upstream-Knoten und Health-Check-Prozessen wurden zusätzliche Hinweise hinzugefügt, um Benutzern zu helfen, die inhärente Verbindung zwischen Upstream-Knoten und Health-Checks besser zu verstehen, wodurch die Konfiguration einfacher wird.

Grundkonzepte von Health-Checks

In API7 Enterprise ist die Prioritätseinstellung von Upstream-Knoten eng mit den Mechanismen des Lastausgleichs und der Health-Checks verbunden. Wenn Benutzer mehrere Upstream-Knoten mit unterschiedlichen Prioritäten für das Gateway konfigurieren, priorisiert das Gateway während des Lastausgleichs die Knoten mit der höchsten Priorität. Das bedeutet, dass das Gateway den Datenverkehr weiterhin an diese Knoten leitet, solange die Knoten mit der höchsten Priorität gesund bleiben.

Nur wenn alle Knoten mit der höchsten Priorität aufgrund fehlgeschlagener Health-Checks als nicht verfügbar eingestuft werden, wird das Gateway automatisch herabgestuft und leitet den Datenverkehr an die nächsthöheren Upstream-Knoten weiter. Dieses Design gewährleistet eine effiziente Nutzung des Datenverkehrs und eine hohe Systemverfügbarkeit.

Es ist erwähnenswert, dass, wenn mehrere Prioritätsstufen von Upstream-Knoten im Dienst konfiguriert sind, aber die Health-Check-Funktion deaktiviert ist, alle Client-Anfragen immer an die Knoten mit der höchsten Priorität weitergeleitet werden, unabhängig von deren tatsächlichem Gesundheitszustand.

Konfigurationsmethoden für Health-Checks

Sondenkonfiguration

Eine Sonde wird verwendet, um die Lebendigkeit und den Dienststatus von Upstream-Knoten zu überprüfen. In APISIX ist die Sonde wie ein „Inspektor“, der regelmäßig an die Tür klopft, um zu überprüfen, ob der Upstream-Dienst ordnungsgemäß funktioniert. Wenn sie Probleme feststellt oder der Dienst „nicht verfügbar“ ist, informiert sie APISIX: „Dieser Dienst ist derzeit nicht verfügbar, also halte Anfragen hier zurück.“ Dieser „Türklopfen“-Prozess wird durch Sonden durchgeführt.

Die Sonde umfasst hauptsächlich die folgenden Konfigurationselemente:

• Sondenschema: Der Protokolltyp, der von der Health-Check-Sonde verwendet wird, unterstützt TCP, HTTP und HTTPS.

• Parallelität: Mit diesem Konfigurationselement können Sie die Anzahl der gleichzeitigen Health-Check-Anfragen festlegen. Mit anderen Worten, dies ist die Anzahl der Male, die Sie gleichzeitig „an die Tür klopfen“ möchten, um die Reaktionsfähigkeit der Upstream-Dienste zu überprüfen. Durch die Anpassung der Parallelität können Sie mögliche gleichzeitige Anfragen in realen Szenarien simulieren und so die Leistung und Stabilität der Upstream-Dienste besser bewerten.

• Host: Gibt die Host-Adresse des zu überprüfenden Upstream-Servers an. Dies ist wie die Bestimmung, an welches Haus Sie „an die Tür klopfen“ möchten.

• Port: Die Portnummer des Upstream-Dienstes. Es ist wie das Wissen, an welche Tür Sie während der Sonde klopfen müssen.

• Pfad: Wenn Sie eine HTTP-Sonde verwenden, gibt dieses Konfigurationselement den URL-Pfad an, den Sie zugreifen möchten. Es ist wie das Anweisen der Sonde, den genauen Raum zu überprüfen, sobald sie drinnen ist.

Kriterien für die Bestimmung gesunder Knoten

Bei der Bestimmung gesunder Knoten überprüft das System regelmäßig Knoten, die zuvor als ungesund markiert wurden, in dem vom Benutzer festgelegten Intervall (in Sekunden), um sicherzustellen, dass vorübergehende Knotenanomalien rechtzeitig erkannt und ordnungsgemäß behandelt werden.

Wenn die Sonde das TCP-Protokoll verwendet, wird der Knoten als gesund betrachtet, nachdem die Sonde die vom Benutzer festgelegte Anzahl von Verbindungen zum Upstream-Knoten erfolgreich hergestellt hat.

Wenn die Sonde das HTTP/HTTPS-Protokoll verwendet, betrachtet das System den Knoten nur dann als gesund, wenn er kontinuierlich Sondenanfragen mit bestimmten Statuscodes (wie 200 und 302) vom Knoten empfängt. Das bedeutet, dass der Knoten nur dann als ordnungsgemäß funktionierend betrachtet wird, wenn er kontinuierlich diese spezifischen Statuscodes zurückgibt.

Kriterien für die Bestimmung ungesunder Knoten

Bei der Bestimmung ungesunder Knoten ist die Konfigurationsmethode ähnlich wie bei der Bestimmung gesunder Knoten. Das System überprüft regelmäßig Knoten, die als gesund markiert wurden, in dem vom Benutzer festgelegten Intervall. Sobald diese Knoten die voreingestellten ungesunden Bedingungen erfüllen, werden sie erneut als ungesund klassifiziert.

Etwas anders als bei der Bestimmung gesunder Knoten wird während des Bestimmungsprozesses ungesunder Knoten ein zusätzliches Konfigurationselement, die Client-Anfrageüberprüfung, hinzugefügt. Wenn diese Funktion aktiviert ist, verlässt sich das Gateway nicht nur auf die Inspektionsergebnisse der Sonde, sondern beobachtet und analysiert auch tiefgehend Anfragen von Clients und die tatsächlichen Antworten von Upstream-Diensten. Basierend auf diesen Daten und benutzerdefinierten Beurteilungskriterien kann das Gateway den Betriebszustand der Upstream-Dienste genauer bewerten.

Best Practices für Health-Checks

Auswahl des geeigneten Sondentyps

• TCP-Sonde: Geeignet für Szenarien, bei denen nur bestätigt werden muss, ob der Dienstport geöffnet und zugänglich ist. Zum Beispiel kann ein Datenbankdienst nur eine TCP-Sonde benötigen, um die Portöffnung zu bestätigen.

• HTTP/HTTPS-Sonde: Eher geeignet für Szenarien, bei denen nicht nur die Netzwerkverbindung normal sein muss, sondern auch der Dienst Anfragen korrekt verarbeiten kann. Zum Beispiel benötigen wir für einen Webserver oder API-Dienst die Sicherstellung, dass er nicht nur Verbindungen empfangen, sondern auch korrekte Seiten oder Daten zurückgeben kann.

Angemessene Konfiguration von Health-Check-Parametern

Bei der Konfiguration von Health-Checks sollten mehrere Schlüsselparameter beachtet werden:

• Überprüfungsintervall: Es sollte nicht zu kurz sein, um unnötigen Overhead zu vermeiden, oder zu lang, um eine langsame Reaktion bei Problemen zu vermeiden. Zum Beispiel ist für eine Website mit hohem Datenverkehr wie ein E-Commerce-Shop ein Überprüfungsintervall von 30 Sekunden eine relativ vernünftige Wahl. Dieses Intervall verbraucht weder übermäßig Systemressourcen noch verzögert es die Erkennung und Behandlung von Problemen auf der Website.

  Natürlich ist dieses Intervall nicht absolut, und Anpassungen müssen basierend auf der tatsächlichen Situation der Website vorgenommen werden. Zum Beispiel, wenn die Website erhebliche Schwankungen im Datenverkehr aufweist oder während bestimmter Zeiträume (wie während Werbekampagnen) einen Anstieg des Datenverkehrs erlebt, kann es notwendig sein, das Überprüfungsintervall anzupassen, um diese Veränderungen zu berücksichtigen.

• Timeout: Die Zeit, die die Sonde auf eine Dienstantwort wartet. Wenn der Dienst innerhalb dieser Zeit nicht antwortet, betrachtet die Sonde den Dienst als ungesund. Dieser Wert sollte entsprechend der tatsächlichen Antwortzeit des Dienstes festgelegt werden.

• Wiederholungsanzahl: Die Anzahl der Versuche, die die Sonde unternimmt, bevor sie den Dienst als ungesund einstuft. Dieser Wert sollte moderat sein, um Fehlurteile zu vermeiden.

Anpassung der Strategien basierend auf dem Geschäft

Health-Check-Strategien sollten basierend auf der tatsächlichen Geschäftssituation angepasst werden. Wenn ein Dienst typischerweise während bestimmter Zeiträume hohe Lasten erfährt, können die Health-Check-Intervalle während dieser Zeiträume erhöht oder die Wiederholungsanzahl reduziert werden, um zusätzlichen Druck auf den Dienst zu vermeiden.

Aktivierung der Client-Anfrageüberprüfung nach Bedarf

Die Client-Anfrageüberprüfung kann den Dienststatus effektiv basierend auf tatsächlichen Geschäftsanfragen bestimmen, insbesondere für die Identifizierung von Problemen, die eng mit der Geschäftslogik verbunden sind. Sie ist jedoch möglicherweise nicht für jedes Geschäftsszenario geeignet.

1. Dienste mit geringem Datenverkehr: Wenn der Dienstverkehr gering ist, können passive Health-Checks basierend auf Client-Anfragen möglicherweise nicht genügend Datenpunkte liefern, um den Dienststatus genau zu bewerten. In solchen Fällen kann die Abhängigkeit von aktiven Sondenüberprüfungen zuverlässiger sein.

2. Leistungsüberlegungen in Umgebungen mit hoher Parallelität: Passive Health-Checks erfordern die Überwachung und Verarbeitung jeder Client-Anfrage, was in Umgebungen mit hoher Parallelität zusätzliche Leistungsbelastungen verursachen kann. Wenn die Leistung ein Hauptanliegen ist und der Dienst bereits durch andere Mittel ausreichend überwacht wurde, kann die passive Health-Check-Funktion in Betracht gezogen werden, um sie zu deaktivieren.

3. Vorhandensein anderer Überwachungssysteme: Wenn im Unternehmen bereits ausgereifte Überwachungssysteme eingesetzt wurden, die den Dienststatus in Echtzeit erfassen und analysieren können, sind passive Health-Checks möglicherweise nicht notwendig, um Datenredundanz und zusätzliche Komplexität zu vermeiden.

Fazit

Health-Checks sind ein entscheidender Aspekt, um die hohe Verfügbarkeit von API-Gateways sicherzustellen. In Version 3.2.9 von API7 Enterprise haben wir die interaktive Konfiguration von Health-Checks umfassend optimiert, wodurch die Bedienung vereinfacht und das Benutzererlebnis verbessert wurde.

Durch die ordnungsgemäße Konfiguration von Sonden, die Festlegung von Kriterien für gesunde und ungesunde Knoten und die Anpassung von Strategien basierend auf den tatsächlichen Geschäftsanforderungen können Benutzer den Status von Upstream-Diensten effektiver überwachen und sicherstellen, dass der Datenverkehr immer an gesunde Knoten weitergeleitet wird. Dies verbessert nicht nur die Stabilität und Verfügbarkeit des Systems, sondern stellt auch sicher, dass Benutzeranfragen zeitnah und korrekt beantwortet werden.