Condividi tramite


Risolvere i problemi di stato di salute delle risorse Azure Load Balancer e di disponibilità in entrata

Sommario

Questo articolo consente di analizzare i problemi che influiscono sulla disponibilità dell'indirizzo IP front-end e delle risorse back-end del servizio di bilanciamento del carico.

È possibile usare la funzionalità integrità delle risorse in Azure Load Balancer per determinare lo stato di salute del bilanciatore di carico. Analizza la metrica Disponibilità del percorso dati per determinare se sono disponibili gli endpoint di bilanciamento del carico, l'IP frontend e le combinazioni di porte frontend con regole di bilanciamento del carico.

Annotazioni

Le Load Balancer di base non supportano la funzionalità integrità delle risorse.

La tabella seguente descrive la logica per determinare lo stato di integrità del bilanciatore del carico.

Stato di integrità delle risorse Descrizione
Disponibile La risorsa del servizio di bilanciamento del carico è integra e disponibile.
Degradato Il servizio di bilanciamento del carico ha eventi avviati dalla piattaforma o dall'utente che influiscono sulle prestazioni. La metrica Disponibilità percorso dati ha segnalato una salute inferiore al 90% ma superiore al 25% per almeno due minuti. Potrebbe verificarsi una riduzione delle prestazioni moderata o grave.
non disponibile La risorsa del bilanciamento del carico non è funzionante. La metrica Disponibilità percorso dati ha segnalato meno di 25% integrità per almeno due minuti. Potrebbe verificarsi una riduzione significativa delle prestazioni o una mancanza di disponibilità per la connettività in ingresso. Gli eventi dell'utente o della piattaforma potrebbero causare l'indisponibilità.
Unknown Lo stato di integrità della risorsa del servizio bilanciamento del carico non è stato aggiornato né sono state ricevute informazioni sulla disponibilità del percorso dati, negli ultimi 10 minuti. Questo stato potrebbe essere temporaneo o il servizio di bilanciamento del carico potrebbe non supportare la funzionalità di integrità delle risorse.

Monitorare la disponibilità del servizio di bilanciamento del carico

Le due metriche usate Azure Load Balancer per verificare l'integrità delle risorse sono Data Path Availability e Health Probe Status. È importante comprendere il loro significato per derivare informazioni dettagliate corrette.

Disponibilità percorso dati

Un ping TCP genera la metrica Disponibilità percorso dati ogni 25 secondi in tutte le porte front-end in cui sono state configurate regole di bilanciamento del carico. Questo ping TCP viene instradato verso qualsiasi delle istanze back-end attive (con probing superato). La metrica è una percentuale aggregata del tasso di successo dei ping TCP su ogni combinazione di IP/porta front-end per ciascuna delle regole di bilanciamento del carico, durante un periodo di campionamento.

Stato del probe di integrità

Un ping del protocollo definito nella sonda di salute genera la metrica Stato sonda di salute. Questo ping viene inviato a ciascuna istanza nel pool del back-end e sulla porta definita dal sondaggio di integrità. Per i probe HTTP e HTTPS, un ping con esito positivo richiede una HTTP 200 OK risposta. Con i probe TCP, qualsiasi risposta viene considerata riuscita.

Azure Load Balancer determina l'integrità di ogni istanza back-end quando il probe raggiunge il numero di successi o errori consecutivi configurati per la proprietà soglia probe. Lo stato di integrità di ogni istanza back-end determina se l'istanza back-end è autorizzata o meno a ricevere traffico.

Analogamente alla metrica Disponibilità percorso dati, la metrica Stato probe di integrità aggrega i ping medi riusciti e totali durante l'intervallo di campionamento. Il valore dello stato del sondaggio di integrità indica l'integrità del back-end in modo isolato dal bilanciatore di carico, sondando le istanze back-end senza trasmettere traffico attraverso il front-end.

Importante

Lo stato della sonda di integrità viene campionato ogni minuto. Questo campionamento può portare a piccole fluttuazioni in un valore altrimenti costante.

Si considerino, ad esempio, scenari attivi/passivi dove ci sono due istanze backend, uno attivo e uno non attivo. Il servizio sonda di integrità potrebbe acquisire sette campioni per l'istanza sana e sei per l'istanza non sana. Questa situazione porta a un valore stabile precedentemente pari a 50 che viene visualizzato come 46,15 per un intervallo di un minuto.

Diagnosticare bilanciatori di carico degradati e non disponibili

Come descritto in questo articolo sull'integrità delle risorse, un bilanciatore del carico degradato mostra tra il 25% e il 90% per la disponibilità del percorso dati. Un bilanciatore di carico non disponibile è uno con meno del 25% di disponibilità del percorso dati in un periodo di due minuti.

Puoi eseguire gli stessi passaggi per investigare l'errore visualizzato in uno stato del sondaggio di integrità o in avvisi di disponibilità dei percorsi dati che hai configurato. La procedura seguente illustra le operazioni da eseguire se si controlla l'integrità delle risorse e si trova che il servizio di bilanciamento del carico non sia disponibile con un valore di disponibilità del percorso dati pari a 0%. Il servizio è inattivo.

  1. Nel portale di Azure, passare alla visualizzazione dettagliata delle metriche della pagina relativa al servizio di bilanciamento del carico per ottenere approfondimenti. Accedere alla vista dalla pagina della risorsa del servizio di bilanciamento del carico o dal collegamento nel messaggio sulla salute delle risorse.

  2. Passare alla tab per la disponibilità di frontend e backend ed esaminare una finestra di 30 minuti del periodo in cui si è verificato lo stato degradato o non disponibile. Se il valore di disponibilità del percorso dati è 0%, saprai che qualcosa sta impedendo il traffico per tutte le tue regole di bilanciamento del carico. È anche possibile vedere per quanto tempo questo problema è durato.

  3. Controllare la metrica "Stato della sonda di integrità" per determinare se il percorso dati non è disponibile perché non ci sono istanze backend integre per servire il traffico. Se hai almeno un'istanza back-end attiva per tutte le regole di bilanciamento del carico e regole in ingresso, sai che la configurazione non è quello che causa l'indisponibilità dei percorsi dati. Questo scenario indica un problema di piattaforma Azure. Anche se i problemi della piattaforma sono rari, attivano un avviso automatizzato al team per la risoluzione rapida.

Diagnosticare i guasti della sonda di salute

Se la metrica di stato della sonda di integrità indica che le istanze di back-end non sono funzionanti, è consigliato usare la checklist seguente per escludere gli errori comuni di configurazione:

  • Verifica l'utilizzo della CPU delle tue risorse per determinare se sono soggette a un carico elevato.

    È possibile controllare visualizzando la metrica Percentuale CPU della risorsa tramite la pagina Metriche . Per ulteriori informazioni, vedere Risoluzione dei problemi relativi all'alto utilizzo della CPU per le macchine virtuali Windows di Azure.

  • Se si utilizza una sonda HTTP o HTTPS, verificare se l'applicazione è in salute e responsiva.

    Verificare che l'applicazione sia funzionale accedendo direttamente 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 (NSG) applicati alle risorse back-end. Assicurarsi che nessuna regola abbia una priorità superiore a AllowAzureLoadBalancerInBound, che blocchi il probe di integrità.

    È possibile eseguire questa attività visitando le impostazioni di rete delle macchine virtuali back-end o dei set di scalabilità di macchine virtuali. Se si riscontra che questo problema del gruppo di sicurezza di rete si verifica, spostare la regola Allow esistente o creare una nuova regola ad alta priorità per consentire il traffico del Load Balancer di Azure.

  • Controllare il sistema operativo. Assicurarsi che le macchine virtuali siano in ascolto sulla porta probe. Esaminare anche le regole del firewall del sistema operativo delle macchine virtuali per assicurarsi che non blocchino il traffico 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 sondare una porta in ascolto di un'applicazione non HTTP fallisce.

  • Non posizionare Firewall di Azure nel pool back-end dei servizi di bilanciamento del carico. Per altre informazioni, vedere Integrate Firewall di Azure con Azure Load Balancer Standard.