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 Edge.
Consulta la documentazione di Apigee X. info

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

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

  • URL diretto a un server HTTP o HTTPS
  • ScriptTarget a uno script Node.js ospitato su Edge
  • HostedTarget a NodeJS di cui è stato eseguito il deployment nell'ambiente di destinazione ospitato
  • Configurazione di TargetServer

Allo stesso modo, il criterio Service Callout 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 di TargetServer.

Configurazione di TargetServer

La configurazione di TargetServer disaccoppia gli URL degli endpoint concreti dalle configurazioni di TargetEndpoint o nei criteri Service Callout. Un TargetServer viene fatto riferimento tramite un nome anziché l'URL in TargetEndpoint. La configurazione di 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. Un criterio TargetEndpoint/Service Callout può essere configurato con uno o più TargetServer denominati utilizzando un LoadBalancer. 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.

Un esempio di configurazione 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 riuscite per "target1", "target1" verrà rimosso dalla rotazione e tutte le richieste successive verranno inviate solo a target2.

Antipattern

Non è consigliabile avere un singolo TargetServer in una configurazione LoadBalancer del criterio TargetEndpoint o Service Callout con MaxFailures impostato su un valore diverso da zero, in quanto può avere implicazioni negative.

Considera la seguente configurazione di esempio che ha 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 esistono altri TargetServer a cui eseguire il failover, tutte le richieste successive al proxy API con questa configurazione non andranno a buon fine con 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é Edge non rimette automaticamente TargetServer in rotazione anche dopo che la destinazione è di nuovo attiva e in esecuzione. Per risolvere questo problema, è necessario eseguire di nuovo il deployment del proxy API affinché Edge rimetta TargetServer in rotazione.

Se la stessa configurazione viene utilizzata nel criterio Service Callout, le richieste API riceveranno l'errore 500 dopo che le richieste a TargetServer "target1" non vanno a buon fine 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 comporta:

  • Le richieste API non vanno a buon fine con errori 503/500 in modo continuo (dopo che le richieste non vanno a buon fine per il numero di volte di MaxFailures) fino a quando non viene eseguito di nuovo il 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 preliminare 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 verrà rimosso dalla rotazione quando il numero di errori raggiunge il numero specificato in MaxFailures. La presenza di un HealthMonitor garantisce che TargetServer venga rimesso in rotazione non appena il server di destinazione torna disponibile, il che significa che non è necessario eseguire di nuovo il deployment del proxy.

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

    Esempio di configurazione 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 che prevede l'utilizzo di un solo TargetServer e se HealthMonitor non viene utilizzato, non specificare MaxFailures nella configurazione LoadBalancer.

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

Per approfondire