4.5   Sledování a vyhodnocování stavů infrastruktury

Činnost v této oblasti 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í měření aktivních síťových prvků na bázi SNMP (Simple Network Management Protokol). Práce dlouhodobě směřují k vývoji měřícího systému GTDMS, aktuálně jeho druhé generace.

4.5.1   Měřící systém GTDMS-II

Systém GTDMS-II vyvíjíme jako generický, opírající se především o obecně akceptované standardy pro měření na bázi SNMP (Simple Network Management Protocol). Základní strategií budování tohoto systému je universalita jeho použití, tedy jeho schopnost sledovat v uspokojivé míře aktivní prvky v libovolné architektuře sítě bez nutnosti masivního přizpůsobování programu konkrétním vlastnostem jednotlivých prvků.

V souvislosti s přechodem na gigabitovou technologii jsme museli ověřit chování nových směrovačů Cisco GSR12016 při měření standardními postupy (v závislosti na různých verzích operačního systému) a zvážit, zda bude nutné a smysluplné rozšířit stávající spektrum interních měřících možností systému. Provedené testy prokázaly, že měřící systém není nutné v tomto směru rozšiřovat.

Vzhledem k tomu, že v předchozím období jsme vývojové úsilí zaměřovali na precizaci měřících schopností, v roce 2001 jsme směrovali svou aktivitu do oblasti optimalizace a zvýšení flexibility vnitřního chodu systému.

Objemová kritéria měření

S přechodem na gigabitové technologie bylo nutné zaměřit se na zvýšení interní efektivity zpracování dat, a to z důvodů kvantitativních. Množství měřených síťových prvků se postupně rozšiřuje. Produkční instalace systému v současné době měří více než sto síťových zařízení a celkové množství měřených položek převyšuje číslo 80 000. Průměrný časový krok měření jednotlivých položek se pohybuje okolo 200 sekund.

Historie uchování dat (volitelná) je aktuálně omezena na dva roky. Reálná data máme v současnosti uložena za posledních 18 měsíců, což představuje přes 15 GB diskového prostoru. Tato čísla reprezentují přibližně dvojnásobný nárůst požadavků pro měření (z hlediska průměrného počtu měřených položek za sekundu) během jednoho roku.

Abychom snížili nároky na výpočetní výkon, provedli jsme některé programátorské úpravy. Jejich výsledkem je schopnost systému měřit uvedené množství položek s průměrnou časovou diferencí v rozsahu -1 až 1 sekunda oproti požadovanému časovému kroku (při časovém kroku nad 30 sekund). Experimentální simulované měření dává předpoklady, že systém zvládne přibližně čtyřnásobné zvýšení počtu sledovaných položek při zachování ostatních parametrů (průměrný časový krok, ekvivalentní hardware). Průměrná doba k naměření položky prostřednictvím SNMP je v tuto chvíli větší než doba nutná k jejímu internímu zpracování a archivaci, což je uspokojujícím výsledkem práce.

Časová hlediska měření

Nasazení gigabitové technologie způsobilo problémy s měřením položek reprezentovaných čítači s rychlým růstem hodnoty (např. objemy přenášených dat na síťových rozhraních). Běžná, standardně podporovaná metoda měření prostřednictvím 32bitových čítačů v případě mohutných datových toků omezuje délku časového kroku měření. V případě datového toku 100 Mb/s dojde k přetečení čítače cca za 5,5 minuty, v případě toku 1 Gb/s se tento čas zkracuje na 57 sekund.

Pro získání věrohodných výsledků je nutné provést alespoň dvě měření v intervalu souvislého růstu hodnoty čítače. S přihlédnutím k uvedeným intervalům by bylo nutné při použití této metody měření extrémně zkracovat časový krok měření. To s sebou přináší neúnosnou zátěž měřených prvků a měřícího stoje.

Standardy definují u takto citlivých položek určitá rozšíření umožňující měření prostřednictvím hodnot 64bitových čítačů. Touto cestou jsme orientovali další vývoj systému. Nicméně reálné implementace na prvcích použitých v síti ukázaly, že přibližně ve 30 % případů je 64bitová hodnota k dipozici, ale není interně "občerstvována". Čítač vykazuje neustále stejnou hodnotu, bez ohledu na reálný běh událostí. Z tohoto důvodu jsme implementovali "inteligentní" adaptivní mechanismus měření, schopný tento stav detekovat a použít nezávisle obě metody s upřednostněním hodnot 64bitových čítačů.

[Obrázek]

Obrázek 4.9: Provoz na trase Praha-Brno převyšující 1 Gb/s měřený prostřednictvím 64bitových čítačů (15.-21. 10. 2001)

[Obrázek]

Obrázek 4.10: Doplňující statistika četnosti IP datagramů k předchozímu obrázku (Praha-Brno 15.-21. 10. 2001)

Detekce síťových rozhraní měřených prvků

Během prací souvisejících s optimalizací systému jsme přepracovali mechanismus detekce síťových rozhraní měřených prvků tak, aby se dokázal vypořádat s nekorektní změnou indexů rozhraní při restartu některých zařízení. Standardní schéma by mělo být určeno zjištěním (naměřením) údaje o počtu síťových rozhraní. Rozhraní by měla být indexována od jedné do této maximální hodnoty, což umožňuje neagresivní detekci rozhraní SNMP požadavky typu Get. Reálné implementace některých producentů však vytvářejí hodnoty indexů daleko za touto hranicí, což nutně vedlo k nasazení agresivnějšího způsobu detekce pomocí SNMP požadavků GetNext.

Interní překladové mechanismy

Pro měření skupin položek s identifikací nezávislou na identifikaci fyzických komponent systému jsme implementovali interní translační mechanismus pro překlad identifikátorů. Tento mechanismus je aktuální například při sledování rozložení koncových zařízení připojených k jednotlivým síťovým rozhraním aktivních prvků (databáze Ethernet adres jednotlivých rozhraní přepínačů) nebo spektrálního rozložení četnosti datových bloků podle jejich délky na jednotlivých rozhraních (Etherstat) a jiné.

Rozšíření sady měřených položek v souvislosti s dominantními transportními technologiemi NREN

Technologie Ethernet získává v NREN stále vyšší podíl z hlediska počtu rozhraní blízkých jádru páteřní sítě. Z těchto důvodů jsme rozšířili sadu měřených položek o sledování rozložení přenášených ethernetových rámců (RMON Etherstat) podle délky. Dále jsme kompletně přepracovali a rozšířili metody sledování přítomnosti Ethernet MAC adres na jednotlivých rozhraních (RFC 1493) a měření ARP translačních tabulek (RFC 1213).

[Obrázek]

Obrázek 4.11: Ukázka přítomnosti Ethernet MAC adres na rozhraních přepínačů a vazby mezi IP adresami a Ethernet MAC adresami na rozhraní směrovače

[Obrázek]

Obrázek 4.12: Ukázka rozložení délky Ethernet rámců - datový kolektor pro analýzu IPv4 provozu (10.-16. 12. 2001)

[Obrázek]

Obrázek 4.13: Ukázka rozložení délky Ethernet rámců - uživatelské PC (10.-16. 12. 2001)

Pro rozhraní typu PoS (Packet over Sonet) jsme rozšířili sadu měřených položek o detekci chybových stavů (RFC 1595, RFC 2558). Dalšími rozšířeními systému je monitorování četnosti SNMP požadavků v závislosti na jednotlivých typech dotazů a monitorování aktivity sériových rozhraní včetně časových slotů strukturovaných linek.

[Obrázek]

Obrázek 4.14: Ukázka průběhu chybovosti PoS linky (10.-16. 12. 2001)

[Obrázek]

Obrázek 4.15: Statistika SNMP požadavků na zařízení (externí směrovač CESNET2 10.-16. 12. 2001)

Snaha překlenout problém s dynamickou reindexací síťových rozhraní1 vyústila (alespoň na úrovni přenášených objemů dat) do možnosti alternativního pohledu na síťová rozhraní dle verbálního popisu či přidělené IP adresy.

[Obrázek]

Obrázek 4.16: Objem provozu - sumarizace podle IPv4 adresy ve srovnání s průběhy datových toků sumarizovaných podle indexu rozhraní (11. 2001)

Další postup prací

Během roku vyvstal požadavek na měření některých specifických zařízení (např. některé záložní zdroje UPS). Bohužel proprietární řešení některých výrobců nedodržují obecné standardy nebo se ubírají vlastní cestou ve smyslu identifikace a spektra měřitelných veličin. To neumožňuje smysluplně začlenit tyto prvky do měřícího mechanismu, aby veškeré požadované veličiny byly měřitelné generickým způsobem.

Krátkodobým řešením tohoto problému by bylo rozšiřování definiční sady měřitelných položek o všechny nestandardní, což je cesta, od které jsme ustoupili. Jako rozumná strategie se jeví úprava systému směrem k volitelným modulům definic měřitelných položek spolu s implementací inteligentního způsobu jejich výběru v závislosti na aktuálně požadovaných zařízeních. Touto cestou budeme systém vyvíjet v příštím roce.

 

Poznámky:
  1. viz průběžná zpráva o řešení projektu v roce 2000, kapitola 5.7.1
předchozí
obsah
následující
další weby:fond rozvojemetacentrumCzechLightpřenosyvideoservereduroameduID.cz