Questa pagina è stata tradotta dall'API Cloud Translation.

Anti-pattern: 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 documentazione di Apigee X. informazioni

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

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

Indirizza l'URL a un server HTTP o HTTPS
ScriptTarget per uno script Node.js ospitato Edge
HostedTarget a NodeJS di cui è stato eseguito il deployment nell'ambiente di destinazione in hosting
Configurazione TargetServer

Analogamente, il criterio 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 di TargetServer.

Configurazione TargetServer

La configurazione TargetServer disaccoppia gli URL di endpoint concreti dalle configurazioni di TargetEndpoint o nei criteri di callout di servizio. In TargetServer si fa riferimento a un nome anziché all'URL dell'URL. La configurazione di TargetServer avrà il nome host del servizio di backend, il numero di porta e altri dettagli.

Ecco una configurazione di TargetServer di esempio:

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

TargetServer consente di avere configurazioni diverse per ogni ambiente. Un criterio di callout TargetEndpoint/Service può essere configurato con uno o più TargetServers 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.

Di seguito è riportato un esempio di configurazione 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 richieste non riuscite al server di destinazione, dopo i quali il server di destinazione deve essere contrassegnato come inattivo e rimosso dalla rotazione per tutte le richieste successive.

Una configurazione di esempio in cui è specificato MaxFailures:

<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 alla destinazione 2.

Antipattern

Non è consigliabile avere un singolo TargetServer in una configurazione LoadBalancer del criterio TargetEndpoint o callout di servizio con MaxFailures impostato su un valore diverso da zero perché 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 al TargetServer "target1" non vanno a buon fine per cinque volte (numero specificato in MaxFailures), TargetServer viene rimosso dalla rotazione. Poiché non esistono altri server di destinazione 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 allo stato normale ed è in grado di inviare risposte riuscite, le richieste al proxy API continueranno a restituire errori 503. Questo perché Edge non riporta automaticamente TargetServer in rotazione anche dopo che la destinazione è di nuovo in esecuzione. Per risolvere il problema, è necessario eseguire nuovamente il deployment del proxy API affinché Edge metta nuovamente TargetServer in rotazione.

Se nel criterio Callout di servizio viene utilizzata la stessa configurazione, le richieste API riceveranno un errore 500 dopo che le richieste al TargetServer "target1" non riescono per 5 volte.

Impatto

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

Le richieste API non andranno a buon fine con errori 503/500 in modo continuo (dopo che le richieste non vanno a buon fine per MaxFailures numero di volte) fino a quando non viene eseguito nuovamente il deployment del proxy API.
Interruzione più lunga in quanto è complessa e può richiedere più tempo per diagnosticare la causa del problema (senza alcuna conoscenza preventiva di questo anti-pattern).

Best practice

Per una disponibilità superiore, devi avere più di un TargetServer nella configurazione LoadBalancer.
Definisci sempre un monitoraggio integrità quando MaxFailures è impostato su un valore diverso da zero. Un server di destinazione verrà rimosso dalla rotazione quando il numero di errori raggiungerà il numero specificato in MaxFailures. Avere un HealthMonitor assicura che TargetServer venga reintegrato non appena il server di destinazione diventa di nuovo disponibile, il che significa che non è necessario eseguire nuovamente il deployment del proxy.

Per garantire che il controllo di integrità venga eseguito sullo stesso numero di porta utilizzato da Edge per la connessione ai server di destinazione, Apigee consiglia di omettere l'elemento secondario <Port> in <TCPMonitor>, a meno che non sia diverso dalla porta di TargetServer. Per impostazione predefinita, <Port> corrisponde alla porta di 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>
```
Se esiste un vincolo che prevede 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 prova sempre a connettersi alla destinazione per ogni richiesta e non rimuove mai il server di destinazione dalla rotazione.