Questa pagina è stata tradotta dall'API Cloud Translation.

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

Stai visualizzando la documentazione di Apigee Edge.
Vai alla sezione Documentazione di Apigee X. Informazioni

La configurazione di TargetEndpoint definisce il modo in cui Apigee Edge si connette a un di servizio di backend o API. Invia le richieste e riceve le risposte alle/da il 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 su uno script Node.js ospitato su Edge
HostedTarget per NodeJS distribuito nell'ambiente di destinazione ospitato
Configurazione di TargetServer

Allo stesso modo, il criterio relativo ai callout di servizio 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 tramite una configurazione TargetServer.

Configurazione di TargetServer

La configurazione di TargetServer disaccoppia gli URL concreti dell'endpoint Configurazioni TargetEndpoint o nei criteri relativi ai callout di servizio. Un TargetServer a cui fa riferimento 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 consente di avere diverse configurazioni per ogni ambiente. Un criterio TargetEndpoint/Callout di servizio può essere configurato 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 configurate del server di backend.

Ecco un esempio di configurazione di TargetEndpoint che utilizza TargetServers:

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

MaxFailures

La configurazione MaxFailures specifica il numero massimo di errori delle richieste al server di destinazione, dopodiché quest'ultimo verrà 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 per "target1" non sono andate a buon fine poi "target1" verrà rimossa dalla rotazione e tutte le richieste successive saranno inviate solo a target2.

Antipattern

Avere un singolo TargetServer in una configurazione LoadBalancer dell'oggetto Criterio TargetEndpoint o callout di servizio con MaxFailures impostato su un un valore diverso da zero è sconsigliato perché ciò può avere implicazioni negative.

Considera la seguente configurazione di esempio con un solo 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 riesce cinque volte (numero specificato in MaxFailures), il TargetServer viene rimosso dalla rotazione. Poiché non esistono altri TargetServer a cui eseguire il failover, tutte le successive richieste al proxy API con questa configurazione non andranno a buon fine 503 Service Unavailable errore.

Anche se TargetServer "target1" torna al suo stato normale ed è in grado di inviare risposte positive, le richieste al proxy API continueranno a restituiscono errori 503. Questo perché Edge non inserisce automaticamente TargetServer in rotazione anche dopo che il target è di nuovo attivo e funzionante. Per risolvere il problema, è necessario eseguire nuovamente il deployment del proxy API affinché Edge possa inserire TargetServer torna alla rotazione.

Se nelle norme sui callout di servizio viene utilizzata la stessa configurazione, l'API le richieste riceveranno un errore 500 dopo le richieste al TargetServer "target1" non riesce per 5 volte.

Impatto

Utilizzo di un singolo TargetServer in una configurazione LoadBalancer di Il criterio TargetEndpoint o callout di servizio con MaxFailures impostato su un valore diverso da zero causa:

Le richieste API hanno esito negativo con errori 503/500 in modo continuo (dopo che le richieste hanno esito negativo per un numero di volte massimo MaxFailures) fino a quando non viene eseguito nuovamente il deployment del proxy API.
Interruzione di maggiore durata in quanto è complessa e può richiedere più tempo per diagnosticare la causa di questo problema (senza alcuna conoscenza preliminare di questo antipattern).

Best practice

Avere più di un TargetServer nella configurazione LoadBalancer per una maggiore disponibilità.
Definisci sempre un monitoraggio dello stato di salute quando MaxFailures sia 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. Avere un HealthMonitor assicura che TargetServer venga rimesso in rotazione non appena il server di destinazione diventa nuovamente disponibile, ossia ci sono non è necessario eseguire nuovamente il deployment del proxy.

Per assicurare che il controllo di integrità venga eseguito sullo stesso numero di porta Apigee utilizza Edge per connettersi ai server di destinazione; Apigee consiglia di omettere l'elemento secondario <Port> in <TCPMonitor>, a meno che è diversa dalla porta TargetServer. Per impostazione predefinita, <Port> corrisponde 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>
```
In presenza di un vincolo che prevede che un solo TargetServer e l'HealthMonitor non viene utilizzato, quindi non specificare MaxFailures nella configurazione di LoadBalancer.

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