Risolvere i problemi di integrità e di disponibilità delle risorse in ingresso

  • Articolo

Questo articolo illustra come analizzare i problemi che influiscono sulla disponibilità delle risorse back-end e dell'indirizzo IP front-end di Load Balancer.

Il controllo dell'integrità delle risorse per Load Balancer consente di determinare l'integrità di un'istanza di Load Balancer. Analizza la metrica Disponibilità del percorso dati in un intervallo di 2 minuti per determinare se sono disponibili endpoint di bilanciamento del carico e combinazioni di porte front-end e IP front-end con regole di bilanciamento del carico.

Nota: RHC non è supportato per Load Balancer SKU Basic

La tabella seguente descrive la logica RHC usata per determinare lo stato di integrità del servizio di bilanciamento del carico.

Stato di integrità delle risorse Descrizione
Disponibile La risorsa di Load Balancer Standard è integra e disponibile.
Degraded Il servizio di bilanciamento del carico standard ha eventi avviati dalla piattaforma o dall'utente che influiscono sulle prestazioni. La metrica Disponibilità del percorso dati ha restituito un valore di integrità inferiore al 90% ma maggiore del 25% per almeno due minuti. Si è quindi verificata una riduzione del livello delle prestazioni.
Non disponibile La risorsa del servizio di bilanciamento del carico standard non è integra. La metrica Disponibilità del percorso dati ha segnalato un valore di integrità inferiore al 25% per almeno due minuti. Si è quindi verificata una significativa riduzione delle prestazioni o una mancanza di disponibilità per la connettività in ingresso. Potrebbero verificarsi eventi utente o piattaforma che causano un'indisponibilità.
Sconosciuto Lo stato di integrità delle risorse per la risorsa di Load Balancer Standard non è stato ancora aggiornato o non ha ricevuto informazioni sulla disponibilità del percorso dati negli ultimi 10 minuti. Questo stato è temporaneo e rifletterà lo stato corretto non appena vengono ricevuti i dati.

Informazioni sulle metriche usate

Le due metriche da usare sono Disponibilità del percorso dati e Stato del probe di integrità ed è importante capirne il significato per ricavarne informazioni dettagliate corrette.

Disponibilità del percorso dati

La metrica di disponibilità del percorso dati viene generata da un ping TCP inviato ogni 25 secondi a tutte le porte front-end con bilanciamento del carico e regole NAT in ingresso configurate. Questo ping TCP viene instradato a una qualsiasi delle istanze back-end integre (su cui è stato eseguito il probe). Se il servizio riceve una risposta al ping, è una risposta con esito positivo e la somma della metrica viene iterata una volta. Se non viene ricevuta una risposta, non viene eseguita alcuna iterazione. Il conteggio di questa metrica è 1/100 del numero totale di ping TCP nel periodo di campionamento. Si vuole quindi considerare la media, ovvero la media di somma/conteggio nell'intervallo di tempo di riferimento. I dati mostrano la metrica di disponibilità del percorso aggregata in base alla media, in modo da poter ricavare la percentuale di esito positivo dei ping TCP alla porta o all'IP front-end per ognuna delle regole NAT in ingresso e di bilanciamento del carico.

Stato del probe di integrità

La metrica di stato del probe di integrità viene generata da un ping del protocollo definito nel probe di integrità. Questo ping viene inviato a ogni istanza del pool back-end e sulla porta definita nel probe di integrità. Per i probe HTTP e HTTPS, un ping con esito positivo richiede una risposta HTTP 200 OK, mentre con i probe TCP qualsiasi risposta viene considerata come esito positivo. Il numero di probe consecutivi con esito positivo o negativo determina l'integrità dell'istanza back-end e se il pool back-end assegnato è in grado di ricevere traffico. Analogamente alla metrica di disponibilità del percorso dati, viene usata l'aggregazione media, che indica la media dei ping con esito positivo sul numero totale durante l'intervallo di campionamento. Questo valore di stato del probe di integrità indica l'integrità del back-end in isolamento dal servizio di bilanciamento del carico eseguendo il probe delle istanze back-end senza inviare il traffico attraverso il front-end.

Importante

Lo stato del probe di integrità viene campionato a intervalli di un minuto. Possono quindi verificarsi piccole fluttuazioni in un valore altrimenti stabile. Se, ad esempio, sono presenti due istanze back-end, una con probe attivo e una con probe non attivo, il servizio probe di integrità può acquisire 7 campioni per l'istanza integra e 6 per l'istanza non integra. In questo modo, un valore che in precedenza rimaneva costante su 50 verrà visualizzato ora come 46,15 per un intervallo di un minuto.

Diagnosticare servizi di bilanciamento del carico degradati e non disponibili

Come descritto nell'articolo sull'integrità delle risorse, un servizio di bilanciamento del carico viene definito come danneggiato se mostra tra una disponibilità del percorso dati compresa tra il 25% e il 90%. Per essere definito come non disponibile, un servizio di bilanciamento del carico deve invece mostrare una disponibilità del percorso dati inferiore al 25% in un periodo di due minuti. È possibile eseguire la stessa procedura per analizzare un problema nello stato del probe di integrità o un avviso di disponibilità del percorso dati configurato. Si esaminerà uno scenario in cui, dopo aver controllato l'integrità delle risorse e aver identificato che il servizio di bilanciamento del carico non è disponibile con una disponibilità del percorso dati pari allo 0%, si determina che il servizio è inattivo.

Per prima cosa, si passa alla visualizzazione dettagliata delle metriche nella pagina delle informazioni sul servizio di bilanciamento del carico nel portale di Azure. Accedere alla visualizzazione dalla pagina della risorsa di bilanciamento del carico o dal collegamento presente nel messaggio relativo all'integrità della risorsa. Passare quindi alla scheda Disponibilità front-end e back-end ed esaminare una finestra di trenta minuti dell'intervallo di tempo in cui l'esito dello stato era danneggiato o non disponibile. Se la disponibilità del percorso dati è pari allo 0%, significa che si è verificato un problema che impedisce il traffico per tutte le regole NAT in ingresso e di bilanciamento del carico ed è possibile scoprire da quanto tempo dura questo problema.

La posizione successiva da esaminare è la metrica relativa allo stato del probe di integrità per determinare se il percorso dati non è disponibile perché non sono presenti istanze back-end integre per gestire il traffico. Se è presente almeno un'istanza back-end integra per tutte le regole di bilanciamento del carico e in ingresso, non è la configurazione a causare l'indisponibilità dei percorsi dati. Questo scenario indica quindi un problema della piattaforma Azure. Sebbene i problemi alla piattaforma siano rari, viene inviato un avviso automatizzato al team Microsoft che risolverà il problema in tempi rapidi.

Diagnosticare errori relativi al probe di integrità

Si supponga di controllare lo stato del probe di integrità e di scoprire che tutte le istanze vengono visualizzate come non integre. In questo caso, il percorso dati risulta non disponibile perché il traffico non ha alcuna destinazione. È quindi necessario consultare l'elenco di controllo seguente per escludere gli errori di configurazione comuni:

  • Controllare l'utilizzo della CPU per le risorse per determinare se sono sottoposte a un carico elevato.
  • Se si usa un probe HTTP o HTTPS, verificare che l'applicazione sia integra e reattiva.
    • Verificare che l'applicazione sia funzionale accedendo direttamente alle applicazioni tramite l'indirizzo IP privato o l'indirizzo IP pubblico a livello di istanza associato all'istanza back-end.
  • Esaminare i gruppi di sicurezza di rete applicati alle risorse back-end. Assicurarsi che non siano presenti regole con priorità più alta di AllowAzureLoadBalancerInBound che blocca il probe di integrità.
    • A tale scopo, consultare le impostazioni di rete delle macchine virtuali back-end o dei set di scalabilità di macchine virtuali.
    • Se si tratta di un problema relativo al gruppo di sicurezza di rete, spostare la regola Consenti esistente o creare una nuova regola ad alta priorità per consentire il traffico di AzureLoadBalancer.
  • Controllare il sistema operativo. Assicurarsi che le macchine virtuali siano in ascolto sulla porta probe e controllare le regole del firewall del sistema operativo per assicurarsi che non blocchino il traffico del probe proveniente dall'indirizzo IP 168.63.129.16.
    • È possibile controllare le porte di ascolto eseguendo netstat -a da un prompt dei comandi di Windows o netstat -l da un terminale Linux.
  • Assicurarsi di usare il protocollo corretto. Ad esempio, un probe che usa HTTP per eseguire il probe su una porta in ascolto di un'applicazione non HTTP avrà esito negativo.
  • Firewall di Azure non deve essere inserito nel pool back-end dei servizi di bilanciamento del carico. Per integrare correttamente Firewall di Azure con il servizio di bilanciamento del carico, vedere Integrare Firewall di Azure con Azure Load Balancer Standard.

Se dopo aver consultato l'elenco di controllo, si stanno ancora verificando errori del probe di integrità, potrebbero sussistere problemi di piattaforma, seppur rari, che compromettono il servizio probe per le istanze in uso. Anche in questo caso, viene inviato un avviso automatizzato al team Microsoft che risolverà il problema in tempi rapidi.

Passaggi successivi