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 sono implementati di attività software dedicate che si connettono ai backend in base ai parametri è specificato in una risorsa di controllo di integrità. Ogni tentativo di connessione è chiamato sondaggio. Google Cloud registra l'esito positivo o negativo di ogni probe.
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 nuovi 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 definiti nella rete Virtual Private Cloud (VPC). Per ulteriori informazioni, consulta Percorsi per i controlli di integrità.
Categorie, protocolli e porte del controllo di integrità
I controlli di integrità hanno una categoria e un protocollo. Le due categorie sono salute e controlli di integrità legacy con i relativi protocolli supportati:
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à precedente. Solo i bilanciatori del carico di rete passthrough esterni basati su pool di destinazione richiedono 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.
- Specifiche della porta:porte utilizzate da Google Cloud con il protocollo.
Devi specificare una porta per il controllo di integrità. I controlli di integrità hanno due porte
metodi di specifica:
--porte--use-serving-port. Per integrità legacy dei controlli, c'è un solo metodo:--port. Per ulteriori informazioni sul controllo di integrità requisiti delle porte per bilanciatore del carico, vedi Specifiche delle porte e i flag facoltativi.
La sezione successiva descrive le selezioni valide per i controlli 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 controlli 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 gestisci traffico HTTP da VM dietro un Network Load Balancer passthrough interno, ha senso utilizzare un controllo di integrità utilizzando il protocollo protocollo.Un bilanciatore del carico di rete passthrough esterno basato su pool di destinazione deve utilizzare un controllo di integrità HTTP legacy. Non può utilizzare un controllo di integrità HTTPS legacy o qualsiasi controllo di integrità non legacy. Se usa 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 con bilanciamento del carico in modo che possano rispondere probe del controllo di integrità.
Per quasi tutti gli altri tipi di bilanciatore del carico, devi utilizzare standard Controlli di integrità in cui il protocollo corrisponde al servizio di backend del bilanciatore del carico protocollo.Per i servizi di backend che utilizzano il protocollo gRPC, utilizza solo l'integrità gRPC o TCP controlli. 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 sezione NEG ibridi Panoramica.
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 del controllo di integrità per gli endpoint di rete il tipo
INTERNET_FQDN_PORTeNON_GCP_PRIVATE_IP_PORTè diverso dall'integrità il controllo del comportamento di 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 Associa un servizio Service Directory a Cloud Service Mesh non puoi impostare un controllo di integrità per il servizio di backend.
Come funzionano i controlli di integrità
Le sezioni seguenti descrivono il funzionamento dei controlli di integrità.
Probe
Quando crei un controllo di integrità oppure un controllo di integrità legacy, devi specificare i seguenti flag o accettarne i valori predefiniti. Ogni controllo di integrità o il controllo di integrità legacy che crei viene implementato di test. 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 per singoli 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. Di conseguenza, i parametri del probe sono gli stessi per 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à sono in secondi. | 5s (5 secondi) |
Timeouttimeout |
Il timeout è il tempo di attesa di Google Cloud per una risposta a un probe. Il suo valore deve essere minore o uguale al intervallo di controllo. Le unità di misura sono in secondi. | 5s (5 secondi) |
Intervalli IP e regole firewall del probe
Affinché i controlli di integrità funzionino, devi creare regole firewall allow in entrata, in modo che
che il traffico proveniente dai probe 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 IP di origine del 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 esterno3 |
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 Cloud Service Mesh documentazione |
1 L'inserimento nella lista consentita degli intervalli di probe di 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. Traffico dal caricamento I bilanciatori che utilizzano NEG internet regionali provengono dalla subnet solo proxy e poi Tradotto da NAT (utilizzando Cloud NAT) in manuale o allocato automaticamente indirizzi IP NAT. Questo traffico include sia probe del controllo di integrità che dal bilanciatore del carico ai backend. Per maggiori dettagli, consulta la sezione A livello di regione NEG: utilizza Cloud NAT per il traffico in uscita.
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 per il controllo di integrità corrispondano all'indirizzo IP del server di 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.
Importanza delle regole firewall
Google Cloud richiede la creazione del traffico allow in entrata necessario
le regole firewall per consentire il traffico dai probe 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 hai regole firewall allow in entrata che consentono il controllo di integrità,
i blocchi implicita deny
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 del probe
Prendi in considerazione le seguenti informazioni quando pianifichi i controlli di integrità e regole firewall:
Gli intervalli IP delle sonde appartengono a Google. Google Cloud utilizza speciali route all'esterno del VPC ma all'interno della rete di produzione di Google per facilitare la comunicazione dai probatori.
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 ricevute da internet e dall'IP di origine del pacchetto incluso in un intervallo IP del probe, Google elimina il pacchetto. Sono inclusi all'indirizzo IP esterno di un'istanza Compute Engine 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 i probe intervalli IP come origini. Google Cloud può implementare nuovi probe automaticamente senza notifica.
Più probe e frequenza
Google Cloud invia probe di controllo di integrità da più sistemi ridondanti chiamati prober. I prober 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 funziona, 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 degli accessi
tcpdump mostra probe più frequenti rispetto alle impostazioni configurate.
Si tratta di un comportamento previsto e non puoi configurare il numero di sondaggi utilizzati da Google Cloud per i controlli di integrità. Tuttavia, puoi stimare di più probe simultanee considerando i fattori riportati di seguito.
Per stimare la frequenza di probe per servizio di backend, considera quanto segue:
Frequenza 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 backend completamente gestito di Google Cloud.
Fattore di scala della sonda. La frequenza di base del servizio di backend viene moltiplicata in base al numero di probe simultanei utilizzati da Google Cloud. Questo può variare, ma in genere è compreso tra 5 e 10.
Regole di forwarding multiple per i bilanciatori del carico di rete passthrough interni. Se configurato più regole di forwarding interno (ognuna con un indirizzo IP diverso principale) che punta allo stesso servizio di backend interno a livello di regione, Google Cloud utilizza più probe per controllare ogni indirizzo IP. La sonda la frequenza per servizio di backend viene moltiplicata per il numero e le regole di forwarding.
Più regole di inoltro per i bilanciatori del carico di rete passthrough esterni. Se disponi configurato più regole di forwarding che puntano allo stesso servizio di backend pool di destinazione, Google Cloud utilizza più probe per controllare ogni IP . La frequenza di probe per VM di backend viene moltiplicata per di regole di forwarding 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ù sondaggi per controllare l'indirizzo IP associato a ciascun proxy di destinazione. La frequenza di probe per servizio di backend viene moltiplicata per il numero di ai 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 di destinazione che indirizzano il traffico allo stesso di servizio di backend, Google Cloud utilizza più probe per verificare l'indirizzo IP associato con ciascun proxy di destinazione. La frequenza di controllo per servizio di backend viene moltiplicata per il numero di proxy target configurati.
Somma sui servizi di backend. Se un backend è in esecuzione utilizzate da più servizi di backend, le istanze di backend vengono contattate come spesso 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 probe
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
l'indirizzo IP del bilanciatore del carico (o 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 inoltro. 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 interno. Se più regole di inoltro rimandano allo stesso servizio di backend, Google Cloud invia sondaggi all'indirizzo IP di ogni regola di inoltro. 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 prober del controllo di integrità per inviare richieste HTTP a una richiesta specifica anziché il percorso di richiesta predefinito,
/.Configura ogni prober del controllo di integrità per verificare la presenza di un prober previsto 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 dei prober | Criteri di successo |
|---|---|---|
Né --request-path né --response
specificato
|
Lo strumento di analisi utilizza / come percorso della richiesta. |
Solo codice di risposta HTTP 200 (OK). |
--request-path e --response specificati entrambi
|
Il prober utilizza il percorso di richiesta configurato. | Codice di risposta HTTP 200 (OK) e fino alla prima
1024 caratteri ASCII del corpo della risposta HTTP devono corrispondere ai valori previsti
la stringa di risposta. |
Solo --response specificato
|
Lo strumento di analisi utilizza / come percorso della richiesta. |
Codice di risposta HTTP 200 (OK) e fino alla prima
1024 caratteri ASCII del corpo della risposta HTTP devono corrispondere ai valori previsti
la stringa di risposta. |
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 esito positivo 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 al backend e completare l'handshake TLS/SSL prima timeout del controllo di integrità.
Per i controlli di integrità TCP, la connessione TCP deve essere chiusa in uno dei nei seguenti modi:
- Tramite il prober del controllo di integrità invia un pacchetto FIN o RST (reimpostato), oppure
- Il backend che invia un pacchetto FIN. Se un backend invia un pacchetto RST TCP, il probe potrebbe essere considerato non riuscito se il 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. Flag di richiesta e risposta Deve essere composto solo da caratteri ASCII stampabili a un byte. Ogni stringa deve essere non deve superare i 1024 caratteri.
| Flag di configurazione | Comportamento dei prober | 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. | Basa i criteri di successo e la stringa di risposta ricevuta dal prober deve 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 con 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 di controllo di integrità legacy è HTTP 200 OK,
il probe è considerato riuscito. Tutti gli altri codici di risposta HTTP, incluso un
reindirizzamento (301, 302) sono considerati in stato non integro.
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 carico del traffico.
| Flag di configurazione | Finalità | Valore predefinito |
|---|---|---|
Soglia stato integrohealthy-threshold |
La soglia di stato integro specifica il numero di errori sequenziali i risultati del probe di tempo per un backend da considerare integro. | Una soglia di 2
probe. |
Soglia di stato non integrounhealthy-threshold |
La soglia di stato non integro specifica il numero di probe sequenziale non riuscito risultati non integri di un backend. | Una soglia di 2
e i sonde. |
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 in stato non integro quando lo stato non è integro sia stata raggiunta la soglia. I backend in stato non integro non sono idonei a ricevere nuovi connections; tuttavia, le connessioni esistenti non vengono terminate 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 le risposte, a seconda della causa il mancato funzionamento della sonda. Un backend non integro può diventare in stato integro se può soddisfare la soglia stato integro.
Il comportamento specifico quando tutti i backend sono in stato non integro varia a seconda del e il tipo di bilanciatore del carico che stai utilizzando:
| Bilanciatore del carico | Comportamento quando tutti i backend sono in stato non integro |
|---|---|
| Bilanciatore del carico delle applicazioni classico | Restituisce un codice di stato HTTP "502" ai client quando tutti i backend sono non è integro. |
|
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 sono in stato non integro. |
| 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 sono in stato non integro. |
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 ammessi 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
imposta 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 le intestazioni solo alle richieste del client, non ai probe del controllo di integrità. Se il backend richiede un'intestazione specifica per l'autorizzazione mancante e il pacchetto del controllo di integrità, il controllo di integrità potrebbe non riuscire.
Esempio di controllo di integrità
Supponiamo di configurare un controllo di stato con le seguenti impostazioni:
- Intervallo: 30 secondi
- Timeout: 5 secondi
- Protocollo: HTTP
- Soglia di stato non integro: 2 (valore predefinito)
- Soglia stato integro: 2 (impostazione predefinita)
Con queste impostazioni, il controllo di integrità si comporta come segue:
- Più sistemi ridondanti vengono configurati contemporaneamente con i parametri di controllo dell'integrità. Le impostazioni di intervallo e timeout vengono applicate a ciascun . Per ulteriori informazioni, vedi Più probe e frequenza.
Ogni prober del 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 consecutivi. Ad esempio, la connessione potrebbe essere rifiutata o potrebbe esserci un timeout della connessione o del 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 probe del controllo di integrità riceve due risposte consecutive che corrispondono al protocollo criteri di successo.
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 il timeout deve essere sempre inferiore o uguale all'intervallo e il timeout non aumenta mai l'intervallo.
In questo esempio, la temporizzazione di ogni sondatore è la seguente, in secondi:
- t=0: avvia il probe A.
- t=5: Arresta la sonda A.
- t=30: avvia la sonda B.
- t=35: interrompi la sonda B.
- t=60: avvia la sonda C.
- t=65: sonda di arresto 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 Controllo di integrità il logging.