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 podle potřeby pracovat s různou logickou strukturou síťových prvků a provádět 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 (verze 4 i 6) 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. Nejvýznamnější výsledky naší práce v roce 2008 byly:

5.1.1   Distribuovaná architektura měřící části systému G3

Základní architektura měřící části systému G3 je založena na principu rozdělení množiny měřených zařízení mezi skupinu samostatných měřících procesů v rámci jedné instalace systému. Množství měřících procesů je podmíněno konfigurací systému a v principu může být libovolné. Každý měřící proces potom sbírá a zpracovává data z příslušné množiny zařízení. Naměřená a zpracovaná data jsou následně ukládána do společného úložiště jedním z možných způsobů (přímo, samostatným procesem prostřednictvím sdílené paměti, samostatným procesem prostřednictvím UNIX soketu). Tato architektura vyhoví v naprosté většině běžných instalací. V některých případech by však bylo žádoucí rozdělit měření mezi několik nezávislých instalací systému resp. několik HW uzlů. To se týká situací kdy například:

Ruku v ruce s potřebou rozdělit procesy zajišťující sběr a zpracování dat mezi více uzlů jde požadavek na opětné sjednocení výsledků na úrovni uživatelského rozhraní. Kromě přirozeného požadavku na jednoduchost a jednoznačnost obsluhy je takový požadavek v případě systému G3 podpořen i snahou zachovat jednu ze základních vlastností zpřístupnění a vizualizace dat - agregační a sumarizační vlastnosti bez ohledu na příslušnost dat ke sledovaným zařízením. Vlastní instalace systému G3 v prostředí sítě CESNET2 se s postupným rozšiřováním množiny sledovaných informací i počtu a typu sledovaných prvků stává velmi rozsáhlou a do budoucnosti nelze vyloučit nutnost rozdělit sledování infrastruktury mezi několik měřících uzlů. Proto jsme v roce 2008 přistoupili k vývoji, jehož cílem bylo povýšit vlastnosti systému takovým způsobem, aby bylo možné jej volitelně provozovat v distribuované architektuře na úrovni sběru a zpracování dat. Zároveň jsme si dali za cíl zajistit, aby bylo možné odděleně naměřená data promítnout jediným uživatelským rozhraním se zachováním všech stávajících vlastností včetně plné podpory elektronického klienta (modul G3 reporter).

Některé nástroje použité při řešení (podrobněji technická zpráva [Kos08]) vyžadují, aby pro uživatelské rozhraní zůstala zachována dostupnost všech úložišť na úrovni systému souborů (s právem pro čtení). Nejpodstatnější úpravy systému jsme provedli v části zajišťující přesnou identifikaci naměřených dat v souvislosti s mapováním externích úložišť do uzlu, na kterém běží uživatelské rozhraní.

Přesná lokace dat v systému souborů měřícího procesu je z různých důvodů ukládána současně s daty samotnými a používá se, kromě jiného, při konstrukci datových zdrojů pro navigační strom nebo pro ad-hoc konstrukci vizualizačních direktiv. Aby byla vždy zachována správná identifikace a integrita dat, vytvořili jsme adaptivní modul, který zajišťuje správný překlad cesty v závislosti na požadované akci. Díky této funkci stačí při konfiguraci celé soustavy pouze namapovat odpovídající část vzdáleného úložiště do správné úrovně lokálního úložiště pod libovolným jménem a odpovídající část této cesty zadat do konfigurace procesu, který generuje zdrojová data pro konstrukci navigačního stromu (viz výše uvedená technická zpráva).

Další rozsáhlé úpravy jsme provedli v oblasti rozšíření direktiv pro konfiguraci vlastního obsahu měření tak, aby bylo možné jednoduchým způsobem nastavit, které položky, skupiny nebo třídy položek mají být v rámci dané instalace měřeny nebo naopak z měření vyloučeny, a to včetně dědění v rámci hierarchie stromu všech definovaných položek. Společně s dalšími dílčími úpravami se nám podařilo dosáhnout takové funkčnosti systému, která umožňuje na úrovni měření nastavit dvě základní varianty sběru a zpracování dat, případně jejich kombinaci:

  1. Rozdělení množiny sledovaných zařízení do skupin a měření každé skupiny zařízení samostatným prvkem distribuovaného systému. V tomto modelu je libovolné konkrétní zařízení měřeno právě z jednoho měřícího uzlu (viz. obrázek).
  2. Rozdělení měření jednotlivých skupin informací v rámci všech sledovaných zařízení mezi jednotlivé prvky distribuovaného systému. V tomto modelu je libovolné konkrétní zařízení měřeno z více než jednoho měřícího uzlu (viz. obrázek)
[Obrázek]

Obrázek 5.1: Distribuované měření - varianta 1 (větší obrázek)

[Obrázek]

Obrázek 5.2: Distribuované měření - varianta 2 (větší obrázek)

Pro druhý uvedený případ je nutné přesnou konfigurací systému zajistit, aby se pro dané zařízení nesbírala a především neukládala stejná data na více místech distribuované soustavy. Jakákoli duplicita by mohla způsobit vzhledem k implicitní agregaci v rámci uživatelského rozhraní systému G3 násobení (v závislosti na typu položky) příslušných veličin při vizualizaci.

Upravený systém jsme na konci léta nasadili na sestavu dvou měřících uzlů a po doladění jsme provedli několikaměsíční testování v konfiguraci přesně odpovídající variantě podle obrázku. V průběhu ověřování jsme testovali i funkci elektronického klienta (modulu G3 reporter) prostřednictvím generování testovacích map zátěže, chybovosti a dalších výstupů. Generické schéma rozšířené architektury systému G3 s distribuovanou měřící částí a vazbami k uživatelskému rozhraní a modulu G3 reporter je na obrázku.

[Obrázek]

Obrázek 5.3: Generické schéma distribuované architektury měření (větší obrázek)

5.1.2   Migrace produkční instalace systému na 64bitovou architekturu operačního systému

Systém G3 postupně rozšiřujeme o schopnost sledovat nové typy zařízení a sbírat a zpracovávat další typy údajů. S tím postupně roste celkový počet zpracovávaných položek a celkový objem dat, která je nutno periodicky zpracovávat. Zároveň je nutné z důvodu zachováni kontinuity informací o některých službách sítě i z důvodů archivačních zachovávat data z již odstavených zařízení. V neposlední řadě systém v prostředí sítě CESNET2 postupně přebírá roli primárního systému pro dlouhodobé plošné sledování infrastruktury sítě. Z těchto důvodů jsme v průběhu roku systém přemigrovali na HW, který svými parametry odpovídá rozsahu měření i nárokům G3 na zdroje. Rozhodli jsme se přejít na 64bitový Debian GNU/Linux 4.0.

Vzhledem k tomu, že prakticky žádný z použitých formátů pro ukládání dat není binárně přenositelný mezi 32b a 64b architekturou, byli jsme nuceni navrhnout způsob a vytvořit nástroje pro migraci dat, a to při průběžném měření na obou systémech - tj. bez zásadních výpadků v měření (max. do 1 hodiny v reálných podmínkách). Vlastní migrace dat trvala cca 70 hodin (téměř 70 GB binárních zdrojových dat). Vyvinuté nástroje jsou s mírnou modifikací použitelné i při migraci systému během měření v rámci jedné architektury. Před vlastní migrací jsme prováděli dlouhodobé výkonnostní testy v závislosti na parametrech hostitelského systému (RAID úrovně, parametry RAID řadiče, parametry systému souborů a vyrovnávacích pamětí, parametry a mechanismy zpracování IO front). Díky optimalizaci je v prostředí 64b systému a rozšířené struktury RRD databáze měření v aktuálním rozsahu provozovatelné stále v rámci jednoho stroje. Konkrétní parametry hostitelského systému jsou: 4×Quad Core Xeon X7350, 64 GB RAM, 8×SAS 15 K 73 GB disky v RAID10 (HW řadič), operační systém Debian GNU/Linux 4.0 64bit. Základní souhrnné parametry sběru dat, počet měřených zařízení a vývoj časového kroku sběru dat v rámci celé instalace, vidíte na obrázku. Za těmito průběhy je skryto celkem cca 550 000 měřených položek v jednom kroku sběru dat (listopad 2008).

[Obrázek]

Obrázek 5.4: Základní souhrnné informace o měření sítě CESNET2 (větší obrázek)

V souvislosti s náběhem systému G3 v síti CESNET2 do produkčního nasazení jsme řešili otázku granularity dat. Původně navržená struktura dat (především RRD databáze) se v průběhu času ukázala jako nedostatečná pro zobrazení detailních průběhů jednotlivých veličin. Pro zjemnění průběhů jsme navrhli a implementovali novou strukturu RRD dat. Pro již existující RRD databáze systému G3 jsme navrhli a naprogramovali "rekalibrátor", který přiblíží strukturu stávající databáze nově navržené (přidání nových slotů do jednotlivých agregačních intervalů v rámci RRA - Round Robin Archive), a to v průběhu měření. Vlastní konverzi již existujících dat jsme provedli po migraci systému na 64bitovou architekturu.

5.1.3   Rozšíření spektra měřených informací

Z mnoha rozšíření systému z hlediska schopnosti měřit nové informace stojí za samostatnou zmínku (i jako ilustrace jeho otevřenosti) sledování využití videopřenosů distribuovaných z našich serverů. Ve spolupráci s aktivitou Multimediální přenosy a kolaborativní prostředí jsme navrhli a realizovali mechanismus sběru dat. Na straně G3 jsme naprogramovali novou třídu sledovaných položek, jejíž ukázku najdete na obrázku. Další podstatné rozšíření jsme realizovali ve spolupráci s aktivitou Optické sítě - testovací SNMP monitorování specifických parametrů optických zesilovačů CLA vyvíjených sdružením. Vývojáři optických zesilovačů vytvořili příslušnou SNMP MIB, na straně systému G3 jsme definovali odpovídající položky do portfolia systému. Ukázka některých sledovaných parametrů zesilovače je na obrázku

[Obrázek]

Obrázek 5.5: Měření video streamů (větší obrázek)

[Obrázek]

Obrázek 5.6: Měření parametrů optické části zesilovače CLA (větší obrázek)

5.1.4   Rozšíření funkcí elektronického klienta systému - modulu G3 reporter

Z úprav, kterými prošel v průběhu roku modul G3 reporter, stojí za zmínku například:

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. V roce 2008 jsme se konkrétně zabývali těmito oblastmi:

5.2.1   Dual-stack na aplikační úrovni

Systém FTAS je koncipován jako distribuovaný a při plošném sledování provozu v rozsáhlých sítích je zpravidla také distribuovaně provozován. Opírá se o centrální konfiguraci, ze které všechny uzly dané instalace vygenerují direktivy pro vlastních chod. Běžnou součástí činnosti systému v distribuované architektuře je interní redistribuce provozních informací mezi jednotlivými uzly. Je samozřejmě podmíněna konfigurací, přičemž konfigurační záznam obsahuje pro přijímající stranu (například na uzlu A) sdělení asi v tomto smyslu: na portu udp/65001 nastartovat příjemce provozních záznamů identifikovaného jako XYZW (identifikátor musí být jednoznačný v rámci celé instalace). Pro jiný, v tomto příkladu vysílající uzel (např. B), může znamenat konfigurace toto: provozní záznamy obsahující informace o provozu z/do IP rozsahu 10.0.0.0-10.0.1.255 posílej příjemci provozních záznamů identifikovanému jako XYZW. To v praxi znamená, že uzel B bude průběžně posílat příslušné provozní záznamy na uzel A prostřednictvím protokolu UDP na port 65001. Tento scénář je jednoznačný v případě existence pouze jedné verze protokolu IP v rámci celé instalace. V případě přítomnosti obou nebo dokonce rozdílných verzí IP v jednotlivých uzlech celé instalace není již konfigurace jednoznačná a za určitých okolností ani nezaručuje funkci celé soustavy. Vzhledem k tomu, že naším záměrem je plná podpora IPv6 ve všech oblastech práce systému, rozhodli jsme se tento problém řešit.

Nejjednodušší možné řešení spočívá patrně v modelu, kdy uzel A bude paušálně poslouchat na UDP portu 65001 jak pro IPv4 tak pro IPv6 a vysílací strana (uzel B) zvolí automaticky podle možností jednu z verzí IP. My jsme se rozhodli implementovat přesnější variantu, která umožňuje stanovit buď prioritu pořadí verzí IP nebo si vynutit přímo v konfiguraci konkrétní verzi IP. Upravené moduly jsme nasadili v rámci produkční instalace systému v síti CESNET2.

5.2.2   Adaptace systému na rozšíření formátu některých polí exportovaných záznamů

Systém FTAS pracuje se všemi běžnými verzemi exportních formátů pro distribuci provozních informací na bázi toků. Vzhledem k tomu, že se pohybujeme v prostředí koexistence IPv4 a IPv6, je všude, kde je to možné, používán exportní formát verze 9 [RFC3954]. Na rozdíl od předchozích exportních formátů je otevřený - součástí exportu jsou informace o struktuře samotných exportovaných dat. Tyto informace (tzv. záznamy typu template) obsahují významový identifikátor pole a velikost pole (počet bajtů) v aktuálním exportu.

Velikost některých polí se může lišit v závislosti na implementaci. Běžné jsou případy, kdy jednotlivé generátory provozních záznamů v rámci jednoho zdroje (např. na směrovač) posílají významově stejná pole v rozdílných délkách. Tyto situace systém automaticky zvládá až do okamžiku, kdy oznamovaná velikost některého z polí přesahuje maximální velikost rezervovanou pro toto pole v rámci celého systému, a to především v případech, kdy se jedná o pole zařazené do množiny polí určených pro uložení do databáze. Systém FTAS používá jako úložný systém relační databázi (konkrétně MySQL) a v zájmu úspory místa je základní struktura tabulky pokud možno přesně nastavena na maximální očekávanou velikost jednotlivých polí. Dalším specifickým případem jsou pole, pro něž se generují filtrační podmínky způsobem závislým na maximální interně deklarované velikosti pole. Proto je nutné v případě překročení interního limitu pro velikost daného pole celý systém adaptovat na nové podmínky při zachování zpětné kompatibility. V roce 2008 se tyto úpravy týkaly polí nesoucích informaci o identifikačních číslech síťových rozhraní (nasazení systémů poskytujících provozní záznamy v multi-shelf architektuře) a čísel autonomních systémů [RFC4893], v obou případech na 4B velikost. Upravená verze byla opět nasazena v rámci produkční instalace systému v síti CESNET2.

5.2.3   Rozšiřování uživatelské komunity

Systém FTAS je v prostředí sítě CESNET2 provozován v několika instalacích. Základní produkční víceuzlová instalace slouží pro souvislé plošné sledování provozu páteře sítě CESNET2 jako přímá podpora správy sítě a řešení bezpečnostních problémů. Rozsah sběru primárních provozních informací topologicky pokrývá celou IP/MPLS páteř CESNET2. Postupným rozšiřováním této instalace a optimalizací klasifikačních a filtračních schémat je vytvářen prostor pro zřízení specifického odděleného monitoringu některých uživatelských skupin (aktuálně například MetaCentrum, v přípravě pracoviště Akademie Věd České Republiky) na úrovni páteřní sítě. Kromě instalací v páteřní síti je systém FTAS nasazen přímo v sítích dalších členů sdružení nebo jiných organizací - konkrétně se jedná o ČVUT v Praze v Dejvicích, Masarykovu Univerzitu v Brně, Technickou Univerzitu v Liberci, připravuje se instalace pro Západočeskou Univerzitu v Plzni a mimo rámec účastníků sítě CESNET2 pokračuje spolupráce na monitorování provozu sítě Seznam.cz, a. s.

předchozí
obsah 		následující
další weby:fond rozvojemetacentrumCzechLightpřenosyvideoservereduroameduID.cz