Load-Balancing über Back-End-Server

Sie sehen die Dokumentation zu Apigee Edge.
Rufen Sie die Apigee X-Dokumentation auf. weitere Informationen

Apigee Edge verbessert die Verfügbarkeit Ihrer API durch integrierte Unterstützung für Load-Balancing und Failover über mehrere Back-End-Serverinstanzen hinweg.

Zielserverkonfigurationen entkoppeln konkrete Endpunkt-URLs von TargetEndpoint-Konfigurationen. Jeder Zielserver wird in einer TargetEndpoint-HTTPConnection mit seinem Namen referenziert. Anstatt eine konkrete URL in der Konfiguration zu definieren, können Sie einen oder mehrere benannte Zielserver konfigurieren, wie im Abschnitt TargetEndpoint beschrieben.

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

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.
API-Routing und Load-Balancing mit Zielservern (Classic Edge)	Leiten Sie eine API basierend auf der Umgebung an einen anderen Zielserver weiter und führen Sie Load-Balancing für Ihre API auf Zielservern in der Classic Edge-Benutzeroberfläche aus.

Beispiel für eine Zielserverkonfiguration

Mit dem folgenden Code wird ein Zielserver definiert:

<TargetServer  name="target1">
  <Host>1.mybackendservice.com</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer >

Zielserver-Konfigurationselemente

In der folgenden Tabelle werden die Elemente beschrieben, die zum Erstellen und Konfigurieren eines Zielservers verwendet werden:

Name	Beschreibung	Standard	Erforderlich?
name	Der Name der Zielserver-Konfiguration, der innerhalb der Umgebung eindeutig sein muss. Der Name des Zielservers darf nur alphanumerische Zeichen enthalten.	–	Ja
Host	Die Host-URL des Back-End-Dienstes (ohne Protokoll).	–	Ja
Port	Der Port, den der Backend-Dienst überwacht	–	Ja
IsEnabled	Ein boolescher Wert, der angibt, ob die TargetServer-Konfiguration aktiviert oder deaktiviert ist. Auf diese Weise können Sie Zielserver aus der Rotation nehmen, ohne die API-Proxy-Konfiguration zu ändern. Häufig wird eine Anwendung oder ein Skript geschrieben, die bzw. das TargetServer basierend auf erwarteten Kapazitätsanforderungen, Wartungsplänen usw. automatisch aktiviert oder deaktiviert.	true	Ja

Zielserver über die UI verwalten

Verwalten Sie Zielserver wie unten beschrieben.

Zielserver mithilfe der API verwalten

Mit der Edge API können Sie Zielserver erstellen, löschen, aktualisieren, abrufen und auflisten. Weitere Informationen finden Sie unter TargetServers.

Verwenden Sie den folgenden API-Aufruf, um einen Zielserver zu erstellen:

$ curl -H "Content-Type:text/xml" -X POST -d \
'<TargetServer name="target1">
   <Host>1.mybackendservice.com</Host>
   <Port>80</Port>
   <IsEnabled>true</IsEnabled>
 </TargetServer>' \
-u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

Beispielantwort:

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

Nachdem Sie den ersten TargetServer erstellt haben, verwenden Sie den folgenden API-Aufruf, um einen zweiten TargetServer zu erstellen. Indem Sie zwei TargetServer definieren, stellen Sie zwei URLs bereit, die ein TargetEndpoint für das Load-Balancing verwenden kann:

$ curl -H "Content-type:text/xml" -X POST -d \
'<TargetServer  name="target2">
  <Host>2.mybackendservice.com</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer >' \
-u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

Beispielantwort:

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

Verwenden Sie den folgenden API-Aufruf, um eine Liste von Zielservern in einer Umgebung abzurufen:

$ curl -u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

Beispielantwort:

[ "target2", "target1" ]

Es stehen jetzt zwei TargetServer zur Verwendung durch API-Proxys zur Verfügung, die in der Testumgebung bereitgestellt werden. 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.

Wie im Thema Limits beschrieben, gilt ein Limit von 500 Zielservern pro Umgebung.

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 obige Konfiguration ist die einfachste verfügbare 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, wechseln ausgehende Anfragen vom API-Proxy an die Back-End-Server abwechselnd, eine zu eins, zwischen Ziel 1 und Ziel 2.

Das Element <Path> bildet den Basispfad des TargetEndpoint-URI für alle Zielserver. Es wird nur verwendet, wenn <LoadBalancer> verwendet wird. Andernfalls wird es ignoriert. Im obigen Beispiel ist eine Anfrage, die "target1" erreicht, http://target1/test und so für andere Zielserver.

Load-Balancer-Optionen festlegen

Sie können die Verfügbarkeit mithilfe von Optionen für Load-Balancing und Failover auf Load-Balancer- und Zielserverebene abstimmen. In diesem Abschnitt werden diese Optionen 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 in direktem Verhältnis zur Gewichtung der einzelnen Zielserver an Ihre Zielserver. 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 Zielserver erhält. In diesem Fall wird der Fehlerzähler um eins erhöht.

Wenn Apigee jedoch eine Antwort von einem Ziel erhält, zählt dies auch dann als Antwort vom Zielserver, selbst wenn die Antwort ein HTTP-Fehler ist (z. B. 500). Der Fehlerzähler wird dann zurückgesetzt. Sie können Ihrer Load-Balancer-Konfiguration das Element <ServerUnhealthyResponse> mit untergeordneten <ResponseCode>-Elementen hinzufügen, damit ungültige HTTP-Antworten (z. B. 500) auch den Fehlerzähler erhöhen, um einen fehlerhaften Server so schnell wie möglich aus der Load-Balancing-Rotation zu nehmen. Edge zählt auch 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 vom Zielserver.

<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. Dies bedeutet, dass Edge immer versucht, für jede Anfrage eine Verbindung zum Ziel herzustellen, und den Zielserver nie aus der Rotation entfernt.

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 von Ihnen angegebene Anzahl von Fehlversuchen aufweist. Wenn ein HealthMonitor eingerichtet ist, setzt Apigee gemäß der Konfiguration dieses HealthMonitors automatisch den Zielserver in die Rotation, sobald das Ziel wieder einsatzbereit ist. Weitere Informationen finden Sie unter Statusüberwachung.

Wenn Sie hingegen MaxFailures > 0 konfigurieren und keinen HealthMonitor konfigurieren, fügt Apigee den TargetServer nicht automatisch wieder in die Rotation ein, nachdem Apigee einen Fehler erkannt hat. In diesem Fall müssen Sie den API-Proxy noch einmal bereitstellen, bevor Apigee den TargetServer wieder in Rotation setzt. Siehe API-Proxy bereitstellen.

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 Round-Robin-Load-Balancing zwischen den Zielen 1 und 2, bis beide Ziele 1 und 2 nicht verfügbar sind. Wenn die Ziele 1 und 2 nicht verfügbar sind, wird der gesamte Traffic an Ziel 3 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>

Zielserver 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 One-Way-TLS/SSL, bei der Edge HTTPS-Anfragen an den Back-End-Dienst stellt:

<TargetServer name="target1">
  <Host>mocktarget.apigee.net</Host>
  <Port>443</Port>
  <IsEnabled>true</IsEnabled>
  <SSLInfo>
      <Enabled>true</Enabled>
  </SSLInfo> 
</TargetServer>

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

<TargetServer  name="TargetServer 1">
    <IsEnabled>true</IsEnabled>
    <Host>www.example.com</Host>
    <Port>443</Port>
    <SSLInfo>
        <Ciphers/>
        <ClientAuthEnabled>true</ClientAuthEnabled>
        <Enabled>true</Enabled>
        <IgnoreValidationErrors>false</IgnoreValidationErrors>
        <KeyAlias>keystore-alias</KeyAlias>
        <KeyStore>keystore-name</KeyStore>
        <Protocols/>
        <TrustStore>truststore-name</TrustStore>
    </SSLInfo>
</TargetServer >

Informationen zu den Attributen <SSLInfo>, z. B. <Ciphers> und <ClientAuthEnabled>, finden Sie unter TLS-Zugriff auf eine API für die Private Cloud konfigurieren.

Eine vollständige Anleitung zum Konfigurieren ausgehender TLS/SSL-Verbindungen finden Sie unter TLS von Edge zum Back-End (Cloud und Private Cloud) konfigurieren.

TargetServer-Schema

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

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 wird ein fehlgeschlagener TargetServer automatisch wieder in die Rotation zurückgeführt, wenn HealthMonitor feststellt, dass der TargetServer aktiv ist.

Das Status-Monitoring funktioniert mit <MaxFailures>. Ist das Monitoring von Systemdiagnosen nicht aktiviert, gibt <MaxFailures> die Anzahl der fehlgeschlagenen Anfragen vom API-Proxy an den TargetServer an, bei dem die Anfrage an einen anderen TargetServer weitergeleitet wird. Der ausgefallene TargetServer wird dann aus der Rotation genommen, bis Sie den Proxy noch einmal bereitstellen.

Bei aktiviertem Statusüberwachung wird ein fehlgeschlagener TargetServer automatisch wieder in die Rotation gesetzt und es sind keine erneuten Proxy-Bereitstellungen erforderlich.

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 das Statusmonitoring aktivieren, sendet Edge Systemdiagnosen an Ihren Zielserver. Eine Systemdiagnose ist eine an den Zielserver gesendete Anfrage, mit der ermittelt wird, ob der Zielserver fehlerfrei ist.

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

• Erfolgreich: Der Zielserver gilt bei einer erfolgreichen Systemdiagnose als fehlerfrei. Dies ist in der Regel das Ergebnis eines oder mehrerer der Folgenden:
  • Der Zielserver nimmt eine neue Verbindung zum angegebenen Port an, antwortet auf eine Anfrage an diesem Port und schließt den Port dann innerhalb des angegebenen Zeitraums. Die Antwort vom Zielserver enthält „Verbindung: Schließen“.
  • Der Zielserver antwortet auf eine Systemdiagnose-Anfrage mit einem 200-Statuscode (OK) oder einem anderen HTTP-Statuscode, den Sie für akzeptabel halten.
  • Der Zielserver antwortet auf eine Systemdiagnose-Anfrage mit einem Nachrichtentext, der mit dem erwarteten Nachrichtentext übereinstimmt.

  Wenn Edge feststellt, dass ein Server fehlerfrei ist, setzt Edge das Senden von Anfragen an diesen fort oder setzt das Senden fort.

• Fehler: Der Zielserver kann eine Systemdiagnose abhängig von der Art der Prüfung auf unterschiedliche Weise fehlschlagen. Ein Fehler kann protokolliert werden, wenn der Zielserver:
  • Lehnt eine Verbindung von Edge zum Port der Systemdiagnose ab.
  • Reagiert nicht innerhalb eines bestimmten Zeitraums auf Systemdiagnoseanfragen.
  • Gibt einen unerwarteten HTTP-Statuscode zurück.
  • Er antwortet mit einem Nachrichtentext, der nicht mit dem erwarteten Nachrichtentext übereinstimmt.

  Wenn ein Zielserver eine Systemdiagnose nicht besteht, erhöht Edge die Anzahl der Fehler dieses Servers. Wenn die Anzahl der Fehler für diesen Server einen vordefinierten Grenzwert (<MaxFailures>) erreicht oder überschreitet, beendet Edge 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. Stattdessen erstellen Sie eine Proxykonfiguration und laden sie als ZIP-Datei in Edge 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. Standardmäßig ist <MaxFailures> 0, was bedeutet, dass Edge keine Korrekturaktion ausfü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>
. . .

HealthMonitor mit TCPMonitor-Konfigurationselementen

In der folgenden Tabelle werden die TCPMonitor-Konfigurationselemente beschrieben:

Name	Beschreibung	Standard	Erforderlich/Optional?
IsEnabled	Ein boolescher Wert zur Aktivierung oder Deaktivierung von HealthMonitor	false	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 HealthMonitor-Beispiel, der einen HTTPMonitor verwendet, sendet alle fünf Sekunden eine GET-Anfrage an den Back-End-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. Folgendes wird jedoch nicht unterstützt:

• Bidirektionales HTTPS (auch als Zwei-Wege-TLS/SSL bezeichnet)
• selbst signierte Zertifikate

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

    <HealthMonitor>
      <IsEnabled>true</IsEnabled>
      <IntervalInSec>5</IntervalInSec>
      <HTTPMonitor>
        <Request>
          <IsSSL>true</IsSSL>
          <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>
    

HealthMonitor mit HTTPMonitor-Konfigurationselementen

In der folgenden Tabelle werden die HTTPMonitor-Konfigurationselemente beschrieben:

Name	Beschreibung	Standard	Erforderlich/Optional?
IsEnabled	Ein boolescher Wert zur Aktivierung oder Deaktivierung von HealthMonitor	false	Nein
IntervalInSec	Das Zeitintervall in Sekunden zwischen den einzelnen Abfrageanfragen.	0	Ja
Request	Konfigurationsoptionen für die ausgehende Anfragenachricht, die von HealthMonitor an die TargetServers in der Rotation gesendet wird. Der Pfad unterstützt keine Variablen.	–	Ja
IsSSL	Gibt an, ob HTTPS (sicheres HTTP) für das Monitoring von Verbindungen verwendet werden soll. Mögliche Werte: true: HTTPS wird verwendet. false: HTTP wird verwendet. Nicht angegeben: Verwendet die Zielserverkonfiguration.	false	Nein
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.	–	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 Pfadelement, um einen „Abfrage-Endpunkt” für Ihren HTTP-Dienst zu konfigurieren.	–	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	false	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
SuccessResponse	Ü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.	–	Nein
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