Panoramica dei controlli di integrità

Google Cloud fornisce controlli di integrità per determinare se i backend rispondono al traffico. In questo documento vengono illustrati i concetti del controllo di integrità per i bilanciatori del carico Google Cloud e Traffic Director.

I controlli di integrità si connettono ai backend su base periodica configurabile. 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 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 riuscito. Questo argomento viene descritto in dettaglio nella sezione Come funzionano i controlli di integrità.

I controlli di integrità utilizzano route speciali non definite nella tua rete Virtual Private Cloud (VPC). Per informazioni complete, consulta la sezione 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 del controllo di integrità. Ad esempio, un controllo di integrità può utilizzare il protocollo HTTP sulla porta TCP 80 oppure può utilizzare il protocollo TCP per una porta denominata in un gruppo di istanze.

Non puoi convertire un controllo di integrità precedente in un controllo di integrità. Non puoi convertire un controllo di integrità in un controllo di integrità precedente.

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à precedente.
  • Protocollo: protocollo utilizzato da Google Cloud per analizzare i backend.
  • Specifica delle porte: 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 di livello superiore, consulta la tabella delle funzionalità dei controlli di integrità.

Categoria e protocollo

Si tratta di una best practice per utilizzare lo stesso protocollo del bilanciatore del carico; tuttavia, questo non è un requisito né è sempre possibile.

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

Per quasi tutti gli altri tipi di bilanciatore del carico, devi utilizzare i normali controlli di integrità non legacy per i protocolli 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 relative a categoria, ambito e porta supportati 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à (area geografica)
  • Numero porta personalizzato (--port)
  • Numero di porta dell'endpoint (--use-serving-port)
Gruppi di istanze Controllo di integrità (area geografica)
  • Numero porta personalizzato (--port)
  • Porta denominata del servizio di backend (--use-serving-port)
Bilanciatore del carico HTTP(S) interno
Bilanciatore del carico proxy TCP interno interno
NEG supportati Controllo di integrità (area geografica)
  • Numero porta personalizzato (--port)
  • Numero di porta dell'endpoint (--use-serving-port)
Gruppi di istanze Controllo di integrità (area geografica)
  • 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 area geografica)
  • Numero porta personalizzato (--port)
Istanze
nei pool di destinazione
Controllo di integrità precedente
(a livello globale con protocollo HTTP)
I controlli di integrità legacy 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 area geografica)
  • Numero porta personalizzato (--port)
Gruppi di istanze Controllo di integrità (globale o a livello di area geografica)
  • 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 No
Bilanciatore del carico HTTP(S) esterno a livello di area geografica No
Bilanciatore del carico HTTP(S) esterno Sì, se entrambe le seguenti condizioni sono soddisfatte:
  • Tali backend sono gruppi di istanze.
  • Le VM di backend gestiscono il traffico che utilizza il protocollo HTTP o HTTPS.

2 Non puoi utilizzare il flag --use-serving-port perché i servizi di backend utilizzati con i bilanciatori del carico TCP/UDP interni e i bilanciatori del carico di rete TCP/UDP esterni non si abbonano a nessuna porta denominata. Inoltre, i bilanciatori del carico TCP/UDP interni supportano solo i NEG di zona con endpoint GCE_VM_IP, privi di informazioni sulla porta.

Come funzionano i controlli di integrità

Le seguenti sezioni descrivono il funzionamento dei controlli di integrità.

Probe

Quando crei un controllo di integrità o un controllo di integrità precedente, puoi specificare i flag seguenti o accettare i relativi valori predefiniti. Ogni controllo di integrità o un controllo di integrità precedente creato 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 backend. I controlli di integrità sono associati a un intero servizio di backend. Per un bilanciamento del carico di rete basato su un pool di destinazione, un controllo di integrità HTTP precedente è associato all'intero pool di destinazione. Pertanto, i parametri del probe sono gli stessi per tutti i backend a cui si fa riferimento in un determinato servizio di backend o pool di destinazione.

Flag di configurazione Scopo 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 da parte di Google Cloud per la risposta a un probe. Il suo valore deve essere inferiore o uguale all'intervallo di controllo. Le unità sono in secondi. 5s (5 secondi)

Intervalli IP e regole firewall dei 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 di origine del 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 area geografica
  • Bilanciamento del carico HTTP(S) interno
  • Bilanciamento del carico TCP/UDP interno
  • Bilanciamento del carico del proxy SSL esterno
  • Bilanciamento del carico del proxy TCP esterno
  • Traffic Director
  • 35.191.0.0/16
  • 130.211.0.0/22
Regole firewall per tutti i prodotti tranne i bilanciatori del carico di rete
Bilanciamento del carico di rete

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

Importanza delle regole firewall

Google Cloud richiede la creazione delle regole 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 tuoi controlli di integrità. Per gli intervalli IP di origine, assicurati di utilizzare gli intervalli IP dei probe documentati elencati nella sezione precedente.

Se non hai regole firewall allow in entrata che consentono il controllo di integrità, la regola implicita deny blocca il traffico in entrata. Quando gli autori di test non possono contattare i tuoi backend, il bilanciatore del carico considera questi dispositivi in stato non integro. Il comportamento in caso di integrità dei backend dipende dal tipo di bilanciatore del carico:

  • Il bilanciatore del carico HTTP(S) esterno globale (classico) restituisce 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 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 scadono quando tutti i backend sono in stato non integro.

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

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

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

Considerazioni sulla sicurezza per gli intervalli IP del probe

Prendi in considerazione le seguenti informazioni quando pianifichi i controlli di integrità e le regole necessarie per il firewall.

  • Gli intervalli IP dei 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 probe.

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

  • Gli intervalli IP dei probe sono un insieme completo di possenti 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 notifiche.

Più probe e frequenza

Google Cloud invia probe di controllo di integrità da più sistemi ridondanti denominati prober. I probe utilizzano intervalli IP di origine specifici. Google Cloud non si basa su un solo prober per implementare un controllo di integrità: più probe valuta contemporaneamente le istanze nei backend di gruppi di istanze o gli endpoint nei backend NEG di zona. Se un probe non riesce, Google Cloud continua a monitorare gli stati di integrità del backend.

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

Questo è 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 ogni 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, definisci una frequenza di base utilizzata da ogni prober 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 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 TCP/UDP interni. Se hai configurato più regole di forwarding interno (ognuno con un indirizzo IP diverso) che punta allo stesso servizio di backend interno a livello di area geografica, 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 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ù probes per verificare l'indirizzo IP associato a ogni 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 SSL esterni, bilanciatori del carico TCP esterni e bilanciatori del carico TCP interni a livello di area geografica. Se hai configurato più proxy di destinazione che indirizzano il traffico allo stesso servizio di backend, Google Cloud utilizza più probes per verificare l'indirizzo IP associato a ogni 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 delle somma delle frequenze di ciascun controllo di integrità del servizio di backend.

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

Destinazione per i pacchetti di probe

La tabella seguente mostra gli indirizzi IP di rete e 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 associarsi all'indirizzo IP del bilanciatore del carico (o di 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 proxy TCP esterno
  • Bilanciatore del carico proxy TCP interno a livello di area geografica (anteprima)
  • 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 i probe a ogni indirizzo IP della regola di forwarding. Ciò può causare un aumento del numero di probe.
Bilanciatore del carico TCP/UDP interno 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 scoprire di più, consulta le pagine relative ai servizi e alle 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 a ogni indirizzo IP della regola di forwarding. Ciò può causare 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 eseguire le operazioni seguenti:

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

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

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 (byte singolo). Se configurata, Google Cloud prevede che questa stringa rientri nei primi 1024 byte della risposta in aggiunta alla ricezione dello 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 di Google Cloud può completare correttamente un handshake SSL o TCP prima del timeout del probe configurato.
  • Per i controlli di integrità TCP, la sessione TCP viene terminata normalmente tramite:
    • Il backend, oppure
    • Il probe di Google Cloud invia un pacchetto TCP RST (reset) mentre è ancora stabilita la sessione TCP al prober

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 una scadenza dell'abbonamento 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 valuta se un probe ha esito positivo 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
Né richiesta né risposta specificata

Nessuno specificato: --request, --response
Google Cloud considera valido il probe quando le condizioni di base sono soddisfatte.
Sia la richiesta che la risposta sono 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 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.

Devi utilizzare --response da sola 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 nessuna, non viene 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 i seguenti articoli:

Stato funzionamento

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

Flag di configurazione Scopo Valore predefinito
Soglia stato integro
healthy-threshold
La soglia di integrità specifica il numero di risultati di 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 sequenziali di probe non riusciti affinché un backend sia considerato in stato non integro. Una soglia di 2 probe.

Google Cloud considera i backend in stato integro dopo che è stata raggiunta questa soglia di integrità. I backend in stato integro sono idonei a ricevere nuove connessioni.

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

Le connessioni esistenti potrebbero non riuscire a restituire le risposte, a seconda della causa dell'errore del probe. Un backend in stato non integro può diventare integro se è in grado di soddisfare nuovamente la soglia di stato integro.

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 indicare ai probe del controllo di integrità Google Cloud di convalidare in modo più completo la risposta del tuo backend.

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

  • Configura un controllo di integrità basato su contenuti SSL o TCP specificando una stringa di risposta prevista e, facoltativamente, definendo una stringa di richiesta. Per maggiori dettagli, consulta la sezione Criteri di successo per SSL e TCP.

Certificati e controlli di integrità

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

  • Puoi utilizzare i certificati autofirmati o i certificati firmati da qualsiasi autorità di certificazione (CA).
  • Sono accettati i certificati scaduti o non ancora validi.
  • Né gli attributi CN né gli attributi 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 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 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 per il controllo di integrità. Le impostazioni di intervallo e timeout vengono applicate a ciascun sistema. Per ulteriori informazioni, consulta la sezione Sonde e frequenza multiple.
  2. Ogni controllo di integrità verifica quanto segue:

    1. Avvia una connessione HTTP da uno degli indirizzi IP di origine all'istanza di backend ogni 30 secondi.
    2. Attendi 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 dell'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 o una connessione.
    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 prober avvia una connessione ogni 30 secondi. Passano trenta secondi tra un tentativo di connessione e l'altro, 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, che non aumenta mai.

In questo esempio, il tempo di ciascun prober è simile al seguente, in secondi:

  1. t=0: Avvia il probe A.
  2. t=5: Arresta il probe A.
  3. t=30: Avvia probe B.
  4. t=35: Arresta il probe B.
  5. t=60: Avvia probe C.
  6. t=65: Arresta il probe C.

Passaggi successivi