Bilanciamento del carico tra server di backend

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

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

Le configurazioni di TargetServer disaccoppiano gli URL di endpoint concreti da TargetEndpoint configurazioni. A ogni TargetServer viene fatto riferimento tramite il nome in un TargetEndpoint HTTPConnection. Anziché definire un URL concreto nella configurazione, puoi configurarne uno o più TargetServer denominati come descritto nella TargetEndpoint.

Una definizione di TargetServer consiste in un nome, un host e una porta, con un ulteriore elemento per indicare se TargetServer è abilitato o disabilitato.

Video

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

Esempio di configurazione TargetServer

Il seguente codice 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

Nella tabella seguente vengono descritti 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 di destinazione tramite l'API

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

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. Se definisci due TargetServer, puoi fornire 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
}

Usa la seguente chiamata API per recuperare un elenco di TargetServers 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 utilizzabili dai proxy API di cui è stato eseguito il deployment nel test completamente gestito di Google Cloud. Per bilanciare il carico del traffico tra questi TargetServer, devi configurare il protocollo connessione nell'endpoint di destinazione di un proxy API per utilizzare i TargetServer.

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

La configurazione di un TargetEndpoint per bilanciare il carico tra i TargetServer denominati

Ora che hai due TargetServer disponibili, puoi modificare il parametro HTTP 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ù basilare possibile. Il carico il bilanciatore del carico supporta tre algoritmi di bilanciamento del carico: Round Robin, Weighted e Least Connection. Round robin è l'algoritmo predefinito. Poiché non viene specificato nessun algoritmo nella configurazione precedente, le richieste in uscita dal proxy API ai server di backend si alternano, una per uno, tra target1 e target 2.

L'elemento <Path> costituisce il percorso base dell'URI TargetEndpoint per a tutti i server di destinazione. Viene utilizzato solo quando si usa <LoadBalancer>. Altrimenti, viene ignorato. Nell'esempio precedente, una richiesta che raggiunge "target1" sarà http://target1/test e così via per altri server di destinazione.

Impostazione delle opzioni del bilanciatore del carico

Puoi ottimizzare la disponibilità utilizzando le opzioni per bilanciamento del carico e failover a livello di bilanciatore e di TargetServer. In questa sezione vengono descritte queste opzioni.

Algoritmo

Imposta l'algoritmo utilizzato da <LoadBalancer>. Le opzioni disponibili sono RoundRobin, Weighted e LeastConnections, ognuno dei quali è documentato di seguito.

Round robin

L'algoritmo predefinito, round robin, inoltra una richiesta a ciascun TargetServer nell'ordine che 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 consente di configurare carichi di traffico proporzionali per i tuoi TargetServer. Il LoadBalancer ponderato distribuisce la richiesta ai TargetServer in modo diretto in proporzione al peso di ogni TargetServer. Di conseguenza, l'algoritmo ponderato richiede 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, verranno instradate due richieste a target2 per ogni richiesta instradata a target1.

Connessione minima

I bilanciatori di carico configurati per utilizzare l'algoritmo di connessione minima instradano le richieste in uscita 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 al TargetServer che determina la richiesta viene reindirizzata a un altro TargetServer.

Un errore di risposta significa che Apigee non riceve risposta da un server di destinazione. Quando Ciò accade, il contatore di errori viene incrementato di uno.

Tuttavia, quando Apigee riceve una risposta da un target, anche se la risposta è un errore HTTP (ad esempio 500), viene conteggiata come risposta da il server di destinazione e il contatore degli errori viene reimpostato. Per garantire che risposte HTTP errate (ad esempio 500) incrementano anche il contatore di errori per eliminare un server non integro di rotazione del bilanciamento del carico il prima possibile, puoi aggiungere Elemento <ServerUnhealthyResponse> con <ResponseCode> elementi secondari alla configurazione del bilanciatore del carico. Edge conteggerà anche le risposte 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 cerca sempre connettersi alla destinazione per ogni richiesta e non rimuove mai il server di destinazione dalla rotazione.

È preferibile utilizzare MaxFailures > 0 con HealthMonitor. Se configuri MaxFailures > 0, il TargetServer viene rimosso dalla rotazione quando il target non supera il numero di volte da te indicato. Quando HealthMonitor è attivo, Apigee inserisce automaticamente TargetServer torna in rotazione quando la destinazione è attiva e in esecuzione, in base alla configurazione di HealthMonitor. Vedi Monitoraggio dello stato di salute. per ulteriori informazioni.

In alternativa, se configuri MaxFailures > 0 e non configuri HealthMonitor, Apigee non includerà nuovamente TargetServer nella rotazione automaticamente dopo il rilevamento di un errore da parte di Apigee. In questo caso, devi rieseguire il deployment del proxy API prima che Apigee rimetta il TargetServer in la rotazione. Consulta Deployment di un proxy API.

Riprova

Se è abilitato un nuovo tentativo, verrà eseguito un nuovo tentativo di 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>. Consulta la sezione Numero massimo di errori sopra per saperne di più sull'impostazione. <ServerUnhealthyResponse>.

Per impostazione predefinita, il campo <RetryEnabled> è impostato su true. Imposta false per disattivare il nuovo tentativo. Ad esempio:

<RetryEnabled>false</RetryEnabled>

IsFallback

Un (e solo uno) TargetServer può essere impostato come "fallback" o server web. TargetServer di riserva non è incluso nelle routine di bilanciamento del carico finché tutti gli altri TargetServer non vengono identificati come non è disponibile dal bilanciatore del carico. Quando il bilanciatore del carico determina che tutti i TargetServer siano se non è disponibile, tutto il traffico viene indirizzato al server di fallback. 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 riportata sopra genera il bilanciamento del carico "round robin" tra le destinazioni 1 e 2 fino a quando entrambi i target 1 e 2 non sono disponibili. Quando le destinazioni 1 e 2 non sono disponibili, tutto il traffico viene instradato al target 3.

Percorso

Percorso definisce un frammento URI che verrà aggiunto a tutte le richieste inviate da TargetServer al server di backend.

Questo elemento accetta un percorso di stringa letterale o un modello di messaggio. Un messaggio consente di eseguire la sostituzione di stringhe variabili in fase di runtime. 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 abilitare TLS/SSL nel Definizione di TargetServer. Questa operazione è necessaria perché il tag <Host> non ti consente specificare il protocollo di connessione. Di seguito è mostrata la definizione di TargetServer per la connessione unidirezionale TLS/SSL dove Edge effettua le 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 a due vie o reciproco, devi configurare 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 nella sezione Configurazione dell'accesso TLS a un'API per il cloud privato.

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

Schema TargetServer

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

Monitoraggio della salute

Il monitoraggio dello stato di integrità consente di migliorare le configurazioni di bilanciamento del carico eseguendo il polling attivo delle degli URL dei servizi di backend definiti nelle configurazioni di TargetServer. Con il monitoraggio dello stato di integrità abilitato, un TargetServer guasto viene automaticamente rimesso in rotazione quando HealthMonitor determina che TargetServer sia attivo.

Il monitoraggio dello stato di integrità funziona con <MaxFailures>. Senza il monitoraggio dello stato di integrità, <MaxFailures> specifica il numero di richieste non riuscite dal proxy API all'indirizzo TargetServer che determina il reindirizzamento della richiesta a un altro TargetServer. Il TargetServer non funzionante viene quindi tolto dalla rotazione finché non si esegue nuovamente il deployment del proxy.

Con il monitoraggio dello stato di integrità abilitato, un TargetServer guasto viene automaticamente riportato in rotazione e nessun proxy i nuovi deployment sono obbligatori.

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

• Un client TCP assicura semplicemente che sia possibile aprire un socket.
• Devi configurare il client HTTP in modo che invii una richiesta HTTP valida al servizio di backend. Tu possono definire operazioni HTTP GET, PUT, POST o DELETE. La risposta alla chiamata di monitoraggio HTTP deve corrispondere le impostazioni configurate nel blocco <SuccessResponse>.

Riusciti e non riusciti

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

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

• Operazione riuscita. Il server di destinazione è considerato integro in caso di integrità corretta quando viene eseguito il controllo. Questo è in genere il risultato di uno o più dei seguenti motivi:
  • Il server di destinazione accetta una nuova connessione alla porta specificata, risponde a una richiesta su quella porta, quindi chiude la porta entro il periodo di tempo specificato. La risposta dal server di destinazione contiene "Connessione: chiudi"
  • Il server di destinazione risponde a una richiesta di controllo di integrità con un codice di stato 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 corrisponda a quello previsto.

  Quando Edge rileva 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. È possibile registrare un errore 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 numero di errori del server. Se il numero di errori per quel server è uguale o superiore a una soglia predefinita (<MaxFailures>), Edge smette di inviare richieste a quel server.

Abilitazione di un monitoraggio di salute

Per creare HealthMonitor, aggiungi l'elemento <HealthMonitor> alla HTTPConnection di TargetEndpoint configurazione per un proxy. Non puoi eseguire questa operazione nell'interfaccia utente. Crea invece una configurazione proxy e come file ZIP su 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 informazioni, consulta Proxy API riferimento alla configurazione.

Un HealthMonitor semplice definisce un IntervalInSec combinato con un TCPMonitor o HTTPMonitor. L'elemento <MaxFailures> specifica il massimo numero di richieste non riuscite dal proxy API al TargetServer che ha generato la richiesta viene reindirizzato a un altro TargetServer. Il valore predefinito di <MaxFailures> è 0, il che significa Edge non esegue azioni correttive. Quando configuri un monitoraggio di integrità, assicurati di impostare <MaxFailures> in 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 un sulla porta 80 ogni cinque secondi. (La porta è facoltativa. Se non specificata, la porta TCPMonitor è la porta TargetServer).

• Se la connessione non riesce o impiega più di 10 secondi per connettersi, il numero di errori incrementi di 1 per quel TargetServer.
• Se la connessione riesce, il numero di errori per TargetServer viene reimpostato su 0.

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

Nella tabella seguente vengono descritti gli elementi di configurazione di TCPMonitor:

HTTPMonitor

Un HealthMonitor di esempio che utilizza HTTPMonitor invierà una richiesta GET al backend servizio una volta ogni cinque secondi. Nell'esempio riportato di seguito viene aggiunta un'intestazione per l'autorizzazione di base HTTP alla di richiesta di accesso. La configurazione della risposta definisce le impostazioni che saranno confrontate con quelle effettive la risposta desiderata dal servizio di backend. Nell'esempio seguente, la risposta prevista è una richiesta HTTP codice di risposta 200 e un'intestazione HTTP personalizzata ImOK il cui valore YourOK. Se la risposta non corrisponde, la richiesta verrà considerata come un errore. dalla configurazione del bilanciatore del carico.

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

• HTTPS a due vie (chiamato anche TLS/SSL a due vie)
• Certificati autofirmati.

Tieni presente che tutte le impostazioni di richiesta e risposta in un monitoraggio HTTP saranno specifiche per il di backend che deve essere richiamato.

    <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

Nella tabella seguente vengono descritti gli elementi di configurazione HTTPMonitor: