Risolvere i problemi relativi alle risposte al traffico back-end di Azure Load Balancer
Questa pagina fornisce informazioni sulla risoluzione dei problemi relativi alle domande su Azure Load Balancer.
Le macchine virtuali alla base di un servizio di bilanciamento del carico ricevono una distribuzione non uniforme del traffico
Se si sospetta che i membri del pool back-end ricevano traffico, potrebbe essere dovuto alle cause seguenti. Azure Load Balancer distribuisce il traffico in base alle connessioni. Assicurarsi di controllare la distribuzione del traffico per ogni connessione e non per pacchetto. Assicurarsi di usare la scheda Distribuzione del flusso nel dashboard di Informazioni dettagliate di Load Balancer preconfigurato.
Azure Load Balancer non supporta il bilanciamento del carico round robin reale, ma supporta una modalità di distribuzione basata su hash.
Causa 1: è stata configurata la persistenza della sessione
L'uso della modalità di distribuzione della persistenza di origine può comportare una distribuzione non omogenea del traffico. Se questa distribuzione non è desiderata, impostare la persistenza della sessione in Nessuna in modo che il traffico venga distribuito in tutte le istanze integre nel pool back-end. Altre informazioni sulle modalità di distribuzione per Azure Load Balancer.
Causa 2: è stato configurato un proxy
I client in esecuzione dietro i proxy possono essere visti come un'applicazione client univoca da parte del servizio di bilanciamento del carico.
Le macchine virtuali dietro un servizio di bilanciamento del carico non rispondono al traffico sulla porta dati configurata
Se una macchina virtuale del pool back-end è elencata come integra e risponde ai probe di integrità, ma comunque non partecipa al bilanciamento del carico o non risponde al traffico dati, i motivi potrebbero essere i seguenti:
La macchina virtuale del pool back-end del bilanciamento del carico non è in ascolto sulla porta dati
Un gruppo di sicurezza di rete blocca la porta nella macchina virtuale del pool back-end del bilanciamento del carico
Accesso al bilanciamento del carico dalla stessa macchina virtuale e scheda di interfaccia di rete
Accesso al front-end del bilanciamento del carico Internet dalla macchina virtuale del pool back-end di bilanciamento del carico
Causa 1: la macchina virtuale del pool back-end del bilanciamento del carico non è in ascolto sulla porta dati
Se una macchina virtuale non risponde al traffico dati, è possibile che la porta di destinazione non sia aperta nella macchina virtuale partecipante oppure che la macchina virtuale non sia in ascolto su tale porta.
Convalida e la risoluzione
Accedere alla macchina virtuale back-end.
Aprire un prompt dei comandi ed eseguire questo comando per verificare che un'applicazione sia in ascolto nella porta dati:
netstat -anSe lo stato della porta non è elencato come LISTENING, configurare la porta listener corretta
Se la porta è contrassegnata come LISTENING, verificare se sono presenti problemi nell'applicazione di destinazione su tale porta.
Causa 2: un gruppo di sicurezza di rete blocca la porta nella macchina virtuale del pool back-end di bilanciamento del carico
Se uno o più gruppi di sicurezza di rete configurati nella subnet o nella macchina virtuale bloccano l'indirizzo IP o la porta di origine, la macchina virtuale non potrà rispondere.
Con il bilanciamento del carico pubblico, per la comunicazione tra i client e le macchine virtuali back-end del bilanciamento del carico verrà usato l'indirizzo IP dei client Internet. Assicurarsi che l'indirizzo IP dei client sia consentito nel gruppo di sicurezza di rete della macchina virtuale back-end.
Elencare i gruppi di sicurezza di rete configurati nella macchina virtuale back-end. Per altre informazioni, vedere Gestire i gruppi di sicurezza di rete.
Dall'elenco dei gruppi di sicurezza di rete verificare se:
il traffico in ingresso o in uscita nella porta dati ha interferenze.
Nella scheda di interfaccia di rete della macchina virtuale o nella subnet è presente una regola di tipo Nega tutto di un gruppo di sicurezza di rete avente una priorità superiore rispetto alla regola predefinita che consente il traffico e i probe di bilanciamento del carico. I gruppi di sicurezza di rete devono consentire l'IP 168.63.129.16 di bilanciamento del carico, ovvero la porta probe
Se alcune di queste regole bloccano il traffico, rimuoverle e riconfigurarle per consentire il traffico dati.
Verificare se la macchina virtuale ha ora iniziato a rispondere ai probe di integrità.
Causa 3: accesso al bilanciamento del carico interno dalla stessa macchina virtuale e interfaccia di rete
Se l'applicazione ospitata nella macchina virtuale back-end di un bilanciamento del carico sta provando ad accedere a un'altra applicazione ospitata nella stessa macchina virtuale back-end tramite la stessa interfaccia di rete, questo scenario non è supportato e avrà esito negativo.
Risoluzione
È possibile risolvere questo problema con uno dei metodi seguenti:
Configurare macchine virtuali del pool back-end separate per ogni applicazione.
Configurare l'applicazione in macchine virtuali con due schede di interfaccia di rete in modo che ogni applicazione usi un'interfaccia di rete e un indirizzo IP propri.
Causa 4: accesso al front-end del bilanciamento del carico interno dalla macchina virtuale del pool back-end di bilanciamento del carico partecipante
Se è configurato di bilanciamento del carico interno in una rete virtuale e una delle macchine virtuali del back-end sta tentando di accedere al front-end del bilanciamento del carico interno, potrebbero verificarsi errori durante il mapping del flusso alla macchina virtuale di origine. Questo scenario non è supportato.
Risoluzione
È possibile sbloccare questo scenario in diversi modi, incluso l'uso di un proxy. Valutare un gateway applicazione o altri proxy di terze parti, ad esempio nginx o haproxy. Per altre informazioni sul gateway applicazione, vedere Panoramica del gateway applicazione
Dettagli
I servizi di bilanciamento del carico interni non convertono le connessioni originate in uscita nel front-end di un servizio di bilanciamento del carico interno perché entrambi risiedono in uno spazio indirizzi IP privati. I servizi di bilanciamento del carico pubblici consentono di stabilire connessioni in uscita dagli indirizzi IP privati interni alla rete virtuale a indirizzi IP pubblici. Per i servizi di bilanciamento del carico interni, questo approccio evita un potenziale esaurimento delle porte SNAT all'interno di uno spazio indirizzi IP interni univoco, in cui la conversione non è obbligatoria.
Un effetto collaterale consiste nella mancata corrispondenza dei due rami del flusso qualora un flusso in uscita da una macchina virtuale nel pool back-end tenti un flusso verso il front-end del bilanciamento del carico interno nel pool e venga mappato a se stesso. A causa della mancata corrispondenza, il flusso ha esito negativo. Il flusso ha esito positivo se non viene mappato alla stessa macchina virtuale nel pool back-end che ha creato il flusso verso il front-end.
Quando il flusso viene mappato nuovamente a se stesso, il flusso in uscita sembra provenire dalla macchina virtuale verso il front-end e il flusso in ingresso corrispondente sembra provenire dalla macchina virtuale verso se stesso. Dal punto di vista del sistema operativo guest, le parti in ingresso e in uscita dello stesso flusso non corrispondono all'interno della macchina virtuale. Lo stack TCP non riconosce queste metà come appartenenti allo stesso flusso, sebbene lo siano. L'origine e la destinazione non corrispondono. Quando il flusso viene mappato a qualsiasi altra macchina virtuale nel pool back-end, le metà del flusso corrispondono e la macchina virtuale può rispondere al flusso stesso.
Il sintomo di questo scenario è il verificarsi di timeout di connessione intermittenti quando il flusso torna nello stesso back-end che lo ha originato. Soluzioni alternative comuni includono l'inserimento di un livello proxy dietro il servizio di bilanciamento del carico interno e l'uso delle regole di stile DSR (Direct Server Return). Per altre informazioni, vedere Più front-end per Azure Load Balancer.
È possibile combinare un bilanciamento del carico interno con qualsiasi proxy di terze parti o usare un gateway applicazione per scenari proxy con HTTP/HTTPS. Sebbene sia possibile usare un servizio di bilanciamento del carico pubblico per attenuare questo problema, lo scenario risultante può determinare l'esaurimento delle porte SNAT. Evitare questo secondo approccio, a meno che non sia gestito accuratamente.
Passaggi successivi
Se il problema non viene risolto tramite i passaggi precedenti, aprire un ticket di supporto.