Antipattern: bilanciamento del carico mediante un singolo server di destinazione con MaxFailures impostato su un valore diverso da zero

Stai visualizzando la documentazione di Apigee e Apigee hybrid.
Visualizza la documentazione di Apigee Edge.

La configurazione TargetEndpoint definisce il modo in cui Apigee si connette a un servizio o API di backend. Invia le richieste e riceve le risposte da/verso il servizio di backend. Il servizio di backend può essere un server HTTP/HTTPS o NodeJS.

Il servizio di backend in TargetEndpoint può essere richiamato in uno dei seguenti modi:

  • URL diretto a un server HTTP o HTTPS
  • Configurazione di TargetServer

Allo stesso modo, il criterio ServiceCallout può essere utilizzato per effettuare una chiamata a qualsiasi servizio esterno dal flusso del proxy API. Questo criterio supporta la definizione di URL di destinazione HTTP/HTTPS direttamente nel criterio stesso o utilizzando una configurazione TargetServer.

Configurazione di TargetServer

La configurazione di TargetServer disaccoppia gli URL degli endpoint concreti dalle configurazioni di TargetEndpoint o nelle norme Service Callout. Un TargetServer viene riferito a un nome anziché all'URL in TargetEndpoint. La configurazione TargetServer conterrà il nome host del servizio di backend, il numero di porta e altri dettagli.

Ecco un esempio di configurazione di TargetServer:

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

TargetServer ti consente di avere configurazioni diverse per ogni ambiente. Una policy TargetEndpoint/Service Callout può essere configurata con uno o più TargetServer denominati utilizzando un bilanciatore del carico. Il supporto integrato per il bilanciamento del carico migliora la disponibilità delle API e il failover tra le istanze del server di backend configurate.

Ecco un esempio di configurazione di TargetEndpoint che utilizza TargetServer:

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

MaxFailures

La configurazione MaxFailures specifica il numero massimo di errori di richiesta al server di destinazione dopo il quale il server di destinazione deve essere contrassegnato come inattivo e rimosso dalla rotazione per tutte le richieste successive.

Una configurazione di esempio con MaxFailures specificato:

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

Nell'esempio precedente, se cinque richieste consecutive non sono andate a buon fine per "target1", "target1" verrà rimosso dalla rotazione e tutte le richieste successive verranno inviate solo a target2.

Antipattern

L'utilizzo di un singolo TargetServer in una configurazione LoadBalancer della policy TargetEndpoint o Service Callout con MaxFailures impostato su un valore diverso da zero non è consigliato, in quanto può avere implicazioni negative.

Considera la seguente configurazione di esempio con un singolo TargetServer denominato "target1" con MaxFailures impostato su 5 (valore diverso da zero): 

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

Se le richieste a TargetServer "target1" non vanno a buon fine cinque volte (numero specificato in MaxFailures), TargetServer viene rimosso dalla rotazione. Poiché non sono presenti altri TargetServer a cui eseguire il failover, tutte le richieste successive al proxy API con questa configurazione non andranno a buon fine e verrà visualizzato l'errore 503 Service Unavailable.

Anche se TargetServer "target1" torna al suo stato normale ed è in grado di inviare risposte riuscite, le richieste al proxy API continueranno a restituire errori 503. Questo perché Apigee non reinserisce automaticamente TargetServer nella rotazione anche dopo che la destinazione è di nuovo operativa. Per risolvere il problema, il proxy API deve essere nuovamente implementato affinché Apigee reinserisca TargetServer nella rotazione.

Se viene utilizzata la stessa configurazione nel criterio Service Callout, le richieste API restituiranno l'errore 500 dopo che le richieste a TargetServer "target1" non sono riuscite 5 volte.

Impatto

L'utilizzo di un singolo TargetServer in una configurazione LoadBalancer del criterio TargetEndpoint o Service Callout con MaxFailures impostato su un valore diverso da zero causa:

  • Le richieste API non vanno a buon fine con errori 503/500 in modo continuo (dopo che le richieste non sono riuscite per il numero di MaxFailures) fino al nuovo deployment del proxy API.
  • Interruzione più lunga, in quanto è difficile e può richiedere più tempo per diagnosticare la causa di questo problema (senza una conoscenza precedente di questo antipattern).

Best practice

  1. Avere più di un TargetServer nella configurazione LoadBalancer per una maggiore disponibilità.

  2. Definisci sempre un monitoraggio dell'integrità quando MaxFailures è impostato su un valore diverso da zero. Un server di destinazione viene rimosso dalla rotazione quando il numero di errori raggiunge il numero specificato in MaxFailures. Un HealthMonitor garantisce che TargetServer venga reinserito nella rotazione non appena il server di destinazione torna disponibile, il che significa che non è necessario eseguire nuovamente il deployment del proxy.

    Per assicurarti che il controllo di integrità venga eseguito sullo stesso numero di porta che Apigee utilizza per connettersi ai server di destinazione, Apigee consiglia di omettere l'elemento secondario <Port> in <TCPMonitor>, a meno che non sia diverso dalla porta TargetServer. Per impostazione predefinita, <Port> è uguale alla porta TargetServer.

    Configurazione di esempio con 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>

  3. Se esiste un vincolo tale che solo un TargetServer e se HealthMonitor non viene utilizzato, non specificare MaxFailures nella configurazione LoadBalancer.

    Il valore predefinito di MaxFailures è 0. Ciò significa che Apigee tenta sempre di connettersi alla destinazione per ogni richiesta e non rimuove mai il server di destinazione dalla rotazione.

Per approfondire