Testování síťového výkonu v Azure

Jak správně testovat síťovou latenci a prostupnost? Jaké jsou parametry sítí v Azure a jaké jsou možnosti z pohledu optimalizací pro potřeby vašich aplikací? Nejprve se podíváme na koncepty Accelerated Networking, Proximity placement group, Availability zóny a regiony. Následně si popíšeme správné testovací nástroje a vyzkoušíme si, co naměříme.

Datová centra, regiony a síťová topologie na backendu

Základním stavebním blokem je datové centrum nebo sál. Jak je velké záleží na konkrétním regionu a stáří. Může to být technologie malých DC v kontejnerech, obrovská hala, patro či design ala motýl (4 haly se společným středem). Uvnitř DC jsou ToR prvky v každém racku zapojené do CLOS architektury s agregačními prvky. Pokud máte dvě VM ve stejném kontejneru či sálu je mezi nimi malinkatá vzdálenost a očekávejme nejlepší latenci i propustnost. Při vytvoření VM ale Azure rozhodne o umístění do konkrétního sálu podle aktuální kapacity, typu VM apod., takže nemůžete garantovat, že se VM dostanou skutečně do stejného sálu. Aby něco takového bylo možné přichází v preview funkce Proximity placement group, díky které si zajistíte, že vaše VM budou ve stejném sále. Získáte tak optimální latenci, ale doporučuji skutečně pouze tam, kde je síťová latence pro vás to nejdůležitější (takových případů je strašně málo). Ono jak uvidíte síťová latence se pohybuje v desítkách mikrosekund, zatímco obvyklá aplikační latence je běžně v řádech milisekund. Jinak řečeno optimalizace software je obvykle to nejdůležitější. Nicméně jsou situace, kde vám pár desítek mikrosekund k dobru pomůže (některé druhy High performance computing, high-frequency trading apod.). Nezapomínejte ale, že proximity group omezuje Azure scheduleru možnosti volby. Pokud například uděláte proximity group s VM typu D a pak do ní chcete přidat VM typu M, může se stát, že se deployment nepodaří jednoduše proto, že exotičtější typy strojů nejsou nutně v každém sále (řešením je začít plnit proximity group právě exotičtějšími servery a pak pokračovat běžnějšími). Zkrátka váš požadavek je velmi přísný a ztěžujete Azure práci, ale pokud je latence pro vás naprosto zásadní, je to pro vás k dispozici.

V regionu není jen jedno datové centrum, ale obvykle několik - třeba 12 obrovských hal nebo desítky/stovky kontejnerů. Ve vybraných regionech jsou k dispozici zóny dostupnosti, tedy datová centra (haly), které mají všechny samostatné napájení, generátory, chlazení, síťovou agregaci apod. Někdy jsou relativně blízko u sebe, ale někdy může být vzdálenost přes kilometr. Obvykle takových jednotek bývá několik. Pro uživatele je to ale zjednodušeno na 3 zóny dostupnosti, s kterými pracuje a ty reprezentují jednu a více budov. Pokud umístíte tři VM každé do jiné zóny, budou výborně odděleny do různých datových center a logicky tak dál od sebe s větší latencí. Nicméně CLOS networking architektura zajišťuje extrémně výkonné propoje, takže na propustnosti to prakticky nepoznáte.

Regiony jsou vždy dostatečně daleko od sebe pro minimalizaci dopadu nějaké místní katastrofy typu zemětřesení. Každý region má (alespoň co do “moderního” Azure, tedy ARM zdrojů) kompletní control plane a nasazování změn řídícího software se provádí tak, aby případná chyba nebyla zanesena najednou do dvou párových regionů jako je třeba West Europe a North Europe. Regiony propojuje globální Microsoft WAN síť s brutální kapacitou. Nicméně logicky musíme očekávat podstatně větší latenci (s rychlostí světla se nic nenadělá) a menší propustnost, než uvnitř datového centra (to určitě znáte z on-premises - servery máte připojeny 10G/40G a celkovou kapacitu DC klidně v řádu desítek TB, ale WAN linku mezi dvěma DC máte třeba jen 10G - v Azure je tohle samozřejmě o řády jinde, ale i tam platí, že výkon uvnitř regionu je logicky větší, než na WAN).

Accelerated Networking

Virtualizace tradičně znamená, že na hostiteli běží vSwitch, který implementuje věci jako je filtrace paketů (firewallig) aka NSG, routing, load-balancing pravidla nebo IP NAT. To samozřejmě přidává latenci, protože implementace běží v CPU. Nicméně v Azure jsou pro standardní a high-end řady montovány síťové karty s podporou SR-IOV a speciální FPGA čipy, které Microsoft programuje pro hardwarovou akceleraci těchto funkcí. Výsledkem pak je, že díky SR-IOV je virtuální síťová karta namapovaná přímo do guest OS (nemusí tak jít přes host procesy) a navíc je logika zpracování paketů zanesena do vedle sedícího FPGA. To výrazně snižuje latenci, takže pokud vám o ni jde, vyberte si stroje, které ji umožňují a zapněte její podporu. Jde typicky a řady D/E a vyšší (kromě nejmenších VM v řadě). Pozor ale, že pro podporu je potřeba mít speciální síťový driver. Ten je součástí Windows a Linux imagů v Azure, ale pokud si přinášíte svůj vlastní, dejte si na to pozor.

Propustnostní limity na VM

Řekněme například, že fyzický server v Azure má 100G připojení do sítě. Nebylo by fér, aby zákazník, který si koupí malé VM reprezentující 1/32 fyzického serveru mohl vyčerpat celých 100G. Stejně jako s CPU, RAM, cache nebo storage IO je i propustnost sítě přidělována VM podle jejich velikosti. Tak například Standard D16 v3 dle dokumentace nabízí 8Gbps hrubé propustnosti. D8 méně, D32 více. U některých typů VM, zejména těch levnějších, není jejich propustnost uvedena a je nějakým způsobem agregována (A-series, B-series).

Nástroje pro testování

Pro testování propustnosti vždy doporučuji použít iperf, který je k dispozici jak pro Linux tak Windows. Má serverovou stranu a klienstkou stranu. Nepoužívejte pro testování něco typu kopírování souborů, protože pak vám do toho promlouvá výkonnost storage a neměříte co potřebujete. U iperf by default pouštíte jako test jednu session. Ve vnitřní sítí obvykle není zásadní rozdíl mezi jednou session a vícero paralelních, protože jsou nízké latence a relativně jednoduché prvky. U WAN linek nebo při průchodu nějakým vaším firewallem už tam ale rozdíl být může, protože třeba firewall může paralelizovat zpracování podle session na jednotlivé core a součet vícero session tak může dávat víc, než session jedna. To prakticky uvidíte právě na spojení mezi dvěma Azure regiony nebo při připojení z on-prem. V takových situacích se snažte paralelizovat přenosy (například ve Windows robocopy vs. copy).

Co se latence týče prosím nikdy nepoužívejte ping. Ten má nejnižší možnou prioritu jak v SDN Azure tak v rámci TCP/IP stacku v OS. Dostanete naprosto nesmyslné výsledky. Pro Linux doporučuji qperf, ve Windws můžete použít ntttcp.

Prostředí

Pro jednoduchost jsem připravil ARM šablonu, která pro vás založí testovací stroje o velikosti D16 v3. Více detailů jak to funguje a jak je to udělané najdete na mém githubu.

Nasaďte šablonu do Azure:

Deploy to Azure

Připojte se na první stroj a odtud budeme testovat (username je net a password zadáváte v šabloně).

export ip=$(az network public-ip show -n r1-z1-pg1-vm01-ip -g netperf --query ipAddress -o tsv)
ssh net@$ip

Testy latence

Nejprve se podívejme latenci.

Latence v rámci proximity placement group

Proximity placement group nám garantuje, že stroje jsou ve stejném sálu. Podívejme se na výsledky:

net@r1-z1-pg1-vm01:~$ qperf -t 20 -v r1-z1-pg1-vm02 tcp_lat # same proximity placement group
tcp_lat:
    latency        =  39.4 us
    msg_rate       =  25.3 K/sec
    time           =    20 sec
    loc_cpus_used  =  15.1 % cpus
    rem_cpus_used  =  12.8 % cpus

Naměřil jsem cca 40 mikrosekund. Můžeme očekávat latenci velmi velmi stabilní.

Latence v rámci zóny dostupnosti

Další VM je ve stejné zóně dostupnosti jako to první, ale ne ve stejné proximity group. To může znamenat buď, že máme štěstí a jsme ve stejném sále a nebo taky jsme v sále jiném. Výsledky tedy mohou být úplně stejné jako v předchozím případě, ale také nemusí. Jak už jsem psal zóna dostupnosti je logické členění a nemusí znamenat pouze jediný sál. Nicméně sály budou blízko u sebe, takže očekáváme výbornou latenci. Změřme si to.

net@r1-z1-pg1-vm01:~$ qperf -t 20 -v r1-z1-vm tcp_lat # same availability zone
tcp_lat:
    latency        =  58.2 us
    msg_rate       =  17.2 K/sec
    time           =    20 sec
    loc_cpus_used  =  10.5 % cpus
    rem_cpus_used  =  10.9 % cpus

V mém případě jsem tedy evidentně v jiném sále, ale latence je pořád pod 60 mikrosekund.

Latence mezi zónami dostupnosti

Další VM už je v jiné zóně dostupnosti, tedy rozhodně nebude ve stejné budově, jako VM první. To může znamenat, že jsou od sebe stovky metrů, ale v některých regionech mohou být DC od sebe i dál a to už bude znamenat větší latenci. Přesto mezi zónami očekávejte latenci hluboko pod 1 milisekundu. Vyzkoušejme na příkladu West Europe.

net@r1-z1-pg1-vm01:~$ qperf -t 20 -v r1-z2-vm tcp_lat # different availability zone
tcp_lat:
    latency        =  57.2 us
    msg_rate       =  17.5 K/sec
    time           =    20 sec
    loc_cpus_used  =    10 % cpus
    rem_cpus_used  =    12 % cpus

Všimněte si, že latence je u mě stejná, jako v předchozím příkladě. Datová centra jsou tedy v jiných zónách, ale blízko u sebe. U jiných regionů, třeba Paříž, to tak ale být nemusí. V každém případě je latence velmi nízká a umožňuje používání synchronních operací mezi zónami.

Latence mezi regiony

V tomto případě jsou centra od sebe stovky kilometrů a jdeme přes WAN síť. Tady se fyzikální zákony ošálit nedají. Jakou jsem naměřil latenci mezi West Europe a North Europe?

net@r1-z1-pg1-vm01:~$ qperf -t 20 -v 10.1.0.4 tcp_lat # secondary region via VNET peering
tcp_lat:
    latency        =   9.9 ms
    msg_rate       =   101 /sec
    time           =    20 sec
    loc_cpus_used  =  0.95 % cpus
    rem_cpus_used  =   0.9 % cpus

Výsledek je kolem 10ms. To není vůbec špatné, ale pro věci typu synchronní replikace už je to moc. Z aplikačního hlediska to ale není nic šíleného, nicméně asi nedává smysl mít databázi v jednom regionu a aplikaci, která ji transakčně obsluhuje v jiném regionu.

Testy propustnosti

Podívejme se teď na jiný aspekt výkonnosti sítě - propustnost. Použiji TCP testy, protože ty nejvíce odpovídají běžnému provozu. VM mojí velikosti má v dokumentaci 8Gbps, ale musíme počítat s nějakým overheadem pro TCP/IP hlavičky.

Propustnost v rámci proximity placement group

Jakou jsem naměřil propustnosti v rámci proximity skupiny?

net@r1-z1-pg1-vm01:~$ sudo iperf -c r1-z1-pg1-vm02 -i 1 -t 30 # same proximity placement group
------------------------------------------------------------
Client connecting to r1-z1-pg1-vm02, TCP port 5001
TCP window size: 45.0 KByte (default)
------------------------------------------------------------
[  3] local 10.0.0.4 port 43002 connected with 10.0.0.5 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 1.0 sec   909 MBytes  7.62 Gbits/sec
[  3]  1.0- 2.0 sec   902 MBytes  7.56 Gbits/sec
[  3]  2.0- 3.0 sec   902 MBytes  7.56 Gbits/sec
[  3]  3.0- 4.0 sec   900 MBytes  7.55 Gbits/sec
[  3]  4.0- 5.0 sec   902 MBytes  7.56 Gbits/sec
[  3]  5.0- 6.0 sec   902 MBytes  7.56 Gbits/sec
[  3]  6.0- 7.0 sec   902 MBytes  7.57 Gbits/sec
[  3]  7.0- 8.0 sec   896 MBytes  7.52 Gbits/sec
[  3]  8.0- 9.0 sec   900 MBytes  7.55 Gbits/sec
[  3]  9.0-10.0 sec   902 MBytes  7.56 Gbits/sec
[  3] 10.0-11.0 sec   902 MBytes  7.56 Gbits/sec
[  3] 11.0-12.0 sec   900 MBytes  7.55 Gbits/sec
[  3] 12.0-13.0 sec   892 MBytes  7.48 Gbits/sec
[  3] 13.0-14.0 sec   901 MBytes  7.56 Gbits/sec
[  3] 14.0-15.0 sec   902 MBytes  7.56 Gbits/sec
[  3] 15.0-16.0 sec   902 MBytes  7.56 Gbits/sec
[  3] 16.0-17.0 sec   902 MBytes  7.56 Gbits/sec
[  3] 17.0-18.0 sec   902 MBytes  7.56 Gbits/sec
[  3] 18.0-19.0 sec   902 MBytes  7.56 Gbits/sec
[  3] 19.0-20.0 sec   875 MBytes  7.34 Gbits/sec
[  3] 20.0-21.0 sec   900 MBytes  7.55 Gbits/sec
[  3] 21.0-22.0 sec   902 MBytes  7.56 Gbits/sec
[  3] 22.0-23.0 sec   900 MBytes  7.55 Gbits/sec
[  3] 23.0-24.0 sec   902 MBytes  7.57 Gbits/sec
[  3] 24.0-25.0 sec   900 MBytes  7.55 Gbits/sec
[  3] 25.0-26.0 sec   902 MBytes  7.57 Gbits/sec
[  3] 26.0-27.0 sec   902 MBytes  7.56 Gbits/sec
[  3] 27.0-28.0 sec   898 MBytes  7.53 Gbits/sec
[  3] 28.0-29.0 sec   898 MBytes  7.53 Gbits/sec
[  3] 29.0-30.0 sec   901 MBytes  7.56 Gbits/sec
[  3]  0.0-30.0 sec  26.4 GBytes  7.55 Gbits/sec

7,55 Gbps a velmi stabilní.

Propustnost v rámci zóny dostupnosti

Jak bude vypadat situace v rámci zóny dostupnosti?

net@r1-z1-pg1-vm01:~$ sudo iperf -c r1-z1-vm -i 1 -t 30 # same availability zone
------------------------------------------------------------
Client connecting to r1-z1-vm, TCP port 5001
TCP window size: 45.0 KByte (default)
------------------------------------------------------------
[  3] local 10.0.0.4 port 51196 connected with 10.0.0.6 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 1.0 sec   909 MBytes  7.62 Gbits/sec
[  3]  1.0- 2.0 sec   902 MBytes  7.57 Gbits/sec
[  3]  2.0- 3.0 sec   902 MBytes  7.57 Gbits/sec
[  3]  3.0- 4.0 sec   902 MBytes  7.56 Gbits/sec
[  3]  4.0- 5.0 sec   901 MBytes  7.56 Gbits/sec
[  3]  5.0- 6.0 sec   898 MBytes  7.53 Gbits/sec
[  3]  6.0- 7.0 sec   895 MBytes  7.51 Gbits/sec
[  3]  7.0- 8.0 sec   901 MBytes  7.56 Gbits/sec
[  3]  8.0- 9.0 sec   902 MBytes  7.56 Gbits/sec
[  3]  9.0-10.0 sec   898 MBytes  7.53 Gbits/sec
[  3] 10.0-11.0 sec   902 MBytes  7.57 Gbits/sec
[  3] 11.0-12.0 sec   901 MBytes  7.56 Gbits/sec
[  3] 12.0-13.0 sec   902 MBytes  7.57 Gbits/sec
[  3] 13.0-14.0 sec   902 MBytes  7.56 Gbits/sec
[  3] 14.0-15.0 sec   902 MBytes  7.56 Gbits/sec
[  3] 15.0-16.0 sec   899 MBytes  7.54 Gbits/sec
[  3] 16.0-17.0 sec   903 MBytes  7.57 Gbits/sec
[  3] 17.0-18.0 sec   902 MBytes  7.56 Gbits/sec
[  3] 18.0-19.0 sec   902 MBytes  7.56 Gbits/sec
[  3] 19.0-20.0 sec   902 MBytes  7.56 Gbits/sec
[  3] 20.0-21.0 sec   898 MBytes  7.53 Gbits/sec
[  3] 21.0-22.0 sec   902 MBytes  7.56 Gbits/sec
[  3] 22.0-23.0 sec   900 MBytes  7.55 Gbits/sec
[  3] 23.0-24.0 sec   902 MBytes  7.56 Gbits/sec
[  3] 24.0-25.0 sec   900 MBytes  7.55 Gbits/sec
[  3] 25.0-26.0 sec   901 MBytes  7.56 Gbits/sec
[  3] 26.0-27.0 sec   902 MBytes  7.56 Gbits/sec
[  3] 27.0-28.0 sec   902 MBytes  7.56 Gbits/sec
[  3] 28.0-29.0 sec   902 MBytes  7.56 Gbits/sec
[  3] 29.0-30.0 sec   902 MBytes  7.56 Gbits/sec
[  3]  0.0-30.0 sec  26.4 GBytes  7.56 Gbits/sec

Situace je prakticky stejná. V rámci zóny jsou síťové propoje masivní, takže nepozoruji žádný úbytek propustnosti nebo její vyrovnanosti.

Latence mezi zónami dostupnosti

Každá zóna dostupnosti má nezávislé agregační prvky z důvodu nesdílení žádných komponent. Teoreticky tak může propustnost mezi zónami vypadat jinak. Vyzkoušejme si to.

net@r1-z1-pg1-vm01:~$ sudo iperf -c r1-z2-vm -i 1 -t 30 # different availability zone
------------------------------------------------------------
Client connecting to r1-z2-vm, TCP port 5001
TCP window size: 45.0 KByte (default)
------------------------------------------------------------
[  3] local 10.0.0.4 port 45604 connected with 10.0.0.7 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 1.0 sec   904 MBytes  7.58 Gbits/sec
[  3]  1.0- 2.0 sec   901 MBytes  7.56 Gbits/sec
[  3]  2.0- 3.0 sec   901 MBytes  7.56 Gbits/sec
[  3]  3.0- 4.0 sec   899 MBytes  7.54 Gbits/sec
[  3]  4.0- 5.0 sec   900 MBytes  7.55 Gbits/sec
[  3]  5.0- 6.0 sec   901 MBytes  7.56 Gbits/sec
[  3]  6.0- 7.0 sec   892 MBytes  7.48 Gbits/sec
[  3]  7.0- 8.0 sec   901 MBytes  7.56 Gbits/sec
[  3]  8.0- 9.0 sec   897 MBytes  7.52 Gbits/sec
[  3]  9.0-10.0 sec   884 MBytes  7.41 Gbits/sec
[  3] 10.0-11.0 sec   901 MBytes  7.56 Gbits/sec
[  3] 11.0-12.0 sec   895 MBytes  7.51 Gbits/sec
[  3] 12.0-13.0 sec   900 MBytes  7.55 Gbits/sec
[  3] 13.0-14.0 sec   901 MBytes  7.56 Gbits/sec
[  3] 14.0-15.0 sec   902 MBytes  7.56 Gbits/sec
[  3] 15.0-16.0 sec   901 MBytes  7.56 Gbits/sec
[  3] 16.0-17.0 sec   901 MBytes  7.56 Gbits/sec
[  3] 17.0-18.0 sec   902 MBytes  7.56 Gbits/sec
[  3] 18.0-19.0 sec   901 MBytes  7.56 Gbits/sec
[  3] 19.0-20.0 sec   902 MBytes  7.56 Gbits/sec
[  3] 20.0-21.0 sec   899 MBytes  7.54 Gbits/sec
[  3] 21.0-22.0 sec   899 MBytes  7.54 Gbits/sec
[  3] 22.0-23.0 sec   901 MBytes  7.56 Gbits/sec
[  3] 23.0-24.0 sec   901 MBytes  7.56 Gbits/sec
[  3] 24.0-25.0 sec   899 MBytes  7.54 Gbits/sec
[  3] 25.0-26.0 sec   897 MBytes  7.53 Gbits/sec
[  3] 26.0-27.0 sec   899 MBytes  7.54 Gbits/sec
[  3] 27.0-28.0 sec   893 MBytes  7.49 Gbits/sec
[  3] 28.0-29.0 sec   894 MBytes  7.50 Gbits/sec
[  3] 29.0-30.0 sec   899 MBytes  7.54 Gbits/sec
[  3]  0.0-30.0 sec  26.3 GBytes  7.54 Gbits/sec

Je vidět, že propoje jsou i mezi zónami nesmírně silné a na celkovou propustnost v mém případě prakticky nemají vliv. Je vidět častější zakolísání, ale v řádu 1%. Z pohledu propustnosti tedy můžeme považovat zóny dostupnost stále za lokální provoz. Pokud máte v on-premises třeba dvě datová centra v rámci Prahy, v Azure tomu odpovídá zóna dostupnosti. Pokud mezi nimi máte 10G linku považte, že v Azure jsme dostali skoro to samé jen pro jedno VMko - a to jsme tam s ohromným množství dalších VM.

Propustnost mezi regiony

Mezi regiony už je WAN linka. Očekávám tedy složitější síťové prvky, nějaké velké routery a podobná zařízení a slabší propoje, než ve vnitřní síti. Připomínám, že v on-premises se tomu přibližuje třeba DC v Plzni a v Ostravě. Propojení mezi nimi budete mít typicky třeba 1G nebo 10G.

Kolik naměříme v Azure?

net@r1-z1-pg1-vm01:~$ sudo iperf -c 10.1.0.4 -i 1 -t 30 # secondary region via VNET peering
------------------------------------------------------------
Client connecting to 10.1.0.4, TCP port 5001
TCP window size: 45.0 KByte (default)
------------------------------------------------------------
[  3] local 10.0.0.4 port 60516 connected with 10.1.0.4 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 1.0 sec  23.4 MBytes   196 Mbits/sec
[  3]  1.0- 2.0 sec   124 MBytes  1.04 Gbits/sec
[  3]  2.0- 3.0 sec   116 MBytes   969 Mbits/sec
[  3]  3.0- 4.0 sec   113 MBytes   946 Mbits/sec
[  3]  4.0- 5.0 sec  91.1 MBytes   764 Mbits/sec
[  3]  5.0- 6.0 sec  88.8 MBytes   744 Mbits/sec
[  3]  6.0- 7.0 sec  91.0 MBytes   763 Mbits/sec
[  3]  7.0- 8.0 sec  95.9 MBytes   804 Mbits/sec
[  3]  8.0- 9.0 sec  97.4 MBytes   817 Mbits/sec
[  3]  9.0-10.0 sec  99.6 MBytes   836 Mbits/sec
[  3] 10.0-11.0 sec  97.8 MBytes   820 Mbits/sec
[  3] 11.0-12.0 sec   100 MBytes   843 Mbits/sec
[  3] 12.0-13.0 sec   100 MBytes   842 Mbits/sec
[  3] 13.0-14.0 sec   100 MBytes   843 Mbits/sec
[  3] 14.0-15.0 sec  98.9 MBytes   829 Mbits/sec
[  3] 15.0-16.0 sec   101 MBytes   844 Mbits/sec
[  3] 16.0-17.0 sec   103 MBytes   866 Mbits/sec
[  3] 17.0-18.0 sec  80.5 MBytes   675 Mbits/sec
[  3] 18.0-19.0 sec  81.9 MBytes   687 Mbits/sec
[  3] 19.0-20.0 sec  61.2 MBytes   514 Mbits/sec
[  3] 20.0-21.0 sec  65.8 MBytes   552 Mbits/sec
[  3] 21.0-22.0 sec  68.4 MBytes   574 Mbits/sec
[  3] 22.0-23.0 sec  70.2 MBytes   589 Mbits/sec
[  3] 23.0-24.0 sec  70.0 MBytes   587 Mbits/sec
[  3] 24.0-25.0 sec  72.1 MBytes   605 Mbits/sec
[  3] 25.0-26.0 sec  72.6 MBytes   609 Mbits/sec
[  3] 26.0-27.0 sec  71.2 MBytes   598 Mbits/sec
[  3] 27.0-28.0 sec  73.1 MBytes   613 Mbits/sec
[  3] 28.0-29.0 sec  74.4 MBytes   624 Mbits/sec
[  3] 29.0-30.0 sec  75.0 MBytes   629 Mbits/sec
[  3]  0.0-30.0 sec  2.52 GBytes   721 Mbits/sec

Dostal jsem se asi na 700 Mbps. Takže pokud máte mezi Plzní a Ostravou 1G linku, tak mezi Azure regiony jsme to dostali i na jednu z třeba milionu VM tam běžících.

Nicméně je to WAN linka a po cestě tedy budou určitě složitější prvky, které mohou paralelizovat zpracování podle jednotlivých sessions. Možná bychom tedy dosáhli vyšší propustnosti, pokud budeme přenášet paralelně.

net@r1-z1-pg1-vm01:~$ sudo iperf -c 10.1.0.4 -P16 -t 30 # multiple parallel sessions
------------------------------------------------------------
Client connecting to 10.1.0.4, TCP port 5001
TCP window size: 45.0 KByte (default)
------------------------------------------------------------
[ 18] local 10.0.0.4 port 60988 connected with 10.1.0.4 port 5001
[ 16] local 10.0.0.4 port 60984 connected with 10.1.0.4 port 5001
[ 17] local 10.0.0.4 port 60986 connected with 10.1.0.4 port 5001
[ 15] local 10.0.0.4 port 60982 connected with 10.1.0.4 port 5001
[  3] local 10.0.0.4 port 60958 connected with 10.1.0.4 port 5001
[  6] local 10.0.0.4 port 60964 connected with 10.1.0.4 port 5001
[  5] local 10.0.0.4 port 60962 connected with 10.1.0.4 port 5001
[  4] local 10.0.0.4 port 60960 connected with 10.1.0.4 port 5001
[ 10] local 10.0.0.4 port 60972 connected with 10.1.0.4 port 5001
[  9] local 10.0.0.4 port 60970 connected with 10.1.0.4 port 5001
[  7] local 10.0.0.4 port 60968 connected with 10.1.0.4 port 5001
[ 11] local 10.0.0.4 port 60974 connected with 10.1.0.4 port 5001
[ 14] local 10.0.0.4 port 60978 connected with 10.1.0.4 port 5001
[  8] local 10.0.0.4 port 60966 connected with 10.1.0.4 port 5001
[ 13] local 10.0.0.4 port 60980 connected with 10.1.0.4 port 5001
[ 12] local 10.0.0.4 port 60976 connected with 10.1.0.4 port 5001
[ ID] Interval       Transfer     Bandwidth
[ 10]  0.0-30.0 sec  1.16 GBytes   332 Mbits/sec
[  5]  0.0-30.0 sec   466 MBytes   130 Mbits/sec
[  3]  0.0-30.0 sec   442 MBytes   124 Mbits/sec
[  9]  0.0-30.0 sec   530 MBytes   148 Mbits/sec
[  7]  0.0-30.0 sec   324 MBytes  90.4 Mbits/sec
[ 13]  0.0-30.0 sec   376 MBytes   105 Mbits/sec
[ 16]  0.0-30.0 sec  1.11 GBytes   319 Mbits/sec
[ 17]  0.0-30.0 sec   729 MBytes   204 Mbits/sec
[  8]  0.0-30.0 sec   351 MBytes  98.1 Mbits/sec
[ 12]  0.0-30.1 sec   573 MBytes   160 Mbits/sec
[ 18]  0.0-30.1 sec   582 MBytes   162 Mbits/sec
[ 14]  0.0-30.1 sec   393 MBytes   110 Mbits/sec
[  4]  0.0-30.1 sec   437 MBytes   122 Mbits/sec
[ 15]  0.0-30.1 sec   461 MBytes   129 Mbits/sec
[ 11]  0.0-30.1 sec   561 MBytes   157 Mbits/sec
[  6]  0.0-30.1 sec   620 MBytes   173 Mbits/sec
[SUM]  0.0-30.1 sec  8.96 GBytes  2.55 Gbits/sec

Při použití 16 vláken jsme na 2,5 Gbps. Efekt zvýšení počtu sessions je v lokálu prakticky nulový, ale mezi regiony hraje důležitou roli. Opět si představte jak silná asi globální Microsoft síť je, když jedno z obrovského množství VM se může dostat na takovou propustnost.

Síť Microsoftu je myslím extrémně silná. V každém případě doporučuji testovat propustnost správně s použitím vhodných nástrojů. Pokud potřebujete testovat výkon ze svého DC do Azure, použijte stejné techniky. Nevěřte obecným statistikám nebo webovkám, ale jen vlastním očím. Pusťte si VM v Azure a otestujte si to sami, ať se přesvědčíte. Pokud máte pocit, že je aplikace uvnitř regionu pomalá a má dlouhou odezvu, zaměřil bych si primárně na prověření aplikačního a OS stacku, možná na sofistikované virtuální prvky po cestě (NGFW, WAFka). Síťovým fabric to obvykle nebude, protože je o 2 řády jinde, než většina software.



Privátní napojení vaší vlastní služby v SaaS stylu s Azure Private Link Service Networking
Privátní napojení PaaS služeb do VNETu s Azure Private Link Networking
Automatické získávání IP range PaaS služeb v Azure přes API Networking
Kubernetes praticky: vystavování aplikací s Ingress a Azure App Gateway (WAF) Networking
IPv6 v Azure Networking