Anti-Pattern: Load-Balancing mit einem einzelnen Zielserver, bei dem MaxFailures auf einen Wert ungleich null gesetzt ist

Sie lesen gerade die Dokumentation zu Apigee und Apigee Hybrid.
Apigee Edge-Dokumentation aufrufen.

Die TargetEndpoint-Konfiguration definiert, wie Apigee eine Verbindung zu einem Backend-Dienst oder einer API herstellt. Sie sendet die Anfragen und empfängt die Antworten an/vom Back-End-Dienst. Der Back-End-Dienst kann ein HTTP/HTTPS- oder NodeJS-Server sein.

Der Back-End-Dienst im TargetEndpoint kann auf eine der folgenden Arten aufgerufen werden:

Direkte URL zu einem HTTP- oder HTTPS-Server
TargetServer-Konfiguration

Entsprechend kann die ServiceCallout-Richtlinie verwendet werden, um einen beliebigen externen Dienst aus dem API-Proxy-Ablauf aufzurufen. Diese Richtlinie unterstützt die Definition von HTTP/HTTPS-Ziel-URLs entweder direkt in der Richtlinie selbst oder mithilfe einer TargetServer-Konfiguration.

TargetServer-Konfiguration

Die TargetServer-Konfiguration entkoppelt die konkrete Endpunkt-URLs von TargetEndpoint-Konfigurationen oder in Service-Callout-Richtlinien. Auf TargetServer wird durch einen Namen anstelle einer URL in TargetEndpoint verwiesen. Die TargetServer-Konfiguration enthält den Hostnamen des Back-End-Dienstes, die Portnummer und weitere Details.

Hier sehen Sie ein Beispiel für eine TargetServer-Konfiguration:

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

TargetServer ermöglicht Ihnen unterschiedliche Konfigurationen für jede Umgebung. Eine TargetEndpoint/Service-Callout-Richtlinie kann mit einem oder mehreren benannten TargetServern anhand eines LoadBalancers konfiguriert werden. Die integrierte Unterstützung für das Load-Balancing verbessert die Verfügbarkeit der APIs und das Failover zwischen den konfigurierten Back-End-Serverinstanzen.

Hier sehen Sie eine TargetEndpoint-Konfiguration mit TargetServern:

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

MaxFailures

Die Konfiguration MaxFailures gibt die maximale Anzahl von Anfragefehlern für den Zielserver an, nach denen der Zielserver als inaktiv gekennzeichnet und für alle nachfolgenden Anfragen aus der Rotation entfernt wird.

Hier eine Beispielkonfiguration mit MaxFailures:

<TargetEndpoint name="default">
    <HTTPTargetConnection>
      <LoadBalancer>
        <Server name="target1"/>
        <Server name="target2"/>
        <MaxFailures>5</MaxFailures>
      </LoadBalancer>
    </HTTPTargetConnection>
</TargetEndpoint>

Wenn im obigen Beispiel fünf aufeinanderfolgende Anfragen für „target1“ fehlgeschlagen sind, wird „target1“ aus der Rotation entfernt und alle nachfolgenden Anfragen werden nur an „target2“ gesendet.

Anti-Pattern

Es wird nicht empfohlen, einzelne TargetServer in einer LoadBalancer-Konfiguration der TargetEndpoint- oder ServiceCallout-Richtlinie mit MaxFailures auf einen Wert ungleich null zu setzen, da dies negative Auswirkungen haben kann.

Betrachten Sie die folgende Beispielkonfiguration mit einem einzelnen Zielserver namens "target1", bei dem MaxFailures auf 5 gesetzt (Wert ungleich null) ist:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <MaxFailures>5</MaxFailures>
      </LoadBalancer>
  </HTTPTargetConnection>

Wenn die Anfragen an den TargetServer „target1“ fünfmal (in MaxFailures angegebene Zahl) fehlschlagen, wird der TargetServer aus der Rotation entfernt. Da keine anderen TargetServers für das Failover vorgesehen sind, schlagen alle nachfolgenden Anfragen an den API-Proxy mit dieser Konfiguration mit dem Fehler 503 Service Unavailable fehl.

Selbst wenn der TargetServer "target1" wieder in seinen normalen Zustand zurückversetzt wird und in der Lage ist, erfolgreiche Antworten zu senden, geben die Anfragen an den API-Proxy weiterhin 503-Fehler zurück. Das liegt daran, dass Apigee den TargetServer nicht automatisch wieder in die Rotation versetzt, auch dann nicht, wenn das Ziel wieder ausgeführt wird. Um dieses Problem zu beheben, muss der API-Proxy neu bereitgestellt werden, damit Apigee den TargetServer wieder in die Rotation versetzt.

Wird dieselbe Konfiguration in der ServiceCallout-Richtlinie verwendet, erhalten die API-Anfragen den Fehler 500, wenn die Anfragen an den TargetServer "target1" fünfmal fehlschlagen.

Auswirkungen

Wenn Sie einen einzelnen TargetServer in einer LoadBalancer-Konfiguration der TargetEndpoint- oder ServiceCallout-Richtlinie verwenden, bei der MaxFailures auf einen Wert ungleich null gesetzt ist, geschieht Folgendes:

API-Anfragen schlagen mit 503/500-Fehlern kontinuierlich fehl (nachdem die Anfragen entsprechend MaxFailures fehlschlagen), bis der API-Proxy neu bereitgestellt wurde.
Längere Ausfälle, da es aufgrund der Komplexität mehr Zeit beanspruchen kann, die Ursache des Problems zu ermitteln, wenn keine vorherigen Kenntnisse zu diesem Anti-Pattern vorhanden sind.

Best Practice

Sie haben mehrere TargetServer in der LoadBalancer-Konfiguration, um eine höhere Verfügbarkeit zu ermöglichen.
Definieren Sie immer eine Systemdiagnose, wenn MaxFailures auf einen Wert ungleich Null gesetzt ist. Ein Zielserver wird aus der Rotation entfernt, wenn die Anzahl der Fehler die in MaxFailures angegebene Zahl erreicht. Mit einem HealthMonitor wird sichergestellt, dass der TargetServer wieder in Rotation aktiviert wird, sobald der Zielserver wieder verfügbar ist. Dies bedeutet, dass der Proxy nicht neu bereitgestellt werden muss..

Damit sichergestellt ist, dass die Systemdiagnose auf der gleichen Portnummer durchgeführt wird, die Apigee für die Verbindung mit den Zielservern verwendet, empfiehlt Apigee, das untergeordnete Element <Port> unter <TCPMonitor> wegzulassen, sofern es sich nicht vom TargetServer-Port unterscheidet. Standardmäßig ist <Port> mit dem TargetServer-Port identisch.

Beispielkonfiguration mit HealthMonitor:
```
<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>
      </TCPMonitor>
    </HealthMonitor>
  </HTTPTargetConnection>
</TargetEndpoint>
```
Wenn eine Einschränkung besteht, beispielsweise dass nur ein TargetServer verwendet wird und wenn HealthMonitor nicht verwendet wird, geben Sie in der Konfiguration LoadBalancer den Wert MaxFailures nicht an.

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.