Felsöka nätverksprestanda

Översikt

Azure är ett stabilt och snabbt sätt att ansluta ditt lokala nätverk till Azure. Metoder som plats-till-plats-VPN och ExpressRoute används av kunder av alla storlekar för att köra sina företag i Azure. Men vad händer när prestanda inte uppfyller dina förväntningar eller tidigare erfarenheter? Den här artikeln kan hjälpa dig att standardisera hur du testar och baslinjeiserar din specifika miljö.

Du får lära dig hur du enkelt och konsekvent testar nätverksfördröjning och bandbredd mellan två värdar. Du får också råd om hur du kan titta på Azure-nätverket för att isolera problempunkter. PowerShell-skriptet och verktygen som diskuteras kräver två värdar i nätverket (i vardera änden av länken som testas). En värd måste vara en Windows Server eller Desktop, och den andra kan vara antingen Windows eller Linux.

Nätverkskomponenter

Innan vi går igenom felsökningen ska vi diskutera några vanliga termer och komponenter. Den här diskussionen säkerställer att vi tänker på varje komponent i kedjan från slutpunkt till slutpunkt som möjliggör anslutning i Azure.

På den högsta nivån finns det tre huvudnätverksroutningsdomäner:

• Azure-nätverket (blått moln)
• Internet eller WAN (grönt moln)
• Företagsnätverket (orange moln)

När vi tittar på diagrammet från höger till vänster ska vi kortfattat diskutera varje komponent:

• Virtuell dator – Servern kan ha flera nätverkskort. Se till att alla statiska vägar, standardvägar och operativsysteminställningar skickar och tar emot trafik som du tror att det är. Dessutom har varje VM SKU en bandbreddsbegränsning. Om du använder en mindre SKU för virtuella datorer begränsas trafiken av den bandbredd som är tillgänglig för nätverkskortet. Vi rekommenderar att du använder en DS5v2 för testning för att säkerställa tillräcklig bandbredd på den virtuella datorn.

• Nätverkskort – Se till att du känner till den privata IP-adress som är tilldelad till det aktuella nätverkskortet.

• Nätverkskortssäkerhetsgrupp – Det kan finnas specifika NSG:er som tillämpas på nätverkskortsnivå. Kontrollera att NSG-regeluppsättningen är lämplig för den trafik som du försöker skicka. Se till exempel till att portarna 5201 för iPerf, 3389 för RDP eller 22 för SSH är öppna så att testtrafiken kan passera.

• VNet-undernät – Nätverkskortet tilldelas till ett specifikt undernät. Kontrollera att du vet vilken och de regler som är associerade med det undernätet.

• NSG för undernät – Precis som nätverkskortet kan även NSG:er tillämpas på undernätsnivå. Kontrollera att NSG-regeluppsättningen är lämplig för den trafik som du försöker skicka. För inkommande trafik till nätverkskortet gäller nätverkssäkerhetsgruppen för undernätet först och sedan nätverkskortets nätverkssäkerhetsgrupp. När trafiken utgående från den virtuella datorn tillämpas nätverkssäkerhetsgruppen först och sedan tillämpas nätverkssäkerhetsgruppen för undernätet.

• Undernäts-UDR – Användardefinierade vägar kan dirigera trafik till ett mellanliggande hopp (till exempel en brandvägg eller lastbalanserare). Se till att du vet om det finns en UDR på plats för din trafik. I så fall, förstå vart det går och vad nästa hopp kommer att göra med din trafik. En brandvägg kan till exempel skicka trafik och neka annan trafik mellan samma två värdar.

• Gateway-undernät/NSG/UDR – Precis som det virtuella datorundernätet kan gatewayundernätet ha NSG:er och UDR:er. Se till att du vet om de finns där och vilka effekter de har på din trafik.

• VNet Gateway (ExpressRoute) – När peering (ExpressRoute) eller VPN har aktiverats finns det inte många inställningar som kan påverka hur eller om trafikvägar. Om du har en virtuell nätverksgateway ansluten till flera ExpressRoute-kretsar eller VPN-tunnlar bör du vara medveten om inställningarna för anslutningens vikt. Anslutningsvikten påverkar anslutningsinställningen och avgör vilken sökväg trafiken tar.

• Routningsfilter (visas inte) – Ett vägfilter krävs när du använder Microsoft-peering via ExpressRoute. Om du inte får några vägar kontrollerar du om vägfiltret har konfigurerats och tillämpats korrekt på kretsen.

Nu är du på WAN-delen av länken. Den här routningsdomänen kan vara din tjänstleverantör, företagets WAN eller Internet. Det finns många hopp, enheter och företag som är involverade i dessa länkar, vilket kan göra det svårt att felsöka. Du måste först utesluta både Azure och företagets nätverk innan du kan undersöka hoppen däremellan.

I föregående diagram finns företagets nätverk längst till vänster. Beroende på företagets storlek kan den här routningsdomänen vara några nätverksenheter mellan dig och WAN eller flera lager av enheter i ett campus-/företagsnätverk.

Med tanke på komplexiteten i dessa tre olika högnivånätverksmiljöer är det ofta optimalt att börja vid kanterna och försöka visa var prestandan är bra och var den försämras. Den här metoden kan hjälpa dig att identifiera de tres problemroutningsdomän. Sedan kan du fokusera felsökningen på den specifika miljön.

Verktyg

De flesta nätverksproblem kan analyseras och isoleras med grundläggande verktyg som ping och traceroute. Det är ovanligt att du behöver gå så djupt som en paketanalys med hjälp av verktyg som Wireshark.

För att hjälpa till med felsökning har Azure Connectivity Toolkit (AzureCT) utvecklats för att placera några av dessa verktyg i ett enkelt paket. För prestandatestning kan verktyg som iPerf och PSPing ge dig information om nätverket. iPerf är ett vanligt verktyg för grundläggande prestandatester och är ganska lätt att använda. PSPing är ett pingverktyg som utvecklats av SysInternals. PSPing kan göra både ICMP- och TCP-pingar för att nå en fjärrvärd. Båda dessa verktyg är lätta och "installerade" genom att helt enkelt kopiera filerna till en katalog på värden.

Dessa verktyg och metoder omsluts i en PowerShell-modul (AzureCT) som du kan installera och använda.

AzureCT – Azure Connectivity Toolkit

AzureCT PowerShell-modulen innehåller två komponenter: Tillgänglighetstestning och prestandatestning. Det här dokumentet fokuserar på prestandatestning, särskilt de två Link Performance-kommandona i den här PowerShell-modulen.

Här är de tre grundläggande stegen för att använda den här verktygslådan för prestandatestning:

1. Installera PowerShell-modulen

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

   Det här kommandot laddar ned och installerar PowerShell-modulen lokalt.

2. Installera de stödprogram som stöds

   Install-LinkPerformance
   

   Det här AzureCT-kommandot installerar iPerf och PSPing i en ny katalog C:\ACTTools och öppnar Windows-brandväggsportarna för att tillåta ICMP- och port 5201-trafik (iPerf).

3. Kör prestandatestet

   Börja med att installera och köra iPerf i serverläge på fjärrvärden. Kontrollera att fjärrvärden lyssnar på antingen 3389 (RDP för Windows) eller 22 (SSH för Linux) och tillåter trafik på port 5201 för iPerf. Om fjärrvärden är Windows installerar du AzureCT och kör kommandot Install-LinkPerformance för att konfigurera iPerf och nödvändiga brandväggsregler.

   När fjärrdatorn är klar öppnar du PowerShell på den lokala datorn och startar testet:

   Get-LinkPerformance -RemoteHost 10.0.0.1 -TestSeconds 10
   

   Det här kommandot kör en serie samtidiga belastnings- och svarstidstester för att uppskatta bandbreddskapaciteten och svarstiden för nätverkslänken.

4. Granska testutdata

   PowerShell-utdataformatet ser ut ungefär så här:

   

   Detaljerade resultat av alla iPerf- och PSPing-tester sparas i enskilda textfiler i katalogen AzureCT-verktyg på C:\ACTTools.

Felsökning

Om prestandatestresultaten inte är som förväntat följer du en systematisk metod för att identifiera problemet. Med tanke på antalet komponenter i sökvägen är en stegvis process effektivare än slumpmässig testning.

Kommentar

Scenariot här är ett prestandaproblem, inte ett anslutningsproblem. Om du vill isolera anslutningsproblem till Azure-nätverket följer du artikeln Verifiera ExpressRoute-anslutning .

1. Utmana dina antaganden

   Se till att dina förväntningar är rimliga. Till exempel med en ExpressRoute-krets på 1 Gbit/s och 100 ms svarstid är det orealistiskt att förvänta sig hela 1 Gbit/s trafik på grund av prestandaegenskaperna för TCP över länkar med hög svarstid. Mer information om prestandaantaganden finns i avsnittet Referenser.

2. Börja vid nätverksgränsen

   Börja vid kanterna mellan routningsdomäner och försök isolera problemet till en enda större routningsdomän. Undvik att skylla på den "svarta rutan" i vägen utan grundlig undersökning, eftersom detta kan fördröja lösningen.

3. Skapa ett diagram

   Rita ett diagram över området i fråga för att metodiskt arbeta igenom och isolera problemet. Planera testpunkter och uppdatera kartan när du rensar områden eller gräver djupare.

4. Dela upp och erövra

   Segmentera nätverket och begränsa problemet. Identifiera var den fungerar och var den inte fungerar och fortsätt att flytta testpunkterna för att isolera den felaktiga komponenten.

5. Överväg alla OSI-lager

   Det är vanligt att fokusera på nätverket och lagren 1–3 (fysiska lager, data och nätverk) men kom ihåg att problem också kan uppstå på Lager 7 (programlager). Ha ett öppet sinne och verifiera alla antaganden.

Avancerad ExpressRoute-felsökning

Det kan vara svårt att isolera Azure-komponenter om du är osäker på var molnets kant är. Med ExpressRoute är gränsen en nätverkskomponent som kallas Microsoft Enterprise Edge (MSEE). MSEE är den första kontaktpunkten i Microsofts nätverk och det sista hoppet när du lämnar det. När du skapar en anslutning mellan din virtuella nätverksgateway och ExpressRoute-kretsen ansluter du till MSEE. Att identifiera MSEE som det första eller sista hoppet är avgörande för att isolera ett Azure-nätverksproblem. Att känna till trafikriktningen hjälper dig att avgöra om problemet finns i Azure eller längre nedströms i WAN-nätverket eller företagsnätverket.

Kommentar

MSEE finns inte i Azure-molnet. ExpressRoute ligger i utkanten av Microsoft-nätverket, inte i Azure. När du är ansluten med ExpressRoute till en MSEE är du ansluten till Microsofts nätverk, vilket ger åtkomst till molntjänster som Microsoft 365 (med Microsoft Peering) eller Azure (med privat och/eller Microsoft-peering).

Om två virtuella nätverk är anslutna till samma ExpressRoute-krets kan du utföra tester för att isolera problemet i Azure.

Testplan

1. Kör Get-LinkPerformance-testet mellan VM1 och VM2. Det här testet ger insikt i om problemet är lokalt. Om testet ger godtagbara svarstider och bandbreddsresultat kan du markera det lokala virtuella nätverket som bra.

2. Förutsatt att den lokala virtuella nätverkstrafiken är bra kör du Get-LinkPerformance-testet mellan VM1 och VM3. Det här testet testar anslutningen via Microsoft-nätverket till MSEE och tillbaka till Azure. Om testet ger godtagbara svarstider och bandbreddsresultat kan du markera Azure-nätverket som bra.

3. Om Azure utesluts utför du liknande tester i företagets nätverk. Om dessa tester också är bra kan du kontakta din tjänstleverantör eller Internetleverantör för att diagnostisera DIN WAN-anslutning. Kör till exempel tester mellan två avdelningskontor eller mellan skrivbordet och en datacenterserver. Hitta slutpunkter som servrar och klientdatorer som kan använda den sökväg du testar.

Viktigt!

För varje test markerar du tiden på dagen och registrerar resultaten på en gemensam plats. Varje testkörning bör ha identiska utdata för konsekvent datajämförelse. Konsekvens mellan flera tester är den främsta orsaken till att du använder AzureCT för felsökning. Nyckeln är att få konsekventa test- och datautdata varje gång. Att registrera tid och ha konsekventa data är särskilt användbart om problemet är sporadiskt. Var noggrann med datainsamling i förväg för att undvika timmar av omtestning av samma scenarier.

Problemet är isolerat, vad händer nu?

Ju mer du isolerar problemet, desto snabbare kan du hitta lösningen. Ibland når du en punkt där du inte kan gå vidare med felsökning. Du kan till exempel se länken mellan tjänsteleverantören som tar hopp genom Europa när du förväntar dig att den ska finnas kvar i Asien. Kontakta nu någon för hjälp baserat på den routningsdomän som du isolerade problemet till. Det är ännu bättre att begränsa den till en specifik komponent.

Vid problem med företagsnätverk kan din interna IT-avdelning eller tjänstleverantör hjälpa dig med enhetskonfiguration eller maskinvarureparation.

För WAN-problem kan du dela dina testresultat med din tjänstleverantör eller isp för att hjälpa dem med deras arbete och undvika redundanta uppgifter. De kanske vill verifiera dina resultat baserat på principen om förtroende men verifiera.

När du har isolerat problemet så detaljerat som möjligt för Azure-problem kan du läsa dokumentationen för Azure-nätverket och, om det behövs, öppna ett supportärende.

Referenser

Förväntningar på svarstid/bandbredd

Dricks

Geografiskt avstånd mellan slutpunkter är den största faktorn för svarstid. Medan utrustningsfördröjning (fysiska och virtuella komponenter, antal hopp osv.) också spelar en roll, är avståndet för fiberkörningen, inte det raka avståndet, den primära deltagaren. Det här avståndet är svårt att mäta korrekt, så vi använder ofta en stadsdistanskalkylator för en grov uppskattning.

Vi har till exempel konfigurerat en ExpressRoute i Seattle, Washington, USA. Tabellen nedan visar svarstiden och bandbredden som observerats vid testning till olika Azure-platser, tillsammans med uppskattade avstånd.

Testkonfiguration:

• En fysisk server som kör Windows Server 2016 med ett nätverkskort på 10 Gbit/s som är ansluten till en ExpressRoute-krets.

• En ExpressRoute-krets på 10 Gbit/s med privat peering aktiverat.

• Ett virtuellt Azure-nätverk med en UltraPerformance-gateway i den angivna regionen.

• En virtuell DS5v2-dator som kör Windows Server 2016 i det virtuella nätverket med azure-standardavbildningen med AzureCT installerat.

• Alla tester använde kommandot AzureCT Get-LinkPerformance med ett belastningstest på 5 minuter för var och en av de sex testkörningarna. Till exempel:

  Get-LinkPerformance -RemoteHost 10.0.0.1 -TestSeconds 300
  

• Dataflödet för varje test kom från den lokala servern (iPerf-klienten i Seattle) till den virtuella Azure-datorn (iPerf-servern i den angivna Azure-regionen).

• Kolumnen "Svarstid" visar data från no load-testet (ett TCP-svarstidstest utan att iPerf körs).

• Kolumnen "Maximal bandbredd" visar data från 16 TCP-flödesbelastningstestet med en fönsterstorlek på 1 Mb.

Resultat av svarstid/bandbredd

Viktigt!

Dessa tal är endast för allmän referens. Många faktorer påverkar svarstiden, och även om dessa värden vanligtvis är konsekventa över tid kan villkoren i Azure eller tjänstleverantörens nätverk ändras, vilket påverkar svarstiden och bandbredden. I allmänhet resulterar dessa ändringar inte i några större skillnader.

ExpressRoute-plats	Azure-region	Uppskattat avstånd (km)	Svarstid	1 sessionsbandbredd	Maximal bandbredd
Seattle	Västra USA 2	191 km	5 ms	262,0 Mbit/s	3,74 Gbits/s
Seattle	Västra USA	1 094 km	18 ms	82,3 Mbit/s	3,70 Gbits/s
Seattle	Centrala USA	2 357 km	40 ms	38,8 Mbit/s	2,55 Gbits/s
Seattle	USA, södra centrala	2 877 km	51 ms	30,6 Mbit/s	2,49 Gbits/s
Seattle	Norra centrala USA	2 792 km	55 ms	27,7 Mbit/s	2,19 Gbits/s
Seattle	USA, östra 2	3 769 km	73 ms	21,3 Mbit/s	1,79 Gbits/s
Seattle	USA, östra	3 699 km	74 ms	21,1 Mbit/s	1,78 Gbits/s
Seattle	Japan, östra	7 705 km	106 ms	14,6 Mbit/s	1,22 Gbits/s
Seattle	Södra Storbritannien	7 708 km	146 ms	10,6 Mbit/s	896 Mbit/s
Seattle	Västeuropa	7 834 km	153 ms	10,2 Mbit/s	761 Mbit/s
Seattle	Australien, östra	12 484 km	165 ms	9,4 Mbit/s	794 Mbit/s
Seattle	Sydostasien	12 989 km	170 ms	9,2 Mbit/s	756 Mbit/s
Seattle	Södra Brasilien *	10 930 km	189 ms	8,2 Mbit/s	699 Mbit/s
Seattle	Södra Indien	12 918 km	202 ms	7,7 Mbit/s	634 Mbit/s

* Svarstiden till Brasilien är ett exempel där fiberkörningsavståndet skiljer sig avsevärt från det räta avståndet. Den förväntade svarstiden skulle vara cirka 160 ms, men det är faktiskt 189 ms på grund av den längre fibervägen.

Kommentar

Dessa siffror testades med Hjälp av AzureCT baserat på iPerf i Windows via PowerShell. iPerf uppfyller inte standardalternativen för Windows TCP för skalningsfaktor och använder ett lägre skiftantal för TCP-fönsterstorleken. Genom att justera iPerf-kommandon med växeln -w och en större TCP-fönsterstorlek kan bättre dataflöde uppnås. Om du kör iPerf i flertrådat läge från flera datorer kan du också få maximal länkprestanda. Om du vill få bästa iPerf-resultat i Windows använder du "Set-NetTCPSetting -AutoTuningLevelLocal Experimental". Kontrollera organisationens principer innan du gör några ändringar.

Nästa steg

• Ladda ned Azure Connectivity Toolkit
• Följ anvisningarna för länkprestandatestning