Problemen met taakverdeling oplossen
Azure biedt een reeks oplossingen voor taakverdeling. Traffic Manager biedt hoge beschikbaarheid en snelle reactietijden met behulp van DNS om clientaanvragen om te leiden naar het meest geschikte eindpunt voor elk protocol. Front Door biedt hoge beschikbaarheid en snelle reactietijden met behulp van proxy's voor HTTP-aanvragen. Traffic Manager en Front Door load balancen in de netwerk- en transportlagen.
Application Gateway laadt taken op de toepassingslaag in plaats van de netwerk- en transportlagen. Dit betekent dat u verkeer kunt routeren op basis van de binnenkomende URL. U kunt bijvoorbeeld verkeer routeren voor een URL die /media bevat naar een specifieke set servers.
Load Balancer werkt op de netwerk- en transportlagen om interne en externe taakverdeling te bieden voor zowel inkomend als uitgaand verkeer met behulp van elk protocol.
Voor elke taakverdelingsoplossing zijn verschillende stappen voor probleemoplossing vereist.
De status van Azure Traffic Manager bepalen
Als u wilt testen of uw Traffic Manager-instellingen juist zijn, moet u meerdere clients op meerdere locaties hebben. U kunt vervolgens de DNS-omzetting voor failover controleren met behulp van de volgende stappen:
Maak uw DNS-cache leeg door ipconfig /flushdns uit te voeren.
Voer nslookup uit voor het domein van uw bedrijf om te controleren of deze wordt omgezet in uw primaire eindpunt.
Haal uw primaire eindpunt op, wacht op de TTL-tijd (Time-to-Live) van uw Traffic Manager-profiel, plus nog eens twee minuten.
Maak uw DNS-cache leeg door ipconfig /flushdns uit te voeren.
Herhaal de nslookup-aanvraag en controleer of deze wordt omgezet naar uw secundaire eindpunt.
Herhaal deze stappen voor elk eindpunt.
U kunt ook testen op gewogen verkeersroutering door alle eindpunten te verlaten en herhaaldelijk de cache leeg te maken en nslookup uit te voeren om te controleren of verkeer door elk eindpunt loopt.
U kunt testen op prestatieroutering door verbinding te maken vanaf verschillende geografische locaties en te testen of het juiste eindpunt wordt geretourneerd door nslookup.
Bepalen of virtuele machines in een cluster met gelijke taakverdeling in orde zijn
Azure Load Balancer maakt gebruik van statustests om te detecteren of een exemplaar in orde is. Als de statustest geen verbinding kan maken, stopt de load balancer met het verzenden van verbindingen naar dat exemplaar.
Wat gebeurt er als virtuele machines (VM's) in een load balancer-set niet reageren op statustests? Er zijn een aantal mogelijke redenen:
De back-endpool-VM heeft geen goede status.
- Als u dit wilt testen, verzendt u een Ping-aanvraag vanaf een andere VIRTUELE machine in de pool. De VIRTUELE machine moet kunnen reageren op aanvragen die deel uitmaken van de pool.
De back-endpool-VM staat geen verbindingen toe vanaf de testpoort.
- Voer vanaf de back-end-VM netstat -an uit en controleer of de juiste poort wordt vermeld als LUISTEREN. U moet de back-end-VM en/of de load balancer configureren om dezelfde poort te gebruiken.
Een firewall of NSG staat geen verbindingen van de testpoort toe.
- Als de back-end-VM en load balancer dezelfde poort gebruiken, controleert u of dit niet wordt geblokkeerd door een firewall of NSG.
De load balancer is onjuist geconfigureerd.
- Als de vorige tests allemaal zijn geslaagd, analyseert u het netwerk voor binnenkomende en uitgaande pakketten van meerdere VM's in de load balancer-set om het probleem te isoleren.
Zie Problemen met de statustest van Azure Load Balancer oplossen voor meer informatie.
Load balancer-regels onderzoeken
Met load balancer-regels wordt gedefinieerd hoe verkeer wordt gedistribueerd naar de load balancer-set. Dit kan betekenen dat een specifieke VIRTUELE machine alleen bepaald verkeer ontvangt op basis van het binnenkomende IP-adres, bijvoorbeeld.
Controleer de load balancer-regels als verkeer niet werkt zoals verwacht.
Zie Regels beheren voor Azure Load Balancer met behulp van Azure Portal voor meer informatie.
Bepalen hoe resources worden toegewezen op basis van de configuratie van de load balancer
Load balancers worden doorgaans gebruikt om verkeer gelijkmatig te verdelen. Hier volgen twee redenen waarom de distributie van verkeer van de load balancer ongelijk is:
Sessiepersistentie is ingeschakeld.
- Sessiepersistentie zorgt ervoor dat elk client- en serverpaar behouden blijft, zodat taakverdeling niet werkt zoals verwacht.
Clients bevinden zich achter een proxyserver.
- Een proxyserver kan ertoe leiden dat meerdere clients worden weergegeven als één client, zodat taakverdeling niet werkt zoals verwacht.
Als een VIRTUELE machine in de pool met gelijke taakverdeling in orde lijkt, maar niet reageert op aanvragen, kan er een aantal redenen zijn:
De back-end-VM luistert mogelijk niet op de juiste poort of de poort is mogelijk niet geopend.
Een netwerkbeveiligingsgroep blokkeert mogelijk de poort.
Een toepassing op de back-end-VM probeert toegang te krijgen tot een andere toepassing in dezelfde netwerkinterface. Dit wordt niet ondersteund.
Een back-end-VM probeert toegang te krijgen tot resources via de load balancer. Dit wordt niet ondersteund.
Zie Problemen met back-endverkeer van Azure Load Balancer oplossen voor meer informatie.
Problemen met poortuitputting oplossen
Wanneer een load balancer wordt gebruikt voor externe verbindingen, moet u rekening houden met poortuitputting. Er zijn 64.000 poorten beschikbaar, maar voor elke verbinding worden acht poorten gebruikt wanneer een load balancer wordt gebruikt. Als er veel back-endexemplaren zijn, is het daarom mogelijk om de beschikbare poorten uit te putten.
Zie Problemen met uitgaande verbindingen oplossen voor meer informatie.
Problemen met Azure Front Door oplossen
Als u Azure Front Door gebruikt voor taakverdeling en veelvoorkomende routeringsproblemen wilt oplossen, moet u eerst aanvragen dat Front Door extra foutopsporingsheaders voor HTTP-antwoorden retourneert.
Zie Protocolondersteuning voor HTTP-headers in Azure Front Door voor meer informatie.
Wanneer u de antwoordheaders van de HTTP-groep hebt, zijn er een aantal reacties van Azure Front Door die u kunt gebruiken voor foutopsporing:
Een reactie van 503 na een paar seconden betekent dat normale aanvragen naar uw back-end gaan zonder Azure Front Door te doorlopen. U kunt dit probleem oplossen door de time-outs voor de oorspronkelijke reactie voor het eindpunt te configureren en de standaardtime-out uit te breiden.
U ontvangt 503 reacties van de Azure Front Door, maar alleen voor HTTPS-aanvragen. Redenen hiervoor kunnen zijn:
De back-endpool is een IP-adres.
De back-endserver retourneert een certificaat dat niet overeenkomt met de volledig gekwalificeerde domeinnaam van de Back-endpool van Azure Front Door.
De back-endpool is een Azure-web-app-server.
U ontvangt 400 statuscodes wanneer aanvragen naar een aangepast domein worden verzonden.
- Het probleem treedt op omdat u geen routeringsregel voor het aangepaste domein hebt gemaakt toen deze als front-endhost werd toegevoegd.
U ontvangt 411 statuscodes van de front-endhost.
- Deze statuscodes worden gegenereerd wanneer uw HTTP-aanvraag niet volledig RFC-compatibel is.
Zie Veelvoorkomende problemen met Azure Front Door oplossen voor meer informatie.
Problemen met Azure-toepassing Gateway oplossen
Application Gateway test back-endservers om hun status te controleren. Als deze servers niet met succes reageren, markeert Application Gateway deze als niet meer en wordt het verzenden van aanvragen naar deze servers gestopt. Application Gateway hervat het verzenden van aanvragen wanneer de server met succes reageert.
Zie Problemen met de back-endstatus in Application Gateway oplossen voor meer informatie.
Problemen met Azure Load Balancer oplossen
Er zijn verschillende stappen voor probleemoplossing die u moet overwegen wanneer u Azure Load Balancer gebruikt:
Standaard interne load balancers worden standaard beveiligd, maar standaard interne load balancers staan verbindingen met internet toe via verborgen IP-adressen. Dit wordt niet aanbevolen voor productieworkloads. Netwerkgateway is de aanbevolen oplossing voor uitgaand verkeer.
Wanneer u een statustest hebt, kan de back-endpoort niet worden gewijzigd voor taakverdeling. Als u dit probleem wilt oplossen, verwijdert u de statustest, configureert u de poort opnieuw en voegt u de statustest opnieuw toe.
Als een VIRTUELE machine wordt verwijderd uit een back-endpool, maar nog steeds netwerkverkeer ontvangt, kan dit worden veroorzaakt door opslag, DNS of andere Azure-functies.
Zie Problemen met Azure Load Balancer oplossen voor meer informatie.
Problemen met Traffic Manager-profiel oplossen
Azure Traffic Manager maakt gebruik van zes verkeersrouteringsmethoden. Dit zijn prioriteit, gewogen, prestaties, geografische, meerdere waarden en subnetten. Als u de onjuiste verkeersrouteringsmethode selecteert, wordt het verwachte gedrag mogelijk niet bereikt. Verkeer gaat mogelijk naar een primair service-eindpunt voor al het verkeer omdat u Prioriteit gebruikt, maar u wilt dat het naar het dichtstbijzijnde eindpunt gaat, bijvoorbeeld met behulp van Prestaties.
Zie Traffic Manager-routeringsmethoden voor meer informatie.
Problemen met latentie oplossen
Voor latentieproblemen in uw netwerk met gelijke taakverdeling moet u testen op dezelfde manier als voor elke netwerklatentie van virtuele machines. U kunt algemene connectiviteitshulpprogramma's zoals Ping gebruiken, maar er zijn meer gespecialiseerde hulpprogramma's van derden beschikbaar voor meer informatie. Als u latentieproblemen wilt testen, is het een goed idee om twee virtuele machines te gebruiken, één als de afzender en de andere als ontvanger. Hiermee kunt u de communicatie in twee richtingen tussen de virtuele machines en de load balancer testen.
Zie Vm-netwerklatentie testen voor meer informatie.