6 Sledování a optimalizace výkonnostních charakteristik

Aktivita Sledování a optimalizace výkonnostních charakteristik se zabývá teoretickými a praktickými stránkami zajištění vysoké propustnosti a dalších kvalitativních komunikačních parametrů vyžadovaných aplikacemi při komunikaci přes rozlehlé vysokorychlostní sítě.

Aktivita má svoje WWW stránky, kde je možné nalézt naše články, technické zprávy, prezentace, výsledky experimentů a vytvořený software. Shrnutí nejdůležitějších výsledků aktivity v roce 2004 uvádíme dále.

6.1 Plánování a zpracování výkonnostních testů

Ukazuje se, že každá rozlehlá počítačová síť by měla mít systém pro monitorování výkonnostních charakteristik jako jsou například propustnost, zpoždění, ztrátovost paketů a kolísání zpoždění. Takový systém umožní zjistit trendy v objemu a vlastnostech datového provozu uživatelů. Zejména však umožní ověřit, zda síť poskytuje požadované kvalitativní charakteristiky komunikace a pomůže nalézt místa způsobující nízkou propustnost nebo jiným způsobem omezující komunikaci mezi uživateli. I v síti s dostatečnou instalovanou fyzickou kapacitou může být kvalita komunikace limitována například vadným komponentem způsobujícím ztráty paketů nebo nevhodnou konfigurací komunikačních protokolů.

Pro měření různých výkonnostních charakteristik byla již vytvořena celá řada nástrojů. Různé cíle monitorování vyžadují použít kombinaci různých typů nástrojů. Tyto mohou být spouštěny podle požadavků buď jednorázově "ad-hoc" nebo periodicky. Každý nástroj se zpravidla konfiguruje různým způsobem a vytváří výstupy v různém tvaru. Naměřené hodnoty ze všech nástrojů musí být vhodným způsobem zpracovány. Zejména musí být provedeno spojení měření provedených v navazujících sítích podél komunikační trasy a agregace hodnot podle požadovaného časového měřítka.

V rámci aktivity jsme vytvořili framework pro plánování spouštění různých typů měření, zpracování výsledků a jejich prezentaci. Framework nám umožňuje získat zkušenosti s různými měřícími nástroji a sledovat jejich chování při souběžném použití v síti. Zároveň nám samozřejmě pomůže v lokalizaci výkonnostních problémů v naší síti.

6.1.1 Specifikace testů

Informace o tom kdy má být spuštěn který test, způsob jakým mají být zpracovány výsledky i naměřené hodnoty jsou uloženy v databázi MySQL se strukturou podle obrázku 6.1. Tabulka test_type obsahuje jeden řádek pro každý typ testu. Tabulka tests obsahuje jeden řádek pro každou instanci testu určitého typu, který může běžet mezi různými koncovými body. Tabulka attributes potom obsahuje parametry instancí testů jako například IP adresy koncových bodů. Naměřené hodnoty jsou ukládány to tabulky mvalues a následně agregovány podle pokynů v tabulce aggregations. Databáze dále obsahuje informace o podobě grafů zobrazujících výsledky a například i informaci o tom, které testy nesmí být spuštěny současně, protože by se mohly navzájem ovlivnit.

Obrázek 6.1: Struktura databáze pro plánování testů a zpracování výsledků (větší obrázek)

6.1.2 Prezentace výsledků

Výsledky všech typů testů jsou prezentovány v jednotném uživatelském rozhraní znázorněném na obrázku 6.2. Uživatel nejprve vybere typ testu. Systém automaticky nabídne koncové body, mezi kterými je vybraný typ testu prováděn. Po volbě koncových bodů systém nabídne charakteristiky měřené mezi těmito body. Uživatel vybere jednu nebo více charakteristik, které budou znázorněny křivkami různých barev. Nakonec může uživatel zvolit potlačení hodnot převyšujících 95% percentil (tím se lépe využije plocha grafu a podrobněji zobrazí většina naměřených hodnot) a současné zobrazení hodnot mezi dalšími koncovými body do téhož grafu pro vzájemné porovnání. Systém automaticky zobrazí sadu grafů pro různá časová období s různými stupni agregace. Uživatel může kliknout na zvolený graf pro jeho zobrazení ve větším měřítku.

Obrázek 6.2: Ukázka uživatelského rozhraní pro prezentaci výsledků testů (větší obrázek)

6.2 Monitorování a optimalizace řízení zahlcení

Naprostá většina dat přenášených v současnosti v Internetu používá na transportní vrstvě protokol TCP. Tento protokol používá několik mechanismů pro tzv. řízení zahlcení (congestion control), jehož cílem je přizpůsobit rychlost posílání dat aktuální volné kapacitě sítě a snažit se tuto kapacitu využít. Protokol TCP je dnes již historický, byl navržen v počátcích budování sítí. Ukazuje se, že některé jeho mechanismy již nepracují dobře v současných gigabitových sítích, kde komunikace navíc probíhá na veliké vzdálenosti s nezanedbatelným dopravním zpožděním, daným rychlostí šíření signálu po vedení.

Mnoho výkonnostních problémů je způsobeno nevhodnou konfigurací mechanismů pro řízení zahlcení v protokolu TCP. Optimalizaci této konfigurace nám usnadní systém pro monitorování vnitřních stavových proměnných protokolu TCP v reálném čase. Zároveň potřebujeme nástroj umožňující nastavování parametrů řízení zahlcení.

V rámci naší aktivity jsme proto vytvořili nástroj bulk umožňující aktivní měření propustnosti trasy (podobně jako známý nástroj iperf) se současným synchronním monitorováním proměnných protokolu TCP. Nástroj bulk používá standardní mechanismus volání jádra setsockopt() a getsockopt(), zejména pro parametr soketu (socket option) TCP_INFO. Nástroj má zabudovanou mnemoniku pro mnoho známých parametrů soketů, lze však používat i jejich číselné kódy. To umožňuje použít nástroj i pro jakékoliv nové parametry soketů implementované v nových verzích jádra operačního systému.

Chceme-li například provést měření s 10 paralelními toky dat s velikostí soketové vyrovnávací paměti vysílače 10 MB a zajímá-li nás zda proběhla v pořádku iniciace spojení (během níž se mimo jiné dohodne násobný faktor velikosti TCP okénka), průběh proměnných rcv_ssthresh, rtt a skutečná velikost soketové vyrovnávací paměti přijímače, můžeme použít následující příkaz:

./bulk -v -m -c50 -sSO_RCVBUF,10000000 -b10000000\
  -gwscales%Scales:\ ,rcv_ssthresh%Recv\ thresh:\ ,rtt%RTT:\
  -gSO_RCVBUF%Real\ RCVBUF\ size:\ >outfile_r.txt

Výstupem pak bude následující posloupnost řádků:

...
[5] Scales: 16Recv thresh: 81919RTT: 10000Real RCVBUF size: 131070
[5] Scales: 16Recv thresh: 81919RTT: 10000Real RCVBUF size: 131070
...

Nástroj bulk jsme již úspěšně použili při řešení několika výkonnostních problémů.

Dále jsme vytvořili AIMD patch pro operační systém Linux umožňující nastavit parametry základního mechanismu řízení zahlcení AIMD (Additive Increase Multiplicative Decrease). Patch dále umožňuje zapnutí, vypnutí a sledování použití mechanismů CWV (Congestion Window Validation) a CWR (Congestion Window Reduction). Všechny tyto možnosti mohou být konfigurovány a monitorovány samostatně pro jednotlivá soketová spojení. Tím se patch zásadně liší od podobných existujících nástrojů, které pracují na úrovni celého operačního systému. Patch vytváří dvě nová volání setsockopt() a getsockopt - TCP_AIMD a TCP_COUNTERS, která jsou podporována nástrojem bulk. AIMD patch umožňuje přizpůsobit rychlost reakce řízení zahlcení jednotlivých spojení vzhledem k parametrům dané komunikační trasy (zejména RTT).

6.3 Program pscp a knihovna psock

Jednou z možností jak zvýšit propustnost při přenosech velkých objemů dat je použít více paralelních spojení. Můžeme tak nejen využít více fyzických paralelních cest, ale i lépe využít kapacitu jedné vysokorychlostní trasy. V tom případě jde o alternativu ke změně AIMD parametrů řízení zahlcení. Výhodou je, že není třeba měnit jádro operačního systému, změnu lze provést na aplikační úrovni.

Zhotovili jsme dvě praktické implementace paralelních přenosů. Za prvé jde o program pscp, který je paralelní verzí populárního programu scp pro kopírování souborů po síti s autentizací účastníků a šifrováním dat. Za druhé jde o knihovnu psock, která je paralelní verzí standardní soketové knihovny pro tvorbu síťových aplikací. Výhodou knihovny psock je možnost použít paralelní přenosy s jakoukoliv síťovou aplikací, která vyžaduje pouze nenáročné úpravy. Knihovna také umožňuje použití různých algoritmů pro obsluhu jednotlivých paralelních spojení a umožňuje tak přizpůsobení různým síťovým podmínkám a experimentování s různými algoritmy.

6.4 PERT

PERT (Performance Enhancement and Response Team) je vznikající mezinárodní aktivita, jejímž cílem je vytvoření technických a organizačních prostředků, které by měly pomoci uživatelům při řešení problémů s výkonností komunikace síťových aplikací. Mělo by jít do určité míry o prostředek analogický k organizaci CERT, zabývající se řešením bezpečnostních problémů.

V současné době probíhá pilotní ověřování činnosti PERTu. Přibližně jeden týden v měsíci má CESNET službu, během které má na starosti aktivní řešení otevřených výkonnostních problémů. Poznatky získané během řešení problémů jsou ukládány do databáze pro pozdější referenci a o činnosti v rámci PERTu je veden elektronický deník.

Typickými problémy řešenými v PERTu je náhlé snížení propustnosti mezi účastníky přes evropskou síť Géant, vznik ztrátovosti paketů v určitém místě sítě nebo silně asymetrická propustnost mezi dvěma body.

6.5 Časová synchronizace

Při monitorování sítě je nezbytné přiřazovat jednotlivým událostem (odeslání paketu, přijetí paketu, čtení registrů síťových prvků, atd.) přesné timestampy (časová razítka), které slouží pro měření parametrů sítě (např. zpoždění paketu při průchodu sítí) a pro zpracování statistických dat o provozu sítě. Na timestampy jsou kladeny dva základní požadavky:

přesnost, tj. odchylka od času UTC nesmí převýšit přípustnou hodnotu
rozlišení, tj. perioda hodin generujících timestampy musí být dostatečně krátká, aby žádné dvě následující události nedostaly stejnou hodnotu timestampu.

Při monitorování provozu ve vysokorychlostních sítích se zvyšuje požadovaná přesnost až na úroveň jednotek mikrosekund a rozlišení na desítky nanosekund. Pro splnění těchto požadavků používáme synchronizaci pomocí GPS přijímačů. V prostorách sdružení CESNET je více počítačů, které potřebují přesný čas. Proto jsme navrhli a instalovali distribuční jednotku, která je schopna signál z jednoho přijímače GPS rozbočit na 8 výstupů vedených přes strukturovanou kabeláž k jednotlivým počítačům. Instalaci druhé jednotky plánujeme na leden 2005. Pro použití v některých dalších lokalitách sítě CESNET2, kde je potřeba galvanické oddělení GPS přijímače na střeše a vzdálenost od přijímače je veliká, jsme nechali zhotovit převodníky RS-232 na RS-422 a zpět pro venkovní provedení.

6.6 Dálkový přístup k analyzátoru a generátoru sítě

Ve spolupráci s aktivitou Optické sítě jsme provedli experimentální ověření možnosti dálkového přístupu k analyzátoru a generátoru síťového provozu na rychlosti 10 Gb/s na úrovni fyzické vrstvy (L1). Přístup byl ověřen jako možný na vzdálenost 210 km, předpokládáme, že by bylo za určitých podmínek možné překlenout vzdálenost až 252 km. Technické řešení je ale nákladné a nevyplatí se vzhledem k ceně analyzátoru a generátoru (ačkoliv jeho cena je vysoká, což je motivací pro dálkový přístup). Plánujeme ověřit možnost přístupu na vyšších vrstvách (L2 a L3), které by mělo být ekonomicky výhodnější, přináší však omezení v možnostech využití vlastností analyzátoru a generátoru.

6.7 Plánované aktivity

V dalším období se chceme soustředit na několik oblastí. V rámci projektu LOBSTER budeme pracovat na anonymizaci monitorovaných dat podle požadavku uživatelů a na nasazení platformy SCAMPI pro bezpečnostní monitorování v evropském měřítku. Plánujeme dále pracovat v oblasti paralelních přenosů pro využití vysokorychlostních tras. Chceme vytvořit novou verzi paralelní soketové knihovny umožňující pružnější změnu obsluhy jednotlivých spojení. Dále pak chceme nasadit systém pro plánování výkonnostních testů a zpracování jejich výsledků v rámci naší sítě CESNET2 a upravit ho tak, aby byl kompatibilní se vznikajícím systémem pro výkonnostní monitorování sítě Géant2 v rámci aktivity JRA1. Budeme se samozřejmě nadále podílet na aktivitě PERT.

předchozí

obsah

následující