Share via


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

  1. Ga naar Azure Resource Explorer en identificeer de resource die de status Mislukt heeft.
  2. Werk de wisselknop in de rechterbovenhoek bij naar Lezen/Schrijven.
  3. Selecteer Bewerken voor de resource met de status Mislukt.
  4. 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.