Bilanciamento del carico tra server di backend

Stai visualizzando la documentazione di Apigee Edge.
Consulta la documentazione di Apigee X. info

Apigee Edge migliora la disponibilità della tua API fornendo supporto integrato per il bilanciamento del carico e il failover su più istanze del server di backend.

Le configurazioni TargetServer separano gli URL endpoint concreti dalle configurazioni TargetEndpoint. Ogni TargetServer viene fatto riferimento per nome in un TargetEndpoint HTTPConnection. Anziché definire un URL concreto nella configurazione, puoi configurare uno o più TargetServer denominati come descritto nella sezione TargetEndpoint.

Una definizione TargetServer è costituita da un nome, un host e una porta, con un elemento aggiuntivo per indicare se TargetServer è abilitato o disabilitato.

Video

Guarda i seguenti video per scoprire di più sul routing API e sul bilanciamento del carico utilizzando i server di destinazione

Configurazione di esempio di TargetServer

Il codice seguente definisce un server di destinazione:

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

Elementi di configurazione di TargetServer

La tabella seguente descrive gli elementi utilizzati per creare e configurare un TargetServer:

Gestione dei server di destinazione utilizzando l'interfaccia utente

Gestisci i server di destinazione, come descritto di seguito.

Gestione dei server di destinazione utilizzando l'API

Puoi utilizzare l'API Edge per creare, eliminare, aggiornare, ottenere ed elencare i server di destinazione. Per maggiori informazioni, vedi TargetServers.

Utilizza la seguente chiamata API per creare un server di destinazione:

$ curl -H "Content-Type:text/xml" -X POST -d \
'<TargetServer name="target1">
   <Host>1.mybackendservice.com</Host>
   <Port>80</Port>
   <IsEnabled>true</IsEnabled>
 </TargetServer>' \
-u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

Esempio di risposta:

{
  "host" : "1.mybackendservice.com",
  "isEnabled" : true,
  "name" : "target1",
  "port" : 80
}

Dopo aver creato il primo TargetServer, utilizza la seguente chiamata API per creare un secondo TargetServer. Definendo due TargetServer, fornisci due URL che un TargetEndpoint può utilizzare per il bilanciamento del carico:

$ curl -H "Content-type:text/xml" -X POST -d \
'<TargetServer  name="target2">
  <Host>2.mybackendservice.com</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer >' \
-u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

Esempio di risposta:

{
  "host" : "2.mybackendservice.com",
  "isEnabled" : true,
  "name" : "target2",
  "port" : 80
}

Utilizza la seguente chiamata API per recuperare un elenco di TargetServer in un ambiente:

$ curl -u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

Esempio di risposta:

[ "target2", "target1" ]

Ora sono disponibili due TargetServer da utilizzare per i proxy API di cui è stato eseguito il deployment nell'ambiente di test. Per bilanciare il carico del traffico tra questi TargetServer, configura la connessione HTTP nell'endpoint di destinazione di un proxy API in modo che utilizzi i TargetServer.

Esiste un limite di 500 TargetServer per ambiente, come documentato nell'argomento Limiti.

Configurazione di un TargetEndpoint per bilanciare il carico tra i TargetServer denominati

Ora che hai a disposizione due TargetServer, puoi modificare l'impostazione di connessione HTTP di TargetEndpoint in modo che faccia riferimento a questi due TargetServer per nome:

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

La configurazione riportata sopra è la configurazione di bilanciamento del carico più semplice possibile. Il bilanciatore del carico supporta tre algoritmi di bilanciamento del carico: Round Robin, Weighted e Least Connection. Round Robin è l'algoritmo predefinito. Poiché nella configurazione precedente non è specificato alcun algoritmo, le richieste in uscita dal proxy API ai server di backend si alterneranno, una per una, tra target1 e target 2.

L'elemento <Path> forma il basepath dell'URI TargetEndpoint per tutti i server di destinazione. Viene utilizzato solo quando viene utilizzato <LoadBalancer>. In caso contrario, viene ignorato. Nell'esempio precedente, una richiesta che raggiunge "target1" verrà http://target1/test e così via per gli altri server di destinazione.

Impostazione delle opzioni del bilanciatore del carico

Puoi ottimizzare la disponibilità utilizzando le opzioni per il bilanciamento del carico e il failover a livello di bilanciatore del carico e TargetServer. Questa sezione descrive queste opzioni.

Algoritmo

Imposta l'algoritmo utilizzato da <LoadBalancer>. Gli algoritmi disponibili sono RoundRobin, Weighted e LeastConnections, ciascuno dei quali è documentato di seguito.

Round robin

L'algoritmo predefinito, round robin, inoltra una richiesta a ogni TargetServer nell'ordine in cui i server sono elencati nella connessione HTTP dell'endpoint di destinazione. Ad esempio:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

Somma

L'algoritmo di bilanciamento del carico ponderato ti consente di configurare carichi di traffico proporzionali per i tuoi TargetServer. Il bilanciatore del carico ponderato distribuisce le richieste ai TargetServer in proporzione diretta al peso di ciascun TargetServer. Pertanto, l'algoritmo ponderato richiede di impostare un attributo weight per ogni TargetServer. Ad esempio:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
    <LoadBalancer>
      <Algorithm>Weighted</Algorithm>
      <Server name="target1">
        <Weight>1</Weight>
      </Server>
      <Server name="target2">
        <Weight>2</Weight>
      </Server>
    </LoadBalancer>
    <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

In questo esempio, due richieste verranno indirizzate a target2 per ogni richiesta indirizzata a target1.

Least Connection

I bilanciatori del carico configurati per utilizzare l'algoritmo di connessione meno recente instradano le richieste in uscita al TargetServer con il minor numero di connessioni HTTP aperte. Ad esempio:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>LeastConnections</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
      </LoadBalancer>
  </HTTPTargetConnection>
  <Path>/test</Path>
</TargetEndpoint>

Numero massimo di errori

Il numero massimo di richieste non riuscite dal proxy API a TargetServer che comporta il reindirizzamento della richiesta a un altro TargetServer.

Un errore di risposta significa che Apigee non riceve alcuna risposta da un server di destinazione. Quando ciò accade, il contatore degli errori aumenta di uno.

Tuttavia, quando Apigee riceve una risposta da una destinazione, anche se la risposta è un errore HTTP (ad esempio 500), questa viene conteggiata come risposta dal server di destinazione e il contatore degli errori viene reimpostato. Per contribuire a garantire che anche le risposte HTTP errate (ad esempio 500) incrementino il contatore degli errori per escludere un server non integro dalla rotazione del bilanciamento del carico il prima possibile, puoi aggiungere l'elemento <ServerUnhealthyResponse> con elementi secondari <ResponseCode> alla configurazione del bilanciatore del carico. Edge conteggerà anche le risposte con questi codici come errori.

Nell'esempio seguente, target1 verrà rimosso dalla rotazione dopo cinque richieste non riuscite, incluse alcune risposte 5XX dal server di destinazione.

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <MaxFailures>5</MaxFailures>
        <ServerUnhealthyResponse>
            <ResponseCode>500</ResponseCode>
            <ResponseCode>502</ResponseCode>
            <ResponseCode>503</ResponseCode>
        </ServerUnhealthyResponse>
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

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.

È consigliabile utilizzare MaxFailures > 0 con un HealthMonitor. Se configuri MaxFailures > 0, TargetServer viene rimosso dalla rotazione quando il target non riesce il numero di volte che indichi. Quando è presente un HealthMonitor, Apigee reinserisce automaticamente il TargetServer nella rotazione dopo che la destinazione è di nuovo operativa, in base alla configurazione di HealthMonitor. Per saperne di più, consulta Monitoraggio dell'integrità.

In alternativa, se configuri MaxFailures > 0 e non configuri un monitor di integrità, Apigee rimuoverà automaticamente il server di destinazione dalla rotazione quando viene rilevato il primo errore. Apigee controllerà l'integrità del server di destinazione ogni cinque minuti e lo ripristinerà nella rotazione quando risponde normalmente.

Riprova

Se i tentativi vengono abilitati, una richiesta verrà ritentata ogni volta che si verifica un errore di risposta (errore I/O o timeout HTTP) o la risposta ricevuta corrisponde a un valore impostato da <ServerUnhealthyResponse>. Per saperne di più sull'impostazione di <ServerUnhealthyResponse>, consulta la sezione Errori massimi sopra.

Per impostazione predefinita, <RetryEnabled> è impostato su true. Imposta su false per disattivare i tentativi. Ad esempio:

<RetryEnabled>false</RetryEnabled>

IsFallback

È possibile impostare un solo TargetServer come server "di riserva". Il TargetServer di fallback non è incluso nelle routine di bilanciamento del carico finché tutti gli altri TargetServer non vengono identificati come non disponibili dal bilanciatore del carico. Quando il bilanciatore del carico determina che tutti i TargetServer non sono disponibili, tutto il traffico viene indirizzato al server di riserva. Ad esempio:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <Server name="target3">
          <IsFallback>true</IsFallback>
        </Server>
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

La configurazione precedente comporta il bilanciamento del carico round robin tra le destinazioni 1 e 2 finché entrambe le destinazioni 1 e 2 non sono disponibili. Quando i target 1 e 2 non sono disponibili, tutto il traffico viene indirizzato al target 3.

Percorso

Il percorso definisce un frammento URI che verrà aggiunto a tutte le richieste emesse da TargetServer al server di backend.

Questo elemento accetta un percorso di stringa letterale o un modello di messaggio. Un modello di messaggio consente di eseguire la sostituzione di stringhe variabili in fase di esecuzione. Ad esempio, nella seguente definizione dell'endpoint di destinazione, il valore di {mypath} viene utilizzato per il percorso:

<HTTPTargetConnection>
    <SSLInfo>
      <Enabled>true</Enabled>
    </SSLInfo>
    <LoadBalancer>
      <Server name="testserver"/>
    </LoadBalancer>
    <Path>{mypath}</Path>
</HTTPTargetConnection>

Configurazione di un server di destinazione per TLS/SSL

Se utilizzi un TargetServer per definire il servizio di backend e quest'ultimo richiede che la connessione utilizzi il protocollo HTTPS, devi attivare TLS/SSL nella definizione di TargetServer. Ciò è necessario perché il tag <Host> non consente di specificare il protocollo di connessione. Di seguito è riportata la definizione di TargetServer per TLS/SSL unidirezionale in cui Edge effettua richieste HTTPS al servizio di backend:

<TargetServer name="target1">
  <Host>mocktarget.apigee.net</Host>
  <Port>443</Port>
  <IsEnabled>true</IsEnabled>
  <SSLInfo>
      <Enabled>true</Enabled>
  </SSLInfo> 
</TargetServer>

Se il servizio di backend richiede TLS/SSL bidirezionale o reciproco, configura TargetServer utilizzando le stesse impostazioni di configurazione TLS/SSL di TargetEndpoints:

<TargetServer  name="TargetServer 1">
    <IsEnabled>true</IsEnabled>
    <Host>www.example.com</Host>
    <Port>443</Port>
    <SSLInfo>
        <Ciphers/>
        <ClientAuthEnabled>true</ClientAuthEnabled>
        <Enabled>true</Enabled>
        <IgnoreValidationErrors>false</IgnoreValidationErrors>
        <KeyAlias>keystore-alias</KeyAlias>
        <KeyStore>keystore-name</KeyStore>
        <Protocols/>
        <TrustStore>truststore-name</TrustStore>
    </SSLInfo>
</TargetServer >

Per informazioni sulle proprietà <SSLInfo>, ad esempio <Ciphers> e <ClientAuthEnabled>, consulta le informazioni sull'impostazione di queste proprietà per un host virtuale in Configurazione dell'accesso TLS a un'API per il cloud privato.

Per istruzioni complete sulla configurazione di TLS/SSL in uscita, vedi Configurazione di TLS da Edge al backend (cloud e cloud privato).

Schema TargetServer

Consulta lo schema per TargetServer e altre entità su GitHub.

Monitoraggio dello stato di integrità

Il monitoraggio dell'integrità consente di migliorare le configurazioni del bilanciamento del carico eseguendo il polling attivo degli URL del servizio di backend definiti nelle configurazioni TargetServer. Se il monitoraggio dell'integrità è abilitato, un TargetServer non riuscito viene reinserito automaticamente nella rotazione quando HealthMonitor determina che il TargetServer è attivo.

Il monitoraggio dello stato di salute funziona con <MaxFailures>. Se il monitoraggio dell'integrità non è abilitato, <MaxFailures> specifica il numero di richieste non riuscite dal proxy API al TargetServer che comporta il reindirizzamento della richiesta a un altro TargetServer. Il TargetServer non funzionante viene quindi rimosso dalla rotazione finché non esegui di nuovo il deployment del proxy.

Con il monitoraggio dell'integrità attivato, un TargetServer non riuscito viene reinserito automaticamente nella rotazione e non sono necessari nuovi deployment del proxy.

HealthMonitor funge da semplice client che richiama un servizio di backend tramite TCP o HTTP:

• Un client TCP si limita a verificare che sia possibile aprire un socket.
• Configura il client HTTP per inviare una richiesta HTTP valida al servizio di backend. Puoi definire operazioni HTTP GET, PUT, POST o DELETE. La risposta alla chiamata di monitoraggio HTTP deve corrispondere alle impostazioni configurate nel blocco <SuccessResponse>.

Operazioni riuscite e non riuscite

Quando abiliti il monitoraggio dell'integrità, Edge inizia a inviare controlli di integrità al server di destinazione. Un controllo di integrità è una richiesta inviata al server di destinazione che determina se il server di destinazione è integro o meno.

Un controllo di integrità può avere uno dei due risultati possibili:

• Riuscito:il server di destinazione viene considerato integro quando viene eseguito un controllo di integrità riuscito. In genere, questo è il risultato di uno o più dei seguenti fattori:
  • Il server di destinazione accetta una nuova connessione alla porta specificata, risponde a una richiesta su quella porta e poi chiude la porta entro il periodo di tempo specificato. La risposta del server di destinazione contiene "Connection: close"
  • Il server di destinazione risponde a una richiesta di controllo di integrità con un codice di stato HTTP 200 (OK) o un altro codice di stato HTTP che ritieni accettabile.
  • Il server di destinazione risponde a una richiesta di controllo di integrità con un corpo del messaggio corrispondente a quello previsto.

  Quando Edge determina che un server è integro, continua o riprende a inviargli richieste.

• Errore:il server di destinazione può non superare un controllo di integrità in diversi modi, a seconda del tipo di controllo. Un errore può essere registrato quando il server di destinazione:
  • Rifiuta una connessione da Edge alla porta del controllo di integrità.
  • Non risponde a una richiesta di controllo di integrità entro un periodo di tempo specificato.
  • Restituisce un codice di stato HTTP imprevisto.
  • Risponde con un corpo del messaggio che non corrisponde a quello previsto.

  Quando un server di destinazione non supera un controllo di integrità, Edge incrementa il conteggio degli errori del server. Se il numero di errori per quel server raggiunge o supera una soglia predefinita (<MaxFailures>), Edge smette di inviare richieste a quel server.

Abilitazione di un HealthMonitor

Per creare un HealthMonitor, aggiungi l'elemento <HealthMonitor> alla configurazione HTTPConnection di TargetEndpoint per un proxy. Non puoi farlo nell'interfaccia utente. Invece, crea una configurazione proxy e caricala come file ZIP su Edge. Una configurazione del proxy è una descrizione strutturata di tutti gli aspetti di un proxy API. Le configurazioni proxy sono costituite da file XML in una struttura di directory predefinita. Per ulteriori informazioni, consulta il riferimento per la configurazione dei proxy API.

Un semplice HealthMonitor definisce un IntervalInSec combinato con un TCPMonitor o un HTTPMonitor. L'elemento <MaxFailures> specifica il numero massimo di richieste non riuscite dal proxy API a TargetServer che comporta il reindirizzamento della richiesta a un altro TargetServer. Per impostazione predefinita, <MaxFailures> è 0, il che significa che Edge non esegue alcuna azione correttiva. Quando configuri un monitor di integrità, assicurati di impostare <MaxFailures> nel tag <HTTPTargetConnection> del tag <TargetEndpoint> su un valore diverso da zero.

TCPMonitor

La configurazione seguente definisce un HealthMonitor che esegue il polling di ogni TargetServer aprendo una connessione sulla porta 80 ogni cinque secondi. La porta è facoltativa. Se non specificata, la porta TCPMonitor è la porta TargetServer.)

• Se la connessione non riesce o richiede più di 10 secondi, il conteggio degli errori aumenta di 1 per TargetServer.
• Se la connessione ha esito positivo, il conteggio degli errori per TargetServer viene reimpostato su 0.

Puoi aggiungere un HealthMonitor come elemento figlio dell'elemento HTTPTargetConnetion di TargetEndpoint, come mostrato di seguito:

<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>
            <Port>80</Port>
        </TCPMonitor>
      </HealthMonitor>
  </HTTPTargetConnection>
. . .

HealthMonitor con elementi di configurazione TCPMonitor

La tabella seguente descrive gli elementi di configurazione di TCPMonitor:

HTTPMonitor

Un HealthMonitor di esempio che utilizza un HTTPMonitor invierà una richiesta GET al servizio di backend ogni cinque secondi. L'esempio seguente aggiunge un'intestazione di autenticazione di base HTTP al messaggio di richiesta. La configurazione della risposta definisce le impostazioni che verranno confrontate con la risposta effettiva del servizio di backend. Nell'esempio seguente, la risposta prevista è un codice di risposta HTTP 200 e un'intestazione HTTP personalizzata ImOK il cui valore è YourOK. Se la risposta non corrisponde, la richiesta verrà trattata come un errore dalla configurazione del bilanciatore del carico.

HTTPMonitor supporta i servizi di backend configurati per utilizzare i protocolli HTTP e HTTPS unidirezionale. Tuttavia, non supporta quanto segue:

• HTTPS bidirezionale (chiamato anche TLS/SSL bidirezionale)
• Certificati autofirmati.

Tieni presente che tutte le impostazioni di richiesta e risposta in un monitor HTTP saranno specifiche del servizio di backend da richiamare.

    <HealthMonitor>
      <IsEnabled>true</IsEnabled>
      <IntervalInSec>5</IntervalInSec>
      <HTTPMonitor>
        <Request>
          <IsSSL>true</IsSSL>
          <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
          <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
          <Port>80</Port>
          <Verb>GET</Verb>
          <Path>/healthcheck</Path>
          <Header name="Authorization">Basic 12e98yfw87etf</Header>
          <IncludeHealthCheckIdHeader>true</IncludeHealthCheckIdHeader>
        </Request>
        <SuccessResponse>
          <ResponseCode>200</ResponseCode>
          <Header name="ImOK">YourOK</Header>
        </SuccessResponse>
      </HTTPMonitor>
    </HealthMonitor>
    

HealthMonitor con elementi di configurazione HTTPMonitor

La tabella seguente descrive gli elementi di configurazione di HTTPMonitor: