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 gruppi di istanze gestite. Questo documento illustra 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 successo. Questo argomento verrà discusso in dettaglio nella sezione Come funzionano i controlli di integrità.

I controlli di integrità implementati da attività software dedicate utilizzano 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 del 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:

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

Selezione di 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.
  • Protocol:protocollo che Google Cloud utilizza per verificare i backend.
  • Specifiche delle porte:porte utilizzate da Google Cloud con il protocollo.

La guida al bilanciatore del carico descrive le selezioni valide per il controllo di integrità per ogni tipo di bilanciatore del carico e backend. Per un riepilogo di livello superiore, consulta la tabella delle funzionalità dei controlli di integrità.

Categoria e protocollo

Una best practice consiste nell'utilizzare lo stesso protocollo del bilanciatore del carico, ma non è un requisito né è sempre possibile.

Ad esempio, i bilanciatori del carico di rete passthrough esterni basati su pool di destinazione richiedono controlli di integrità legacy e richiedono l'utilizzo del protocollo HTTP nei controlli di integrità legacy, anche se i bilanciatori del carico di rete passthrough esterni basati sul pool di destinazione supportano TCP o UDP. Per i bilanciatori del carico di rete passthrough esterni basati su pool di destinazione, devi eseguire un server HTTP sulle tue istanze di macchine virtuali (VM) in modo che possano rispondere ai probe di controllo di integrità.

Inoltre, 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 NEG ibridi.

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.

Categoria e specifiche della porta

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 solo metodo: --port.

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 di porta personalizzato (--port)
  • Numero di porta dell'endpoint (--use-serving-port)
Gruppi di istanze Controllo di integrità (globale)
  • Numero di porta personalizzato (--port)
  • Porta denominata del servizio di backend (--use-serving-port)
Application Load Balancer esterno regionale NEG supportati Controllo di integrità (a livello di regione)
  • Numero di porta personalizzato (--port)
  • Numero di porta dell'endpoint (--use-serving-port)
Gruppi di istanze Controllo di integrità (a livello di regione)
  • Numero di 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 di porta personalizzato (--port)
  • Numero di porta dell'endpoint (--use-serving-port)
Gruppi di istanze Controllo di integrità (globale)
  • Numero di 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 di porta personalizzato (--port)
  • Numero di porta dell'endpoint (--use-serving-port)
Gruppi di istanze Controllo di integrità (a livello di regione)
  • Numero di 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 di porta personalizzato (--port)
Istanze
nei pool di destinazione
Controllo di integrità precedente
(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 di porta personalizzato (--port)
Gruppi di istanze Controllo di integrità (globale o a livello di regione)
  • Numero di porta personalizzato (--port)
1 Per gli Application Load Balancer 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:
  • I 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
2 Non puoi utilizzare il flag --use-serving-port perché i servizi di backend utilizzati con i bilanciatori del carico di rete passthrough interni e i bilanciatori del carico di rete passthrough esterni non si registrano a nessuna porta denominata. Inoltre, i bilanciatori del carico di rete passthrough interni supportano solo NEG di zona con endpoint GCE_VM_IP, che non dispongono di informazioni sulle porte.

Controllo di integrità con Traffic Director in ambienti ibridi

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 pianifica 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

Come funzionano i controlli di integrità

Le seguenti sezioni descrivono come funzionano i controlli di integrità.

Probe

Quando crei un controllo di integrità o un controllo di integrità legacy, specifichi i seguenti flag o accetti 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 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. Di conseguenza, 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 dall'inizio di un probe emesso da un probe all'inizio del probe successivo emesso dallo stesso utente. Le unità sono i secondi. 5s (5 secondi)
Timeout
timeout
Il timeout è il tempo di attesa di Google Cloud per 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)

Esegui il probe di intervalli IP e regole firewall

Affinché i controlli di integrità funzionino, devi creare regole firewall allow in entrata in modo che il traffico 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 regionale1, 2
  • Bilanciatore del carico di rete proxy interno tra regioni 1
  • Bilanciatore del carico di rete proxy esterno regionale1, 2
  • Traffic Director, tranne i backend di NEG internet e i backend di 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

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à attraverso il server di metadati. In questo caso, le origini dei pacchetti per il controllo di integrità corrispondono all'indirizzo IP del server di metadati: 169.254.169.254.

Regole firewall per i bilanciatori del carico di rete passthrough esterni
Bilanciatore del carico di rete passthrough interno
  • 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 di NEG internet e backend di NEG ibridi Indirizzi IP delle VM che eseguono il software Envoy Esempio di regola firewall

1 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 singolo servizio di backend, devi inserire nella lista consentita gli intervalli di probe del controllo di integrità di Google per i NEG di zona.

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 proviene dalla subnet solo proxy e viene quindi tradotto tramite NAT (utilizzando Cloud NAT) in indirizzi IP NAT, assegnati manualmente o automaticamente. Questo traffico include sia probe di controllo di integrità che richieste utente dal bilanciatore del carico ai backend. Per maggiori dettagli, consulta NEG a livello di regione: utilizzare Cloud NAT per il traffico in uscita.

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 di probe documentati 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 possono contattare i tuoi backend, il bilanciatore del carico considera i tuoi backend non integri.

Considerazioni sulla sicurezza per gli intervalli IP dei probe

Considera le seguenti informazioni quando pianifichi i controlli di integrità e le regole firewall necessarie:

  • Gli intervalli IP del probe appartengono a Google. Google Cloud utilizza route speciali al di fuori della tua rete VPC, ma all'interno della rete di produzione di Google per facilitare le comunicazioni da parte dei probe.

  • 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 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 di Compute Engine o di un nodo di Google Kubernetes Engine (GKE).

  • Gli intervalli IP dei probe sono un insieme completo di possibili indirizzi IP 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 dei probe. Come best practice, crea regole firewall in entrata che consentano tutti gli intervalli IP dei probe come origini. Google Cloud può implementare nuovi probe automaticamente senza notifica.

Più probe e frequenza

Google Cloud invia probe per il 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 test per implementare un controllo di integrità: più prober valutano contemporaneamente le istanze nei backend di gruppi di istanze o gli endpoint nei backend di NEG a livello di zona. Se un problema 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 test. 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 è possibile configurare il numero di probe che Google Cloud utilizza per i controlli di integrità. Tuttavia, puoi stimare l'effetto di più probe simultanei considerando i seguenti fattori.

  • 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:

      1(intervallo di controllo)

      Quando associ un controllo di integrità a un servizio di backend, stabilisci una frequenza di base utilizzata da ogni test per i backend su quel servizio di backend.

    • Verifica il fattore di scala. La frequenza di base del servizio di backend viene moltiplicata per il numero di probe simultanei utilizzati da Google Cloud. Questo numero può variare, ma in genere è 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ù prober 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ù prober 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 a livello di regione. Se hai configurato più proxy di destinazione che indirizzano il traffico allo stesso servizio di backend, Google Cloud utilizza più prober 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 sui servizi di backend. Se un backend viene utilizzato da più servizi di backend, le istanze di backend vengono contattate con una frequenza pari alla somma delle frequenze per il controllo di integrità di ciascun servizio di backend.

    Con i backend di 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 del probe

La tabella seguente mostra l'interfaccia di rete e gli indirizzi IP di destinazione a cui i probe di 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 di NEG a livello di zona con endpoint GCE_VM_IP_PORT, l'interfaccia di rete nella rete VPC associata al NEG.
  • Per i backend di NEG a livello di zona con endpoint NON_GCP_PRIVATE_IP_PORT, l'endpoint deve rappresentare un'interfaccia di una risorsa on-premise che sia 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 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 sul pool di destinazione, lo stesso pool di destinazione), Google Cloud invia 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 Per i backend di gruppi di istanze e di 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 di backend e interfacce di rete.

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 HTTP 200 (OK) 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 entro i primi 1024 byte del corpo della risposta HTTP.

Le seguenti combinazioni di flag stringa di risposta e percorso di richiesta sono disponibili per i controlli di integrità che utilizzano i protocolli HTTP, HTTPS e HTTP/2.

Flag di configurazione Criteri di successo
Percorso richiesta
request-path
Specifica il percorso dell'URL a cui Google Cloud invia le richieste dei 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 (singoli byte). Se configurato, Google Cloud prevede che questa stringa entro i primi 1024 byte della risposta oltre a ricevere un codice di stato HTTP 200 (OK).

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 professionista 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 tramite:
    • Il backend
    • Il team di Google Cloud che invia un pacchetto TCP RST (reimpostazione) mentre la sessione TCP al team è 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 team di assistenza Google Cloud ha già avviato una risoluzione TCP gestita.

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 (singoli byte). Quando è 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.

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

Flag di configurazione Criteri di successo
Nessuna richiesta o risposta specificata

Nessun flag specificato: --request, --response
Google Cloud considera il probe riuscito quando sono soddisfatte le condizioni di base.
Sia la richiesta che la risposta specificate

Entrambi i flag sono 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.
È stata specificata solo la risposta

Flag specificati: solo --response
Google Cloud attende la stringa di risposta prevista e ritiene che il probe abbia avuto esito positivo quando le condizioni di base sono soddisfatte e la stringa della risposta restituita corrisponde esattamente alla stringa di risposta prevista.

Dovresti utilizzare --response da solo se i tuoi backend inviano automaticamente una stringa di risposta come parte dell'handshake TCP o SSL.
Solo richiesta specificata

Flag specificati: solo --request
Google Cloud invia la stringa di richiesta configurata e considera il probe riuscito quando le condizioni di base sono soddisfatte. La risposta, se presente, non 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 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:

Stato integrità

Google Cloud utilizza i seguenti flag di configurazione per determinare lo stato di integrità complessivo di ciascun backend verso cui viene bilanciato il carico del 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 riusciti affinché un backend sia considerato integro. Una soglia di 2 probe.
Soglia stato non integro
unhealthy-threshold
La soglia di stato non integro specifica il numero di risultati sequenziali del probe non riusciti affinché un backend sia considerato non integro. Una soglia di 2 probe.

Google Cloud considera i backend in stato integro dopo aver raggiunto questa soglia integro. I backend integri sono idonei a ricevere nuove connessioni.

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

Le connessioni esistenti potrebbero non restituire risposte, a seconda della causa dell'errore del probe. Un backend in stato non integro può tornare in stato integro se riesce a raggiungere di nuovo la soglia di stato integro.

Il comportamento specifico in caso di stato non integro di tutti i backend varia a seconda del tipo di bilanciatore del carico che utilizzi:

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 esterni basati su servizio di backend

Distribuisci il traffico a tutte le VM di backend come ultima alternativa quando tutti i backend sono in stato non integro e il failover non è configurato.

Per maggiori informazioni su questo comportamento, consulta gli articoli 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 servizio di backend 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

Controlli di integrità basati sui contenuti

Un controllo di integrità basato sui contenuti è un controllo i cui criteri di successo 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 successo per HTTP, HTTPS e HTTP/2.

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

Certificati e controlli di integrità

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

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

Esempio di controllo di integrità

Supponi di aver 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 Frequenza e probe multipli.
  2. Ogni 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 un codice di stato HTTP 200 (OK) (i criteri di operazione riuscita per i protocolli HTTP, HTTPS e HTTP/2).
  3. Un backend è considerato non integro quando almeno un 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 una connessione o un timeout 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 sistema di probe del controllo di integrità riceve due risposte consecutive che corrispondono ai criteri di successo specifici del protocollo.

In questo esempio, ogni probe avvia una connessione ogni 30 secondi. Passano 30 secondi tra i tentativi di connessione di un utente indipendentemente dalla durata del timeout (sia 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 indicatore hanno il seguente aspetto, espresso in secondi:

  1. t=0: avvia il probe A.
  2. t=5: arresta la sonda A.
  3. t=30: avvia il probe B.
  4. t=35: arresta la sonda B.
  5. t=60: avvia il probe C.
  6. t=65: arresta la sonda C.

Passaggi successivi