Bez analýzy nelze dosáhnout kvality

Rychlost práce určité sítě, to je jedno z kritérií, které rozhoduje o její kvalitě. Aby byl výkon sítě na úrovni...


Rychlost práce určité sítě, to je jedno z kritérií, které rozhoduje o její
kvalitě. Aby byl výkon sítě na úrovni, měl by poskytovatel služeb pravidelně
prověřovat vybavovací časy nabízených dat nejlépe pomocí softwaru pro
automatické sledování sítě. Dialogové aplikace vyžadují krátké vybavovací časy,
aby je jejich uživatelé akceptovali. Při multimediálních aplikacích záleží na
zpoždění a na kontinuitě přenosu. Pouze detailní analýza chování jednotlivých
komponent sítě a vyhledání kritických míst zde povede k optimálním hodnotám
kritických veličin a tak ke spokojenosti uživatelů.
Smlouva o úrovni služeb
Každý uživatel má určitou představu o tom, jak rychle má určitý program
pracovat, nebo jak dlouho může trvat např. přenos dat do souborového serveru.
Není-li spokojen, sáhne po telefonu a reklamuje poskytované služby u hotline. Z
tohoto důvodu jsou časy odezvy často předmětem smlouvy o úrovni služeb (Service
Level Agreement SLA).
Konkrétní smlouva o rozsahu a úrovni služeb je dohodou mezi poskytovatelem
služby a zákazníkem. Pokud úroveň služby klesá, stanovuje SLA potřebná opatření
a definuje takzvané eskalační procedury. V dohodě se též hovoří o tom, v jakém
čase musí být služba opět obnovena. Stanovený vybavovací čas zpravidla závisí
na tom, jaký je rozsah dané závady (disfunkce).
Pro posouzení závad existují scénáře možných závad rozdělené do určitých tříd.
K vyhledávání závad slouží vedle standardních měřicích technik speciální
softwarové nástroje. Dělí se do dvou skupin:
nástroje pro monitorování a hlášení (Reporting Tools) v dlouhodobé analýze
sledují vybavovací časy a průchodnost komponent a aplikací v síti
systém sledování závad (Faultmanager) který shromažďuje a eviduje události v
síti v reálném čase
Zjištěné údaje pak slouží k posouzení, zda byla dodržena příslušná smlouva.
Jak sledovat funkčnost sítě
Projektant sítě musí vědět, které komponenty sítě mohou negativně ovlivňovat
chování určitého systému, a tak může již při výstavbě sítě předejít chybám. I
když je však síť navržena dobře, nelze se zcela vyhnout všem závadám, ať už
plynou z poruch jednotlivých prvků, nebo jsou výsledkem nepředpokládaných
provozních špiček. Pro zajištění hladkého provozu je nezbytné provoz na síti
neustále monitorovat a snažit se předpovídat její chování v následujícím období.
K pravidelnému sledování sítě patří i testy jejích jednotlivých komponent. V
nejjednodušším případě se zkoušejí ručně kabelovým testovacím přístrojem
(testerem). Hlavní oblast použití takového měřicího přístroje je 1. vrstva
referenčního modelu OSI. Tím je umožněn pouze test spojení. Zkoušející s
přístrojem prošetřuje, zda spojení v síti mezi komunikačními partnery odpovídá
příslušným specifikacím.
Analyzátor sleduje spojení na úrovni protokolu a kontroluje bit po bitu datový
provoz pomocí odpovídajícího softwarového dekodéru. Rozlišujeme zde přitom dva
různé provozní režimy:
On-line analýza zkoumá spojení ve skutečném čase, tzn. snímá průběžně síťový
provoz a současně jej analyzuje.
Off-line analýza je založena na metodě snímání dat, kdy je záznam o síťovém
provozu uložen v jednom souboru, a tyto podklady slouží pro budoucí rozbory.
Informace o výkonu systému mezi koncovými zařízeními analyzátor poskytne s
maximálním vynaložením energie a pokaždé jen v momentu měření. Pro zjištění
vybavovací doby se analyzuje nejprve datový provoz mezi oběma datovými body
daného spojení a přičítá se zpoždění jednotlivých kroků. Celkový čas (tj. čas
obou cest) je dán dodatečným vyhodnocením potvrzovacího paketu. Tento způsob
kontroly poskytuje informaci o počtu vyslaných datových bytů a množství
přenášených dat.
Protože nasazení analyzátoru protokolu je časově náročné, k dlouhodobému
sledování je vhodnější speciální software.
Program Ping (Packet Internet Groper) vyšle ICMP datový paket (ICMP = Internet
Control Message Protocol). Výzva Ping je úspěšná, jestliže protistanice vyšle
odezvu. V tom případě sdělí informaci o uskutečněném přenosu k cílové adrese a
celkovém času přenosu. V opačném případě se na konzoli objeví informace o
ztrátě přenosového paketu.
Software umožňuje testovat spojení a povoluje testeru propočet různých
výkonových dat na základě variantních velikostí paketů. Také testy
prostřednictvím Pingu vyžadují ruční zadání, a nehodí se tedy pro dlouhodobé
sledování.
Spojení mezi dvěma body v síti lze testovat programem Telnet až na úroveň
uživatele. Jestliže se uskuteční spojení, funguje TCP/IP komunikace mezi uzly
sítě. Telnet je terminálová aplikace a slouží mj. k přenosu dat s aktivními
komponentami sítě, tedy se směrovači nebo přepínači.
Expertní systém jako Mentor od Wavetek Wandel Goltermann nebo Sniffer od
Network Associates může měření na základě vstupů interpretovat ve vlastní
databázi. Předpokladem je datový zdroj, to znamená shromažďování dat nebo
výstup analyzátoru. Software ukáže správci, kde by mohla být potenciální vada v
systému, nebo potvrdí, že odpovídá standardním požadavkům. Nicméně nástroj
neopouští úroveň protokolu a neumožňuje žádné výstupy mimo standardní
hardwarové komponenty a spojení sítě.
Reportování přes RMON
Manažer síťových prvků nabízí přístup ke všem komponentám sítě přes grafické
rozhraní (Graphical User Interface GUI). Díky GUI lze rychle rozeznat stav
sítě. Hlavní oblastí nasazení tohoto manažera je řízení konfigurace a závad.
Slouží například ke správě a sledování aktivních komponent. Program přitom
kontroluje pomocí aktivních dotazů jako SNMP Get nebo Ping zda je daný uzel k
dispozici. Údaje o výkonu z hlediska propojených koncových zařízení však tato
analýza nedodá.
S vývojovým prostředím systému jako Clearcase od Rational nebo s kompilátory
jako C++ mohou uživatelé psát speciální programy pro analýzu, které přebírají
též monitoring. Tato možnost stojí však firmu mnoho času a je méně flexibilní,
protože se programátor musí vždy přizpůsobit určitému konkrétnímu hardwaru.
Výkon hardwaru sledují nástroje pro monitoring. Takový klasický nástroj ve
smyslu standardu Remote Network Monitoring (RMON), např. Trend od Desktalk,
Networkhealth od Concordu nebo Manager od Netscoutu, je založen na agentech
rozložených v síti.
Tyto sondy shromáždí informace o provozu v síti, např. "kdo jak mnoho
komunikuje s kým", a určí vytížení aktivních komponent. Centrála se dotazuje v
pravidelných časových intervalech agentů (polling) a shromažďuje údaje v určité
databázi. Přes noc se v systému připraví report a sestaví se podle předem
daných pravidel a druhý den ráno si ho administrátor sítě může přečíst.
V těchto zprávách nalezne správce systému např. zprávy o vytížení šíře pásma v
určitých definovaných časových intervalech. Mimoto umožňují údaje analýzu
trendů na základě chování systému v blízké budoucnosti. Čísla o přenášeném
objemu dat vydávají jednoduchým způsobem účty pro uživatele sítě. Formule pro
takzvané výkaznictví zní: Náklady = datový provoz v megabytech krát náklad za
megabyte. Zůstává zde však nezodpovězena jedna otázka: Bude dodržen smluvně
přislíbený vybavovací čas aplikace, která byla zákazníkem spuštěna na serveru?
Pokud pošle zákazník aplikace dotaz na server, musí vyčkat, až se mu objeví
odpověď na obrazovce. Tento vyčkávací čas nazýváme dobou odezvy (odpovědi)
aplikace (anglicky "Application Response Time").
Doba odezvy aplikace
Tato doba se skládá z množství vedlejších časů. Nejdříve se aplikace dostane do
oblasti služby sítě klienta. Tato služba rozdělí zprávy pro komunikačního
partnera v paketech na příslušné adresy. Následně se pakety přenesou pomocí
síťových karet. Různé přenosové mechanismy přitom zajišťují, aby zpráva prošla
sítí bezvadně a bez chyby. Aktivní komponenty musí rozhodnout o cestě, kam se
data dále pošlou. Nakonec vezme adaptér sítě pakety, které síťová služba
rozbalí a dá je k dispozici pro další aplikace. V případě chyby přenosu jsou
pakety vyžádány znovu. Z tohoto vychází čas trvání transakce jako suma
následujících dílčích časů:
čas zdržení TCP/IP u odesilatele
čas adaptéru sítě u odesilatele
čas zprostředkování sítě
čas adaptéru sítě u příjemce
čas TCP/IP u příjemce
čas zdržení aplikace u příjemce
Celkový čas je součtem obou časů transakce od klienta k serveru a zpět.
Podstatný je přitom též použitý protokol. Tak reaguje nezajištěný přenos s UDP
v průměru rychleji než spojení TCP/IP.
Měření časů odezvy
Pro měření časů odezvy jsou k dispozici různé postupy:
Uživatel změří prováděcí čas jedné určité transakce stopkami. Tato metoda stojí
nejméně, pokud nebereme v úvahu pracovní čas spolupracovníka. Nicméně je měření
poměrně nepřesné, především tam, kde jsou časy pod jednu sekundu.
Skript spustí testovací transakci a zjistí dobu jejího trvání pomocí rozdílu
časového záznamu, který je např. generován povelem TIME pod UNIXem. Toto je
cenově přiměřená metoda, která však není pro sledování SLA dostatečně pružná,
protože sice změří výsledek, avšak nepošle jej dále. Uživatel potřebuje
dodatečně databázi a nástroje pro statistické vyhodnocení.
Speciální aplikace klient/server změří vybavovací časy jedné aplikace, které
další software vyhodnotí. Abychom získali údaje o celé síti, musí toto měření
brát v úvahu různé "typické" cesty. Z hlediska vybavovacích časů je zpravidla
určen reprezentativní klient z daného segmentu sítě, protože všechny ostatní
počítače v rámci určité větve sítě mají přístup přes tytéž aktivní komponenty
na společnou centrálu služeb. Proto stačí změřit vybrané páry klient/server.
Pomocí tohoto postupu se dosáhne nejvyšší přesnosti měření s minimálními
náklady z hlediska uživatele.
0 1785 / pen

Nástroje pro analýzu
Pokud je úroveň služby nedostatečná, musí její poskytovatel identifikovat
kritické místo. K tomu má následující pomocné prostředky:
měřicí přístroje (testery kabelů, analyzátory)
jednoduchý software (např. Ping)
expertní systémy s analyzátorem
správce aktivních prvků
speciální aplikace s diagnostickými funkcemi a nástroje pro monitorování a
hlášení
Trasování
Trasování cesty hraje důležitou roli při výkaznictví. Postup vyhodnocuje
statisticky různé cesty v síti z hlediska jejich čekacích dob a doby průchodu
signálu. Podle toho, jak je cesta naprogramována, upřednostní jednu z možných
cest. Při analýze se například zjistí, že stanovená hlavní cesta má horší časy
odezvy. Při znalosti údajů určitého spojení mezi dvěma koncovými body lze
optimalizovat jednotlivé spojovací cesty, v nichž se např. jeden hub nahradí
jedním přepínačem nebo protokol TCP/IP nahradí protokolem jiným.









Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.