5.7   Statistické vyhodnocení provozu

5.7.1   Sledování a vyhodnocování síťové infrastruktury - GTDMS II

V této oblasti se zaměřujeme na tvorbu metodiky a nástrojů pro nepřetržité sledování a vyhodnocování stavů síťové infrastruktury. Na tomto procesu se rozhodující mírou podílí pasivní měření aktivních síťových prvků na bázi SNMP (Simple Network Management Protokol).

Cílem je poskytnout reálný obraz o chování elementární síťové infrastruktury včetně míry jejího využití, četnosti chybových stavů, indikace potenciálních zdrojů problémů, vývojových tendencí a dalších ukazatelů jako podporu pro technickou i organizační správu sítě TEN-155 CZ.

Zaměřujeme se především na vývoj měřícího systému GTDMS, jehož základ byl vytvořen již v rámci projektu TEN-34 CZ a jeho první generace byla dále vyvíjena a postupně rozšiřována během minulých etap projektu TEN-155 CZ. V roce 2000 jsme systém na základě zkušeností s provozováním jeho první generace a nových požadavků řešitelů kompletně přepracovali.

Výsledkem je nová verze, pracovně pojmenovaná GTDMS II. Kromě zásadních změn v metodice měření a interní architektuře systému došlo k podstatnému rozšíření měřících, konfiguračních a archivačních vlastností. Systém má zcela nové uživatelské rozhraní, a to jak pro běžný uživatelský přístup, tak pro administraci. Také mechanismus autentizace a autorizace uživatelů prošel výraznými změnami směrem k integraci s ostatními aplikacemi používanými pro správu sítě TEN-155 CZ

GTDMS II je soustava softwarových balíků realizující sledování síťové infrastruktury s těmito základními vlastnostmi:

Architektura systému

Z hlediska logické architektury lze systém rozdělit na tři nezávislé části:

[Obrázek]

Obrázek 5.29: Logická architektura systému

Systém je navržen jako otevřený, umožňující pracovat v modelu point to multipoint z hlediska vztahu uživatelského rozhraní vůči měřícím uzlům. Měření probíhá víceúlohovým způsobem (zajišťují měřící démoni) a je řízeno jedním kontrolním procesem (řídící démon). Počet měřících procesů, stejně jako ostatní parametry, lze měnit za chodu (bez nutnosti dalších zásahů) prostřednictvím nástrojů pro správu systému spouštěných HTTP serverem v podobě CGI skriptu.

Prezentační rozhraní je spouštěno stejným mechanismem. Vedle toho je lze alternativně volat přímo na pozadí (včetně spouštění z příkazové řadky) nástroji k tomu vytvořenými (agenti na pozadí). Tímto způsobem lze efektivně vytvářet výstupy ze systému jako statické struktury HTML dokumentů. Používáme jej např. pro generování mapky využití páteře TEN-155 CZ.

Autentizace uživatelů může být lokální nebo externí. V případě sítě TEN-155 CZ se opírá o externí CAAS (Centrální autentizační a autorizační systém) s lokální autorizací, jejíž konfigurace je centralizována do místa spouštění příslušného uživatelského rozhraní.

Měřící subsystém

Měřící subsystém plní čtyři skupiny úloh:

Pro bližší představu jsou ve zjednodušeném schématu na obrázku znázorněny jednotlivé logické vazby barvami odpovídajícími příslušné skupině úloh.

[Obrázek]

Obrázek 5.30: Architektura měřícího subsystému

Měřící subsystém zpracovává požadavky (konfigurační požadavky) na sledování jednotlivých uzlů sítě vygenerované uživatelským rozhraním nástrojů pro správu. Začleňuje je do mechanismu periodického měření (měřicí úloha) a provádí periodické interní rekonfigurace (konfigurační úloha) obrazu měřeného prvku (konfigurace měřených uzlů a položek) na základě předdefinovaných vzorů potenciálně měřitelných veličin. Reálný stav měřeného prvku pak odpovídá jeho obrazu v měřícím systému.

Tento proces je plně parametrizovatelný, a to jak globálně, tak pro jednotlivé měřené uzly sítě. Hodnoty parametrů je možné nastavit a průběžně měnit prostřednictvím uživatelského rozhraní pro správu.

Kromě těchto základních činností je prováděna automatická agregace zastarávajích dat. Agregovaná data mají podstatně menší velikost a lze je tudíž dlouhodobě uchovávat.

Jelikož požadavky na systém oscilují mezi statistickými a "reálně-časovými", zásadně jsme přepracovali systém varovných zpráv. Informace o nestandardních událostech jsou dostupné jak prostřednictvím prezentačního uživatelského rozhraní, tak mohou být distribuovány pomocí elektronické pošty.

Systém varovných zpráv umožňuje nezávislou konfiguraci varování pro dva typy událostí. Do první skupiny patří události chybového charakteru, kdy z nějakých důvodů nebylo možné provést měření daného zařízení (např. ztráta konektivity). Do druhé skupiny spadají události obsahového charakteru, kdy bylo měření provedeno, ale konkrétní naměřené hodnoty jsou svým obsahem mimo tolerované pásmo (např. zvýšená chybovost síťových rozhraní, změna popisu síťových rozhraní, zvýšená zátěž procesoru apod.).

Struktura sledovaných uzlů, měřené položky

Z pohledu systému je měřený aktivní síťový prvek rozčleněn do hierarchické (rozšiřitelné) struktury popisující jeho logické komponenty. V současné době jsou nadefinovány tyto typy objektů v následujícím hierarchickém uspořádání:

[Obrázek]

Obrázek 5.31: Abstrakce měřeného uzlu sítě

Tento úhel pohledu umožňuje nezávisle definovat parametry v rámci jednotlivých typů jak pro proces reálného měření, tak pro proces konfigurační synchronizace (průmět změn na měřeném uzlu sítě do jeho obrazu v měřícím systému).

S každým uvedeným typem objektu má systém svázánu rozšiřitelnou sadu normalizovaným způsobem nadefinovaných, potenciálně měřitelných položek. Tyto definované položky obsahují, kromě jiného, reference na příslušné MIB-OID objekty (SNMP meření), případě definice pro alternativní způsoby měření. Pro bližší představu uvádím základní zdroje předdefinovaných položek pro jednotlivé typy objektů použité při měření v prostředí sítě TEN-155 CZ:

System
RFC 1213, RFC 2011, CISCO-MEMORY-POOL-MIB, OLD-CISCO-CPU-MIB, OLD-CISCO-CHASSIS-MIB, CISCO-ENVMON-MIB
Interface
RFC 1213, RFC 2233, RFC 1573, RFC 1229, OLD-CISCO-INTERFACES-MIB, ESSWITCH-MIB, RFC 1695, RFC 1643, RFC 1595, RFC 2558, IPMROUTE-MIB, PIM-MIB
Atm-PVP
RFC 1695, CISCO-ATM-CONN-MIB
Atm-PVC
RFC 1695, CISCO-ATM-CONN-MIB, CISCO-AAL5-MIB
Framerelay-DLC
RFC 1315
Cisco-CAR
CISCO-CAR-MIB

Uživatelské rozhraní pro konfiguraci měřícího subsystému

Toto uživatelské rozhraní slouží pro nastavení parametrů měření jednotlivých uzlů sítě a pro nastavení globálních parametrů systému. Mezi typické operace patří:

[Obrázek]

Obrázek 5.32: Ukázky WWW rozhraní systému

Administrační rozhraní pro správu uživatelů

Tento modul zajišťuje nastavování autentizačních a autorizačních parametrů jednotlivých uživatelů. Lze jej provozovat v architektuře s lokální i s externí autentizací. Přístup uživatelů k informacím lze nastavovat jak z hlediska omezení přístupu k datům konkrétní části měřeného uzlu sítě (např. síťové rozhraní, ATM kanál apod.), tak z hlediska kategorizace měřených položek do hierarchicky setříděných skupin (např. popisné, objemové, varovné, chybové skupiny).

Prezentační uživatelské rozhraní

Prezentační uživatelské rozhraní se proti předchozí verzi také změnilo. Nyní je koncipováno tak, aby uživatel mohl vyhledávat a posléze vybírat kombinaci libovolných strukturálních částí měřených uzlů sítě (např. síťová rozhraní, ATM kanály apod.) a jednotlivých skupin měřených veličin (např. vstupní datové toky, výstupní chybovost atd.) co nejefektivnějším způsobem.

Takto zvolenou kombinaci je možné ve zvoleném časovém úseku zobrazit, přenést výsledky na svůj počítač, případně zobrazit ve formátu vhodném pro tisk. Jako další možnost nabízí systém uložení navolené konfigurace do osobního či společného (v závislosti na přístupových právech) profilu. Takto uloženou konfiguraci lze později importovat, přímo zobrazit, případně změnit. V případě spuštění aplikace na pozadí (mimo HTTP server) je možné ji parametrizovat stejným způsobem jako při interaktivní práci. Toto je např. využito pro generování mapky zátěže páteřních tras TEN-155 CZ.

[Obrázek]

Obrázek 5.33: Mapa zatížení páteřních tras TEN-155 CZ

Výhled do budoucnosti

V roce 2001 bychom rádi rozšířili systém o schopnost měřit informace, týkající se analýzy procesů a oddělené analýzy zátěží jednotlivých procesorů na víceprocesorových aktivních síťových prvcích. V testovacím režimu je toto možné, hodnoty prezentované aktivními prvky bohužel závisí na implementaci a jsou v současnosti zpravidla mimo realitu.

V oblasti vývoje uživatelského rozhraní bychom rádi implementovali do uživatelských profilů dynamické vlastnosti na úrovni vyhledávací podmínky v závislosti na aktuálně naměřených hodnotách. V současné verzi je obsahem záznamu v profilu prostý výčet vybraných objektů. S tímto problémem souvisí dlouhodobé úskalí při měření metodami SNMP. Nejčastěji požadované typy informací jsou buď přímo (např. zátěžová charakteristika) nebo zprostředkovaně (např. vazba na logické kanály) svázány s konkrétním síťovým rozhraním.

Z lidského pohledu je síťové rozhraní aktivního prvku jednoznačně identifikováno svou fyzickou polohou, technologickým typem, případně jinými specifickými vlastnostmi. Z pohledu SNMP je jednoznačným identifikátorem rozhraní veličina nazývaná index, tedy pořadové číslo. Až potud by bylo vše v pořádku, neboť od tohoto údaje se odvozují identifikátory pro sběr hodnot s ním souvisejících.

Problém spočívá v tom, že ve velkém množství SNMP implementací je tento identifikátor přidělován dynamicky, a to buď při startu systému nebo za běhu při změně konfigurace. To znamená, že z lidského úhlu pohledu stejné síťové rozhraní může být v průběhu času svázáno s několika rozdílnými hodnotami indexu. Tato vlastnost vede ve svých důsledcích k tomu, že při generování dlouhodobé charakteristiky libovolného typu může být její průbeh složen z několika úseků svázaných s různými fyzickými rozhraními. Při jejich posuzování je proto třeba brát v úvahu i změny naměřených popisných údajů, což je pro analytickou práci poměrně nepohodlné.

Existují sice popisné vazební prvky (např. popis rozhraní zadaný administrátorem, IP adresa apod.), ale jejich nevýhodou je, že nemusí pokrývat plnou množinu síťových rozhraní na daném prvku nebo nejsou jednoznačné (např. vícenásobný výskyt, modifikace za chodu systému apod.). Přes tato omezení bychom se rádi pokusili o implementaci takového alternativního pohledu na síťová rozhraní, který by byl odvozen od kompromisní kombinace sekundárních popisných údajů.

5.7.2   Analýza IPv4 provozu sítě TEN-155 CZ

Cílem činnosti v této oblasti je tvorba nástrojů pro průběžné statistické vyhodnocování IPv4 provozu jednotlivých účastníků sítě TEN-155 CZ. V roce 2000 jsme se v této oblasti zaměřili na další rozvoj systému Accounting and Statistics, jehož základní popis je uveden v průběžné zprávě o řešení projektu za rok 1999. V roce 2000 došlo ke změnám některých požadavků stanovených zadavatelem. Za nejvýznamnější lze považovat schopnost kategorizovat mezinárodní provoz podle tras, po kterých byly příslušné objemy přeneseny, a to se zachováním vazeb na jednotlivé účastníky sítě.

Postup řešení

Rozdělení problematiky do tří základních skupin úloh zůstalo nezměněno. Jedná se o:

V rámci každé skupiny jsme však museli změnit metodiku činnosti nebo mechanismus zpracování dat, případně rozšířili nabízené funkce.

Pořizování provozních dat

Páteřní infrastruktura sítě TEN-155 CZ je vybudována na produktech firmy Cisco Systems, takže máme k dispozici dvě metody pro měření provozních dat implementované tímto producentem: IP cache flow a IP accounting. Vzledem k tomu, že metoda IP accounting neposkytuje z hlediska datového obsahu dostatek údajů pro plnohodnotnou analýzu a jednoznačnou identifikaci datové trasy, není pro naše potřeby vhodná.

Pro pořizování provozních dat jsme použili metodu IP cache flow s exportním formátem Netflow verze 5. Je v maximální míře podporována v produktové řadě firmy Cisco Systems a navíc obsahuje informace nutné pro rozlišení trasy, kterou byly příslušné datové objemy přeneseny.

[Obrázek]

Obrázek 5.34: Architektura sběru provozních dat

Při podrobnějším zkoumání struktury Netflow dat se nabízí několik možností detekce datové trajektorie. V našem případě byl jako opěrný bod zvolen údaj identifikující sousední autonomní systém od kterého (ke kterému) jsou příslušná data přenášena (source/neighbor AS number). Tento údaj byl zvolen jako nejméně závislý na aktuální fyzické topologii a jejích vazbách na konfiguraci hraničních mezinárodních směrovačů.

Abychom měli možnost alespoň krátkodobě přesněji analyzovat provoz při anomálních provozních stavech, nastavili jsme nejmenší možnou expirační dobu (pro export) jednotlivých položek na hraničních směrovačích. V současné verzi IOS se jedná o 1 minutu. Doba archivace v místě sběru je dána dostupnou diskovou kapacitou. V současné době reprezentuje přibližně období dvou až tří dnů v částečně agregované podobě (agregace po pětiminutových časových intervalech).

Softwarový balík data collector jsme rozšířili o schopnost zpracovávat další verze exportního formátu Netflow a provedli jsme v něm další úpravy směřující k maximální stabilitě a spolehlivosti. Logická architektura mechanismu sběru primárních provozních dat je naznačena na obrázku.

Zpracování provozních dat a statistické výpočty

Jak jsme uvedli výše, kategorizace mezinárodního provozu podle trasy přenosu se provádí na základě identifikačního čísla sousedícího autonomního systému. Určitým omezením tohoto přístupu je, že tento údaj je dostupný pouze na směrovačích realizujících externí směrování. Proto jsme museli změnit metodiku zpracování provozních dat pro jednotlivé účastníky sítě.

Veškerá provozní data ze všech hraničních směrovačů, ke kterým je připojen alespoň jeden účastník sítě, jsou vyhodnocena podle IP adres, jež obsahují. Posuzuje se, zda adresy náleží sítím jednotlivých účastníků a ostatních poskytovatelů na národní úrovni. Z takto vyhodnocených dat jsou vyňaty položky, které mají alespoň jednu stranu logického spojení (IP adresu) nezařazenou.

Tím se v rámci daného hraničního směrovače získá obraz provozu realizovaného uvnitř sítě TEN-155 CZ nebo vůči ostatním poskytovatelům na národní úrovni (informace týkající se mezinárodního provozu byly eliminovány). V tomto okamžiku lze vyhodnotit národní provoz pro účastníky, pro které je tento směrovač autoritativní.

Ve druhém kroku se vyhodnotí data ze směrovačů realizujících zahraniční konektivitu. Vychází se při něm ze známých adresních rozsahů a identifikačních čísel sousedních autonomních systémů. Postupuje se analogicky, jako u domácího provozu v prvním kroku. To znamená, že informace o provozu každého účastníka sítě TEN-155 CZ jsou složeny ze dvou nezávislých částí, jak je naznačeno na obrázku.

[Obrázek]

Obrázek 5.35: Logika zpracování provozních dat účastníka sítě

Provozní data z jednotlivých hraničních směrovačů (hraniční body) jsou kategorizována podle příslušnosti k účastníkům sítě a podle typu provozu na národní (interní) a zahraniční (externí). Pro každého účastníka sítě jsou zpracovány částečné statistické výstupy, které slouží jako zdrojová data pro parametrizované dotazy generované uživatelským rozhraním. Obsahem těchto výstupů jsou například celkové přenesené objemy účastníka, nejvýznamnější zdroje dat svázané s provozem účastníka nebo nejvýznamnější jeho relace.

Součastí zpracování jsou i sumární výstupy (globální data) sloužící jako podklad pro pohled na celkový provoz sítě TEN-155 CZ. Zdrojem pro tato provozní data jsou datové agregace statisticky zpracováných dat jednotlivých účastníků.

Prezentační a administrační uživatelské rozhraní

Uživatelské rozhraní nedoznalo výrazných změn. Podařilo se zachovat kontinuitu služby tak, že zůstávají dostupné informace o provozu zpracované předchozími metodami. Nové informace jsou do výstupů zakomponovány takovým způsobem, že nedošlo k zásadním změnám ve vzhledu dokumentů.

Prezentační rozhraní jsme rozšířili na základě požadavků těch uživatelů systému, kteří jej používají k hlubší analýze provozu vlastní organizace. Přidali jsme další filtrační funkce umožňující zpřesnění zadávaných dotazů - filtraci založenou na volitelném adresovém rozsahu v souvislosti s výstupy, které obsahují konkrétní adresní informace (např. nejvýznamnější relace, zdroje).

Statistické závislosti

Přestože během roku 2000 došlo k několika změnám, které významným způsobem ovlivnily rozložení provozu (např. připojení dalších částí lokální infrastruktury, rekonfigurace páteře), ne všichni účastníci využívali síť TEN-155 CZ po celý rok (např. připojení během roku), případně ji využívali nerovnoměrně (prázdniny), lze vysledovat určité statistické závislosti v přenesených objemech dat. Pro ilustraci uvádíme průběhy vypočtené z objemu dat přenesených po transatlantických trasách ke členům sdružení v pracovních dnech v období provozních špiček (8-20 hodin). Ve všech případech se jedná o velikost odchylek výsledků vypočtených z náhodně vybraných dat od hodnot vypočtených ze všech naměřených provozních dat.

[Obrázek]

Obrázek 5.36: Odchylky v přenosových objemech členů

[Obrázek]

Obrázek 5.37: Odchylky v přenosových objemech při vyloučení hodnot s podílem na objemu menším než 0,15 %

[Obrázek]

Obrázek 5.38: Maximální odchylky měsíčního příspěvku

Výhled do budoucnosti

V roce 2001 bychom rádi zahájili postupnou změnu architektury systému a přepracování jeho jednotlivých částí. Důvodem je postupně narůstající rozpor mezi organizačně-strategickými a technicko-analytickými požadavky na výstupy systému. Stávající mechanismus opírající se o kompromisní sadu částečně zpracovaných provozních dat přestává být efektivní a dostačující.

Z toho vyplývá nutnost rozdělit zpracování provozních dat na dvě části. Část souhrnná bude zaměřena na dlouhodobou historii uchování výstupů a schopnost postihovat provozní vývojové trendy. Část analytická nabídne sice jen velmi krátkou historii uchování dat (dny), ale uchová pokud možno kompletní obraz provozu bez jakýchkoli agregací zanesených zpracováním. Cílem tohoto vývoje by mělo být zajištění optimální podpory jak technickému personálu pro řešení problematického chování infrastruktury, dohledávání útoků a analýzy incidentů, tak organizačnímu a strategickému řízení rozvoje sítě TEN-155 CZ.

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