Documentazione di Oracle Cloud Infrastructure

Criteri di controllo dello stato per i load balancer di rete

Impostare e utilizzare i controlli dello stato per decidere la disponibilità dei server backend per un load balancer di rete.

Il controllo dello stato è un test che consente di confermare la disponibilità dei server backend. Un controllo dello stato può essere una richiesta o un tentativo di connessione. In base a un intervallo di tempo specificato, il load balancer di rete applica il criterio di controllo dello stato per monitorare continuamente i server backend. Se un server non supera il controllo dello stato, il load balancer di rete elimina temporaneamente la rotazione del server. Se in seguito il server supera il controllo dello stato, il load balancer di rete lo restituisce alla rotazione.

Puoi configurare il criterio di controllo dello stato quando crei un load balancer di rete. Inoltre, puoi configurare il criterio di controllo dello stato quando crei o modifichi un set backend per un load balancer esistente. Di seguito è riportato un riepilogo dei protocolli che è possibile utilizzare con il criterio di controllo dello stato.

  • I controlli dello stato a livello TCP cercano di effettuare una connessione TCP con i server backend e convalidano la risposta in base allo stato della connessione.

    Se non è pratico creare una richiesta per il protocollo con cui si sta lavorando, è possibile omettere i dati della richiesta. In questo caso, il backend viene considerato in buono stato se la connessione TCP riesce.

  • I controlli dello stato a livello HTTP inviano le richieste ai server backend utilizzando un URI specifico e convalidano la risposta in base al codice di stato o ai dati entità (corpo) restituiti.
  • I controlli dello stato a livello HTTPS inviano le richieste ai server backend utilizzando un URI specifico e convalidano la risposta in base al codice di stato o ai dati entità (corpo) restituiti tramite un protocollo HTTPS sicuro e cifrato.
  • I controlli dello stato a livello UDP inviano una singola richiesta al server backend e corrispondono alla risposta (se ricevuta) rispetto ai dati di risposta specificati.
  • I controlli dello stato a livello DNS inviano le richieste ai server backend utilizzando UDP o TCP. Il controllo dello stato utilizza anche il nome della query e le informazioni correlate che si desidera fornire alla risposta DNS dal server backend.

Il servizio offre funzionalità di controllo dello stato specifiche dell'applicazione che consentono di aumentare la disponibilità e ridurre la finestra di manutenzione dell'applicazione.

È possibile eseguire i task di gestione dei criteri di controllo dell'integrità riportati di seguito.

Configurazione del protocollo di controllo dello stato per la corrispondenza dell'applicazione o del servizio

Se si esegue un servizio HTTP, accertarsi di configurare un controllo dell'integrità a livello HTTP. Se si esegue un controllo dello stato a livello TCP su un servizio HTTP, è possibile che non si ottenga una risposta corretta. L'handshake TCP può riuscire e indicare che il servizio è attivo anche quando il servizio HTTP è configurato in modo errato o ha altri problemi. Sebbene il controllo dello stato sembri valido, i clienti potrebbero riscontrare errori nelle transazioni. Ad esempio:

  • Il servizio HTTP backend presenta problemi quando si parla dell'URL di controllo dello stato e l'URL di controllo dello stato restituisce 5XX messaggi. Un controllo dello stato HTTP recupera il messaggio dall'URL di controllo dello stato e lo contrassegna come inattivo. In questo caso, un handshake di controllo dello stato TCP ha esito positivo e contrassegna il servizio come integro, anche se il servizio HTTP potrebbe non essere utilizzabile.
  • Il servizio HTTP backend risponde con 4XX messaggi a causa di problemi di autorizzazione o di nessun contenuto configurato. Un controllo dello stato TCP non rileva questi errori.

Indicatori di stato dello stato di integrità

Il servizio Load balancer di rete fornisce indicatori di stato che utilizzano i criteri di controllo dello stato per generare report sullo stato generale dei load balancer di rete e dei relativi componenti. Gli indicatori di stato possono essere visualizzati nelle pagine Elenco e Dettagli della console per i load balancer, i set backend e i server backend. È anche possibile utilizzare l'API per recuperare queste informazioni.

Gli indicatori di stato sanitario hanno quattro livelli. La tabella seguente fornisce il significato generale di ogni livello:

Livello Colore descrizione;
OK Verde Nessuna attenzione richiesta.

La risorsa funziona come previsto.
Avvertenza Giallo Alcuni soggetti dichiaranti richiedono attenzione.

La risorsa non funziona al massimo dell'efficienza o la risorsa è incompleta e richiede ulteriore lavoro.
Critico Rosso Alcuni o tutti i soggetti dichiaranti richiedono un'attenzione immediata.

La risorsa non funziona o un errore imprevisto è imminente.
Sconosciute Gray Impossibile determinare lo stato.

La risorsa non risponde o è in transizione e potrebbe passare a un altro stato nel tempo.

Il significato preciso di ogni livello differisce tra i seguenti componenti:

Uso dello stato

Al livello più elevato, lo stato del load balancer di rete riflette lo stato dei relativi componenti. Gli indicatori dello stato di integrità forniscono informazioni che potrebbero essere necessarie per eseguire il drill-down e analizzare un problema esistente. Alcuni problemi comuni che gli indicatori dello stato di salute possono aiutare a rilevare e correggere includono:

Il controllo dello stato non è configurato correttamente.

In questo caso, tutti i server backend per uno o più listener interessati riportano come non integri. Se l'indagine eseguita rileva che i server backend non presentano problemi, è probabile che un set backend includa un controllo dello stato non configurato correttamente.

Configurazione errata di un listener.

Tutti gli indicatori di stato del server backend segnalano OK, ma il load balancer di rete non passa il traffico su un listener.

È possibile configurare il listener per:

  • Ascolto sulla porta sbagliata.
  • Utilizzare il protocollo errato.
  • Utilizzare il criterio errato.

Se l'indagine mostra che il listener non è in stato di errore, controllare la configurazione della lista di sicurezza.

Una regola di sicurezza non è configurata correttamente.

Gli indicatori dello stato di integrità consentono di diagnosticare due casi di regole di sicurezza configurate in modo errato:

  • Tutti gli indicatori dello stato di integrità dell'entità riportano OK, ma il traffico non scorre, come accade con i listener configurati in modo errato. Se il listener non è in stato di errore, controllare la configurazione della regola di sicurezza.
  • Tutti gli stati di integrità delle entità riportano come non in buono stato. La configurazione del controllo dello stato è stata controllata e i servizi sono stati eseguiti correttamente sui server backend.

    In questo caso, le regole di sicurezza potrebbero non includere l'intervallo IP per l'origine delle richieste di controllo dello stato. È possibile trovare l'IP di origine del controllo dello stato nella pagina Dettagli per ogni server backend. È inoltre possibile utilizzare l'API per trovare l'IP nel campo sourceIpAddress dell'oggetto HealthCheckResult.

    Nota

    L'IP di origine per le richieste di controllo dello stato proviene da un'istanza di computazione gestita dal servizio Load balancer di rete.

Uno o più server backend segnalano un cattivo stato.

Un server backend può essere in cattivo stato o il controllo dello stato potrebbe non essere configurato correttamente. Per visualizzare il codice di errore corrispondente, controllare il campo status nella pagina Details del server backend. È inoltre possibile utilizzare l'interfaccia API per trovare il codice di errore nel campo healthCheckStatus dell'oggetto HealthCheckResult.

Altri casi in cui lo stato di salute potrebbe rivelarsi utile includono:

Lo stato di integrità viene aggiornato ogni tre minuti. Non è disponibile una granularità più fine.

Lo stato non fornisce dati cronologici sullo stato.

Best practice per il controllo dello stato

Configurare il protocollo di controllo dello stato in modo che corrisponda all'applicazione o al servizio. Se si esegue un servizio HTTP, accertarsi di configurare un controllo dell'integrità a livello HTTP. Se si esegue un controllo dello stato a livello TCP su un servizio HTTP, è possibile che non si ottenga una risposta corretta. L'handshake TCP può riuscire e indicare che il servizio è attivo anche quando il servizio HTTP è configurato in modo errato o ha altri problemi. Sebbene il controllo dello stato sembri valido, i clienti potrebbero riscontrare errori nelle transazioni.

Ad esempio:

  • Il servizio HTTP backend presenta problemi quando si parla dell'URL di controllo dello stato e l'URL di controllo dello stato restituisce 5XX messaggi. Un controllo dello stato HTTP recupera il messaggio dall'URL di controllo dello stato e lo contrassegna come inattivo. In questo caso, un handshake di controllo dello stato TCP ha esito positivo e contrassegna il servizio come integro, anche se il servizio HTTP potrebbe non essere utilizzabile.
  • Il servizio HTTP backend risponde con 4XX messaggi a causa di problemi di autorizzazione o di nessun contenuto configurato. Un controllo dello stato TCP non rileva questi errori.

Effetti collaterali comuni della configurazione errata del controllo dello stato

Di seguito sono riportati gli effetti collaterali comuni della configurazione errata del controllo dello stato, che possono essere utilizzati per la risoluzione dei problemi.

  • Porta errata

    In questo scenario, tutti i server backend sono considerati in cattivo stato. Se i server backend non presentano problemi, è possibile che si sia verificato un errore durante l'impostazione della porta. La porta deve essere in ascolto e ha consentito il traffico sul backend.

    Errore di registrazione OCI: errno":"EHOSTUNREACH","syscall":"connect".

  • Percorso errato

    In questo scenario, tutti i server backend sono considerati in cattivo stato. Se i server backend non presentano problemi, è possibile che si sia verificato un errore durante l'impostazione del percorso per il controllo dello stato HTTP necessario per trovare una corrispondenza con un'applicazione effettiva nel server backend. In questo caso, è possibile utilizzare un test di curl da un sistema della stessa rete.

    Ad esempio: 

    $ curl -i http://10.0.0.5/health

    Si riceve il codice di stato configurato nella risposta Errore di log OCI: 

    "msg":"invalid statusCode","statusCode":404,"expected":"200".
  • Protocollo errato

    In questo scenario, tutti i server backend sono considerati in cattivo stato. Se i server backend non presentano problemi, è possibile che si sia verificato un errore durante l'impostazione del protocollo che deve corrispondere al protocollo in ascolto sul backend. Ad esempio: sono supportati solo i controlli dello stato TCP e HTTP. Se il server backend utilizza HTTPS, utilizzare TCP come protocollo.

    Errore di log OCI:

    "code":"EPROTO","errno":"EPROTO".
  • Codice di stato errato

    In questo scenario, tutti i server backend sono considerati in cattivo stato. Se i server backend non presentano problemi, per un controllo dello stato HTTP è possibile che si sia verificato un errore durante l'impostazione del codice di stato corrispondente al codice di stato effettivo restituito dal backend. Uno scenario comune è quando un backend sta restituendo un 302 e ti aspetti un 200. Questo risultato è probabilmente il backend che ti invia a una pagina di accesso o a un'altra posizione del server. In questo scenario, è possibile correggere il backend per restituire il codice previsto oppure utilizzare 302 nella configurazione di controllo dello stato.

    Errore di log OCI:

    "msg":"invalid statusCode","statusCode":XX,"expected":"200"

    dove XX è il codice di stato restituito.

  • Pattern regex errato

    Tutti i server backend presentano un report non salutare. Se i server backend non presentano problemi, è possibile che si sia verificato un errore durante l'impostazione di un pattern regex errato coerente con il corpo oppure che il backend non restituisca il corpo previsto. In questo scenario, è possibile modificare il backend in modo che corrisponda al pattern oppure correggere il pattern in modo che corrisponda al backend. Di seguito sono riportati alcuni esempi di pattern specifici.

    • Qualsiasi contenuto - ".*"
    • Una pagina che restituisce il valore "Status:OK:" - "Status:OK:.*"
    • Errore di registrazione OCI: "risultato corrispondenza risposta: non riuscito"
  • Gruppi di sicurezza di rete, liste di sicurezza o firewall locale configurati in modo errato

Tutti o alcuni server backend sono considerati in cattivo stato. Se i server backend non presentano problemi, è possibile che si sia verificato un errore durante la configurazione dei gruppi NSG, delle liste di sicurezza o dei firewall locali quali firewalld, iptables o SELiinux. In questo scenario è possibile utilizzare un test curl o netcat da un sistema che appartiene alla stessa subnet e allo stesso gruppo NSG dell'istanza del balancer HTTP:

Ad esempio: 

$ curl -i http://10.0.0.5/health TCP: ex: nc -zvw3 10.0.05 443.

È possibile controllare il firewall locale utilizzando il comando seguente: 

firewall-cmd --list-all --zone=public.

Se nel firewall mancano le regole previste è possibile utilizzare un set di comandi come questo per aggiungere il servizio: (esempio per la porta HTTP 80): 

  • firewall-cmd --zone=public --add-service=http
  • firewall-cmd --zone=public --permanent --add-service=http

Configurazione del protocollo di controllo dello stato per la corrispondenza tra l'applicazione o il servizio

Il servizio offre funzionalità di controllo dello stato specifiche dell'applicazione che consentono di aumentare la disponibilità e ridurre la finestra di manutenzione dell'applicazione.

Se si esegue un servizio HTTP, accertarsi di configurare un controllo dell'integrità a livello HTTP. Se si esegue un controllo dello stato a livello TCP su un servizio HTTP, è possibile che non si ottenga una risposta corretta. L'handshake TCP può riuscire e indicare che il servizio è attivo anche quando il servizio HTTP è configurato in modo errato o ha altri problemi. Sebbene il controllo dello stato sembri valido, i clienti potrebbero riscontrare errori nelle transazioni. Ad esempio:

  • Il servizio HTTP backend presenta problemi quando si parla dell'URL di controllo dello stato e l'URL di controllo dello stato restituisce 5XX messaggi. Un controllo dello stato HTTP recupera il messaggio dall'URL di controllo dello stato e lo contrassegna come inattivo. In questo caso, un handshake di controllo dello stato TCP ha esito positivo e contrassegna il servizio come integro, anche se il servizio HTTP potrebbe non essere utilizzabile.
  • Il servizio HTTP backend risponde con 4XX messaggi a causa di problemi di autorizzazione o di nessun contenuto configurato. Un controllo dello stato TCP non rileva questi errori.

Controllo dello stato DNS

Il servizio Load balancer di rete supporta il controllo dello stato DNS tramite il trasporto TCP e UDP per i server backend IPv4 e IPv6. Il controllo dello stato DNS per i server backend del resolver DNS è un miglioramento rispetto ai controlli basati su TCP o UDP, poiché verifica che il protocollo DNS sia funzionale per i server backend del resolver DNS. Tali protocolli utilizzano il formato base64 per specificare i messaggi di richiesta e risposta e ciò può essere difficile quando si formano richieste e risposte DNS. Inoltre, nel messaggio di risposta possono essere presenti diverse risposte valide e RCODE, ad esempio NOERROR(0) e NXDOMAIN(3). Non è possibile gestire tutti questi scenari utilizzando il controllo dello stato TCP o UDP standard.

Quando si crea un set backend, durante la creazione iniziale del load balancer di rete o quando si aggiunge un set backend a un load balancer di rete esistente, è necessario specificare le configurazioni specifiche del protocollo riportate di seguito se si utilizza il controllo dello stato DNS.

  • Nome query: fornire un nome di dominio DNS per la query.
  • Classe query: selezionare una delle seguenti opzioni:
    • IN: Internet (impostazione predefinita)
    • CH: Caos
  • Tipo di query: selezionare una delle seguenti opzioni:
    • A: indica un nome host corrispondente all'indirizzo IPv4. (impostazione predefinita)
    • AAAA: indica un nome host corrispondente all'indirizzo IPv6.
    • TXT: indica un campo di testo.
  • Codici di risposta accettabili: selezionare una o più opzioni tra quelle riportate di seguito.
    • Query DNS RCODE:0 NOERROR completata correttamente.
    • Il server RCODE:2 SERVFAIL non è riuscito a completare la richiesta DNS.
    • Il nome di dominio RCODE:3 NXDOMAIN non esiste.
    • RCODE:5 REFUSED Il server ha rifiutato di rispondere alla query.