Problemen met Azure Load Balancer van back-Azure Load Balancer oplossen

  • Artikel
  • 5 minuten om te lezen

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

VM's achter Load Balancer krijgen ongelijke verdeling van verkeer terug

Als u vermoedt dat back-endpoolleden verkeer ontvangen, kan dit de volgende oorzaken hebben. Azure Load Balancer distribueert verkeer op basis van verbindingen. Controleer de verkeersdistributie per verbinding en niet per pakket. Controleer het met behulp Flow tabblad Distributie in uw vooraf geconfigureerde Load Balancer Insights dashboard.

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

Oorzaak 1: Er is sessiepersistence geconfigureerd

Het gebruik van de distributiemodus voor bron persistentie kan leiden tot een ongelijke verdeling van het verkeer. Als dit niet gewenst is, moet u de persistentie van de sessie bijwerken op Geen, zodat verkeer wordt verdeeld over alle gezonde exemplaren in de back-endpool. Meer informatie over distributiemodi voor Azure Load Balancer.

Oorzaak 2: Er is een proxy geconfigureerd

Clients die achter -proxies worden uitgevoerd, kunnen vanuit het oogpunt van Load Balancer client worden gezien als één unieke clienttoepassing.

VM's 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:

  • Load Balancer back-endpool-VM luistert niet op de gegevenspoort
  • De netwerkbeveiligingsgroep blokkeert de poort op de Load Balancer back-endpool-VM
  • Toegang tot de Load Balancer vanaf dezelfde VM en NIC
  • Toegang tot de front-Load Balancer van de deelnemende Load Balancer back-Load Balancer pool

Oorzaak 1: Load Balancer back-endpool-VM 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 'LUISTEREN', 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: De netwerkbeveiligingsgroep blokkeert de poort op de virtuele Load Balancer back-Load Balancer-pool

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

Voor de openbare load balancer wordt het IP-adres van de internet-clients gebruikt voor communicatie tussen de clients en de load balancer back-load balancer-VM's. 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 Voor alle netwerkbeveiligingsgroepen weigeren op de NIC van de virtuele machine of het subnet met een hogere prioriteit dan de standaardregel die Load Balancer-tests en verkeer toestaat (netwerkbeveiligingsgroepen moeten Load Balancer IP-adres van 168.63.129.16 toestaan, dat testpoort is)
  3. Als een van de regels het verkeer blokkeert, verwijdert en herconfigureerde u deze regels om het gegevensverkeer toe te staan.
  4. Test of de VM nu op de statustests reageert.

Oorzaak 3: Toegang tot de Load Balancer vanaf dezelfde VM en netwerkinterface

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

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

  • Configureer afzonderlijke back-endpool-VM's per toepassing.
  • Configureer de toepassing in dubbele NIC-VM's, zodat elke toepassing een eigen netwerkinterface en IP-adres gebruikt.

Oorzaak 4: Toegang tot de interne Load Balancer front-Load Balancer van de deelnemende back-Load Balancer-pool

Als een interne Load Balancer is geconfigureerd in een VNet en een van de back-end-VM's van de deelnemer toegang probeert te krijgen tot de interne Load Balancer-front-end, kunnen er fouten optreden wanneer de stroom wordt toe te voegen aan de oorspronkelijke VM. Een dergelijk scenario wordt niet ondersteund.

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

Details Interne load balancers vertalen uitgaande verbindingen niet naar de front-end van een interne Load Balancer omdat beide zich in een privé-IP-adresruimte. Openbare load balancers bieden uitgaande verbindingen van privé-IP-adressen in het virtuele netwerk naar openbare IP-adressen. Voor interne load balancers voorkomt deze methode mogelijke uitputting van SNAT-poort binnen een unieke interne IP-adresruimte, waarbij vertaling niet is vereist.

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 te brengen en wordt teruggemapt aan zichzelf, de twee kanten van de stroom niet overeenkomen. Omdat ze niet overeenkomen, mislukt de stroom. De stroom slaagt als de stroom niet is terugverkend naar dezelfde VM in de back-endpool die de stroom aan de front-end heeft gemaakt.

Wanneer de stroom weer aan zichzelf is gebonden, 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 onderdelen van dezelfde stroom niet overeen in 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 afgestemd op 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 verbindings time-outs wanneer de stroom terugkeert naar dezelfde back-end waaruit de stroom afkomstig is. Veelvoorkomende tijdelijke oplossingen zijn onder andere het invoegen van een proxylaag achter de interne Load Balancer en het gebruik van regels voor Direct Server Return (DSR). Zie Multiple Frontends for Azure Load Balancervoor meer Azure Load Balancer.

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

Volgende stappen

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