Problemen met netwerkprestaties oplossen

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 met succes toegepast door klanten met kleine of grote ondernemingen om hun bedrijf te exploiteren in Azure. 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, 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.

Op het hoogste niveau zijn er drie belangrijke netwerkrouteringsdomeinen:

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

Als u het diagram van rechts naar links bekijkt, bespreken we kort elk onderdeel:

• 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 zijn mogelijk specifieke NSG's toegepast op NIC-niveau, zorg ervoor dat de NSG-regelset geschikt is voor het verkeer dat u probeert door te geven. 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 is 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 worden toegepast op het subnet. Zorg ervoor dat de NSG-regelset geschikt is voor het verkeer dat u wilt doorgeven. Voor verkeer dat binnenkomt op de NIC, is de NSG van het subnet eerst van toepassing en vervolgens de NIC-NSG. Wanneer verkeer uitgaand van de VIRTUELE machine, wordt de NIC-NSG eerst toegepast, waarna de NSG van het subnet wordt 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. Het is vaak optimaal om aan de randen te beginnen en te proberen 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.

Extra

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 Verbinding maken ivity 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 over te laten 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 Verbinding maken ivity Toolkit

De AzureCT PowerShell-module heeft twee onderdelen : beschikbaarheidstests en prestatietests. Dit document heeft alleen betrekking op het testen van de prestaties, dus we kunnen zich richten op de twee opdrachten voor koppelingsprestaties in deze PowerShell-module.

Er zijn 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 gedownload en lokaal geïnstalleerd.

2. Installeer de ondersteunende toepassingen.

   Install-LinkPerformance
   

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

3. Voer de prestatietest uit.

   Eerst moet u op de externe host iPerf installeren en uitvoeren in de servermodus. Zorg er ook voor 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. Met de opdracht worden iPerf en de firewallregels ingesteld die nodig zijn om iPerf in de servermodus te starten.

   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 belasting- en latentietests uitgevoerd om de bandbreedtecapaciteit en latentie van uw netwerkkoppeling te schatten.

4. Controleer de uitvoer van de tests.

   De PowerShell-uitvoerindeling ziet er ongeveer als volgt uit:

   

   De gedetailleerde resultaten van alle iPerf- en PSPing-tests bevinden zich in afzonderlijke tekstbestanden in de map met AzureCT-hulpprogramma's op C:\ACTTools.

Problemen oplossen

Als de prestatietest u geen verwachte resultaten geeft, moet u uitzoeken waarom een stapsgewijs proces moet zijn. Gezien het aantal onderdelen in het pad, biedt een systematische aanpak een snellere oplossing dan rondspringen. Door systematisch problemen op te lossen, kunt u onnodige tests meerdere keren voorkomen.

Notitie

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

Daag eerst uw veronderstellingen uit. Is je verwachting redelijk? Als u bijvoorbeeld een ExpressRoute-circuit van 1 Gbps hebt en 100 ms latentie. Het is niet redelijk om de volledige 1 Gbps van het verkeer te verwachten, gezien de prestatiekenmerken van TCP via koppelingen met hoge latentie. Zie de sectie Verwijzingen voor meer informatie over prestatieveronderstellingen.

Vervolgens raden we u aan om aan de randen tussen routeringsdomeinen te beginnen en het probleem te isoleren tot één belangrijk routeringsdomein. U kunt beginnen bij het bedrijfsnetwerk, het WAN of het Azure-netwerk. Mensen de "zwarte doos" in het pad vaak de schuld geven. Hoewel het eenvoudig is om de zwarte doos de schuld te geven, kan het de resolutie aanzienlijk vertragen. Vooral als het probleem zich in een gebied bevindt dat u wijzigingen kunt aanbrengen om het probleem op te lossen. Zorg ervoor dat u uw due diligence uitvoert voordat u deze aflevert aan uw serviceprovider of internetprovider.

Nadat u het primaire routeringsdomein hebt geïdentificeerd dat het probleem lijkt te bevatten, moet u een diagram maken van het betreffende gebied. Wanneer u een diagram uittekent, kunt u het probleem methodisch doorlopen en isoleren. U kunt testpunten plannen en de kaart bijwerken naarmate u gebieden wist of dieper graaft naarmate de test vordert.

Nu u een diagram hebt, begint u het netwerk te verdelen in segmenten en het probleem te beperken. Ontdek waar het werkt en waar het niet werkt. Blijf uw testpunten verplaatsen om te isoleren naar het offending-onderdeel.

Vergeet ook niet om andere lagen van het OSI-model te bekijken. U kunt zich eenvoudig richten op het netwerk en de lagen 1 - 3 (fysieke, gegevens- en netwerklagen), maar de problemen kunnen zich ook voordoen op laag 7 in de toepassingslaag. Houd rekening met een open geest en controleer veronderstellingen.

Geavanceerde problemen met ExpressRoute oplossen

Als u niet zeker weet waar de rand van de cloud zich daadwerkelijk bevindt, kan het isoleren van de Azure-onderdelen een uitdaging zijn. Wanneer ExpressRoute wordt gebruikt, is de rand een netwerkonderdeel met de naam Microsoft Enterprise Edge (MSEE). Wanneer u ExpressRoute gebruikt, is de MSEE het eerste contactpunt in het microsoft-netwerk en de laatste hop wanneer u het Microsoft-netwerk verlaat. Wanneer u een verbindingsobject maakt tussen uw virtuele netwerkgateway en het ExpressRoute-circuit, maakt u daadwerkelijk verbinding met de MSEE. Het herkennen van de MSEE als de eerste of laatste hop, afhankelijk van de richting waarin het verkeer van cruciaal belang is voor het isoleren van een Azure-netwerkprobleem. Weten welke richting bewijst of het probleem zich in Azure bevindt of verder downstream is in het WAN of het bedrijfsnetwerk.

Notitie

U ziet dat de MSEE zich niet in de Azure-cloud bevindt. ExpressRoute bevindt zich eigenlijk aan de rand van het Microsoft-netwerk, niet in Azure. Zodra u bent verbonden met ExpressRoute met een MSEE, bent u verbonden met het netwerk van Microsoft, van daaruit kunt u naar een van de cloudservices gaan, 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 een reeks tests uitvoeren om het probleem in Azure te isoleren.

Testplan

1. Voer de Get-LinkPerformance-test uit tussen VM1 en VM2. Deze test biedt inzicht in of het probleem lokaal is of niet. Als deze test acceptabele latentie en bandbreedteresultaten produceert, kunt u het lokale virtuele netwerk als 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 deze test acceptabele latentie en bandbreedteresultaten produceert, kunt u het Azure-netwerk als goed markeren.

3. Als Azure wordt uitgesloten, kunt u een vergelijkbare reeks tests uitvoeren op uw bedrijfsnetwerk. Als dat ook goed test, is het tijd om samen te werken met uw serviceprovider of internetprovider om uw WAN-verbinding te diagnosticeren. Voorbeeld: Voer deze test uit tussen twee filialen of tussen uw bureau en een datacentrumserver. Afhankelijk van wat u test, vindt u eindpunten zoals servers en client-pc's die dat pad kunnen uitoefenen.

Belangrijk

Het is essentieel dat u voor elke test de tijd van de dag markeert waarop u de test uitvoert en de resultaten op een gemeenschappelijke locatie vastlegt. Elke testuitvoering moet identieke uitvoer hebben, zodat u de resulterende gegevens in testuitvoeringen kunt vergelijken en geen 'gaten' in de gegevens hebt. Consistentie tussen meerdere tests is de primaire reden waarom we AzureCT gebruiken voor probleemoplossing. De magie bevindt zich niet in de exacte laadscenario's die we uitvoeren, maar in plaats daarvan is het feit dat we een consistente test en gegevensuitvoer krijgen van elke test. Het vastleggen van de tijd en het hebben van consistente gegevens elke keer is vooral handig als u later merkt dat het probleem sporadisch is. Wees zorgvuldig met uw gegevensverzameling vooraf en u voorkomt 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 uw probleemoplossing. U ziet bijvoorbeeld de koppeling tussen uw serviceprovider die hops door Europa neemt, maar u verwacht dat het pad in Azië blijft. Op dit moment moet u contact opnemen met iemand voor hulp. Wie u vraagt, is afhankelijk van het routeringsdomein waarnaar u het probleem wilt isoleren. Als u deze kunt beperken tot een specifiek onderdeel dat nog beter zou zijn.

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

Een goede gewoonte voor het oplossen van problemen met het WAN is het delen van uw testresultaten met uw serviceprovider of internetprovider, omdat dit hen kan helpen met hun werk. Uw testresultaten kunnen ook voorkomen dat u dezelfde taken opnieuw uitvoert als u al hebt gedaan. Het kan echter zijn dat ze uw resultaten zelf willen controleren. Dit is gebaseerd op het vertrouwensbeginsel maar verifieert.

Zodra u het probleem hebt geïsoleerd in Azure, is het tijd om de documentatie van Het Azure-netwerk te bekijken en vervolgens, indien nodig , een ondersteuningsticket te openen.

Verwijzingen

Latentie/bandbreedteverwachtingen

Tip

Geografische latentie (mijlen of kilometers) tussen de eindpunten die u test, is verreweg het grootste onderdeel van latentie. Hoewel er sprake is van een latentie van apparatuur (fysieke en virtuele onderdelen, het aantal hops, enzovoort), is geografie het grootste onderdeel van de algehele latentie gebleken bij het omgaan met WAN-verbindingen. Het is ook belangrijk om te weten dat de afstand de afstand is van de glasvezelbaan niet de rechte lijn- of roadmapafstand. Deze afstand is ongelooflijk moeilijk te bereiken met elke nauwkeurigheid. Als gevolg hiervan gebruiken we over het algemeen een stadsafstandscalculator op internet en weten we dat deze methode een bruto onnauwkeurige meting is, maar is voldoende om een algemene verwachting in te stellen.

We hebben bijvoorbeeld een ExpressRoute-installatie in Seattle, Washington in de VS. In de volgende tabel ziet u de latentie en bandbreedte die we hebben gezien bij het testen naar verschillende Azure-locaties. We hebben de geografische afstand tussen elk einde van de test geschat.

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 op de locatie die is geïdentificeerd met persoonlijke peering ingeschakeld.

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

• Een DS5v2-VM met Windows Server 2016 in het virtuele netwerk. De VM is niet toegevoegd aan een domein, gebouwd op basis van de standaardinstallatiekopie van Azure (geen optimalisatie of aanpassing) waarop AzureCT is geïnstalleerd.

• Alle tests gebruiken 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 had de belasting van de on-premises fysieke server (iPerf-client in Seattle) tot aan de Azure-VM (iPerf-server in de vermelde Azure-regio).

• De kolomgegevens latentie zijn afkomstig van de test Geen belasting (een TCP-latentietest zonder dat iPerf wordt uitgevoerd).

• De kolomgegevens maximale bandbreedte zijn afkomstig uit de belastingstest van 16 TCP-stromen met een venstergrootte van 1 MB.

Resultaten van latentie/bandbreedte

Belangrijk

Deze getallen zijn alleen ter algemene referentie. Veel factoren beïnvloeden latentie en hoewel deze waarden over het algemeen consistent zijn in de loop van de tijd, kunnen voorwaarden binnen Azure of het netwerk serviceproviders op elk gewenst moment verkeer verzenden via verschillende paden, waardoor latentie en bandbreedte kunnen worden beïnvloed. Over het algemeen leiden de effecten van deze wijzigingen niet tot aanzienlijke verschillen.

ExpressRoute Locatie	Azure Regio	Geschat Afstand (km)	Latentie	1 sessie Bandbreedte	Maximum Bandbreedte
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	VK - 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 goed voorbeeld waarbij de rechte lijnafstand aanzienlijk verschilt van de glasvezelloopafstand. De verwachte latentie zou in de buurt van 160 ms zijn, maar is eigenlijk 189 ms. Het verschil in latentie lijkt ergens op een netwerkprobleem aan te geven. Maar de realiteit is dat de glasvezellijn niet in een rechte lijn naar Brazilië gaat. U zou dus een extra 1000 km of zo'n reis moeten verwachten om vanuit Seattle naar Brazilië te gaan.

Notitie

Hoewel rekening moet worden gehouden met deze getallen, zijn ze getest met behulp van AzureCT die is gebaseerd op IPERF in Windows via PowerShell. In dit scenario voldoet IPERF niet aan de standaardopties voor Windows TCP voor schaalfactor en maakt gebruik van een veel lager aantal shifts voor de grootte van het TCP-venster. De getallen die hier worden weergegeven, zijn uitgevoerd met behulp van standaard-IPERF-waarden en zijn alleen ter algemene referentie. Door IPERF-opdrachten af te stemmen met -w switch en een grote TCP-venstergrootte, kan een betere doorvoer worden verkregen via lange afstanden, met aanzienlijk betere doorvoercijfers. Om ervoor te zorgen dat een ExpressRoute gebruikmaakt van de volledige bandbreedte, is het ideaal om de IPERF uit te voeren in meerdere threads tegelijk vanaf meerdere computers om ervoor te zorgen dat de computercapaciteit maximale koppelingsprestaties kan bereiken en niet wordt beperkt door de verwerkingscapaciteit van één VIRTUELE machine. Gebruik Set-NetTCPSetting -AutoTuningLevelLocal Experimental om de beste Iperf-resultaten op Windows te krijgen. Controleer uw organisatiebeleid voordat u wijzigingen aanbrengt.

Volgende stappen

• De Azure Verbinding maken ivity Toolkit downloaden
• Volg de instructies voor het testen van koppelingsprestaties