Jako síťový administrátor jsem byl vždy hodnocen podle hodnoty MTTR (Mean Time To Repair). Pokaždé, když mi uživatelé hlásili problémy související se sítí, potřeboval jsem něco, co by mi pomohlo rychle identifikovat příčinu problému. Věděl jsem, že abych byl opravdu efektivní, musím porozumět síťovému provozu napříč vrstvami L2 až L7. A právě datové toky (NetFlow/IPFIX) umožňují nahlédnout do síťového provozu skrze metriky sledování výkonu sítě, které jsou známé jako RTT (Round Trip Time), SRT (Server Response Time) nebo Jitter. Pojďme si přiblížit, jak je využít v boji proti výkonnostním problémům a výpadkům sítě.

Základy sledování výkonu sítě

Network Performance Monitoring je metodika, jak spolehlivě a rychle určit, kde je problém, pokud síťové aplikace mají problém s odezvou. Je-li problém v přenosové trase mezi klientem a serverem, nebo v aplikaci samotné. Tím se jednoznačně určí, které oddělení správy ICT musí problém řešit.

Metodika pracuje se dvěma hlavními hodnotami naměřenými pasivním odposlechem sítě:

  • Round Trip Time (RTT) – doba trvání navázání spojení TCP, tedy doba přenosu paketu z klienta na server a zpět. Často označována jako zpoždění sítě (network delay). Vypočítá se z času potřebného pro vytvoření relace TCP (sleduje se tzv. TCP handshake). Tato metrika je k dispozici pouze pro spojení TCP.

  • Server Response Time (SRT) – doba (delay), kterou potřebuje aplikační server k odeslání odpovědi na požadavek klienta. Jednoduše lze říci, že se vypočítá jako časový rozdíl mezi potvrzením (TCP ACK) a prvním datovým paketem odpovědi. Tato metrika je k dispozici (s určitými výjimkami) pouze pro spojení TCP

1. Round Trip Time - RTT

Základní hodnota, která ukazuje/zobrazuje výkon sítě. Standardní doba trvání je pod 1 ms (často desítky mikrosekund), ale co když se její hodnota zvýší na několik stovek milisekund? Příčina je vždy v přenosové trase. Aplikace nemá žádný vliv na TCP handshake, protože ten navazují mezi sebou na L4 network stacky implementované v jádru operačního systému. Zde se tedy ještě neuplatní případné přetížení operačního systému, ať už na straně serveru nebo klienta. Takže víme s jistotou, že server i klient jsou schopni navázat TCP spojení pod 1 ms. Pokud je hodnota RTT ve stovkách milisekund, zpoždění vzniká v přenosové trase.

Zde je několik takových typických případů z praxe:

Přetížení síťových zařízení, zejména směrovačů

Vysoké rychlosti paketů ovlivňují vyrovnávací paměť síťových zařízení, ve kterých mají být odbaveny. QoS sice může určit prioritní služby a nastavit přenosové pásmo, ale takový útok DDoS může vést k přetížení sítě a zvýšení hodnot RTT.

Klienti se vzdáleným připojením do firemní sítě

Stížnost na pomalou odezvu aplikací nemusí vždy poukazovat na problém v síti. Například pokud se uživatelé připojují k firemní síti z domova přes VPN, znamená RTT o hodnotě 500 ms jen to, že zpoždění vzniká již na straně klienta. Tedy ještě dříve, než TCP paket dorazí na rozhraní firemní sítě. Každá aplikace se proto bude z pohledu uživatele jevit jako pomalá.   

 

Aplikace v cloudu

Podobná situace jako v případě, kdy se klienti připojují vzdáleně do firemní sítě. Aplikace běží v cloudu mimo podnikovou síť a jejich RTT je mnohonásobně větší než RTT uvnitř sítě. Nelze očekávat hodnoty okolo 10 ms jako u aplikací hostovaných ve firemním datovém centru. Za rozumný výsledek lze považovat RTT okolo 100 ms. Proto poskytovatelé SaaS využívají sítě CDN (Content Delivery Networks) a proxy servery k hostování aplikací, aby byly co nejblíže k zákazníkům a redukovali tak síťové zpoždění. Ze stejného důvodu si velké společnosti pořizují pro připojení své infrastruktury vyhrazené linky přímo k poskytovatelům cloudu. Odchylky v rámci provozu cloudových aplikací obvykle ukazují na nekvalitní trasu spojení mezi podnikovou sítí a aplikací.

 

Ethernet vs. Wi-Fi

Každý se již setkal s tvrzením, že Wi-Fi připojení vykazuje větší zpoždění sítě než v případě kabelového připojení. Je to pravda? Ze zkušenosti je obvyklý rozdíl mezi pevným a Wi-Fi připojením cca 10 ms. Ale to stále hovoříme o ideálních podmínkách. Ve skutečnosti můžeme pozorovat mnohem vyšší hodnoty a výrazné odchylky v závislosti na prostředí. Může například docházet k rušení ze strany ostatních Wi-Fi sítí na stejné frekvenci.

 

Výkonově uzká místa způsobená heterogenními rychlostmi portů

Jedná se o speciální případy. Představte si páteřní linku 10 Gbit, ke které jsou ale servery připojeny přes 1 Gbit. Problém vyvstává v okamžiku přechodu z vysoké rychlosti na nižší. Vinou zahlceného bufferu portu switche dochází k zahazování paketů. Pokud je například zahozen paket serveru z TCP handshake (SYN ACK), musí se klient pokusit znovu o handshake a uživatelé pociťují zpoždění sítě.

 

Obr. 2 vizualizace špičky RTT v síťovém provozu (Flowmon GUI) 

2. Server Response Time - SRT

Tato metrika prokazatelně odhalí délku trvání zpracování požadavku (request) klienta na server a zobrazuje tak zpoždění způsobené samotnou aplikací. Měří se od serverem potvrzeného přijetí (ACK na L4) celé dávky požadavku, po odeslání prvního paketu odpovědi klientovi. Toto měření se provede u prvního požadavku klienta a odpovědi serveru. Následující další hodnoty SRT již nejsou měřeny předchozí metodou, ale jsou vypočítávány z rozdílu očekávaného zpoždění a odezvy serveru. Lze tedy dobře sledovat uživatelskou zkušenost s aplikací v průběhu celé pracovní doby.


SRT umožňuje sledovat výkon aplikace, aplikačního serveru, řady klientských sítí nebo jednotlivých klientů. Jelikož se zatížení aplikace mění s počtem připojených klientů, umožňuje SRT najít korelaci mezi výkonem aplikací a počtem klientů respektive specifickou denní dobou, kdy jich je připojeno nejvíce. Využitím metriky SRT spolu s RTT získáme odpověď na otázku - je problém v síti nebo v aplikaci?

Obr. 3 vizualizace špičky SRT (Flowmon GUI)

3. Jitter - rozptyl zpoždění mezi pakety

Jitter může odhalit nepravidelnost toku paketů pomocí výpočtu rozptylu jednotlivých zpoždění mezi pakety. V ideálním případě je zpoždění mezi jednotlivými pakety konstantní, což znamená, že Jitter = 0. Neexistují žádné odchylky naměřených hodnot. Ve skutečnosti se taková hodnota nevyskytuje, protože datový tok ovlivňuje celá řada parametrů. Proč tedy měřit Jitter?

Jedná se o kritickou hodnotu, kterou využíváme zejména v rámci hodnocení kvality real-time aplikací. Typicky například u konferenčních hovorů, streamování videa, ale také při stahování ISO souboru linuxové distribuce. Zatímco u prvně jmenovaných využijeme Jitter při řešení zadrhávání konferenčních hovorů, respektive trhání obrazu nebo rozpadání, u posledně jmenovaného dokáže Jitter indikovat nestabilní síťové připojení.

Obr. 4 vizualizace špičky Jitter (Flowmon GUI)

Shrnutí

Ze své zkušenosti mohu potvrdit, že sledování NPM metrik v provozu sítě pomáhá správcům odhalit problémy přenosové trasy, nebo přetížení aplikací. Opravdu stojí zato věnovat průběžně čas sledování NPM hodnot a odstranit nalezené nedostatky dříve, než nespokojení uživatelé začnou atakovat ICT oddělení.

Také lze sledovat dlouhodobý vývoj zatížení sítě a zatížení aplikací v čase. Pokud například SRT pomalu narůstá během týdnů, je jisté, že s pokračujícím trendem nárůstu dojde k přetížení aplikačního serveru. Můžeme tedy na základě trendu nárůstu predikovat nutnost posílení systémových prostředků, na kterých aplikace běží. Včasným posílením předejdeme kritické situaci, kdy by došlo k trvalému přetížení aplikačního serveru. 

Z praxe mohu říci, že správci ICT, kteří začali používat NPM analýzu své sítě a aplikací, dokázali perfektně vyladit jak síťový provoz, tak aplikační servery. Odměnou je spokojenost uživatelů i vedení společnosti.

Pokud chcete vědět, jak s metrikami výkonu sítě pracuje Flowmon, zažádejte si o bezplatnou zkušební verzi (download our free trial).