Problemen met antwoorden op Azure Load Balancer back-endverkeer oplossen

Deze pagina bevat informatie over probleemoplossing voor Azure Load Balancer vragen.

Virtuele machines achter een load balancer ontvangen ongelijke verdeling van verkeer

Als u vermoedt dat leden van de back-endpool verkeer ontvangen, kan dit de volgende oorzaken hebben. Azure Load Balancer verdeelt verkeer op basis van verbindingen. Controleer de distributie van verkeer per verbinding en niet per pakket. Controleer dit met behulp van het tabblad Stroomdistributie in uw vooraf geconfigureerde Load Balancer Insights-dashboard.

Azure Load Balancer biedt geen ondersteuning voor echte round robin-taakverdeling, maar ondersteunt een distributiemodus op basis van hash.

Oorzaak 1: U hebt sessiepersistentie geconfigureerd

Het gebruik van de distributiemodus voor bronpersistentie kan leiden tot een ongelijke verdeling van het verkeer. Als deze distributie niet gewenst is, werkt u sessiepersistentie bij naar Geen , zodat het verkeer wordt verdeeld over alle gezonde exemplaren in de back-endpool. Meer informatie over distributiemodi voor Azure Load Balancer.

Oorzaak 2: U hebt een proxy geconfigureerd

Clients die achter proxy's worden uitgevoerd, kunnen vanuit het oogpunt van de load balancer worden gezien als één unieke clienttoepassing.

VM's achter een load balancer reageren niet op verkeer op de geconfigureerde gegevenspoort

Als een back-endpool-VM wordt vermeld als in orde en reageert op de statustests, maar nog steeds niet deelneemt aan de taakverdeling of niet reageert op het gegevensverkeer, kan dit een van de volgende oorzaken hebben:

  • Een back-endpool-VM van een load balancer luistert niet op de gegevenspoort

  • Netwerkbeveiligingsgroep blokkeert de poort op de back-endpool-VM van de load balancer

  • Toegang tot de load balancer vanaf dezelfde VM en NIC

  • Toegang tot de front-end van de internet load balancer vanuit de vm van de deelnemende back-endpool van de load balancer

Oorzaak 1: een back-endpool-VM van een load balancer luistert niet op de gegevenspoort

Als een VM niet reageert op het gegevensverkeer, kan dit zijn omdat de doelpoort niet is geopend op de deelnemende VM of omdat 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 gegevenspoort:

    netstat -an 
    
  3. Als de poort niet wordt vermeld met de status LISTENING, configureert u de juiste listenerpoort

  4. Als de poort is gemarkeerd als LUISTEREN, controleert u de doeltoepassing op die poort op mogelijke problemen.

Oorzaak 2: Een netwerkbeveiligingsgroep blokkeert de poort op de vm met de back-endpool van de load balancer

Als een of meer netwerkbeveiligingsgroepen die zijn geconfigureerd in het subnet of op de VM, het bron-IP-adres of de bronpoort blokkeren, kan de VM niet reageren.

Voor de openbare load balancer wordt het IP-adres van de internetclients gebruikt voor communicatie tussen de clients en de back-end-VM's van de load balancer. Zorg ervoor dat het IP-adres van de clients is toegestaan in de netwerkbeveiligingsgroep van de back-end-VM.

  1. Vermeld de netwerkbeveiligingsgroepen die zijn geconfigureerd op de back-end-VM. Zie Netwerkbeveiligingsgroepen beheren voor meer informatie

  2. Controleer in de lijst met netwerkbeveiligingsgroepen of:

    • Het binnenkomende of uitgaande verkeer op de gegevenspoort heeft interferentie.

    • Een regel Alle netwerkbeveiligingsgroepen weigeren op de NIC van de VIRTUELE machine of het subnet met een hogere prioriteit dan de standaardregel die tests en verkeer van de load balancer toestaat (netwerkbeveiligingsgroepen moeten het IP-adres van de load balancer van 168.63.129.16 toestaan, dit is testpoort)

  3. Als een van de regels het verkeer blokkeert, verwijdert en configureert u deze regels om het gegevensverkeer toe te staan. 

  4. Test of de VM nu is begonnen met reageren op de statustests.

Oorzaak 3: Toegang tot de interne load balancer vanaf dezelfde VM en netwerkinterface

Als uw toepassing die wordt gehost op de back-end-VM van een interne load balancer via dezelfde netwerkinterface toegang probeert te krijgen tot een andere toepassing die wordt gehost op dezelfde back-end-VM, is dit een niet-ondersteund scenario en mislukt dit.

Oplossing

U kunt dit probleem oplossen via een van de volgende methoden:

  • Configureer afzonderlijke VM's voor back-endpools per toepassing.

  • Configureer de toepassing in twee NIC-VM's, zodat elke toepassing een eigen netwerkinterface en IP-adres gebruikt.

Oorzaak 4: Toegang tot de front-end van de interne load balancer vanuit de vm van de deelnemende back-endpool van de load balancer

Als een interne load balancer is geconfigureerd in een virtueel netwerk en een van de back-end-VM's van de deelnemer toegang probeert te krijgen tot de front-end van de interne load balancer, kunnen er fouten optreden wanneer de stroom wordt toegewezen aan de oorspronkelijke VM. Dit scenario wordt niet ondersteund.

Oplossing

Er zijn verschillende manieren om dit scenario te deblokkeren, waaronder het gebruik van een proxy. Evalueer Application Gateway of andere proxy's van derden (bijvoorbeeld nginx of haproxy). Zie Overzicht van Application Gateway voor meer informatie over Application Gateway

Details

Interne load balancers vertalen geen uitgaande verbindingen naar de front-end van een interne load balancer, omdat beide zich in een privé-IP-adresruimte bevinden. Openbare load balancers bieden uitgaande verbindingen van privé-IP-adressen in het virtuele netwerk naar openbare IP-adressen. Voor interne load balancers voorkomt deze aanpak mogelijke SNAT-poortuitputting binnen een unieke interne IP-adresruimte, waar vertaling niet vereist is.

Een neveneffect is dat als een uitgaande stroom van een VM in de back-endpool een stroom naar de front-end van de interne load balancer in de pool probeert en weer aan zichzelf wordt toegewezen, de twee benen van de stroom niet overeenkomen. Omdat ze niet overeenkomen, mislukt de stroom. De stroom slaagt als de stroom niet is toegewezen aan dezelfde VM in de back-endpool waarmee de stroom naar de front-end is gemaakt.

Wanneer de stroom weer aan zichzelf wordt toegewezen, lijkt de uitgaande stroom afkomstig te zijn van de VM naar de front-end en lijkt de bijbehorende binnenkomende stroom afkomstig te zijn van de VM naar zichzelf. Vanuit het oogpunt van het gastbesturingssysteem komen de binnenkomende en uitgaande delen van dezelfde stroom niet overeen binnen de virtuele machine. De TCP-stack herkent deze helften van dezelfde stroom niet als onderdeel van dezelfde stroom. De bron en het doel komen niet overeen. Wanneer de stroom wordt toegewezen aan een andere VM in de back-endpool, komen de helften van de stroom overeen en kan de VM reageren op de stroom.

Het symptoom voor dit scenario is onregelmatige verbindingstime-outs wanneer de stroom terugkeert naar dezelfde back-end die de stroom heeft veroorzaakt. Veelvoorkomende tijdelijke oplossingen zijn het invoegen van een proxylaag achter de interne load balancer en het gebruik van DSR-stijlregels (Direct Server Return). Zie Meerdere front-ends voor Azure Load Balancer voor meer informatie.

U kunt een interne load balancer combineren met een proxy van derden of interne Application Gateway gebruiken voor proxyscenario's met HTTP/HTTPS. Hoewel u een openbare load balancer kunt gebruiken om dit probleem te verhelpen, is het resulterende scenario gevoelig voor SNAT-uitputting. Vermijd deze tweede benadering, tenzij deze zorgvuldig wordt beheerd.

Volgende stappen

Als het probleem niet is opgelost met de voorgaande stappen, opent u een ondersteuningsticket.