Delen via

Problemen met de teststatus van Azure Load Balancer oplossen

  • Artikel

Op deze pagina vindt u informatie over het oplossen van problemen met veelvoorkomende vragen over statustests van Azure Load Balancer.

Symptoom: VM's achter de Load Balancer reageren niet op statustests

Als de back-endservers kunnen deelnemen aan de load balancer-set, moeten ze de testcontrole doorgeven. Zie Load Balancer-tests voor meer informatie over statustests. 

De vm's van de back-endpool van Load Balancer reageren mogelijk niet op de tests vanwege een van de volgende redenen:

  • Vm met back-endpool van Load Balancer is beschadigd
  • Vm van load balancer-back-endpool luistert niet op de testpoort
  • Firewall of een netwerkbeveiligingsgroep blokkeert de poort op de vm's van de back-endpool van load balancer
  • Andere onjuiste configuraties in Load Balancer

Oorzaak 1: Vm met back-endpool load balancer is beschadigd

Validatie en oplossing

U kunt dit probleem oplossen door u aan te melden bij de deelnemende VM's en te controleren of de vm-status in orde is en kan reageren op PsPing of TCPing vanaf een andere VIRTUELE machine in de pool. Als de VM niet in orde is of niet kan reageren op de test, moet u het probleem oplossen en de VIRTUELE machine weer in orde krijgen voordat deze kan deelnemen aan taakverdeling.

Oorzaak 2: De back-endpool-VM van load balancer 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

  1. Meld u aan bij de back-end-VM.
  2. Open een opdrachtprompt en voer de volgende opdracht uit om te controleren of er een toepassing luistert op de testpoort: netstat -an
  3. Als de poortstatus niet wordt vermeld als LUISTEREN, configureert u de juiste poort.
  4. U kunt ook een andere poort selecteren die wordt vermeld als LUISTEREN en de configuratie van de Load Balancer dienovereenkomstig bijwerken.

Oorzaak 3: Firewall of een netwerkbeveiligingsgroep blokkeert de poort op de vm's van de back-endpool van de load balancer

Als de firewall op de VM de testpoort blokkeert of een of meer netwerkbeveiligingsgroepen die zijn geconfigureerd op het subnet of op de VIRTUELE machine, de test niet de poort kan bereiken, kan de VM niet reageren op de statustest.

Validatie en oplossing

  1. Als de firewall is ingeschakeld, controleert u of deze is geconfigureerd om de testpoort toe te staan. Zo niet, configureert u de firewall om verkeer op de testpoort toe te staan en test u opnieuw.
  • Controleer of uw VM-firewall geen testverkeer blokkeert dat afkomstig is van ip-adres 168.63.129.16
  • U kunt luisterende poorten controleren door uit te voeren netstat -a vanaf een Windows-opdrachtprompt of netstat -l vanuit een Linux-terminal
  • U kunt query's uitvoeren op uw firewallprofielen om te controleren of uw beleid binnenkomend verkeer blokkeert door uit te voeren netsh advfirewall show allprofiles | more vanaf een Windows-opdrachtprompt of sudo iptables -L vanuit een Linux-terminal om alle geconfigureerde firewallregels te bekijken.
  • Meer informatie over het oplossen van firewallproblemen voor Azure-VM's, raadpleegt u de firewall van het gastbesturingssystemen van Azure VM's die binnenkomend verkeer blokkeren.
  1. Controleer in de lijst met netwerkbeveiligingsgroepen of het binnenkomende of uitgaande verkeer op de testpoort interferentie heeft.
  2. Controleer ook of de regel Alle netwerkbeveiligingsgroepen weigeren op de NIC van de VIRTUELE machine of het subnet met een hogere prioriteit heeft dan de standaardregel waarmee LB-tests en -verkeer zijn toegestaan (netwerkbeveiligingsgroepen moeten load balancer-IP van 168.63.129.16 toestaan).
  3. Als een van deze regels het testverkeer blokkeert, verwijdert en configureert u de regels om het testverkeer toe te staan. 
  4. Test of de VIRTUELE machine nu reageert op de statustests.

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 de connectiviteit te begrijpen.

Validatie en oplossing

  1. Gebruik Psping van een van de andere VM's in het VNet om het antwoord van de testpoort te testen (bijvoorbeeld: .\psping.exe -t 10.0.0.4:3389) en recordresultaten.
  2. Gebruik TCPing van 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.
  3. Als er geen antwoord wordt ontvangen in deze pingtests, dan
    • Voer een gelijktijdige Netsh-trace uit op de doelback-endpool-VM en een andere test-VM van hetzelfde VNet. Voer nu een PsPing-test uit, verzamel enkele netwerktraceringen en stop vervolgens de test.
    • Analyseer de netwerkopname en kijk of er zowel binnenkomende als uitgaande pakketten zijn gerelateerd aan de pingquery.
      • Als er geen binnenkomende pakketten worden waargenomen op de VM van de back-endpool, is er mogelijk een netwerkbeveiligingsgroep of UDR-onjuiste configuratie die het verkeer blokkeert.
      • Als er geen uitgaande pakketten worden waargenomen op de back-endpool-VM, moet de VM worden gecontroleerd op niet-gerelateerde problemen (bijvoorbeeld toepassing die de testpoort blokkeert).
    • Controleer of de testpakketten worden gedwongen naar een andere bestemming (mogelijk via UDR-instellingen) voordat u de load balancer bereikt. Dit kan ertoe leiden dat het verkeer nooit de back-end-VM bereikt.
  4. Wijzig het testtype (bijvoorbeeld HTTP naar TCP) en configureer de bijbehorende poort in netwerkbeveiligingsgroepen-ACL's en firewall om te controleren of het probleem bij de configuratie van het testantwoord hoort. Zie de configuratie van de statustest voor eindpunttaakverdeling 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.