Ladění výkonu protokolu TCP/IP pro virtuální počítače Azure
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. Poskytne základní přehled technik a prozkoumá, jak je lze 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), který je 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 se sadou Bit Don't Fragment a tento paket překročí mtU rozhraní zařízení, je standardní chování zařízení, aby paket vyhodil. Zařízení odešle zprávu Typu fragmentace PROTOKOLU ICMP zpět do původního zdroje paketu.
Důsledky fragmentace výkonu
Fragmentace může mít negativní dopad na výkon. Jedním z hlavních důvodů z hlediska výkonu je dopad fragmentace procesoru a paměti na fragmentaci a opětovné sestavení paketů. Pokud síťové zařízení potřebuje fragmentovat paket, bude muset 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
Akcelerované síťové služby nezpracovávají fragmentované pakety v Azure. Když virtuální počítač obdrží fragmentovaný paket, zpracuje se prostřednictvím nerychlované cesty. To znamená, že fragmentované pakety nebudou mít výhody akcelerovaných síťových služeb (nižší latence, nižší zpoždění a vyšší pakety za sekundu). Z tohoto důvodu doporučujeme zabránit fragmentaci, pokud je to možné.
Azure ve výchozím nastavení vyhodí fragmenty objednávek, tj. fragmentované pakety, které nedorazí na virtuální počítač v pořadí, v jakém byly přenášeny ze zdrojového koncového bodu. K tomu může dojít, když se pakety přenášejí přes internet nebo jiné velké WAN. V některých případech je možné změnit pořadí fragmentů mimo pořadí. Pokud to aplikace vyžaduje, otevřete případ podpory.
Ladění MTU
Nedoporučujeme zákazníkům zvyšovat MTU na síťových kartách virtuálních počítačů. Pokud virtuální počítač potřebuje komunikovat s cíli, které nejsou ve virtuální síti, které mají podobnou sadu MTU, dojde pravděpodobně k fragmentaci, která sníží výkon.
Velké přesměrování 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 adaptér Ethernet. Když je 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ýhodou LSO je, že může segmentaci paketů do velikostí, které odpovídají MTU, vzít z procesoru a nechat zpracování na ethernetové rozhraní, kde se provádí v hardwaru. Další informace o výhodách LSO najdete v tématu Podpora velkého snižování zátěže pro odesílání.
Když je povolený LSO, zákazníci Azure můžou při zachytávání paketů vidět velké velikosti rámců. Tyto velké velikosti rámců můžou vést některé zákazníky k názoru, že dochází k fragmentaci nebo že se používá velké MTU, pokud ne. S LSO může ethernetový adaptér inzerovat větší maximální velikost segmentu (MSS) do zásobníku TCP/IP a vytvořit větší paket TCP. Celý nes segmentovaný rámec se pak přesměruje na ethernetový adaptér a bude viditelný v zachytávání paketů prováděném na virtuálním počítači. Paket se ale rozdělí do mnoha menších rámců adaptérem Sítě Ethernet podle MTU adaptéru sítě Ethernet.
Š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 tedy bude mít MSS 1 460. Služba MSS je ale konfigurovatelná.
Toto nastavení je dohodnuto v trojcestné metodě handshake protokolu TCP, když je relace TCP nastavena 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
Služba MSS je vyjednána, ale nemusí znamenat skutečný msS, který lze použít. Důvodem je to, že 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 takovém případě zařízení, jehož MTU je menší než paket, paket zahodí. 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 jeho cestu MTU. Proces se nazývá zjišťování PATH MTU (PMTUD).
Proces PMTUD je neefektivní a má vliv na výkon sítě. Pokud se pakety odesílají, které překračují MTU síťové cesty, musí se pakety znovu odeslat s nižším MSS. Pokud odesílatel neobdrží zprávu Potřebujete fragmentaci protokolu ICMP, možná kvůli síťové bráně firewall v cestě (běžně označované jako blackhole PMTUD), odesílatel neví, že potřebuje snížit MSS a bude se neustále znovu převést paket. Proto nedoporučujeme zvýšit 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), je potřeba vzít v úvahu některé další aspekty týkající se velikosti paketů a MTU. Sítě VPN přidávají do paketů další hlavičky, což zvyšuje velikost paketů a vyžaduje menší msS.
Pro Azure doporučujeme nastavit upnutí TCP MSS na 1 350 bajtů a tunelové rozhraní MTU 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 odezvy
Latence sítě se řídí rychlostí světla v optické síti. Propustnost sítě tcp se také efektivně řídí dobou odezvy (RTT) mezi dvěma síťovými zařízeními.
| Postup | Vzdálenost | Jednosměrný čas | RTT |
|---|---|---|---|
| New York do San Francisca | 4 148 km | 21 ms | 42 ms |
| New York do Londýna | 5 585 km | 28 ms | 56 ms |
| New York 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. To je vzdálenost, v kilometrech, že 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. Když se tato hodnota připojí k rovnici, získáme následující:
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 časové efekty doby odezvy protokolu 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, 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ředtím, než bude muset přijmout potvrzení od příjemce. Pokud odesílatel nedosáhne potvrzení, 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 | 0 | 65.54 | 524.29 |
| 65,535 | 30 | 2.18 | 17.48 |
| 65,535 | 60 | 1.09 | 8.74 |
| 65,535 | 90 | .73 | 5,83 |
| 65,535 | 120 | 55. | 4.37 |
Pokud dojde ke ztrátě paketů, sníží se maximální propustnost připojení TCP, zatímco odesílatel znovu přepošle data, která už odeslal.
Š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 vyžadování potvrzení. 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í, což zvyšuje maximální propustnost protokolu TCP.
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
Měřítko 14 vede k velikosti okna TCP 14 (maximální povolený posun). Velikost okna TCP bude 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
Toto jsou platná nastavení protokolu TCP pro AutoTuningLevel:
| AutoTuningLevel | Faktor škálování | Násobitel škálování | Vzorec do výpočet maximální velikosti okna |
|---|---|---|---|
| Zakázá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.
Akcelerované síťové služby a škálování na straně příjmu
Akcelerované síťové služby
Síťové funkce virtuálních počítačů byly historicky náročné na procesor na hostovaném virtuálním počítači i na hostiteli nebo hypervisoru. Každý paket, který prochází přes hostitele, se zpracovává v softwaru procesorem hostitele, včetně zapouzdření a zapouzdření všech virtuálních sítí. Čím více provozu prochází hostitelem, tím vyšší je zatížení procesoru. A pokud je procesor hostitele zaneprázdněný jinými operacemi, ovlivní to také propustnost a latenci sítě. Azure tento problém řeší s akcelerovanými síťovými službami.
Akcelerované síťové služby poskytují konzistentní ultralow 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, což snižuje zatížení virtuálního počítače, snižuje zpoždění a nekonzistenci v latenci. 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 cesty k datům eliminuje čas strávený pakety v hostiteli pro zpracování zásad a zvyšuje počet paketů, které je možné zpracovat na virtuálním počítači.
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 odebere tuto variabilitu tím, že do virtuálního počítače doručí pakety, eliminuje komunikaci mezi hostitelem a virtuálním počítačem a všechny softwarové přerušení a kontextové přepínače.
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.
Vražda TIME_WAIT TCP a TIME_WAIT
Tcp TIME_WAIT je dalším běžným nastavením, které má vliv na výkon sítě a aplikace. Na zaneprázdněných virtuálních počítačích, které otevírají a zavírají mnoho soketů, buď jako klienti, nebo jako servery (zdrojová IP adresa: zdrojový port + cílová IP adresa:cílový port), během normálního provozu protokolu TCP může daný soket skončit v TIME_WAIT stavu po dlouhou dobu. Stav TIME_WAIT umožňuje doručení dalších dat na soketu před zavřením. Zásobníky TCP/IP tedy obecně brání opakovanému použití soketu tím, že bezobslužně zahodí paket TCP SYN klienta.
Doba, po kterou je soket v TIME_WAIT, je možné konfigurovat. Může se pohybovat od 30 sekund do 240 sekund. Sokety jsou konečný prostředek a počet soketů, které lze v daném okamžiku použít, je možné konfigurovat. (Počet dostupných soketů je obvykle přibližně 30 000.) Pokud se využívají dostupné sokety nebo pokud se klienti a servery neshodují TIME_WAIT nastavení a virtuální počítač se pokusí znovu použít soket v TIME_WAIT stavu, nová připojení selžou, protože pakety TCP SYN se tiše zahodí.
Hodnota rozsahu portů pro odchozí sokety je obvykle 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 vyřešení tohoto omezení škálování můžete použít TIME_WAIT vraždu. TIME_WAIT vraždy umožňuje opakované použití soketu v určitých situacích, například když pořadové číslo v paketu IP nového připojení překračuje pořadové číslo posledního paketu z předchozího připojení. V takovém případě operační systém umožní navázat nové připojení (přijme nový SYN/ACK) a vynutí zavření předchozího připojení, které bylo ve stavu TIME_WAIT. 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í propustnost odchozích přenosů virtuálního počítače
Azure nabízí celou řadu velikostí a typů 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ěří na odchozích (odchozích) přenosech 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á například virtuální počítač limit 1 000 Mb/s, použije se tento limit, jestli je odchozí provoz určený pro jiný virtuální počítač ve stejné virtuální síti nebo jeden mimo Azure.
Příchozí přenos dat není měřen ani omezen přímo. 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 tabulka, která poskytuje specifikace sítí v posledním sloupci s názvem "Maximální síťová karta / Očekávaná šířka pásma sítě (Mb/s)."
Limit propustnosti se vztahuje na virtuální počítač. Propustnost není ovlivněna 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í.
Cíl provozu: Všechny cíle se započítávají do limitu odchozích přenosů.
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čů.
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 může být ovlivněná problémy v mezilehlých sítích, přenosy, které nepřebírají "nejkratší" cestu vzdálenosti a neoptimální cesty peeringu.
Ztráta paketů: Ztráta paketů může být způsobena zahlcením sítě, problémy s fyzickou cestou a pod výkonem síťových zařízení.
Velikost/fragmentace MTU: Fragmentace v cestě může vést ke zpoždění při doručení dat nebo v paketech přicházejících mimo pořadí, což může ovlivnit doručování 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 hvězdicový návrh, který backhauluje provoz globálně do virtuální sítě s jedním centrem, způsobí latenci sítě, která ovlivní celkový výkon sítě.
Počet síťových zařízení, která síťový provoz prochází, může také ovlivnit celkovou latenci. Například v hvězdicovém návrhu, pokud provoz prochází paprskovým síťovým virtuálním zařízením a centrálním virtuálním zařízením před průchodem na internet, síťové virtuální zařízení způsobí 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, řádcích nebo dokonce datacentrech. 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.
Zeměpisné umístění virtuálních počítačů a potenciální výsledná latence mezi dvěma virtuálními počítači může ovlivnit konfigurace skupin dostupnosti, skupin umístění bezkontaktní komunikace 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ů překladu adres (NAT) zdroje
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 vytvořit pouze určitý počet odchozích připojení. Po dosažení těchto limitů virtuální počítač nebude moct vytvářet odchozí připojení.
Toto chování je ale možné konfigurovat. Další informace o vyčerpání portů SNAT a 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. Hodnoty latence, MTU, MSS a velikosti okna můžete připojit do výpočtů uvedených dříve a porovnat teoretická maxima se skutečnými hodnotami, které během testování sledujete.
Měření doby odezvy 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 zobrazí minimální/maximální/průměrnou latenci mezi zdrojem a cílem. Zobrazí se také ztráta 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.
IcMP ani příkazy PING protokolu TCP neměří akcelerovanou síťovou cestu k datům. Chcete-li to změřit, 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ší podrobnosti o testování další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í seznamy ACL jsou v síti normální. 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, můžete si přečíst další informace o plánování virtuálních sítí nebo další informace o připojování a konfiguraci virtuálních sítí.