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

<ph type="x-smartling-placeholder"></ph> Sie sehen die Dokumentation zu Apigee Edge.
Gehen Sie zur Apigee X-Dokumentation. Weitere Informationen

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

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

Direkte URL zu einem HTTP- oder HTTPS-Server
ScriptTarget auf ein Edge-gehostetes Node.js-Skript
HostedTarget auf NodeJS, das in einer gehosteten Zielumgebung bereitgestellt wird
TargetServer-Konfiguration

Ebenso kann die Service Callout-Richtlinie verwendet werden, um einen Aufruf an einen beliebigen externen Dienst zu tätigen. aus dem API-Proxy-Ablauf. 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 Edge den TargetServer nicht automatisch wieder in Rotation, auch wenn das Ziel wieder aktiv ist. Um dieses Problem zu beheben, der API-Proxy neu bereitgestellt werden muss, damit Edge die Zielserver zurück in Rotation.

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

Um sicherzustellen, dass die Systemdiagnose für dieselbe Portnummer durchgeführt wird, Edge verwendet, um eine Verbindung zu den Zielservern herzustellen, empfiehlt Apigee, dass Sie keine das untergeordnete Element <Port> unter <TCPMonitor>, es sei denn, es unterscheidet sich vom TargetServer-Port. 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 Edge immer versucht, für jede Anfrage eine Verbindung zum Ziel herzustellen, und entfernt den Zielserver niemals aus der Rotation.