Load-Balancing über Back-End-Server

Sie lesen die Dokumentation zu Apigee X.
Apigee Edge-Dokumentation aufrufen

Apigee verbessert die Verfügbarkeit Ihrer APIs, indem es integrierte Unterstützung für Load-Balancing und Failover über mehrere Back-End-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 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",
  "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-Benutzeroberfläche

So erstellen Sie TargetServers mithilfe der 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:

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

    Das Dialogfeld TargetServer hinzufügen wird angezeigt.

  5. Klicken Sie auf Aktiviert, um die neue TargetServer- Definition kurz nach ihrer Erstellung zu aktivieren.
  6. Geben Sie einen Namen, einen Host und einen Port in die dafür vorgesehenen Felder ein. Klicken Sie optional das Kästchen SSL an. 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",
  "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 finden Sie unter Umgebungsvariablen für Apigee API-Anfragen festlegen.

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

{
  "host" : "1.mybackendservice.com",
  "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",
  "port": "80",
  "isEnabled": "true",
  }'

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

{
  "host" : "2.mybackendservice.com",
  "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.

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 Back-End-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 Back-End-Dienst mit einem TargetServer definieren und der Back-End-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 Back-End-Dienst stellt:

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

Wenn der Back-End-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",
  "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",
    "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 Back-End-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 Back-End-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 Back-End-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>
. . .

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 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 Beispiel für HealthMonitor, das 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 Back-End-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 Back-End-Dienste, die für die Verwendung von HTTP- und One-Way-HTTPS-Protokollen konfiguriert sind. Eine bidirektionale HTTPS, die auch als bidirektionale TLS/SSL bekannt ist, wird jedoch nicht unterstützt.

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

<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>
    </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 Default 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
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 Back-End-Dienst hergestellt wird. Nein
Verb Das HTTP-Verb, das für jede HTTP-Abfrageanfrage an den Back-End-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
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 Back-End-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 Back-End-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 Back-End-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