Správa a monitorování lokálních počítačových sítí

Současná neustále rostoucí velikost a složitost lokálních počítačových sítí přináší i rostoucí požadavky na...


Současná neustále rostoucí velikost a složitost lokálních počítačových sítí
přináší i rostoucí požadavky na nepřetržitý dohled nad jejich správnou
činností, který je nezbytným předpokladem jejich dobré výkonnosti, bezpečnosti
a spolehlivosti.
Cíle správy sítě
Všeobecně používaný pojem "správa počítačové sítě" je poměrně široký a jeho
interpretace není vždy zcela jednoznačná. Můžeme říci, že se jedná o dohled nad
správnou činností technického i softwarového vybavení počítačové sítě, ale i o
jeho neustálou údržbu a postupné rozšiřování.
Při podrobnějším pohledu na práci administrátora zjistíme, že správa počítačové
sítě obsahuje celou řadu nejrůznějších činností, a to zejména:
Správu technického vybavení sítě patří k ní komplexní návrh, instalace a údržba
kabelových rozvodů, instalace a konfigurace síťových adaptérů v počítačích,
zapojování aktivních síťových prvků a dalších zařízení, nepřetržitá kontrola
jejich správné funkce a údržba dokumentace počítačové sítě (řádná a přehledná
dokumentace je velmi často neprávem podceňována, přestože je velmi důležitá pro
lokalizace a opravy poruch).
Administraci adresového prostoru sítě v případě protokolu TCP/IP se jedná o
přidělování a odebírání IP adres koncovým zařízením, odhalování používání
duplicitních IP adres v síti, konfigurace a provoz DNS (Domain Name Service)
serverů, vedení dokumentace o přidělených IP adresách atd.
Zabezpečení spojení LAN s okolními sítěmi, např. Internetem to zahrnuje údržbu
hardwaru a softwaru všech směrovačů, které spojují LAN s okolním světem.
Údržbu programového vybavení v síti jde o instalaci a konfiguraci programových
produktů, přechod na jejich nové verze atp. Programové vybavení používané v
lokální počítačové síti můžeme rozdělit na 2 velké skupiny a to na:
. Software nezbytný pro samotnou funkci sítě např. software pro doručování
elektronické pošty, prostředky pro zajištění funkce serverů DNS, evidenci
přidělených IP adres (databáze přidělených IP adres), realizaci automatického
přidělování adres pomocí protokolů BOOTP (Bootstrap Protocol) a DHCP (Dynamic
Host Configuration Protocol) atd.
. Uživatelský software, kam patří zejména programy pro vzdálený přístup
(telnet, ssh), pro zpracování elektronické pošty, síťové služby ve Windows 3.x
a Windows 95/98/NT, prostředky pro sdílení souborů (souborové servery),
prohlížeče WWW atd.
Zajištění provozu informačních zdrojů v síti FTP serverů, WWW serverů atd.
Monitorování provozu sítě cílem je na základě pravidelného sledování statistik
a chybových hlášení plánovat další rozvoj a předcházet případným poruchám. K
tomu účelu je vhodné využívat v síti dostatečně "inteligentní" síťové prvky a
všechny dostupné prostředky vzdálené správy, např. protokol SNMP (Simple
Network Management Protocol) nebo RMON (Remote MONitoring).
Správu přístupu uživatelů zavádění a rušení oprávněných uživatelů a jejich
skupin, přidělování příslušných přístupových práv, odborné konzultace pro
uživatele, vydávání různých příruček a návodů atd.
Ochranu dat a bezpečnost provozu zálohování dat, ochrana sítě před útoky z
vnějších i vnitřních sítí.
Metody a nástroje pro správu sítě
Výše zmíněné úkoly mohou pomoci správci počítačové sítě realizovat některé
vhodné metody a nástroje, kterým se budeme podrobněji věnovat v další části.
Tvorba dokumentace sítě
Základní činností každého ze správců by měla být tvorba kvalitní technické
dokumentace sítě, která musí obsahovat všechny důležité informace o jejím
hardwarovém vybavení. Součástí takové dokumentace by měla být přehledná
evidence všech koncových zařízení (pracovních stanic, serverů, síťových
tiskáren atp.), seznam a popis aktivních prvků sítě (rozbočovačů, přepínačů,
směrovačů atd.) a konečně velmi důležitá dokumentace instalovaných kabelových
rozvodů.
Zatímco k evidenci koncových zařízení a aktivních prvků postačí v podstatě
libovolná relační databáze, u kabelových rozvodů většinou nevystačíme jen s
popisem stavu, ale je potřeba vytvářet názornou obrazovou dokumentaci (např.
zakreslením všech kabelových vedení do půdorysů místností, budov, případně
celých areálů). Možnými nástroji, které může správce pro svou práci použít,
mohou být, jak již bylo řečeno, obecně používané programové prostředky, jako
jsou relační databáze a vektorové kreslicí programy, nebo produkty speciálně
vytvořené pro tvorbu technické dokumentace sítí. Mezi takové prostředky patří
např. programy NetViz (http://www.netviz.com) nebo Visio Enterprise (http://
www.visio.com), které v sobě spojují funkce databázové s nástroji pro kreslení
technické dokumentace sítě.
Měření kvality vedení
Nenahraditelným pomocníkem správce nebo realizátora datové sítě jsou testery
pro ověřování kvality kabelových vedení (jak metalických, tak optických spojů).
K tomuto účelu jsou vyráběny a dodávány přístroje (testery), které umožňují
změřit základní parametry datového spoje (např. celkový útlum signálu, přeslech
mezi jednotlivými páry vedení, ale i přibližnou délku vedení) a certifikovat
jej pro provoz v daném typu sítě. Příkladem přístroje určeného k měření
kvalitativních parametrů kabelů může být např. zařízení LANcat System5 od firmy
Datacom Textron (http://www.datacomtech.com).
Sledování dostupnosti povel ping
Základním nástrojem pro sledování dostupnosti zařízení na síti je povel ping.
Ten by měl být implementován v každém operačním systému s protokolem TCP/IP a
používá protokol ICMP (Internet Control Message Protocol). Počítač, na kterém
zadáme povel ping spolu s cílovou IP adresou, vyšle po síti žádost o odpověď
(ICMP Echo Request) cílovému počítači a čeká na odezvu. Po obdržení odpovědi
(ICMP Echo Response) zjistí čas, který byl k této činnosti potřeba (Round Trip
Time).
Příklad (výstup povelu ping v operačním systému MS Windows 95):
C:WIN95>ping www.idg.cz
Pinging www.idg.cz [193.85.4.100] with 32 bytes of data:
Reply from 193.85.4.100: bytes=32 time=19ms TTL=249
Reply from 193.85.4.100: bytes=32 time=8ms TTL=249
Reply from 193.85.4.100: bytes=32 time=11ms TTL=249
Reply from 193.85.4.100: bytes=32 time=8ms TTL=249
Tímto jednoduchým povelem lze velmi pohodlně sledovat, zda je určitý počítač
(obecně libovolné zařízení s IP adresou) dostupný na síti, či nikoli. Na
stejném principu pracuje i řada dokonalejších programů pro sledování
dostupnosti jednotlivých zařízení v počítačové síti, kdy může být správce
vizuálně upozorněn na názorném schématu sítě, že některý stroj je nedostupný
při periodických kontrolách (změnou barvy, blikáním atd.). Časová závislost
výstupu povelu ping může ukazovat i to, jak moc je daný spoj vytížen v čase, či
zda není již přetížen natolik, že je na čase posílit jeho přenosovou kapacitu.
Povel traceroute
Pokud chceme zjistit, kudy data od zdroje k cíli procházejí, můžeme použít
povel traceroute (v MS Windows je to povel tracert). Je opět implementován ve
většině síťových operačních systémů. Výstupem tohoto povelu je seznam
směrovačů, přes které data postupně procházejí. Traceroute využívá ICMP
protokol pro získání odpovědi (Time Exceeded) od jednotlivých směrovačů na
cestě k danému cíli. Jméno každého z nich včetně časového údaje vypisuje na
nový řádek. Údaj "* * *" místo jména a čísel znamená, že odpověď ze směrovače
nedošla ve stanoveném časovém limitu. Zde je příklad výstupu:
traceroute to www.idg.cz (193.85.4.100), 30 hops max, 40 byte packets
1 corp-2-eth-1.netsys.com (199.201.233.1) 2,28 ms 2,146 ms 1,986 ms
2 corp-1-eth-1.netsys.com (199.201.232.1) 4,924 ms 2,881 ms 2,82 ms
3 corp-1-serial-0.netsys.com (206.20.143.249) 6,792 ms 5,148 ms 6,29 ms
4 core-1-fddi-0.hck.idt.net (169.132.34.244) 7,466 ms 5,913 ms 7,452 ms
5 h4-0.nyc4-cr4.bbnplanet.net (4.1.75.9) 8,523 ms 16,839 ms 7,501 ms
6 fa0-1-0.nyc4-br2.bbnplanet.net (4.1.64.85) 7,499 ms 8,224 ms 7,257 ms
7 h11-0-0.nyc1-br2.bbnplanet.net (4.0.2.177) 14,776 ms 8,887 ms 8,683 ms
8 h1-0.nynap.bbnplanet.net (4.0.1.26) 12,821 ms 10,361 ms 11,11 ms
9 Pennsauken1.NJ.US.EU.net (192.157.69.75) 10,533 ms 10,625 ms 11,247 ms
10 Amsterdam2.NL.EU.net (134.222.228.121) 180,821 ms 154,055 ms 160,481 ms
11 Amsterdam12.NL.EU.net (134.222.186.12) 156,823 ms 241,866 ms 192,753 ms
12 Prague1.CZ.EU.net (134.222.32.2) 200,912 ms 198,968 ms 202,339 ms
13 ext2-gw.eunet.cz (193.86.72.185) 157,484 ms 228,795 ms 212,679 ms
14 www.idg.cz (193.85.4.100) 174,477 ms 165,704 ms 144,876 ms
Jak zjistit dostupnou přenosovou kapacitu linky
Zjistit maximální možnou přenosovou kapacitu linky mezi dvěma body sítě je
velmi obtížné, výsledky mohou být zkresleny mnoha faktory. Nejlépe by bylo
měřit kapacitu linky přenosem reálných dat, když není zatížena jiným provozem.
I tak jsou výsledky takového měření maximální dostupné kapacity linky vždy jen
orientační.
Analýza provozu
Pokud chceme zjistit to, jaký druh provozu zatěžuje vybraný segment sítě (délka
datagramů, rozdělení protokolů, obsah dat), můžeme použít některý z nástrojů
určených k analýze provozu na síti. Je možné použít libovolný nástroj, který
dokáže odposlouchávat veškerý provoz na daném segmentu sítě, tzn. je schopen
"odchytávání" paketů (např. programy snoop, tcpdump a další). Dokonalejší
možností jsou pak vizuální programy pro grafická prostředí, které názorně
zobrazují potřebné informace (formou různých grafů). Takové nástroje jsou
dostupné jak pro unixové prostředí, tak i pro MS Win 9x/NT (např. LanExplorer
firmy Intellimax http://www.intellimax.com, nebo Observer od firmy Network
Instruments http://www.network instruments.com).
Pro provádění analýzy provozu na lokální počítačové síti jsou dodávána i
jednoúčelová speciální zařízení s poměrně širokou škálou vlastností, velmi
často se zde však jedná o přenosné počítače s patřičným programovým vybavením.
Jejich nevýhodou však bývá jejich poměrně velmi vysoká cena.
Evidence poruch
O všech zaznamenaných poruchách v síti by měly existovat přesné záznamy spolu s
popisem, kdo a jak je řešil, případně i vyřešil. Taková evidence závad a jejich
oprav nemusí být nijak složitá, přesto může ušetřit správci mnoho času v
budoucnu při opakování stejné nebo podobné poruchy.
Statistiky provozu a řízení sítě SNMP
Protokol SNMP (Simple Network Management Protocol) se po svém zavedení v roce
1988 brzy stal nejrozšířenější metodou pro řízení a sledování počítačových
sítí. První verze tohoto protokolu SNMPv1 je definována v RFC 1157. Nepsaným
standardem mezi výrobci zařízení je dnes ovšem jeho novější verze SNMPv2
vzniklá v roce 1993 a upravená v roce 1996. Z důvodu nedostatečné bezpečnosti
obou předchozích verzí vznikla na počátku roku 1998 ještě novější verze, a to
SNMPv3, která přidává mimo jiné i možnost šifrovaného přístupu ke spravovaným
zařízením.
Při vzniku protokolu SNMP bylo cílem vytvořit pro správce univerzální
centralizovaný nástroj pro sledování funkce, kontrolu stavu a vzdálené řízení
sítí (centrální stanice se označuje NMS Network Management Station). Z takového
řídicího uzlu pak může správce číst a nastavovat jednotlivé parametry všech
síťových zařízení.
Programové vybavení, které je k takové činnosti potřeba, se nazývá SNMP
manažer. Ten komunikuje po síti se SNMP agenty v jednotlivých síťových
zařízeních. Všechny potřebné informace jsou uloženy v přesně strukturovaných
tabulkách MIB (Management Information Base). Standardní je dnes verze MIB,
označovaná jako MIB-II, která je definována v RFC 1213.
Identifikace každého objektu MIB je tvořena posloupností přirozených čísel ve
stromové struktuře, např. popis sledovaného systému "sysDescr" je určen takto:
1.3.6.1.2.1.1.1. Definice celých tabulek MIB je zapisována v podmnožině
formálního jazyka ASN.1 (Abstract Syntax Notation) a je nezávislá na
platformách. Stromová struktura MIB dává možnost snadného rozšiřování
standardních definic o další sledované veličiny (např. podle výrobce nebo typu
zařízení).
V protokolu SNMPv2 je definováno celkem 6 základních operací pro komunikaci
mezi centrální řídicí stanicí (NMS) a agenty v jednotlivých sledovaných
zařízeních:
Get dovoluje NMS stanici zjistit hodnotu vybraného objektu od SNMP agenta.
GetNext dovoluje NMS stanici získat hodnotu dalšího objektu ve stromové
struktuře MIB.
GetBulk (jen SNMPv2) tato operace byla přidána, aby se eliminovala potřeba
zadávat velkého množství žádostí GetNext pro přenos větších objemů SNMP dat.
Set dovoluje NMS stanici nastavit hodnotu vybraného objektu v agentu (přístup
je řízen heslem tzv. community string).
Trap používáno na asynchronní informování centrální stanice o významných
událostech.
Inform (jen SNMPv2) dovoluje výměnu Trap informací mezi několika NMS.
Dostupných SNMP managerů je celá řada, jsou určeny pro různé platformy a
operační systémy (MS Windows 3.x/9x/NT, HP-UX, Solaris, Linux atd.). Řada
výrobců aktivních síťových prvků dodává vlastní SNMP manažer s některými
rozšířenými vlastnostmi pro správu jejich zařízení (někdy je součástí dodávky
samotného hardwaru).
RMON
Protokol SNMP má bohužel tu nevýhodu, že se musí SNMP manažer pravidelně
dotazovat jednotlivých SNMP agentů na aktuální stav sledovaných síťových
zařízení (typicky vždy po několika minutách) a tyto informace neustále
vyhodnocovat. Při velkém rozsahu sítě to může vést k jejímu nezanedbatelnému
zatížení přenosem těchto dat. Poměrně časté zpracovávání velkého objemu dat v
centrální stanici ji může velmi nepříjemně zatěžovat. Proto v roce 1991 vznikla
úprava tabulek MIB zvaná RMON Remote MONitoring (RFC 1757). Tato úprava měla za
cíl, aby tabulky MIB neobsahovaly jen aktuální stavové informace zařízení, ale
i statistické, analytické a diagnostické skupiny dat. Struktura RMON MIB
obsahuje několik základních skupin:
1. Statistika statistiky o provozu a chybách
2. Historie časový vývoj veličin
3. Poplachy prahové hodnoty poplachů jednotlivých veličin
4. Hostitelé statistiky vzhledem k adresám fyzické vrstvy
5. TOP N hostitelé nejaktivnějších N zařízení podle vybrané veličiny 6. Matice
provozu sledování vzájemného provozu mezi páry zařízení (podle MAC adres)
7. Filtry nastavení výběru paketů
8. Záznam paketů
9. Události
10. Token Ring specifické informace pro Token Ring
Tabulky objektů RMON mohou být vytvářeny přímo v aktivních síťových prvcích
jako rozšíření standardních tabulek MIB. Jelikož jde o činnost velmi náročnou
na výpočetní výkon, lze do každého segmentu sledované sítě umístit speciální
zařízení tzv. RMON sondu. Ta dokáže analyzovat síťový provoz, ukládat výsledky
do RMON MIB a komunikovat SNMP protokolem s centrální stanicí správy.
RMON verze 2
Někdy nestačí znát, odkud kam jsou data po síti přenášena a s jakou chybovostí,
ale pro další plánování rozvoje sítě je potřeba vědět i to, co datagramy na
síti obsahují, jaké aplikace nejvíce zatěžují síť, co je zdrojem chyb apod. K
takové analýze sítě může sloužit rozšíření RMON MIB s názvem RMON 2 (podle RFC
2021 a 2074). Takto definovaný RMON 2 analyzuje přenášený obsah datagramů na
síti i do vyšších vrstev, než jen na úrovni Ethernetu (IP, TCP/UDP, aplikační
vrstva), kdy je pak možné zjistit zejména, která zařízení a aplikace si po síti
nejvíce vyměňují data, jaké protokoly se nejčastěji pro komunikaci používají
nebo jaké jsou časové odezvy v síti.
Aby RMON 2 dokázal zodpovědět všechny výše uvedené otázky, obsahuje tyto
skupiny dat:
1. Seznam protokolů přehled naměřených protokolů vyšších vrstev
2. Rozložení protokolů četnost jednotlivých protokolů podle počtu paketů nebo
objemu přenesených dat
3. Přiřazení adres přiřazení MAC adres k adresám síťové vrstvy (k IP adresám)
4. Statistika síťové vrstvy statistika (počet paketů/objem dat) podle síťových
adres
5. Matice síťové vrstvy obraz komunikace mezi uzly v síťové vrstvě
6. Statistika aplikační vrstvy statistika (počet paketů/objem dat) podle typu
aplikace
7. Matice aplikační vrstvy obraz komunikace mezi uzly v aplikační vrstvě
8. Uživatelem definovaná historie záznam historie uživatelem definované veličiny
9. Konfigurace sondy parametry RMON sondy
Zobrazování statistik
na WWW serverech
Pro to, aby byl umožněn snadný přístup ke statistickým informacím o síti pro
jejího správce, se dnes často využívá i zobrazování stavu spravovaných zařízení
na WWW serverech. Software SNMP manažerů k tomuto účelu sám dokáže dynamicky
generovat na základě informací získaných SNMP protokolem stránky v jazyce HTML.
Stránky lze již prohlížet libovolným prohlížečem WWW stránek.
Příkladem dobrého prostředku pro generování dynamických HTML stránek s
grafickými informacemi o historii zatížení aktivních prvků sledované sítě může
být známý MRTG (Multi Router Traffic Grapher) http://ee
staff.ethz.ch/~oetiker/webtools/mrtg/mrtg.html. Tímto prostředkem lze snadno
monitorovat libovolný objekt MIB spravovaného zařízení, nejčastěji je to objem
přenesených dat za jednotku času.
Správa sítí založená
na technologii Java
V použití technologií rozvíjejících se v oblasti WWW serverů lze jít i dál a
provádět celou správu sítě speciálními CGI (Common Gateway Interface) skripty,
které dokáží zobrazovat SNMP informace, nebo použít programovací jazyk Java pro
vytváření speciálních appletů pro správu sítě (viz např. stránka o SNMP správě
sítí založené na technologii Java na adrese http://www.adventnet.com/
/products/snmpbeans/). Takové nástroje, které nahrazují klasického SNMP
manažera, jsou pak nezávislé na použité platformě a proto velice snadno
přenositelné.
Závěr
Jak je vidět, použitelných nástrojů a metod, které mohou pomoci správci sítě v
jeho nelehké úloze udržet lokální počítačovou síť v dobrém stavu, je celá řada.
Liší se často svou nákladností některé jsou zcela zdarma, jiné mohou vyžadovat
nemalé investice. Často bude rozhodujícím faktorem pro rozhodování o výběru té
nejvhodnější i míra složitosti jejich praktické implementace.
9 0960 / pen

Nejznámější SNMP manažery
HP OpenView http://www.hp.com/openview/products.html
Cabletron Spectrum http://www.cabletron.com/spectrum/
Solstice NetManager
http://www.sun.com/software/solstice/em-pro-ducts/network/sunnetmg r.html
Cisco Works http://www.cisco.com/warp/public/734//cworks/
SMC EliteView http://www.smc.com/network/managemt/eliteview.html
Novell ManageWise http://www.novell.com/products/managewise/

Gigabitový Ethernet
V letošním TECH-Tipu s názvem "Budování lokální počítačové sítě" (CW 10/99)
jsme se zmínili o stále více se prosazující technologii Gigabitového Ethernetu.
Protože text tohoto TECH-Tipu na předchozí volně navazuje, přinášíme současně s
ním i aktuální informace o stavu této technologie.
Pro Gigabitový Ethernet (http://www.gigabit ethernet.
org/) je v současné době schválena norma 802.3z (1000Base X) z června roku 1998
a ve stadiu draftu je připraven pro konečné přijetí standard 802.3ab (1000Base
T) pro Gigabitový Ethernet na UTP kabelech, u kterého se předpokládá schválení
do září 1999. Jedná se o další desetinásobné zrychlení Ethernetu až na
závratnou rychlost přenosu dat 1 000 Mb/s při zachování přístupové metody k
médiu CSMA/CD (povolen je ale jen jeden opakovač v kolizní doméně) a s možností
nejen polovičního, ale i plného duplexu.
Podle normy 802.3z je možné realizovat Gigabitový Ethernet na vícevidových
optických vláknech při použití vlnové délky záření 850 nm (1000Base SX), na
vícevidových nebo jednovidových optických vláknech s využitím záření s vlnovou
délkou 1 310 nm (1000Base LX), kdy je možné dosáhnout většího dosahu až do
délky jednovidového vlákna 5 km. Součástí normy 802.3z je i standard 1000Base
CX, který definuje možnost přenášet Gigabitový Ethernet po speciálních dobře
stíněných měděných kabelech jen na poměrně krátkou vzdálenost do délky vedení
25 m.
Podle zatím připravované normy 802.3ab (1000Base-T) bude po jejím schválení
Gigabitový Ethernet možné provozovat i na kroucených párech (UTP) kategorie 5 a
lepších (s nutností kontroly některých vybraných vlastností) až do délky kabelu
100 m. Předpokládá se využít pro přenos dat čtyř párů UTP kabelu, kdy se datový
tok rozdělí na paralelní toky 250 Mb/s. Bude opět umožněn jak poloviční
(kolizní), tak plně duplexní provoz.

Přehled značení Gigabitového Ethernetu
OznačeníVýznam
1000Base-SX Gigabitový Ethernet, vícevidová optická vlákna, vlnová délka 850 nm
1000Base-LX Gigabitový Ethernet, vícevidová nebo jednovidová optická vlákna,
vlnová délka 1 310 nm
1000Base-CX Gigabitový Ethernet, speciální stíněné měděné kabely, do
vzdálenosti 25 m
1000Base-TGigabitový Ethernet, UTP kabely kategorie 5 a lepší, do vzdálenosti
100 m (předpokládá se schválení do září 1999)









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