Panoramica dei controlli di integrità

Google Cloud offre controlli di integrità configurabili per backend del bilanciatore del carico Google Cloud, backend di Traffic Director e riparazione automatica basata sulle applicazioni per i gruppi di istanze gestite. Questo documento tratta i concetti chiave del controllo di integrità.

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 probe. Google Cloud registra l'esito positivo o negativo di ogni probe.

In base a un numero configurabile di probe 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 in stato non integro.

Lo stato di integrità complessivo di ogni backend determina l'idoneità a ricevere nuove richieste o connessioni. Puoi configurare i criteri che definiscono un probe di esito positivo. Questo aspetto è discusso in dettaglio nella sezione Come funzionano i controlli di integrità.

I controlli di integrità implementati da attività software dedicate usano route speciali non definite nella rete Virtual Private Cloud (VPC). Per ulteriori informazioni, consulta Percorsi di ritorno del bilanciatore del carico.

Categorie, protocolli e porte 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 rispettivi protocolli supportati sono i seguenti:

• Controlli di integrità

  • Globale (gRPC, TCP, SSL, HTTP, HTTPS o HTTP/2)
  • A livello di regione (gRPC, TCP, SSL, HTTP, HTTPS o HTTP/2)

• Controlli di integrità legacy:

  • Legacy globale (HTTP)
  • Globale legacy (HTTPS)

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 o 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à né puoi convertire un controllo di integrità in un controllo di integrità legacy.

Nota: il termine controllo di integrità non si riferisce ai controlli di integrità legacy. In questo documento, i controlli di integrità legacy sono esplicitamente denominati controlli di integrità legacy. Inoltre, tieni presente che questo documento utilizza il termine gruppo di istanze per fare riferimento a gruppi di istanze non gestite, a gruppi di istanze gestite a livello di zona e a gruppi di istanze gestite a livello di regione.

Seleziona un controllo di integrità

I controlli di integrità devono essere compatibili con il tipo di bilanciatore del carico (o Traffic Director) e con i tipi di backend. I fattori da considerare quando si seleziona 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 controlli di integrità legacy. Per tutti gli altri prodotti utilizzerai regolari controlli di integrità.
• Protocollo:protocollo che Google Cloud utilizza per testare i backend. È ideale utilizzare un controllo di integrità (o un controllo di integrità legacy) il cui protocollo corrisponda a quello utilizzato dal servizio di backend o dal pool di destinazione del bilanciatore del carico. Tuttavia, i protocolli per il controllo di integrità e quelli del bilanciatore del carico non devono essere uguali.
• Specifiche delle porte:porte che Google Cloud utilizza con il protocollo. Devi specificare una porta per il controllo di integrità. I controlli di integrità prevedono due metodi di specifica della porta: --port e --use-serving-port. Per i controlli di integrità legacy, esiste un metodo: --port.

La sezione successiva descrive le selezioni valide per il controllo di integrità per ogni tipo di bilanciatore del carico e backend.

Guida al bilanciatore del carico

Questa tabella mostra le specifiche di categoria, ambito e porta supportate per ogni bilanciatore del carico e tipo di backend.

Bilanciatore del carico	Tipo di backend	Categoria e ambito del controllo di integrità	Specifica della porta
Bilanciatore del carico delle applicazioni esterno globale Application Load Balancer classico ^1 Bilanciatore del carico di rete proxy esterno globale Bilanciatore del carico di rete proxy classico	NEG supportati	Controllo di integrità (globale)	Numero porta personalizzato (--port) Numero di porta dell'endpoint (--use-serving-port)
	Gruppi di istanze	Controllo di integrità (globale)	Numero porta personalizzato (--port) Porta denominata del servizio di backend (--use-serving-port)
Bilanciatore del carico delle applicazioni esterno regionale	NEG supportati	Controllo di integrità (a livello di regione)	Numero porta personalizzato (--port) Numero di porta dell'endpoint (--use-serving-port)
	Gruppi di istanze	Controllo di integrità (a livello di regione)	Numero porta personalizzato (--port) Porta denominata del servizio di backend (--use-serving-port)
Bilanciatore del carico delle applicazioni interno tra regioni Bilanciatore del carico di rete proxy interno tra regioni	NEG supportati	Controllo di integrità (globale)	Numero porta personalizzato (--port) Numero di porta dell'endpoint (--use-serving-port)
	Gruppi di istanze	Controllo di integrità (globale)	Numero porta personalizzato (--port) Porta denominata del servizio di backend (--use-serving-port)
Bilanciatore del carico delle applicazioni interno regionale Bilanciatore del carico di rete proxy interno regionale Bilanciatore del carico di rete proxy esterno regionale	NEG supportati	Controllo di integrità (a livello di regione)	Numero porta personalizzato (--port) Numero di porta dell'endpoint (--use-serving-port)
	Gruppi di istanze	Controllo di integrità (a livello di regione)	Numero porta personalizzato (--port) Porta denominata del servizio di backend (--use-serving-port)
Bilanciatore del carico di rete passthrough esterno ^2	Gruppi di istanze	Controllo di integrità (a livello di regione)	Numero porta personalizzato (--port)
	Istanze nei pool di destinazione	Controllo di integrità legacy (globale con il protocollo HTTP)	I controlli di integrità legacy supportano solo la specifica del numero di porta (--port).
Bilanciatore del carico di rete passthrough interno ^2	NEG supportati	Controllo di integrità (globale o a livello di regione)	Numero porta personalizzato (--port)
	Gruppi di istanze	Controllo di integrità (globale o a livello di regione)	Numero porta personalizzato (--port)

¹ Per i bilanciatori del carico delle applicazioni esterni, i controlli di integrità legacy non sono consigliati, ma a volte sono supportati, a seconda della modalità del bilanciatore del carico.

Modalità bilanciatore del carico	Controlli di integrità legacy supportati
Bilanciatore del carico delle applicazioni esterno globale Bilanciatore del carico delle applicazioni classico	Sì, se si verificano entrambe le seguenti condizioni: Questi backend sono gruppi di istanze. Le VM di backend gestiscono il traffico che utilizza il protocollo HTTP o HTTPS.
Bilanciatore del carico delle applicazioni esterno regionale	No

² Non puoi utilizzare il flag --use-serving-port perché i servizi di backend utilizzati con bilanciatori del carico di rete passthrough interni e bilanciatori del carico di rete passthrough esterni non si sottoscrivono ad alcuna porta denominata. Inoltre, i bilanciatori del carico di rete passthrough interni supportano solo NEG di zona con endpoint GCE_VM_IP, privi di informazioni sulla porta.

Note aggiuntive sull'utilizzo

• Per i bilanciatori del carico di rete passthrough interni, puoi utilizzare solo TCP o UDP per il protocollo del servizio di backend. Se gestisci il traffico HTTP dalle VM che utilizzano un bilanciatore del carico di rete passthrough interno, ha senso utilizzare un controllo di integrità utilizzando il protocollo HTTP.

• 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 un 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 con bilanciamento del carico in modo che possano rispondere ai probe del controllo di integrità.
  
  Per quasi tutti gli altri tipi di bilanciatore del carico, devi utilizzare controlli di integrità regolari 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 integrità gRPC o TCP. Non utilizzare i 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 sui NEG ibridi.

Controllo di integrità con Traffic Director

Tieni presente le seguenti differenze di comportamento quando utilizzi i controlli di integrità con Traffic Director.

• Con Traffic Director, il comportamento del controllo di integrità per gli endpoint di rete di tipo INTERNET_FQDN_PORT e NON_GCP_PRIVATE_IP_PORT è diverso da quello di controllo di integrità per altri tipi di endpoint di rete. Anziché utilizzare le attività software dedicate, Traffic Director programma i proxy Envoy per eseguire controlli di integrità per NEG internet (INTERNET_FQDN_PORT endpoint) e NEG ibridi (NON_GCP_PRIVATE_IP_PORT endpoint).

  Envoy supporta i seguenti protocolli per il controllo di integrità:

  • HTTP
  • HTTPS
  • HTTP/2
  • TCP

• Se Traffic Director è integrato con Service Directory e associ un servizio Service Directory a un servizio di backend di Traffic Director, non puoi impostare un controllo di integrità sul 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à o un controllo di integrità legacy, devi specificare i seguenti flag o accettare i relativi valori predefiniti. Ogni controllo di integrità o controllo di integrità legacy che crei viene implementato da più probe. Questi flag controllano la frequenza con cui ogni probe 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 i 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. Pertanto, i parametri del probe 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 controllo check-interval	L'intervallo di controllo è la quantità di tempo che intercorre dall'inizio di un probe emesso da un prober all'inizio del probe successivo emesso dallo stesso prober. Le unità sono i secondi.	5s (5 secondi)
Timeout timeout	Il timeout è il tempo durante il quale Google Cloud attende una risposta a un probe. Il suo valore deve essere inferiore o uguale all'intervallo di controllo. Le unità sono i secondi.	5s (5 secondi)

Probe per intervalli IP e regole firewall

Affinché i controlli di integrità funzionino, devi creare regole firewall allow in entrata in modo che il traffico proveniente dai probe di Google Cloud possa connettersi ai tuoi backend.

La tabella seguente mostra gli intervalli IP di origine da consentire:

Prodotto	Intervalli IP di origine del probe	Esempio di regola firewall
Bilanciatore del carico delle applicazioni esterno globale Bilanciatore del carico delle applicazioni classico Bilanciatore del carico delle applicazioni esterno regionale ^1, 2 Bilanciatore del carico delle applicazioni interno tra regioni^1 Bilanciatore del carico delle applicazioni interno regionale^1, 2 Bilanciatore del carico di rete passthrough interno Bilanciatore del carico di rete proxy esterno Bilanciatore del carico di rete proxy interno regionale^1, 2 Bilanciatore del carico di rete proxy interno tra regioni^1 Bilanciatore del carico di rete proxy esterno regionale^1, 2 Traffic Director, ad eccezione dei backend NEG internet e dei backend NEG ibridi	35.191.0.0/16 130.211.0.0/22	Regole firewall per tutti i prodotti tranne i bilanciatori del carico di rete passthrough esterni
Bilanciatore del carico di rete passthrough esterno	Per il traffico IPv4 verso i backend: 35.191.0.0/16 209.85.152.0/22 209.85.204.0/22 Per il traffico IPv6 verso i backend: 2600:1901:8001::/48 ^3	Regole firewall per bilanciatori del carico di rete passthrough esterni
Bilanciatore del carico di rete passthrough interno	Per il traffico IPv4 verso i backend: 35.191.0.0/16 130.211.0.0/22 Per il traffico IPv6 verso i backend: 2600:2d00:1:b029::/64	Regole firewall per i bilanciatori del carico di rete passthrough interni
Traffic Director con backend NEG internet e backend NEG ibridi	Indirizzi IP delle VM che eseguono il software Envoy	Esempio di regola firewall

¹ Non è necessario inserire nella lista consentita gli intervalli di probe del controllo di integrità di Google per i NEG ibridi. Tuttavia, se utilizzi una combinazione di NEG ibridi e di zona in un unico servizio di backend, devi inserire nella lista consentita gli intervalli del probe del controllo di integrità di Google per i NEG di zona.

² Per i NEG internet a livello di regione, i controlli di integrità sono facoltativi. Il traffico proveniente da bilanciatori del carico che utilizzano NEG internet a livello di regione ha origine dalla subnet solo proxy e viene quindi tradotto (utilizzando Cloud NAT) in indirizzi IP NAT manuali o allocati automaticamente. Questo traffico include sia i probe di controllo di integrità sia le richieste degli utenti dal bilanciatore del carico ai backend. Per maggiori dettagli, consulta NEG regionali: utilizzare Cloud NAT per il traffico in uscita.

³ 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 dei metadati. In questo caso, le origini dei pacchetti per il controllo di integrità corrispondono all'indirizzo IP del server dei metadati: 169.254.169.254. Non è necessario creare regole firewall per consentire il traffico dal server dei metadati. I pacchetti del server dei metadati sono sempre consentiti.

Importanza delle regole firewall

Google Cloud richiede la creazione delle regole firewall allow in entrata necessarie per consentire il traffico dai prober 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 del probe documentati elencati nella sezione precedente.

Se non hai regole firewall allow in entrata che consentono il controllo di integrità, la regola deny implicita blocca il traffico in entrata. Quando i probe non riescono a contattare i tuoi backend, il bilanciatore del carico considera i tuoi backend in stato non integro.

Considerazioni sulla sicurezza per gli intervalli IP di probe

Considera le seguenti informazioni durante la pianificazione dei controlli di integrità e le regole firewall necessarie:

• Gli intervalli IP di probe appartengono a Google. Google Cloud utilizza route speciali all'esterno della tua rete VPC, ma all'interno della rete di produzione di Google per facilitare la comunicazione da parte dei probe.

• Google utilizza gli intervalli IP dei probe per inviare probe del controllo di integrità per bilanciatori del carico delle applicazioni esterni e bilanciatori del carico di rete proxy esterni. Se un pacchetto viene ricevuto da internet e l'indirizzo IP di origine del pacchetto rientra nell'intervallo IP di un probe, Google elimina il pacchetto. Questo include l'indirizzo IP esterno di un'istanza Compute Engine o di un nodo Google Kubernetes Engine (GKE).

• Gli intervalli IP di probe sono un insieme completo di indirizzi IP possibili utilizzati dai probe di Google Cloud. Se utilizzi tcpdump o 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 del probe come origini. Google Cloud può implementare nuovi probe automaticamente senza preavviso.

Sonde multipli e frequenza

Google Cloud invia probe del controllo di integrità da più sistemi ridondanti chiamati probe. I Prober utilizzano intervalli IP di origine specifici. Google Cloud non si affida a un solo prober per implementare un controllo di integrità: più prober valutano contemporaneamente le istanze nei backend di gruppi di istanze o gli endpoint nei backend NEG a livello di zona. Se un prober ha esito negativo, Google Cloud continua a monitorare lo stato di integrità del backend.

Le impostazioni di intervallo e timeout che configuri per un controllo di integrità vengono applicate a ogni prober. Per un determinato backend, i log di accesso al software e tcpdump mostrano probe più frequenti rispetto alle impostazioni configurate.

Si tratta di un comportamento previsto e non puoi configurare il numero di prober che Google Cloud utilizza per i controlli di integrità. Tuttavia, puoi stimare l'effetto di più probe simultanei considerando i fattori seguenti.

• Per stimare la frequenza del probe per servizio di backend, considera 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:

    ¹⁄_{(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 del probe. La frequenza di base del servizio di backend viene moltiplicata per il numero di probe simultanei che Google Cloud utilizza. Questo numero può variare, ma generalmente è compreso tra 5 e 10.

• Più regole di forwarding per bilanciatori del carico di rete passthrough interni. Se hai configurato più regole di forwarding interno (ognuna con un indirizzo IP diverso) che puntano allo stesso servizio di backend interno a livello di regione, Google Cloud utilizza più probe per controllare ogni indirizzo IP. La frequenza del probe per servizio di backend viene moltiplicata per il numero di regole di forwarding configurate.

• Più regole di forwarding per bilanciatori del carico di rete passthrough esterni. Se hai configurato più regole di forwarding che puntano allo stesso servizio di backend o pool di destinazione, Google Cloud utilizza più prober per controllare ogni indirizzo IP. La frequenza del probe per VM di backend viene moltiplicata per il numero di regole di forwarding configurate.

• Più proxy di destinazione per bilanciatori del carico delle applicazioni esterni. Se hai più proxy di destinazione che indirizzano il traffico alla stessa mappa URL, Google Cloud utilizza più probe per controllare l'indirizzo IP associato a ciascun proxy di destinazione. La frequenza del probe 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 di destinazione che indirizzano il traffico allo stesso servizio di backend, Google Cloud utilizza più probe per verificare l'indirizzo IP associato a ciascun proxy di destinazione. La frequenza del probe per servizio di backend viene moltiplicata per il numero di proxy di destinazione configurati.

• Somma dei servizi di backend. Se un backend viene utilizzato da più servizi di backend, le istanze di backend vengono contattate con la stessa frequenza della somma delle frequenze per il controllo di integrità di ciascun servizio di backend.

  Con i backend NEG a livello di zona, è più difficile determinare il numero esatto di probe di controllo di integrità. Ad esempio, lo stesso endpoint può trovarsi in più NEG a livello di zona. Questi NEG a livello di zona non hanno necessariamente lo stesso insieme di endpoint e endpoint diversi possono puntare allo stesso backend.

Destinazione per i pacchetti probe

La seguente tabella 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 delle applicazioni esterno globale Bilanciatore del carico delle applicazioni classico Bilanciatore del carico delle applicazioni esterno regionale Bilanciatore del carico delle applicazioni interno tra regioni Bilanciatore del carico delle applicazioni interno Bilanciatore del carico di rete proxy esterno globale Bilanciatore del carico di rete proxy classico Bilanciatore del carico di rete proxy interno regionale Bilanciatore del carico di rete proxy interno tra regioni Traffic Director	Per i backend di gruppi di istanze, l'interfaccia di rete principale (nic0). Per i backend NEG a livello di zona con endpoint GCE_VM_IP_PORT, l'interfaccia di rete nella rete VPC associata al NEG. Per i backend NEG a livello di zona con endpoint NON_GCP_PRIVATE_IP_PORT, l'endpoint deve rappresentare un'interfaccia di una risorsa on-premise raggiungibile tramite una route nella rete VPC associata al NEG e nella regione che contiene il NEG.	Per i backend di gruppi di istanze, l'indirizzo IPv4 interno principale associato all'interfaccia di rete principale (nic0) di ogni istanza. Per i backend NEG a livello di zona con endpoint GCE_VM_IP_PORT, l'indirizzo IP dell'endpoint: un indirizzo IPv4 interno principale dell'interfaccia di rete o un indirizzo IPv4 interno da un intervallo IP alias dell'interfaccia di rete. Per i backend NEG a livello di zona con NON_GCP_PRIVATE_IP_PORT endpoint, l'indirizzo IP dell'endpoint.
Bilanciatore del carico di rete passthrough esterno	Interfaccia di rete principale (nic0)	L'indirizzo IP della regola di forwarding esterno. Se più regole di forwarding puntano 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 i probe all'indirizzo IP di ogni regola di forwarding. Ciò può comportare un aumento del numero di probe.
Bilanciatore del carico di rete passthrough interno	Sia per i backend di gruppi di istanze sia per i backend NEG a livello di zona con endpoint GCE_VM_IP, l'interfaccia di rete utilizzata dipende dalla configurazione del servizio di backend. Per maggiori dettagli, consulta Servizi e interfacce di rete di backend.	L'indirizzo IP della regola di forwarding interno. Se più regole di forwarding puntano allo stesso servizio di backend, Google Cloud invia probe all'indirizzo IP di ogni regola di forwarding. Ciò può comportare un aumento del numero di probe.

Criteri di successo per HTTP, HTTPS e HTTP/2

Quando un controllo di integrità utilizza il protocollo HTTP, HTTPS o HTTP/2, ogni probe richiede la consegna di un codice di stato 200 (OK) HTTP prima del timeout del probe. Inoltre, puoi:

• Puoi configurare i probe di Google Cloud per inviare richieste HTTP a un percorso di richiesta specifico. Se non specifichi un percorso di richiesta, viene utilizzato /.

• Se configuri un controllo di integrità basato sui contenuti specificando una stringa di risposta prevista, Google Cloud deve trovare la stringa prevista all'interno dei primi 1024 byte del corpo della risposta HTTP.

Per i controlli di integrità che utilizzano i protocolli HTTP, HTTPS e HTTP/2 sono disponibili le seguenti combinazioni di flag del percorso di richiesta e delle stringhe di risposta.

Flag di configurazione	Criteri di successo
Percorso richiesta request-path	Specifica il percorso dell'URL a cui Google Cloud invia le richieste del probe di controllo di integrità. Se omesso, Google Cloud invia richieste probe al percorso principale, /.
Risposta response	Il flag di risposta facoltativo consente di configurare un controllo di integrità basato sui contenuti. La stringa di risposta prevista deve essere inferiore o uguale a 1024 caratteri ASCII (singolo byte). Se configurata, Google Cloud prevede che questa stringa entro i primi 1024 byte della risposta oltre a ricevere un codice di stato 200 (OK) HTTP.

Criteri di successo per SSL e TCP

A meno che non specifichi una stringa di risposta prevista, i probe di controlli di integrità che utilizzano i protocolli SSL e TCP hanno esito positivo quando entrambe le seguenti condizioni di base sono vere:

• Ogni prober Google Cloud può completare un handshake SSL o TCP prima del timeout del probe configurato.
• Per i controlli di integrità TCP, la sessione TCP viene terminata automaticamente da:
  • Il backend o
  • Il prober di Google Cloud che invia un pacchetto TCP RST (reset) mentre la sessione TCP al prober è ancora stabilita

Se il backend invia un pacchetto TCP RST (reimpostazione) per chiudere una sessione TCP per un controllo di integrità TCP, il probe potrebbe essere considerato non riuscito. Questo accade quando il prober di Google Cloud ha già avviato una risoluzione provvisoria di TCP.

Puoi creare un controllo di integrità basato sui contenuti se fornisci una stringa di richiesta e una stringa di risposta prevista, ognuna con una lunghezza massima di 1024 caratteri ASCII (byte singolo). Quando viene configurata una stringa di risposta prevista, Google Cloud considera un probe riuscito solo se le condizioni di base sono soddisfatte e la stringa di risposta restituita corrisponde esattamente alla stringa di risposta prevista.

Per i controlli di integrità che utilizzano i protocolli SSL e TCP sono disponibili le seguenti combinazioni di flag di richiesta e risposta.

Flag di configurazione	Criteri di successo
Nessuna richiesta o risposta specificata Nessuno dei due flag specificati: --request, --response	Google Cloud considera il probe riuscito quando le condizioni di base sono soddisfatte.
Sia la richiesta che la risposta specificate Entrambi i flag specificati: --request, --response	Google Cloud invia la stringa di richiesta configurata e attende la stringa di risposta prevista. Google Cloud considera il probe riuscito quando le condizioni di base sono soddisfatte e la stringa di risposta restituita corrisponde esattamente alla stringa di risposta prevista.
Solo la risposta specificata Flag specificati: solo --response	Google Cloud attende la stringa di risposta prevista e considera che il probe abbia esito positivo quando le condizioni di base sono soddisfatte e la stringa di risposta restituita corrisponde esattamente alla stringa di risposta prevista. Devi utilizzare --response da solo se i tuoi backend invieranno automaticamente una stringa di risposta come parte dell'handshake TCP o SSL.
Solo la richiesta specificata Flag specificati: solo --request	Google Cloud invia la stringa di richiesta configurata e considera che il probe abbia esito positivo quando le condizioni di base sono soddisfatte. La risposta, se presente, non viene verificata.

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 dello 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 Traffic Director.
• I controlli di integrità gRPC non supportano TLS.

Per ulteriori informazioni, consulta le seguenti risorse:

• Flag aggiuntivo per i controlli di integrità gRPC
• Documentazione di gRPC per i controlli di integrità

Criteri di esito positivo per i controlli di integrità legacy

Se la risposta ricevuta dal probe di controllo di integrità legacy è HTTP 200 OK, il probe viene considerato riuscito. Tutti gli altri codici di risposta HTTP, incluso un reindirizzamento (301, 302), sono considerati non integri.

Stato di integrità

Google Cloud utilizza i seguenti flag di configurazione per determinare lo stato di integrità complessivo di ogni backend su cui viene bilanciato il traffico.

Flag di configurazione	Finalità	Valore predefinito
Soglia stato integro healthy-threshold	La soglia in stato integro specifica il numero di risultati sequenziali del probe di successo che un backend deve essere considerato integro.	Una soglia di 2 probe.
Soglia di stato non integro unhealthy-threshold	La soglia di stato non integro specifica il numero di risultati del probe sequenziale non riusciti affinché un backend venga considerato non integro.	Una soglia di 2 probe.

Google Cloud considera i backend in stato integro una volta raggiunta questa soglia. I backend in stato integro sono idonei a ricevere nuove connessioni.

Google Cloud considera i backend non integri quando la soglia di stato non integro viene raggiunta. I backend in stato non integro non sono idonei a ricevere nuove connessioni, ma le connessioni esistenti non vengono terminate immediatamente. La connessione rimane invece aperta fino a quando non si verifica un timeout o fino a quando il traffico non viene interrotto.

Le connessioni esistenti potrebbero non restituire le risposte, a seconda della causa dell'esito negativo del probe. Un backend in stato non integro può essere in stato integro se riesce a raggiungere nuovamente la soglia di stato integro.

Il comportamento specifico quando tutti i backend sono in stato non integro varia a seconda del 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 in stato non integro.
Bilanciatore del carico delle applicazioni esterno globale Bilanciatore del carico delle applicazioni esterno regionale Bilanciatore del carico delle applicazioni interno	Restituisce un codice di stato HTTP "503" ai client quando tutti i backend sono in stato non integro.
Bilanciatori del carico di rete proxy	Termina le connessioni client quando tutti i backend sono in stato non integro.
Bilanciatori del carico di rete passthrough interni e bilanciatori del carico di rete passthrough esterni basati sul servizio di backend	Distribuisci il traffico a tutte le VM di backend come ultima risorsa quando tutti i backend sono in stato non integro e il failover non è configurato. Per maggiori informazioni su questo comportamento, consulta Distribuzione del traffico per bilanciatori del carico di rete passthrough interni e Distribuzione del traffico per 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 sono in stato non integro.

Note aggiuntive

Le sezioni seguenti includono alcune note aggiuntive sull'utilizzo dei controlli di integrità in Google Cloud.

Controlli di integrità basati sui contenuti

Un controllo di integrità basato sui contenuti è un controllo i cui criteri di esito positivo dipendono dalla valutazione di una stringa di risposta prevista. Utilizza un controllo di integrità basato sui contenuti per indicare ai probe del controllo di integrità di Google Cloud di convalidare in modo più completo la risposta del backend.

• Puoi configurare un controllo di integrità basato sui contenuti HTTP, HTTPS o HTTP/2 specificando una stringa di risposta prevista e, facoltativamente, definendo un percorso della richiesta. Per maggiori dettagli, consulta Criteri di esito positivo per HTTP, HTTPS e HTTP/2.

• Puoi configurare un controllo di integrità basato su contenuti SSL o TCP specificando una stringa di risposta prevista e, facoltativamente, definendo una stringa di richiesta. Per ulteriori dettagli, consulta Criteri di esito positivo per SSL e TCP.

Certificati e controlli di integrità

I probe del controllo di integrità di Google Cloud non eseguono la convalida dei certificati, anche per i protocolli che richiedono che i backend utilizzino certificati (SSL, HTTPS e HTTP/2), ad esempio:

• Puoi utilizzare certificati autofirmati o firmati da qualsiasi autorità di certificazione (CA).
• Sono accettabili i certificati scaduti o non ancora validi.
• Né gli attributi CN né subjectAlternativeName devono corrispondere a un'intestazione Host o 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 protocolli HTTP, HTTPS o HTTP/2 e i controlli di integrità legacy consentono di specificare un'intestazione Host HTTP utilizzando il flag --host.

Esempio di controllo di integrità

Supponiamo che tu abbia configurato un controllo di integrità con le seguenti impostazioni:

• Intervallo: 30 secondi
• Timeout: 5 secondi
• Protocollo: HTTP
• Soglia di stato non integro: 2 (predefinita)
• Soglia di stato integro: 2 (predefinita)

Con queste impostazioni, il controllo di integrità si comporta come segue:

1. Con i parametri del controllo di integrità vengono configurati contemporaneamente più sistemi ridondanti. Le impostazioni di intervallo e timeout vengono applicate a ogni sistema. Per maggiori informazioni, consulta Più probe e frequenza.

2. Ogni prober del controllo di integrità esegue quanto segue:

   1. Avvia una connessione HTTP da uno degli indirizzi IP di origine all'istanza di backend ogni 30 secondi.
   2. Attende fino a cinque secondi per la ricezione di un codice di stato HTTP 200 (OK) (i criteri di successo per i protocolli HTTP, HTTPS e HTTP/2).

3. Un backend è considerato non integro quando almeno un sistema di probe di controllo di integrità esegue quanto segue:

   1. 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.
   2. Riceve due risposte consecutive che non corrispondono ai criteri di successo specifici del protocollo.

4. Un backend è considerato integro quando almeno un probe di controllo di integrità riceve due risposte consecutive che corrispondono ai criteri di successo specifici del protocollo.

In questo esempio, ogni prober avvia una connessione ogni 30 secondi. Tra i tentativi di connessione di un prober passano 30 secondi, indipendentemente dalla durata del timeout (indipendentemente dal fatto che la connessione sia scaduta o meno). In altre parole, il timeout deve essere sempre inferiore o uguale all'intervallo e il timeout non aumenta mai l'intervallo.

In questo esempio, i tempi di ogni prober sono espressi in secondi come segue:

1. t=0: avvia il probe A.
2. t=5: arresta il probe A.
3. t=30: avvia il probe B.
4. t=35: Arresta il sonda B.
5. t=60: avvia il probe C.
6. t=65: Arresta il 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à.