Delen via

Problemen met netwerkprestaties oplossen

  • Artikel

Overzicht

Azure biedt een stabiele en snelle manier om uw on-premises netwerk te verbinden met Azure. Methoden zoals site-naar-site-VPN en ExpressRoute worden door klanten van alle grootten gebruikt om hun bedrijf in Azure uit te voeren. Maar wat gebeurt er wanneer de prestaties niet voldoen aan uw verwachtingen of eerdere ervaring? Dit artikel kan u helpen bij het standaardiseren van de manier waarop u uw specifieke omgeving test en basislijn gebruikt.

U leert hoe u eenvoudig en consistent netwerklatentie en bandbreedte tussen twee hosts kunt testen. U krijgt ook advies over manieren om naar het Azure-netwerk te kijken om probleempunten te isoleren. Voor het PowerShell-script en de hulpprogramma's die worden besproken, zijn twee hosts in het netwerk vereist (aan beide uiteinden van de koppeling die wordt getest). De ene host moet een Windows Server of Desktop zijn en de andere host kan Windows of Linux zijn.

Netwerkonderdelen

Voordat u problemen gaat oplossen, bespreken we enkele algemene termen en onderdelen. Deze discussie zorgt ervoor dat we nadenken over elk onderdeel in de end-to-end-keten die connectiviteit in Azure mogelijk maakt.

Diagram van een netwerkrouteringsdomein tussen on-premises naar Azure met behulp van ExpressRoute of VPN.

Op het hoogste niveau zijn er drie belangrijke netwerkrouteringsdomeinen:

  • Het Azure-netwerk (blauwe cloud)
  • Internet of WAN (groene cloud)
  • Het bedrijfsnetwerk (oranje cloud)

Laten we elk onderdeel kort bespreken door het diagram van rechts naar links te bekijken:

  • Virtuele machine : de server heeft mogelijk meerdere NIC's. Zorg ervoor dat statische routes, standaardroutes en besturingssysteeminstellingen verkeer verzenden en ontvangen zoals u denkt. Bovendien heeft elke VM-SKU een bandbreedtebeperking. Als u een kleinere VM-SKU gebruikt, wordt uw verkeer beperkt door de bandbreedte die beschikbaar is voor de NIC. U wordt aangeraden een DS5v2 te gebruiken om te testen of er voldoende bandbreedte beschikbaar is op de VIRTUELE machine.

  • NIC : zorg ervoor dat u het privé-IP-adres kent dat is toegewezen aan de betreffende NIC.

  • NIC-NSG : er kunnen specifieke NSG's worden toegepast op NIC-niveau. Zorg ervoor dat de NSG-regelset geschikt is voor het verkeer dat u wilt doorgeven. Zorg er bijvoorbeeld voor dat poorten 5201 voor iPerf, 3389 voor RDP of 22 voor SSH zijn geopend om testverkeer door te geven.

  • VNet-subnet : de NIC wordt toegewezen aan een specifiek subnet. Zorg ervoor dat u weet welke en welke regels aan dat subnet zijn gekoppeld.

  • Subnet-NSG : net als de NIC kunnen NSG's ook op subnetniveau worden toegepast. Zorg ervoor dat de NSG-regelset geschikt is voor het verkeer dat u wilt doorgeven. Voor inkomend verkeer naar de NIC is de NSG van het subnet eerst van toepassing en vervolgens de NIC-NSG. Wanneer verkeer uitgaand van de VIRTUELE machine, is de NIC-NSG eerst van toepassing en wordt de NSG van het subnet toegepast.

  • Subnet UDR : door de gebruiker gedefinieerde routes kunnen verkeer omleiden naar een tussenliggende hop (zoals een firewall of load balancer). Zorg ervoor dat u weet of er een UDR aanwezig is voor uw verkeer. Zo ja, begrijp dan waar het heen gaat en wat die volgende hop met uw verkeer doet. Een firewall kan bijvoorbeeld verkeer doorgeven en ander verkeer tussen dezelfde twee hosts weigeren.

  • Gatewaysubnet/NSG/UDR : net als het VM-subnet kan het gatewaysubnet NSG's en UDR's hebben. Zorg ervoor dat u weet of ze er zijn en welke gevolgen ze hebben voor uw verkeer.

  • VNet-gateway (ExpressRoute): zodra peering (ExpressRoute) of VPN is ingeschakeld, zijn er niet veel instellingen die van invloed kunnen zijn op hoe of als verkeer routes. Als u een virtuele netwerkgateway hebt verbonden met meerdere ExpressRoute-circuits of VPN-tunnels, moet u rekening houden met de instellingen voor het gewicht van de verbinding. Het verbindingsgewicht is van invloed op de verbindingsvoorkeur en bepaalt het pad dat uw verkeer neemt.

  • Routefilter (niet weergegeven): er is een routefilter nodig bij het gebruik van Microsoft-peering via ExpressRoute. Als u geen routes ontvangt, controleert u of het routefilter is geconfigureerd en correct is toegepast op het circuit.

Op dit moment bevindt u zich op het WAN-gedeelte van de koppeling. Dit routeringsdomein kan uw serviceprovider, uw zakelijke WAN of internet zijn. Er zijn veel hops, apparaten en bedrijven die betrokken zijn bij deze koppelingen, waardoor het lastig kan zijn om problemen op te lossen. U moet eerst zowel Azure- als bedrijfsnetwerken uitsluiten voordat u de hops daartussen kunt onderzoeken.

In het voorgaande diagram bevindt zich uiterst links uw bedrijfsnetwerk. Afhankelijk van de grootte van uw bedrijf kan dit routeringsdomein enkele netwerkapparaten zijn tussen u en het WAN of meerdere lagen apparaten in een campus-/bedrijfsnetwerk.

Gezien de complexiteit van deze drie verschillende netwerkomgevingen op hoog niveau, is het vaak optimaal om aan de randen te beginnen en te laten zien waar de prestaties goed zijn en waar de prestaties afnemen. Deze aanpak kan helpen bij het identificeren van het probleemrouteringsdomein van de drie. Vervolgens kunt u zich richten op het oplossen van problemen met die specifieke omgeving.

Hulpprogramma's

De meeste netwerkproblemen kunnen worden geanalyseerd en geïsoleerd met behulp van basishulpprogramma's zoals ping en traceroute. Het is zeldzaam dat u zo diep moet gaan als een pakketanalyse met behulp van hulpprogramma's zoals Wireshark.

Om u te helpen bij het oplossen van problemen, is de Azure Connectivity Toolkit (AzureCT) ontwikkeld om een aantal van deze hulpprogramma's in een eenvoudig pakket te plaatsen. Voor prestatietests kunnen hulpprogramma's zoals iPerf en PSPing u informatie geven over uw netwerk. iPerf is een veelgebruikt hulpprogramma voor eenvoudige prestatietests en is redelijk eenvoudig te gebruiken. PSPing is een ping tool ontwikkeld door SysInternals. PSPing kan zowel ICMP- als TCP-pings uitvoeren om een externe host te bereiken. Beide hulpprogramma's zijn lichtgewicht en worden 'geïnstalleerd' door de bestanden te kopiëren naar een map op de host.

Deze hulpprogramma's en methoden worden verpakt in een PowerShell-module (AzureCT) die u kunt installeren en gebruiken.

AzureCT - de Azure Connectivity Toolkit

De AzureCT PowerShell-module bevat twee onderdelen: Beschikbaarheidstests en Prestatietests. Dit document is gericht op het testen van prestaties, met name de twee opdrachten voor koppelingsprestaties in deze PowerShell-module.

Hier volgen de drie basisstappen voor het gebruik van deze toolkit voor prestatietests:

  1. De PowerShell-module installeren

    (new-object Net.WebClient).DownloadString("https://aka.ms/AzureCT") | Invoke-Expression

    Met deze opdracht wordt de PowerShell-module lokaal gedownload en geïnstalleerd.

  2. De ondersteunende toepassingen installeren

    Install-LinkPerformance

    Met deze AzureCT-opdracht worden iPerf en PSPing in een nieuwe map C:\ACTTools geïnstalleerd en worden de Windows Firewall-poorten geopend om ICMP- en iPerf-verkeer (iPerf) toe te staan.

  3. De prestatietest uitvoeren

    Installeer en voer iPerf eerst uit op de externe host in de servermodus. Zorg ervoor dat de externe host luistert op 3389 (RDP voor Windows) of 22 (SSH voor Linux) en verkeer op poort 5201 voor iPerf toestaat. Als de externe host Windows is, installeert u AzureCT en voert u de opdracht Install-LinkPerformance uit om iPerf en de benodigde firewallregels in te stellen.

    Zodra de externe machine gereed is, opent u PowerShell op de lokale computer en start u de test:

    Get-LinkPerformance -RemoteHost 10.0.0.1 -TestSeconds 10

    Met deze opdracht wordt een reeks gelijktijdige belastings- en latentietests uitgevoerd om de bandbreedtecapaciteit en latentie van uw netwerkkoppeling te schatten.

  4. De testuitvoer controleren

    De PowerShell-uitvoerindeling ziet er ongeveer als volgt uit:

    Schermopname van De PowerShell-uitvoer van de test Koppelingsprestaties.

    Gedetailleerde resultaten van alle iPerf- en PSPing-tests worden opgeslagen in afzonderlijke tekstbestanden in de map met AzureCT-hulpprogramma's op C:\ACTTools.

Probleemoplossing

Als de resultaten van de prestatietest niet zoals verwacht zijn, volgt u een systematische benadering om het probleem te identificeren. Gezien het aantal onderdelen in het pad is een stapsgewijs proces effectiever dan willekeurige tests.

Notitie

Het scenario hier is een prestatieprobleem, niet een verbindingsprobleem. Als u connectiviteitsproblemen met het Azure-netwerk wilt isoleren, volgt u het artikel Over het verifiëren van ExpressRoute-connectiviteit .

  1. Uw veronderstellingen uitdagen

    Zorg ervoor dat uw verwachtingen redelijk zijn. Als u bijvoorbeeld een ExpressRoute-circuit van 1 Gbps en 100 ms latentie verwacht, is de volledige 1 Gbps aan verkeer onrealistisch vanwege de prestatiekenmerken van TCP via koppelingen met hoge latentie. Raadpleeg de sectie Verwijzingen voor meer informatie over prestatieveronderstellingen.

  2. Beginnen aan de rand van het netwerk

    Begin aan de randen tussen routeringsdomeinen en probeer het probleem te isoleren naar één primair routeringsdomein. Vermijd de schuld van het 'zwarte vak' in het pad zonder grondig onderzoek, omdat dit de oplossing kan vertragen.

  3. Een diagram maken

    Teken een diagram van het betrokken gebied om het probleem methodisch te doorlopen en te isoleren. Plan testpunten en werk de kaart bij naarmate u gebieden wist of dieper graaft.

  4. Delen en veroveren

    Segmenteer het netwerk en verfijn het probleem. Bepaal waar het werkt en waar dat niet gebeurt en blijf uw testpunten verplaatsen om het offending-onderdeel te isoleren.

  5. Overweeg alle OSI-lagen

    Hoewel het richten op het netwerk en de lagen 1-3 (fysieke, gegevens- en netwerklagen) gebruikelijk is, moet u er rekening mee houden dat er ook problemen kunnen optreden op laag 7 (toepassingslaag). Houd rekening met alle veronderstellingen en controleer alle veronderstellingen.

Geavanceerde problemen met ExpressRoute oplossen

Het isoleren van Azure-onderdelen kan lastig zijn als u niet zeker weet waar de rand van de cloud zich bevindt. Met ExpressRoute is de rand een netwerkonderdeel met de naam Microsoft Enterprise Edge (MSEE). De MSEE is het eerste contactpunt in het netwerk van Microsoft en de laatste hop wanneer u deze verlaat. Wanneer u een verbinding maakt tussen uw virtuele netwerkgateway en het ExpressRoute-circuit, maakt u verbinding met de MSEE. Het herkennen van de MSEE als eerste of laatste hop is van cruciaal belang voor het isoleren van een Azure-netwerkprobleem. Als u de richting van het verkeer kent, kunt u bepalen of het probleem zich in Azure bevindt of verder downstream in het WAN- of bedrijfsnetwerk.

Diagram van meerdere virtuele netwerken die zijn verbonden met een ExpressRoute-circuit.

Notitie

De MSEE bevindt zich niet in de Azure-cloud. ExpressRoute bevindt zich aan de rand van het Microsoft-netwerk, niet in Azure. Zodra u verbinding hebt gemaakt met ExpressRoute met een MSEE, bent u verbonden met het netwerk van Microsoft, zodat u toegang hebt tot cloudservices zoals Microsoft 365 (met Microsoft-peering) of Azure (met privé- en/of Microsoft-peering).

Als twee VNets zijn verbonden met hetzelfde ExpressRoute-circuit, kunt u tests uitvoeren om het probleem in Azure te isoleren.

Testplan

  1. Voer de Get-LinkPerformance-test uit tussen VM1 en VM2. Deze test geeft inzicht in of het probleem lokaal is. Als de test acceptabele latentie en bandbreedteresultaten produceert, kunt u het lokale virtuele netwerk zo goed markeren.

  2. Ervan uitgaande dat het lokale verkeer van het virtuele netwerk goed is, voert u de Get-LinkPerformance-test uit tussen VM1 en VM3. Deze test oefent de verbinding via het Microsoft-netwerk naar de MSEE en terug naar Azure. Als de test acceptabele latentie en bandbreedteresultaten produceert, kunt u het Azure-netwerk als goed markeren.

  3. Als Azure wordt uitgesloten, voert u vergelijkbare tests uit op uw bedrijfsnetwerk. Als deze tests ook goed zijn, neemt u contact op met uw serviceprovider of internetprovider om uw WAN-verbinding te diagnosticeren. Voer bijvoorbeeld tests uit tussen twee filialen of tussen uw bureau en een datacenterserver. Zoek eindpunten zoals servers en client-pc's die het pad kunnen uitoefenen dat u wilt testen.

Belangrijk

Markeer voor elke test het tijdstip van de dag en noteer de resultaten op een gemeenschappelijke locatie. Elke testuitvoering moet identieke uitvoer hebben voor consistente gegevensvergelijking. Consistentie tussen meerdere tests is de primaire reden voor het gebruik van AzureCT voor probleemoplossing. De sleutel krijgt elke keer consistente test- en gegevensuitvoer. Het vastleggen van de tijd en het hebben van consistente gegevens is vooral handig als het probleem sporadisch is. Wees zorgvuldig met het verzamelen van gegevens vooraf om te voorkomen dat dezelfde scenario's opnieuw worden getest.

Het probleem is geïsoleerd, wat nu?

Hoe meer u het probleem isoleert, hoe sneller de oplossing kan worden gevonden. Soms bereikt u een punt waar u niet verder kunt gaan met het oplossen van problemen. U ziet bijvoorbeeld de koppeling tussen uw serviceprovider die hops door Europa neemt wanneer u verwacht dat deze in Azië blijft. Neem op dit moment contact op met iemand voor hulp op basis van het routeringsdomein waarnaar u het probleem hebt geïsoleerd. Het beperken tot een specifiek onderdeel is nog beter.

Voor problemen met het bedrijfsnetwerk kan uw interne IT-afdeling of serviceprovider u helpen bij het configureren van apparaten of het herstellen van hardware.

Voor WAN-problemen deelt u uw testresultaten met uw serviceprovider of internetprovider om hen te helpen met hun werk en redundante taken te voorkomen. Mogelijk willen ze uw resultaten controleren op basis van het vertrouwensbeginsel, maar verifiëren.

Als u het probleem zo gedetailleerd mogelijk hebt geïsoleerd, raadpleegt u de documentatie voor Het Azure-netwerk en opent u, indien nodig, een ondersteuningsticket.

Verwijzingen

Latentie/bandbreedteverwachtingen

Tip

Geografische afstand tussen eindpunten is de grootste factor in latentie. Hoewel de latentie van apparatuur (fysieke en virtuele onderdelen, het aantal hops, enzovoort) ook een rol speelt, is de afstand van de glasvezeluitvoering, niet de rechte lijnafstand, de primaire inzender. Deze afstand is moeilijk om nauwkeurig te meten, dus we gebruiken vaak een stadsafstandscalculator voor een ruwe schatting.

We hebben bijvoorbeeld een ExpressRoute ingesteld in Seattle, Washington, USA. In de onderstaande tabel ziet u de latentie en bandbreedte die zijn waargenomen bij het testen naar verschillende Azure-locaties, samen met geschatte afstanden.

Testinstallatie:

  • Een fysieke server met Windows Server 2016 met een 10 Gbps NIC die is verbonden met een ExpressRoute-circuit.

  • Een Premium ExpressRoute-circuit van 10 Gbps waarvoor privépeering is ingeschakeld.

  • Een virtueel Azure-netwerk met een UltraPerformance-gateway in de opgegeven regio.

  • Een DS5v2-VM met Windows Server 2016 in het virtuele netwerk, met behulp van de standaardInstallatiekopieën van Azure waarop AzureCT is geïnstalleerd.

  • Alle tests gebruikten de AzureCT Get-LinkPerformance-opdracht met een belastingstest van vijf minuten voor elk van de zes testuitvoeringen. Voorbeeld:

    Get-LinkPerformance -RemoteHost 10.0.0.1 -TestSeconds 300

  • De gegevensstroom voor elke test is afkomstig van de on-premises server (iPerf-client in Seattle) naar de Azure-VM (iPerf-server in de vermelde Azure-regio).

  • De kolom 'Latentie' toont gegevens uit de test Geen belasting (een TCP-latentietest zonder dat iPerf wordt uitgevoerd).

  • In de kolom Maximale bandbreedte ziet u gegevens uit de belastingstest van 16 TCP-stromen met een venstergrootte van 1 MB.

Diagram van de testomgeving waarin AzureCT is geïnstalleerd.

Resultaten van latentie/bandbreedte

Belangrijk

Deze getallen zijn alleen ter algemene referentie. Veel factoren zijn van invloed op latentie en hoewel deze waarden over het algemeen consistent zijn in de loop van de tijd, kunnen voorwaarden binnen Azure of het netwerk van de serviceprovider veranderen, wat van invloed is op latentie en bandbreedte. Over het algemeen leiden deze wijzigingen niet tot aanzienlijke verschillen.

ExpressRoute-locaties Azure-regio Geschatte afstand (km) Latentie 1 sessiebandbreedte Maximumbandbreedte
Seattle VS - west 2 191 km 5 ms 262,0 Mbits per seconde 3,74 Gbits per seconde
Seattle VS - west 1.094 km 18 ms 82,3 Mbits per seconde 3,70 Gbits per seconde
Seattle Central US 2.357 km 40 ms 38,8 Mbits per seconde 2,55 Gbits per seconde
Seattle VS - zuid-centraal 2.877 km 51 ms 30,6 Mbits per seconde 2,49 Gbits per seconde
Seattle VS - noord-centraal 2.792 km 55 ms 27,7 Mbits per seconde 2,19 Gbits per seconde
Seattle VS - oost 2 3.769 km 73 ms 21,3 Mbits per seconde 1,79 Gbits per seconde
Seattle VS - oost 3.699 km 74 ms 21,1 Mbits per seconde 1,78 Gbits per seconde
Seattle Japan East 7.705 km 106 ms 14,6 Mbits per seconde 1,22 Gbits per seconde
Seattle Verenigd Koninkrijk Zuid 7.708 km 146 ms 10,6 Mbits per seconde 896 Mbits per seconde
Seattle Europa -west 7.834 km 153 ms 10,2 Mbits/sec 761 Mbits per seconde
Seattle Australië - oost 12.484 km 165 ms 9,4 Mbits per seconde 794 Mbits per seconde
Seattle Azië - zuidoost 12.989 km 170 ms 9,2 Mbits per seconde 756 Mbits per seconde
Seattle Brazilië - zuid * 10.930 km 189 ms 8,2 Mbits/sec 699 Mbits per seconde
Seattle India - zuid 12.918 km 202 ms 7,7 Mbits per seconde 634 Mbits per seconde

* De latentie naar Brazilië is een voorbeeld waarbij de glasvezelafstand aanzienlijk verschilt van de rechte lijnafstand. De verwachte latentie zou ongeveer 160 ms zijn, maar het is eigenlijk 189 ms vanwege de langere glasvezelroute.

Notitie

Deze getallen zijn getest met behulp van AzureCT op basis van iPerf in Windows via PowerShell. iPerf voldoet niet aan de standaardopties voor Windows TCP voor Schaalfactor en maakt gebruik van een lagere Shift Count voor de grootte van het TCP-venster. Door iPerf-opdrachten af te stemmen met de -w switch en een grotere TCP-venstergrootte, kan een betere doorvoer worden bereikt. Het uitvoeren van iPerf in de modus met meerdere threads vanaf meerdere computers kan ook helpen de maximale koppelingsprestaties te bereiken. Gebruik Set-NetTCPSetting -AutoTuningLevelLocal Experimental om de beste iPerf-resultaten op Windows te krijgen. Controleer uw organisatiebeleid voordat u wijzigingen aanbrengt.

Volgende stappen