5 Sledování infrastruktury a provozu sítě
V této aktivitě se zabýváme návrhem, vývojem a optimalizací užití prostředků pro systematické dlouhodobé a plošné sledování dějů v síti. Soustřeďujeme se na dva základní okruhy problematiky.
V oblasti sledování infrastruktury sítě se zaměřujeme na zpracování a poskytování informací primárně získaných ze souboru technických prostředků, které síťovou infrastrukturu vytvářejí, a to prakticky bez ohledu na vrstvu sítě, ve které ten či onen prvek dominantně pracuje. Snažíme se vyvíjet prostředky, které by byly schopny poskytnout jak detailní, tak souhrnné informace o konkrétních parametrech, zachytily alespoň určitou míru dynamiky jevů v síti a na úrovni vizualizace dokázaly na základě aktuální potřeby pracovat s různou logickou strukturu síťových prvků a provádět tomu odpovídající agregaci průběhů požadovaných veličin. Základním zdrojem informací o stavu jednotlivých prvků infrastruktury sítě je pro nás SNMP (Simple Network Management Protocol). Námi přidaná hodnota spočívá v hledání nestandardních způsobů zpracování a zprostředkování takto získaných informací.
V oblasti sledování provozu sítě provádíme analýzu toho, co je síťovou infrastrukturou přenášeno. Zde se zaměřujeme na provoz přenesený protokolem IP (IPv4 i IPv6) a na zpracování provozních záznamů založených na bázi toků, které tento provoz v agregované podobě popisují. Naším primárním zdrojem provozních informací jsou páteřní směrovače sítě CESNET2 a sondy FlowMon vyvíjené v rámci aktivity Programovatelný hardware. Naší snahou je postupný vývoj flexibilních a škálovatelných řešení pro analýzu provozu (v distribuované architektuře), která jsou schopna poskytnout velmi široké spektrum informací o IP provozu a budou, kromě jiného, podpůrným nástrojem v oblasti bezpečnostní problematiky a při řešení incidentů.
5.1 Sledování infrastruktury sítě
Nosným prvkem naší činnosti v této oblasti je vývoj systému G3. V roce 2009 jsme se v rámci jeho vývoje zaměřili na rozšíření měřicích vlastností systému v oblastech, které jsou významné z hlediska rozvoje páteřní sítě a jejích služeb a v oblastech, které ovlivňují přesnost nastavení běhu systému a jeho stabilitu. Změny se dotkly i uživatelského rozhraní a souvisejícího elektronického klienta (modul G3 reporter). Nejvýznamnější rozšíření systému jsou detailněji popsána v technické zprávě [Koš09]. Kromě vývoje systému G3 jsme vytvořili i několik dalších nástrojů jako podporu různých monitorovacích aktivit v rámci výzkumného záměru.
5.1.1 Měřicí část systému G3
Vytvořili jsme nový SNMP modul pro sběr informací z jednotlivých zařízení, který se opírá o rozšířenou knihovnu net-snmp. Tímto vznikla alternativa ke stávajícímu základnímu modulu založenému na bázi knihovny snmp-session. Pro vlastní sběr dat jsou knihovny volitelné až na úroveň konkrétních monitorovaných zařízení. Motivací bylo maximální zefektivnění sběru dat z některých specifických prvků, kdy i marginální rozdíly v možnostech jednotlivých knihoven mohou hrát významnou roli.
Implementovali jsme první verzi konfigurace měřených položek pro sběr hodnot z modulární monitorovací platformy (MTPP) vyvíjené aktivitou Sledování a optimalizace výkonnostních charakteristik. Vytvořili jsme schéma popisující logickou strukturu zařízení, nadefinovali základní položky popisující souhrnné informace o provozu a následně položky reprezentující čítače a tabulky distribuce paketů podle délky. Pro potřebu kolegů z téže aktivity jsme rozšířili aplikaci pro sběr dat protokolem SNMP ze zabezpečené sítě prostřednictvím oprávněného uzlu tak, že tento uzel automaticky překládá cílové adresy v požadavku (což mohou být např. adresy libovolného rozhraní poptávaných uzlů) na primární adresy uzlů, jsou-li k dispozici. Tím je zajištěna maximální pravděpodobnost průchodu požadavku z hlediska legitimity vůči přístupové politice aplikované na poptávaném uzlu zabezpečené sítě.
Pro případné využití systému jako jednoho z nástrojů pro operační monitoring jsme rozšířili mechanismus notifikací o schopnost vydávat varování v závislosti na obsahu naměřených hodnot. Doposud byly ohlašovány pouze události, které se týkají stavu a průběhu měření. Systém je ve výchozí podobě nastaven tak, že oznamuje pouze principiální změny. Aktuálně je možné nastavit oznamování změn stavu dostupnosti jednotlivých měřených zařízení, jejich restart, změny funkčních stavů síťových rozhraní (administrativní i operativní) a „vznik, či zánik“ síťových rozhraní, resp. nově vzniklé nebo zaniklé kombinace popisu síťového rozhraní a jeho adresy v rámci zařízení. Ve druhé fázi jsme toto schéma rozšířili o možnost nastavit nezávisle více kombinací adresátů a souvisejících filtračních podmínek pro ohlašování tak, aby bylo možné nastavit např. oznamování změn stavu konkrétního rozhraní konkrétnímu člověku. Pro ilustraci uvádíme na obrázku 5.1 příklad kumulovaného oznámení o změně stavu rozhraní.
Síť CESNET2 je hybridní síť, v níž lze vytvářet virtuální infrastruktury se specifickými vlastnostmi. Významná část virtuálních spojů a sítí má základ v IP/MPLS vrstvě sítě. Jsou nejčastěji vytvářeny jako EoMPLS (Ethernet over MPLS) linky nebo VPLS (Virtual Private LAN Service) sítě. Vzhledem k postupně narůstajícímu množství takto vzniklých virtuálních sítí vyvstává potřeba jejich komponenty průběžně sledovat. Za tímto účelem jsme navrhli a implementovali mechanismus sběru a vizualizace informací o virtuálních kanálech v páteřní síti včetně stavebních prvků VPLS infrastruktury, a to pro prvky tvořící páteř sítě CESNET2. Do systému G3 jsme za tímto účelem zavedli novou skupinu objektů a vytvořili neutrální, na konkrétním výrobci nezávislý model identifikace. Celé schéma měření objektů tohoto typu bylo odladěno a nasazeno do produkční instalace G3 v páteři sítě CESNET2. Kromě detailních popisných údajů jsou k dispozici i základní stavové a objemové ukazatele. Ukázku výstupu měření virtuálního kanálu najdete na obrázku 5.2.
V souvislosti s postupnou virtualizací síťové infrastruktury a nastavováním specifických parametrů vzniká potřeba začít sledovat systematicky oblast QoS (Quality of Services), konkrétně class based QoS. V průběhu roku jsme postupně navrhli a implementovali několik verzí mechanismu sběru dat a vizualizace class based QoS parametrů pro platformy, na nichž je postavena IP/MPLS páteř sítě CESNET2. Stejně jako v předchozím případě jsme do systému G3 zavedli samostatnou skupinu objektů a vytvořili nezávislý model jejich identifikace. Oproti původním požadavkům na sledování na úrovni tříd provozu class-map jsme nakonec navrhli obecný mechanismus, který umožňuje sledovat a vizualizovat všechny typy objektů class based QoS hierarchie.
Jako ukázku výstupů uvádíme náhodně vybrané statistiky objektů typu class-map na obrázku 5.3, police na obrázku 5.4 a match-statement na obrázku 5.5. Vzhledem k poměrně komplexní problematice a snaze bezpečně doladit a stabilizovat celé schéma jsme paralelně rozšířili konfigurační možnosti měřicí části systému – nyní je možné nastavit ve výchozí podobě položky tak, že jsou neaktivní. Pro použití pak musí být explicitně povoleny v rámci měření uzlu, skupiny uzlů nebo celé instalace. Pozitivní i negativní vymezení jsme pro celý systém rozšířili o model plně založený na regulárním aparátu.
V oblasti sběru údajů jednotlivých čidel sledovaných zařízení v páteřní sítí CESNET2 jsme implementovali sběr limitních hodnot (thresholds) těchto čidel. Ukázka výstupu je na obrázku 5.6.
Obrázek 5.6: Ukázka výstupu průběhu hodnot čidel včetně nastavených limitních hodnot (větší obrázek)
5.1.2 Uživatelské rozhraní systému G3, elektronický klient G3 reporter
Princip fungování elektronického klienta (G3 reporter) jsme rozšířili o možnost pracovat v architektuře, kdy jedna instance bežícího programu připravuje data a další instance vytvářejí detailní a souhrnné výstupy. Doposud byla filosofie taková, že každý typ výstupu bez ohledu na to, zda se týkal identické množiny zobrazovaných prvků, byl zpracováván nezávisle (např. využití sítě a chybovost sítě). To znamenalo, že v rámci každé z úloh se periodicky verifikovala vazba mezi každým zobrazovaným prvkem a jemu odpovídajícími monitorovanými objekty (operace náročná na zdroje i čas). Pro takto získané identifikace monitorovaných objektů se prováděl výběr dat z úložiště, jejich zpracování a následně generování detailních a souhrnných výstupů.
Pro zefektivnění chodu při paralelním nezávislém zpracovávání výstupů nad identickou množinou prvků jsme přepracovali vnitřní mechanismy systému tak, že je nyní možné mít společnou konfiguraci pro sběr veškerých hodnot pro příslušnou množinu zobrazovaných prvků, kde se výše zmíněná verifikace vazeb provádí najednou, a to pro všechny případy dalšího využití. Data získaná touto částí jsou periodicky ukládána a mohou být využita libovolným množstvím souvisejících konfiguračních entit generujících detailní i souhrnné výstupy různého účelu.
Další úpravy jsme provedli v oblasti rozšíření konfiguračních možností tak, aby bylo možné rozdělit zátěž rovnoměrněji na časové ose a adaptivně vykonat některé úkony v předstihu. Také jsme eliminovali některé nadbytečné úkony v rámci negociace elektronického klienta s uživatelským rozhraním systému G3. Všechny tyto úpravy vedly ke zkrácení času potřebného k vygenerování požadovaných výstupů až na čtvrtinu.
Naší motivací pro výše uvedená vylepšení elektronického klienta a uživatelské rozhraní systému bylo zvýšit efektivitu především ve zpracování několika sad výstupů nad relativně rozsáhlými identickými síťovými entitami. Příkladem může být nová „mapa využití“ (a související detailní výstupy) IP/MPLS páteře sítě CESNET2 (ukázku souhrnného výstupu obsahuje obrázek 5.7, standardně dostupný prostřednictvím www.cesnet.cz) a paralelně generované sady výstupů pro správu sítě (např. chybovost apod.). Dalším příkladem může být víceúčelové monitorování páteřní infrastruktury mezinárodního projektu FEDERICA (ukázka souhrnného výstupu chybovostních charakteristik je na obrázku 5.8).
Obrázek 5.8: Ukázka souhrnného výstupu – mapa chybovosti páteřní infrastruktury projektu FEDERICA (větší obrázek)
5.1.3 Provozní stav systému G3 v páteři sítě CESNET2
V oblasti provozní jsme povýšili sekundární instalaci systému G3 v prostředí páteře sítě CESNET2 na výkonný HW, analogický primární instalaci systému. Migraci jsme provedli za chodu, bez výpadků ve sběru dat. Měření probíhá v současnosti duálně z obou instalací, konfigurace a rozsah měření je prakticky stejný. Tím jsme docílili zálohy jak na aplikační úrovni, tak i na úrovni shromážděných dat. V praxi obsluhuje primární instalace interaktivní uživatele, zatímco sekundární instalace je využívána elektronickým klientem (modul G3 reporter) pro systematické periodické generování požadovaných statických výstupů.
Aktuálně každá instalace systému periodicky sbírá a zpracovává přibližně 570 tisíc údajů z více než 130 zařízení. Obě instalace se dařilo udržet v průběhu roku v chodu bez výpadků. Základní souhrnné ukazatele měření jsou uvedeny na obrázku 5.9. Časový krok měření se pohybuje v rozsahu 20 vteřin až 20 minut s průměrem okolo deseti minut. Průměrný čas ke sběru dat z jednoho prvku je necelých 18 vteřin. Maximální časy pro sběr dat z jednotlivých prvků výrazně oscilují, což je nejčastěji způsobeno buď problémy s měřením (např. po povýšení operačního systému zařízení před tím, než se podaří optimalizovat nastavení zařízení i sběru dat) nebo kumulací požadavků z různých zdrojů. Poslední graf obrázku ukazuje přibližný průběh celkového času nutného ke změření a zpracování dat ze všech měřených zařízení v rámci jedné instalace.
5.2 Sledování provozu sítě
V této oblasti se zaměřujeme na rozvoj systému FTAS (Flow-based Traffic Analysis System) a jeho efektivní využití v prostředí sítě CESNET2.
5.2.1 Úpravy a rozšíření systému FTAS
Ve většině případů nasazení systému FTAS, a to obzvláště při zpracování provozních informací z míst s vysokou mírou agregace provozu, je nutné aplikovat určitou úroveň vzorkování na příchozí tok provozních záznamů na vstupu systému. Vzorkování na úrovni provozních záznamů bylo doposud implementováno podle schématu jedna z N, což při nízkých hodnotách N neumožňuje optimální využití zdrojů. Proto jsme vzorkovací mechanismus přepracovali do podoby, která umožňuje výrazně zjemnit vzorkovací škálu a implementovali jsme schéma M z N vyjádřené hodnotou vzorkování za desetinnou tečkou – např. nastavená hodnota vzorkování 1,25 odpovídá 100 vybraných záznamů ze 125 celkových.
Na základě intenzivního využívaní systému pro bezpečnostní analýzy a z toho plynoucích požadavků (např. pracoviště typu CSIRT/CERT) jsme rozšířili funkce a možnosti uživatelského rozhraní systému. Implementovali jsme volitelný export výsledků ve strojově snadno zpracovatelném formátu (prostý text, oddělovač polí) a rozšířili výstup o možnost zobrazení základních geolokačních údajů (kódy zemí podle ISO 3166). Ukázka výstupu je na obrázku 5.10.
5.2.2 Provozní stav systému FTAS v páteři sítě CESNET2 a další instalace
Z ryze provozního hlediska se podařilo udržet systém v chodu bez neočekávaných výpadků a průběžně reagovat na změny v konfiguraci IP/MPLS páteře CESNET2 (rekonfigurace v rámci rozdělení uzlů v Praze a Brně). Na počátku roku jsme přesunuli jádro systému – čtyři primární kolektory – na nový HW a průběžně přeskupili další kolektory na uvolněný HW. Dobu uchování se tak podařilo zvýšit až na 62 dnů (v závislosti na zdroji) při zachování úrovně vzorkování. V současnosti produkční instalace systému sestává ze sady osmi primárních kolektorů, které zpracovávají data ze sedmnácti páteřních směrovačů. Průběh objemu příchozích provozních záznamů během roku je uveden na obrázku 5.11, ukázku průběhu celkového objemu zpracovaných provozních záznamů (tj. včetně interní redistribuce) během listopadu 2009 obsahuje obrázek 5.12.
V průběhu roku jsme ustanovili systematický monitoring pracovišť AV ČR na základě IP rozsahů a příslušnosti k jednotlivým místům přítomnosti páteřní IP/MPLS sítě CESNET2, a to včetně nadstavbových filtrů pro generování souhrnných statistik provozu. Tento monitoring provozu jsme realizovali v rámci primární instalace FTAS v síti CESNET2. Další z realizovaných instalací zajišťuje sledování vnitřního provozu sítě Západočeské univerzity. Vznikla ve spolupráci se správou univerzitní sítě na technických prostředcích univerzity. Již dříve založené sledování provozu vnitřní sítě Masarykovy university v Brně jsme reinstalovali na nový hardware. Všechny ostatní dříve realizované instalace jsou průběžně udržovány v chodu.
|
|
obsah |
následující
|
![[Obrázek]](g3-notification-1.png)
![[Obrázek]](g3-vchannel-1.png)
![[Obrázek]](g3-class-map-example.png)
![[Obrázek]](g3-police-example.png)
![[Obrázek]](g3-matchstatement-example.png)
![[Obrázek]](g3-cesnet-utilization-map.png)
![[Obrázek]](g3-system-aggregated.png)
![[Obrázek]](ftas-geo-location-example.png)
![[Obrázek]](ftas-input-netflow-bitrate.png)
![[Obrázek]](ftas-summary-netflow-bitrate.png)