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 il supporto integrato per il bilanciamento del carico e il failover su più istanze di server di backend.

I server di destinazione disaccoppiano gli URL degli endpoint specifici dalle configurazioni degli endpoint di destinazione. Anziché definire un URL specifico nella configurazione, puoi configurare uno o più server target denominati. Poi, a ogni server di destinazione viene fatto riferimento per nome in un endpoint di destinazione HTTPConnection.

Video

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

Video Descrizione
Bilanciamento del carico mediante server target API di bilanciamento del carico sui server target.
Routing delle API in base all'ambiente che utilizza i server target Indirizza 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 di TargetServer e di altre entità su GitHub.

Creazione di server di destinazione

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

Apigee nella console Cloud

Per creare i server di destinazione utilizzando Apigee nella console Cloud:

  1. Accedi all'interfaccia utente di Apigee nella console Cloud.
  2. Seleziona Gestione > Ambienti.
  3. Seleziona l'ambiente in cui vuoi definire un nuovo server di destinazione.
  4. Fai clic su Server di destinazione nella parte superiore del riquadro.
  5. Fai clic su + Crea server di destinazione.

  6. Inserisci un nome, un host, un protocollo e una porta nei campi a disposizione. Le opzioni per Protocollo sono: HTTP per i server di destinazione basati su REST, gRPC - Target per i server di destinazione basati su gRPC o gRPC - Callout esterno. Consulta Creare proxy API gRPC per informazioni sul supporto dei proxy gRPC.

    Se vuoi, puoi selezionare Attiva SSL. Consulta la panoramica dei certificati SSL.

  7. Fai clic su Crea.

Apigee classica

Per creare i server di destinazione utilizzando l'interfaccia utente Apigee classica:

  1. Accedi all'interfaccia utente di Apigee.
  2. Seleziona Amministrazione > Ambienti > TargetServer.
  3. Nell'elenco a discesa Ambiente, seleziona l'ambiente per cui vuoi definire un nuovo server di destinazione.

    L'interfaccia utente di Apigee mostra un elenco dei server target correnti 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 averlo creato.

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

    Se vuoi, puoi selezionare la casella di controllo SSL. Per ulteriori informazioni su questi campi, consulta 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 target.

Per maggiori informazioni, consulta l'API TargetServers.

Creazione di un server di destinazione in un ambiente mediante 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 Utilizzare curl. Per una descrizione delle variabili di ambiente utilizzate, consulta Impostazione delle variabili di ambiente per le richieste dell'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. Se definisci 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 target 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 che possono essere utilizzati dai 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 per utilizzare i server di destinazione.

Configurazione di un endpoint target per il bilanciamento del carico tra server target denominati

Ora che hai due server di destinazione disponibili, puoi modificare l'elemento <HTTPTargetConnection> dell'endpoint di destinazione in modo da fare riferimento ai 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: 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 target2.

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

Per ulteriori informazioni, 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 di 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 è descritto 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 tuoi server di destinazione. Il bilanciatore del carico ponderato distribuisce le richieste ai server target in proporzione diretta al peso di ciascun server target. Pertanto, l'algoritmo ponderato richiede di impostare un attributo weight per ogni server target. 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 a target1 ne verranno inoltrate due a 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 al server di destinazione che comporta il reindirizzamento della richiesta a un altro server di destinazione.

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 404 o 500), viene conteggiata come risposta del server di destinazione e il contatore degli errori viene reimpostato. Per 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. Apigee conteggia anche le risposte con questi codici come errori.

Nel seguente esempio, target1 verrà rimosso dalla rotazione dopo cinque richieste non riuscite, tra cui 404 e 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>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 al target per ogni richiesta e non rimuove mai il server target dalla rotazione.

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

Tieni presente che sia le chiamate API regolari sia quelle avviate da un monitor di integrità verranno conteggiate ai fini del conteggio di MaxFailures.

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

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 riprovare è 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 server di destinazione come server di riserva. Il bilanciatore del carico non utilizzerà il server di riserva finché tutti gli altri server di destinazione non saranno stati rimossi dalla rotazione dal bilanciatore del carico. In questo caso, tutto il traffico viene indirizzato al server di riserva fino a quando uno degli altri server di destinazione non viene segnalato di nuovo come funzionante e viene reintegrato 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 riportata sopra comporta il bilanciamento del carico Round Robin tra target1 e target2 finché entrambi target1 e 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 verso di esso. Le chiamate API restituiranno invece un errore 503 "Il servizio non è temporaneamente disponibile".

Percorso

Path definisce un frammento URI che verrà aggiunto a tutte le richieste inviate 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 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 server di destinazione 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 del server di destinazione. Questo è 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 invia 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 del protocollo 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": []
  }
}

Configurare SSL rigoroso utilizzando l'API

Per creare un server di destinazione con applicazione rigorosa di SSL 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 di bilanciamento del carico eseguendo il polling attivo degli URL dei servizio di backend definiti nelle configurazioni del server di destinazione. Con il monitoraggio dell'integrità abilitato, i server di destinazione che non sono raggiungibili o che restituiscono una risposta di errore sono contrassegnati come non integri. Un server di destinazione non riuscito viene reintegrato automaticamente nella rotazione quando il monitoraggio dell'integrità determina che il server di destinazione è attivo. Non sono necessari nuovi deployment dei proxy.

Un monitor di integrità 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à, 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 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 si verifica 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 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 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 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à, 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.

Attivazione di un monitor dello stato di integrità

Per creare un monitoraggio dell'integrità per un proxy API, aggiungi l'elemento <HealthMonitor> alla configurazione dell'elemento <HTTPTargetConnection dell'endpoint target per il proxy.

Non è possibile creare monitor di integrità nell'interfaccia utente. Devi invece creare una configurazione proxy e caricarla come file ZIP in 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 <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 dello stato richiede l'impostazione dell'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 della salute, assicurati di impostare<MaxFailures> su un valore diverso da zero.

Monitor di integrità che utilizza il monitor TCP

Il monitor di stato di esempio descritto nella configurazione seguente 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 specificato, la porta del monitor TCP è la porta del server di destinazione.

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

  • Se la connessione non riesce o se la connessione richiede più di 10 secondi, il conteggio degli errori aumenta di 1 per il server target.
  • Se la connessione va a buon fine, 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 <TCPMonitor>:

Nome Descrizione Predefinito Obbligatorio?
ConnectTimeoutInSec Tempo entro il quale deve essere stabilita la connessione alla porta TCP per essere considerata riuscita. La mancata connessione nell'intervallo specificato viene conteggiata come un 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 specificato, la porta del monitor TCP è la porta del server di destinazione. 0 No

Monitor di integrità che utilizza il monitor HTTP

Il monitoraggio dell'integrità di esempio descritto nella configurazione seguente utilizza un monitoraggio HTTP che invia una richiesta GET al servizio di backend ogni cinque secondi e aggiunge un'intestazione di autorizzazione 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 HTTP Authorization di base personalizzata ImOK è YourOK.
  • L'elemento <UseTargetServerSSLInfo> è impostato su true per utilizzare i parametri SSL dal blocco <SSLInfo> del server di destinazione.

Con questa configurazione, i codici di risposta e i valori dell'intestazione previsti verranno confrontati con le risposte effettive del servizio di backend. Se la risposta non corrisponde, la richiesta verrà considerata 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 consentire l'accesso a questi parametri per il monitoraggio dell'integrità in modo da supportare TLS mutuale, 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 monitoraggio dell'integrità ai server di destinazione nella rotazione. Tieni presente che <Request> è un elemento obbligatorio.

Nome Descrizione Predefinito Obbligatorio?
ConnectTimeoutInSec Tempo, in secondi, entro il quale deve essere completata la procedura di handshake della connessione TCP al servizio HTTP per essere considerata riuscita. Il mancato collegamento nell'intervallo specificato viene conteggiato come un errore, incrementando il conteggio degli errori di LoadBalancer per il server di destinazione.

0 No
SocketReadTimeoutInSec Tempo, in secondi, entro il quale 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 dello stato a un server di destinazione useranno 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

 Ti consente di monitorare le richieste di controllo dell'integrità sui sistemi a monte. IncludeHealthCheckIdHeader accetta un valore booleano e il valore predefinito è false. Se lo imposti su true, esiste un Header denominato X-Apigee-Healthcheck-Id che viene inserito nella richiesta di controllo di integrità. Il valore dell'intestazione viene assegnato dinamicamente e ha il formato 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 Uno o più valori e intestazioni HTTP che dovrebbero essere ricevuti dal servizio di backend sottoposto a polling. Eventuali intestazioni o valori HTTP nella risposta diversi da quelli specificati generano un errore e il conteggio del server di destinazione sottoposto a polling viene incrementato di 1. Puoi definire più elementi Header. N/D No
IsSSL Se true, specifica che la richiesta di monitoraggio dell'integrità venga inviata utilizzando HTTPS. Falso No
TrustAllSSL Specifica se il controllo del monitoraggio HTTP considererà attendibili automaticamente 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 il conteggio degli errori di 1.

Nome Descrizione Predefinito Obbligatorio?
ResponseCode Il codice di risposta HTTP che dovrebbe essere ricevuto dal server di destinazione sottoposto a polling. Un codice diverso da quello specificato genera un errore e il conteggio viene incrementato per il servizio di backend sottoposto a polling. Puoi definire più elementi ResponseCode. N/D No
Header Uno o più valori e intestazioni HTTP che dovrebbero essere ricevuti dal servizio di backend sottoposto a polling. Eventuali intestazioni o valori HTTP nella risposta diversi da quelli specificati generano un errore e il conteggio del server di destinazione sottoposto a polling viene incrementato di 1. Puoi definire più elementi Header. N/D No