hledat:

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 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 dosažených v roce 2005 uvádíme dále.

6.1   Monitorování výkonnostních charakteristik sítě CESNET2

Abychom měli přehled o základních výkonnostních charakteristikách sítě CESNET2 rozhodli jsme se instalovat postupně v každém významném uzlu jednu monitorovací stanici. V současné době je instalováno 7 monitorovacích stanic, jak je znázorněno na obrázku. Instalace dalších 2 stanic znázorněných v šedé barvě bude realizována do konce roku. Každá stanice je vybavena jedním síťovým rozhraním pro konektivitu a aktivní měření a jedním až dvěma dalšími rozhraními připravenými pro pasivní monitorování. Aktivní měření nám umožňuje monitorovat zpoždění, ztrátovost a propustnost. Spouštění jednotlivých měření a zpracování výsledků je řešeno našimi vlastními skripty. V příštím roce plánujeme vývoj aplikací pasivního monitorování a jejich nasazení. Rovněž plánujeme využití systému pro plánování výkonnostních testů perfSONAR, který je vyvíjen v rámci aktivity JRA1 projektu GN2 a na jehož vývoji se také podílíme.

6.2   Synchronizace času

Měření některých charakteristik, zejména jednosměrného zpoždění, vyžaduje přesnou časovou synchronizaci mezi monitorovacími stanicemi. V principu je možné použít synchronizaci přes síť pomocí protokolu NTP, ale tímto způsobem nelze dosáhnout požadované přesnosti a zejména by nešlo věrohodně měřit zpoždění na linkách, po nichž se synchronizace provádí. Rozhodli jsme se proto vybavit každou monitorovací stanici nezávislým externím zdrojem času. Po vyhodnocení cenové náročnosti několika variant přijímačů GPS a DCF jsme zvolili následující typové řešení:

• přijímač Garmin GPS 18 (nebo GPS 35)
• konvertory rozhraní RS-232 <-> RS-422
• připojení přijímače na sériový port

Měřicí stanice mají instalován operační systém Linux, jádro 2.4.29 s tzv. "nanokernel patch" (pro jádra řady 2.6 není nanokernel k dispozici). Synchronizaci času zajišťuje program ntpd ve verzi 4.2.0.

V současné době je typové řešení instalováno v Brně, Plzni, Českých Budějovicích a Olomouci. Instalace se připravuje v Ústí nad Labem a v Hradci Králové. V Praze je synchronizace monitorovací stanice zajištěna GPS přijímačem Trimble Acutime 2000, jehož signál je rozveden na serverovém sále. Také v Ostravě byl použit signál již existujícího přijímače (geodetický GPS přijímač Topcon GB-1000). V Liberci se zatím bohužel nepodařilo GPS přijímač instalovat.

Pro zvýšení kvality synchronizace jsme instalovali rubidiové hodiny PRS-10 firmy Stanford Research System s frekvenční stabilitou 5×10^-12. V praxi to znamená, že naše časové servery budou schopny udržet přesnost času v řádu mikrosekund po dobu několika dnů i bez GPS.

V roce 2006 plánujeme vytvořit systém pro kontrolu stavu a kvality synchronizace času v jednotlivých měřicích stanicích a časových serverech. Systém bude schopen doložit přesnost časové synchronizace a upozornit na případný chybový stav. Tím se zvýší věrohodnost našich budoucích měření.

6.3   Paralelní přenosy

Řízení zahlcení ovládané ve standardním protokolu TCP algoritmem AIMD(1, 0.5) je pro rozlehlé vysokorychlostní sítě příliš pomalé a není schopné plně využít šířku pásma. Možným řešením je použít některou z implementací "fast TCP" s agresívnějším řízením zahlcení nebo například AIMD patch vyvinutý v rámci naší aktivity. To ale vyžaduje přístup uživatele root do operačního systému a restartování počítače. Alternativní možností zvýšení propustnosti je použití paralelních přenosů. V této oblasti jsme začali pracovat již v roce 2004, v letošním roce jsme zcela přepracovali paralelní soketovou knihovnu psock, která je univerzálním prostředkem pro využití paralelních přenosů v aplikacích. Knihovnu je možné získat na WWW stránkách naší aktivity.

6.3.1   Implementace knihovny psock

Pro implementaci jsme si stanovili následující požadavky:

• Paralelní přenosy musí být snadno použitelné v existujících síťových aplikacích využívajících standardní soketovou knihovnu BSD.
• Distribuce dat do dílčích přenosů musí umět využít různou a měnící se šířku pásma dílčích přenosů, pomalejší dílčí přenos nesmí brzdit rychelší.
• Metoda distribuce dat do dílčích přenosů musí být konfigurovatelná.
• Architektura musí umožnit paralelní provádění na paralelním počítači.

Aplikace používající knihovnu psock běží ve vlákně knihovny. Psock dále vytvoří nové vlákno protokolu, které posílá data do dílčích přenosů a řídí paralelní přenos. Obě vlákna spolu komunikují asynchronně předáváním zpráv přes rozhraní PSCIF (Parallel Socket Control Interface). Architektura knihovny psock je znázorněna na obrázku.

Vlákno protokolu používá řídící soket (1) k výměně řídicích informací s druhou stranou. Mezi tyto informace patří například dohoda o počtu dílčích přenosů, oznámení čísel portů nebo dohoda použitého ovladače paralelního přenosu.

Vlákno protokolu dále čeká na události na soketech dílčích přenosů (2), čte z nich hlavičky bloků a připravuje plánovací tabulku paralelního přenosu. Vlákno knihovny používá tuto tabulku k řízení multiplexování a demultiplexování dat do a z dílčích přenosů.

6.3.2   Plánovací tabulka paralelního přenosu

Plánovací tabulka paralelního přenosu je tvořena dvěma kruhovými buffery, jedním pro odesílání a jedním pro příjem dat. Tyto buffery neobsahují přímo vlastní data, uvnitř knihovny nedochází k žádnému kopírování dat. Každá položka bufferu obsahuje číslo dílčího přenosu, který má být použit jako následující pro posílání nebo čtení dat, a počet bajtů, jež mohou být daným dílčím přenosem odeslány nebo z něj přijaty. Ke každému bufferu je udržován ukazatel na položku, která má být jako další použita vláknem knihovny. Je-li tato položka prázdná (žádný dílčí přenos není k dispozici pro odeslání nebo příjem dat), musí vlákno knihovny počkat, až bude tato položka naplněna vláknem protokolu. Stav tabulky pro tři dílčí přenosy může vypadat následovně:

6.3.3   Ovladač round-robin

Způsob distribuce dat do dílčích přenosů je určen ovladačem paralelního přenosu. Součástí implementace psock jsou zatím dva ovladače. Prvním z nich je ovladač round-robin, který posílá data v blocích stejné délky cyklicky jednotlivými dílčími spojeními. Propustnost paralelního přenosu je c=n×min(c_i), kde c_i je propustnost i-tého dílčího přenosu a n je počet dílčích přenosů.

6.3.4   Ovladač poll-all

Ovladač poll-all používá volání poll() na soketech všech dílčích přenosů. Data jsou distribuována do dílčích přenosů podle jejich připravenosti k odesílání. Vysílač může využít různou a měnící se propustnost dílčích přenosů. Datové bloky jsou číslovány, aby mohly být sestaveny do původního pořadí. Pokud některý blok předběhne jiné bloky tak, že záznam o něm se nevejde to plánovací tabulky, je poznamenán do struktury farsched_list připojené k položce bufferu, do které bude záznam později přemístěn.

6.3.5   Ověření vlastností knihovny psock

Knihovnu psock jsme testovali v řadě situací. Zde vybíráme dva zajímavé scénáře.

Ovladače round-robin a poll-all na různých fyzických cestách

Mezi vysílačem a přijímačem vzdálenými asi 260 km (umístěnými v Praze a v Brně) byly dvě samostatné fyzické cesty. Jejich instalovaná propustnost byla 155 Mb/s a 620 Mb/s. Konfigurace je znázorněna na obrázku.

Měřili jsme propustnost pomocí programu iperf. Soketové buffery byly o něco větší než součin propustnosti každého dílčího přenosu a RTT.

• TCP propustnost dílčích spojení byla 142 Mb/s a 567 Mb/s, což bylo velmi blízko fyzické propustnosti.
• TCP propustnost paralelního přenosu s ovladačem round-robin byla 282,6 Mb/s, což bylo podle očekávání blízko dvojnásobku propustnosti pomalejšího dílčího přenosu.
• TCP propustnost paralelního přenosu s ovladačem poll-all byla 707,1 Mb/s, což bylo podle očekávání blízko součtu propustnosti dílčích spojení.

Test potvrdil schopnost ovladače poll-all využít různé kapacity paralelních tras použitých k přenosu.

Ovladače round-robin a poll-all a kolísání volné kapacity

Obě linky jsme zkonfigurovali na stejnou fyzickou propustnost 310 Mb/s. Měřili jsme propustnost paralelního přenosu pomocí programu iperf po dobu 15 sekund. V době 5 až 10 sekund jsme přidali další tok TCP jako zátěž v pozadí. Naměřená propustnost je znázorněna na obrázku. V dolní části obrázku je znázorněna i propustnost toku v pozadí. Můžeme vidět, že ovladač poll-all dokázal udržet podstatně větší propustnost paralelního přenosu než ovladač round-robin využitím aktuální volné kapacity linek jen s malým snížením propustnosti toku v pozadí.

Výhody naší knihovny psock oproti existujícím implementacím paralelních přenosů představují možnost použití existující implementace TCP v jádře operačního systému (standardní TCP nebo "fast TCP"), jednoduchá úprava stávajících síťových aplikací a možnost využití šířky pásma různých paralelních kanálů, jakož i možnost experimentů s algoritmy pro distribuci dat do paralelních kanálů.

6.4   Rozvoj firmware pro hardwarovou podporu monitorování

CESNET ve spolupráci s Masarykovou univerzitou a VUT v Brně již delší dobu pracuje na vývoji firmware pro hardwarovou podporu monitorování na kartách COMBO, vyvinutých v rámci projektů Liberouter a SCAMPI. Kapacita stávajícího týmu vývojářů je však již vyčerpána a protože se objevují další aktivity a projekty, pro které může být využití programovatelného hardware velmi užitečné, rozhodli jsme se vytvořit nové pracoviště pro vývoj programovatelného hardware. Pracoviště vzniká ve spolupráci s Katedrou telekomunikační techniky a Katedrou počítačů FEL ČVUT v rámci projektu Fondu rozvoje sdružení CESNET. Do konce roku 2005 budou instalovány dva počítače vybavené kartami COMBO a potřebným vývojovým software. Tyto počítače budou využity během výuky. Nezávisle na tom jsme úspěšně rozběhli vývoj programovatelného hardware pro anonymizaci dat v hlavičkách paketů.

6.4.1   Hardwarová anonymizace hlaviček paketů

Při pasivním monitorování pracujeme přímo s pakety odeslanými uživatelskými aplikacemi (nikoliv s testovacími pakety). Odchycené toky reálného provozu jsou velmi užitečné pro výzkum v různých oblastech - od bezpečnostních aplikací přes směrovací protokoly. Zároveň je však důležité zajistit důvěrnost dat uživatelů. Proto je třeba z odchycených paketů odstranit důvěrné informace, avšak zachovat původní dynamiku provozu.

V rámci projektu LOBSTER pracujeme na programovatelné anonymizaci dat. Ta probíhá ve dvou úrovních. Nižší úroveň (first-tier) bude realizována přímo v hardware monitorovacího adaptéru. Vyšší úroveň (second-tier) bude probíhat dále v monitorovacím software. Anonymizace v software může být složitější, výhodou anonymizace v hardware je vyšší rychlost a to, že se citlivá data vůbec nedostanou do počítače, v němž je umístěn monitorovací adaptér. CESNET je v rámci projektu zodpovědný za hardwarovou anonymizaci.

Hardwarovou anonymizaci jsme navrhli a implementovali v podobě nové jednotky TU (Transformation Unit) přidané do monitorovacího firmware vytvořeného v rámci projektu SCAMPI. Struktura jednotky TU je znázorněna na obrázku. Jednotka TU je navržena jako tzv. nanoprocesor. Jde o hardwarovou jednotku, která pro každý přijatý paket provede specifikovaný nanoprogram z instrukční sady rozpoznávané jednotkou.

Jednotka TU umí v současné době zpracovávat následující položky v hlavičkách paketů:

• Zdrojová a cílová IP adresa
• Zdrojový a cílový TCP nebo UDP port
• Jakákoliv položka o šířce 16 nebo 8 bitů, jejíž pozice je zadána vůči některé z předcházejících položek

Jednotka TU tedy může pracovat v podstatě s jakýmikoliv položkami v hlavičkách paketů. Transformace, které může jednotka TU nad těmito položkami provádět, jsou následující:

• nastavení na zadanou hodnotu
• nastavení na pseudonáhodnou hodnotu
• operace XOR se zadanou hodnotou

Jednotku TU jsme implementovali a úspěšně otestovali na hardware COMBO karty. V současné době pracujeme na dalších typech transformací. Nejzajímavější bude mapování IP adres se zachováním délek prefixů.

předchozí

obsah

následující