Panoramica dei controlli di integrità

Trusted Cloud by S3NS offre controlli di integrità configurabili per i backend del Trusted Cloud bilanciatore del carico e la riparazione automatica basata sull'applicazione per i gruppi di istanze gestiti. Questo documento tratta i concetti chiave del controllo di integrità.

Se non diversamente indicato, Trusted Cloud i controlli di integrità 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 viene chiamato probe. Trusted 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 vengono considerati integri. I backend che non rispondono correttamente per un numero configurabile separatamente sono non integri.

Lo stato di integrità generale di ogni backend determina l'idoneità a ricevere nuove richieste o connessioni. Puoi configurare i criteri che definiscono un probe riuscito. Questo aspetto è trattato 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 definiti nella rete Virtual Private Cloud (VPC). Per saperne di più, consulta Percorsi per i controlli di integrità.

Protocolli, porte e categorie per il controllo di integrità

I controlli di integrità hanno una categoria e un protocollo. Le due categorie sono controlli di integrità e controlli di integrità legacy e i protocolli supportati sono i seguenti:

• Controlli di integrità

  • Regionale (gRPC, TCP, SSL, HTTP, HTTPS o HTTP/2)
  • gRPC regionale (con TLS) (anteprima)
  • Globale (gRPC, TCP, SSL, HTTP, HTTPS o HTTP/2)
  • gRPC globale (con TLS) (anteprima)

• Controlli di integrità legacy:

  • Globale precedente (HTTP)

Il protocollo e la porta determinano la modalità di esecuzione dei probe di 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à legacy in un controllo di integrità e non puoi convertire un controllo di integrità in un controllo di integrità legacy.

Seleziona un controllo di integrità

I controlli di integrità devono essere compatibili con il tipo di bilanciatore del carico 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. Solo i bilanciatori del carico di rete passthrough esterni basati su pool target richiedono controlli di integrità legacy. Per tutti gli altri prodotti, utilizzerai i normali controlli di integrità.
• Protocollo:protocollo utilizzato da Trusted Cloud per eseguire il probe dei backend. È consigliabile utilizzare un controllo di integrità (o un controllo di integrità legacy) il cui protocollo corrisponda al protocollo utilizzato dal servizio di backend o dal pool di destinazione del bilanciatore del carico. Tuttavia, i protocolli di controllo di integrità e i protocolli del bilanciatore del carico non devono essere gli stessi.
• Specifica della porta:le porte che Trusted Cloud utilizza con il protocollo. 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 solo metodo: --port. Per ulteriori informazioni sui requisiti della porta del controllo di integrità per bilanciatore del carico, consulta la sezione Flag di specifica della porta.

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

Guida al bilanciatore del carico

Questa tabella mostra la categoria e l'ambito del controllo di integrità supportati per ogni tipo di bilanciatore del carico.

Bilanciatore del carico	Categoria e ambito del controllo di integrità
Bilanciatore del carico delle applicazioni esterno regionale Bilanciatore del carico delle applicazioni interno regionale Bilanciatore del carico di rete proxy interno regionale Bilanciatore del carico di rete proxy esterno regionale	Controllo di integrità (regionale)
Bilanciatore del carico di rete passthrough esterno	Bilanciatore del carico basato sui servizi di backend: controllo di integrità (regionale) Bilanciatore del carico basato su pool di destinazione: controllo di integrità legacy (globale con il protocollo HTTP)
Bilanciatore del carico di rete passthrough interno	Controllo di integrità (globale o regionale)

Note aggiuntive sull'utilizzo

• Per i backend dei gruppi di istanze VM, i controlli di integrità vengono eseguiti solo sulle istanze VM avviate. Le istanze VM arrestate non ricevono pacchetti di controllo di integrità.

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

• Un bilanciatore del carico di rete passthrough esterno basato su pool di destinazione deve utilizzare un controllo di integrità HTTP legacy. Non può utilizzare un controllo di integrità HTTPS legacy o qualsiasi controllo di integrità non legacy. Se utilizzi un bilanciatore del carico di rete passthrough esterno basato su pool di destinazione per bilanciare il traffico TCP, devi eseguire un servizio HTTP sulle VM sottoposte a bilanciamento del carico in modo che possano rispondere ai probe di controllo di integrità'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.

• Per i servizi di backend che utilizzano il protocollo gRPC, utilizza solo i controlli di integrità gRPC o TCP. Non utilizzare controlli di integrità HTTP(S) o HTTP/2.

• Alcuni bilanciatori del carico basati su Envoy che utilizzano backend NEG ibridi non supportano i controlli di integrità gRPC. Per ulteriori informazioni, consulta la panoramica dei NEG ibridi.

Come funzionano i controlli di integrità

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

Probe

Quando crei un controllo di integrità o un controllo di integrità legacy, 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 gli endpoint nei NEG di zona.

Le impostazioni di un controllo di integrità non possono essere configurate per ogni backend. I controlli di integrità sono associati a un intero servizio di backend. Per un bilanciatore del carico di rete passthrough esterno basato su pool di destinazione, un controllo di integrità HTTP legacy è associato all'intero pool di destinazione. Pertanto, i parametri del probe sono gli stessi per tutti i backend a cui fa riferimento un determinato servizio di backend o pool di destinazione.

Flag di configurazione	Finalità	Valore predefinito
Intervallo di controllo check-interval	L'intervallo di controllo è l'intervallo di tempo dall'inizio di un probe emesso da un prober all'inizio del probe successivo emesso dallo stesso prober. Le unità sono in secondi.	5s (5 secondi)
Timeout timeout	Il timeout è il tempo di attesa da parte di Trusted 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 di probing e regole firewall

Affinché i controlli di integrità funzionino, devi creare regole firewall in entrata allow in modo che il traffico proveniente dai prober Trusted Cloud possa connettersi ai tuoi backend. Per istruzioni, vedi Creare le regole firewall obbligatorie.

La tabella seguente mostra gli intervalli IP di origine da consentire per ogni bilanciatore del carico:

Prodotto	Intervalli IP di origine dei probe di controllo di integrità
Bilanciatore del carico delle applicazioni esterno regionale Bilanciatore del carico delle applicazioni interno regionale Bilanciatore del carico di rete proxy esterno regionale Bilanciatore del carico di rete proxy interno regionale Bilanciatore del carico di rete passthrough interno	Per il traffico IPv4 verso i backend: 177.222.80.0/23 Per il traffico IPv6 verso i backend: 2a13:7500:8301:b029:0:2b::/96
Bilanciatore del carico di rete passthrough esterno	Per il traffico IPv4 verso i backend: 177.222.87.64/26 Per il traffico IPv6 verso i backend: 2a13:7500:241:30::/64 Per i bilanciatori del carico basati su pool di destinazione: 177.222.87.0/26

Importanza delle regole firewall

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

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

Considerazioni sulla sicurezza per gli intervalli IP di probe

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

• Gli intervalli IP del probe appartengono a Google. Trusted Cloud utilizza route speciali al di fuori 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 del controllo di integrità per bilanciatori del carico delle applicazioni esterni e bilanciatori del carico di rete proxy esterni. Se un pacchetto viene ricevuto da internet e l'indirizzo IP di origine del pacchetto rientra in un intervallo IP di probe, Google lo elimina. Ciò include l'indirizzo IP esterno di un'istanza Compute Engine o di un nodo Google Kubernetes Engine (GKE).

• Gli intervalli IP dei probe sono un insieme completo di indirizzi IP possibili utilizzati dai probeTrusted Cloud . Se utilizzi tcpdump o uno strumento simile, potresti non osservare il traffico di tutti gli indirizzi IP in tutti gli intervalli IP di probe. Come best practice, crea regole firewall in entrata che consentano tutti gli intervalli IP dei probe come origini. Trusted Cloud può implementare nuovi prober automaticamente senza notifica.

Più sonde e frequenza

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

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

Questo è il comportamento previsto e non puoi configurare il numero di probe che Trusted Cloud utilizza per i controlli di integrità. Tuttavia, puoi stimare l'effetto di più probe simultanei considerando i seguenti fattori.

• Per stimare la frequenza di probing per servizio di backend, considera quanto segue:

  • Frequenza di base per servizio di backend. Ogni controllo di integrità ha una frequenza di controllo associata, inversamente proporzionale all'intervallo di controllo configurato:

    ¹⁄_{(intervallo di controllo)}

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

  • Fattore di scala del probe. La frequenza di base del servizio di backend viene moltiplicata per il numero di probe simultanei utilizzati da Trusted Cloud . Questo numero può variare, ma in genere è compreso tra 5 e 10.

• Più regole di forwarding per i 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 regionale,Trusted 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 passthrough esterni. Se hai configurato più regole di forwarding che puntano allo stesso servizio di backend o allo stesso pool di destinazione, Trusted Cloud utilizza più probe 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 i bilanciatori del carico delle applicazioni esterni. Se hai più proxy di destinazione che indirizzano il traffico alla stessa mappa URL, Trusted Cloud utilizza più probe per controllare l'indirizzo IP associato a ogni proxy di destinazione. La frequenza di probe per servizio di backend viene moltiplicata per il numero di proxy di destinazione configurati.

• Più proxy di destinazione per i bilanciatori del carico di rete proxy esterni e i bilanciatori del carico di rete proxy interni regionali. Se hai configurato più proxy di destinazione che indirizzano il traffico allo stesso servizio di backend, Trusted Cloud utilizza più probe per controllare l'indirizzo IP associato a ogni proxy di destinazione. La frequenza dei 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 una frequenza pari alla somma delle frequenze del controllo di integrità di ciascun servizio di backend.

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

Destinazione per i pacchetti di probing

La tabella seguente mostra l'interfaccia di rete e gli indirizzi IP di destinazione a cui i probe del controllo di integrità inviano i pacchetti, a seconda del tipo di bilanciatore del carico.

Per i bilanciatori del carico di rete passthrough esterni e 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 regionale Bilanciatore del carico delle applicazioni interno regionale Bilanciatore del carico di rete proxy esterno regionale Bilanciatore del carico di rete proxy interno regionale	Per i backend dei gruppi di istanze, l'interfaccia di rete principale (nic0). Per i backend NEG di zona con endpoint GCE_VM_IP_PORT, l'interfaccia di rete nella rete VPC associata al NEG. Per i backend NEG di zona con endpoint NON_GCP_PRIVATE_IP_PORT, l'endpoint deve rappresentare un'interfaccia di una risorsa on-premise raggiungibile tramite una route nella rete VPC associata al NEG e nella regione che contiene il NEG.	Per i backend dei 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 di un intervallo IP alias dell'interfaccia di rete. Per i backend NEG di zona con endpoint NON_GCP_PRIVATE_IP_PORT, l'indirizzo IP dell'endpoint.
Bilanciatore del carico di rete passthrough esterno	Interfaccia di rete principale (nic0)	L'indirizzo IP della regola di forwarding esterno. Se più regole di forwarding puntano allo stesso servizio di backend (per i bilanciatori del carico di rete passthrough esterni basati su pool di destinazione, lo stesso pool di destinazione), Trusted 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 dei gruppi di istanze e i backend NEG a livello di zona con endpoint GCE_VM_IP, l'interfaccia di rete utilizzata dipende dalla configurazione del servizio di backend. Per maggiori dettagli, vedi Servizi di backend e interfacce di rete.	L'indirizzo IP della regola di forwarding interna. Se più regole di forwarding puntano allo stesso servizio di backend, Trusted Cloud invia probe all'indirizzo IP di ogni regola di forwarding. Ciò può comportare un aumento del numero di probe.

Criteri di esito positivo per HTTP, HTTPS e HTTP/2

I controlli di integrità HTTP, HTTPS e HTTP/2 richiedono sempre la ricezione di un codice di risposta HTTP 200 (OK) prima del timeout del controllo di integrità. Tutti gli altri codici di risposta HTTP, inclusi i codici di risposta di reindirizzamento come 301 e 302, sono considerati non integri.

Oltre a richiedere un codice di risposta HTTP 200 (OK), puoi:

• Configura ogni sonda di controllo di integrità'integrità per inviare richieste HTTP a un percorso di richiesta specifico anziché al percorso di richiesta predefinito, /.

• Configura ogni sonda di controllo di integrità per verificare la presenza di una stringa di risposta prevista nel corpo della risposta HTTP. La stringa di risposta prevista deve essere composta solo da caratteri ASCII stampabili a byte singolo, che si trovano all'interno dei primi 1024 byte del corpo della risposta HTTP.

La tabella seguente elenca le combinazioni valide di percorso della richiesta e flag di risposta disponibili per i controlli di integrità HTTP, HTTPS e HTTP/2.

Flag di configurazione	Comportamento del probe	Criteri di successo
Né --request-path né --response specificati	Il probe utilizza / come percorso della richiesta.	Solo codice di risposta HTTP 200 (OK).
Sono stati specificati sia --request-path che --response	Il probe utilizza il percorso della richiesta configurato.	Il codice di risposta HTTP 200 (OK) e fino ai primi 1024 caratteri ASCII del corpo della risposta HTTP devono corrispondere alla stringa di risposta prevista.
Solo --response specificato	Il probe utilizza / come percorso della richiesta.	Il codice di risposta HTTP 200 (OK) e fino ai primi 1024 caratteri ASCII del corpo della risposta HTTP devono corrispondere alla stringa di risposta prevista.
Solo --request-path specificato	Il probe utilizza il percorso della richiesta configurato.	Solo codice di risposta HTTP 200 (OK).

Criteri di successo per SSL e TCP

I controlli di integrità TCP e SSL hanno i seguenti criteri di successo di base:

• Per i controlli di integrità TCP, un prober del controllo di integrità deve aprire correttamente una connessione TCP al backend prima del timeout del controllo di integrità.

• Per i controlli di integrità SSL, un probe di controllo di integrità deve aprire correttamente una connessione TCP al backend e completare l'handshake TLS/SSL prima del timeout del controllo di integrità.

• Per i controlli di integrità TCP, la connessione TCP deve essere chiusa in uno dei seguenti modi:

  • Tramite l'invio di un pacchetto FIN o RST (reset) da parte del prober del controllo di integrità oppure
  • Il backend invia un pacchetto FIN. Se un backend invia un pacchetto TCP RST, il probe potrebbe essere considerato non riuscito se il prober del controllo di integrità ha già inviato un pacchetto FIN.

La tabella seguente elenca le combinazioni valide di flag di richiesta e risposta disponibili per i controlli di integrità TCP e SSL. I flag di richiesta e risposta devono essere costituiti solo da caratteri ASCII stampabili a byte singolo e ogni stringa non deve superare i 1024 caratteri.

Flag di configurazione	Comportamento del probe	Criteri di successo
Né --request né --response specificato	Il probe non invia alcuna stringa di richiesta.	Solo i criteri di successo di base.
Sono stati specificati sia --request che --response	Il probe invia la stringa di richiesta configurata.	I criteri di successo di base e la stringa di risposta ricevuta dal probe devono corrispondere esattamente alla stringa di risposta prevista.
Solo --response specificato	Il probe non invia alcuna stringa di richiesta.	I criteri di successo di base e la stringa di risposta ricevuta dal probe devono corrispondere esattamente alla stringa di risposta prevista.
Solo --request specificato	Il probe invia la stringa di richiesta configurata.	Solo i criteri di successo di base (nessuna stringa di risposta viene controllata).

Criteri di successo per gRPC

I controlli di integrità gRPC vengono utilizzati solo con applicazioni gRPC, Trusted Cloud bilanciatori del carico e Cloud Service Mesh. Trusted Cloud Supporta due tipi di controlli di integrità gRPC:

• I controlli di integrità GRPC_WITH_TLS (anteprima) vengono utilizzati per controllare l'integrità dei backend gRPC con TLS abilitato. Supportano la crittografia TLS non autenticata, il che significa che i controlli di integrità non verificano l'identità del server.
• I controlli di integrità GRPC vengono utilizzati per controllare l'integrità dei backend gRPC non sicuri. Non supportano l'autenticazione e la crittografia, pertanto non possono essere utilizzati per i backend gRPC con TLS abilitato.

Se utilizzi i controlli di integrità gRPC (con o senza TLS), 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.

Per ulteriori informazioni, consulta le seguenti risorse:

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

Criteri di successo per i controlli di integrità legacy

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

Stato di integrità

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

Flag di configurazione	Finalità	Valore predefinito
Soglia stato integro healthy-threshold	La soglia di integrità specifica il numero di risultati di probe sequenziali riusciti affinché un backend precedentemente non integro venga considerato integro.	Una soglia di 2 probe.
Soglia stato non integro unhealthy-threshold	La soglia di stato non integro specifica il numero di risultati di probe sequenziali non riusciti affinché un backend precedentemente integro venga considerato non integro.	Una soglia di 2 probe.

Trusted Cloud considera i backend integri dopo che è stata raggiunta questa soglia di integrità. I backend integri sono idonei a ricevere nuove connessioni.

Trusted Cloud considera i backend non integri quando la soglia di stato non integro è stata raggiunta. I backend non integri non sono idonei a ricevere nuove connessioni; tuttavia, le connessioni esistenti non vengono terminate immediatamente. La connessione rimane aperta finché non si verifica un timeout o finché il traffico non viene interrotto.

Le connessioni esistenti potrebbero non restituire risposte, a seconda della causa del mancato esito positivo del probe. Un backend non integro può tornare integro se è in grado di soddisfare di nuovo la soglia di integrità.

Il comportamento specifico quando tutti i backend non sono integri varia a seconda del tipo di bilanciatore del carico che utilizzi:

Note aggiuntive

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

Certificati e controlli di integrità

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

• Puoi utilizzare certificati autofirmati o certificati firmati da qualsiasi autorità di certificazione (CA).
• Sono accettabili i certificati scaduti o non ancora validi.
• Né l'attributo CN né l'attributo 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, 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.

Se utilizzi intestazioni delle richieste personalizzate, tieni presente che il bilanciatore del carico aggiunge queste intestazioni solo alle richieste client, non ai probe di controllo di integrità. Se il backend richiede un'intestazione specifica per l'autorizzazione che non è presente nel pacchetto di controllo di integrità, il controllo di integrità potrebbe non riuscire.

Esempio di controllo di integrità

Supponiamo di configurare 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 nel seguente modo:

1. Più sistemi ridondanti vengono configurati contemporaneamente con i parametri di controllo di integrità. Le impostazioni di intervallo e timeout vengono applicate a ogni sistema. Per saperne di più, vedi Più probe e frequenza.

2. Ogni sonda di 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 5 secondi un codice di stato HTTP 200 (OK) (i criteri di esito positivo per i protocolli HTTP, HTTPS e HTTP/2).

3. Un backend viene considerato non integro quando almeno un probe di controllo di integrità del sistema 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 del controllo di integrità riceve due risposte consecutive che corrispondono ai criteri di successo specifici del protocollo.

In questo esempio, ogni sonda avvia una connessione ogni 30 secondi. Tra i tentativi di connessione di un probe trascorrono 30 secondi, indipendentemente dalla durata del timeout (che la connessione abbia o meno raggiunto il timeout). In altre parole, il timeout deve sempre essere inferiore o uguale all'intervallo e non lo aumenta mai.

In questo esempio, la tempistica di ogni sonda è la seguente, in secondi:

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

Passaggi successivi

• Per creare, modificare e utilizzare i controlli di integrità, consulta Utilizzare i controlli di integrità.
• Per risolvere i problemi relativi ai controlli di integrità, abilita il logging dei controlli di integrità.