Problemen met Azure Load Balancer oplossen
Dit artikel bevat informatie over probleemoplossing voor veelgestelde vragen over Azure Load Balancer (Basic- en Standard-lagen). Zie het overzicht van Standard Load Balancer voor meer informatie over Standard Load Balancer.
Wanneer de connectiviteit van een load balancer niet beschikbaar is, zijn de meest voorkomende symptomen:
- Virtuele machines (VM's) achter de load balancer reageren niet op statustests.
- VM's achter de load balancer reageren niet op het verkeer op de geconfigureerde poort.
Wanneer de externe clients naar de back-end-VM's de load balancer doorlopen, wordt het IP-adres van de clients gebruikt voor de communicatie. Zorg ervoor dat het IP-adres van de clients is toegevoegd aan de acceptatielijst van de netwerkbeveiligingsgroep (NSG).
Probleem: Geen uitgaande connectiviteit van interne Standard-load balancers
Validatie en oplossing
Standaard interne load balancers (ILBs) hebben standaardbeveiligingsfuncties. Standaard-IL's maken verbinding met internet mogelijk via een verborgen openbaar IP-adres dat het standaard-IP-adres voor uitgaande toegang wordt genoemd. Het is niet raadzaam om verbinding te maken via het standaard-IP-adres voor uitgaande toegang voor productieworkloads, omdat het IP-adres niet statisch is of is vergrendeld via netwerkbeveiligingsgroepen waarvan u eigenaar bent.
Als u onlangs bent overgestapt van een Basic ILB naar een Standard ILB en uitgaande connectiviteit met internet vanaf uw VM's nodig hebt, kunt u Azure NAT Gateway in uw subnet configureren. We raden NAT Gateway aan voor alle uitgaande toegang in productiescenario's.
Probleem: Geen binnenkomende connectiviteit met externe Standard load balancers
Oorzaak
Standaard load balancers en standaard openbare IP-adressen worden gesloten voor binnenkomende verbindingen, tenzij netwerkbeveiligingsgroepen ze openen. U gebruikt NSG's om toegestaan verkeer expliciet toe te laten. U moet uw NSG's configureren om toegestaan verkeer expliciet toe te laten. Als u geen NSG op een subnet of netwerkinterfacekaart (NIC) van uw VM-resource hebt, is verkeer niet toegestaan om de resource te bereiken.
Oplossing
Als u inkomend verkeer wilt toestaan, voegt u een netwerkbeveiligingsgroep toe aan het subnet of de interface voor uw virtuele resource.
Probleem: kan de back-endpoort niet wijzigen voor een bestaande taakverdelingsregel van een load balancer waarop een virtuele-machineschaalset is geïmplementeerd in de back-endpool
Oorzaak
Wanneer een load balancer is geconfigureerd met een virtuele-machineschaalset, kunt u de back-endpoort van een taakverdelingsregel niet wijzigen terwijl deze is gekoppeld aan een statustest.
Oplossing
Als u de poort wilt wijzigen, kunt u de statustest verwijderen. Werk de virtuele-machineschaalset bij, werk de poort bij en configureer de statustest opnieuw.
Probleem: Klein verkeer dat nog steeds via de load balancer gaat na het verwijderen van VM's uit de back-endpool
Oorzaak
VM's die zijn verwijderd uit de back-endpool van de load balancer, mogen geen verkeer meer ontvangen. De kleine hoeveelheid netwerkverkeer kan betrekking hebben op opslag, Domain Name System (DNS) en andere functies in Azure.
Oplossing
U kunt een netwerktracering uitvoeren om dit te controleren. De eigenschappen van elk opslagaccount bevatten de FQDN (Fully Qualified Domain Name) voor uw blob-opslagaccount. Vanaf een virtuele machine in uw Azure-abonnement kunt u uitvoeren nslookup
om het Azure-IP-adres te bepalen dat aan dat opslagaccount is toegewezen.
Probleem: Load Balancer met de status Mislukt
Oplossing
- Ga naar Azure Resource Explorer en identificeer de resource die de status Mislukt heeft.
- Werk de wisselknop in de rechterbovenhoek bij naar Lezen/Schrijven.
- Selecteer Bewerken voor de resource met de status Mislukt.
- Selecteer PUT gevolgd door GET om ervoor te zorgen dat de inrichtingsstatus is gewijzigd in Geslaagd.
U kunt vervolgens doorgaan met andere acties, omdat de resource de status Mislukt heeft.
Netwerkopnamen voor ondersteuningstickets
Als het probleem niet wordt opgelost met de voorgaande oplossingen, opent u een ondersteuningsticket.
Als u besluit een ondersteuningsticket te openen, verzamelt u netwerkopnamen voor een snellere oplossing. Kies één back-end-VM om de volgende tests uit te voeren:
- Gebruik
ps ping
van een van de back-end-VM's in het virtuele netwerk om het antwoord van de testpoort (bijvoorbeeld:ps ping 10.0.0.4:3389
) te testen en de resultaten vast te leggen. - Als u geen antwoord ontvangt in pingtests, voert u een gelijktijdige Netsh-trace uit op de back-end-VM en de virtuele netwerktest-VM terwijl u PsPing uitvoert. Stop vervolgens de Netsh-trace.