Cette page a été traduite par l'API Cloud Translation.

Antimodèle : équilibrer la charge avec un seul serveur cible tout en définissant MaxFailures sur une valeur non nulle

Vous consultez la documentation d'Apigee Edge.
Consultez la documentation Apigee X. en savoir plus

La configuration TargetEndpoint définit la manière dont Apigee Edge se connecte à un service de backend ou à une API. Il envoie les requêtes et reçoit les réponses vers/depuis le service de backend. Le service de backend peut être un serveur HTTP/HTTPS, NodeJS ou une cible hébergée.

Le service de backend dans le point d'extrémité cible peut être appelé de l'une des manières suivantes :

Rediriger une URL vers un serveur HTTP ou HTTPS
ScriptTarget à un script Node.js hébergé par Edge
HostedTarget vers NodeJS déployé dans un environnement cible hébergé
Configuration de serveur cible

De même, la règle d'appel de service peut être utilisée pour appeler n'importe quel service externe à partir du flux de proxy de l'API. Cette règle permet de définir des URL cibles HTTP/HTTPS directement dans la règle elle-même ou en utilisant une configuration de serveur cible.

Configuration de serveur cible

La configuration de serveur cible dissocie les URL de points de terminaison concrètes des configurations de point d'extrémité cible ou dans les règles d'appel de service. Un serveur cible est référencé par un nom au lieu de l'URL dans le point d'extrémité cible. La configuration de serveur cible comporte le nom d'hôte du service de backend, le numéro de port et d'autres détails.

Voici un exemple de configuration de serveur cible :

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

Le serveur cible vous permet d'avoir des configurations différentes pour chaque environnement. Une règle de point d'extrémité cible/d'appel de service peut être configurée avec un ou plusieurs serveur cibles à l'aide d'un équilibreur de charge. La compatibilité intégrée pour l'équilibrage de charge améliore la disponibilité des API et le basculement entre les instances de serveur de backend configurées.

Voici un exemple de configuration de point d'extrémité cible utilisant des serveurs cibles :

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

MaxFailures

La configuration MaxFailures spécifie le nombre maximal d'échecs de requêtes adressées au serveur cible au-delà duquel le serveur cible doit être marqué comme indisponible et supprimé de la rotation pour toutes les requêtes ultérieures.

Exemple de configuration avec MaxFailures spécifié :

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

Dans l'exemple ci-dessus, si cinq requêtes consécutives échouent pour la cible "target1", la valeur "target1" est supprimée de la rotation et toutes les requêtes suivantes ne sont envoyées qu'à la cible target2.

Antimodèle

Il n'est pas recommandé d'avoir un seul serveur cible dans une configuration LoadBalancer de la règle de point d'extrémité cible ou d'appel de service avec MaxFailures défini sur une valeur non nulle, car cela peut avoir des conséquences négatives.

Prenons l'exemple de configuration suivant, qui comporte un seul TargetServer nommé "target1" avec MaxFailures défini sur 5 (valeur différente de zéro):

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

Si les requêtes adressées au serveur cible "target1" échouent cinq fois (nombre spécifié dans MaxFailures), le serveur cible est supprimé de la rotation. Étant donné qu'il n'y a pas d'autre serveurs cibles vers lesquels basculer, toutes les requêtes ultérieures envoyées au proxy d'API ayant cette configuration échouent avec une erreur 503 Service Unavailable.

Même si le serveur cible "target1" revient à son état normal et est capable d'envoyer des réponses réussies, les requêtes adressées au proxy d'API continuent à renvoyer des erreurs 503. En effet, Edge ne remet pas automatiquement le TargetServer en rotation même après que la cible est à nouveau opérationnelle. Pour résoudre ce problème, le proxy d'API doit être redéployé pour que Edge puisse remettre en rotation TargetServer.

Si la même configuration est utilisée dans la règle d'appel de service, les requêtes API affichent une erreur 500 lorsque les requêtes au serveur cible "target1" ont échoué 5 fois.

Impact

L'utilisation d'un seul serveur cible dans une configuration LoadBalancer de la règle de point d'extrémité cible ou d'appel de service avec MaxFailures défini sur une valeur différente de zéro a les effets suivants :

Les requêtes API échouent continuellement avec des erreurs 503/500 (lorsque les requêtes échouent le nombre maximal d'échecs) jusqu'à ce que le proxy d'API soit redéployé.
Une panne plus longue, car diagnostiquer la cause du problème est compliqué et peut prendre plus de temps (sans connaissance préalable de cet antimodèle).

Bonne pratique

Avoir plusieurs TargetServers dans la configuration LoadBalancer pour une meilleure disponibilité
Définissez toujours un objet HealthMonitor lorsque MaxFailures est défini sur une valeur non nulle. Dès que le nombre d'échecs sur un serveur cible atteint la valeur spécifiée dans MaxFailures, ce serveur est supprimé de la rotation. L'objet HealthMonitor permet de s'assurer que le serveur cible est remis en rotation lorsqu'il est de nouveau disponible. Il n'est donc pas nécessaire de redéployer le proxy.

Pour vous assurer que la vérification de l'état est effectuée sur le même numéro de port que celui utilisé par Edge pour se connecter aux serveurs cibles, Apigee vous recommande d'omettre l'élément enfant <Port> sous <TCPMonitor>, sauf s'il est différent du port TargetServer. Par défaut, <Port> est identique au port de serveur cible.

Exemple de configuration avec 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>
```
S'il existe une contrainte telle qu'un seul serveur cible et si l'objet HealthMonitor n'est pas utilisé, ne spécifiez pas MaxFailures dans la configuration LoadBalancer.

La valeur par défaut de MaxFailures est 0. Cela signifie que Edge tente toujours de se connecter à la cible pour chaque requête et ne supprime jamais le serveur cible de la rotation.