Řešení potíží s výkonem sítě

Přehled

Azure poskytuje stabilní a rychlý způsob připojení místní sítě k Azure. Metody, jako je vpn typu Site-to-Site a ExpressRoute, úspěšně používají zákazníci všech velikostí k provozování svých firem v Azure. Co se ale stane, když výkon nesplňuje vaše očekávání nebo předchozí zkušenosti? Tento článek vám pomůže standardizovat způsob testování a nastavení směrného plánu vašeho konkrétního prostředí.

Dozvíte se, jak snadno a konzistentně testovat latenci sítě a šířku pásma mezi dvěma hostiteli. Budete také dostávat rady o způsobech, jak se podívat na síť Azure, abyste mohli izolovat problémové body. Probíraný skript a nástroje PowerShellu vyžadují dva hostitele v síti (na každém konci testovaného propojení). Jeden hostitel musí být Windows Server nebo Desktop a druhý může být Windows nebo Linux.

Komponenty sítě

Než se podíváme na řešení potíží, probereme některé běžné termíny a komponenty. Tato diskuze zajišťuje, že uvažujeme o jednotlivých komponentách v komplexním řetězu, který umožňuje připojení v Azure.

Na nejvyšší úrovni existují tři hlavní domény směrování sítě:

• Síť Azure (modrý cloud)
• Internet nebo SÍŤ WAN (zelený cloud)
• Podniková síť (oranžový cloud)

Podívejme se na diagram zprava doleva, pojďme stručně probrat jednotlivé komponenty:

• Virtuální počítač – Server může mít několik síťových adaptérů. Ujistěte se, že všechny statické trasy, výchozí trasy a nastavení operačního systému odesílají a přijímají provoz podle vás. Každá skladová položka virtuálního počítače má také omezení šířky pásma. Pokud používáte menší skladovou položku virtuálního počítače, provoz je omezený šířkou pásma dostupnou pro síťovou kartu. K zajištění odpovídající šířky pásma na virtuálním počítači doporučujeme použít DS5v2.

• Síťová karta – Ujistěte se, že znáte privátní IP adresu přiřazenou k dané síťové kartě.

• NSG síťových adaptérů – Na úrovni síťové karty se můžou použít konkrétní skupiny zabezpečení sítě. Ujistěte se, že je sada pravidel NSG vhodná pro provoz, který se pokoušíte předat. Ujistěte se například, že jsou otevřené porty 5201 pro iPerf, 3389 pro protokol RDP nebo 22 pro SSH, aby bylo možné testovat provoz.

• Podsíť virtuální sítě – Síťové rozhraní je přiřazené ke konkrétní podsíti. Ujistěte se, že víte, která pravidla a která jsou přidružená k dané podsíti.

• Skupina zabezpečení sítě podsítě – stejně jako síťová karta, skupiny zabezpečení sítě se dají použít i na úrovni podsítě. Ujistěte se, že je sada pravidel NSG vhodná pro provoz, který se pokoušíte předat. Pro příchozí provoz do síťové karty se nejprve použije skupina zabezpečení sítě podsítě a pak skupina zabezpečení sítě síťové karty. Při odchozím přenosu z virtuálního počítače se nejprve použije skupina zabezpečení sítě síťových adaptérů a pak se použije skupina zabezpečení sítě podsítě.

• Trasa definovaná uživatelem – Trasy definované uživatelem můžou směrovat provoz do zprostředkujícího segmentu směrování (jako je brána firewall nebo nástroj pro vyrovnávání zatížení). Ujistěte se, že víte, jestli pro provoz existuje trasy definované uživatelem. Pokud ano, porozumíte tomu, kam směřuje a co další segment směrování bude pro váš provoz dělat. Brána firewall může například předat nějaký provoz a zakázat jiný provoz mezi stejnými dvěma hostiteli.

• Podsíť brány / skupina zabezpečení sítě / trasy definované uživatelem – stejně jako podsíť virtuálního počítače může mít podsíť brány skupiny zabezpečení sítě a trasy definované uživatelem. Ujistěte se, že víte, jestli tam jsou a jaké účinky mají na váš provoz.

• Brána virtuální sítě (ExpressRoute) – Po povolení partnerského vztahu (ExpressRoute) nebo SÍTĚ VPN neexistuje mnoho nastavení, která můžou ovlivnit, jak nebo jestli trasy provozu. Pokud máte bránu virtuální sítě připojenou k několika okruhům ExpressRoute nebo tunelům VPN, měli byste vědět o nastavení váhy připojení. Váha připojení ovlivňuje předvolbu připojení a určuje cestu, kterou provoz trvá.

• Filtr tras (není zobrazený) – Filtr tras je nutný při použití partnerského vztahu Microsoftu prostřednictvím ExpressRoute. Pokud nepřijímáte žádné trasy, zkontrolujte, jestli je filtr tras nakonfigurovaný a správně použitý pro okruh.

V tuto chvíli se nacházíte v části sítě WAN odkazu. Tato doména směrování může být vaším poskytovatelem služeb, vaší podnikovou sítí WAN nebo internetem. S těmito odkazy je zapojeno mnoho segmentů směrování, zařízení a společností, které by mohly ztížit řešení potíží. Než budete moct prozkoumat segmenty směrování mezi jednotlivými segmenty, musíte nejprve vyloučit Azure i podnikové sítě.

V předchozím diagramu je úplně vlevo vaše podniková síť. V závislosti na velikosti vaší společnosti může být tato doména směrování několika síťovými zařízeními mezi vámi a sítí WAN nebo několika vrstvami zařízení v síti campus/enterprise.

Vzhledem ke složitosti těchto tří různých síťových prostředí vysoké úrovně je často optimální začít na hranách a snažit se ukázat, kde je výkon dobrý a kde se snižuje. Tento přístup může pomoct identifikovat doménu směrování problému ze tří. Pak se můžete zaměřit na řešení potíží v daném konkrétním prostředí.

Nástroje

Většinu problémů se sítí je možné analyzovat a izolovat pomocí základních nástrojů, jako je ping a traceroute. Je vzácné, že je potřeba jít do hloubky jako analýza paketů pomocí nástrojů, jako je Wireshark.

V rámci řešení potíží jsme vyvinuli sadu Azure Connectivity Toolkit (AzureCT), která některé z těchto nástrojů obsahuje jednoduchý balíček. Pro testování výkonu vám nástroje, jako je iPerf a PSPing, můžou poskytnout informace o vaší síti. iPerf je běžně používaný nástroj pro základní testy výkonnosti a je poměrně snadno použitelný. PSPing je nástroj ping vyvinutý nástrojem SysInternals. PSPing může provádět protokoly ICMP i příkazy ping tcp pro připojení ke vzdálenému hostiteli. Oba tyto nástroje jsou jednoduché a jsou "nainstalovány" jednoduše zkopírováním souborů do adresáře na hostiteli.

Tyto nástroje a metody jsou zabalené do modulu PowerShellu (AzureCT), který můžete nainstalovat a používat.

AzureCT – Sada nástrojů Azure Connectivity Toolkit

Modul AzureCT PowerShellu obsahuje dvě komponenty: testování dostupnosti a testování výkonu. Tento dokument se zaměřuje na testování výkonu, konkrétně dva příkazy výkonu propojení v tomto modulu PowerShellu.

Tady jsou tři základní kroky pro použití této sady nástrojů pro testování výkonu:

1. Instalace modulu PowerShellu

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

   Tento příkaz stáhne a nainstaluje modul PowerShellu místně.

2. Instalace podpůrných aplikací

   Install-LinkPerformance
   

   Tento příkaz AzureCT nainstaluje do nového adresáře C:\ACTTools iPerf a PSPing a otevře porty brány Windows Firewall, které umožní provoz protokolu ICMP a portu 5201 (iPerf).

3. Spuštění testu výkonnosti

   Nejprve na vzdáleném hostiteli nainstalujte a spusťte iPerf v režimu serveru. Ujistěte se, že vzdálený hostitel naslouchá na portu 3389 (RDP pro Windows) nebo 22 (SSH pro Linux) a povoluje provoz na portu 5201 pro iPerf. Pokud je vzdálený hostitel Windows, nainstalujte AzureCT a spusťte příkaz Install-LinkPerformance, který nastaví iPerf a potřebná pravidla brány firewall.

   Jakmile je vzdálený počítač připravený, otevřete PowerShell na místním počítači a spusťte test:

   Get-LinkPerformance -RemoteHost 10.0.0.1 -TestSeconds 10
   

   Tento příkaz spustí řadu testů souběžného zatížení a latence, které odhadnou kapacitu šířky pásma a latenci síťového propojení.

4. Kontrola výstupu testu

   Výstupní formát PowerShellu vypadá nějak takto:

   

   Podrobné výsledky všech testů iPerf a PSPing se ukládají do jednotlivých textových souborů v adresáři nástrojů AzureCT na adrese C:\ACTTools.

Řešení problému

Pokud výsledky testu výkonnosti nejsou očekávané, postupujte podle systémového přístupu k identifikaci problému. Vzhledem k počtu komponent v cestě je krok za krokem efektivnější než náhodné testování.

Poznámka:

Tento scénář představuje problém s výkonem, ne problém s připojením. Pokud chcete izolovat problémy s připojením k síti Azure, postupujte podle článku Ověření připojení ExpressRoute.

1. Vyzývejte své předpoklady

   Ujistěte se, že jsou vaše očekávání rozumné. Například u okruhu ExpressRoute s rychlostí 1 Gb/s a latencí 100 ms očekáváte, že plný provoz o velikosti 1 Gb/s je nereálný kvůli charakteristikám výkonu protokolu TCP při propojení s vysokou latencí. Další informace o předpokladech výkonu najdete v části Reference.

2. Začněte na okraji sítě.

   Začněte na hranách mezi doménami směrování a pokuste se problém izolovat s jedinou hlavní doménou směrování. Vyhněte se obviňování "černé skříňky" v cestě bez důkladného šetření, protože to může zpozdit řešení.

3. Vytvoření diagramu

   Nakreslete diagram dané oblasti, který bude metodicky pracovat a izolovat problém. Naplánujte testovací body a aktualizujte mapu, jakmile vymažete oblasti nebo se podrobněji ponoříte do hloubky.

4. Dělit a dobít

   Segmentujte síť a zpřesníte problém. Určete, kde funguje a kde ne, a pokračujte v přesouvání testovacích bodů, abyste izolovali součást pro odsunutí.

5. Zvažte všechny vrstvy OSI.

   Zatímco zaměření na síť a vrstvy 1–3 (fyzické, datové a síťové vrstvy) je běžné, mějte na paměti, že problémy můžou nastat také na vrstvě 7 (aplikační vrstva). Mějte otevřenou mysl a ověřte všechny předpoklady.

Pokročilé řešení potíží s ExpressRoute

Izolace komponent Azure může být náročná, pokud si nejste jistí, kde je hraniční zařízení cloudu. S ExpressRoute je hraniční komponenta, která se nazývá Microsoft Enterprise Edge (MSEE). MSEE je prvním kontaktním bodem v síti Microsoftu a posledním segmentem směrování, když ho opustíte. Když vytvoříte připojení mezi bránou virtuální sítě a okruhem ExpressRoute, připojujete se k MSEE. Rozpoznávání MSEE jako prvního nebo posledního segmentu směrování je zásadní pro izolování problému se sítí Azure. Znalost směru provozu pomáhá určit, jestli se problém nachází v Azure nebo ve službě WAN nebo v podnikové síti.

Poznámka:

MSEE není v cloudu Azure. ExpressRoute je na okraji sítě Microsoftu, nikoli ve skutečnosti v Azure. Po připojení expressRoute k MSEE jste připojení k síti Microsoftu a umožníte přístup ke cloudovým službám, jako je Microsoft 365 (s partnerským vztahem Microsoftu) nebo Azure (s privátním partnerským vztahem nebo partnerským vztahem Microsoftu).

Pokud jsou dvě virtuální sítě připojené ke stejnému okruhu ExpressRoute, můžete problém izolovat v Azure pomocí testů.

Testovací plán

1. Spusťte test Get-LinkPerformance mezi virtuálním počítačem 1 a virtuálním počítačem 2. Tento test poskytuje přehled o tom, jestli je problém místní. Pokud test produkuje přijatelné výsledky latence a šířky pásma, můžete místní virtuální síť označit jako dobrou.

2. Za předpokladu, že je provoz místní virtuální sítě dobrý, spusťte test Get-LinkPerformance mezi virtuálním počítačem 1 a virtuálním počítačem 3. Tento test otestuje připojení přes síť Microsoftu až do MSEE a zpět do Azure. Pokud test produkuje přijatelné výsledky latence a šířky pásma, můžete síť Azure označit jako dobrou.

3. Pokud se Azure vyloučí, proveďte podobné testy ve vaší podnikové síti. Pokud jsou tyto testy také dobré, spolupracujte s poskytovatelem služeb nebo poskytovatelem internetových služeb a diagnostikujte připojení WAN. Můžete například spouštět testy mezi dvěma pobočkami nebo mezi vaším stolem a serverem datového centra. Vyhledejte koncové body, jako jsou servery a klientské počítače, které můžou vykonávat cestu, kterou testujete.

Důležité

Pro každý test označte čas dne a poznamenejte si výsledky do společného umístění. Každé testovací spuštění by mělo mít stejný výstup pro konzistentní porovnání dat. Hlavním důvodem použití AzureCT k řešení potíží je konzistence napříč více testy. Klíč pokaždé získává konzistentní test a výstup dat. Zaznamenávání času a konzistentních dat je užitečné zejména v případě, že je problém občasný. Usilovně se s shromažďováním dat vyhněte hodinám opakovaného testování stejných scénářů.

Problém je izolovaný, co teď?

Čím více problém izolujete, tím rychleji se řešení najde. Někdy se dostanete k bodu, kdy se s řešením potíží nemůžete dále pustit. Pokud například očekáváte, že zůstane v Asii, může se zobrazit propojení mezi poskytovatelem služeb, který prochází Evropou. V tomto okamžiku zapojte někoho, kdo vám pomůže v závislosti na doméně směrování, na kterou jste problém izolovali. Zúžení na konkrétní komponentu je ještě lepší.

V případě problémů s podnikovou sítí může interní IT oddělení nebo poskytovatel služeb pomoct s konfigurací zařízení nebo opravou hardwaru.

V případě problémů se sítí WAN sdílejte výsledky testování se svým poskytovatelem služeb nebo poskytovatelem internetových služeb, abyste jim pomohli s jejich prací a vyhnuli se redundantním úlohám. Mohou chtít ověřit vaše výsledky na základě principu důvěryhodnosti, ale ověřit.

Pokud máte problémy s Azure, jakmile problém izolujete co nejpodrobněji, projděte si dokumentaci k síti Azure a v případě potřeby otevřete lístek podpory.

Reference

Očekávání latence a šířky pásma

Tip

Geografická vzdálenost mezi koncovými body je největším faktorem latence. I když latence zařízení (fyzické a virtuální komponenty, počet segmentů směrování atd.) hraje roli, vzdálenost chodu vláken, nikoli přímočará vzdálenost, je primárním přispěvatelem. Tato vzdálenost je obtížné přesně měřit, proto často používáme kalkulačku vzdálenosti města pro hrubý odhad.

Například jsme nastavili ExpressRoute v Seattlu, Washingtonu, USA. Následující tabulka ukazuje latenci a šířku pásma pozorovanou při testování do různých umístění Azure spolu s odhadovanými vzdálenostmi.

Testovací nastavení:

• Fyzický server s Windows Serverem 2016 s síťovým adaptérem 10 Gb/s připojeným k okruhu ExpressRoute.

• Okruh ExpressRoute úrovně Premium 10 Gb/s s povoleným privátním partnerským vztahem.

• Virtuální síť Azure s bránou UltraPerformance v zadané oblasti.

• Virtuální počítač DS5v2 s Windows Serverem 2016 ve virtuální síti s nainstalovanou výchozí imagí Azure.

• Všechny testy používaly příkaz AzureCT Get-LinkPerformance s 5minutovým zátěžovým testem pro každou ze šesti testovacích spuštění. Příklad:

  Get-LinkPerformance -RemoteHost 10.0.0.1 -TestSeconds 300
  

• Tok dat pro každý test byl z místního serveru (klienta iPerf v Seattlu) na virtuální počítač Azure (server iPerf v uvedené oblasti Azure).

• Ve sloupci Latence se zobrazují data z zátěžového testu Bez zátěžového testu (test latence protokolu TCP bez spuštění iPerf).

• Ve sloupci Maximální šířka pásma se zobrazují data z zátěžového testu 16 toku TCP s velikostí okna o velikosti 1 Mb.

Výsledky latence a šířky pásma

Důležité

Tato čísla jsou určena pouze pro obecné odkazy. Latence ovlivňuje mnoho faktorů a zatímco tyto hodnoty jsou v průběhu času obecně konzistentní, můžou se měnit podmínky v rámci sítě poskytovatele služeb nebo sítě poskytovatele služeb, což má vliv na latenci a šířku pásma. Obecně platí, že tyto změny nemají za následek významné rozdíly.

Umístění ExpressRoute	Oblast Azure	Odhadovaná vzdálenost (km)	Latence	1 Šířka pásma relace	Maximální šířka pásma
Seattle	Západní USA 2	191 km	5 ms	262 Mbits/s	3,74 Gbits/s
Seattle	USA – západ	1 094 km	18 ms	82,3 Mbits/s	3,70 Gbits/s
Seattle	USA – střed	2 357 km	40 ms	38,8 Mbits/s	2,55 Gbits/s
Seattle	Středojižní USA	2 877 km	51 ms	30,6 Mbits/s	2,49 Gbits/s
Seattle	Severní střed USA	2 792 km	55 ms	27,7 Mbits/s	2,19 Gbits/s
Seattle	USA – východ 2	3 769 km	73 ms	21,3 Mbits/s	1,79 Gbits/s
Seattle	USA – východ	3 699 km	74 ms	21,1 Mbits/s	1,78 Gbits/s
Seattle	Japonsko – východ	7 705 km	106 ms	14,6 Mbits/s	1,22 Gbits/s
Seattle	Velká Británie – jih	7 708 km	146 ms	10,6 Mbits/s	896 Mbits/s
Seattle	Západní Evropa	7 834 km	153 ms	10,2 Mbits/s	761 Mbits/s
Seattle	Austrálie – východ	12 484 km	165 ms	9,4 Mbits/s	794 Mbits/s
Seattle	Southeast Asia	12 989 km	170 ms	9,2 Mbits/s	756 Mbits/s
Seattle	Brazílie – jih *	10 930 km	189 ms	8,2 Mbits/s	699 Mbits/s
Seattle	Indie – jih	12 918 km	202 ms	7,7 Mbits/s	634 Mbits/s

* Latence do Brazílie je příkladem, kde se vzdálenost mezi vlákny výrazně liší od vzdálenosti přímky. Očekávaná latence by byla přibližně 160 ms, ale ve skutečnosti je to 189 ms kvůli delší optické trase.

Poznámka:

Tato čísla byla testována pomocí AzureCT na základě iPerf ve Windows přes PowerShell. iPerf nedotkne výchozích možností protokolu TCP systému Windows pro faktor škálování a používá nižší počet směn pro velikost okna TCP. Laděním příkazů iPerf s -w přepínačem a větší velikostí okna TCP je možné dosáhnout lepší propustnosti. Spuštění iPerf v režimu s více vlákny z více počítačů může také pomoct dosáhnout maximálního výkonu propojení. Pokud chcete získat nejlepší výsledky iPerf ve Windows, použijte Set-NetTCPSetting -AutoTuningLevelLocal Experimentální. Před provedením jakýchkoli změn zkontrolujte zásady vaší organizace.

Další kroky

• Stažení sady Azure Connectivity Toolkit
• Postupujte podle pokynů pro testování výkonu propojení.