Felsöka nätverksprestanda

Sammanfattning

Azure är ett stabilt och snabbt sätt att ansluta ditt lokala nätverk till Azure. Kunder av alla storlekar använder metoder som plats-till-plats-VPN och ExpressRoute för att driva 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 hjälper dig att standardisera hur du testar och baslinjeiserar din specifika miljö.

Du lär 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ätverk 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). Den ena värddatorn måste köra Windows Server eller vara en Windows-dator, och den andra värddatorn kan vara antingen en Windows- eller Linux-dator.

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 du tänker på varje komponent i slutpunkt till slutpunkt-kedjan som möjliggör anslutning i Azure.

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

• Det 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 förväntar dig. 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. Använd 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.

• NIC NSG – Det kan finnas specifika NSG:er som tillämpas på NIC-nivå. 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 du även använda NSG:er på undernätsnivå. Kontrollera att NSG-regeluppsättningen är lämplig för den trafik som du försöker släppa igenom. För trafik som kommer in till nätverkskortet tillämpas först undernätets NSG och sedan nätverkskortets NSG. När trafik går ut från den virtuella datorn tillämpas först nätverkskortets nätverkssäkerhetsgrupp och därefter nätverkssäkerhetsgruppen för undernätet.

• UDR för undernät – användardefinierade vägar kan dirigera trafik till en mellanliggande nod, till exempel en brandvägg eller lastbalanserare. Se till att du vet om det finns en UDR på plats för din trafik. Om så är fallet, ta reda på vart den går och vad nästa hopp gör med trafiken. 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 peeringanslutning (ExpressRoute) eller VPN har aktiverats finns det inte många inställningar som kan påverka hur eller om trafik dirigeras. 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.

• Route Filter (visas inte) – Ett vägfilter krävs när du använder Microsoft Peering via ExpressRoute. Om du inte får några rutter, kontrollerar du om rutfilteret har konfigurerats och tillämpats korrekt på nätverkskretsen.

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. Många mellanled, enheter och företag är inblandade i de här länkarna, 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- eller 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 den problematiska routningsdomänen av de tre. Sedan kan du fokusera felsökningen på den specifika miljön.

Tools

Du kan analysera och isolera de flesta nätverksproblem med hjälp av grundläggande verktyg som ping och traceroute. Det är ovanligt att du behöver gå så djupt som 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 installeras genom att kopiera filerna till en katalog på värddatorn.

Du kan använda en PowerShell-modul (AzureCT) som omsluter dessa verktyg och metoder.

AzureCT – Azure-anslutningsverktyget

AzureCT PowerShell-modulen innehåller två komponenter: Availability Testing och Performance Testing. Den här artikeln fokuserar på prestandatestning, särskilt de två Link Performance-kommandona i den här PowerShell-modulen.

Följ dessa tre grundläggande steg 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 portarna Windows Firewall 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ök problem med prestanda

Om prestandatestresultatet inte är det du förväntade dig 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.

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 det här antagandet 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 det fungerar och var det inte fungerar. 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ätverksnivåer), 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 eller företagsnätverket.

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

Testplan

1. Kör Get-LinkPerformance test 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 test mellan VM1 och VM3. Det här testet utför anslutningen via Microsoft-nätverket ned 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 kan du utföra 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.

Problemet är isolerat, vad händer nu?

Ju mer du isolerar problemet, desto snabbare kan du hitta en lösning. Ibland når du en punkt där du inte kan gå vidare med felsökning. Till exempel kan du se länken över din tjänsteleverantör ta vägen via Europa när du förväntar dig att den ska stanna 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.

Om du har problem med Azure, försök att isolera problemet så detaljerat som möjligt och granska Azure Network Documentation. Om det behövs kan du öppna ett supportärende.

Referenser

Förväntningar på svarstid och bandbredd

Du kan till exempel konfigurera en ExpressRoute i Seattle, Washington, USA. I följande tabell visas svarstiden och bandbredden som du observerar när du testar 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 Azure virtuellt 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 standardavbildningen Azure med AzureCT installerat.

• Alla tester använder 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 kommer från den lokala servern (iPerf-klienten i Seattle) till den Azure virtuella 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 och bandbredd

* 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 är cirka 160 ms, men det är faktiskt 189 ms på grund av den längre fibervägen.

Nästa steg

• Ladda ned Azure Connectivity Toolkit
• Följ anvisningarna för prestandatestning av länk