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á své internetové 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 2006 uvádíme dále.

6.1 Pasivní monitorování v síti CESNET2

Monitorování sítě je užitečné pro její plánování, řešení funkčních, výkonnostních a bezpečnostních problémů. Většinu monitorovacích metod lze rozdělit do následujících čtyř kategorií:

aktivní monitorování,
pasivní monitorování,
vyhodnocování údajů z komponentů sítové infrastruktury,
vyhodnocování stavu koncové stanice.

Při aktivním monitorování posíláme do sítě testovací pakety. Pro některé charakteristiky, například zpoždění, je aktivní monitorování optimální metodou. Pasivní monitorování neposílá do sítě žádné pakety, ale vyhodnocuje přímo vlastnosti uživatelského provozu. Řadu charakteristik lze získat pouze pasivním monitorováním. Například skutečnou volnou kapacitu sítě, informace o bezpečnostních útocích nebo informace o trendech v používání aplikací. Pasivní monitorování je obecně mocnější metoda než aktivní monitorování, vyžaduje ale zpracování velkého objemu dat v reálném čase.

6.1.1 Aplikace ABW

Pro plánování sítě a řešení výkonnostních problémů je užitečné znát zátěž linek v různých časových měřítcích včetně distribuce zátěže mezi jednotlivé protokoly. Tradiční metoda měření zátěže linek spočívá ve čtení čítačů přenesených bajtů na portech směrovačů protokolem SNMP. Takto můžeme získat pouze celkovou zátěž linky bez informace o podílu jednotlivých protokolů. Směrovače navíc aktualizují své čítače s nepravidelným zpožděním, a proto nejkratší časová granularita, pro kterou můžeme takto zjistit průměrnou zátěž, je asi 20 sekund. Ukazuje se, že linky často obsahují krátké a vysoké špičky zátěže, které nelze tímto způsobem detekovat, které ale mohou ovlivňovat propustnost datových přenosů.

Netflow záznamy ze směrovačů mohou být použity pro rozdělení objemu provozu podle jednotlivých TCP a UDP portů. V současnosti je ale stále větší objem provozu přenášen protokoly, které používají dynamická čísla portů.

Pro podrobné monitorování zátěže linek jsme vytvořili aplikaci ABW (Available Bandwidth), která poskytuje následující informace navíc oproti SNMP monitorování:

rozdělení zátěže mezi protokoly různých vrstev OSI modelu (L2, L3, L4 i aplikační protokoly) včetně protokolů používajících dynamické porty,
zátěž v krátkých časových intervalech (1 sekunda a méně) pro detekci špiček.

Obrázek 6.1: Aplikace ABW pro pasivní monitorování zátěže

Aplikace je implementována pomocí middleware DiMAPI (Distributed Monitoring Application Interface) a knihovny trackflib, které byly vytvořeny v projektech SCAMPI a LOBSTER. Architektura aplikace je znázorněna na obrázku. Její činnost lze popsat následovně:

Pakety jsou odbočeny z monitorované linky optickým rozbočovačem nebo monitorovacím portem na přepínači nebo směrovači.
Pakety jsou následně přijaty síťovým adaptérem, což může být běžná síťová karta nebo specializovaný monitorovací adaptér (např. COMBO nebo DAG).
V dalším kroku jsou pakety zpracovány v DiMAPI, které je rozděleno na démony mapid a mapicommd běžící na vzdálených monitorovacích stanicích a tzv. DiMAPI stub, což je knihovna přilinkovaná k aplikaci.
Vlastní aplikace ABW používá konfiguraci určující, které protokoly na kterých vzdálených monitorovacích stanicích mají být monitorovány. Tato konfigurace určuje také další parametry, jako časovou periodu monitorování, omezení monitorovaného provozu hlavičkovou filtrací a podobně.
Výsledky jsou ukládány do souborů RRD (Round Robin Database) nebo zobrazovány na standardním výstupu.
Sada skriptů v jazyce PHP a nástroj rrdtool vytvářejí uživatelské rozhraní.

Při obousměrném monitorování linky může ABW přijímat provoz z každého směru na různých portech, různých síťových adaptérech, na stejné nebo na různých monitorovacích stanicích. Můžeme libovolně promíchat síťové adaptéry přijímající MPLS hlavičky s adaptéry přijímajícími standardní IP pakety. ABW ve všech případech použije správnou klasifikaci provozu a zobrazí správně podíl protokolů v každém směru monitorované linky.

ABW může pracovat v lokálním nebo distribuovaném režimu nebo v jejich kombinaci. V lokálním režimu na každé vzdálené monitorovací stanici pracuje samostatná instance programu ABW a démon mapid (démon mapicommd není použit). Web server kontaktuje pro získání výsledků jednotlivé monitorovací stanice. V distribuovaném režimu běží na vzdálených monitorovacích stanicích démoni mapid a mapicommd (který poskytuje vzdálený přístup k démonu mapid). Program ABW běží pouze na jednom centrálním počítači. Web server kontaktuje pouze centrální počítač. Distribuovaný režim umožňuje jednodušší konfiguraci na web serveru. Lokální režim ale obvykle poskytuje rychlejší odezvu.

Middleware DiMAPI

DiMAPI je middleware pro tvorbu přenositelných monitorovacích aplikací na vyšší úrovni abstrakce. Aplikace si otevře jeden nebo více toků (flows). Každý tok představuje nejprve posloupnost všech paketů přicházejících na jeden nebo více lokálních nebo vzdálených síťových adaptérů (v případě více adaptérů jde o tzv. scope). Aplikace následně nasadí na každý tok posloupnost monitorovacích funkcí. Výběr a pořadí těchto funkcí určuje výsledné monitorování. Jsou k dispozici již hotové monitorovací funkce, například pro hlavičkovou filtraci (BPF_FILTER), hledání řetězců (STR_SEARCH) nebo počítání paketů (PKT_COUNTER). Uživatel ale může také vytvořit své vlastní monitorovací funkce.

Síťové adaptéry

DiMAPI může pracovat nad různými síťovými adaptéry. V současné době jsou podporovány běžné síťové karty, karty COMBO a karty DAG. DiMAPI umí pro určité funkce automaticky využít hardwarové podpory, která je k dispozici, v závislosti na nasazených funkcích a jejich pořadí. Tento proces je plně transparentní pro aplikaci, která zůstává stejná ve zdrojové i binární podobě. To je umožněno samostatnou implementací některých monitorovacích funkcí pro jednotlivé síťové adaptéry. Implementovali jsme do DiMAPI podporu hardwarové filtrace paketů v kartách DAG s koprocesorem, pracujeme na podpoře filtrace v kartách DAG s klasifikací DSM a v kartách COMBO. Specializované adaptéry kromě toho nabízí mnohem efektivnější přenos paketů ze sítě do paměti hostitelského PC.

Detekce aplikačních protokolů

Aplikační protokoly jsou detekovány knihovnou trackflib, která je nyní součástí DiMAPI. Tato knihovna poskytuje monitorovací funkci TRACK sloužící ke klasifikaci paketů do známých protokolů. Knihovna používá kombinaci hlavičkové filtrace a hledání řetězců k identifikaci příslušnosti paketů k protokolům. Hledané řetězce se obvykle nachází blízko začátku paketů, hledání proto může skončit brzy a je efektivní. V současné době knihovna rozpoznává následující aplikace: WWW (není shodné s porty 80 a 443, které bývají používány i jinými protokoly pro snazší průchod přes firewall), FTP (zahrnuje i pasivní spojení), Skype, BitTorrent, Gnutella, DC++ a eDonkey.

Nasazení aplikace ABW v CESNETu

Instalovali jsme 10 monitorovacích stanic používajících pasivní monitorování a aplikaci ABW. Jedna stanice monitoruje linku do sítě GÉANT2, ostatní stanice monitorují různá přístupová místa do páteřní sítě CESNET2. Rozmístění stanic je znázorněno na obrázku. Provoz stanic je trvale kontrolován testovacími skripty. Stanice pro monitorování linky do sítě GÉANT2 je vybavena dvěma kartami DAG. Ostatní stanice jsou vybaveny běžnými síťovými kartami. Plánujeme vybavit stanice monitorující velký objem provozu dalšími monitorovacími kartami.

Obrázek 6.2: Nasazení aplikace ABW v CESNETu (větší obrázek)

Aktuální a archivní naměřené hodnoty jsou k dispozici na stránce výsledků. Monitorování linky do sítě GÉANT2 je přístupné pro veřejnost, monitorování páteřní sítě CESNET2 je k dispozici po zadání uživatelského jména a hesla autentizačního systému CAAS.

Příklady výstupů

Uživatelské rozhraní ABW je znázorněno na obrázku. Uživatel si zvolí jeden nebo více typů grafů - distribuci L4 protokolů (včetně informace o multicastu a IPv6) nebo distribuci aplikačních protokolů. Potom si uživatel zvolí jednu nebo více monitorovacích stanic a jedno nebo více časových období a časových granularit, pro něž mají být síťové charakteristiky získány z databáze a graficky znázorněny. Granularita určuje krok grafu, pro který mají být počítány průměrné a maximální hodnoty.

Obrázek 6.3: Uživatelské rozhraní aplikace ABW

Příklad rozložení L4 protokolů je na obrázku. Charakteristiky jsou vždy počítány pro dvě časové granularity. Jemnější granularita je použita v hlavním grafu (v daném příkladu 1 sekunda) a hrubší granularita v obalových křivkách průměrných a maximálních hodnot (v daném příkladu 30 sekund). Je možné si všimnout, že hlavní graf obsahuje řadu vysokých špiček, které nejsou v obalových křivkách vidět. Třicetisekundové průměry zátěže se pohybovaly okolo 150 Mb/s, zatímco řada krátkých špiček dosahovala přes 300 Mb/s.

Obrázek 6.4: Detekce špiček zátěže

Příklad rozložení aplikačních protokolů je na obrázku. Je vidět, že bylo detekováno několik protokolů používajících dynamické porty. Detekce těchto protokolů poskytne podrobný obraz o struktuře zatížení linky.

Obrázek 6.5: Rozložení aplikačních protokolů

Další příklad rozložení L4 protokolů obsahuje obrázek. Kromě krátkých špiček si můžeme povšimnout, že objem protokolu UDP se téměř shoduje s objemem multicastu, což je v současné době obvyklý jev.

Obrázek 6.6: Rozložení L4 protokolů s multicastem

Na posledním příkladu na obrázku můžeme vidět zátěž v delším časovém období.

Obrázek 6.7: Aplikační protokoly v delším období

6.2 Infrastruktura pro řešení výkonnostních problémů datových přenosů

Přestože páteřní linky sítí mají dnes velikou instalovanou kapacitu, dochází někdy k tomu, že datové přenosy mají nedostatečnou propustnost. Většina dat je nyní přenášena protokolem TCP. Nedostatečná propustnost může být důsledkem jedné nebo více následujících skutečností, v pořadí od fyzické vrstvy sítě směrem k aplikacím:

problém nebo omezení v síťové infrastruktuře (např. vadný transceiver, špatné nastavení full/half duplexu, přetížení síťového procesoru),
nedostatečná volná kapacita v síťové trase,
omezení v hardware koncové stanice (např. rychlost CPU, paměti a sběrnic),
omezení v operačním systému koncové stanice (např. malé soketové vyrovnávací paměti, vysoká režie obsluhy přerušení, nevhodné řízení toku v transportním protokolu),
omezení v aplikaci (např. špatné využití kapacity CPU).

Pro detekci úzkého místa v komunikační trase obvykle používáme sadu nástrojů a technik, mimo jiné následující (nejde o úplný výčet):

testovací přenosy nástrojem iperf,
odchycení paketů nástrojem tcpdump a jejich analýza nástroji tcptrace a xplot,
sledování runtime TCP proměnných pomocí rozšíření jádra operačního systému web100,
sledování výkonnostních čítačů v koncové stanici pomocí knihovny PAPI,
nastavení limitů soketových vyrovnávacích pamětí pomocí sysctl,
sledování zatížení CPU a využití paměti pomocí top a ps,
sledování aktivity přerušení v souboru /proc/interrupts,
sledování aktivity volání jádra pomocí strace.

Analýza odchycených paketů a sledování runtime TCP proměnných obvykle vyžadují řadu iterací (v důsledku měnících se podmínek v síti) a manuální proložení informací z různých zdrojů, což je pracné a časově náročné.

Rozhodli jsme se proto vyvinout integrovanou sadu nástrojů se společným uživatelským rozhraním nazvanou tbwtools, usnadňující ladění výkonnostních problémů TCP přenosů.

6.2.1 Požadavky

Definovali jsme následující množinu požadavků:

zobrazení charakteristik získaných z odchycených paketů (tcpdump), runtime TCP proměnných z web100 a soketových vlastností z nástroje bulk,
všechny charakteristiky musí být korelovány na časové ose a zobrazeny ve společném rozhraní,
systém musí být snadno rozšiřitelný o nové charakteristiky,
uživateli musí stačit běžný webovský prohlížeč,
musí být možné provést testovací spojení mezi PC uživatele a vzdáleným počítačem nebo mezi dvěma vzdálenými počítači,
vytvořený systém musí komunikovat se systémem perfSONAR pro monitorování sítě GÉANT2.

Předpokládáme následující způsoby používání systému tbwtools:

uživatel provede testovací spojení a sám vyhodnotí naměřené charakteristiky,
uživatel provede testovací spojení a zašle získané identifikační číslo testu odborníkovi v oblasti přenosových protokolů, který použije identifikační číslo k získání výsledků a analyzuje je,
uživatel nahraje do systému soubor s odchycenými pakety spojení získaný jinými prostředky a požádá systém o analýzu souboru (pouze charakteristiky počítané z odchycených paketů mohou být získány tímto způsobem).

6.2.2 Systém tbwtools

Komunikace mezi komponenty systému tbwtools je znázorněna na obrázku. Uživatelské rozhraní je implementováno v jazyce Java jako aplet pro webovský prohlížeč. Použití je rozděleno do dvou fází. Uživatel nejprve provede testovací spojení a potom nechá vytvořit grafy znázorňující charakteristiky tohoto spojení.

Obrázek 6.8: Struktura systému tbwtools

Fáze testovacího spojení

Pro testovací spojení jsme vytvořili nástroj bulk, který pracuje podobně jako známý nástroj iperf, ale má navíc zabudované monitorování soketových vlastností během spojení. Nejzajímavější vlastností s řadou údajů o spojení je TCP_INFO. Aby bylo možné testovat trasu směrem k PC uživatele, zabudovali jsme část nástroje bulk provádějící testovací spojení také do apletu uživatelského rozhraní (bez monitorování soketových vlastností, které nejsou v operačním systému Windows k dispozici).

Abychom mohli provádět testovací spojení přes síť, je potřeba ve vhodných místech instalovat systém tbwtools. Ten je řešen jako měřící bod (Measurement Point - MP) systému perfSONAR. To znamená, že řídicí komunikace mezi apletem a měřícím bodem probíhá pomocí zpráv ve formátu XML s elementy podle doporučení NMWG (Network Monitoring Working Group). Měřící body se budou v budoucnu registrovat k vyhledávací službě (Lookup Service - LS) systému perfSONAR. Formát zpráv a tato registrace umožňují vzájemnou komunikaci obou systémů. Použití apletu není nutné, uživatel může použít klient systému perfSONAR pro komunikaci s měřícím bodem systému tbwtools.

Aplet prezentuje uživateli rozhraní znázorněné na obrázku. Uživatel může provést testovací spojení (volba 1a) mezi zadaným měřícím bodem a zadanou IP adresou. Zde je předem vyplněna adresa uživatelova PC, ale je možné zadat jinou adresu nebo jméno, například jiného měřícího bodu. Je také možné zvolit směr a dobu spojení. Druhou možností (volba 1b) je nahrát soubor s odchycenými pakety již provedeného spojení. V okně v dolní části apletu (2) je možné sledovat zprávy o průběhu měření a komunikaci mezi apletem a měřícím bodem ve formátu XML.

Obrázek 6.9: Testovací spojení v systému tbwtools

Fáze analýzy a grafické prezentace

Data získaná z odchycených paketů, runtime TCP proměnné a soketové vlastnosti jsou společně zpracována nástrojem tbwsyn a převedena do grafické podoby nástrojem gengraph. Výsledné grafy a tabulkové shrnutí informací o spojení jsou přeneseny na web server a prezentovány uživateli.

Nejprve je zobrazena nabídka možných charakteristik spojení, jak je vidět na obrázku. Proměnné jsou rozděleny do sekcí podle zdroje informací na proměnné z odchycených paketů (3a), soketové vlastnosti (3b) a runtime TCP proměnné (3c). V dolní části formuláře (4) je možné zvolit časový úsek spojení, který má být zobrazen.

Obrázek 6.10: Výběr charakteristik spojení v systému tbwtools

Příklad grafů několika charakteristik je uveden na obrázku. Jde o okénko vysílače (cwnd) z nástroje bulk, objem duplikovaných dat z rozšíření web100, časový vývoj proměnné tcpthresh z nástroje bulk a konečně frekvence duplikací potvrzení z odchycených paketů. Je vidět, že informace získané různým způsobem z různých zdrojů jsou prezentovány jednotně. Pomocí těchto charakteristik získáme podrobné informace o chování testovacího spojení a můžeme určit pravděpodobnou příčinu malé propustnosti.

Obrázek 6.11: Příklad grafů ze systému tbwtools (větší obrázek)

Nástroje systému tbwtools

Kromě práce s jednotným uživatelským rozhraním v apletu může být užitečné některé nástroje systému tbwtools použít přímo.

bulk

Nástroj bulk používá volání getsockopt() po každém volání send() na vysílači nebo recv() na přijímači pro čtení soketových vlastností. Kromě standardních vlastností umí pracovat i s vlastností TCP_AIMD přidanou pomocí AIMD patche, který jsme vytvořili pro konfiguraci a monitorování řízení zahlcení (congestion control) jednotlivých TCP spojení. Například následující příkaz spustí testovací spojení na počítač perfmon1.cesnet.cz posílající data po blocích 16 kB a monitorující okénko vysílače a RTT spojení:

bulk2 -b16384 -gSnd_Cwnd,rtt perfmon1.cesnet.cz

wread

Nástroj wread slouží ke čtení runtime TCP proměnných udržovaných rozšířením web100. Například následující příkaz bude vypisovat počet odeslaných a přijatých paketů s periodou 100 ms u spojení mezi počítači perfmon1.cesnet.cz a perfmon2.cesnet.cz:

wread perfmon1.cesnet.cz 2000 perfmon2.cesnet.cz 2001 100000 PktsOut PktsIn

6.3 Synchronizace času a monitorování služby NTP

V průběhu roku 2006 jsme uvedli do provozu další monitorovací stanice v uzlech sítě CESNET2. Na každé této stanici bylo třeba zajistit přesně synchronizovaný čas důležitý pro některá měření, například jednosměrného zpoždění. V osmi uzlech jsme instalovali GPS přijímače (v ostatních uzlech to zatím z konstrukčních důvodů nebylo možné). Provozujeme také vlastní primární časové servery NTP. V rutinním provozu nebo v rámci mezinárodních projektů je nyní instalováno více než 20 počítačů vyžívajících tyto NTP servery. Dosud jsme neměli k dispozici nástroj pro sledování kvality časové synchronizace, například odchylky od času UTC. Běžné monitorovací nástroje (např. Nagios) mohou detekovat aktivní proces NTP, nikoliv však sbírat jeho parametry a vyhodnotit přesnost časové synchronizace. Proto jsme vytvořili vlastní systém pro monitorování služby NTP.

Monitorovací systém NTP se skládá z několika funkčních bloků:

sběr dat,
generování grafů kvantitativních parametrů,
databáze kvalitativních parametrů,
databáze událostí,
kontrola překročení mezních hodnot.

Monitorovací systém pracuje s daty získanými různými způsoby:

dotaz na parametry procesu ntpd pomocí funkce ntpq -c rl,
data zjištěná NTP klientem, který se dotazuje NTP serveru na jeho čas,
pomocí protokolu SNMP (dosud není implementováno, protože současné instalace NTP tuto možnost nepodporují, specifikace MIB zatím existuje jen jako draft IETF).

Nejdůležitější kvantitativní parametry jsou zobrazeny graficky. Jedná se o posun času (time offset), zpoždění paketů mezi serverem a monitorovacím systémem (delay), relativní změny frekvence (frequency change) a akumulovaný rozptyl zpoždění od primárního zdroje (root dispersion). Grafy jsou generovány pro období posledních 6 hodin, posledních 24 hodin, vybraný den, týden a rok.

Do databáze jsou ukládány kvalitativní parametry, např. stav systému, synchronizační zdroj, stratum, významné události, např. restart systému, ztráta synchronizace, změna verze operačního systému nebo ntp, a dále překročení sledovaných prahových hodnot. Závažné události jsou hlášeny elektronickou poštou.

6.3.1 Upgrade NTP serverů

Časový server tik.cesnet.cz (alias ntp.cesnet.cz) je uveden v seznamu primárních t.j. stratum-1 NTP serverů. Je využíván nejen v rámci sítě CESNET2, ale v souladu s jeho statutem i jako referenční server mnoha sekundárních NTP serverů v České republice i jinde v Evropě. V roce 2006 došlo k nahrazení jeho hardware novým systémem, protože výkonově již nestačil stále se zvyšující zátěži.

Nový server má zprovozněnu autentizaci na principu distribuce veřejných klíčů podle tzv. Schnorrova schématu. Klient systému NTP si tak může ověřit, že komunikuje skutečně s naším časovým serverem a naopak náš server je chráněn před kompromitací.

6.3.2 Atomové hodiny

Atomové hodiny, u nichž je frekvence oscilátoru odvozena od změn energetických hladin elektronů, jsou dnes nejlepší možností jak získat přesný a do značné míry nezávislý zdroj času.

Základem hodin je vysoce přesný modul oscilátoru, jehož frekvence je řízena rubidiovým rezonátorem. Dosažená stabilita kmitočtu je řádu 10^-12. Dlouhodobá stabilita je zajištěna vstupním signálem 1PPS (1 pulse per second) z přijímače GPS. Rubidiové hodiny jsou schopny dosáhnout přesnosti času lepší než 1 us i v případě, kdy není signál z GPS k dispozici po několik dní.

Rubidiové hodiny jsme vestavěli do šasi o výšce 2U. Celý systém se skládá z následujících funkčních celků:

Rubidiový oscilátor: Jedná se o typ PRS-10 od firmy Stanford Research Systems. Modul má vstup pro referenční signál 1PPS, výstup 1PPS a výstup 10 MHz. Stabilita frekvence je 5×10^-12/den, fázová odchylka výstupního signálu 1PPS je menší než 10 ns. Modul je dále vybaven sériovým portem pro řízení.
Řídicí počítač: Základem řídicího počítače je základní deska typu VIA EPIA formátu mini-ITX. Řídicí počítač slouží k monitorování a nastavování parametrů rubidiového oscilátoru a ke sledování vstupního signálu 1PPS.
Zálohovaný zdroj 24 V: Rubidiový oscilátor je napájen ze stabilizovaného zdroje 24 V. Zdroj je tvořen měničem 12 V-24 V, olověným akumulátorem 12V/9Ah a logikou pro nabíjení akumulátoru. Akumulátor je schopen napájet oscilátor a výstupní obvody po dobu nejméně 5 hodin.
Vstupní/výstupní obvody: Vstupní a výstupní obvody 1PPS slouží k impedančnímu přizpůsobení a k indikaci přítomnosti signálu. Hodiny mají celkem 3 oddělené výstupy 1PPS, výstup referenční frekvence 10 MHz a výstup DDS.

Hodiny jsou připraveny k vestavbě modulu DDS (direct digital synthesis), který bude využívat přesnou frekvencí 10 MHz. Modul DDS lze naprogramovat na generování libovolného kmitočtu do cca 20 MHz s krokem menším než 10^-6 Hz.

Zálohované napájení umožní provést časovou kalibraci soustavy atomové hodiny, GPS přijímač a propojovací kabel. Hodiny lze převézt do místa, kde je k dispozici z metrologického hlediska přesný zdroj času, tam je nastavit a bez vypnutí dovézt zpět. Kalibrace pak závisí na změřeném fázovém rozdílu signálů 1PPS seřízených hodin a GPS přijímače. Dosažená přesnost kalibrace je určena maximální odchylkou času hodin mezi okamžikem seřízení a měření. V našem případě bude přesnost kalibrace v řádu desítek nanosekund, protože doba převozu je cca 1 hodina a stabilita hodin je v řádu 10^-12.

6.4 Systém perfSONAR

Pro monitorování různých charakteristik sítí je dnes používána řada nástrojů. Z praktického hlediska se jeví účelné různé nástroje integrovat tak, aby si mohly vyměňovat data, abychom mohli měřit přes několik sítí, které jsou ve správě různých subjektů a aby výsledné charakteristiky byly prezentovány pokud možno v jednotném uživatelském rozhraní.

Za účelem integrace monitorovacích nástrojů je v rámci aktivity JRA1 projektu GN2 vytvářen systém nazvaný perfSONAR. Architektura tohoto systému je založena na tzv. webovských službách (web services), neboli jde o sadu samostatně pracujících služeb komunikujících posíláním XML zpráv. Nejdůležitější služby jsou následující:

měřící bod (Measurement Point - MP),
měřící archív (Measurement Archive - MA),
vyhledávací služba (Lookup Service - LS),
uživatelské rozhraní (perfSONAR UI).

Měřící bod komunikuje na jedné straně s určitým monitorovacím nástrojem a na druhé straně se zbývající částí systému perfSONAR. Vytváří tak jednotné rozhraní pro komunikaci s monitorovacími nástroji. Měřící archív pracuje shodně, ale navíc obsahuje vnitřní paměť pro archivaci dat. Vyhledávací služba slouží pro registraci a opětovné vyhledávání adres instalací ostatních služeb.

V CESNETu jsme vytvořili několik měřících bodů nebo archívů pro přístup k námi vyvinutým monitorovacím nástrojům. Například modul G3 MA zpřístupňuje data z aplikace G3 pro SNMP monitorování. Měřená data lze potom zobrazit v modulu perfSONAR UI. Dříve popsaný systém tbwtools také obsahuje modul měřícího bodu tbw MP, který může komunikovat se systémem perfSONAR.

6.5 Další činnosti

V rámci naší výzkumné aktivity jsme v roce 2006 vytvořili řadu dalších zajímavých výstupů podrobně popsaných v publikovaných nebo připravovaných technických zprávách. Níže uvádíme krátké shrnutí dalších provedených činností. V příštím roce plánujeme další rozvoj v těchto oblastech.

Sledování dynamiky provozu pomocí programovatelného hardware: Vytvořili jsme jednotku firmware pro karty řady COMBO umožňující v reálném čase kvantifikovat dávkovost paketů (t.j. dynamiku zátěže) na monitorované lince. Jednotku jsme integrovali do designu SCAMPI a NIFIC. Pracujeme na softwarové podpoře jednotky.
Univerzální platforma pro zpracování paketů rychlostí 10 Gb/s: Vytvořili jsme prototyp univerzální platformy umožňující vysokorychlostní zpracování paketů (příjem a posílání) pomocí programovatelného hardware. Využíváme průmyslově dostupných univerzálních desek, které jsme vestavěli do šasi o výšce 1U a vytvořili jsme vlastní základní firmware zpřístupňující periferie desek. Ověřili jsme příjem a vysílání paketů rychlostí 10 Gb/s.
Knihovna pro klasifikaci paketů pomocí karet řady COMBO: Vytvořili jsme knihovnu umožňující aplikacím využít hardwarovou klasifikaci v kartách řady COMBO. Knihovna přijímá specifikaci filtrů ve standardním formátu knihovny libpcap.
Anonymizace hlaviček paketů pomocí programovatelného hardware: Vytvořili jsme programovatelnou jednotku umožňující flexibilní anonymizaci hlaviček paketů při pasivním monitorování. Integrovali jsme jednotku do firmware SCAMPI pro karty řady COMBO.
Zpracování a prezentace měření projektu RIPE-TTM: Vytvořili jsme systém pro zpracování dat a prezentaci aktuálních i archivních dat ze systému RIPE-TTM pro měření zpoždění a ztrátovosti přes rozsáhlou část Internetu.

předchozí

obsah

následující