Dela via


Felsöka nätverksprestanda

Översikt

Azure är ett stabilt och snabbt sätt att ansluta ditt lokala nätverk till Azure. Små och stora kunder använder metoder som plats-till-plats-VPN och ExpressRoute för att driva sin verksamhet 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 lär dig hur du enkelt och konsekvent testar nätverksfördröjning och bandbredd mellan två värdar. Du får också några 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, 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.

Diagram över en nätverksroutningsdomän mellan lokalt till Azure med hjälp av ExpressRoute eller VPN.

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.

  • NSG för nätverkskort – Det kan finnas specifika NSG:er som tillämpas på nätverkskortsnivå. Se till 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, se till att du vet vilken och de regler som är associerade med det undernätet.

  • NSG för undernät – Precis som nätverkskortet kan NSG:er även användas i undernätet. 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 undernätets NSG först, 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. Det är 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 hantera 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 har två komponenter tillgänglighetstestning och prestandatestning. Det här dokumentet handlar bara om prestandatestning, så vi kan fokusera på de två Link Performance-kommandona i den här PowerShell-modulen.

Det finns 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 PowerShell-modulen och installerar den lokalt.

  2. Installera de program som stöds.

    Install-LinkPerformance
    

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

  3. Kör prestandatestet.

    Först måste du installera och köra iPerf i serverläge på fjärrvärden. Kontrollera också 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. Kommandot konfigurerar iPerf och de brandväggsregler som krävs för att starta iPerf i serverläge.

    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 beräkna bandbreddskapaciteten och svarstiden för nätverkslänken.

  4. Granska testernas utdata.

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

    Skärmbild av PowerShell-utdata från linkprestandatestet.

    De detaljerade resultaten av alla iPerf- och PSPing-tester finns i enskilda textfiler i AzureCT-verktygskatalogen i "C:\ACTTools".

Felsökning

Om prestandatestet inte ger förväntade resultat kan du ta reda på varför du bör vara en progressiv steg-för-steg-process. Med tanke på antalet komponenter i vägen ger ett systematiskt tillvägagångssätt en snabbare lösningsväg än att hoppa runt. Genom att felsöka systematiskt kan du förhindra onödig testning flera gånger.

Kommentar

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

Börja med att utmana dina antaganden. Är din förväntan rimlig? Om du till exempel har en ExpressRoute-krets på 1 Gbit/s och 100 ms svarstid. Det är inte rimligt att förvänta sig hela 1 Gbit/s trafik med tanke på prestandaegenskaperna för TCP över länkar med hög svarstid. Mer information om prestandaantaganden finns i avsnittet Referenser.

Därefter rekommenderar vi att du börjar vid kanterna mellan routningsdomäner och försöker isolera problemet till en enda större routningsdomän. Du kan börja på Företagsnätverk, WAN eller Azure Network. Folk skyller ofta på den "svarta lådan" i vägen. Även om det är lätt att skylla på den svarta lådan kan det avsevärt fördröja upplösningen. Särskilt om problemet finns i ett område där du kan göra ändringar för att åtgärda problemet. Se till att du gör din due diligence innan du lämnar över till tjänsteleverantören eller leverantören.

När du har identifierat den stora routningsdomänen som verkar innehålla problemet bör du skapa ett diagram över området i fråga. När du ritar ut ett diagram kan du metodiskt arbeta igenom och isolera problemet. Du kan planera testpunkter och uppdatera kartan när du rensar områden eller gräver djupare när testningen fortskrider.

Nu när du har ett diagram börjar du dela upp nätverket i segment och begränsa problemet. Ta reda på var det fungerar och var det inte gör det. Fortsätt att flytta testpunkterna för att isolera till den felaktiga komponenten.

Glöm inte heller att titta på andra lager i OSI-modellen. Det är enkelt att fokusera på nätverket och lagren 1–3 (fysiska lager, data och nätverk) men problemen kan också vara uppe på lager 7 i programskiktet. Ha ett öppet sinne och verifiera antaganden.

Avancerad ExpressRoute-felsökning

Om du inte är säker på var gränsen i molnet faktiskt är kan det vara en utmaning att isolera Azure-komponenterna. När ExpressRoute används är gränsen en nätverkskomponent som kallas Microsoft Enterprise Edge (MSEE). När du använder ExpressRoute är MSEE den första kontaktpunkten i Microsofts nätverk och det sista hoppet när du lämnar Microsoft-nätverket. När du skapar ett anslutningsobjekt mellan din virtuella nätverksgateway och ExpressRoute-kretsen skapar du faktiskt en anslutning till MSEE. Identifiera MSEE som det första eller sista hoppet beroende på vilken riktning trafiken är avgörande för att isolera ett Azure-nätverksproblem. Att veta vilken riktning som bevisar om problemet finns i Azure eller längre nedströms i WAN eller företagsnätverket.

Diagram över flera virtuella nätverk som är anslutna till en ExpressRoute-krets.

Kommentar

Observera att MSEE inte finns i Azure-molnet. ExpressRoute ligger faktiskt i utkanten av Microsoft-nätverket som faktiskt inte finns i Azure. När du är ansluten med ExpressRoute till en MSEE är du ansluten till Microsofts nätverk. Därifrån kan du gå till någon av molntjänsterna, till exempel 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 en serie 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 om problemet är lokalt eller inte. Om det här 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 det här testet ger godkända svarstider och bandbreddsresultat kan du markera Azure-nätverket som bra.

  3. Om Azure utesluts kan du göra en liknande sekvens med tester i företagets nätverk. Om det också testar bra är det dags att arbeta med din tjänstleverantör eller Internetleverantör för att diagnostisera DIN WAN-anslutning. Exempel: Kör det här testet mellan två avdelningskontor eller mellan skrivbordet och en datacenterserver. Beroende på vad du testar hittar du slutpunkter som servrar och klientdatorer som kan använda den sökvägen.

Viktigt!

Det är viktigt att du för varje test markerar den tid på dagen som du kör testet och registrerar resultaten på en gemensam plats. Varje testkörning bör ha identiska utdata så att du kan jämföra resulterande data mellan testkörningar och inte ha "hål" i data. Konsekvens mellan flera tester är den främsta orsaken till att vi använder AzureCT för felsökning. Magin finns inte i de exakta belastningsscenarier som vi kör, utan i stället är magin det faktum att vi får ett konsekvent test och datautdata från varje test. Att registrera tid och ha konsekventa data varje gång är särskilt användbart om du senare upptäcker att problemet är sporadiskt. Var noggrann med din datainsamling i förväg så undviker du 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ökningen. Du ser till exempel länken mellan tjänsteleverantören som tar hopp genom Europa, men du förväntar dig att vägen ska förbli i Asien. Nu bör du kontakta någon för att få hjälp. Vem du frågar är beroende av den routningsdomän som du isolerar problemet till. Om du kan begränsa det till en specifik komponent som skulle vara ännu bättre.

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

En bra metod för att felsöka WAN är att dela dina testresultat med din tjänstleverantör eller ISP, eftersom det kan hjälpa dem med deras arbete. Testresultaten kan också undvika att utföra samma uppgifter igen som du redan har gjort. Men de kanske vill kontrollera dina resultat själva. Detta baseras på förtroendeprincipen men verifieras.

När du har isolerat problemet så detaljerat som möjligt med Azure är det dags att granska Azure Network-dokumentationen och sedan, om det behövs, öppna ett supportärende.

Referenser

Förväntningar på svarstid/bandbredd

Dricks

Geografisk svarstid (miles eller kilometer) mellan slutpunkterna som du testar är den överlägset största komponenten för svarstid. Även om det finns svarstider för utrustning (fysiska och virtuella komponenter, antal hopp osv.) har geografin visat sig vara den största komponenten i den totala svarstiden vid hantering av WAN-anslutningar. Det är också viktigt att notera att avståndet är avståndet för fiberkörningen, inte den raka linjen eller färdplansavståndet. Detta avstånd är otroligt svårt att få med någon noggrannhet. Därför använder vi vanligtvis en stadsdistanskalkylator på Internet och vet att den här metoden är ett grovt felaktigt mått, men räcker för att ställa in en allmän förväntan.

Vi har till exempel en ExpressRoute-konfiguration i Seattle, Washington i USA. I följande tabell visas svarstiden och bandbredden som vi såg testning på olika Azure-platser. Vi uppskattade det geografiska avståndet mellan varje slut av testet.

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 10Gbps Premium ExpressRoute-krets på den plats som identifieras 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. Den virtuella datorn var inte domänansluten, byggd från standardavbildningen i Azure (ingen optimering eller anpassning) 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 hade belastningen som flödade från den lokala fysiska servern (iPerf-klienten i Seattle) upp till den virtuella Azure-datorn (iPerf-servern i den angivna Azure-regionen).

  • Kolumndata för svarstid kommer från no load-testet (ett TCP-svarstidstest utan att iPerf körs).

  • Kolumndata för maximal bandbredd kommer från 16 TCP-flödesbelastningstestet med en fönsterstorlek på 1 Mb.

Diagram över testmiljön där AzureCT är installerat.

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 villkor i Azure eller tjänstprovidernätverket skicka trafik via olika sökvägar när som helst, vilket innebär att svarstid och bandbredd kan påverkas. I allmänhet resulterar effekterna av dessa ändringar inte i betydande skillnader.

ExpressRoute
Plats
Azure
Region
Beräknad
Avstånd (km)
Svarstid 1 session
Bandbredd
Högsta
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 bra exempel där det raka avståndet skiljer sig avsevärt från fiberkörningsavståndet. Den förväntade svarstiden skulle vara i närheten av 160 ms, men är faktiskt 189 ms. Skillnaden i svarstid verkar tyda på ett nätverksproblem någonstans. Men verkligheten är att fiberlinjen inte går till Brasilien i en rak linje. Så du bör förvänta dig en extra 1000 km eller så av resor för att komma till Brasilien från Seattle.

Kommentar

Dessa siffror bör beaktas, men de testades med Hjälp av AzureCT som är baserat i IPERF i Windows via PowerShell. I det här scenariot uppfyller IPERF inte standardalternativen för Windows TCP för skalningsfaktor och använder ett mycket lägre Skift-antal för TCP-fönsterstorleken. Talen som representeras här utfördes med IPERF-standardvärden och är endast för allmän referens. Genom att justera IPERF-kommandon med -w switch och en stor TCP-fönsterstorlek kan bättre dataflöde erhållas över långa avstånd, vilket visar betydligt bättre dataflödessiffror. För att säkerställa att en ExpressRoute använder den fullständiga bandbredden är det också idealiskt att köra IPERF i flertrådade alternativ från flera datorer samtidigt för att säkerställa att beräkningskapaciteten kan nå maximal länkprestanda och inte begränsas av bearbetningskapaciteten för en enda virtuell dator. 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