Ř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. Malí i velcí zákazníci při provozu svých firem v Azure úspěšně využívají metody jako site-to-site VPN nebo ExpressRoute. 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í.

Naučíte se snadno a konzistentně testovat latenci sítě a šířku pásma mezi dvěma hostiteli. Také vám poskytneme několik rad, 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, 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)

Když se podíváme na diagram zprava doleva, probereme stručně 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á z nich a jaká pravidla jsou k této podsíti přidružená.

• Skupina zabezpečení sítě podsítě – stejně jako síťová karta, skupiny zabezpečení sítě se dají použít i v podsíti. 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ých adaptérů. 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ů, použije se 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ě. Často je 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.

Pro pomoc s řešením potíží byla vyvinuta sada Azure Připojení ivity 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 tak, že soubory zopořádáte 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 Připojení ivity

Modul AzureCT PowerShellu má dvě komponenty Testování dostupnosti a Testování výkonu. Tento dokument se zabývá pouze testováním výkonu, takže se v tomto modulu PowerShellu zaměříme na dva příkazy výkonu propojení.

Existují 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 modul PowerShellu a nainstaluje ho místně.

2. Nainstalujte podpůrné aplikace.

   Install-LinkPerformance
   

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

3. Spusťte test výkonnosti.

   Nejprve na vzdáleném hostiteli musíte nainstalovat a spustit iPerf v režimu serveru. Také se ujistěte, ž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. Příkaz nastaví iPerf a pravidla brány firewall potřebná k úspěšnému spuštění iPerf v režimu serveru.

   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é vám pomůžou odhadnout kapacitu šířky pásma a latenci síťového propojení.

4. Zkontrolujte výstup testů.

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

   

   Podrobné výsledky všech testů iPerf a PSPing jsou v jednotlivých textových souborech v adresáři nástrojů AzureCT v adresáři C:\ACTTools.

Řešení problému

Pokud vám test výkonnosti neuděluje očekávané výsledky, zjistěte, proč by měl být progresivní krok za krokem. Vzhledem k počtu komponent v cestě poskytuje systematický přístup rychlejší cestu k řešení než přeskakování. Díky systematicky odstraňování potíží můžete zabránit zbytečnému testování vícekrát.

Poznámka:

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

Nejdřív vyzývejte své předpoklady. Je vaše očekávání rozumné? Pokud máte například okruh ExpressRoute s rychlostí 1 Gb/s a latenci 100 ms. Není rozumné očekávat plný provoz o velikosti 1 Gb/s vzhledem k výkonovým charakteristikám protokolu TCP oproti propojením s vysokou latencí. Další informace o předpokladech výkonu najdete v části Reference.

Dále doporučujeme začít na hranách mezi doménami směrování a pokusit se izolovat problém s jedinou hlavní doménou směrování. Můžete začít podnikovou sítí, sítí WAN nebo sítí Azure. Lidé často obviňovat "černou skříňku" v cestě. I když je obviňování černé skříňky snadné, může výrazně zpozdit řešení. Zvlášť pokud je problém v oblasti, kterou můžete změnit, aby se problém vyřešil. Před předáním poskytovateli služeb nebo poskytovateli internetových služeb se ujistěte, že provádíte svoji důkladnou kontrolu.

Jakmile identifikujete hlavní doménu směrování, která se zdá, že problém obsahuje, měli byste vytvořit diagram dané oblasti. Při kreslení diagramu můžete metodicky pracovat a izolovat problém. Můžete naplánovat testovací body a aktualizovat mapu, jakmile vymažete oblasti nebo se podrobněji ponoříte do průběhu testování.

Teď, když máte diagram, začněte rozdělovat síť do segmentů a zúžit problém dolů. Zjistěte, kde funguje a kde ne. Přesuňte testovací body tak, aby se izolovaly směrem dolů do komponenty pro odsunutí.

Nezapomeňte se také podívat na další vrstvy modelu OSI. Je snadné se zaměřit na síť a vrstvy 1 – 3 (fyzické, datové a síťové vrstvy), ale problémy můžou být také ve vrstvě 7 v aplikační vrstvě. Mějte otevřenou mysl a ověřte předpoklady.

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

Pokud si nejste jistí, kde je skutečně okraj cloudu, může být izolace komponent Azure výzvou. Když se použije ExpressRoute, hraniční zařízení je síťová komponenta s názvem Microsoft Enterprise Edge (MSEE). Při použití ExpressRoute je MSEE prvním kontaktním bodem v síti Microsoftu a posledním segmentem směrování při opuštění sítě Microsoftu. Když vytvoříte objekt připojení mezi bránou virtuální sítě a okruhem ExpressRoute, ve skutečnosti vytváříte připojení k MSEE. Rozpoznávání MSEE jako prvního nebo posledního segmentu směrování v závislosti na tom, ve kterém směru je provoz zásadní pro izolování problému se sítí Azure. Znalost toho, který směr ukazuje, jestli je problém v Azure nebo v další podřízené síti v síti WAN nebo v podnikové síti.

Poznámka:

Všimněte si, že MSEE není v cloudu Azure. ExpressRoute je ve skutečnosti na okraji sítě Microsoftu, která ve skutečnosti není v Azure. Jakmile se připojíte s ExpressRoute k MSEE, budete připojení k síti Microsoftu, odtud můžete přejít na některou z cloudových služeb, 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í řady 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í nebo ne. Pokud tento 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 tento test produkuje přijatelné výsledky latence a šířky pásma, můžete síť Azure označit jako dobrou.

3. Pokud se v Azure vyloučí, můžete v podnikové síti provést podobnou sekvenci testů. Pokud se to také dobře otestuje, je čas s poskytovatelem služeb nebo poskytovatelem internetových služeb diagnostikovat připojení WAN. Příklad: Spusťte tento test mezi dvěma pobočkami nebo mezi vaším stolem a serverem datového centra. V závislosti na tom, co testujete, vyhledejte koncové body, jako jsou servery a klientské počítače, které můžou tuto cestu vykonávat.

Důležité

Je důležité, aby každý test označil čas, kdy test spustíte, a zaznamenával výsledky do společného umístění. Každá testovací běh by měla mít stejný výstup, abyste mohli porovnat výsledná data napříč testovacími běhy a neměli v datech "díry". Hlavním důvodem, proč k řešení potíží používáme AzureCT, je konzistence napříč více testy. Magie není ve scénářích přesného zatížení, které spouštíme, ale magie je skutečnost, že z každého testu získáme konzistentní test a výstup dat. Zaznamenávání času a konzistentních dat pokaždé je užitečné zejména v případě, že později zjistíte, že problém je občasný. Usilovně se shromažďováním dat vyhnete hodinám opětovného testování stejných scénářů.

Problém je izolovaný, co teď?

Čím více problém izolujete, tím rychleji řešení najdete. Někdy se dostanete k bodu, kdy se s řešením potíží nemůžete nijak dále spojit. Uvidíte například odkaz na poskytovatele služeb, který prochází Evropou, ale očekáváte, že cesta zůstane v Asii. V tuto chvíli byste se měli obrátit na někoho, kdo by vám pomohl. Kdo dotaz závisí na doméně směrování, na kterou problém izolujete. Pokud ji můžete zúžit na konkrétní komponentu, která by byla 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.

Osvědčeným postupem při řešení potíží se sítí WAN je sdílení výsledků testování s poskytovatelem služeb nebo poskytovatelem internetových služeb, protože to jim může pomoct s jejich prací. Výsledky testů se také můžou vyhnout dalšímu provádění stejných úkolů, které jste už udělali. Mohou se ale chtít podívat na výsledky sami. To je založeno na principu důvěryhodnosti, ale ověření.

Jakmile problém v Azure izolujete co nejvíce podrobností, je čas si projít dokumentaci k síti Azure a v případě potřeby otevřít lístek podpory.

Odkazy

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

Tip

Geografická latence (míle nebo kilometry) mezi koncovými body, které testujete, je zdaleka největší součástí latence. I když existuje latence zařízení (fyzické a virtuální komponenty, počet segmentů směrování atd.), zeměpis se ukázal jako největší komponenta celkové latence při práci s připojeními WAN. Je také důležité si uvědomit, že vzdálenost je vzdálenost vlákna běžet ne přímočarou nebo silniční mapou vzdálenost. Tato vzdálenost je neuvěřitelně těžké získat s jakoukoli přesností. V důsledku toho obecně používáme kalkulačku vzdálenosti města na internetu a víme, že tato metoda je hrubě nepřesná míra, ale stačí k nastavení obecného očekávání.

Máme například nastavení ExpressRoute v Seattlu, Washingtonu v USA. Následující tabulka ukazuje latenci a šířku pásma, které jsme viděli při testování na různých místech Azure. Odhadli jsme geografickou vzdálenost mezi každým koncem testu.

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 v umístění označeném 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. Virtuální počítač nebyl připojený k doméně, vytvořený z výchozí image Azure (bez optimalizace nebo přizpůsobení) s nainstalovanou službou AzureCT.

• Všechny testy používají 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 měl tok zatížení z místního fyzického serveru (klienta iPerf v Seattlu) až do virtuálního počítače Azure (server iPerf v uvedené oblasti Azure).

• Data ve sloupci Latence pocházejí z testu Bez zatížení (test latence protokolu TCP bez spuštění iPerf).

• Data sloupce Maximální šířka pásma pocházejí 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. Mnoho faktorů ovlivňuje latenci a zatímco tyto hodnoty jsou v průběhu času obecně konzistentní, podmínky v síti Azure nebo poskytovatelé služeb můžou kdykoli odesílat provoz prostřednictvím různých cest, což může mít vliv na latenci a šířku pásma. Obecně platí, že účinky těchto změn nemají za následek významné rozdíly.

ExpressRoute Umístění	Azure Oblast	Odhadnuto Vzdálenost (km)	Latence	1 Relace Šířka pásma	Maximum Šířka pásma
Seattle	USA – západ 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	Jihovýchodní Asie	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 dobrým příkladem, kde se přímá vzdálenost výrazně liší od vzdálenosti běhu vláken. Očekávaná latence by byla v sousedství 160 ms, ale ve skutečnosti je 189 ms. Zdá se, že rozdíl v latenci někde značí problém se sítí. Ale realita je, že vlákno linky nejdou do Brazílie v rovné přímce. Takže byste měli očekávat další 1 000 km cesty do Brazílie z Seattlu.

Poznámka:

I když by se tato čísla měla vzít v úvahu, testovaly se pomocí AzureCT, která je založená na IPERF ve Windows prostřednictvím PowerShellu. V tomto scénáři IPERF nedotkne výchozích možností protokolu TCP systému Windows pro Scaling Factor a používá mnohem nižší počet směn pro velikost okna TCP. Zde reprezentovaná čísla byla provedena pomocí výchozích hodnot IPERF a jsou určena pouze pro obecné odkazy. Laděním příkazů IPERF s přepínačem -w a velkou velikostí okna TCP je možné dosáhnout lepší propustnosti v dlouhých vzdálenostech, což ukazuje výrazně lepší hodnoty propustnosti. Pokud chcete zajistit, aby ExpressRoute používal celou šířku pásma, je ideální spustit IPERF ve vícevláknových možnostech z více počítačů současně, aby se zajistilo, že výpočetní kapacita dokáže dosáhnout maximálního výkonu propojení a není omezena kapacitou zpracování jednoho virtuálního počítače. 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 Připojení ivity Toolkit
• Postupujte podle pokynů pro testování výkonu propojení.