Load-Balancing über Back-End-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.

Zielserver entkoppeln konkrete Endpunkt-URLs von Zielendpunkt-Konfigurationen. Anstatt eine konkrete URL in der Konfiguration zu definieren, können Sie einen oder mehrere benannte Zielserver 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 Zielserver-Konfiguration

Eine Zielserver-Konfiguration besteht aus einem Namen, einem Host, einem Protokoll und einem Port mit einem zusätzlichen Element, das angibt, ob der Zielserver aktiviert oder deaktiviert ist. Ein Zielserver kann auch ein optionales <sSLInfo>-Objekt haben.

Der folgende Code enthält ein Beispiel für eine Zielserver-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.

Zielserver erstellen

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

Apigee in der Cloud Console

So erstellen Sie Zielserver mit Apigee in der Cloud Console:

Melden Sie sich in der Apigee-UI in der Cloud Console an.
Wählen Sie Verwaltung > Umgebungen aus.
Wählen Sie die Umgebung aus, in der Sie einen neuen Zielserver definieren möchten.
Klicken Sie oben im Bereich auf Zielserver.
Klicken Sie auf + Zielserver erstellen.
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.
Klicken Sie auf Erstellen.

Klassisches Apigee

So erstellen Sie Zielserver mithilfe der klassischen Apigee-UI:

Melden Sie sich bei der Apigee-UI an.
Wählen Sie Verwaltung > Umgebungen > TargetServers aus.
Wählen Sie in der Drop-down-Liste Umgebung die Umgebung aus, in der Sie einen neuen Zielserver definieren möchten.
In der Apigee-Benutzeroberfläche wird eine Liste der aktuellen Zielserver in der ausgewählten Umgebung angezeigt:
Klicken Sie auf + Target Server, um einen neuen Zielserver zur ausgewählten Umgebung hinzuzufügen.
Das Dialogfeld TargetServer hinzufügen wird angezeigt.
Klicken Sie auf Aktiviert, um den neuen Zielserver zu aktivieren. Definition kurz nach ihrer Erstellung zu aktivieren.
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).
Klicken Sie auf Hinzufügen.
Apigee erstellt die neue Zielserver-Definition.
Nachdem Sie einen neuen Zielserver 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 Zielservern.

Zielserver mit der API in einer Umgebung erstellen
Zielserver mithilfe der API in einer Umgebung auflisten

Weitere Informationen finden Sie in der TargetServers API.

Zielserver mit der API in einer Umgebung erstellen

Verwenden Sie den folgenden API-Aufruf, um einen Zielserver 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 Zielserver. Indem Sie zwei Zielserver definieren, stellen Sie zwei URLs bereit, die ein Ziel-Endpoint 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
}

Zielserver mithilfe der API in einer Umgebung auflisten

Verwenden Sie den folgenden API-Aufruf, um die Zielserver 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 Zielserver für die Verwendung durch API Proxies verfügbar, die in der test-Umgebung bereitgestellt werden. Für das Verteilen des Traffics via Load-Balancing auf diese Zielserver konfigurieren Sie die HTTP-Verbindung im Zielendpunkt eines API-Proxys für die Verwendung der Zielserver.

Zielendpunkt für das Load-Balancing über benannte Zielserver hinweg konfigurieren

Da jetzt zwei Zielserver verfügbar sind, können Sie das Element <HTTPTargetConnection> des Zielendpunkts so ändern, dass auf diese beiden Zielserver 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 Zielendpunkt-URI für alle Zielserver. 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 andere Zielserver 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 Zielserver-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 Zielserver 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 Zielserver. Daher muss beim gewichteten Algorithmus für jeden Zielserver 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 Zielserver 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 Zielserver, die dazu führen, dass die Anfrage an einen anderen Zielserver weitergeleitet wird.

Ein Antwortfehler bedeutet, dass Apigee keine Antwort von einem Zielserver 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. 404 oder 500) handelt, zählt dies als Antwort vom Zielserver, und der Fehlerzähler wird zurückgesetzt. Um dafür zu sorgen, 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 404 und einiger 5XX-Antworten des Zielservers.

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <MaxFailures>5</MaxFailures>
        <ServerUnhealthyResponse>
            <ResponseCode>404</ResponseCode>
            <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 Zielserver niemals aus der Rotation.

Es empfiehlt sich, MaxFailures > 0 mit einem HealthMonitor zu verwenden. Wenn Sie MaxFailures > 0 konfigurieren, wird der Zielserver 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 Zielserver 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 Zielserver automatisch aus der Rotation, wenn der erste Fehler erkannt wird. Apigee prüft den Status des Zielserver 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) Zielserver kann als Fallback-Server festgelegt werden. Der Fallback-Zielserver wird erst dann in die Load Balancing-Routinen einbezogen, wenn alle anderen Zielserver vom Load Balancer als nicht verfügbar erkannt wurden. Wenn der Load-Balancer feststellt, dass keiner der Zielserver verfügbar ist, 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.

Wenn der Fallback-Server fehlerhaft ist, leitet Apigee keinen Traffic an ihn weiter. Stattdessen wird bei API-Aufrufen der Fehler 503 "Der Dienst ist vorübergehend nicht verfügbar" zurückgegeben.

Pfad

Der Pfad definiert ein URI-Fragment, das an alle Anfragen vom Zielserver 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>

Zielserver für TLS/SSL konfigurieren

Wenn Sie den Back-End-Dienst mit einem Zielserver definieren und der Back-End-Dienst erfordert, dass die Verbindung das HTTPS-Protokoll verwendet, müssen Sie TLS/SSL in der Zielserver-Definition aktivieren. Dies ist erforderlich, da das Verbindungsprotokoll mit dem Tag host nicht angegeben werden kann.

Hinweis: Wenn Sie den Block sSLInfo sowohl im Zielendpunkt als auch in der Zielserver-Definition definieren, hat der Block im Zielserver Vorrang.

One-Way-TLS/SSL konfigurieren

Verwenden Sie die folgende Konfiguration, um einen Zielserver mit One-Way-TLS/SSL zu definieren. In diesem Beispiel stellt Apigee HTTPS-Anfragen an den Backend-Dienst:

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

Strikte SSL-Erzwingung konfigurieren

Um die strenge SSL-Erzwingung in der Zielserverdefinition anzugeben, legen Sie enforce im Block sSLInfo auf true fest, wie im folgenden Beispiel gezeigt:

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

Bidirektionales TLS/SSL konfigurieren

Wenn der Back-End-Dienst bidirektionales oder gegenseitiges TLS/SSL erfordert, können Sie den Zielserver mit denselben Konfigurationseinstellungen für TLS/SSL wie Zielendpunkte konfigurieren:

{
  "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": []
  }
}

Striktes SSL mithilfe der API konfigurieren

So erstellen Sie einen Zielserver mit strenger SSL-Erzwingung über einen API-Aufruf:

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,
      "enforce":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 Zielserver-Konfigurationen definierten Back-End-Dienst-URLs abfragen. Bei aktivierter Statusüberwachung werden Zielserver, die nicht erreichbar sind oder eine Fehlerantwort zurückgeben, als fehlerhaft markiert. Ein fehlgeschlagener Zielserver wird automatisch wieder in die Rotation zurückgeführt, wenn HealthMonitor feststellt, dass der Zielserver aktiv ist. Es sind keine erneuten Bereitstellungen für den Proxy erforderlich.

Sie müssen <MaxFailures> auf größer als 0 festlegen, wenn Sie einen HealthMonitor verwenden. Wenn der Wert <MaxFailures> auf 0 gesetzt ist, versucht Apigee immer, für jede Anfrage eine Verbindung zum Ziel herzustellen, und entfernt den Zielserver nicht aus der Rotation.

Eine Systemdiagnose 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 Zielserver gesendet wird und bestimmt, ob der Zielserver fehlerfrei ist oder nicht.

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

Erfolg: Der Zielserver wird bei einer erfolgreichen Systemdiagnose als fehlerfrei erachtet. Dies ist in der Regel das Ergebnis eines oder mehrerer der Folgenden:
- Der Zielserver akzeptiert eine neue Verbindung zum angegebenen Port, antwortet auf eine Anfrage an diesen Port und schließt dann den Port innerhalb des angegebenen Zeitraums. Die Antwort vom Zielserver enthält Connection: close.
- Der Zielserver antwortet auf eine Anfrage zur Systemdiagnose mit 200 (OK) oder einem anderen HTTP-Statuscode, der von Ihnen als akzeptabel eingestuft wird.
- Der Zielserver antwortet 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 Zielservers kann je nach Diagnosetyp auf unterschiedliche Weise fehlschlagen. Ein Fehler kann protokolliert werden, wenn der Zielserver:
- 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 Zielserver 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 einer Systemdiagnose für einen API-Proxy fügen Sie das Element <HealthMonitor> der <HTTPTargetConnection-Elementkonfiguration des Zielendpunkts für den Proxy hinzu.

Systemdiagnosen können nicht in der Benutzeroberfläche erstellt werden. 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.

`<HealthMonitor>`-Konfigurationselemente

In der folgenden Tabelle werden die <HealthMonitor>-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- oder HTTP-Abfrageanfragen.	0	Ja
`HTTPMonitor` oder `TCPMonitor`	Eine Definition des TCP- oder HTTP-Clients, der zum Abfragen des Zielservers verwendet werden soll.	–	Ja

Zusätzlich zu diesen Elementen müssen Sie zum Aktivieren einer Systemdiagnose das Element <MaxFailures> im Block <HTTPTargetConnection> des Elements <TargetEndpoint> auf einen Wert größer als 0 setzen. <MaxFailures> wird verwendet, um die maximale Anzahl fehlgeschlagener Anfragen vom API-Proxy an den Zielserver anzugeben, die auftreten können, bevor die Anfrage an einen anderen Zielserver weitergeleitet wird.

<MaxFailures> ist standardmäßig 0, was bedeutet, dass Apigee keine Korrekturmaßnahme durchführt. Achten Sie beim Konfigurieren eines HealthMonitor darauf, dass Sie <MaxFailures> auf einen Wert ungleich Null setzen.

Statusüberwachung mit TCP-Monitoring

Das in der folgenden Konfiguration beschriebene Beispiel für eine Systemdiagnose verwendet einen TCP-Monitor, um jeden Zielserver abzufragen, indem alle fünf Sekunden eine Verbindung auf 80 geöffnet wird. (Port ist optional. Wenn nicht angegeben, ist der TCPMonitor-Port der Zielserver-Port.

In dieser Beispielkonfiguration für die Systemdiagnose:

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 Zielserver um 1.
Ist die Verbindung erfolgreich, wird der Fehlerzähler für den Zielserver auf 0 zurückgesetzt.

Sie können eine Systemdiagnose als untergeordnetes Element des Elements <HTTPTargetConnection> des Zielendpunkts 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>

`<TCPMonitor>`-Konfigurationselemente

In der folgenden Tabelle werden die <TCPMonitor>-Konfigurationselemente beschrieben:

Name	Beschreibung	Default	Erforderlich/Optional?
`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 Zielserver.	0	Ja
`Port`	Optional: Der Port, über den die TCP-Verbindung hergestellt wird. Wenn nicht angegeben, ist der TCPMonitor-Port der Zielserver-Port.	0	Nein

Systemdiagnose mit HTTP-Monitor

Die in der folgenden Konfiguration beschriebene Beispiel-Systemdiagnose verwendet einen HTTP-Monitor, der alle fünf Sekunden eine GET-Anfrage an den Backend-Dienst sendet und der Anfragenachricht einen HTTP-Basisauthentifizierungs-Header hinzufügt.

In dieser Beispielkonfiguration für die Systemdiagnose:

Die erwartete Antwort vom Backend-Dienst ist ein HTTP-Antwortcode 200.
Der erwartete Wert für den benutzerdefinierten HTTP-Basisauthentifizierungs-Header ImOK ist YourOK.
Für das <UseTargetServerSSLInfo>-Element wird true festgelegt, um die SSL-Parameter aus dem Block <SSLInfo> des Zielservers zu verwenden.

Bei dieser Konfiguration werden die erwarteten Antwortcodes und Headerwerte mit den tatsächlichen Antworten vom Backend-Dienst verglichen. Wenn die Antwort nicht übereinstimmt, wird die Anfrage von der Konfiguration des Load-Balancers als Fehler behandelt.

Standardmäßig können Systemdiagnosen nicht auf Schlüsselspeicher, Truststores oder andere SSL-Parameter von ihren Zielservern zugreifen. Wenn Sie den Zugriff auf diese Parameter für die Systemdiagnose aktivieren möchten, um gegenseitiges TLS zu unterstützen, fügen Sie beispielsweise <UseTargetServerSSLInfo>true</UseTargetServerSSLInfo> in den Block <Request> ein.

    <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>
              <UseTargetServerSSLInfo>true</UseTargetServerSSLInfo>
              <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?
`Request`	Die ausgehende Anfragenachricht, die von der Systemdiagnose an die Zielserver in der Rotation gesendet wird.	–	Ja
`SuccessResponse`	(Optional) Übereinstimmungsoptionen für die eingehende HTTP-Antwortnachricht, die vom abgefragten Backend-Dienst generiert wurde	–	Nein

<HTTPMonitor>/<Request> Konfigurationselemente

Konfigurationsoptionen für die ausgehende Anfragenachricht, die von HealthMonitor an die Zielserver 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 Zielserver. Hinweis: Wenn der angegebene Wert 0 ist, verwendet Apigee ein Standardzeitlimit von 30 Sekunden.	0	Nein
`SocketReadTimeoutInSec`	Zeit in Sekunden, in der Daten aus dem HTTP-Dienst gelesen werden müssen, damit dies als Erfolg gilt. Wenn das Lesen innerhalb des angegebenen Intervalls fehlschlägt, wird dies als Fehler gewertet und die Anzahl der Fehler des LoadBalancers für den Zielserver wird erhöht. Hinweis: Wenn der angegebene Wert 0 ist, verwendet Apigee ein Standardzeitlimit von 30 Sekunden.	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 Zielserver 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
`UseTargetServerSSLInfo`	Wenn `UseTargetServerSSLInfo` "true" ist, verwenden Systemdiagnoseanfragen an einen Zielserver die SSL-Parameter aus dem SSLInfo-Block ("sSLInfo") des Zielservers. Andernfalls sind SSL-Parameter wie Protokoll, Schlüsselspeicher, Truststore usw. für die Systemdiagnose nicht verfügbar.	falsch	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
`Header`	Ein oder mehrere HTTP-Header und -Werte, 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 Zielserver wird um 1 erhöht. Sie können mehrere Header-Elemente definieren.	–	Nein
`IsSSL`	Mit "true" wird angegeben, dass die Anfrage zur Systemdiagnose über HTTPS gesendet wird.	Falsch	Nein
`TrustAllSSL`	Gibt an, ob die HTTP-Überwachungsprüfung automatisch allen SSL-Zertifikaten vertraut.	Falsch	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 Zielserver 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
`Header`	Ein oder mehrere HTTP-Header und -Werte, 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 Zielserver wird um 1 erhöht. Sie können mehrere Header-Elemente definieren.	–	Nein

Load-Balancing über Back-End-Server

Videos

Informationen zur Zielserver-Konfiguration

Zielserver erstellen

Apigee in der Cloud Console

Klassisches Apigee

Apigee API

Zielserver mit der API in einer Umgebung erstellen

Zielserver mithilfe der API in einer Umgebung auflisten

Zielendpunkt für das Load-Balancing über benannte Zielserver hinweg konfigurieren

Load-Balancer-Optionen konfigurieren

Algorithmus

Round-Robin

Gewichtet

Mindestverbindung

Maximale Fehlschläge

Wiederholen

IsFallback

Pfad

Zielserver für TLS/SSL konfigurieren

One-Way-TLS/SSL konfigurieren

Strikte SSL-Erzwingung konfigurieren

Bidirektionales TLS/SSL konfigurieren

Striktes SSL mithilfe der API konfigurieren

Statusüberwachung

Erfolge und Fehler

HealthMonitor aktivieren

<HealthMonitor>-Konfigurationselemente

Statusüberwachung mit TCP-Monitoring

<TCPMonitor>-Konfigurationselemente

Systemdiagnose mit HTTP-Monitor

<HTTPMonitor>-Konfigurationselemente

<HTTPMonitor>/<Request> Konfigurationselemente

<HTTPMonitor>/<SuccessResponse> Konfigurationselemente

`<HealthMonitor>`-Konfigurationselemente

`<TCPMonitor>`-Konfigurationselemente

`<HTTPMonitor>`-Konfigurationselemente