Poznámka:
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
Tento článek popisuje běžné techniky ladění výkonu protokolu TCP/IP a některé věci, které je potřeba zvážit při jejich použití pro virtuální počítače běžící v Azure. Poskytuje základní přehled technik a prozkoumal, jak lze virtuální počítače ladit.
Běžné techniky ladění PROTOKOLU TCP/IP
Snižování zátěže MTU, fragmentace a velkého odesílání
MTU
Maximální přenosová jednotka (MTU) je největší rámec velikosti (paket plus hlavičky síťového přístupu) určený v bajtech, které lze odesílat přes síťové rozhraní. MTU je konfigurovatelné nastavení. Výchozí MTU používané na virtuálních počítačích Azure a výchozí nastavení na většině síťových zařízení globálně je 1 500 bajtů.
Fragmentace
Fragmentace nastane, když se paket odešle, který překračuje MTU síťového rozhraní. Zásobník TCP/IP rozdělí paket na menší části (fragmenty), které odpovídají MTU rozhraní. Fragmentace probíhá ve vrstvě PROTOKOLU IP a je nezávislá na základním protokolu (například TCP). Když se přes síťové rozhraní odešle 2 000 bajtový paket s MTU 1 500, paket se rozdělí do jednoho 1 500 bajtového paketu a jednoho 500 bajtového paketu.
Síťová zařízení v cestě mezi zdrojem a cílem můžou buď zahodit pakety, které překračují MTU, nebo fragmentovat pakety do menších částí.
Bit Ne fragmentovat v paketu PROTOKOLU IP
Bit Don't Fragment (DF) je příznak v hlavičce protokolu IP. Bit DF označuje, že síťová zařízení na cestě mezi odesílatelem a příjemcem nesmí paket fragmentovat. Tento bit může být nastavený z mnoha důvodů. (Příklad najdete v části Zjišťování MTU cesty v tomto článku.) Když síťové zařízení přijme paket s nastaveným bitem Don't Fragment a tento paket překročí MTU rozhraní zařízení, standardní chování zařízení je tento paket vyřadit. Zařízení odešle zprávu ICMP Fragmentation Needed zpět k původnímu zdroji paketu.
Důsledky fragmentace výkonu
Fragmentace může mít negativní dopad na výkon. Jedním z hlavních důvodů vlivu na výkon je efekt fragmentace a opětovného sestavení paketů na využití procesoru a paměti. Pokud síťové zařízení potřebuje fragmentovat paket, musí přidělit prostředky procesoru a paměti, aby bylo možné provést fragmentaci.
Totéž se stane, když se paket znovu sestaví. Síťové zařízení musí ukládat všechny fragmenty, dokud nebudou přijaty, aby je bylo možné znovu sestavit do původního paketu.
Azure a fragmentace
Azure nepracuje s fragmentovanými pakety s akcelerovanými sítěmi. Když virtuální počítač obdrží fragmentovaný paket, nezrychlená cesta jej zpracuje. V důsledku toho fragmentované pakety přicházejí o výhody zrychleného síťového připojení, jako je nižší latence, snížené kolísání a vyšší počet paketů za sekundu. Z tohoto důvodu doporučujeme zabránit fragmentaci, pokud je to možné.
Azure ve výchozím nastavení zahodí fragmentované pakety, které přicházejí na virtuální počítač mimo pořadí, což znamená, že pakety neodpovídají sekvenci přenosu ze zdrojového koncového bodu. K tomuto problému může dojít, když pakety cestují přes internet nebo jiné velké WAN.
Nastavte MTU
Propustnost interní virtuální sítě můžete zlepšit zvýšením MTU provozu virtuálního počítače. Pokud ale virtuální počítač komunikuje s cíli mimo virtuální síť, které mají jinou MTU, může dojít k fragmentaci a snížit výkon.
Další informace o nastavení MTU na virtuálních počítačích Azure najdete v tématu Konfigurace maximální přenosové jednotky (MTU) pro virtuální počítače v Azure.
Velké odlehčení odesílání
Velké snižování zátěže odesílání (LSO) může zlepšit výkon sítě tím, že přesměruje segmentaci paketů na ethernetový adaptér. Při povolení LSO vytvoří zásobník TCP/IP velký paket TCP a odešle ho do ethernetového adaptéru pro segmentaci před jeho předáním. Výhoda LSO spočívá v tom, že uvolní CPU od segmentace paketů do velikostí, které odpovídají MTU, a přesune toto zpracování na hardware ethernetového rozhraní. Další informace o výhodách LSO najdete v sekci Podpora velkého odlehčení odesílání.
Když je povolený LSO, můžou si zákazníci Azure během zachytávání paketů všimnout velkých velikostí snímků. Tyto velikosti rámců můžou způsobit, že někteří zákazníci předpokládají, že dochází k fragmentaci nebo že se používá velké MTU, i když tomu tak není. S LSO může ethernetový adaptér oznamovat větší maximální velikost segmentu (MSS) pro zásobník TCP/IP, aby vytvořil větší paket TCP. Ethernetový adaptér pak rozdělí celý nesegmentovaný rámec na mnoho menších snímků podle mtU, které jsou viditelné v zachytávání paketů prováděném na virtuálním počítači.
Škálování okna TCP MSS a PMTUD
Maximální velikost segmentu PROTOKOLU TCP
Maximální velikost segmentu (MSS) protokolu TCP je nastavení, které omezuje velikost segmentů protokolu TCP, což zabraňuje fragmentaci paketů TCP. Operační systémy obvykle používají tento vzorec k nastavení MSS:
MSS = MTU - (IP header size + TCP header size)
Hlavička PROTOKOLU IP a hlavička TCP jsou 20 bajtů z každého nebo 40 bajtů celkem. Rozhraní s MTU 1 500 má MSS 1 460. Služba MSS je konfigurovatelná.
Toto nastavení je dohodnuto během trojcestného handshake protokolu TCP při nastavení relace TCP mezi zdrojem a cílem. Obě strany odesílají hodnotu MSS a nižší z těchto dvou se použije pro připojení TCP.
Mějte na paměti, že MTU zdroje a cíle nejsou jedinými faktory, které určují hodnotu MSS. Zprostředkující síťová zařízení, jako jsou brány VPN, včetně služby Azure VPN Gateway, můžou upravit MTU nezávisle na zdroji a cíli, aby se zajistil optimální výkon sítě.
Zjišťování MTU cesty
MSS je dohodnuto, ale nemusí označovat skutečné MSS, které lze použít. Jiná síťová zařízení v cestě mezi zdrojem a cílem můžou mít nižší hodnotu MTU než zdroj a cíl. V tomto případě zařízení, jehož MTU je menší než paket zahodí paket. Zařízení odešle zpět zprávu o potřebě fragmentace PROTOKOLU ICMP (typ 3, kód 4), která obsahuje její MTU. Tato zpráva ICMP umožňuje zdrojovému hostiteli odpovídajícím způsobem snížit MTU cesty. Proces se nazývá Path MTU Discovery (PMTUD).
Proces PMTUD snižuje výkon sítě kvůli neefektivitě. Pokud dojde k překročení MTU síťové cesty, musí se pakety znovu přeposílat s nižším msS. Pokud síťová brána firewall blokuje zprávu o potřebě fragmentace ICMP, odesílatel není si vědom potřeby snížit MSS a opakovaně přeposílá paket. Z tohoto důvodu nedoporučujeme zvyšovat MTU virtuálního počítače Azure.
VPN a MTU
Pokud používáte virtuální počítače, které provádějí zapouzdření (jako jsou sítě VPN IPsec), existují některé další aspekty týkající se velikosti paketů a MTU. Sítě VPN přidávají do paketů další hlavičky. Přidané hlavičky zvětší velikost paketu a vyžadují menší MSS.
Pro Azure doporučujeme nastavit limitaci TCP MSS na 1 350 bajtů a MTU tunelového rozhraní na 1 400. Další informace najdete na stránce s parametry sítě VPN a protokolu IPsec/IKE.
Latence, doba odezvy a škálování oken TCP
Latence a doba zpáteční cesty
Rychlost světla určuje latenci sítě prostřednictvím optické sítě. Doba odezvy (RTT) mezi dvěma síťovými zařízeními řídí propustnost sítě TCP.
| Trasa | Vzdálenost | Jednosměrný čas | RTT |
|---|---|---|---|
| New York a San Francisco | 4 148 km | 21 ms | 42 ms |
| Z New Yorku do Londýna | 5 585 km | 28 ms | 56 ms |
| z New Yorku do Sydney | 15 993 km | 80 ms | 160 ms |
Tato tabulka zobrazuje přímočarou vzdálenost mezi dvěma umístěními. V sítích je vzdálenost obvykle delší než přímá vzdálenost. Tady je jednoduchý vzorec pro výpočet minimální hodnoty RTT, který se řídí rychlostí světla:
minimum RTT = 2 * (Distance in kilometers / Speed of propagation)
Pro rychlost šíření můžete použít 200. Rychlost šíření je vzdálenost, v kilometrech, která světlo cestuje v 1 milisekundách.
Jako příklad si vezmeme New York do San Francisca. Přímá vzdálenost je 4 148 km. Zadáním této hodnoty do rovnice vznikne následující rovnice:
Minimum RTT = 2 * (4,148 / 200)
Výstup rovnice je v milisekundách.
Pokud chcete dosáhnout nejlepšího výkonu sítě, logickou možností je vybrat cíle s nejkratší vzdáleností mezi nimi. Měli byste také navrhnout virtuální síť tak, aby optimalizovala cestu provozu a snížila latenci. Další informace najdete v části Aspekty návrhu sítě v tomto článku.
Latence a vliv doby obousměrného přenosu na TCP
Doba odezvy má přímý vliv na maximální propustnost PROTOKOLU TCP. V protokolu TCP je velikost okna maximální objem provozu, který lze odeslat přes připojení TCP předtím, než odesílatel potřebuje přijmout potvrzení od příjemce. Pokud je tcp MSS nastaven na 1 460 a velikost okna TCP je nastavena na 65 535, odesílatel může odeslat 45 paketů před potvrzením od příjemce. Pokud odesílatel potvrzení nezíská, přepošle data znovu. Tento vzorec vypadá takto:
TCP window size / TCP MSS = packets sent
V tomto příkladu je 65 535 / 1 460 zaokrouhleno nahoru na 45.
Tento stav čekání na potvrzení, což je mechanismus pro zajištění spolehlivého doručování dat, je to, co způsobí, že RTT ovlivní propustnost protokolu TCP. Čím déle odesílatel čeká na potvrzení, tím déle musí před odesláním dalších dat počkat.
Tady je vzorec pro výpočet maximální propustnosti jednoho připojení TCP:
Window size / (RTT latency in milliseconds / 1,000) = maximum bytes/second
Tato tabulka ukazuje maximální propustnost megabajtů za sekundu jednoho připojení TCP. (Pro čitelnost se megabajty používají pro jednotku měření.)
| Velikost okna PROTOKOLU TCP (bajty) | Latence RTT (ms) | Maximální propustnost megabajtu/sekundy | Maximální propustnost megabitů/sekund |
|---|---|---|---|
| 65,535 | 1 | 65.54 | 524.29 |
| 65,535 | 30 | 2.18 | 17.48 |
| 65,535 | 60 | 1.09 | 8.74 |
| 65,535 | 90 | 0.73 | 5,83 |
| 65,535 | 120 | 0.55 | 4.37 |
Pokud dojde ke ztrátě paketů, sníží se maximální propustnost připojení TCP při opakovaném přenosu dat odesílaných odesílatelem.
Škálování okna PROTOKOLU TCP
Škálování okna TCP je technika, která dynamicky zvyšuje velikost okna TCP, aby bylo možné odeslat více dat před potvrzením. V předchozím příkladu by se před vyžadování potvrzení odeslalo 45 paketů. Pokud zvýšíte počet paketů, které je možné odeslat před potvrzením, snížíte počet, kolikrát odesílatel čeká na potvrzení.
Tato tabulka znázorňuje tyto relace:
| Velikost okna PROTOKOLU TCP (bajty) | Latence RTT (ms) | Maximální propustnost megabajtu/sekundy | Maximální propustnost megabitů/sekund |
|---|---|---|---|
| 65,535 | 30 | 2.18 | 17.48 |
| 131,070 | 30 | 4.37 | 34.95 |
| 262,140 | 30 | 8.74 | 69.91 |
| 524,280 | 30 | 17.48 | 139.81 |
Hodnota hlavičky TCP pro velikost okna TCP je ale jenom 2 bajty dlouhá, což znamená, že maximální hodnota pro okno příjmu je 65 535. Pokud chcete zvětšit maximální velikost okna, zavedl se faktor škálování oken TCP.
Faktor škálování je také nastavení, které můžete nakonfigurovat v operačním systému. Tady je vzorec pro výpočet velikosti okna PROTOKOLU TCP pomocí faktorů škálování:
TCP window size = TCP window size in bytes * (2^scale factor)
Tady je výpočet faktoru měřítka okna 3 a velikosti okna 65 535:
65,535 * (2^3) = 524,280 bytes
Faktor měřítka 14 vede k velikosti okna TCP 14 (maximální povolený posuv). Velikost okna TCP je 1 073 725 440 bajtů (8,5 gigabitů).
Podpora škálování oken PROTOKOLU TCP
Systém Windows může pro různé typy připojení nastavit různé faktory škálování. (Třídy připojení zahrnují datacentrum, internet atd.) Pomocí příkazu PowerShellu Get-NetTCPConnection zobrazíte typ připojení škálování okna:
Get-NetTCPConnection
K zobrazení hodnot jednotlivých tříd můžete použít Get-NetTCPSetting příkaz PowerShellu:
Get-NetTCPSetting
Počáteční velikost okna TCP a faktor škálování protokolu TCP ve Windows můžete nastavit pomocí příkazu PowerShellu Set-NetTCPSetting . Další informace naleznete v tématu Set-NetTCPSetting.
Set-NetTCPSetting
Následující hodnoty jsou efektivní nastavení protokolu TCP pro AutoTuningLevel:
| Úroveň automatického ladění | Faktor škálování | Škálovací násobitel | Vzorec do výpočet maximální velikosti okna |
|---|---|---|---|
| Deaktivováno | Nic | Nic | Velikost okna |
| Omezeno | 4 | 2^4 | Velikost okna * (2^4) |
| Vysoce omezený | 2 | 2^2 | Velikost okna * (2^2) |
| Normální | 8 | 2^8 | Velikost okna * (2^8) |
| Experimentální | 14 | 2^14 | Velikost okna * (2^14) |
Tato nastavení mají největší pravděpodobnost vliv na výkon protokolu TCP, ale mějte na paměti, že mnoho dalších faktorů přes internet, mimo kontrolu Azure, může také ovlivnit výkon protokolu TCP.
Podporované síťování a škálování na straně příjmu dat
Akcelerované síťové služby
Síťové funkce virtuálních počítačů jsou historicky náročné na procesor na hostovaném virtuálním počítači i na hostiteli nebo hypervisoru. Procesor hostitele zpracovává v softwaru všechny pakety, které procházejí hostitelem, včetně veškerého zapouzdření a rozbalení virtuální sítě. Čím více provozu prochází hostitelem, tím vyšší je zatížení procesoru. Pokud je procesor hostitele zaneprázdněn jinými operacemi, které mají vliv na propustnost a latenci sítě. Azure tento problém řeší s akcelerovanými síťovými službami.
Akcelerované síťování poskytuje konzistentní ultra nízkou latenci sítě prostřednictvím interního programovatelného hardwaru Azure a technologií, jako je SR-IOV. Akcelerované síťové služby přesunují většinu softwarově definovaného síťového zásobníku Azure z procesorů a do inteligentních síťových adaptérů založených na FPGA. Tato změna umožňuje aplikacím koncových uživatelů uvolnit výpočetní cykly, které na virtuálním počítači snižují zpoždění a nekonzistenci latence. Jinými slovy, výkon může být determinističtější.
Akcelerované síťové služby zvyšují výkon tím, že hostovanému virtuálnímu počítači umožňují obejít hostitele a vytvořit datovou cestu přímo s čipovou síťí hostitele. Tady jsou některé výhody akcelerovaných síťových služeb:
Nižší latence / vyšší pakety za sekundu (pps): Odebrání virtuálního přepínače z datové cesty eliminuje čas, který pakety stráví v hostitelském systému pro zpracování zásad a zvýšení počtu paketů, které mohou být zpracovány v rámci virtuálního počítače.
Menší zpoždění: Zpracování virtuálního přepínače závisí na množství zásad, které je potřeba použít, a na úloze procesoru, který provádí zpracování. Přesměrování vynucení zásad na hardware odstraní tuto variabilitu tím, že přímo doručí pakety do virtuálního počítače, čímž eliminuje komunikaci mezi hostitelem a virtuálním počítačem i všechna softwarová přerušení a přepínání kontextu.
Menší využití procesoru: Obejití virtuálního přepínače v hostiteli vede k menšímu využití procesoru pro zpracování síťového provozu.
Pokud chcete používat akcelerované síťové služby, musíte ho explicitně povolit na každém příslušném virtuálním počítači. Pokyny najdete v tématu Vytvoření virtuálního počítače s Linuxem s akcelerovanými síťovými službami .
Škálování na straně příjmu
Škálování na straně příjmu (RSS) je technologie síťového ovladače, která distribuuje příjem síťového provozu efektivněji tím, že distribuuje zpracování příjmu napříč několika procesory v multiprocesorovém systému. Rss jednoduše řečeno umožňuje systému zpracovávat více přijatých přenosů, protože používá všechny dostupné procesory místo jenom jednoho. Podrobnější diskuzi o technologii RSS najdete v tématu Úvod k škálování na straně příjmu.
Pokud chcete dosáhnout nejlepšího výkonu při povolení akcelerovaných síťových služeb na virtuálním počítači, musíte povolit rss. Rss může také poskytovat výhody na virtuálních počítačích, které nepoužívají akcelerované síťové služby. Přehled toho, jak zjistit, jestli je technologie RSS povolená a jak ji povolit, najdete v tématu Optimalizace propustnosti sítě pro virtuální počítače Azure.
"TCP TIME_WAIT a ukončení TIME_WAIT"
TIME_WAIT TCP je dalším běžným nastavením, které má vliv na výkon sítě a aplikací. Zaneprázdněné virtuální počítače často otevírají a zavírají mnoho soketů, a to buď jako klienti nebo servery. Během normálních operací TCP často soket vstupuje do TIME_WAIT stavu a zůstává tam po delší dobu. Tento stav zajišťuje doručení všech zbývajících dat do soketu před jeho uzavřením. V důsledku toho zásobníky TCP/IP obvykle brání opakovanému použití soketu tím, že paket TCP SYN klienta vyřazuje tiše.
Můžete nakonfigurovat, jak dlouho soket zůstane v TIME_WAIT stavu. Doba trvání může být v rozsahu od 30 sekund do 240 sekund. Sokety jsou omezeným zdrojem a jejich dostupnost lze upravit. Obvykle je v daném okamžiku k dispozici přibližně 30 000 zásuvek. Pokud systém využívá všechny dostupné sokety nebo pokud klienti a servery používají neodpovídající nastavení TIME_WAIT, může se virtuální počítač pokusit znovu použít soket stále v TIME_WAIT stavu. V takových případech nová připojení selžou, protože pakety TCP SYN se bezobslužně zahodí.
Hodnota rozsahu portů pro odchozí sokety je konfigurovatelná v rámci zásobníku TCP/IP operačního systému. Totéž platí pro nastavení tcp TIME_WAIT a opětovné použití soketu. Změna těchto čísel může potenciálně zlepšit škálovatelnost. V závislosti na situaci ale tyto změny můžou způsobit problémy s interoperabilitou. Pokud tyto hodnoty změníte, měli byste být opatrní.
K řešení tohoto omezení škálování můžete použít odstranění TIME_WAIT. Odstranění TIME_WAIT umožňuje v určitých situacích opětovné použití socketu, například když pořadové číslo v IP paketu nového připojení překračuje pořadové číslo posledního paketu z předchozího připojení. V tomto případě operační systém umožňuje navázat nové připojení (přijímá nový SYN/ACK) a vynutit zavření předchozího připojení, které bylo v TIME_WAIT stavu. Tato funkce je podporovaná na virtuálních počítačích s Windows v Azure. Pokud se chcete dozvědět o podpoře v jiných virtuálních počítačích, obraťte se na dodavatele operačního systému.
Další informace o konfiguraci nastavení TIME_WAIT protokolu TCP a rozsahu zdrojových portů najdete v tématu Nastavení, která se dají upravit, aby se zlepšil výkon sítě.
Faktory virtuální sítě, které můžou ovlivnit výkon
Maximální odchozí propustnost virtuálního počítače
Azure poskytuje různé velikosti a typy virtuálních počítačů, z nichž každá má jinou kombinaci možností výkonu. Jednou z těchto funkcí je propustnost sítě (nebo šířka pásma), která se měří v megabitech za sekundu (Mb/s). Vzhledem k tomu, že virtuální počítače jsou hostované na sdíleném hardwaru, musí se síťová kapacita sdílet mezi virtuálními počítači, které používají stejný hardware. Větší virtuální počítače mají přidělenou větší šířku pásma než menší virtuální počítače.
Šířka pásma sítě přidělená každému virtuálnímu počítači se měří u odchozího (odchozího) provozu z virtuálního počítače. Veškerý síťový provoz, který opouští virtuální počítač, se počítá do přiděleného limitu bez ohledu na cíl. Pokud má virtuální počítač limit 1 000 Mb/s, platí tento limit, jestli je odchozí provoz určený pro jiný virtuální počítač ve stejné virtuální síti nebo pro jeden mimo Azure.
Příchozí přenos dat se neměří ani přímo neomezuje. Existují ale další faktory, jako jsou limity procesoru a úložiště, které můžou ovlivnit schopnost virtuálního počítače zpracovávat příchozí data.
Akcelerované síťové služby jsou navržené tak, aby zlepšily výkon sítě, včetně latence, propustnosti a využití procesoru. Akcelerované síťové služby můžou zvýšit propustnost virtuálního počítače, ale můžou to udělat až do přidělené šířky pásma virtuálního počítače.
Virtuální počítače Azure mají připojené aspoň jedno síťové rozhraní. Může jich být několik. Šířka pásma přidělená virtuálnímu počítači je součet veškerého odchozího provozu napříč všemi síťovými rozhraními připojenými k počítači. Jinými slovy, šířka pásma se přiděluje na základě jednotlivých virtuálních počítačů bez ohledu na to, kolik síťových rozhraní je k počítači připojené.
Očekávaná odchozí propustnost a počet síťových rozhraní podporovaných jednotlivými velikostmi virtuálních počítačů jsou podrobně popsány ve velikostech virtuálních počítačů s Windows v Azure. Pokud chcete zobrazit maximální propustnost, vyberte typ, například pro obecné účely, a pak na výsledné stránce najděte oddíl o řadě velikostí (například Dv2-series). Pro každou řadu je zde tabulka, která v posledním sloupci, jejíž název je "Max. počet síťových karet / Očekávaná šířka pásma sítě (Mbps)", poskytuje specifikace sítí.
Limit propustnosti se vztahuje na virtuální počítač. Propustnost není ovlivněná těmito faktory:
Počet síťových rozhraní: Omezení šířky pásma se vztahuje na součet veškerého odchozího provozu z virtuálního počítače.
Akcelerované síťové služby: I když tato funkce může být užitečná při dosažení publikovaného limitu, limit se nezmění.
Destinace přenosu: Všechny cíle se započítávají do limitu odchozího přenosu.
Protokol: Veškerý odchozí provoz přes všechny protokoly se počítá do limitu.
Další informace najdete v tématu Šířka pásma sítě virtuálních počítačů.
Optimalizace virtuálních počítačů s Linuxem
Moderní linuxová jádra mají funkce, které můžou pomoct dosáhnout konzistence a výkonu, někdy vyžadovaných určitými úlohami.
Další informace najdete v tématu Optimalizace šířky pásma sítě na virtuálních počítačích Azure.
Důležité informace o výkonu internetu
Jak je popsáno v tomto článku, faktory na internetu a mimo kontrolu Azure můžou ovlivnit výkon sítě. Tady jsou některé z těchto faktorů:
Latence: Doba odezvy mezi dvěma koncovými body je ovlivněna problémy v mezilehlých sítích, přenosem, který nebere nejkratší možnou cestu, a neoptimálními peeringovými cestami.
Ztráta paketů: Ztráta paketů je způsobena zahlcením sítě, problémy s fyzickou cestou a pod výkonem síťových zařízení.
Velikost/fragmentace MTU: Fragmentace na cestě může vést ke zpoždění při doručení dat nebo k tomu, že pakety přicházejí v nesprávném pořadí, což může ovlivnit doručení paketů.
Traceroute je vhodný nástroj pro měření charakteristik výkonu sítě (jako je ztráta paketů a latence) podél každé síťové cesty mezi zdrojovým zařízením a cílovým zařízením.
Aspekty návrhu sítě
Spolu s aspekty, které jsme si probrali dříve v tomto článku, může topologie virtuální sítě ovlivnit výkon sítě. Například návrh s centrálním bodem a paprsky, který přenáší provoz globálně do virtuální sítě s jedním centrem, způsobuje latenci sítě, která ovlivňuje celkový výkon sítě.
Počet síťových zařízení, která síťový provoz prochází, může také ovlivnit celkovou latenci. Pokud provoz prochází síťovým virtuálním zařízením ve spojovací síti a centrálním virtuálním zařízením před odchodem na internet, síťová virtuální zařízení v návrhu hvězdicové sítě přidávají určitou latenci.
Oblasti Azure, virtuální sítě a latence
Oblasti Azure se skládají z několika datacenter, která existují v rámci obecné geografické oblasti. Tato datová centra nemusí být fyzicky vedle sebe. V některých případech jsou oddělené až o 10 kilometrů. Virtuální síť je logické překrytí nad fyzickou sítí datového centra Azure. Virtuální síť neznamená žádnou konkrétní topologii sítě v datovém centru.
Například dva virtuální počítače, které jsou ve stejné virtuální síti a podsíti, můžou být v různých rackech, řadách nebo dokonce datových centrech. Mohou být odděleny stopami optického kabelu nebo kilometry optického kabelu. Tato varianta může představovat proměnlivou latenci (několik milisekund) mezi různými virtuálními počítači.
Geografické umístění virtuálních počítačů a potenciální výsledná latence mezi dvěma virtuálními počítači je ovlivněno konfigurací skupin dostupnosti, skupin umístění v blízkosti a zón dostupnosti. Vzdálenost mezi datovými centry v oblasti je specifická pro jednotlivé oblasti a primárně je ovlivněná topologií datacentra v dané oblasti.
Vyčerpání portů zdrojového překladu adres (NAT)
Nasazení v Azure může komunikovat s koncovými body mimo Azure na veřejném internetu nebo ve veřejném prostoru IP adres. Když instance zahájí odchozí připojení, Azure dynamicky mapuje privátní IP adresu na veřejnou IP adresu. Jakmile Azure toto mapování vytvoří, může návratový provoz pro odchozí tok také dosáhnout privátní IP adresy, ze které tok pochází.
Pro každé odchozí připojení musí Azure Load Balancer toto mapování udržovat po určitou dobu. Díky víceklientní povaze Azure může být údržba tohoto mapování pro každý odchozí tok pro každý virtuální počítač náročná na prostředky. Existují tedy omezení, která jsou nastavená a založená na konfiguraci služby Azure Virtual Network. Nebo přesněji řečeno, virtuální počítač Azure může v daném okamžiku provádět jenom některá odchozí připojení. Po dosažení těchto limitů virtuální počítač nevyutvá více odchozích připojení.
Toto chování je ale možné konfigurovat. Další informace o SNAT a vyčerpání portů SNAT najdete v tomto článku.
Měření výkonu sítě v Azure
Řada maximálních výkonů v tomto článku souvisí s latencí sítě / dobou odezvy (RTT) mezi dvěma virtuálními počítači. Tato část obsahuje několik návrhů, jak otestovat latenci nebo RTT a jak otestovat výkon protokolu TCP a výkon sítě virtuálních počítačů. Hodnoty TCP/IP a sítě popsané výše můžete vyladit a otestovat výkon pomocí technik popsaných v této části. Zadejte hodnoty latence, MTU, MSS a velikosti okna do výpočtů uvedených dříve a porovnejte teoretická maxima se skutečnými hodnotami pozorovanými během testování.
Měření doby zpáteční cesty a ztráty paketů
Výkon protokolu TCP je silně závislý na rtT a ztrátě paketů. Nástroj PING dostupný ve Windows a Linuxu poskytuje nejjednodušší způsob měření RTT a ztráty paketů. Výstup příkazu PING ukazuje minimální/maximální/průměrnou latenci mezi zdrojem a cílem. Zobrazuje ztrátu paketů. Příkaz PING ve výchozím nastavení používá protokol ICMP. K otestování protokolu TCP RTT můžete použít nástroj PsPing. Další informace najdete v tématu PsPing.
Protokoly ICMP a TCP ping neměří akcelerovanou síťovou cestu k datům. Pokud chcete měřit cestu k datům, přečtěte si informace o Latte a SockPerf v tomto článku.
Měření skutečné šířky pásma virtuálního počítače
Pokud chcete přesně měřit šířku pásma virtuálních počítačů Azure, postupujte podle těchto pokynů.
Další informace o testování jiných scénářů najdete v těchto článcích:
Detekce neefektivního chování protokolu TCP
V zachytávání paketů můžou zákazníci Azure vidět pakety TCP s příznaky TCP (SACK, DUP ACK, RETRANSMIT a FAST RETRANSMIT), které by mohly značit problémy s výkonem sítě. Tyto pakety konkrétně označují nedostatky sítě, které jsou výsledkem ztráty paketů. Ztrátu paketů ale nemusí nutně způsobovat problémy s výkonem Azure. Problémy s výkonem můžou být výsledkem aplikací, operačního systému nebo jiných problémů, které nemusí přímo souviset s platformou Azure.
Mějte také na paměti, že některé opakované přenosy a duplicitní ACKy jsou běžné v síti. Protokoly TCP byly vytvořeny tak, aby byly spolehlivé. Důkazy o těchto paketech TCP v zachytávání paketů nemusí nutně znamenat systémový problém se sítí, pokud nejsou nadměrné.
Přesto jsou tyto typy paketů indikací, že propustnost protokolu TCP nedosáží maximálního výkonu z důvodů probíraných v jiných částech tohoto článku.
Další kroky
Teď, když jste se seznámili s laděním výkonu protokolu TCP/IP pro virtuální počítače Azure, zvažte prozkoumání dalších faktorů pro plánování virtuálních sítí. Můžete se také dozvědět více o připojení a konfiguraci virtuálních sítí.