Panoramica dei controlli di integrità

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Google Cloud offre controlli di integrità configurabili per i backend del bilanciatore del carico Google Cloud, il backend di Traffic Director e la 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 consecutivi 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 integri.

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 verrà discusso in dettaglio nella sezione Come funzionano i controlli di integrità.

I controlli di integrità implementati da attività software dedicate utilizzano route speciali che non sono definite nella tua 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 come vengono eseguiti i probe di controllo dell'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é puoi convertirlo 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 selezioni un controllo di integrità sono i seguenti:

  • Categoria: controllo di integrità o controllo di integrità legacy.
  • Protocollo: protocollo utilizzato da Google Cloud per esaminare i backend.
  • Specifica della porta: porte utilizzate da Google Cloud con il protocollo.

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

Categoria e protocollo

È una best practice utilizzare lo stesso protocollo del bilanciatore del carico, tuttavia, non è un requisito, né è sempre possibile.

Ad esempio, i bilanciatori del carico di rete basati su pool di destinazione richiedono controlli di integrità legacy e richiedono che i controlli di integrità legacy utilizzino il protocollo HTTP, anche se i bilanciatori del carico di rete basati su pool di destinazione supportano TCP o UDP. Per i bilanciatori del carico di rete 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à.

Per quasi tutti gli altri tipi di bilanciatori del carico, devi utilizzare controlli di integrità regolari e non legacy in cui il protocollo corrisponde al protocollo del servizio di backend del bilanciatore del carico.

Specifiche di categoria e porta

Devi specificare una porta per il controllo di integrità. I controlli di integrità hanno due metodi di specifica della porta: --port e --use-serving-port. Per i controlli di integrità legacy, esiste un metodo: --port.

Guida al bilanciatore del carico

Questa tabella mostra le specifiche supportate per categoria, ambito e porta 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 HTTP(S) esterno globale

Bilanciatore del carico HTTP(S) esterno globale (classico) 1

Bilanciatore del carico proxy TCP esterno

Bilanciatore del carico del proxy SSL esterno
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 HTTP(S) esterno a livello di area geografica 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 HTTP(S) interno
Bilanciatore del carico proxy TCP a livello interno
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 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à precedenti supportano solo la specifica del numero di porta (--port).
Bilanciatore del carico TCP/UDP 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)
1 Per i bilanciatori del carico HTTP(S) 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 HTTP(S) esterno globale

Bilanciatore del carico HTTP(S) esterno globale (versione classica)

Sì, se entrambe le seguenti condizioni sono soddisfatte:
  • I backend sono gruppi di istanze.
  • Le VM di backend gestiscono il traffico che utilizza il protocollo HTTP o HTTPS.
Bilanciatore del carico HTTP(S) esterno a livello di area geografica No
2 Non puoi utilizzare il flag --use-serving-port perché i servizi di backend utilizzati con bilanciatori del carico TCP/UDP interni e i bilanciatori del carico di rete TCP/UDP esterni non si iscrivono a nessuna porta denominata. Inoltre, i bilanciatori del carico TCP/UDP interni supportano solo NEG a livello di zona con endpoint GCE_VM_IP, privi di informazioni sulla porta.

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 dal comportamento di controllo dell'integrità per altri tipi di endpoint di rete.

Invece di utilizzare le attività software dedicate, Traffic Director programma i proxy Envoy per eseguire controlli di integrità per i NEG Internet (endpoint) INTERNET_FQDN_PORT e i NEG ibridi (endpoint NON_GCP_PRIVATE_IP_PORT).

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, devi specificare i seguenti flag o accettarne i valori predefiniti. Ogni controllo di integrità o controllo di integrità legacy che crei è 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 in base al backend. I controlli di integrità sono associati a un intero servizio di backend. Per un bilanciamento del carico di rete basato su pool di destinazione, un controllo di integrità HTTP legacy è associato all'intero pool di destinazione. Quindi 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 è il periodo di tempo dall'inizio di un probe emesso da un probe all'inizio del successivo probe emesso dallo stesso probe. Le unità sono in secondi. 5s (5 secondi)
Timeout
timeout
Il timeout è il tempo di attesa di Google Cloud per una risposta a un probe. Il valore deve essere inferiore o uguale all'intervallo di controllo. Le unità 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 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 dell'origine probe Esempio di regola firewall
  • Bilanciatore del carico HTTP(S) esterno globale
  • Bilanciatore del carico HTTP(S) esterno globale (versione classica)
  • Bilanciatore del carico HTTP(S) esterno a livello di regione 1
  • Bilanciatore del carico HTTP(S) interno 1
  • Bilanciatore del carico TCP/UDP interno
  • Bilanciatore del carico del proxy SSL esterno
  • Bilanciatore del carico del proxy TCP esterno
  • Bilanciatore del carico proxy TCP a livello di regione interno 1
  • Traffic Director, ad eccezione dei backend NEG per Internet e 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
Bilanciatore del carico di rete TCP/UDP 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 basati su pool di destinazione supportano solo il traffico IPv4 e potrebbero controllare i controlli di integrità del proxy tramite il server di metadati. In questo caso, le origini dei pacchetti di controllo di integrità corrispondono all'indirizzo IP del server di metadati: 169.254.169.254.

Regole firewall per i bilanciatori del carico di rete
Bilanciamento del carico TCP/UDP 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
Traffic Director con backend NEG Internet e backend NEG ibridi Indirizzi IP delle VM che eseguono il software Envoy Esempio di regola firewall
1 Attualmente, i probe di controllo dell'integrità per i NEG ibridi provengono dal meccanismo di controllo centralizzato di Google. Se non puoi consentire al traffico proveniente dagli intervalli di controllo di integrità di Google di raggiungere gli endpoint ibridi e preferisci che i probe di controllo dell'integrità provengano da indirizzi IP privati, contatta il rappresentante del tuo account Google per inserire il tuo progetto nella lista consentita dei controlli di integrità distribuiti.

Importanza delle regole firewall

Google Cloud richiede la creazione delle regole del firewall in entrata allow necessarie per consentire il traffico dai probe ai tuoi backend. Come best practice, limita queste regole solo ai protocolli e alle porte che corrispondono 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 sono presenti 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. Il comportamento in cui tutti i backend sono in stato non integro dipende dal tipo di bilanciatore del carico:

  • Il bilanciatore del carico HTTP(S) esterno globale (versione classica) restituisce le risposte HTTP 502 ai client quando tutti i backend sono in stato non integro.

  • i bilanciatori del carico HTTP(S) esterni globali, i bilanciatori del carico HTTP(S) esterni a livello di area geografica e i bilanciatori del carico HTTP(S) interni restituiscono le risposte HTTP 503 ai client quando tutti i backend sono in stato non integro.

  • I bilanciatori del carico del proxy SSL esterno e i bilanciatori del carico del proxy TCP esterno scadono quando tutti i backend sono in stato non integro.

  • I bilanciatori del carico del proxy TCP a livello di regione interni interrompono le connessioni client inviando un pacchetto RST TCP quando tutti i backend sono in stato non integro.

  • Quando tutti i backend sono in stato non integro e non è configurato, i bilanciatori del carico TCP/UDP interni e i bilanciatori del carico di rete basati su servizi di backend distribuiscono il traffico a tutte le VM di backend come ultima risorsa. Per ulteriori dettagli su questo comportamento, consulta Distribuzione del traffico per i bilanciatori del carico TCP/UDP interni e Distribuzione del traffico per i bilanciatori del carico di rete basati su servizi di backend.

  • Quando tutti i backend sono in stato non integro, scegli come target i bilanciatori del carico di rete basati su pool e distribuisci il traffico a tutte le VM di backend come ultima risorsa.

Considerazioni sulla sicurezza per intervalli IP del probe

Prendi in considerazione 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 all'esterno della tua rete VPC, ma all'interno della rete di produzione di Google per facilitare la comunicazione dai probe.

  • Google utilizza gli intervalli IP dei probe per inviare probe di controllo di integrità per bilanciatori del carico HTTP(S) esterni, bilanciatori del carico del proxy SSL esterno e bilanciatori del carico del proxy TCP esterni. Se un pacchetto viene ricevuto da Internet e l'indirizzo IP sorgente del pacchetto rientra in un intervallo IP di probe, Google elimina il pacchetto. Include l'indirizzo IP esterno di un'istanza Compute Engine o di un nodo Google Kubernetes Engine (GKE).

  • Gli intervalli IP del 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 del probe. Come best practice, crea regole firewall in entrata che consentano tutti gli intervalli IP del probe come origini. Google Cloud può implementare automaticamente nuovi prober senza notifica.

Più probe e frequenza

Google Cloud invia probe di controllo dell'integrità da più sistemi ridondanti chiamati probe. I probe utilizzano intervalli IP di origine specifici. Google Cloud non si affida a un solo prober per implementare un controllo di integrità: più probe valutano contemporaneamente le istanze nei backend di gruppi di istanze o gli endpoint nei backend NEG di zona. In caso di errore di un probe, Google Cloud continua a monitorare gli stati di integrità dei backend.

Le impostazioni di intervallo e di timeout configurate per un controllo di integrità vengono applicate a ogni probe. Per un determinato backend, i log degli accessi software e tcpdump mostrano probe più frequenti delle impostazioni configurate.

Si tratta di un comportamento previsto e non puoi configurare il numero di probe utilizzati da Google Cloud per i controlli di integrità. Tuttavia, puoi stimare l'effetto di più probe simultanei prendendo in considerazione i seguenti fattori.

  • Per stimare la frequenza del probe per il servizio di backend, considera quanto segue:

    • Frequenza di base per servizio di backend. A ciascun 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, definisci una frequenza di base utilizzata da ogni probe per i backend su quel servizio di backend.

    • Fattore di scalabilità del probe. La frequenza di base del servizio di backend viene moltiplicata per il numero di probe simultanee che Google Cloud utilizza. Questo numero può variare, ma in genere è compreso tra 5 e 10.

  • Più regole di forwarding per bilanciatori del carico TCP/UDP interni. Se hai configurato più regole di forwarding interno (ognuna ha un indirizzo IP diverso) che rimanda allo stesso servizio di backend interno a livello di area geografica, Google Cloud utilizza più probe per controllare ogni indirizzo IP. La frequenza di probe per servizio di backend viene moltiplicata per il numero di regole di forwarding configurate.

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

  • Più proxy di destinazione per bilanciatori del carico HTTP(S) esterni. Se hai più proxy di destinazione che indirizzano il traffico alla stessa mappa URL, 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.

  • Più proxy di destinazione per bilanciatori del carico proxy SSL esterni, bilanciatori del carico proxy TCP esterni e bilanciatori del carico TCP a livello di regione interni. Se hai configurato più proxy di destinazione che indirizzano il traffico verso lo stesso servizio di backend, 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.

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

    Con i backend NEG di zona, è più difficile determinare l'esatto numero di probe di controllo di integrità. Ad esempio, lo stesso endpoint può avere più NEG di zona. Questi NEG di zona non hanno necessariamente lo stesso insieme di endpoint, che 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 del controllo di integrità inviano i pacchetti, a seconda del tipo di bilanciatore del carico.

Per i bilanciatori del carico di rete e i bilanciatori del carico TCP/UDP 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 HTTP(S) esterno globale
  • Bilanciatore del carico HTTP(S) esterno globale (versione classica)
  • Bilanciatore del carico HTTP(S) esterno a livello di area geografica
  • Bilanciatore del carico HTTP(S) interno
  • Bilanciatore del carico del proxy SSL esterno
  • Bilanciatore del carico del proxy TCP esterno
  • Bilanciatore del carico del proxy TCP regionale interno
  • Traffic Director
Interfaccia di rete principale (nic0)
  • Per i backend dei gruppi di istanze, l'indirizzo IP interno principale associato all'interfaccia di rete principale (nic0) di ogni istanza.
  • Per i backend NEG di zona, l'indirizzo IP dell'endpoint. Può essere un indirizzo IP interno primario o un intervallo IP alias dell'interfaccia di rete principale, nic0, sull'istanza che ospita l'endpoint.
Bilanciatore del carico di rete 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 basati su 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 TCP/UDP interno L'interfaccia di rete dell'istanza che si trova nella rete specificata per il servizio di backend interno. Se non specificato, viene utilizzata l'interfaccia di rete principale (nic0).

Per ulteriori informazioni, 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 l'invio di un codice di risposta 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.

Sono disponibili le seguenti combinazioni di flag del percorso di richiesta e della stringa di risposta 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 di probe del controllo di integrità.
Se omesso, Google Cloud invia richieste di probe al percorso principale, /.
Risposta
response
Il flag di risposta facoltativo ti consente di configurare un controllo di integrità basato sui contenuti. La stringa di risposta prevista deve essere inferiore o uguale a 1024 caratteri ASCII (a byte singolo). Quando è configurata, Google Cloud prevede che questa stringa rientri nei primi 1024 byte della risposta in aggiunta allo stato HTTP 200 (OK).

Criteri di successo per SSL e TCP

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

  • Ogni probe 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 normalmente da:
    • Il backend, o
    • Il probe di Google Cloud invia un pacchetto TCP RST (reset) mentre la sessione TCP al probe è ancora stabilita

Se il backend invia un pacchetto TCP RST (reset) per chiudere una sessione TCP per un controllo di integrità TCP, il probe potrebbe essere considerato non riuscito. Questo accade quando il probe di Google Cloud ha già avviato un'arresto controllato del TCP.

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

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

Flag di configurazione Criteri di successo
Nessuna richiesta o risposta specificata

Né il flag specificato: --request, --response
Google Cloud considera il probe riuscito quando le condizioni di base sono soddisfatte.
Richiesta e risposta specificate

Entrambi i flag specificati: --request, --response
Google Cloud invia la stringa di richiesta configurata ed 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 risposta specificata

Flag specificati: solo --response
Google Cloud attende la stringa di risposta prevista e considera il probe riuscito quando le condizioni di base sono soddisfatte e la stringa di risposta restituita corrisponde esattamente alla stringa di risposta prevista.

Utilizza --response da sola se i backend invieranno 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 è selezionata.

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 di 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 quanto segue:

Stato di integrità

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

Flag di configurazione Finalità Valore predefinito
Soglia stato integro
healthy-threshold
La soglia di stato integro specifica il numero di risultati probe sequenziali riusciti per un backend da considerare integro. Una soglia di 2 probe.
Soglia stato non integro
unhealthy-threshold
La soglia di stato non integro specifica il numero di risultati del probe non riusciti sequenziali per un backend da considerare non integro. Una soglia di 2 probe.

Google Cloud considera i backend come saluti dopo il raggiungimento di questa soglia integro. I backend integri sono idonei a ricevere nuove connessioni.

Google Cloud considera i backend come non integri quando viene raggiunta la soglia in stato non integro. I backend non integri non sono idonei a ricevere nuove connessioni, ma le connessioni esistenti non vengono terminate immediatamente. La connessione rimane aperta finché non si verifica un timeout o fino a quando il traffico non viene eliminato. Il comportamento specifico varia a seconda del tipo di bilanciatore del carico che utilizzi.

Le connessioni esistenti potrebbero non restituire le risposte, a seconda della causa per cui il probe non riesce. Un backend in stato non integro può diventare integro se è in grado di soddisfare nuovamente la soglia prevista.

Note aggiuntive

Controlli di integrità basati sui contenuti

Un controllo di integrità basato sui contenuti è quello i cui criteri di successo dipendono dalla valutazione di una stringa di risposta prevista. Utilizza un controllo di integrità basato sui contenuti per istruire i probe di controllo dell'integrità di Google Cloud per convalidare in modo più completo la risposta del tuo backend.

  • Per configurare un controllo di integrità basato sui contenuti HTTP, HTTPS o HTTP/2 devi specificare una stringa di risposta prevista e, facoltativamente, definire un percorso di richiesta. Per ulteriori dettagli, consulta Criteri di successo per HTTP, HTTPS e HTTP/2.

  • Per configurare un controllo di integrità basato sui contenuti SSL o TCP devi specificare una stringa di risposta prevista e, facoltativamente, una stringa di richiesta. Per ulteriori dettagli, consulta Criteri di successo per SSL e TCP.

Certificati e controlli di integrità

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

  • Puoi utilizzare i certificati autofirmati o quelli 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à precedenti, 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à

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

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

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

  1. Più sistemi ridondanti sono configurati contemporaneamente con i parametri del controllo di integrità. Le impostazioni di intervallo e timeout vengono applicate a ciascun sistema. Per ulteriori informazioni, consulta probe e frequenza multipli.
  2. Ogni controllo di integrità esegue le seguenti operazioni:

    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 un codice di risposta HTTP 200 (OK) (i criteri di successo per i protocolli HTTP, HTTPS e HTTP/2).
  3. Un backend è considerato in stato non integro quando almeno un sistema di probe di controllo di integrità esegue le seguenti operazioni:

    1. Non riceve un codice di risposta HTTP 200 (OK) per due probe consecutivi. Ad esempio, la connessione potrebbe essere rifiutata oppure potrebbe verificarsi 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 sistema di probe di 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 un tentativo e l'altro della connessione, indipendentemente dalla durata del timeout (indipendentemente dal fatto che la connessione sia scaduta). In altre parole, il timeout deve essere sempre inferiore o uguale all'intervallo e non aumenta mai di conseguenza.

In questo esempio, il tempo di ogni probe è simile al seguente, in secondi:

  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 probe B.
  5. t=60: Avvia il probe C.
  6. t=65: Arresta il probe C.

Passaggi successivi