Google Cloud offre controlli dell'integrità configurabili per i backend dei bilanciatori del carico di Google Cloud, i backend di Cloud Service Mesh e la correzione automatica basata sulle applicazioni per i gruppi di istanze gestite. Questo documento illustra i concetti chiave relativi ai controlli di salute.
Se non diversamente indicato, i controlli di integrità di Google Cloud vengono implementati da attività software dedicate che si connettono ai backend in base ai parametri specificati in una risorsa di controllo di integrità. Ogni tentativo di connessione è chiamato sondaggio. Google Cloud registra l'esito positivo o negativo di ogni prova.
In base a un numero configurabile di sondaggi sequenziali riusciti o non riusciti, viene calcolato uno stato di integrità complessivo per ogni backend. I backend che rispondono correttamente per il numero di volte configurato sono considerati integri. I backend che non rispondono correttamente per un numero di volte configurabile separatamente sono non validi.
Lo stato di integrità complessivo di ciascun backend determina l'idoneità a ricevere nuove richieste o connessioni. Puoi configurare i criteri che definiscono un'indagine riuscita. Questo aspetto è trattato in dettaglio nella sezione Come funzionano i controlli di salute.
I controlli di integrità implementati da attività software dedicate utilizzano route speciali che non sono definite nella rete Virtual Private Cloud (VPC). Per ulteriori informazioni, consulta Percorsi per i controlli di integrità.
Protocolli, porte e categorie per il controllo di integrità
I controlli di integrità hanno una categoria e un protocollo. Le due categorie sono controlli di integrità e controlli di integrità legacy e i relativi protocolli supportati sono i seguenti:
Controlli di integrità
Controlli di integrità legacy:
Il protocollo e la porta determinano il modo in cui vengono eseguiti i probe di controllo di integrità. Ad esempio, un controllo di integrità può utilizzare il protocollo HTTP sulla porta TCP 80 oppure il protocollo TCP per una porta denominata in un gruppo di istanze.
Non puoi convertire un controllo di integrità legacy in un controllo di integrità e non puoi convertire un controllo di integrità in un controllo di integrità legacy.
Seleziona un controllo di integrità
I controlli di integrità devono essere compatibili con il tipo di bilanciatore del carico (o Cloud Service Mesh) e con i tipi di backend. I fattori da considerare quando selezioni un controllo di integrità sono i seguenti:
- Categoria: controllo di integrità o controllo di integrità legacy. Solo i bilanciatori del carico di rete passthrough esterni basati su pool di destinazione require i controlli di integrità precedenti. Per tutti gli altri prodotti, utilizzerai i controlli di salute di routine.
- Protocollo:il protocollo utilizzato da Google Cloud per eseguire la sonda dei backend. È preferibile utilizzare un controllo di integrità (o un controllo di integrità precedente) il cui protocollo corrisponde al protocollo utilizzato dal servizio di backend o dal pool di destinazione del bilanciatore del carico. Tuttavia, i protocolli di controllo di integrità e i protocolli del bilanciatore del carico non devono essere necessariamente gli stessi.
- Specifica porta: le porte utilizzate da Google Cloud con il protocollo.
Devi specificare una porta per il controllo di integrità. I controlli di integrità hanno due metodi di specifica della porta:
--porte--use-serving-port. Per i controlli di idoneità legacy, è disponibile un solo metodo:--port. Per ulteriori informazioni sui requisiti delle porte per controllo di integrità per bilanciatore del carico, consulta Flag di specifica della porta.
La sezione successiva descrive le selezioni valide per controllo di integrità per ogni tipo di bilanciatore del carico e backend.
Guida al bilanciatore del carico
Questa tabella mostra la categoria e l'ambito dei controllo di integrità supportati per ogni tipo di bilanciatore del carico.
| Modalità del bilanciatore del carico | Controlli di integrità legacy supportati |
|---|---|
Bilanciatore del carico delle applicazioni esterno globale Bilanciatore del carico delle applicazioni classico |
Sì, se entrambe le seguenti condizioni sono vere:
|
| Bilanciatore del carico delle applicazioni esterno regionale | No |
Note aggiuntive sull'utilizzo
Per i backend dei gruppi di istanze VM, i controlli di integrità vengono eseguiti solo sulle istanze VM avviate. Le istanze VM arrestate non ricevono i pacchetti di controllo di integrità.
Per i bilanciatori del carico di rete passthrough interni, puoi utilizzare solo
TCPoUDPper il protocollo del servizio di backend. Se servi traffico HTTP da VM dietro un bilanciatore del carico di rete passthrough interno, ha senso utilizzare un controllo di integrità che utilizza il protocollo HTTP.Un bilanciatore del carico di rete passthrough esterno basato su pool di destinazione deve utilizzare un controllo di integrità HTTP precedente. Non può utilizzare un controllo di integrità HTTPS legacy o qualsiasi controllo di integrità non legacy. Se utilizzi un bilanciatore del carico di rete passthrough esterno basato su pool di destinazione per bilanciare il traffico TCP, devi eseguire un servizio HTTP sulle VM bilanciate in modo che possano rispondere ai controlli di salute.
Per quasi tutti gli altri tipi di bilanciatori del carico, devi utilizzare controlli di integrità regolari e non legacy in cui il protocollo corrisponde al protocollo del servizio di backend del bilanciatore del carico.Per i servizi di backend che utilizzano il protocollo gRPC, utilizza solo i controlli di stato gRPC o TCP. Non utilizzare controlli di integrità HTTP(S) o HTTP/2.
Alcuni bilanciatori del carico basati su Envoy che utilizzano backend NEG ibridi non supportano i controlli di integrità gRPC. Per ulteriori informazioni, consulta la panoramica dei gruppi di istanze gestite ibride.
Controllo dell'integrità con Cloud Service Mesh
Tieni presente le seguenti differenze di comportamento quando utilizzi i controlli di integrità con Cloud Service Mesh.
Con Cloud Service Mesh, il comportamento dei controlli di integrità per gli endpoint di rete di tipo
INTERNET_FQDN_PORTeNON_GCP_PRIVATE_IP_PORTè diverso da quello per altri tipi di endpoint di rete. Anziché utilizzare le attività software dedicate, Cloud Service Mesh programma i proxy Envoy per eseguire controlli di salute per i NEG di internet (endpointINTERNET_FQDN_PORT) e i NEG ibridi (endpointNON_GCP_PRIVATE_IP_PORT).Envoy supporta i seguenti protocolli per i controlli di integrità:
- HTTP
- HTTPS
- HTTP/2
- TCP
Quando Cloud Service Mesh è integrato con Service Directory e lieghe un servizio Service Directory a un servizio di backend Cloud Service Mesh, non puoi impostare un controllo di integrità dell'integrità sul servizio di backend.
Come funzionano i controlli di integrità
Le sezioni seguenti descrivono il funzionamento dei controlli di stato.
Probe
Quando crei un controllo di integrità o un controllo di integrità precedente, specifica i seguenti flag o accetta i relativi valori predefiniti. Ogni controllo di integrità o controllo di integrità precedente che crei viene implementato da più sonde. Questi flag controllano la frequenza con cui ogni probed valuta le istanze nei gruppi di istanze o negli endpoint nei NEG a livello di zona.
Le impostazioni di un controllo di integrità non possono essere configurate in base al backend. I controlli di integrità sono associati a un intero servizio di backend. Per un bilanciatore del carico di rete passthrough esterno basato su pool di destinazione, un controllo di integrità HTTP legacy è associato all'intero pool di destinazione. Pertanto, i parametri per la sonda sono gli stessi per tutti i backend a cui fa riferimento un determinato servizio di backend o pool di destinazione.
| Flag di configurazione | Finalità | Valore predefinito |
|---|---|---|
Intervallo di controllocheck-interval |
L'intervallo di controllo è il periodo di tempo che intercorre dall'inizio di un controllo emesso da un prober all'inizio del controllo successivo emesso dallo stesso prober. Le unità di misura sono in secondi. | 5s (5 secondi) |
Timeouttimeout |
Il timeout è il periodo di tempo che Google Cloud attende per ricevere una risposta a una sonda. Il valore deve essere minore o uguale all'intervallo di controllo. Le unità di misura sono in secondi. | 5s (5 secondi) |
Esaminare gli intervalli IP e le regole del firewall
Affinché i controlli di integrità funzionino, devi creare regole firewall allow in entrata in modo che il traffico proveniente dai controllori di Google Cloud possa connettersi ai tuoi backend. Per le istruzioni, consulta Creare le regole firewall.
La tabella seguente mostra gli intervalli IP di origine da consentire per ogni bilanciatore del carico:
| Prodotto | Intervalli di indirizzi IP di origine dei probe del controllo di integrità |
|---|---|
|
Per il traffico IPv6 verso i backend:
|
|
Per il traffico IPv6 verso i backend:
|
|
|
| Bilanciatore del carico di rete passthrough esterno 3 |
Per il traffico IPv4 verso i backend:
Per il traffico IPv6 verso i backend:
|
| Bilanciatore del carico di rete passthrough interno |
Per il traffico IPv4 verso i backend:
Per il traffico IPv6 verso i backend:
|
| Cloud Service Mesh con backend NEG internet e backend NEG ibridi | Indirizzi IP delle VM su cui è in esecuzione il software Envoy Per una configurazione di esempio, consulta la documentazione di Cloud Service Mesh. |
1 L'inserimento nella lista consentita degli intervalli di probe del controllo di integrità di Google non è obbligatorio per i NEG ibridi. Tuttavia, se utilizzi una combinazione di NEG ibridi e zonali in un singolo servizio di backend, devi inserire nella lista consentita gli intervalli di sonde di controllo di integrità di Google per i NEG zonali.
2 Per i NEG internet a livello di regione, i controlli di integrità sono facoltativi. Il traffico proveniente dai bilanciatori del carico che utilizzano NEG internet a livello di regione ha origine dalla subnet solo proxy e viene poi sottoposto a traduzione NAT (utilizzando Cloud NAT) in indirizzi IP NAT manuali o allocati automaticamente. Questo traffico include sia i probe del controllo di integrità sia le richieste degli utenti dal bilanciatore del carico ai backend. Per maggiori dettagli, consulta NEG regionali: utilizzare Cloud NAT per l'egress.
3 I bilanciatori del carico di rete passthrough esterni basati su pool di destinazione supportano solo il traffico IPv4 e potrebbero eseguire il proxy dei controlli di integrità tramite il server di metadati. In questo caso,
le origini dei pacchetti del controllo di integrità corrispondono all'indirizzo IP del server dei metadati:
169.254.169.254. Non è necessario creare regole del firewall per consentire il traffico dal server dei metadati. I pacchetti provenienti dal
server dei metadati sono sempre consentiti.
L'importanza delle regole firewall
Google Cloud richiede di creare le regole firewall allow
in entrata necessarie per consentire il traffico dai sondaggi ai tuoi backend. Come best practice, limita queste regole solo ai protocolli e alle porte corrispondenti a quelli utilizzati dai controlli di integrità. Per gli intervalli IP di origine, assicurati di utilizzare gli intervalli IP delle sonde documentati elencati nella sezione precedente.
Se non disponi di regole firewall allow in entrata che consentano il controllo di integrità,
la regola deny implicita blocca
il traffico in entrata. Quando i prober non riescono a contattare i tuoi backend, il bilanciatore del carico li considera non operativi.
Considerazioni sulla sicurezza per gli intervalli IP di ispezione
Tieni presente le seguenti informazioni durante la pianificazione dei controlli di integrità e delle regole firewall necessarie:
Gli intervalli IP delle sonde appartengono a Google. Google Cloud utilizza route speciali al di fuori della rete VPC, ma all'interno della rete di produzione di Google, per facilitare la comunicazione da parte dei tester.
Google utilizza gli intervalli IP dei probe per inviare probe di controllo di integrità per bilanciatori del carico delle applicazioni esterni e bilanciatori del carico di rete con proxy esterni. Se un pacchetto viene ricevuto da internet e l'indirizzo IP di origine del pacchetto rientra in un intervallo IP di una sonda, Google lo ignora. Sono inclusi l'indirizzo IP esterno di un'istanza Compute Engine o di un nodo Google Kubernetes Engine (GKE).
Gli intervalli IP dei controlli sono un insieme completo di indirizzi IP possibili utilizzati dai controlli di Google Cloud. Se utilizzi
tcpdumpo uno strumento simile, potresti non osservare il traffico da tutti gli indirizzi IP in tutti gli intervalli IP del probe. Come best practice, crea regole firewall in entrata che consentano tutti gli intervalli IP dei probe come origini. Google Cloud può implementare nuovi sondaggi automaticamente senza invio di notifiche.
Più sonde e frequenza
Google Cloud invia probe di controllo di integrità da più sistemi ridondanti chiamati prober. I sondaggi utilizzano intervalli IP di origine specifici. Google Cloud non si basa su un solo prober per implementare un controllo di integrità: più prober valutano contemporaneamente le istanze nei backend dei gruppi di istanze o gli endpoint nei backend dei NEG zonali. Se un prober non va a buon fine, Google Cloud continua a monitorare gli stati di integrità del backend.
Le impostazioni di intervallo e timeout che configuri per un controllo di integrità vengono applicate a ogni sonda. Per un determinato backend, i log di accesso al software e
tcpdump mostrano sondaggi più frequenti rispetto alle impostazioni configurate.
Si tratta di un comportamento previsto e non puoi configurare il numero di sondaggi che Google Cloud utilizza per i controlli di integrità. Tuttavia, puoi stimare l'effetto di più sonde simultanee tenendo conto dei seguenti fattori.
Per stimare la frequenza di controllo per servizio di backend, tieni presente quanto segue:
Frequenza di base per servizio di backend. A ogni controllo di integrità è associata una frequenza di controllo, inversamente proporzionale all'intervallo di controllo configurato:
1⁄(intervallo di controllo)
Quando associ un controllo di integrità a un servizio di backend, stabilisci una frequenza di base utilizzata da ogni prober per i backend su quel servizio di backend.
Fattore di scala della sonda. La frequenza di base del servizio di backend viene moltiplicata per il numero di sondaggi simultanei utilizzati da Google Cloud. Questo numero può variare, ma in genere è compreso tra 5 e 10.
Più regole di inoltro per i bilanciatori del carico di rete passthrough interni. Se hai configurato più regole di inoltro interno (ciascuna con un indirizzo IP diverso) che rimandano allo stesso servizio di backend interno regionale, Google Cloud utilizza più sondatori per controllare ogni indirizzo IP. La frequenza di indagine per servizio di backend viene moltiplicata per il numero di regole di inoltro configurate.
Più regole di inoltro per i bilanciatori del carico di rete passthrough esterni. Se hai configurato più regole di inoltro che rimandano allo stesso servizio di backend o allo stesso pool di destinazione, Google Cloud utilizza più sondatori per controllare ogni indirizzo IP. La frequenza del probe per VM di backend viene moltiplicata per il numero di regole di inoltro configurate.
Più proxy target per i bilanciatori del carico delle applicazioni esterni. Se hai più proxy di destinazione che indirizzano il traffico alla stessa mappa URL, Google Cloud utilizza più sondatori per controllare l'indirizzo IP associato a ciascun proxy di destinazione. La frequenza di controllo per servizio di backend viene moltiplicata per il numero di proxy di destinazione configurati.
Più proxy di destinazione per bilanciatori del carico di rete proxy esterni e bilanciatori del carico di rete proxy interni regionali. Se hai configurato più proxy target che indirizzano il traffico allo stesso servizio di backend, Google Cloud utilizza più sondatori per controllare l'indirizzo IP associato a ciascun proxy target. La frequenza di controllo per servizio di backend viene moltiplicata per il numero di proxy target configurati.
Somma per i servizi di backend. Se un backend viene utilizzato da più servizi di backend, le istanze di backend vengono contattate con la frequenza pari alla somma delle frequenze per il controllo di integrità di ciascun servizio di backend.
Con i backend NEG zonali, è più difficile determinare il numero esatto di verifiche di salute. Ad esempio, lo stesso endpoint può essere presente in più NEG zonali. Questi NEG zonali non hanno necessariamente lo stesso insieme di endpoint e endpoint diversi possono puntare allo stesso backend.
Destinazione per i pacchetti di prova
La tabella seguente mostra l'interfaccia di rete e gli indirizzi IP di destinazione a cui i probe del controllo di integrità inviano i pacchetti, a seconda del tipo di bilanciatore del carico.
Per i bilanciatori del carico di rete passthrough esterni e i bilanciatori del carico di rete passthrough interni, l'applicazione deve essere associata all'indirizzo IP del bilanciatore del carico (o a qualsiasi indirizzo IP 0.0.0.0).
| Bilanciatore del carico | Interfaccia di rete di destinazione | Indirizzo IP di destinazione |
|---|---|---|
|
|
|
|
|
|
| Bilanciatore del carico di rete passthrough esterno | Interfaccia di rete principale (nic0) |
L'indirizzo IP della regola di forwarding esterno. Se più regole di inoltro rimandano allo stesso servizio di backend (per i bilanciatori del carico di rete passthrough esterni basati su pool di destinazione, lo stesso pool di destinazione), Google Cloud invia sonde all'indirizzo IP di ogni regola di forwarding. Ciò può comportare un aumento del numero di sonde. |
| Bilanciatore del carico di rete passthrough interno | Sia per i backend di gruppi di istanze sia per i backend NEG zonali con endpoint GCE_VM_IP, l'interfaccia di rete utilizzata dipende dalla configurazione del servizio di backend. Per maggiori dettagli, consulta
Servizi di backend
e interfacce di rete.
|
L'indirizzo IP della regola di forwarding interna. Se più regole di inoltro rimandano allo stesso servizio di backend, Google Cloud invia sondaggi all'indirizzo IP di ogni regola di forwarding. Ciò può comportare un aumento del numero di sonde. |
Criteri di successo per HTTP, HTTPS e HTTP/2
I controlli di integrità HTTP, HTTPS e HTTP/2 richiedono sempre di ricevere un codice risposta HTTP 200 (OK) prima del timeout del controllo di integrità. Tutti gli altri codici di risposta HTTP, inclusi i codici di risposta di reindirizzamento come 301 e 302, sono considerati non sicuri.
Oltre a richiedere un codice di risposta HTTP 200 (OK), puoi:
Configura ogni sonda di controllo di integrità dell'integrità in modo che invii richieste HTTP a un percorso della richiesta specifico anziché al percorso della richiesta predefinito,
/.Configura ogni sondatore del controllo di integrità per verificare la presenza di una stringa di risposta prevista nel corpo della risposta HTTP. La stringa di risposta prevista deve essere composta solo da caratteri ASCII stampabili a un byte, che si trovano nei primi 1024 byte del corpo della risposta HTTP.
La tabella seguente elenca le combinazioni valide di indicatori di percorso della richiesta e di risposta che sono disponibili per i controlli di integrità HTTP, HTTPS e HTTP/2.
| Flag di configurazione | Comportamento del validatore | Criteri di successo |
|---|---|---|
Né --request-path né --response
specificati
|
Lo strumento di analisi utilizza / come percorso della richiesta. |
Solo codice di risposta HTTP 200 (OK). |
Sono stati specificati sia --request-path che --response
|
Lo strumento di analisi utilizza il percorso della richiesta configurato. | Il codice di risposta HTTP 200 (OK) e fino ai primi
1024 caratteri ASCII del corpo della risposta HTTP devono corrispondere alla stringa di risposta prevista. |
Solo --response specificato
|
Lo strumento di analisi utilizza / come percorso della richiesta. |
Il codice di risposta HTTP 200 (OK) e fino ai primi
1024 caratteri ASCII del corpo della risposta HTTP devono corrispondere alla stringa di risposta prevista. |
Solo --request-path specificato
|
Lo strumento di analisi utilizza il percorso della richiesta configurato. | Solo codice di risposta HTTP 200 (OK). |
Criteri di successo per SSL e TCP
I controlli di integrità TCP e SSL hanno i seguenti criteri di successo di base:
Per i controlli di integrità TCP, un prober del controllo di integrità deve aprire correttamente una connessione TCP al backend prima del timeout del controllo di integrità.
Per i controlli di integrità SSL, un prober del controllo di integrità deve aprire correttamente una connessione TCP al backend e completare l'handshake TLS/SSL prima del timeout del controllo di integrità.
Per i controlli di integrità TCP, la connessione TCP deve essere chiusa in uno dei modi seguenti:
- Il probe del controllo di integrità invia un pacchetto FIN o RST (reset) oppure
- Il backend invia un pacchetto FIN. Se un backend invia un pacchetto TCP RST, la sonda potrebbe essere considerata non riuscita se il sondatore del controllo di integrità ha già inviato un pacchetto FIN.
La tabella seguente elenca le combinazioni valide di flag di richiesta e risposta disponibili per i controlli di integrità TCP e SSL. Sia gli indicatori di richiesta che quelli di risposta devono essere costituiti solo da caratteri ASCII stampabili a un byte, con ogni stringa che non deve superare i 1024 caratteri.
| Flag di configurazione | Comportamento del validatore | Criteri di successo |
|---|---|---|
Né --request né --response specificati
|
Lo strumento di analisi non invia alcuna stringa di richiesta. | Solo criteri di successo di base. |
Sono stati specificati sia --request che --response
|
Il prober invia la stringa di richiesta configurata. | I criteri di successo di base e la stringa di risposta ricevuta dal sondaggiatore devono corrispondere esattamente alla stringa di risposta prevista. |
Solo --response specificato
|
Lo strumento di analisi non invia alcuna stringa di richiesta. | I criteri di successo di base e la stringa di risposta ricevuta dal sondaggiatore devono corrispondere esattamente alla stringa di risposta prevista. |
Solo --request specificato
|
Il prober invia la stringa di richiesta configurata. | Solo criteri di successo di base (nessuna stringa di risposta viene controllata). |
Criteri di successo per gRPC
Se utilizzi i controlli di integrità gRPC, assicurati che il servizio gRPC invii la risposta RPC con lo stato OK e il campo stato impostato su SERVING o NOT_SERVING di conseguenza.
Tieni presente quanto segue:
- I controlli di integrità gRPC vengono utilizzati solo con le applicazioni gRPC e Cloud Service Mesh.
- I controlli di integrità gRPC non supportano TLS.
Per ulteriori informazioni, consulta le seguenti risorse:
Criteri di successo per i controlli di integrità legacy
Se la risposta ricevuta dal probe del controllo di integrità precedente è HTTP 200 OK,
la verifica viene considerata riuscita. Tutti gli altri codici di risposta HTTP, incluso un reindirizzamento (301, 302), sono considerati non corretti.
Stato di integrità
Google Cloud utilizza i seguenti flag di configurazione per determinare lo stato di integrità complessivo di ciascun backend a cui viene bilanciato il traffico.
| Flag di configurazione | Finalità | Valore predefinito |
|---|---|---|
Soglia stato integrohealthy-threshold |
La soglia di stato integro specifica il numero di risultati di verifica consecutivi riusciti affinché un backend sia considerato integro. | Una soglia di 2
probe. |
Soglia di stato non integrounhealthy-threshold |
La soglia di stato non integro specifica il numero di risultati di sondaggi consecutivi non riusciti per cui un backend è considerato non integro. | Una soglia di 2
probe. |
Google Cloud considera i backend integri dopo aver raggiunto questa soglia di integrità. I backend integri sono idonei a ricevere nuove connessioni.
Google Cloud considera i backend non integri quando viene raggiunta la soglia di non integrità. I backend non integri non sono idonei a ricevere nuove connessioni. Tuttavia, le connessioni esistenti non vengono interrotte immediatamente. La connessione rimane aperta fino a quando non si verifica un timeout o fino a quando il traffico non viene abbandonato.
Le connessioni esistenti potrebbero non restituire risposte, a seconda della causa del fallimento della sonda. Un backend non integro può diventare integro se è in grado di soddisfare nuovamente la soglia di integrità.
Il comportamento specifico quando tutti i backend non sono operativi varia a seconda del tipo di bilanciatore del carico in uso:
| Bilanciatore del carico | Comportamento quando tutti i backend non sono integri |
|---|---|
| Bilanciatore del carico delle applicazioni classico | Restituisce ai client un codice di stato HTTP "502" quando tutti i backend non sono operativi. |
|
Bilanciatore del carico delle applicazioni esterno globale Bilanciatore del carico delle applicazioni interno tra regioni Bilanciatore del carico delle applicazioni esterno regionale Bilanciatore del carico delle applicazioni interno regionale |
Restituisce ai client un codice di stato HTTP "503" quando tutti i backend non sono operativi. |
| Bilanciatori del carico di rete proxy | Termina le connessioni client quando tutti i backend non sono integri. |
| Bilanciatore del carico di rete passthrough interno Bilanciatori del carico di rete passthrough esterni basati sui servizi di backend |
Distribuisci il traffico a tutte le VM di backend come ultima risorsa quando tutti i backend non sono integri e il failover non è configurato. Per ulteriori informazioni su questo comportamento, consulta Distribuzione del traffico per i bilanciatori del carico di rete passthrough interni e Distribuzione del traffico per i bilanciatori del carico di rete passthrough esterni basati su servizi di backend. |
| Bilanciatori del carico di rete passthrough esterni basati su pool di destinazione | Distribuisci il traffico a tutte le VM di backend come ultima risorsa quando tutti i backend non sono integri. |
Note aggiuntive
Le sezioni seguenti includono alcune altre note sull'utilizzo dei controlli di integrità su Google Cloud.
Certificati e controlli di integrità
I controlli di salute di Google Cloud non eseguono la convalida dei certificati, anche per i protocolli che richiedono l'utilizzo di certificati (SSL, HTTPS e HTTP/2), ad esempio:
- Puoi utilizzare certificati autofirmati o certificati firmati da qualsiasi autorità di certificazione (CA).
- Sono accettabili i certificati scaduti o non ancora validi.
- Né l'attributo
CNné l'attributosubjectAlternativeNamedevono corrispondere a un'intestazioneHosto a un record PTR DNS.
Intestazioni
I controlli di integrità che utilizzano qualsiasi protocollo, ma non i controlli di integrità legacy, ti consentono di impostare un'intestazione proxy utilizzando il flag --proxy-header.
I controlli di integrità che utilizzano i protocolli HTTP, HTTPS o HTTP/2 e i controlli di integrità legacy ti consentono di specificare un'intestazione HTTP Host utilizzando il flag --host.
Se utilizzi intestazioni delle richieste personalizzate, tieni presente che il bilanciatore del carico aggiunge queste intestazioni solo alle richieste del client, non ai controlli di integrità. Se il tuo backend richiede un'intestazione specifica per l'autorizzazione mancante nel pacchetto del controllo di integrità, il controllo potrebbe non riuscire.
Esempio di controllo di integrità
Supponiamo di configurare un controllo di integrità con le seguenti impostazioni:
- Intervallo: 30 secondi
- Timeout: 5 secondi
- Protocollo: HTTP
- Soglia di stato non integro: 2 (valore predefinito)
- Soglia di stato integro: 2 (valore predefinito)
Con queste impostazioni, il controllo di integrità si comporta nel seguente modo:
- Più sistemi ridondanti vengono configurati contemporaneamente con i parametri di controllo di integrità'integrità. Le impostazioni di intervallo e timeout vengono applicate a ogni sistema. Per ulteriori informazioni, consulta Più sonde e frequenza.
Ogni sonda di controllo di integrità esegue le seguenti operazioni:
- Avvia una connessione HTTP da uno degli indirizzi IP di origine all'istanza di backend ogni 30 secondi.
- Attende fino a cinque secondi per un codice di stato HTTP
200 (OK)(i criteri di esito positivo per i protocolli HTTP, HTTPS e HTTP/2).
Un backend è considerato non integro quando almeno un sistema di sondaggi di controllo di integrità esegue le seguenti operazioni:
- Non riceve un codice di risposta
HTTP 200 (OK)per due probe consecutive. Ad esempio, la connessione potrebbe essere rifiutata o potrebbe verificarsi un timeout della connessione o della socket. - Riceve due risposte consecutive che non corrispondono ai criteri di successo specifici del protocollo.
- Non riceve un codice di risposta
Un backend è considerato integro quando almeno un sistema di probe del controllo di integrità riceve due risposte consecutive che corrispondono ai criteri di successo specifici del protocollo.
In questo esempio, ogni sonda avvia una connessione ogni 30 secondi. Trascorrono 30 secondi tra i tentativi di connessione di un prober, indipendentemente dalla durata del timeout (indipendentemente dal fatto che la connessione abbia superato o meno il timeout). In altre parole, il timeout deve sempre essere inferiore o uguale all'intervallo e non deve mai aumentarlo.
In questo esempio, la temporizzazione di ogni sondatore è la seguente, in secondi:
- t=0: avvia la sonda A.
- t=5: interrompi il probe A.
- t=30: avvia la sonda B.
- t=35: interrompi la sonda B.
- t=60: avvia la sonda C.
- t=65: interrompi la sonda C.
Passaggi successivi
- Per creare, modificare e utilizzare i controlli di integrità, consulta Utilizzare i controlli di integrità.
- Per risolvere i problemi relativi ai controlli di integrità, abilita il logging del controllo di integrità.