Risolvere i problemi di integrità delle risorse e disponibilità in ingresso
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 l'integrità del servizio di bilanciamento del carico. Analizza la metrica Disponibilità percorso dati per determinare se sono disponibili gli endpoint di bilanciamento del carico, l'IP front-end e le combinazioni di porte front-end con regole di bilanciamento del carico.
Nota
Load Balancer Basic non supporta la funzionalità di integrità delle risorse.
La tabella seguente descrive la logica per determinare lo stato di integrità del servizio di bilanciamento del carico.
Stato di integrità delle risorse | Descrizione |
---|---|
Disponibile | La risorsa del servizio di bilanciamento del carico è integra e disponibile. |
Degraded | Il servizio di bilanciamento del carico ha eventi avviati dalla piattaforma o dall'utente che influiscono sulle prestazioni. La metrica Di disponibilità del percorso dati ha segnalato meno del 90% ma maggiore del 25% di integrità per almeno due minuti. Potrebbe verificarsi una riduzione delle prestazioni moderata o grave. |
Unavailable | La risorsa del servizio di bilanciamento del carico non è integra. La metrica Disponibilità percorso dati ha segnalato meno del 25% di 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à delle risorse per la risorsa del servizio di bilanciamento del carico non ha aggiornato o ricevuto le 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 da Azure Load Balancer per controllare l'integrità delle risorse sono Disponibilità percorso dati e Stato probe di integrità. È 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 a una qualsiasi delle istanze back-end integre (su cui è stato eseguito il probe). La metrica è una percentuale aggregata di ping TCP in ogni combinazione di porta/IP front-end per ognuna delle regole di bilanciamento del carico, in un periodo di tempo di campionamento.
Stato del probe di integrità
Un ping del protocollo definito nel probe di integrità genera la metrica Stato 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 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 Stato probe di integrità indica l'integrità back-end in isolamento dal servizio di bilanciamento del carico eseguendo il probe delle istanze back-end senza inviare traffico attraverso il front-end.
Importante
Lo stato del probe di integrità viene campionato su base di un minuto. Questo campionamento può portare a piccole fluttuazioni in un valore altrimenti costante.
Si considerino, ad esempio, scenari attivi/passivi in cui sono presenti due istanze back-end, un probe verso l'alto e un probe inattivo. Il servizio probe di integrità potrebbe acquisire sette campioni per l'istanza integra e sei per l'istanza non integra. Questa situazione porta a un valore stabile precedentemente pari a 50 che viene visualizzato come 46,15 per un intervallo di un minuto.
Diagnosticare servizi di bilanciamento del carico degradati e non disponibili
Come descritto in questo articolo sull'integrità delle risorse, un servizio di bilanciamento del carico danneggiato mostra tra il 25% e il 90% per la disponibilità del percorso dati. Un servizio di bilanciamento del carico non disponibile è uno con meno del 25% per la disponibilità del percorso dati in un periodo di due minuti.
È possibile eseguire gli stessi passaggi per analizzare l'errore visualizzato in qualsiasi stato del probe di integrità o avvisi di disponibilità del percorso dati configurati. I passaggi seguenti illustrano 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.
Nella portale di Azure passare alla visualizzazione dettagliata delle metriche della pagina per informazioni dettagliate sul servizio di bilanciamento del carico. Accedere alla visualizzazione dalla pagina per la risorsa del servizio di bilanciamento del carico o dal collegamento nel messaggio di integrità delle risorse.
Passare alla scheda per la disponibilità front-end e back-end ed esaminare una finestra di 30 minuti del periodo di tempo in cui si è verificato lo stato danneggiato o non disponibile. Se il valore di disponibilità percorso dati è 0%, si sa che qualcosa impedisce il traffico per tutte le regole di bilanciamento del carico. È anche possibile vedere per quanto tempo questo problema è durato.
Controllare la metrica Stato probe di integrità per determinare se il percorso dati non è disponibile perché non sono presenti istanze back-end integre per gestire il traffico. Se si dispone di almeno un'istanza back-end integra per tutte le regole di bilanciamento del carico e in ingresso, si sa che la configurazione non è ciò che causa l'indisponibilità dei percorsi dati. Questo scenario indica un problema della piattaforma Azure. Anche se i problemi della piattaforma sono rari, attivano un avviso automatizzato al team per la risoluzione rapida.
Diagnosticare errori relativi al probe di integrità
Se la metrica Stato probe di integrità indica che le istanze back-end non sono integre, è consigliabile usare l'elenco di controllo seguente per escludere gli errori di configurazione comuni:
Controllare l'utilizzo della CPU per le risorse per determinare se sono sotto carico elevato.
È possibile controllare visualizzando la metrica Percentuale CPU della risorsa tramite la pagina Metriche . Per altre informazioni, vedere Risolvere i problemi di utilizzo elevato della CPU per le macchine virtuali Windows di Azure.
Se si usa un probe HTTP o HTTPS, verificare se l'applicazione è integra e reattiva.
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
quella del blocco del 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 rileva che questo problema del gruppo di sicurezza di rete è il caso, spostare la regola esistente
Allow
o creare una nuova regola ad alta priorità per consentire il traffico di Azure Load Balancer.Controllare il sistema operativo. Assicurarsi che le macchine virtuali siano in ascolto sulla porta probe. Esaminare anche le regole del firewall del sistema operativo per le macchine virtuali per assicurarsi che non blocchino il traffico probe proveniente dall'indirizzo
168.63.129.16
IP .È possibile controllare le porte di ascolto eseguendo
netstat -a
da un prompt dei comandi di Windows onetstat -l
da un terminale Linux.Assicurarsi di usare il protocollo corretto. Ad esempio, un probe che usa HTTP per eseguire il probe di una porta in ascolto di un'applicazione non HTTP ha esito negativo.
Non posizionare Firewall di Azure nel pool back-end dei servizi di bilanciamento del carico. Per altre informazioni, vedere Integrare Firewall di Azure con Azure Load Balancer Standard.