Bilanciamento del carico tra server di backend

Stai visualizzando la documentazione di Apigee Edge.
Vai alla documentazione di Apigee X. info

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

Le configurazioni di TargetServer disaccoppiano gli URL endpoint specifici dalle configurazioni di TargetEndpoint. A ogni TargetServer viene fatto riferimento per nome in una connessione HTTP di TargetEndpoint. Anziché definire un URL specifico nella configurazione, puoi configurare uno o più TargetServer denominati come descritto nella sezione TargetEndpoint.

Una definizione di TargetServer è composta 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 delle API e sul bilanciamento del carico utilizzando i server target

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 tramite l'interfaccia utente

Gestisci i server di destinazione, come descritto di seguito.

Gestione dei server target utilizzando l'API

Puoi utilizzare l'API Edge per creare, eliminare, aggiornare, recuperare ed elencare i server di destinazione. Per maggiori informazioni, consulta 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

Risposta di esempio:

{
  "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. Se definisci 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

Risposta di esempio:

{
  "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

Risposta di esempio:

[ "target2", "target1" ]

Ora sono disponibili due TargetServer che possono essere utilizzati dai 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 da utilizzare i TargetServer.

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

Configurazione di un TargetEndpoint per il bilanciamento del carico tra TargetServer denominati

Ora che hai due TargetServer disponibili, puoi modificare l'impostazione di connessione HTTP di TargetEndpoint per fare 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, Ponderato e Connessione minima. 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 percorso di base dell'URI TargetEndpoint per tutti i server di destinazione. Viene utilizzato solo quando viene utilizzato <LoadBalancer>. In caso contrario, viene ignorata. Nell'esempio precedente, una richiesta che raggiunge "target1" sarà http://target1/test e così via per gli altri server target.

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 è descritto 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, per ogni richiesta inoltrata al target1 verranno inoltrate due richieste al target2.

Connessione minima

I bilanciatori del carico configurati per utilizzare l'algoritmo di connessione minima indirizzano le richieste in uscita al Server di destinazione 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 indica che Apigee non riceve alcuna risposta da un server di destinazione. In questo caso, il contatore degli errori aumenta di uno.

Tuttavia, quando Apigee riceve una risposta da un target, anche se si tratta di un errore HTTP (ad esempio 500), viene conteggiata come risposta del server di destinazione e il contatore degli errori viene reimpostato. Per contribuire ad assicurarti che le risposte HTTP errate (ad esempio 500) incrementino anche il contatore degli errori per rimuovere un server non funzionante dalla rotazione del bilanciamento del carico il prima possibile, puoi aggiungere l'elemento <ServerUnhealthyResponse> con elementi figli <ResponseCode> alla configurazione del bilanciatore del carico. Edge conteggia come errori anche le risposte con questi codici.

Nell'esempio seguente, target1 verrà rimosso dalla rotazione dopo cinque richieste non andate a buon fine, incluse alcune risposte 5XX del 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 al target per ogni richiesta e non rimuove mai il server di destinazione dalla rotazione.

È preferibile utilizzare MaxFailures > 0 con un HealthMonitor. Se configuri MaxFailures > 0, il server Target viene rimosso dalla rotazione quando il target non riesce il numero di volte che indichi. Quando è implementato un HealthMonitor, Apigee inserisce automaticamente il TargetServer di nuovo in rotazione dopo che il target è di nuovo attivo e funzionante, in base alla configurazione di HealthMonitor. Per ulteriori informazioni, consulta Monitoraggio dell'integrità.

In alternativa, se configuri MaxFailures > 0 e non configuri un monitoraggio dello stato, 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 reintegrerà nella rotazione quando risponde normalmente.

Riprova

Se il nuovo tentativo è abilitato, verrà eseguito un nuovo tentativo per una richiesta 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 ulteriori informazioni sull'impostazione <ServerUnhealthyResponse>, consulta Errori massimi sopra.

Per impostazione predefinita, <RetryEnabled> è impostato su true. Imposta su false per disattivare il nuovo tentativo. 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 con assegnazione a rotazione tra i target 1 e 2 finché entrambi i target non sono disponibili. Quando i target 1 e 2 non sono disponibili, tutto il traffico viene indirizzato al target 3.

Percorso

Path definisce un frammento URI che verrà aggiunto a tutte le richieste inviate dal server 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, per il percorso viene utilizzato il valore {mypath}:

<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 il servizio di backend richiede che la connessione utilizzi il protocollo HTTPS, devi attivare TLS/SSL nella definizione di TargetServer. Questo è necessario perché il tag <Host> non consente di specificare il protocollo di connessione. Di seguito è riportata la definizione di TargetServer per TLS/SSL in un'unica direzione in cui Edge invia 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 il server 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>, come <Ciphers> e <ClientAuthEnabled>, consulta le informazioni su come impostarle per un host virtuale in Configurare l'accesso TLS a un'API per il cloud privato.

Per istruzioni complete sulla configurazione di TLS/SSL in uscita, consulta Configurare TLS da Edge al backend (Cloud e private cloud).

Schema TargetServer

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

Monitoraggio dello stato di integrità

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

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

Con il monitoraggio dell'integrità abilitato, un TargetServer non riuscito viene reinserito automaticamente nella rotazione e non è necessario alcun nuovo dispiegamento del proxy.

HealthMonitor agisce come un semplice client che richiama un servizio di backend tramite TCP o HTTP:

• Un client TCP si limita ad assicurarsi che sia possibile aprire una socket.
• Configura il client HTTP in modo che invii una richiesta HTTP valida al servizio di backend. Puoi definire operazioni HTTP GET, PUT, POST o DELETE. La risposta della chiamata del monitoraggio HTTP deve corrispondere alle impostazioni configurate nel blocco <SuccessResponse>.

Successi e insuccessi

Quando attivi il monitoraggio dello stato di 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 possibili risultati:

• Successo: il server di destinazione è considerato integro quando viene eseguito un controllo di integrità riuscito. Di solito, questo accade per uno o più dei seguenti motivi:
  • 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 che corrisponde 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 di 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.

Attivazione 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. Devi invece creare una configurazione proxy e caricarla come file ZIP in Edge. Una configurazione 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 monitoraggio dello stato, assicurati di impostare <MaxFailures> nel tag <HTTPTargetConnection> del tag <TargetEndpoint> su un valore diverso da zero.

TCPMonitor

La configurazione riportata di seguito definisce un HealthMonitor che esegue il polling di ogni TargetServer aprendo una connessione sulla porta 80 ogni cinque secondi. (La porta è facoltativa. Se non specificato, la porta TCPMonitor è la porta del server di destinazione.

• Se la connessione non riesce o richiede più di 10 secondi, il conteggio degli errori aumenta di 1 per quel TargetServer.
• Se la connessione va a buon fine, il conteggio degli errori per TargetServer viene reimpostato su 0.

Puoi aggiungere un HealthMonitor come elemento secondario 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>
. . .

Elementi di configurazione di HealthMonitor con TCPMonitor

La tabella seguente descrive gli elementi di configurazione di TCPMonitor:

HTTPMonitor

Un HealthMonitor di esempio che utilizza un HTTPMonitor invia una richiesta GET al servizio di backend ogni cinque secondi. L'esempio seguente aggiunge un'intestazione HTTP Basic Authorization 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à considerata un errore dalla configurazione del bilanciatore del carico.

HTTPMonitor supporta i servizi di backend configurati per utilizzare i protocolli HTTP e HTTPS unidirezionali. 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 per il servizio di backend che deve essere invocato.

    <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>
    

Elementi di configurazione di HealthMonitor con HTTPMonitor

La tabella seguente descrive gli elementi di configurazione di HTTPMonitor: