Probe di integrità di Azure Load Balancer
Un probe di integrità di Azure Load Balancer è una funzionalità che rileva lo stato di integrità delle istanze dell'applicazione. Invia una richiesta alle istanze per verificare se sono disponibili e rispondere alle richieste. Il probe di integrità può essere configurato per l'uso di protocolli diversi, come TCP, HTTP o HTTPS. È una funzionalità importante perché consente di rilevare gli errori dell'applicazione, gestire il carico e pianificare i tempi di inattività.
Le regole di Azure Load Balancer richiedono un probe di integrità per rilevare lo stato dell'endpoint. La configurazione del probe di integrità e delle risposte del probe determina quali istanze del pool back-end ricevono nuove connessioni. È possibile utilizzare i probe di integrità per rilevare l'errore di un'applicazione. Generare una risposta personalizzata a un probe di integrità. Usare il probe di integrità per il controllo del flusso per gestire il carico o il tempo di inattività pianificato. Se il probe di integrità non riesce, il servizio di bilanciamento del carico interrompe l'invio di nuove connessioni alla relativa istanza non integra. La connettività in uscita non è interessata, ma solo quella in ingresso.
Protocolli del probe
I probe di integrità supportano più protocolli. La disponibilità di uno specifico protocollo del probe di integrità dipende dalla SKU di Load Balancer. Anche il comportamento del servizio varia a seconda della SKU di Load Balancer, come mostrato nella tabella seguente:
| SKU Standard | SKU Basic | |
|---|---|---|
| Protocollo del probe | TCP, HTTP, HTTPS | TCP, HTTP |
| Comportamento in caso di inattività dei probe | Tutti i probe sono inattivi, tutti i flussi TCP continuano. | Tutti i probe sono inattivi, tutti i flussi TCP scadono. |
Proprietà del probe
I probe di integrità hanno le seguenti proprietà:
| Nome proprietà del probe di integrità | Dettagli |
|---|---|
| Nome | Nome del probe di integrità. Si tratta di un nome che serve per definire per il probe di integrità |
| Protocollo | Protocollo del probe di integrità. Il tipo di protocollo che si desidera usare per il probe di integrità. Le opzioni sono: TCP, HTTP, HTTPS |
| Porta | Porta del probe di integrità. La porta di destinazione che si desidera usare per il probe di integrità quando si connette alla macchina virtuale per controllarne lo stato di integrità |
| Intervallo (secondi) | Intervallo del probe di integrità. Intervallo di tempo (in secondi) tra i diversi probe per due tentativi di probe di integrità consecutivi sulla macchina virtuale |
| Usato da | Elenco di regole di bilanciamento del carico che usano questo probe di integrità specifico. Deve essere presente almeno una regola che usa il probe di integrità affinché questa configurazione sia effettiva |
Configurazione del probe
La configurazione del probe di integrità è costituita dai seguenti elementi:
| Configurazione del probe di integrità | Dettagli |
|---|---|
| Protocollo | Protocollo del probe di integrità. Il tipo di protocollo che si desidera usare per il probe di integrità. Le opzioni disponibili sono: TCP, HTTP, HTTPS |
| Porta | Porta del probe di integrità. La porta di destinazione che dovrà essere usata dal probe di integrità quando si connette alla macchina virtuale per controllarne lo stato di integrità. È necessario assicurarsi che la macchina virtuale sia in ascolto anche su questa porta, ovvero che la porta sia aperta. |
| Intervallo | Intervallo del probe di integrità. Intervallo di tempo (in secondi) tra i tentativi di controlli di integrità consecutivi alla macchina virtuale |
Protocollo probe
Il protocollo usato dal probe di integrità può essere configurato su una delle opzioni seguenti: TCP, HTTP, HTTPS.
| Scenario | Probe TCP | Probe HTTP/HTTPS |
|---|---|---|
| Panoramica | I probe TCP avviano una connessione tramite l'esecuzione di un handshake TCP aperto a tre vie con la porta definita, I probe TCP terminano una connessione con un handshake TCP chiuso a quattro vie. | HTTP e HTTPS rilasciano HTTP GET con il percorso specificato. Entrambi i probe supportano i percorsi relativi per HTTP GET. I probe HTTPS sono uguali ai probe HTTP con l'aggiunta di un Transport Layer Security (TLS). I probe HTTP / HTTPS possono essere utili per implementare la logica personalizzata per rimuovere le istanze dal bilanciamento del carico se la porta del probe è anche il listener per il servizio. |
| Comportamento di errore del probe | Un probe TCP ha esito negativo quando: 1. Il listener TCP sull'istanza non invia alcuna risposta durante il periodo di timeout. Un probe viene contrassegnato in base alla configurazione del numero di richieste di probe con timeout che possono rimanere senza risposta prima che il probe sia contrassegnato come inattivo. 2. Il probe riceve un TCP Reset dall'istanza. | Un probe HTTP/HTTPS ha esito negativo quando: 1. L'endpoint del probe restituisce un codice di risposta HTTP diverso da 200, ad esempio 403, 404 o 500. 2. L'endpoint del probe non invia alcuna risposta durante l'intervallo di probe minimo e il periodo di timeout di 30 secondi. Più richieste di probe potrebbero non ricevere risposta prima che il probe venga contrassegnato come non in esecuzione e fino a quando non viene raggiunta la somma di tutti gli intervalli di timeout. 3. L'endpoint del probe chiude la connessione tramite l'invio di un TCP Reset. |
| Comportamento di probe attivo | I probe di integrità TCP sono considerati integri e contrassegnano come integro l'endpoint back-end quando: 1. Il probe di integrità ha esito positivo dopo l'avvio della macchina virtuale. 2. Qualsiasi endpoint back-end che ha raggiunto uno stato di integrità è idoneo per la ricezione di nuovi flussi. | Il probe di integrità viene contrassegnato come inattivo quando l'istanza risponde con uno stato HTTP 200 entro il periodo di timeout. I probe di integrità HTTP/HTTPS sono considerati integri e contrassegnano l'endpoint back-end come integro quando: 1. Il probe di integrità ha esito positivo dopo l'avvio della macchina virtuale. 2. Qualsiasi endpoint back-end che ha raggiunto uno stato di integrità è idoneo per la ricezione di nuovi flussi. |
Nota
Il probe HTTPS richiede l'uso di certificati basati su un hash di firma minimo di SHA256 nell'intera catena.
Comportamento in caso di inattività dei probe
| Scenario | Connessioni TCP | Datagrammi UDP |
|---|---|---|
| Probe a istanza singola inattivi | Le nuove connessioni TCP hanno esito positivo per l'endpoint back-end integro rimanente. Le connessioni TCP stabilite a questo endpoint back-end continuano. | I flussi UDP esistenti passano a un'altra istanza integra nel pool back-end. |
| Probe di tutte le istanze inattivi | Nessun nuovo flusso viene inviato al pool back-end. Load Balancer Standard consente ai flussi TCP stabiliti di continuare, purché un pool back-end abbia più di un'istanza back-end. Load Balancer Basic termina tutti i flussi TCP esistenti verso il pool back-end. | Tutti i flussi UDP esistenti terminano. |
Timeout e intervallo di probe
Il valore di intervallo determina la frequenza con cui il probe di integrità verifica la presenza di una risposta da parte delle istanze del pool back-end. Se il probe di integrità non riesce, le istanze del pool back-end vengono immediatamente contrassegnate come non integre. Se il probe di integrità ha esito positivo nel probe integro successivo, Azure Load Balancer contrassegna le istanze del pool back-end come integre. Per impostazione predefinita nel portale di Azure, il probe di integrità tenta di controllare la porta del probe di integrità configurata ogni 5 secondi, ma può essere impostato su un altro valore.
Per garantire la ricezione di una risposta tempestiva, i probe di integrità HTTP/S hanno timeout predefiniti. Di seguito sono riportate le durate di timeout per i probe TCP e HTTP/S:
- Durata del timeout del probe TCP: N/D (i probe avranno esito negativo dopo il superamento della durata dell'intervallo del probe configurato e l'invio del probe successivo)
- Durata del timeout del probe HTTP/S: 30 secondi
Per i probe HTTP/S, se l'intervallo configurato è più lungo del periodo di timeout sopra indicato, il probe di integrità andrà in timeout e avrà esito negativo se non viene ricevuta alcuna risposta durante il periodo di timeout. Ad esempio, se un probe di integrità HTTP è configurato con un intervallo di probe di 120 secondi (ogni 2 minuti) e non viene ricevuta alcuna risposta al probe entro i primi 30 secondi, il probe avrà raggiunto il periodo di timeout e avrà esito negativo. Quando l'intervallo configurato è più breve del periodo di timeout precedente, il probe di integrità avrà esito negativo se non viene ricevuta alcuna risposta prima del completamento del periodo di intervallo configurato e il probe successivo verrà inviato immediatamente.
Indicazioni per la progettazione
Quando si progetta il modello di integrità per l'applicazione, eseguire il probe di una porta in un endpoint back-end che rifletta l'integrità dell'istanza e del servizio dell'applicazione. La porta dell'applicazione e la porta del probe non devono necessariamente corrispondere. In alcuni scenari, potrebbe essere utile differenziare la porta del probe dalla porta utilizzata dall'applicazione, ma in generale è consigliabile utilizzare la stessa porta.
Può essere utile per l'applicazione generare una risposta al probe di integrità e segnalare al servizio di bilanciamento del carico se l'istanza deve ricevere nuove connessioni. È possibile modificare la risposta del probe per limitare il recapito di nuove connessioni a un'istanza attraverso l'esito negativo del probe di integrità. È possibile preparare la manutenzione dell'applicazione e avviare lo svuotamento delle connessioni all'applicazione. Un segnale di probe inattivo consentirà sempre ai flussi TCP di continuare fino al timeout di inattività o alla chiusura della connessione in un Load Balancer Standard.
Per un'applicazione con carico bilanciato UDP, generare un segnale di probe di integrità personalizzato dall'endpoint back-end. Per il probe di integrità, usare TCP, HTTP o HTTPS corrispondente al relativo listener.
Regola di bilanciamento del carico delle porte a disponibilità elevata con Load Balancer Standard. Viene bilanciato il carico per tutte le porte e una singola risposta del probe di integrità deve riflettere lo stato dell'intera istanza.
Non convertire o eseguire il proxy di un probe di integrità tramite l'istanza che riceve il probe di integrità a un'altra istanza della rete virtuale. Questa configurazione può causare errori nello scenario. Ad esempio, un set di appliance di terze parti viene distribuito nel pool back-end di un servizio di bilanciamento del carico per fornire scalabilità e ridondanza per gli appliance. Il probe di integrità è configurato per eseguire il probe di una porta per cui l'appliance di terze parti esegue il proxy o la conversione ad altre macchine virtuali dietro l'appliance. Se si esegue il probe della stessa porta in uso per la conversione o per l'esecuzione del proxy alle altre macchine virtuali dietro l'appliance, ogni risposta di probe da una singola macchina virtuale contrassegnerà l'appliance ultima come inattiva. Questa configurazione può causare un errore a catena dell'applicazione. Il trigger può essere un errore intermittente del probe che porta il servizio di bilanciamento del carico a contrassegnare come inattiva l'istanza dell'app. Questa azione può disabilitare l'applicazione. Eseguire il probe dell'integrità dell'appliance stesso. La selezione del probe per determinare il segnale di integrità è una considerazione importante per gli scenari di appliance virtuali di rete (NVA). Consultare il fornitore dell'applicazione per conoscere il segnale di integrità appropriato per questi scenari.
Se si dispone di più interfacce configurate nella macchina virtuale, assicurarsi di rispondere al probe nell'interfaccia su cui è stato ricevuto. Potrebbe essere necessario generare l'indirizzo di rete e convertirlo nella macchina virtuale in base a ogni interfaccia.
Si noti che una definizione di probe non è obbligatoria né verificata quando si usano Azure PowerShell, l'interfaccia della riga di comando di Azure, i modelli o l'API. I test di convalida del probe vengono eseguiti solo quando si usa il portale di Azure.
Se l'integrità di un probe varia, il servizio di bilanciamento del carico attende più a lungo prima di ripristinare lo stato di integrità dell'endpoint back-end. Questo tempo di attesa aggiuntivo protegge l'utente e l'infrastruttura ed è un criterio voluto.
Verificare che le istanze della macchina virtuale siano in esecuzione. Per ogni istanza in esecuzione nel pool back-end, il probe di integrità verifica la disponibilità. Se un'istanza viene arrestata, non verrà sottoposta a probe fino a quando non viene riavviata.
Evitare di configurare la rete virtuale con l'intervallo di indirizzi IP di proprietà di Microsoft, che contiene 168.63.129.16. Tale configurazione è in conflitto con l'indirizzo IP del probe di integrità e potrebbe causare un esito negativo dello scenario.
Per testare un errore del probe di integrità o contrassegnare una singola istanza come inattiva, è possibile usare un gruppo di sicurezza di rete per bloccare esplicitamente il probe di integrità. Creare una regola del gruppo di sicurezza di rete per bloccare la porta di destinazione o l'indirizzo IP di origine per simulare l'errore di un probe.
A differenza delle regole di bilanciamento del carico, le regole NAT in ingresso non richiedono un probe di integrità collegato.
Non è consigliabile bloccare l'IP o la porta del probe di integrità di Azure Load Balancer con regole del gruppo di sicurezza di rete. Si tratta di uno scenario non supportato e può causare l'effetto ritardato delle regole del gruppo di sicurezza di rete, determinando che i probe di integrità rappresentano in modo non accurato la disponibilità delle istanze back-end.
Monitoraggio
Load Balancer Standard espone lo stato del probe di integrità per endpoint e endpoint back-end tramite Monitoraggio di Azure. Altri servizi di Azure o applicazioni partner possono usare queste metriche. I log di Monitoraggio di Azure non sono supportati per Load Balancer Basic.
Indirizzo IP di origine dei probe
Per consentire al probe di integrità di Azure Load Balancer di contrassegnare l'istanza come attiva, è necessario autorizzare l'indirizzo IP 168.63.129.16 in qualsiasi gruppo di sicurezza di rete di Azure e criterio di firewall locale. Il tag del servizio AzureLoadBalancer identifica questo indirizzo IP di origine nei gruppi di sicurezza di rete e consente il traffico dei probe di integrità per impostazione predefinita. È possibile ottenere altre informazioni su questo IP qui.
Se non si consente l'indirizzo IP di origine del probe nei criteri firewall, il probe di integrità avrà esito negativo, perché non sarà in grado di raggiungere l'istanza. A sua volta, Azure Load Balancer contrassegnerà l'istanza come inattiva a causa dell'errore del probe di integrità. Questo errore di configurazione può causare un esito negativo nello scenario dell'applicazione con bilanciamento di carico. Tutti i probe di integrità di Load Balancer IPv4 sono originati dall'indirizzo IP 168.63.129.16 come la rispettiva origine. I probe IPv6 usano un indirizzo locale di link (fe80::1234:5678:9abc) come origine. Per un Azure Load Balancer dual stack, è necessario configurare un gruppo di sicurezza di rete per il funzionamento del probe di integrità IPv6.
Limiti
I probe HTTPS non supportano l'autenticazione reciproca con un certificato client.
I probe HTTP non supportano l'uso di nomi host per i back-end di probe
L'abilitazione dei timestamp TCP può causare limitazioni o altri problemi di prestazioni, che possono quindi causare il timeout dei probe di integrità.
Un probe di integrità del servizio di bilanciamento del carico SKU Basic non è supportato con un set di scalabilità di macchine virtuali.
I probe HTTP non supportano il probe sulle porte seguenti a causa di problemi di sicurezza: 19, 21, 25, 70, 110, 119, 143, 220, 993.