Diese Seite wurde von der Cloud Translation API übersetzt.

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

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

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

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

Direkte URL zu einem HTTP- oder HTTPS-Server
ScriptTarget zu einem Edge-gehosteten Node.js-Skript
HostedTarget für NodeJS, bereitgestellt in einer gehosteten Zielumgebung
TargetServer-Konfiguration

Ebenso kann die Service-Callout-Richtlinie verwendet werden, um aus dem API-Proxy-Ablauf einen Aufruf an einen beliebigen externen Dienst zu senden. 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 andere 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 der Failover unter 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“, wobei MaxFailures auf 5 festgelegt ist (Wert ungleich null):

<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. Dies liegt daran, dass Edge den Zielserver nicht automatisch wieder in die Rotation versetzt, auch wenn das Ziel wieder aktiv ist. Um dieses Problem zu beheben, muss der API-Proxy neu bereitgestellt werden, damit Edge den Zielserver wieder in die Rotation versetzen kann.

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

Mehr als einen TargetServer in der LoadBalancer-Konfiguration, um die Verfügbarkeit zu erhöhen.
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 die Systemdiagnose auf derselben Portnummer durchgeführt wird, die Edge für die Verbindung zu den Zielservern verwendet, empfiehlt Apigee, dass Sie das untergeordnete Element <Port> unter <TCPMonitor> weglassen, es sei denn, es unterscheidet sich vom Port des Zielservers. 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. Dies bedeutet, dass Edge bei jeder Anfrage immer versucht, eine Verbindung zum Ziel herzustellen, und den Zielserver nie aus der Rotation entfernt.