Problemen met back-endverkeer van Azure Load Balancer oplossen
Op deze pagina vindt u informatie over probleemoplossing voor vragen over Azure Load Balancer.
Virtuele machines achter een load balancer ontvangen ongelijke verdeling van verkeer
Als u vermoedt dat leden van de back-endpool verkeer ontvangen, kan dit worden veroorzaakt door de volgende oorzaken. Azure Load Balancer distribueert verkeer op basis van verbindingen. Controleer de verkeersdistributie per verbinding en niet per pakket. Controleer of u het tabblad Stroomdistributie gebruikt in het vooraf geconfigureerde dashboard van Load Balancer Insights.
Azure Load Balancer biedt geen ondersteuning voor echte round robin-taakverdeling, maar ondersteunt een distributiemodus op basis van hash.
Oorzaak 1: Er is sessiepersistentie geconfigureerd
Het gebruik van de distributiemodus voor bronpersistentie kan een ongelijke distributie van verkeer veroorzaken. Als deze distributie niet gewenst is, werkt u sessiepersistentie bij zodat geen 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 worden gezien als één unieke clienttoepassing vanuit het oogpunt van de load balancer.
VM's achter een load balancer reageren niet op verkeer op de geconfigureerde gegevenspoort
Als een back-endpool-VM als in orde wordt vermeld 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 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 virtuele machine 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
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 gegevenspoort:
netstat -anAls de poort niet wordt vermeld met de status LUISTEREN, configureert u de juiste listenerpoort
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 van de back-endpool van de load balancer
Als een of meer netwerkbeveiligingsgroepen die zijn geconfigureerd op het subnet of op de VM, het bron-IP-adres of de bronpoort blokkeert, kan de VIRTUELE machine 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.
Vermeld de netwerkbeveiligingsgroepen die zijn geconfigureerd op de back-end-VM. Zie Netwerkbeveiligingsgroepen beheren voor meer informatie
Controleer in de lijst met netwerkbeveiligingsgroepen of:
Het binnenkomende of uitgaande verkeer op de gegevenspoort heeft interferentie.
A Deny All network security group rule on the NIC of the subnet that has a higher priority that the default rule that allow the load balancer probes and traffic (network security groups must allow load balancer IP of 168.63.129.16, that is probe port)
Als een van de regels het verkeer blokkeert, verwijdert en configureert u deze regels om het gegevensverkeer toe te staan.
Test of de VIRTUELE machine nu is begonnen met reageren op de statustests.
Oorzaak 3: Toegang van 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 toegang probeert te krijgen tot een andere toepassing die wordt gehost in dezelfde back-end-VM via dezelfde netwerkinterface, is dit een niet-ondersteund scenario en mislukt deze.
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 dubbele NIC-VM's, zodat elke toepassing een eigen netwerkinterface en ip-adres gebruikte.
Oorzaak 4: Toegang tot de interne load balancer-front-end van de deelnemende back-endpool-VM 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 is 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 uitgaande verbindingen met de front-end van een interne load balancer niet omdat beide zich in de 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, waarbij vertaling niet is vereist.
Een neveneffect is dat als een uitgaande stroom van een VIRTUELE machine in de back-endpool een stroom naar de front-end van de interne load balancer in de pool probeert en weer aan zichzelf is toegewezen, komen de twee benen van de stroom niet overeen. Omdat ze niet overeenkomen, mislukt de stroom. De stroom slaagt als de stroom niet is toegewezen aan dezelfde VIRTUELE machine in de back-endpool die de stroom heeft gemaakt naar de front-end.
Wanneer de stroom weer aan zichzelf is toegewezen, lijkt de uitgaande stroom afkomstig te zijn van de VIRTUELE machine 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 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 VIRTUELE machine in de back-endpool, komen de helften van de stroom overeen en kan de VIRTUELE machine 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 wordt opgelost met de voorgaande stappen, opent u een ondersteuningsticket.