Load-Balancing über Back-End-Server

Sie sehen sich die Dokumentation zu Apigee Edge an.
Sehen Sie sich die Apigee X-Dokumentation an. info

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

TargetServer-Konfigurationen entkoppeln konkrete Endpunkt-URLs von TargetEndpoint-Konfigurationen. In einer TargetEndpoint-HTTPConnection wird auf jeden TargetServer per Name verwiesen. Anstatt eine konkrete URL in der Konfiguration zu definieren, können Sie einen oder mehrere benannte TargetServer konfigurieren, wie im Abschnitt TargetEndpoint beschrieben.

Eine TargetServer-Definition besteht aus einem Namen, einem Host und einem Port mit 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.

Beispiel für eine TargetServer-Konfiguration

Im folgenden Code wird ein Zielserver definiert:

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

TargetServer-Konfigurationselemente

In der folgenden Tabelle werden die Elemente beschrieben, mit denen ein TargetServer erstellt und konfiguriert wird:

Zielserver über die Benutzeroberfläche verwalten

Verwalten Sie Zielserver wie unten beschrieben.

Zielserver mit 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 der TargetServers in einer Umgebung abzurufen:

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

Beispielantwort:

[ "target2", "target1" ]

Es sind jetzt zwei TargetServers für die Verwendung durch API Proxies verfügbar, 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.

Für jede Umgebung gilt ein Limit von 500 TargetServers, wie im Thema Limits dokumentiert.

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 Ziel 1 und Ziel 2 ausgetauscht, eine nach der anderen.

Das <Path> -Element 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 lautet eine Anfrage für http://target1/test so: . Anfragen an andere Zielserver sind äquivalent.

Load-Balancer-Optionen festlegen

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 verwenden. 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. Beispiele:

<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 Anfrage an den 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. Beispiele:

<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 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 Zielserver, 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. Edge 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 Zielservers.

<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 Edge immer versucht, für jede Anfrage eine Verbindung zum Ziel herzustellen, und den Zielserver niemals 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 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 Zielserver automatisch aus der Rotation, wenn der erste Fehler erkannt wird. Apigee prüft den Status des Zielservers 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 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 das One-Way-TLS/SSL, bei dem Edge HTTPS-Anfragen an den Backend-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 <SSLInfo>-Eigenschaften wie <Ciphers> und <ClientAuthEnabled> finden Sie unter TLS-Zugriff auf eine API für die Private Cloud konfigurieren.

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

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 die Statusüberwachung aktivieren, sendet Edge 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 Systemdiagnoseanfrage mit einem HTTP-Statuscode 200 (OK) oder einem anderen HTTP-Statuscode, der von Ihnen als akzeptabel eingestuft wird.
  • Der Zielserver antwortet auf eine Anfrage zur Systemdiagnose mit einem Nachrichtentext, der dem erwarteten Nachrichtentext entspricht.

  Wenn Edge feststellt, dass ein Server fehlerfrei ist, setzt Edge 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 Edge 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 Edge den Fehlerzähler dieses Servers. Wenn die Anzahl der Fehler für diesen Server einen vordefinierten Schwellenwert (<MaxFailures>) erreicht oder übersteigt, stoppt 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. Erstellen Sie stattdessen eine Proxykonfiguration und laden Sie 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. <MaxFailures> ist standardmäßig 0, was bedeutet, dass Edge 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:

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 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:

• Bidirektionale HTTPS (auch als bidirektionale 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: