Problemen met Azure Load Balancer status van de statustest oplossen
Deze pagina bevat veelvoorkomende informatie over probleemoplossing Azure Load Balancer vragen over statustests.
Symptoom: VM's achter Load Balancer reageren niet op statustests
De back-load balancer servers kunnen alleen deelnemen aan de test. Zie Understanding Load Balancer Probes (Meer informatie over Load Balancer tests) voor meer informatie over statustests.
De Load Balancer back-endpool-VM's reageren mogelijk niet op de tests vanwege een van de volgende redenen:
- Load Balancer back-endpool-VM is beschadigd
- Load Balancer back-endpool-VM luistert niet op de testpoort
- Firewall of een netwerkbeveiligingsgroep blokkeert de poort op de virtuele Load Balancer back-Load Balancer-pool
- Andere onjuiste configuraties in Load Balancer
Oorzaak 1: Load Balancer back-endpool-VM is beschadigd
Validatie en oplossing
U kunt dit probleem oplossen door u aan te melden bij de deelnemende VM's, te controleren of de status van de VM in orde is en te reageren op PsPing of TCPing vanaf een andere VM in de pool. Als de VM een slechte status heeft of niet kan reageren op de test, moet u het probleem oplossen en de VM weer in orde krijgen voordat deze kan deelnemen aan taakverdeling.
Oorzaak 2: Load Balancer back-endpool-VM luistert niet op de testpoort
Als de VM in orde is, maar niet reageert op de test, kan een mogelijke reden zijn dat de testpoort niet is geopend op de deelnemende VM of dat de VM niet luistert op die poort.
Validatie en oplossing
- Meld u aan bij de back-end-VM.
- Open een opdrachtprompt en voer de volgende opdracht uit om te controleren of er een toepassing luistert op de testpoort: netstat -an
- Als de poorttoestand niet wordt vermeld als LUISTEREN, configureert u de juiste poort.
- U kunt ook een andere poort selecteren die wordt vermeld als LUISTEREN en de configuratie load balancer bijwerken.
Oorzaak 3: Firewall of een netwerkbeveiligingsgroep blokkeert de poort op de virtuele load balancer back-load balancer-pool
Als de testpoort wordt geblokkeerd door de firewall op de VM of als een of meer netwerkbeveiligingsgroepen die zijn geconfigureerd op het subnet of op de virtuele machine, de test niet toestaat om de poort te bereiken, kan de virtuele machine niet reageren op de statustest.
Validatie en oplossing
- Als de firewall is ingeschakeld, controleert u of deze is geconfigureerd om de testpoort toe te staan. Zo niet, configureer dan de firewall om verkeer op de testpoort toe te staan en test opnieuw.
- Controleer of uw VM-firewall testverkeer dat afkomstig is van het IP-adres niet blokkeert
168.63.129.16 - U kunt luisterende poorten controleren door uit te voeren vanaf Windows
netstat -aopdrachtprompt ofnetstat -lvanuit een Linux-terminal - U kunt een query uitvoeren op uw firewallprofielen om te controleren of uw beleid binnenkomend verkeer blokkeert door uit te voeren vanaf een Windows-opdrachtprompt of vanuit een Linux-terminal om alle geconfigureerde
netsh advfirewall show allprofiles | moresudo iptables -Lfirewallregels weer te geven. - Zie Azure VM Guest OS firewall is blocking inbound traffic (Firewall van gast-besturingssysteem van Azure-VM blokkeert het inkomende verkeer) voor meer informatie over het oplossen van firewallproblemen voor Azure-VM's.
- Controleer in de lijst met netwerkbeveiligingsgroepen of het binnenkomende of uitgaande verkeer op de testpoort interferentie heeft.
- Controleer ook of een regel Alle netwerkbeveiligingsgroepen weigeren op de NIC van de virtuele machine of het subnet met een hogere prioriteit heeft dan de standaardregel die LB-tests &-verkeer toestaat (netwerkbeveiligingsgroepen moeten Load Balancer IP-adres van 168.63.129.16 toestaan).
- Als een van deze regels het testverkeer blokkeert, verwijdert en herconfigureerde u de regels om het testverkeer toe te staan.
- Test of de VM nu op de statustests reageert.
Oorzaak 4: Andere onjuiste configuraties in Load Balancer
Als alle voorgaande oorzaken correct lijken te worden gevalideerd en opgelost, en de back-end-VM nog steeds niet reageert op de statustest, test u handmatig op connectiviteit en verzamelt u enkele traceringen om inzicht te krijgen in de connectiviteit.
Validatie en oplossing
- Gebruik Psping vanaf een van de andere VM's in het VNet om het antwoord van de testpoort te testen (voorbeeld: .\psping.exe -t 10.0.0.4:3389) en recordresultaten.
- Gebruik TCPing vanaf een van de andere VM's in het VNet om het antwoord van de testpoort te testen (bijvoorbeeld: .\tcping.exe 10.0.0.4 3389) en recordresultaten.
- Als er geen antwoord wordt ontvangen in deze pingtests,
- Voer een gelijktijdige Netsh-trace uit op de doel-back-endpool-VM en een andere test-VM van hetzelfde VNet. Voer nu enige tijd een PsPing-test uit, verzamel enkele netwerk traceringen en stop de test.
- Analyseer de netwerkopname en kijk of er zowel binnenkomende als uitgaande pakketten zijn die betrekking hebben op de pingquery.
- Als er geen binnenkomende pakketten worden waargenomen op de back-endpool-VM, wordt het verkeer mogelijk geblokkeerd door een netwerkbeveiligingsgroep of onjuiste UDR-configuratie.
- Als er geen uitgaande pakketten worden waargenomen op de back-endpool-VM, moet de VM worden gecontroleerd op niet-gerelateerde problemen (bijvoorbeeld Toepassing blokkeert de testpoort).
- Controleer of de testpakketten worden geforceerd naar een andere bestemming (mogelijk via UDR-instellingen) voordat de load balancer. Dit kan ertoe leiden dat het verkeer nooit de back-end-VM bereikt.
- Wijzig het testtype (bijvoorbeeld HTTP in TCP) en configureer de bijbehorende poort in de ACL's van netwerkbeveiligingsgroepen en de firewall om te controleren of het probleem te maken heeft met de configuratie van de testreactie. Zie Endpoint Load Balancing health probe configuration (Statustestconfiguratie voor eindpuntbelastingsverdeling) voor meer informatie over de configuratie van de statustest.
Volgende stappen
Als het probleem niet wordt opgelost met de voorgaande stappen, opent u een ondersteuningsticket.