Bilanciamento del carico tra server di backend

Questa pagina si applica ad Apigee e Apigee hybrid.

Visualizza la documentazione di Apigee Edge.

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

I server di destinazione separano gli URL degli endpoint concreti dalle configurazioni degli endpoint di destinazione. Anziché definire un URL concreto nella configurazione, puoi configurare uno o più server di destinazione denominati. Quindi, viene fatto riferimento a ogni server di destinazione per nome in una connessione HTTPConnection dell'endpoint di destinazione.

Video

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

Video Descrizione
Bilanciamento del carico utilizzando i server di destinazione Bilancia il carico delle API tra i server di destinazione.
Routing API basato sull'ambiente utilizzando i server di destinazione Instradare un'API a un server di destinazione diverso in base all'ambiente.

Informazioni sulla configurazione del server di destinazione

Una configurazione del server di destinazione è costituita da un nome, un host, un protocollo e una porta, con un elemento aggiuntivo per indicare se il server di destinazione è abilitato o disabilitato. Un server di destinazione può anche avere un oggetto <sSLInfo> facoltativo.

Il seguente codice fornisce un esempio di configurazione del server di destinazione:

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

Per ulteriori informazioni sull'API TargetServers, consulta organizations.environments.targetservers.

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

Creazione dei server di destinazione

Crea i server di destinazione utilizzando l'API o l'interfaccia utente Apigee come descritto nelle sezioni seguenti.

Apigee nella console Cloud

Per creare server di destinazione utilizzando Apigee nella console Cloud:

  1. Nella console Google Cloud , vai alla pagina Gestione > Ambienti.

    Vai ad Ambienti

  2. Seleziona l'ambiente in cui vuoi definire un nuovo server di destinazione.
  3. Fai clic su Server di destinazione nella parte superiore del riquadro.
  4. Fai clic su + Crea server di destinazione.

  5. Inserisci un nome, un host, un protocollo e una porta nei campi forniti. Le opzioni per Protocollo sono: HTTP per i server di destinazione basati su REST, gRPC - Destinazione per i server di destinazione basati su gRPC o gRPC - Callout esterno. Consulta Creazione di proxy API gRPC per informazioni sul supporto del proxy gRPC.

    Facoltativamente, puoi selezionare Abilita SSL. Vedi Panoramica dei certificati SSL.

  6. Fai clic su Crea.

Apigee classico

Per creare server di destinazione utilizzando la UI Apigee classica:

  1. Accedi alla UI Apigee.
  2. Seleziona Amministratore > Ambienti > TargetServer.
  3. Dall'elenco a discesa Ambiente, seleziona l'ambiente in cui vuoi definire un nuovo server di destinazione.

    L'interfaccia utente di Apigee mostra un elenco dei server di destinazione attuali nell'ambiente selezionato:

    Elenco dei server di destinazione

  4. Fai clic su +Server di destinazione per aggiungere un nuovo server di destinazione all'ambiente selezionato.

    Viene visualizzata la finestra di dialogo Aggiungi server di destinazione:

    Finestra di dialogo Aggiungi server di destinazione

  5. Fai clic su Attivato per attivare il nuovo server di destinazione. immediatamente dopo la creazione.

  6. Inserisci un nome, un host, un protocollo e una porta nei campi forniti. Le opzioni per Protocollo sono HTTP o GRPC.

    Se vuoi, puoi selezionare la casella di controllo SSL. Per ulteriori informazioni su questi campi, vedi TargetServers (video 4MV4D).

  7. Fai clic su Aggiungi.

    Apigee crea la nuova definizione del server di destinazione.

  8. Dopo aver creato un nuovo server di destinazione, puoi modificare il proxy API e cambiare l'elemento <HTTPTargetConnection> in modo che faccia riferimento alla nuova definizione.

API Apigee

Le sezioni seguenti forniscono esempi di utilizzo dell'API Apigee per creare ed elencare i server di destinazione.

Per maggiori informazioni, consulta l'API TargetServers.

Creazione di un server di destinazione in un ambiente utilizzando l'API

Per creare un server di destinazione denominato target1 che si connette a 1.mybackendservice.com sulla porta 80, utilizza la seguente chiamata API:

curl "https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers" \
  -X POST \
  -H "Content-Type:application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '
  {
  "name": "target1",
  "host": "1.mybackendservice.com",
  "protocol": "http",
  "port": "80",
  "isEnabled": "true",
  }'

Dove $TOKEN è impostato sul tuo token di accesso OAuth 2.0, come descritto in Ottenere un token di accesso OAuth 2.0. Per informazioni sulle opzioni curl utilizzate in questo esempio, consulta la sezione Utilizzare curl. Per una descrizione delle variabili di ambiente che puoi utilizzare, consulta Impostazione delle variabili di ambiente per le richieste API Apigee.

Di seguito è riportato un esempio di risposta:

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

Crea un secondo server di destinazione utilizzando la seguente chiamata API. Definendo due server di destinazione, fornisci due URL che un endpoint di destinazione può utilizzare per il bilanciamento del carico:

curl "https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers" \
  -X POST \
  -H "Content-Type:application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '
  {
  "name": "target2",
  "host": "2.mybackendservice.com",
  "protocol": "http",
  "port": "80",
  "isEnabled": "true",
  }'

Di seguito è riportato un esempio di risposta:

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

Elenco dei server di destinazione in un ambiente utilizzando l'API

Per elencare i server di destinazione in un ambiente, utilizza la seguente chiamata API:

curl https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers \
  -H "Authorization: Bearer $TOKEN"

Di seguito è riportato un esempio di risposta:

[ "target2", "target1" ]

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

Configurazione di un endpoint di destinazione per bilanciare il carico tra server di destinazione denominati

Ora che hai a disposizione due server di destinazione, puoi modificare l'elemento <HTTPTargetConnection> dell'endpoint di destinazione per fare riferimento a questi due server di destinazione 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. Il bilanciatore del carico supporta tre algoritmi di bilanciamento del carico: RoundRobin, Weighted e LeastConnections. 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 target2.

L'elemento <Path> forma il basepath dell'URI dell'endpoint di destinazione 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.

Per saperne di più, consulta TargetEndpoint.

Configurazione delle opzioni del bilanciatore del carico

Puoi ottimizzare la disponibilità configurando le opzioni per il bilanciamento del carico e il failover a livello di bilanciatore del carico e server di destinazione, come descritto nelle sezioni seguenti.

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 server di destinazione 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 server di destinazione. Il bilanciatore del carico ponderato distribuisce le richieste ai server di destinazione in proporzione diretta al peso di ciascun server di destinazione. Pertanto, l'algoritmo ponderato richiede di impostare un attributo weight per ogni server di destinazione. 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 indirizzata a target2, ne verranno indirizzate due a target1.

Least Connections

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 al server di destinazione che comporta il reindirizzamento della richiesta a un altro server di destinazione.

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 404 o 500), viene conteggiata come risposta dal server di destinazione e il contatore degli errori viene reimpostato. Per assicurarti che anche le risposte HTTP errate (ad esempio 500) incrementino il contatore degli errori per rimuovere 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. Apigee conteggerà anche le risposte con questi codici come errori.

Nell'esempio seguente, target1 verrà rimosso dalla rotazione dopo cinque richieste non riuscite, incluse 404 e 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>404</ResponseCode>
            <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 Apigee 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 monitor di integrità. Se configuri MaxFailures > 0, il server di destinazione viene rimosso dalla rotazione quando la destinazione non riesce il numero di volte che indichi. Quando è presente un monitoraggio dell'integrità, Apigee reinserisce automaticamente il server di destinazione nella rotazione dopo che la destinazione è di nuovo operativa, in base alla configurazione del monitoraggio dell'integrità. Per saperne di più, consulta Monitoraggio dell'integrità.

Tieni presente che sia le chiamate API regolari sia quelle avviate da un monitor di integrità vengono conteggiate nel numero MaxFailures.

Tieni presente inoltre che il conteggio degli errori di esecuzione per ogni server di destinazione viene mantenuto in base al bilanciamento del carico. Ad esempio, supponiamo che un proxy abbia due endpoint di destinazione e che ognuno abbia un bilanciatore del carico e che entrambi i bilanciatori del carico siano configurati per utilizzare lo stesso insieme di server di destinazione. In questo caso, gli errori di un endpoint di destinazione vengono conteggiati solo per il bilanciatore del carico corrispondente. Non influiscono sulla rotazione dell'altro endpoint di destinazione.

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 ulteriori informazioni sull'impostazione di <ServerUnhealthyResponse>, vedi 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 server di destinazione come server di riserva. Il bilanciatore del carico non utilizzerà il server di fallback finché tutti gli altri server di destinazione non saranno stati rimossi dalla rotazione del bilanciatore del carico. In questo caso, tutto il traffico viene indirizzato al server di failover finché uno degli altri server di destinazione non viene nuovamente segnalato come integro e non viene reinserito nella rotazione. 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 target1 e target2 finché sia target1 che target2 non sono disponibili. Quando target1 e target2 non sono disponibili, tutto il traffico viene indirizzato a target3.

Se il server di riserva non è integro, Apigee non indirizzerà il traffico. Le chiamate API restituiranno invece un errore 503 "Il servizio non è temporaneamente disponibile".

Percorso

Il percorso definisce un frammento URI che verrà aggiunto a tutte le richieste emesse dal server di destinazione 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 runtime. 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 server di destinazione per definire il servizio di backend e quest'ultimo richiede che la connessione utilizzi il protocollo HTTPS, devi attivare TLS/SSL nella definizione del server di destinazione. Ciò è necessario perché il tag host non consente di specificare il protocollo di connessione.

Configura TLS/SSL unidirezionale

Utilizza la seguente configurazione per definire un server di destinazione con TLS/SSL unidirezionale. In questo esempio, Apigee effettua richieste HTTPS al servizio di backend:

{
  "name": "target1",
  "host": "mocktarget.apigee.net",
  "protocol": "http",
  "port": "443",
  "isEnabled": "true",
  "sSLInfo": {
    "enabled": "true"
  }
}

Configurare l'applicazione forzata rigorosa di SSL

Per specificare l'applicazione rigorosa di SSL nella definizione del server di destinazione, imposta enforce su true nel blocco sSLInfo, come mostrato nell'esempio seguente: 

  {
    "name": "target1",
    "host": "mocktarget.apigee.net",
    "protocol": "http",
    "port": "443",
    "isEnabled": "true",
    "sSLInfo": {
      "enabled": "true",
      "enforce": "true"
    }
  }

Configurare TLS/SSL bidirezionale

Se il servizio di backend richiede TLS/SSL bidirezionale o reciproco, puoi configurare il server di destinazione con le stesse impostazioni di configurazione TLS/SSL degli endpoint di destinazione:

{
  "name": "TargetServer 1",
  "host": "www.example.com",
  "protocol": "http",
  "port": "443",
  "isEnabled": "true",
  "sSLInfo": {
    "enabled": "true",
    "clientAuthEnabled": "true",
    "keyStore": "keystore-name",
    "keyAlias": "keystore-alias",
    "trustStore": "truststore-name",
    "ignoreValidationErrors": "false",
    "ciphers": []
  }
}

Configura SSL rigoroso utilizzando l'API

Per creare un server di destinazione con applicazione SSL rigorosa utilizzando una chiamata API: 

curl "https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers" \
  -X POST \
  -H "Content-Type:application/json"  \
  -H "Authorization: Bearer $TOKEN" \
  -d '
  {
    "name": "TargetServer 1",
    "host": "www.example.com",
    "protocol": "http",
    "port": 443,
    "isEnabled": true,
    "sSLInfo":
    {
      "enabled":true,
      "enforce":true,
      "clientAuthEnabled":true,
      "keyStore":"keystore-name",
      "keyAlias":"keystore-alias",
      "ciphers":[],
      "protocols":[],
      "clientAuthEnabled":true,
      "ignoreValidationErrors":false,
      "trustStore":"truststore-name"
    }
  }'

Monitoraggio dello stato di integrità

Il monitoraggio dell'integrità ti consente di migliorare le configurazioni del bilanciamento del carico eseguendo il polling attivo degli URL del servizio di backend definiti nelle configurazioni del server di destinazione. Se il monitoraggio dell'integrità è attivato, i server di destinazione che non sono raggiungibili o restituiscono una risposta di errore vengono contrassegnati come non integri. Un server di destinazione non riuscito viene rimesso automaticamente in rotazione quando il monitor di integrità determina che il server di destinazione è attivo. Non sono necessari nuovi deployment del proxy.

Un monitor di integrità funge da semplice client che richiama un servizio di backend tramite TCP o HTTP:

  • Un client TCP si limita a garantire 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 della chiamata di monitoraggio HTTP deve corrispondere alle impostazioni configurate nel blocco <SuccessResponse>.

Operazioni riuscite e non riuscite

Quando attivi il monitoraggio dello stato di integrità, Apigee 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.

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 la chiude 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 Apigee 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 Apigee 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à, Apigee incrementa il conteggio degli errori del server. Se il numero di errori per quel server raggiunge o supera una soglia predefinita (<MaxFailures>), Apigee smette di inviare richieste a quel server.

Abilitare un monitoraggio dello stato di integrità

Per creare un monitor di integrità per un proxy API, aggiungi l'elemento <HealthMonitor> all'elemento <HTTPTargetConnection dell'endpoint di destinazione per il proxy.

Non è possibile creare monitor di integrità nella UI. Invece, crei una configurazione proxy e la carichi come file ZIP su Apigee. 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.

Elementi di configurazione di <HealthMonitor>

La tabella seguente descrive gli elementi di configurazione di <HealthMonitor>:

Nome Descrizione Predefinito Obbligatorio?
IsEnabled Un valore booleano che attiva o disattiva il monitoraggio dello stato di integrità. falso No
IntervalInSec L'intervallo di tempo, in secondi, tra ogni richiesta TCP o HTTP di polling. 0 Sì
HTTPMonitor o TCPMonitor Una definizione del client TCP o HTTP da utilizzare per eseguire il polling del server di destinazione. N/D Sì

Oltre a questi elementi, l'attivazione di un monitoraggio dell'integrità richiede di impostare l'elemento <MaxFailures> nel blocco <HTTPTargetConnection> dell'elemento <TargetEndpoint> su un valore maggiore di 0. <MaxFailures> viene utilizzato per specificare il numero massimo di richieste non riuscite dal proxy API al server di destinazione che possono verificarsi prima che la richiesta venga reindirizzata a un altro server di destinazione.

Per impostazione predefinita, <MaxFailures> è 0, il che significa che Apigee non esegue alcuna azione correttiva. Quando configuri un monitor di integrità, assicurati di impostare <MaxFailures> su un valore diverso da zero.

Monitoraggio dell'integrità utilizzando il monitor TCP

Il monitor di integrità di esempio descritto nella seguente configurazione utilizza un monitor TCP per eseguire il polling di ogni server di destinazione aprendo una connessione sulla porta 80 ogni cinque secondi. La porta è facoltativa. Se non specificata, la porta di monitoraggio TCP è la porta del server di destinazione.)

In questa configurazione di monitoraggio dell'integrità di esempio:

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

Puoi aggiungere un monitoraggio dell'integrità come elemento secondario dell'elemento <HTTPTargetConnection> dell'endpoint di destinazione, 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>
</TargetEndpoint>

Elementi di configurazione di <TCPMonitor>

La tabella seguente descrive gli elementi di configurazione di <TCPMonitor>:

Nome Descrizione Predefinito Obbligatorio?
ConnectTimeoutInSec Tempo in cui deve essere stabilita la connessione alla porta TCP per essere considerata riuscita. L'impossibilità di connettersi nell'intervallo specificato viene conteggiata come errore, incrementando il conteggio degli errori del bilanciatore del carico per il server di destinazione. 0 Sì
Port Facoltativo. La porta su cui verrà stabilita la connessione TCP. Se non specificata, la porta di monitoraggio TCP è la porta del server di destinazione. 0 No

Monitoraggio dell'integrità utilizzando il monitor HTTP

Il monitor di integrità di esempio descritto nella seguente configurazione utilizza un monitor HTTP che invia una richiesta GET al servizio di backend una volta ogni cinque secondi e aggiunge un'intestazione di autenticazione di base HTTP al messaggio di richiesta.

In questa configurazione di monitoraggio dell'integrità di esempio:

  • La risposta prevista dal servizio di backend è un codice di risposta HTTP 200.
  • Il valore previsto per l'intestazione di autorizzazione di base HTTP personalizzata ImOK è YourOK.
  • L'elemento <UseTargetServerSSLInfo> è impostato su true per utilizzare i parametri SSL del blocco <SSLInfo> del server di destinazione.

Con questa configurazione, i codici di risposta e i valori delle intestazioni previsti verranno confrontati con le risposte effettive del servizio di backend. Se la risposta non corrisponde, la richiesta verrà trattata come un errore dalla configurazione del bilanciatore del carico.

Per impostazione predefinita, i monitor di integrità non possono accedere a keystore, truststore o altri parametri SSL dai server di destinazione. Per attivare l'accesso a questi parametri per il monitoraggio dell'integrità al fine di supportare TLS reciproco, ad esempio, aggiungi <UseTargetServerSSLInfo>true</UseTargetServerSSLInfo> nel blocco <Request>.

    <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>
          <HTTPMonitor>
            <Request>
              <UseTargetServerSSLInfo>true</UseTargetServerSSLInfo>
              <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>
      </HTTPTargetConnection>
    </TargetEndpoint>

Elementi di configurazione di <HTTPMonitor>

La tabella seguente descrive gli elementi di configurazione <HTTPMonitor> di primo livello:

Nome Descrizione Predefinito Obbligatorio?
Request Il messaggio di richiesta in uscita inviato dal monitor di integrità ai server di destinazione nella rotazione. N/D Sì
SuccessResponse (Facoltativo) Opzioni di corrispondenza per il messaggio di risposta HTTP in entrata generato dal servizio di backend sottoposto a polling. N/D No

Elementi di configurazione <HTTPMonitor>/<Request>

Opzioni di configurazione per il messaggio di richiesta in uscita inviato dal monitor di integrità ai server di destinazione nella rotazione. Tieni presente che <Request> è un elemento obbligatorio.

Nome Descrizione Predefinito Obbligatorio?
ConnectTimeoutInSec Tempo, in secondi, in cui l'handshake della connessione TCP al servizio HTTP deve essere completato per essere considerato riuscito. L'impossibilità di connettersi nell'intervallo specificato viene conteggiata come un errore, incrementando il conteggio degli errori del bilanciamento del carico per il server di destinazione.

0 No
SocketReadTimeoutInSec Tempo, in secondi, in cui i dati devono essere letti dal servizio HTTP per essere considerati un successo. La mancata lettura nell'intervallo specificato viene conteggiata come errore, incrementando il conteggio degli errori del bilanciatore del carico per il server di destinazione.

0 No
Port La porta su cui verrà stabilita la connessione HTTP al servizio di backend. Porta del server di destinazione No
Verb Il verbo HTTP utilizzato per ogni richiesta HTTP di polling al servizio di backend. N/D No
Path Il percorso aggiunto all'URL definito nel server di destinazione. Utilizza l'elemento Path per configurare un "endpoint di polling" sul tuo servizio HTTP. Tieni presente che l'elemento Path non supporta le variabili. N/D No
UseTargetServerSSLInfo Quando UseTargetServerSSLInfo è true, le richieste di monitoraggio dell'integrità a un server di destinazione utilizzeranno i parametri SSL del blocco SSLInfo ("sSLInfo") del server di destinazione. In caso contrario, i parametri SSL come il protocollo, il keystore, il truststore e così via non saranno disponibili per il monitoraggio dell'integrità. falso No

IncludeHealthCheckIdHeader

 Consente di monitorare le richieste di controllo dell'integrità sui sistemi upstream. IncludeHealthCheckIdHeader accetta un valore booleano e il valore predefinito è false. Se lo imposti su true, viene inserito nella richiesta di controllo di integrità un Header denominato X-Apigee-Healthcheck-Id. Il valore dell'intestazione viene assegnato dinamicamente e assume la forma ORG/ENV/SERVER_UUID/N, dove ORG è il nome dell'organizzazione, ENV è il nome dell'ambiente, SERVER_UUID è un ID univoco che identifica il MP e N è il numero di millisecondi trascorsi dal 1° gennaio 1970.

Esempio di intestazione della richiesta risultante:

X-Apigee-Healthcheck-Id: orgname/envname/E8C4D2EE-3A69-428A-8616-030ABDE864E0/1586802968123 		falso No
Payload Il corpo HTTP generato per ogni richiesta HTTP di polling. Tieni presente che questo elemento non è obbligatorio per le richieste GET. N/D No
Header Una o più intestazioni e valori HTTP previsti da ricevere dal servizio di backend sondato. Qualsiasi intestazione o valore HTTP nella risposta diverso da quelli specificati comporta un errore e il conteggio per il server di destinazione sottoposto a polling viene incrementato di 1. Puoi definire più elementi di intestazione. N/D No
IsSSL Se il valore è true, specifica che la richiesta di monitoraggio dell'integrità deve essere inviata utilizzando HTTPS. Falso No
TrustAllSSL Specifica se il controllo del monitor HTTP considererà automaticamente attendibili tutti i certificati SSL. Falso No

Elementi di configurazione <HTTPMonitor>/<SuccessResponse>

(Facoltativo) Opzioni di corrispondenza per il messaggio di risposta HTTP in entrata generato dal servizio di backend sottoposto a polling. Le risposte che non corrispondono aumentano di 1 il conteggio degli errori.

Nome Descrizione Predefinito Obbligatorio?
ResponseCode Il codice di risposta HTTP previsto dal server di destinazione sottoposto a polling. Un codice diverso da quello specificato comporta un errore e l'incremento del conteggio per il servizio di backend sottoposto a polling. Puoi definire più elementi ResponseCode. N/D No
Header Una o più intestazioni e valori HTTP previsti da ricevere dal servizio di backend sondato. Qualsiasi intestazione o valore HTTP nella risposta diverso da quelli specificati comporta un errore e il conteggio per il server di destinazione sottoposto a polling viene incrementato di 1. Puoi definire più elementi di intestazione. N/D No