Load-Balancing über Backend-Server

Diese Seite gilt für Apigee und Apigee Hybrid.

Apigee Edge-Dokumentation aufrufen

Apigee verbessert die Verfügbarkeit Ihrer APIs, indem es integrierte Unterstützung für Load-Balancing und Failover über mehrere Backend-Serverinstanzen bereitstellt.

TargetServer entkoppeln konkrete Endpunkt-URLs von TargetEndpoint-Konfigurationen. Anstatt eine konkrete URL in der Konfiguration zu definieren, können Sie einen oder mehrere benannte TargetServer konfigurieren. Anschließend wird in jedem TargetEndpunkt mit HTTPConnection auf den Namen verwiesen.

Videos

In den folgenden Videos erfahren Sie mehr über API-Routing und Load-Balancing mithilfe von Zielservern.

Video Beschreibung
Load-Balancing mithilfe von Zielservern Load-Balancing von APIs über mehrere Zielserver
API-Routing anhand der Umgebung mithilfe von Zielservern Leiten Sie eine API anhand der Umgebung an einen anderen Zielserver weiter.

Informationen zur TargetServer-Konfiguration

Eine TargetServer-Konfiguration besteht aus einem Namen, einem Host, einem Protokoll und einem Port mit einem zusätzlichen Element, das angibt, ob der TargetServer aktiviert oder deaktiviert ist.

Der folgende Code enthält ein Beispiel für eine TargetServer-Konfiguration:

{
  "name": "target1",
  "host": "1.mybackendservice.com",
  "protocol": "http",
  "port": "80",
  "isEnabled": "true"
}

Weitere Informationen zur TargetServer API finden Sie unter organizations.environments.targetservers.

Das Schema für TargetServer und andere Entitäten finden Sie auf GitHub.

TargetServers erstellen

Erstellen Sie TargetServers mithilfe der Apigee-Benutzeroberfläche oder der API, wie in den folgenden Abschnitten beschrieben.

Apigee in der Cloud Console

So erstellen Sie TargetServer mit Apigee in der Cloud Console:

  1. Melden Sie sich bei der Apigee-UI in der Cloud Console an.
  2. Wählen Sie Verwaltung > Umgebungen > TargetServers aus.
  3. Wählen Sie die Umgebung aus, in der Sie einen neuen TargetServer definieren möchten.
  4. Klicken Sie oben im Bereich auf Zielserver.
  5. Klicken Sie auf + Zielserver erstellen.

  6. Geben Sie einen Namen, einen Host, ein Protokoll und einen Port in die dafür vorgesehenen Felder ein. Die Optionen für Protokoll sind: HTTP für REST-basierte Zielserver, gRPC – Ziel für gRPC-basierte Zielserver und gRPC – Externer Callout. Weitere Informationen zur Unterstützung von gRPC-Proxys finden Sie unter gRPC-API-Proxys erstellen.

    Optional können Sie SSL aktivieren wählen. Weitere Informationen finden Sie unter Übersicht: SSL-Zertifikate.

  7. Klicken Sie auf Erstellen.

Klassisches Apigee

So erstellen Sie TargetServers mithilfe der klassischen Apigee-UI:

  1. Melden Sie sich bei der Apigee-UI an.
  2. Wählen Sie Verwaltung > Umgebungen > TargetServers aus.
  3. Wählen Sie in der Drop-down-Liste Umgebung die Umgebung aus, in der Sie einen neuen TargetServer definieren möchten.

    In der Apigee-Benutzeroberfläche wird eine Liste der aktuellen TargetServers in der ausgewählten Umgebung angezeigt:

    Liste der Zielserver

  4. Klicken Sie auf + Target Server, um einen neuen TargetServer zur ausgewählten Umgebung hinzuzufügen.

    Das Dialogfeld TargetServer hinzufügen wird angezeigt.

    Dialogfeld „Zielserver hinzufügen“

  5. Klicken Sie auf Aktiviert, um die neue TargetServer- Definition kurz nach ihrer Erstellung zu aktivieren.

  6. Geben Sie einen Namen, einen Host, ein Protokoll und einen Port in die dafür vorgesehenen Felder ein. Die Optionen für Protokoll sind HTTP oder GRPC.

    Optional können Sie das Kästchen SSL anklicken. Weitere Informationen zu diesen Feldern finden Sie unter TargetServer (4MV4D-Video).

  7. Klicken Sie auf Add.

    Apigee erstellt die neue TargetServer-Definition.

  8. Nachdem Sie einen neuen TargetServer erstellt haben, können Sie Ihren API-Proxy bearbeiten und das Element <HTTPTargetConnection> ändern, um auf die neue Definition zu verweisen.

Apigee API

In den folgenden Abschnitten finden Sie Beispiele für die Verwendung der Apigee API zum Erstellen und Auflisten von TargetServers.

Weitere Informationen finden Sie in der TargetServers API.

TargetServer mit der API in einer Umgebung erstellen

Verwenden Sie den folgenden API-Aufruf, um einen TargetServer namens target1 zu erstellen, der eine Verbindung zu 1.mybackendservice.com an Port 80 herstellt:

curl "https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers" \
  -X POST \
  -H "Content-Type:application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '
  {
  "name": "target1",
  "host": "1.mybackendservice.com",
  "protocol": "http",
  "port": "80",
  "isEnabled": "true",
  }'

Dabei ist $TOKEN auf Ihr OAuth 2.0-Zugriffstoken festgelegt. Weitere Informationen hierzu finden Sie unter OAuth 2.0-Zugriffstoken abrufen. Informationen zu den in diesem Beispiel verwendeten curl-Optionen finden Sie unter curl verwenden. Eine Beschreibung der verwendeten Umgebungsvariablen findet sich unter Umgebungsvariablen für Apigee API-Anfragen festlegen.

Im Folgenden finden Sie ein Beispiel für die Antwort:

{
  "host" : "1.mybackendservice.com",
  "protocol": "http",
  "isEnabled" : true,
  "name" : "target1",
  "port" : 80
}

Erstellen Sie mit dem folgenden API-Aufruf einen zweiten TargetServer. Indem Sie zwei TargetServer definieren, stellen Sie zwei URLs bereit, die ein TargetEndpoint für das Load-Balancing verwenden kann:

curl "https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers" \
  -X POST \
  -H "Content-Type:application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '
  {
  "name": "target2",
  "host": "2.mybackendservice.com",
  "protocol": "http",
  "port": "80",
  "isEnabled": "true",
  }'

Im Folgenden finden Sie ein Beispiel für die Antwort:

{
  "host" : "2.mybackendservice.com",
  "protocol": "http",
  "isEnabled" : true,
  "name" : "target2",
  "port" : 80
}

TargetServers mithilfe der API in einer Umgebung auflisten

Verwenden Sie den folgenden API-Aufruf, um die TargetServers in einer Umgebung aufzulisten:

curl https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers \
  -H "Authorization: Bearer $TOKEN"

Im Folgenden finden Sie ein Beispiel für die Antwort:

[ "target2", "target1" ]

Es sind jetzt zwei TargetServers für die Verwendung durch API Proxies verfügbar, die bereitgestellt in der test-Umgebung. Für das Verteilen des Traffics via Load-Balancing auf diese TargetServers konfigurieren Sie die HTTP-Verbindung im Zielendpunkt eines API-Proxys für die Verwendung der TargetServers.

TargetEndpoint für das Load-Balancing über benannte TargetServers hinweg konfigurieren

Da jetzt zwei TargetServers verfügbar sind, können Sie die TargetEndpoint-HTTP-Verbindungseinstellung so ändern, dass auf die zwei TargetServer anhand des Namens verwiesen wird:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
    <LoadBalancer>
      <Server name="target1" />
      <Server name="target2" />
    </LoadBalancer>
    <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

Die oben genannte Konfiguration ist die einfachste Load-Balancing-Konfiguration. Der Load-Balancer unterstützt drei Load-Balancing-Algorithmen: Round Robin, Weighted und Least Connection. Round Robin ist der Standardalgorithmus. Da in der obigen Konfiguration kein Algorithmus angegeben ist, werden ausgehende Anfragen vom API-Proxy an die Backend-Server abwechselnd zwischen target1 und target2 ausgetauscht, eine nach der anderen.

Das <Path> -Element bildet den Basispfad des TargetEndpoint-URI für alle TargetServers. Es wird nur verwendet, wenn <LoadBalancer> verwendet wird. Andernfalls wird es ignoriert. Im obigen Beispiel lautet eine Anfrage für target1 so: http://target1/test. Anfragen an ander TargetServers sind äquivalent.

Weitere Informationen finden Sie unter TargetEndpoint auf Ihrem Mobilgerät.

Load-Balancer-Optionen konfigurieren

Sie können die Verfügbarkeit optimieren, indem Sie die Optionen für Load-Balancing und Failover auf der Ebene des Load-Balancers und der TargetServer-Ebene konfigurieren. Dies wird in den folgenden Abschnitten beschrieben.

Algorithmus

Legt den von <LoadBalancer> verwendeten Algorithmus fest. Die verfügbaren Algorithmen sind RoundRobin, Weighted und LeastConnections, die jeweils unten dokumentiert sind.

Round-Robin

Der Standardalgorithmus Round Robin leitet eine Anfrage an jeden TargetServer in der Reihenfolge weiter, in der die Server in der HTTP-Verbindung des Zielendpunkts aufgeführt sind. Beispiel:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

Gewichtet

Der gewichtete Load-Balancing-Algorithmus ermöglicht die Konfiguration proportionaler Traffic-Lasten für Ihre Zielserver. Der gewichtete LoadBalancer verteilt die Anfragen an Ihre Zielserver direkt auf die Gewichtung der einzelnen TargetServer. Daher muss beim gewichteten Algorithmus für jeden TargetServer ein weight-Attribut festgelegt werden. Beispiel:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
    <LoadBalancer>
      <Algorithm>Weighted</Algorithm>
      <Server name="target1">
        <Weight>1</Weight>
      </Server>
      <Server name="target2">
        <Weight>2</Weight>
      </Server>
    </LoadBalancer>
    <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

In diesem Beispiel werden für jede an target1 weitergeleitete Anfrage zwei Anfragen an target2 weitergeleitet.

Mindestverbindung

LoadBalancer, die für die Verwendung des Mindestverbindungsalgorithmus konfiguriert sind, leiten ausgehende Anfragen an den TargetServer mit den wenigsten offenen HTTP-Verbindungen weiter. Beispiel:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>LeastConnections</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
      </LoadBalancer>
  </HTTPTargetConnection>
  <Path>/test</Path>
</TargetEndpoint>

Maximale Fehlschläge

Die maximale Anzahl fehlgeschlagener Anfragen vom API-Proxy an den TargetServer, die dazu führen, dass die Anfrage an einen anderen TargetServer weitergeleitet wird.

Ein Antwortfehler bedeutet, dass Apigee keine Antwort von einem TargetServer empfängt. In diesem Fall wird der Fehlerzähler um eins erhöht.

Wenn Apigee jedoch eine Antwort von einem Ziel erhält, selbst wenn es sich bei der Antwort um einen HTTP-Fehler (wie z. B. 500) handelt, zählt dies als Antwort vom TargetServer, und der Fehlerzähler wird zurückgesetzt. Um sicherzustellen, dass HTTP-Fehler-Antworten (z. B. 500) auch den Fehlerzähler schrittweise erhöhen, damit ein fehlerhafter Server so schnell wie möglich aus der Load-Balancing-Rotation herausgenommen wird, können Sie das Element <ServerUnhealthyResponse> mit untergeordneten <ResponseCode> Elementen zu Ihrer Load-Balancing-Konfiguration hinzufügen. Apigee zählt außerdem Antworten mit diesen Codes als Fehler.

Im folgenden Beispiel wird target1 nach fünf fehlgeschlagenen Anfragen aus der Rotation entfernt, einschließlich einiger 5XX-Antworten des TargetServer.

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <MaxFailures>5</MaxFailures>
        <ServerUnhealthyResponse>
            <ResponseCode>500</ResponseCode>
            <ResponseCode>502</ResponseCode>
            <ResponseCode>503</ResponseCode>
        </ServerUnhealthyResponse>
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

Der Standardwert von MaxFailures ist 0. Das bedeutet, dass Apigee immer versucht, für jede Anfrage eine Verbindung zum Ziel herzustellen, und entfernt den TargetServer niemals aus der Rotation.

Es empfiehlt sich, MaxFailures > 0 mit einem HealthMonitor zu verwenden. Wenn Sie MaxFailures > 0 konfigurieren, wird der TargetServer aus der Rotation entfernt, wenn das Ziel die Anzahl der von Ihnen angegebenen Häufigkeiten nicht erreicht. Wenn ein HealthMonitor eingerichtet ist, setzt Apigee automatisch den TargetServer wieder in die Rotation, nachdem das Ziel wieder ausgeführt wird, gemäß der Konfiguration dieses HealthMonitors. Weitere Informationen finden Sie unter Statusüberwachung.

Wenn Sie hingegen MaxFailures > 0 konfigurieren und keinen HealthMonitor konfigurieren, entfernt Apigee den TargetServer automatisch aus der Rotation, wenn der erste Fehler erkannt wird. Apigee prüft den Status des TargetServers alle fünf Minuten und setzt ihn in die Rotation zurück, wenn er normal reagiert.

Wiederholen

Wenn „Wiederholen” aktiviert ist, wird eine Anfrage wiederholt, wenn ein Antwortfehler (E/A-Fehler oder HTTP-Zeitüberschreitung) auftritt oder die empfangene Antwort mit einem Wert übereinstimmt, der durch <ServerUnhealthyResponse> festgelegt wurde. Weitere Informationen zum Festlegen von <ServerUnhealthyResponse> finden Sie oben unter Maximale Fehler.

Standardmäßig ist <RetryEnabled> auf true festgelegt. Setzen Sie diesen Wert auf false, um die Wiederholung zu deaktivieren. Beispiel:

<RetryEnabled>false</RetryEnabled>

IsFallback

Ein (und nur ein) TargetServer kann als Fallback-Server festgelegt werden. Der Fallback-TargetServer ist erst in den Load-Balancing-Routinen enthalten, bis alle anderen TargetServer als vom Load-Balancer als nicht verfügbar gekennzeichnet sind. Wenn der Load-Balancer feststellt, dass alle TargetServer nicht verfügbar sind, wird der gesamte Traffic zum Fallback-Server weitergeleitet. Beispiel:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <Server name="target3">
          <IsFallback>true</IsFallback>
        </Server>
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

Die obige Konfiguration führt zu einem runden Robin-Load-Balancing zwischen target1 und target2, bis target1 und target2 nicht verfügbar sind. Wenn target1 und target2 nicht verfügbar sind, wird der gesamte Traffic an target3 weitergeleitet.

Pfad

Der Pfad definiert ein URI-Fragment, das an alle Anfragen vom TargetServer an den Backend-Server angehängt wird.

Dieses Element akzeptiert einen Stringliteralpfad oder eine Nachrichtenvorlage. Mit einer Nachrichtenvorlage können Sie zur Laufzeit eine variable Stringsubstitution durchführen. In der folgenden Zielendpunktdefinition wird beispielsweise der Wert von {mypath} für den Pfad verwendet:

<HTTPTargetConnection>
    <SSLInfo>
      <Enabled>true</Enabled>
    </SSLInfo>
    <LoadBalancer>
      <Server name="testserver"/>
    </LoadBalancer>
    <Path>{mypath}</Path>
</HTTPTargetConnection>

TargetServer für TLS/SSL konfigurieren

Wenn Sie den Backend-Dienst mit einem TargetServer definieren und der Backend-Dienst erfordert, dass die Verbindung das HTTPS-Protokoll verwendet, müssen Sie TLS/SSL in der TargetServer-Definition aktivieren. Dies ist erforderlich, da das Verbindungsprotokoll mit dem Tag host nicht angegeben werden kann. Im Folgenden sehen Sie die TargetServer-Definition für das One-Way-TLS/SSL, bei dem Apigee HTTPS-Anfragen an den Backend-Dienst stellt:

{
  "name": "target1",
  "host": "mocktarget.apigee.net",
  "protocol": "http",
  "port": "443",
  "isEnabled": "true",
  "sSLInfo": {
    "enabled": "true"
  }
}

Wenn der Backend-Dienst bidirektionales oder gegenseitiges TLS/SSL erfordert, konfigurieren Sie den TargetServer mit denselben Konfigurationseinstellungen für TLS/SSL wie TargetEndpoints:

{
  "name": "TargetServer 1",
  "host": "www.example.com",
  "protocol": "http",
  "port": "443",
  "isEnabled": "true",
  "sSLInfo": {
    "enabled": "true",
    "clientAuthEnabled": "true",
    "keyStore": "keystore-name",
    "keyAlias": "keystore-alias",
    "trustStore": "truststore-name",
    "ignoreValidationErrors": "false",
    "ciphers": []
  }
}

So erstellen Sie einen TargetServer mit SSL mithilfe eines API-Aufrufs: 

curl "https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers" \
  -X POST \
  -H "Content-Type:application/json"  \
  -H "Authorization: Bearer $TOKEN" \
  -d '
  {
    "name": "TargetServer 1",
    "host": "www.example.com",
    "protocol": "http",
    "port": 443,
    "isEnabled": true,
    "sSLInfo":
    {
      "enabled":true,
      "clientAuthEnabled":true,
      "keyStore":"keystore-name",
      "keyAlias":"keystore-alias",
      "ciphers":[],
      "protocols":[],
      "clientAuthEnabled":true,
      "ignoreValidationErrors":false,
      "trustStore":"truststore-name"
    }
  }'

Statusüberwachung

Mit Statusüberwachung können Sie die Load-Balancing-Konfigurationen optimieren, indem Sie aktiv die in den TargetServer-Konfigurationen definierten Backend-Dienst-URLs abfragen. Bei aktiviertem Statusüberwachung werden Target-Server, die nicht erreichbar sind oder eine Fehlerantwort zurückgeben, als fehlerhaft markiert. Ein fehlgeschlagener TargetServer wird automatisch wieder in die Rotation zurückgeführt, wenn HealthMonitor feststellt, dass der TargetServer aktiv ist. Es sind keine erneuten Bereitstellungen für den Proxy erforderlich.

Sie müssen

HealthMonitor fungiert als einfacher Client, der einen Backend-Dienst über TCP oder HTTP aufruft:

  • Ein TCP-Client stellt lediglich sicher, dass ein Socket geöffnet werden kann.
  • Sie konfigurieren den HTTP-Client so, dass er eine gültige HTTP-Anfrage an den Backend-Dienst sendet. Sie können HTTP-GET-, PUT-, POST- oder DELETE-Vorgänge definieren. Die Antwort des HTTP-Monitoring-Aufrufs muss mit den konfigurierten Einstellungen im Block <SuccessResponse> übereinstimmen.

Erfolge und Fehler

Wenn Sie die Statusüberwachung aktivieren, sendet Apigee Systemdiagnosen an Ihren Zielserver. Eine Systemdiagnose ist eine Anfrage, die an den TargetServer gesendet wird und bestimmt, ob der TargetServer fehlerfrei ist oder nicht.

Eine Systemdiagnose kann eines von zwei möglichen Ergebnissen haben:

  • Erfolg:Der TargetServer wird bei einer erfolgreichen Systemdiagnose als fehlerfrei erachtet. Dies ist in der Regel das Ergebnis eines oder mehrerer der Folgenden:
    • TargetServer akzeptiert eine neue Verbindung zum angegebenen Port, antwortet auf eine Anfrage an diese Port und schließt dann den Port innerhalb des angegebenen Zeitraums. Die Antwort von TargetServer enthält Connection: close.
    • TargetServer antwortet auf eine Systemdiagnosenanfrage mit einem HTTP-Statuscode 200 (OK) oder einem anderen HTTP-Statuscode, der von Ihnen als akzeptabel eingestuft wird.
    • TargetServer reagiert auf eine Systemdiagnoseanfrage mit einem Nachrichtentext, der dem erwarteten Nachrichtentext entspricht.

    Wenn Apigee feststellt, dass ein Server fehlerfrei ist, setzt Apigee das Senden von Anfragen an den Server fort.

  • Fehler: Die Systemdiagnose des TargetServers kann je nach Diagnosetyp auf unterschiedliche Weise fehlschlagen. Ein Fehler kann protokolliert werden, wenn der TargetServer:
    • Eine Verbindung von Apigee zum Systemdiagnose-Port verweigert.
    • Nicht auf eine Systemdiagnoseanfrage innerhalb eines bestimmten Zeitraums antwortet.
    • Einen unerwarteten HTTP-Statuscode zurückgibt.
    • Mit einem Nachrichtentext antwortet, der nicht dem erwarteten Nachrichtentext entspricht.

    Wenn ein TargetServer eine Systemdiagnose nicht besteht, erhöht Apigee den Fehlerzähler dieses Servers. Wenn die Anzahl der Fehler für diesen Server einen vordefinierten Schwellenwert (<MaxFailures>) erreicht oder übersteigt, stoppt Apigee das Senden von Anfragen an diesen Server.

HealthMonitor aktivieren

Zum Erstellen eines HealthMonitors fügen Sie das Element <HealthMonitor> der HTTPConnection-Konfiguration des TargetEndpoints für einen Proxy hinzu. Auf der UI ist das nicht möglich. Erstellen Sie stattdessen eine Proxykonfiguration und laden Sie sie als ZIP-Datei in Apigee hoch. Eine Proxykonfiguration ist eine strukturierte Beschreibung aller Aspekte eines API-Proxys. Proxykonfigurationen bestehen aus XML-Dateien in einer vordefinierten Verzeichnisstruktur. Weitere Informationen finden Sie unter Referenz zur API-Proxy-Konfiguration.

Mit einem einfachen HealthMonitor wird ein IntervalInSec definiert, das entweder mit ein TCPMonitor oder mit ein HTTPMonitor kombiniert wird. Das <MaxFailures>-Element gibt die maximale Anzahl fehlgeschlagener Anfragen vom API-Proxy an den TargetServer an, die bewirkt, dass die Anfrage an einen anderen TargetServer weitergeleitet wird. <MaxFailures> ist standardmäßig 0, was bedeutet, dass Apigee keine Korrekturmaßnahme durchführt. Achten Sie beim Konfigurieren einer HealthMonitor darauf, dass Sie <MaxFailures> im Tag <HTTPTargetConnection> des Tags <TargetEndpoint> auf einen Wert ungleich null setzen.

TCPMonitor

Die folgende Konfiguration definiert einen HealthMonitor, das jeden TargetServer abfragt, indem alle fünf Sekunden eine Verbindung zu Port 80 hergestellt wird. (Port ist optional. Wenn nicht angegeben, ist der TCPMonitor-Port der TargetServer-Port.)

  • Wenn die Verbindung fehlschlägt oder die Verbindung länger als zehn Sekunden zum verbinden braucht, erhöht sich der Fehlerzähler für diesen TargetServer um 1.
  • Ist die Verbindung erfolgreich, wird der Fehlerzähler für den TargetServer auf 0 zurückgesetzt.

Sie können ein HealthMonitor als untergeordnetes Element des HTTPTargetConnection-Elements des TargetEndpoint hinzufügen, wie unten gezeigt:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <MaxFailures>5</MaxFailures>
      </LoadBalancer>
      <Path>/test</Path>
      <HealthMonitor>
        <IsEnabled>true</IsEnabled>
        <IntervalInSec>5</IntervalInSec>
        <TCPMonitor>
            <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
            <Port>80</Port>
        </TCPMonitor>
      </HealthMonitor>
  </HTTPTargetConnection>
</TargetEndpoint>

HealthMonitor mit TCPMonitor-Konfigurationselementen

In der folgenden Tabelle werden die TCPMonitor-Konfigurationselemente beschrieben:

Name Beschreibung Default Erforderlich/Optional?
IsEnabled Ein boolescher Wert zur Aktivierung oder Deaktivierung von HealthMonitor falsch Nein
IntervalInSec Das Zeitintervall in Sekunden zwischen den einzelnen TCP-Abfrageanfragen. 0 Ja
ConnectTimeoutInSec Zeit, in der eine Verbindung zum TCP-Port hergestellt werden muss, um als Erfolg zu gelten. Wenn keine Verbindung im angegebenen Intervall hergestellt wird, zählt dies als Fehler und erhöht den Fehlerzähler des Load-Balancers für den TargetServer. 0 Ja
Port Optional: Der Port, über den die TCP-Verbindung hergestellt wird. Wenn nicht angegeben, ist der TCPMonitor-Port der TargetServer-Port. 0 Nein

HTTPMonitor

Ein Beispiel für HealthMonitor, das einen HTTPMonitor verwendet, sendet alle fünf Sekunden eine GET-Anfrage an den Backend-Dienst. Das folgende Beispiel fügt der Anfrage einen HTTP-Basisauthentifizierungs-Header hinzu. Die Antwortkonfiguration definiert Einstellungen, die mit der tatsächlichen Antwort vom Backend-Dienst verglichen werden. Im folgenden Beispiel ist die erwartete Antwort ein HTTP-Antwortcode 200 und ein benutzerdefinierter HTTP-Header ImOK, dessen Wert YourOK ist. Wenn die Antwort nicht übereinstimmt, wird die Anfrage von der Konfiguration des Load-Balancers als Fehler behandelt.

HTTPMonitor unterstützt Backend-Dienste, die für die Verwendung von HTTP- und One-Way-HTTPS-Protokollen konfiguriert sind. Eine bidirektionale HTTPS, die auch als bidirektionale TLS/SSL oder selbst signierte Zertifikate bekannt ist, wird jedoch nicht unterstützt.

Beachten Sie, dass alle Einstellungen für Anfragen und Antworten in einem HTTPMonitor spezifisch für den Backend-Dienst sind, der aufgerufen werden muss.

    <TargetEndpoint name="default">
      <HTTPTargetConnection>
        <LoadBalancer>
          <Algorithm>RoundRobin</Algorithm>
          <Server name="target1" />
          <Server name="target2" />
          <MaxFailures>5</MaxFailures>
        </LoadBalancer>
        <Path>/test</Path>
        <HealthMonitor>
          <IsEnabled>true</IsEnabled>
          <IntervalInSec>5</IntervalInSec>
          <HTTPMonitor>
            <Request>
              <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
              <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
              <Port>80</Port>
              <Verb>GET</Verb>
              <Path>/healthcheck</Path>
              <Header name="Authorization">Basic 12e98yfw87etf</Header>
              <IncludeHealthCheckIdHeader>true</IncludeHealthCheckIdHeader>
            </Request>
            <SuccessResponse>
              <ResponseCode>200</ResponseCode>
              <Header name="ImOK">YourOK</Header>
            </SuccessResponse>
          </HTTPMonitor>
        </HealthMonitor>
      </HTTPTargetConnection>
    </TargetEndpoint>

<HTTPMonitor>-Konfigurationselemente

In der folgenden Tabelle werden die übergeordneten <HTTPMonitor>-Konfigurationselemente beschrieben:

Name Beschreibung Default Erforderlich/Optional?
IsEnabled Ein boolescher Wert zur Aktivierung oder Deaktivierung von HealthMonitor falsch Nein
IntervalInSec Das Zeitintervall in Sekunden zwischen den einzelnen Abfrageanfragen. 0 Ja

<HTTPMonitor>/<Request>-Konfigurationselemente

Konfigurationsoptionen für die ausgehende Anfragenachricht, die von HealthMonitor an die TargetServers in der Rotation gesendet wird. Beachten Sie, dass <Request> ein erforderliches Element ist.

Name Beschreibung Default Erforderlich/Optional?
ConnectTimeoutInSec Zeit in Sekunden, in der der TCP-Verbindungs-Handshake mit dem HTTP-Dienst geschehen muss, um als Erfolg zu gelten. Wenn keine Verbindung im angegebenen Intervall hergestellt wird, zählt dies als Fehler und erhöht den Fehlerzähler des Load-Balancers für den TargetServer. 0 Nein
SocketReadTimeoutInSec Zeit in Sekunden, in der Daten aus dem HTTP-Dienst gelesen werden müssen, damit dies als Erfolg gilt. Wenn nicht gelesen wird im angegebenen Intervall, zählt dies als Fehler und erhöht den Fehlerzähler des Load-Balancers für den TargetServer. 0 Nein
Port Der Port, über den die HTTP-Verbindung zum Backend-Dienst hergestellt wird. Zielserverport Nein
Verb Das HTTP-Verb, das für jede HTTP-Pollinganfrage an den Backend-Dienst verwendet wird. – Nein
Path Pfad, der an die URL angehängt ist, die im TargetServer definiert ist. Verwenden Sie das Element Path, um einen „Abfrage-Endpunkt” für Ihren HTTP-Dienst zu konfigurieren. Beachten Sie, dass das Path-Element keine Variablen unterstützt. – Nein

IncludeHealthCheckIdHeader

 Hiermit können Sie die Systemdiagnoseanfragen auf vorgelagerten Systemen verfolgen. Für IncludeHealthCheckIdHeader wird ein boolescher Wert verwendet, der standardmäßig false ist. Wenn Sie true festlegen, wird ein Header namens X-Apigee-Healthcheck-Id in die Systemdiagnoseanfrage eingefügt. Der Wert des Headers wird dynamisch zugewiesen und hat die Form ORG/ENV/SERVER_UUID/N, wobei ORG der Organisationsname und ENV der Umgebungsname. SERVER_UUID ist eine eindeutige ID, die den MP identifiziert. N ist die Anzahl der seit dem 1. Januar 1970 verstrichenen Millisekunden.

Beispiel für einen resultierenden Anfrageheader:

X-Apigee-Healthcheck-Id: orgname/envname/E8C4D2EE-3A69-428A-8616-030ABDE864E0/1586802968123 		falsch Nein
Payload Der für jede abzufragende HTTP-Anfrage generierte HTTP-Text. Beachten Sie, dass dieses Element für GET-Anfragen nicht erforderlich ist. – Nein

<HTTPMonitor>/<SuccessResponse>-Konfigurationselemente

(Optional) Übereinstimmungsoptionen für die eingehende HTTP-Antwortnachricht, die vom abgefragten Backend-Dienst generiert wurde Antworten, die nicht übereinstimmen, erhöhen den Fehlerzähler um 1.

Name Beschreibung Default Erforderlich/Optional?
ResponseCode Der HTTP-Antwortcode, der vom abgefragten TargetServer erwartet wird. Ein anderer Code als der angegebene Code führt zu einem Fehler und der Zähler wird für den abgefragten Backend-Dienst erhöht. Sie können mehrere ResponseCode-Elemente definieren. – Nein
Headers Eine Liste mit einem oder mehreren HTTP-Headern und -Werten, die vom abgefragten Backend-Dienst empfangen werden sollten. HTTP-Header oder -Werte, die sich von den angegebenen Werten unterscheiden, führen zu einem Fehler und die Anzahl für den abgefragten TargetServer wird um 1 erhöht. Sie können mehrere Header-Elemente definieren. – Nein