Monitorovanie a analýza siete. LAN - Local Area Network. Prenosné analytické a monitorovacie systémy

Odoslanie dobrej práce do databázy znalostí je jednoduché. Použite nižšie uvedený formulár

Študenti, postgraduálni študenti, mladí vedci, ktorí využívajú vedomostnú základňu pri štúdiu a práci, vám budú veľmi vďační.

Hostené na http://www.allbest.ru/

ESAY

Tento dokument je technickým projektom na vývoj a implementáciu systému monitorovania siete pre verejnú sieť prenosu údajov mesta Verkhnepyshma spoločnosti Gerkon LLC. Projekt zahŕňal štúdiu existujúcich sieťových monitorovacích systémov, analýzu súčasnej situácie v podniku a zdôvodnil výber konkrétnych komponentov sieťového monitorovacieho systému.

Dokument obsahuje popis konštrukčných riešení a špecifikácie zariadení.

Výsledkom návrhu sú vyvinuté riešenia pre implementáciu a využitie systému:

§ Úplný popis všetkých fáz návrhu, vývoja a implementácie systému;

§ Sprievodca správou systému, ktorý obsahuje popis používateľského rozhrania systému.

Tento dokument predstavuje kompletné konštrukčné riešenia a možno ho použiť na implementáciu systému.

ZOZNAM LISTOV GRAFICKÝCH DOKUMENTOV

Tabuľka 1 - Zoznam listov grafických dokumentov

ZOZNAM SYMBOLOV A POJMOV

Ethernet je štandard prenosu dát vydaný IEEE. Určuje spôsob prenosu alebo príjmu údajov z bežného komunikačného média. Tvorí nižšiu transportnú vrstvu a používajú ho rôzne protokoly vyššej úrovne. Poskytuje rýchlosť prenosu dát 10 Mbps.

Fast Ethernet je technológia prenosu dát rýchlosťou 100 Mb/s pomocou metódy CSMA/CD, rovnako ako 10Base-T.

FDDI - Fiber Distributed Data Interface - optické rozhranie na distribuovaný prenos dát - technológia prenosu dát rýchlosťou 100 Mbps metódou token ring.

IEEE - Institute of Electrical and Electronic Engineers (Institute of Electrical and Electronic Engineers) - organizácia, ktorá vyvíja a vydáva normy.

LAN - Local Area Network - lokálna sieť, LAN.

MAC adresa - Media Access Control - identifikačné číslo sieťového zariadenia, zvyčajne určené výrobcom.

RFC - Request for Comments - súbor dokumentov vydaných organizáciou IEEE, vrátane popisu noriem, špecifikácií atď.

TCP/IP - Transmission Control Protocol/ Internet Protocol - protokol riadenia prenosu/Internetový protokol.

LAN - Lokálna počítačová sieť.

OS - Operačný systém.

ON - Softvér.

SCS - Systém štruktúrovanej kabeláže.

DBMS - Systém správy databáz.

Trend – Dlhodobá štatistika, ktorá umožňuje zostaviť trend tzv.

Využitie - Načítanie kanála alebo segmentu.

POČÍTAČ - Elektronický počítač.

ÚVOD

Informačná infraštruktúra moderného podniku je komplexný konglomerát sietí a systémov rôzneho rozsahu a rozmanitosti. Ak chcete, aby fungovali hladko a efektívne, potrebujete podnikovú platformu na správu s integrovanými nástrojmi. Až donedávna však samotná štruktúra odvetvia správy sietí bránila vytvoreniu takýchto systémov – „hráči“ tohto trhu sa snažili viesť vydávaním produktov obmedzeného rozsahu, využívaním nástrojov a technológií, ktoré nie sú kompatibilné so systémami iných výrobcov. predajcovia.

Dnes sa situácia mení k lepšiemu – existujú produkty, ktoré tvrdia, že univerzálne spravujú celú škálu podnikových informačných zdrojov, od desktopových systémov po sálové počítače a od lokálnych sietí po sieťové zdroje. Zároveň prichádza poznanie, že riadiace aplikácie musia byť otvorené riešeniam od všetkých dodávateľov.

Relevantnosť tejto práce je daná tým, že v súvislosti s rozšírením osobných počítačov a vytváraním automatizovaných pracovných staníc (AWP) na ich základe vzrástol význam lokálnych sietí (LAN), ktorých diagnostika je tzv. objekt našej štúdie. Predmetom štúdia sú hlavné metódy organizácie a vedenia diagnostiky modernej počítačové siete.

"Diagnostika lokálnej siete" - proces (kontinuálnej) analýzy stavu informačnej siete. V prípade poruchy sieťových zariadení sa skutočnosť poruchy zaznamená, určí sa jej poloha a typ. Odošle sa chybové hlásenie, zariadenie sa vypne a nahradí sa zálohou.

Správca siete, ktorý je najčastejšie zodpovedný za diagnostiku, by mal začať študovať vlastnosti svojej siete už v štádiu jej formovania, t.j. poznať sieťovú schému a podrobný popis konfigurácie softvéru s uvedením všetkých parametrov a rozhraní. Na spracovanie a uchovávanie týchto informácií je vhodné špeciálne systémy sieťovú dokumentáciu. Pomocou nich bude správca systému vopred poznať všetky možné „skryté chyby“ a „úzke miesta“ svojho systému, takže v prípade núdze bude vedieť, aký je problém s hardvérom alebo softvérom, program je poškodený, resp. chyba viedla k zásahu operátora.

Správca siete by mal mať na pamäti, že z pohľadu používateľov je rozhodujúca kvalita aplikačného softvéru v sieti. Všetky ostatné kritériá, ako je počet chýb pri prenose dát, miera využitia sieťových zdrojov, výkon zariadenia atď., sú druhoradé. " dobrá sieť„je sieť, ktorej používatelia si nevšimnú, ako funguje.

Spoločnosť

Predgraduálna prax prebiehala vo firme „Gerkon“ LLC na oddelení podpory ako správca systému. Spoločnosť ponúka služby prístupu na internet v mestách Verkhnyaya Pyshma a Sredneuralsk pomocou technológie Ethernet a dial-up kanálov od roku 1993 a je jedným z prvých poskytovateľov internetových služieb v týchto mestách. Pravidlá poskytovania služieb upravuje verejná ponuka a predpisy.

Vedecké a výrobné úlohy divízie

Oddelenie podpory rieši v rámci podniku nasledujúce spektrum úloh:

§ technická a technologická organizácia poskytovania prístupu na internet prostredníctvom dial-up a vyhradených kanálov;

§ technická a technologická organizácia bezdrôtového prístupu k internetu;

§ pridelenie diskového priestoru na ukladanie a prevádzku webových stránok (hosting);

§ podpora práce poštových schránok alebo virtuálny poštový server;

§ umiestnenie zariadenia klienta na mieste poskytovateľa (kolokácia);

§ prenájom vyhradených a virtuálne servery;

§ zálohovanie dát;

§ nasadenie a podpora podnikových sietí súkromných podnikov.

V procese aktivity a zvyšovania objemu dodávok služieb vznikol problém proaktívneho odhaľovania chybných a slabých miest v organizácii siete, teda úlohou bolo implementovať riešenie, ktoré by umožnilo predpovedať potrebu výmeny alebo modernizácie. časti siete predtým, než poruchy ovplyvnia činnosť účastníckych uzlov.

1. SYSTÉMY MONITOROVANIA SIETE

Napriek množstvu techník a nástrojov na zisťovanie a odstraňovanie problémov v počítačových sieťach je „zem pod nohami“ správcov sietí stále dosť vratká. Počítačové siete čoraz viac obsahujú optické a bezdrôtové komponenty, ktoré robia tradičné technológie a nástroje navrhnuté pre konvenčné medené káble bezpredmetnými. Navyše, pri rýchlostiach nad 100 Mbps tradičné diagnostické prístupy často zlyhávajú, aj keď je prenosovým médiom bežný medený kábel. Avšak asi najvýznamnejšou zmenou v technológii počítačových sietí, ktorej museli správcovia čeliť, bol nevyhnutný prechod od zdieľaných ethernetových sietí na prepínané siete, v ktorých jednotlivé servery alebo pracovné stanice často fungujú ako prepínané segmenty.

Je pravda, že s technologickými transformáciami sa niektoré staré problémy vyriešili sami. Koaxiálny kábel, v ktorom bolo vždy ťažšie identifikovať elektrické poruchy ako v prípade krútenej dvojlinky, sa stáva v r. firemné prostredie. Siete Token Ring, ktorých hlavným problémom bola odlišnosť od Ethernetu (a už vôbec nie technická slabosť), sú postupne nahrádzané prepínanými sieťami Ethernet. Protokoly, ktoré generujú početné chybové hlásenia protokolov sieťovej vrstvy, ako napríklad SNA, DECnet a AppleTalk, sa nahrádzajú protokolom IP. Samotný zásobník IP protokolov sa stal stabilnejším a ľahšie sa udržiava, o čom svedčia milióny klientov a miliardy webových stránok na internete. Dokonca aj zarytí odporcovia Microsoftu musia uznať, že pripojenie nového klienta Windows k internetu je oveľa jednoduchšie a spoľahlivejšie ako inštalácia zásobníkov TCP/IP tretích strán a samostatného softvéru na telefonické pripojenie.

Akokoľvek je dnes zložité riešiť problémy a spravovať sieťový výkon pomocou viacerých technológií, situácia by mohla byť ešte hrozivejšia, ak by sa technológia ATM rozšírila na úrovni PC. Pozitívnu úlohu zohralo aj to, že koncom 90-tych rokov, ešte pred získaním prijatia, boli odmietnuté aj niektoré ďalšie technológie vysokorýchlostnej výmeny dát, vrátane Token Ring so šírkou pásma 100 Mbps, 100VG-AnyLAN a pokročilých sietí ARCnet. Napokon, veľmi zložitý zásobník protokolov OSI (ktorý je však legalizovaný radom európskych vlád) bol v USA odmietnutý.

Uvažujme o niektorých naliehavých problémoch, ktoré vznikajú pre správcov sietí podnikov.

Hierarchická topológia počítačových sietí s diaľkovými kanálmi gigabitový ethernet a vyhradené porty prepínačov s rýchlosťou 10 alebo dokonca 100 Mbps pre jednotlivé klientske systémy zvýšili maximálnu šírku pásma potenciálne dostupnú pre používateľov najmenej 10-20 krát. Samozrejme, vo väčšine počítačových sietí existujú úzke miesta na úrovni serverov alebo prístupových smerovačov, pretože šírka pásma na jednotlivého používateľa je výrazne nižšia ako 10 Mbps. Preto nahradenie 10 Mb/s portu rozbočovača vyhradeným 100 Mb/s portom prepínača pre koncový uzol nevedie vždy k výraznému zvýšeniu rýchlosti. Ak si však uvedomíte, že náklady na prepínače sa nedávno znížili a väčšina podnikov nainštalovala kábel kategórie 5, ktorý podporuje technológiu Ethernet 100 Mbps, a nainštalovala sieťové karty, ktoré môžu pracovať rýchlosťou 100 Mbps ihneď po reštarte systému, stane sa to je jasné, prečo je také ťažké odolať pokušeniu modernizácie. V tradičnej zdieľanej sieti LAN môže analyzátor protokolu alebo monitor preskúmať všetku prevádzku v danom segmente siete.

Ryža. 1.1 - Tradičná LAN so zdieľanými médiami a analyzátorom protokolov

Zatiaľ čo výkonnostná výhoda prepínanej siete je niekedy nepatrná, šírenie prepínaných architektúr bolo pre tradičné diagnostické nástroje katastrofálne. V silne segmentovanej sieti môžu sledovači protokolov vidieť iba unicastovú prevádzku na jedinom porte prepínača, na rozdiel od staršej topológie siete, kde by mohli skúmať akýkoľvek paket v kolíziovej doméne. Za takýchto podmienok tradičné monitorovacie nástroje nemôžu zbierať štatistiky o všetkých „konverzáciách“, pretože každý „hovoriaci“ pár koncových bodov v skutočnosti používa svoju vlastnú sieť.

Ryža. 1.2 - Komutovaná sieť

V prepínanej sieti môže analyzátor protokolu v jednom bode „vidieť“ iba jeden segment, ak prepínač nie je schopný zrkadliť viacero portov súčasne.

Na udržanie kontroly nad silne segmentovanými sieťami ponúkajú predajcovia prepínačov množstvo nástrojov na obnovenie plnej viditeľnosti siete, no na ceste je veľa výziev. Prepínače, ktoré sa teraz dodávajú, zvyčajne podporujú „zrkadlenie“ portov, keď je prevádzka jedného z nich duplikovaná na predtým nepoužívanom porte, ku ktorému je pripojený monitor alebo analyzátor.

„Zrkadlenie“ má však množstvo nevýhod. Po prvé, vždy je viditeľný iba jeden port, takže je veľmi ťažké identifikovať problémy, ktoré ovplyvňujú viacero portov naraz. Po druhé, zrkadlenie môže zhoršiť výkon prepínača. Po tretie, zlyhania fyzickej vrstvy sa na zrkadlovom porte zvyčajne nereprodukujú a niekedy sa dokonca stratia označenia VLAN. Nakoniec, v mnohých prípadoch nie je možné plne zrkadliť plne duplexné ethernetové linky.

Čiastočným riešením pri analýze agregovaných prevádzkových parametrov je využitie monitorovacích schopností mini-RMON agentov, najmä preto, že sú zabudované do každého portu väčšiny ethernetových prepínačov. Hoci agenti mini-RMON nepodporujú skupinu objektov RMON II Capture, ktoré poskytujú plnohodnotnú analýzu protokolov, stále dokážu vyhodnotiť využitie prostriedkov, chybovosť a objem multicast.

Niektoré z nedostatkov technológie zrkadlenia portov možno prekonať inštaláciou „pasívnych odbočovačov“, ako sú tie od spoločnosti Shomiti. Tieto zariadenia sú predinštalovanými Y-konektormi a umožňujú analyzátorom protokolov alebo iným zariadeniam monitorovať skutočný signál, nie ten regenerovaný.

Ďalším aktuálnym problémom je problém s vlastnosťami optiky. Správcovia počítačových sietí zvyčajne používajú na riešenie problémov s optickými káblami iba špecializované diagnostické zariadenia optickej siete. Bežný štandardný softvér na správu zariadení SNMP alebo CLI dokáže odhaliť problémy na prepínačoch a smerovačoch s optickými rozhraniami. A len niekoľko správcov siete čelí potrebe diagnostikovať zariadenia SONET.

Pri optických kábloch je podstatne menej dôvodov na výskyt prípadných porúch v nich ako v prípade medeného kábla. Optické signály nespôsobujú presluchy, čo vyplýva zo skutočnosti, že signál jedného vodiča indukuje signál na druhom - tento faktor najviac komplikuje diagnostické zariadenie pre medený kábel. Optické káble sú odolné voči elektromagnetickému šumu a indukovaným signálom, takže nemusia byť umiestnené mimo elektromotorov výťahov a žiariviek, t.j. všetky tieto premenné môžu byť vylúčené z diagnostického scenára.

Sila signálu alebo optický výkon v danom bode je skutočne jedinou premennou, ktorú je potrebné merať pri riešení problémov s optickými sieťami. Ak je možné určiť stratu signálu cez optický kanál, potom bude možné identifikovať takmer akýkoľvek problém. Lacné prídavné moduly pre testery medených káblov umožňujú optické merania.

Podniky, ktoré nasadili veľkú optickú infraštruktúru a sami si ju udržiavajú, si možno budú musieť zakúpiť reflektometer OTDR (Optical Time Domain Reflectometer), ktorý vykonáva rovnaké funkcie pre optické vlákno ako reflektometer časovej domény (TDR) pre medený kábel. Zariadenie funguje ako radar: vysiela impulzné signály po kábli a analyzuje ich odrazy, na základe čoho deteguje poruchy vodiča alebo inú anomáliu a následne povie odborníkovi, kde má v kábli hľadať zdroj problému. .

Zatiaľ čo rôzni predajcovia káblových konektorov a konektorov zjednodušili ukončenie a rozvetvenie optických vlákien, stále si to vyžaduje určitú úroveň špecializovaných zručností a so správnou politikou bude musieť podnik s rozvinutou optickou infraštruktúrou školiť svojich zamestnancov. Bez ohľadu na to, ako dobre je káblová sieť položená, vždy existuje možnosť fyzického poškodenia kábla v dôsledku neočakávanej udalosti.

Môže sa vyskytnúť aj odstraňovanie problémov s bezdrôtovými sieťami LAN 802.11b. Samotná diagnostika je rovnako jednoduchá ako v prípade ethernetových sietí založených na rozbočovačoch, keďže bezdrôtové prenosové médium zdieľajú všetci majitelia klientskych rádiových zariadení. Spoločnosť Sniffer TechHlogies bola prvá, ktorá ponúkla riešenie analýzy protokolov pre takéto siete až do 11 Mbps, a následne väčšina popredných predajcov analyzátorov predstavila podobné systémy.

Na rozdiel od káblového ethernetového rozbočovača nie je kvalita bezdrôtových klientskych pripojení ani zďaleka konzistentná. Mikrovlnné rádiové signály používané vo všetkých miestnych prenosoch sú slabé a niekedy nepredvídateľné. Dokonca malé zmeny Pozícia antény môže vážne ovplyvniť kvalitu pripojenia. Bezdrôtové prístupové body LAN sa dodávajú s konzolou na správu zariadenia, čo je často efektívnejšia diagnostická metóda ako návšteva bezdrôtových klientov a monitorovanie priepustnosti a chybových stavov pomocou ručného analyzátora.

Hoci problémy so synchronizáciou údajov a inštaláciou zariadení, s ktorými sa stretávajú používatelia osobných digitálnych asistentov (PDA), prirodzenejšie zodpovedajú úlohám tímu technickej podpory než povinnostiam správcu siete, nie je ťažké predvídať, že v blízkej budúcnosti bude takéto zariadenia sa vyvinú zo samostatných pomocných nástrojov, ktoré dopĺňajú PC, v plnohodnotných sieťových klientoch.

Spravidla prevádzkovatelia firemných bezdrôtové siete bude (alebo by malo) zabrániť nasadeniu príliš otvorených systémov, v ktorých každý používateľ v rámci pokrytia siete a vlastniaci kompatibilnú kartu rozhrania získa prístup ku každému informačnému rámcu systému. Bezdrôtový bezpečnostný protokol WEP (Wired Equivalent Privacy) poskytuje autentifikáciu používateľa, zabezpečenie integrity a šifrovanie údajov, ale ako to zvyčajne býva, pokročilé zabezpečenie sťažuje analýzu príčin sieťových problémov. V zabezpečených sieťach s podporou WEP musia diagnostici poznať kľúče alebo heslá, ktoré chránia informačné zdroje a riadia prístup do systému. Pri prístupe v režime príjmu všetkých paketov bude analyzátor protokolu schopný vidieť všetky hlavičky rámcov, ale informácie v nich obsiahnuté bez prítomnosti kľúčov budú bezvýznamné.

Pri diagnostike tunelovaných prepojení, ktorým mnohí predajcovia hovoria virtuálne privátne siete vzdialený prístup, vznikajúce problémy sú podobné tým, ktoré sa vyskytujú pri analýze šifrovaných bezdrôtových sietí. Ak prevádzka neprechádza cez tunelované spojenie, príčina zlyhania sa nedá ľahko určiť. Môže ísť o chybu autentifikácie, zlyhanie na jednom z koncových bodov alebo preťaženie verejnej internetovej zóny. Pokúšať sa použiť analyzátor protokolov na detekciu chýb vysokej úrovne v tunelovanej prevádzke by bolo zbytočné, pretože obsah údajov, ako aj hlavičky aplikácie, prenosu a sieťovej vrstvy sú šifrované. Opatrenia prijaté na zlepšenie bezpečnosti podnikových sietí majú vo všeobecnosti tendenciu sťažiť identifikáciu porúch a problémov s výkonom. Firewally, proxy servery a systémy detekcie narušenia môžu ešte viac skomplikovať riešenie problémov.

Problém diagnostiky počítačových sietí je teda aktuálny a v konečnom dôsledku je diagnostika porúch úlohou manažmentu. Pre tých najkritickejších podnikové systémy, zdĺhavé snahy o obnovu sú neprijateľné, takže jediným riešením je použitie redundantných zariadení a procesov, ktoré dokážu prevziať potrebné funkcie ihneď po výskyte zlyhania. V niektorých podnikoch majú siete vždy dodatočný redundantný komponent pre prípad, že hlavný komponent zlyhá, to znamená n x 2 komponentov, kde n je počet primárnych komponentov potrebných na zabezpečenie prijateľného výkonu. Ak je stredná doba opravy (MTTR) dostatočne vysoká, môže byť potrebná väčšia redundancia. Ide o to, že čas na riešenie problémov nie je ľahké predvídať a značné náklady počas nepredvídateľného obdobia obnovy sú znakom zlého riadenia.

V prípade menej kritických systémov nemusí byť redundancia ekonomicky opodstatnená, v takom prípade sa môže oplatí investovať do efektívne nástroje(a pri školení zamestnancov) na urýchlenie procesu diagnostiky a riešenia problémov v podniku. Okrem toho možno podporu pre určité systémy zadať externe, buď outsourcingom do podniku, alebo využitím možností externých dátových centier, alebo kontaktovaním poskytovateľov aplikačných služieb (ASP) alebo poskytovateľov služieb správy. Za najvýznamnejší faktor ovplyvňujúci rozhodnutie využiť služby organizácií tretích strán možno popri nákladoch považovať úroveň spôsobilosti vlastného personálu. Správcovia siete musia zvážiť, či konkrétna funkcia tak úzko súvisí so špecifickými úlohami podniku, že nemožno očakávať, že špecialista tretej strany odvedie lepšiu prácu, než akú by odviedli zamestnanci spoločnosti.

Takmer okamžite po nasadení prvých podnikových sietí, ktorých spoľahlivosť zostala v nedohľadne, výrobcovia a vývojári predložili koncept „samoopravných sietí“. Moderné siete sú určite spoľahlivejšie ako v 90. rokoch, ale nie preto, že by sa problémy začali samé opravovať. Riešenie problémov so softvérovými a hardvérovými poruchami v súčasných sieťach si stále vyžaduje ľudský zásah a neočakáva sa, že by sa tento stav v krátkodobom horizonte zásadne zmenil. Diagnostické metódy a nástroje sú celkom v súlade s modernými postupmi a technológiami, ale zatiaľ nedosiahli úroveň, ktorá by výrazne šetrila sieťovým administrátorom čas v boji so sieťovými problémami a výkonnostnými medzerami.

1 .1 Diagnostický softvér

Medzi softvérom na diagnostiku počítačových sietí možno vyčleniť špeciálne systémy riadenia siete (Network Management Systems) - centralizované softvérové ​​systémy, ktoré zhromažďujú údaje o stave sieťových uzlov a komunikačných zariadení, ako aj údaje o premávke v sieti. Tieto systémy nielen monitorujú a analyzujú sieť, ale tiež vykonávajú akcie správy siete v automatickom alebo poloautomatickom režime - povoľovanie a zakázanie portov zariadení, zmena parametrov mostov adresných tabuliek mostov, prepínačov a smerovačov atď. Príkladmi riadiacich systémov sú populárne systémy HPOpenView, SunNetManager, IBMNetView.

Nástroje na správu systému vykonávajú funkcie podobné funkciám systémov správy, ale s ohľadom na komunikačné zariadenia. Niektoré funkcie týchto dvoch typov systémov správy sa však môžu prekrývať, napríklad nástroje na správu systému môžu vykonávať základnú analýzu sieťovej prevádzky.

Expertné systémy. Tento typ systému zhromažďuje ľudské znalosti o identifikácii príčin abnormálnej prevádzky siete a možných spôsoboch, ako priviesť sieť späť do zdravého stavu. Expertné systémy sú často implementované ako samostatné podsystémy rôznych nástrojov na monitorovanie a analýzu siete: systémy riadenia siete, analyzátory protokolov, analyzátory siete. Najjednoduchšou verziou expertného systému je kontextový systém pomoci. Zložitejšie expertné systémy sú takzvané znalostné bázy s prvkami umela inteligencia. Príkladom takéhoto systému je expertný systém zabudovaný do riadiaceho systému Spectrum spoločnosti Cabletron.

1.1.1 Analyzátory protokolov

V priebehu navrhovania novej alebo modernizácie starej siete je často potrebné kvantifikovať niektoré charakteristiky siete, ako je napríklad intenzita dátových tokov cez sieťové komunikačné linky, oneskorenia, ktoré sa vyskytujú v rôznych fázach spracovania paketov, odozva. časov na požiadavky toho či onoho druhu, frekvenciu výskytu určitých udalostí a iné charakteristiky.

Na tieto účely možno použiť rôzne prostriedky a predovšetkým monitorovacie nástroje v systémoch riadenia siete, o ktorých už bola reč vyššie. Niektoré merania v sieti je možné vykonávať aj softvérovými meračmi zabudovanými v operačnom systéme, príkladom je OS Windows Performance Monitor. Dokonca testery káblov vo svojom modernom dizajne sú schopné zachytávať pakety a analyzovať ich obsah.

Najpokročilejším nástrojom na výskum siete je však analyzátor protokolov. Proces analýzy protokolu zahŕňa zachytávanie paketov cirkulujúcich v sieti, ktoré implementujú konkrétny sieťový protokol, a skúmanie obsahu týchto paketov. Na základe výsledkov analýzy je možné vykonávať rozumné a vyvážené zmeny akýchkoľvek sieťových komponentov, optimalizovať ich výkon a odstraňovať problémy. Je zrejmé, že na to, aby bolo možné vyvodiť závery o vplyve zmeny na sieť, je potrebné analyzovať protokoly pred a po vykonaní zmeny.

Analyzátor protokolov je buď nezávislé špecializované zariadenie alebo osobný počítač, zvyčajne prenosný, triedy Htebook, vybavený špeciálnou sieťovou kartou a súvisiacim softvérom. Použitá sieťová karta a softvér musia zodpovedať topológii siete (kruh, zbernica, hviezda). Analyzátor sa pripája k sieti rovnakým spôsobom ako bežný uzol. Rozdiel je v tom, že analyzátor môže prijímať všetky dátové pakety prenášané cez sieť, zatiaľ čo bežná stanica môže prijímať len tie, ktoré sú jej adresované. Softvér analyzátora pozostáva z jadra, ktoré podporuje činnosť sieťového adaptéra a dekóduje prijaté dáta, a dodatočného programového kódu v závislosti od typu topológie skúmanej siete. Okrem toho sa dodáva množstvo dekódovacích rutín špecifických pre protokol, ako napríklad IPX. Súčasťou niektorých analyzátorov môže byť aj expertný systém, ktorý môže užívateľovi poskytnúť odporúčania, aké experimenty by sa mali v danej situácii vykonať, čo môže znamenať určité výsledky meraní, ako eliminovať určité typy výpadkov siete.

Napriek relatívnej rozmanitosti analyzátorov protokolov na trhu existujú niektoré funkcie, ktoré sú do určitej miery vlastné všetkým z nich:

Užívateľské rozhranie. Väčšina analyzátorov má vyvinuté užívateľsky prívetivé rozhranie, zvyčajne založené na Windows alebo Motif. Toto rozhranie umožňuje užívateľovi: zobraziť výsledky analýzy intenzity dopravy; získať okamžité a priemerné štatistické hodnotenie výkonu siete; nastaviť určité udalosti a kritické situácie na sledovanie ich výskytu; vykonať dekódovanie protokolu rôzne úrovne a prezentovať v zrozumiteľnej forme obsah balíkov.

Zachytiť vyrovnávaciu pamäť. Pufry rôznych analyzátorov sa líšia objemom. Buffer môže byť umiestnený na inštalovanom internetová karta, alebo mu môže byť pridelené miesto v pamäti RAM jedného z počítačov v sieti. Ak je vyrovnávacia pamäť umiestnená na sieťovej karte, potom je riadená hardvérom a vďaka tomu sa zvyšuje vstupná rýchlosť. To však vedie k zvýšeniu nákladov na analyzátor. V prípade nedostatočného vykonania postupu zachytávania sa niektoré informácie stratia a analýza nebude možná. Veľkosť vyrovnávacej pamäte určuje schopnosť analyzovať viac či menej reprezentatívne vzorky zachytených dát. Ale bez ohľadu na to, aký veľký je zachytávací buffer, skôr či neskôr sa zaplní. V tomto prípade sa buď zachytávanie zastaví, alebo plnenie začne od začiatku vyrovnávacej pamäte.

Filtre. Filtre vám umožňujú kontrolovať proces zachytávania údajov, a tým šetriť miesto vo vyrovnávacej pamäti. V závislosti od hodnoty určitých polí v pakete špecifikovanej ako podmienka filtra sa paket buď ignoruje, alebo sa zapíše do vyrovnávacej pamäte. Použitie filtrov výrazne urýchľuje a zjednodušuje analýzu, pretože vylučuje prezeranie balíkov, ktoré momentálne nie sú potrebné.

Prepínače sú určité podmienky na spustenie a zastavenie procesu zachytávania dát zo siete, ktoré určuje operátor. Takýmito podmienkami môže byť vykonanie manuálnych príkazov na spustenie a zastavenie procesu snímania, čas dňa, trvanie procesu snímania, výskyt určitých hodnôt v dátových rámcoch. Prepínače možno použiť v spojení s filtrami, čo umožňuje podrobnejšiu a jemnejšiu analýzu, ako aj produktívnejšie využitie obmedzeného množstva vyrovnávacej pamäte.

Vyhľadávanie. Niektoré analyzátory protokolov vám umožňujú automatizovať kontrolu informácií vo vyrovnávacej pamäti a nájsť v nej údaje podľa špecifikovaných kritérií. Zatiaľ čo filtre kontrolujú vstupný tok v porovnaní s podmienkami filtra, funkcie vyhľadávania sa aplikujú na údaje, ktoré sú už nazhromaždené vo vyrovnávacej pamäti.

Metodika analýzy môže byť prezentovaná vo forme nasledujúcich šiestich etáp:

1. Zachytenie údajov.

2. Zobrazte zachytené údaje.

3. Analýza údajov.

4. Hľadajte chyby. (Väčšina syntaktických analyzátorov uľahčuje túto prácu identifikáciou typov chýb a identifikáciou stanice, z ktorej chybný paket prišiel.)

5. Výkonnostná štúdia. Vypočíta sa využitie šírky pásma siete alebo priemerný čas odozvy na požiadavku.

6. Podrobná štúdia jednotlivých úsekov siete. Obsah tejto fázy je špecifikovaný pri vykonávaní analýzy.

Proces analýzy protokolu zvyčajne trvá relatívne málo času – 1 – 2 pracovné dni.

Väčšina moderných analyzátorov umožňuje analyzovať niekoľko WAN protokolov naraz, ako sú X.25, PPP, SLIP, SDLC/SNA, frame relay, SMDS, ISDN, mostové/routerové protokoly (3Com, Cisco, Bay Networks a iné). Takéto analyzátory umožňujú merať rôzne parametre protokolov, analyzovať sieťovú prevádzku, konvertovať medzi protokolmi LAN a WAN, oneskorenie na smerovačoch počas týchto konverzií atď. Pokročilejšie zariadenia poskytujú možnosť simulácie a dekódovania WAN protokolov, "záťažové" testovanie, meranie maxima priepustnosť, testovanie kvality poskytovaných služieb. Z dôvodu univerzálnosti implementujú takmer všetky analyzátory WAN protokolu funkcie testovania LAN a všetkých hlavných rozhraní. Niektoré prístroje sú schopné analyzovať telefónne protokoly. A najmodernejšie modely dokážu dekódovať a prezentovať všetkých sedem úrovne OSI. Nástup ATM viedol výrobcov k tomu, aby svojim analyzátorom poskytli prostriedky na testovanie týchto sietí. Tieto prístroje dokážu plne otestovať siete ATM E-1/E-3 s podporou monitorovania a simulácie. Súbor servisných funkcií analyzátora je veľmi dôležitý. Niektoré z nich, ako napríklad možnosť diaľkového ovládania zariadenia, sú jednoducho nenahraditeľné.

Moderné analyzátory protokolu WAN/LAN/DTM teda dokážu odhaliť chyby v konfigurácii smerovačov a mostov; nastaviť typ prenosu odosielaného cez globálnu sieť; určiť použitý rozsah rýchlosti, optimalizovať pomer medzi šírkou pásma a počtom kanálov; lokalizovať zdroj nesprávnej návštevnosti; vykonať testovanie sériové rozhrania a úplné testovanie ATM; vykonávať úplné monitorovanie a dekódovanie hlavných protokolov na akomkoľvek kanáli; analyzovať štatistiky v reálnom čase, vrátane analýzy prevádzky LAN cez siete WAN.

1.1.2 Monitorovacie protokoly

SNMP protokol

SNMP (anglicky Simple Network Management Protocol - simple network management protocol) je protokol na správu komunikačných sietí založený na architektúre TCP / IP.

Na základe koncepcie TMN v rokoch 1980-1990. rôzne normalizačné orgány vyvinuli množstvo protokolov na správu dátových sietí s rôznym spektrom implementácie funkcií TMN. Jedným typom takéhoto riadiaceho protokolu je SNMP. Protokol SNMP bol vyvinutý na testovanie funkčnosti sieťových smerovačov a mostov. Následne rozsah protokolu pokrýval aj ďalšie sieťové zariadenia, ako sú huby, brány, terminálové servery, servery LAN Manager, stroje pod Ovládanie Windows NT atď. Okrem toho protokol umožňuje vykonávať zmeny vo fungovaní týchto zariadení.

Táto technológia je navrhnutá tak, aby poskytovala správu a kontrolu nad zariadeniami a aplikáciami v komunikačnej sieti prostredníctvom výmeny riadiacich informácií medzi agentmi umiestnenými na sieťových zariadeniach a manažérmi umiestnenými na riadiacich staniciach. SNMP definuje sieť ako súbor staníc pre správu siete a sieťových prvkov (hostiteľov, brán a smerovačov, terminálových serverov), ktoré spolu zabezpečujú administratívnu komunikáciu medzi stanicami správy siete a sieťovými agentmi.

Pri používaní SNMP existujú riadené a riadiace systémy. Riadený systém obsahuje komponent nazývaný agent, ktorý posiela správy do riadiaceho systému. V podstate odosielajú SNMP agenti informácie o riadení na riadiacich systémoch ako premenné (ako napríklad „voľná pamäť“, „názov systému“, „počet spustených procesov“).

Agent v protokole SNMP je procesný prvok, ktorý poskytuje manažérom umiestneným na staniciach riadenia siete prístup k hodnotám premenných MIB a umožňuje im tak implementovať funkcie správy a monitorovania zariadení.

Softvérový agent je rezidentný program, ktorý vykonáva riadiace funkcie a tiež zbiera štatistiky na ich prenos do informačnej základne sieťového zariadenia.

Hardvérový agent - vstavaný hardvér (s procesorom a pamäťou), ktorý ukladá softvérových agentov.

Premenné prístupné cez SNMP sú usporiadané v hierarchii. Tieto hierarchie a ďalšie metaúdaje (napríklad typ a popis premennej) sú opísané v riadiacich informačných bázach (MIB).

Dnes existuje niekoľko štandardov pre riadiace informačné databázy. Hlavnými sú štandardy MIB-I a MIB-II, ako aj verzia databázy pre diaľkové ovládanie RMON MIB. Okrem toho existujú štandardy pre špeciálne MIB zariadenia určitého typu (napríklad MIB pre rozbočovače alebo MIB pre modemy), ako aj súkromné ​​MIB konkrétnych výrobcov zariadení.

Pôvodná špecifikácia MIB-I definovala iba operácie na čítanie hodnôt premenných. Operácie na zmenu alebo nastavenie hodnôt objektov sú súčasťou špecifikácií MIB-II.

Verzia MIB-I (RFC 1156) definuje až 114 objektov, ktoré sú rozdelené do 8 skupín:

* Systém – všeobecné údaje o zariadení (napríklad ID predajcu, čas poslednej inicializácie systému).

* Rozhrania – popisuje parametre sieťových rozhraní zariadenia (napríklad ich počet, typy, výmenné kurzy, maximálna veľkosť paketov).

* AddressTranslationTable – popisuje súlad medzi sieťovými a fyzickými adresami (napríklad prostredníctvom protokolu ARP).

* InternetProtocol - údaje súvisiace s IP protokolom (adresy IP brán, hostiteľov, štatistiky IP paketov).

* ICMP - údaje súvisiace s protokolom výmeny riadiacich správ ICMP.

* TCP - údaje súvisiace s protokolom TCP (napríklad o TCP spojeniach).

* UDP - údaje súvisiace s protokolom UDP (počet prenesených, prijatých a chybných UPD datagramov).

*EGP - údaje súvisiace s protokolom výmeny smerovacích informácií ExteriorGatewayProtocol používaným v Internetové siete(počet správ prijatých s chybami a bez nich).

Z tohto zoznamu skupín premenných je zrejmé, že štandard MIB-I bol vyvinutý so silným zameraním na správu smerovačov, ktoré podporujú protokoly zásobníka TCP/IP.

Vo verzii MIB-II (RFC 1213), prijatej v roku 1992, sa výrazne (až na 185) rozšírila sada štandardných objektov a počet skupín sa zvýšil na 10.

Agenti RMON

Najnovší prírastok do funkčnosť SNMP je špecifikácia RMON, ktorá poskytuje vzdialenú komunikáciu s MIB.

Štandard pre RMON sa objavil v novembri 1991, keď Internet Engineering Task Force vydala RFC 1271 s názvom „Remote Network Monitoring Management Information Base“ (“ Informačná základňa vzdialené monitorovanie siete"). Tento dokument popisuje RMON pre siete Ethernet.

RMON je protokol na monitorovanie počítačových sietí, nadstavba SNMP, ktorý je podobne ako SNMP založený na zbere a analýze informácií o povahe informácií prenášaných cez sieť. Rovnako ako v SNMP, informácie sú zhromažďované hardvérovými a softvérovými agentmi, z ktorých sa údaje odosielajú do počítača, kde je nainštalovaná aplikácia na správu siete. Rozdiel medzi RMON a jeho predchodcom je predovšetkým v povahe zhromažďovaných informácií - ak v SNMP tieto informácie charakterizujú iba udalosti vyskytujúce sa na zariadení, kde je nainštalovaný agent, potom RMON vyžaduje, aby prijaté údaje charakterizovali prevádzku medzi sieťou zariadení.

Pred RMON sa SNMP nedalo používať na diaľku, iba to umožňovalo miestne ovládanie zariadení. RMON MIB má vylepšenú sadu vlastností pre vzdialenú správu, pretože obsahuje súhrnné informácie o zariadení, čo nevyžaduje prenos veľkého množstva informácií cez sieť. Objekty RMON MIB zahŕňajú dodatočné počítadlá chýb paketov, flexibilnejšiu analýzu grafických trendov a štatistík a ďalšie výkonné nástroje filtrovanie na zachytávanie a analýzu jednotlivých paketov, ako aj zložitejšie podmienky pre nastavenie upozornení. Agenti RMON MIB sú inteligentnejší ako agenti MIB-I alebo MIB-II a vykonávajú veľkú časť práce pri spracovaní informácií o zariadení, ktorú robili manažéri. Títo agenti môžu byť umiestnení vo vnútri rôznych komunikačných zariadení, ako aj implementovaní ako samostatné softvérové ​​moduly bežiace na univerzálnych PC a notebookoch (ako príklad môže poslúžiť LANalyzerНvell).

Inteligencia agentov RMON im umožňuje vykonávať jednoduché odstraňovanie porúch a varovné akcie - napríklad v rámci technológie RMON môžete zbierať údaje o bežnom fungovaní siete (t. j. vykonávať tzv. baselining) a následne vydávať varovné signály, keď sa prevádzkový režim siete odchýli od základnej línie – môže to naznačovať najmä to, že zariadenie nie je plne funkčné. Zhromaždením informácií od agentov RMON môže aplikácia na správu pomôcť správcovi siete (napríklad vzdialenému tisíce kilometrov) lokalizovať problém a vypracovať najlepší akčný plán na jeho vyriešenie.

Informácie RMON zhromažďujú hardvérové ​​a softvérové ​​sondy pripojené priamo k sieti. Na vykonanie úlohy zberu a primárnej analýzy údajov musí mať sonda dostatok výpočtových zdrojov a RAM. V súčasnosti sú na trhu tri typy sond: vstavané sondy, počítačové sondy a samostatné sondy. Produkt sa považuje za produkt s povoleným RMON, ak implementuje aspoň jednu skupinu RMON. Samozrejme, čím viac dátových skupín RMON je v danom produkte implementovaných, tým je na jednej strane drahší a na druhej strane kompletnejšie informácie o prevádzke siete poskytuje.

Vstavané sondy sú rozširujúce moduly pre sieťové zariadenia. Takéto moduly vyrába mnoho výrobcov, najmä také veľké spoločnosti ako 3Com, Cabletron, Bay Networks a Cisco. (Mimochodom, 3Com a Bay Networks nedávno získali Axon a ARMON, uznávaných lídrov v dizajne a výrobe nástrojov na správu RMON. Takýto záujem o túto technológiu zo strany hlavných výrobcov sieťových zariadení opäť ukazuje, aké nevyhnutné je vzdialené monitorovanie pre používateľov.) Väčšina rozhodnutí vkladanie modulov RMON do rozbočovačov sa zdá prirodzené, pretože práve z pozorovania týchto zariadení si možno urobiť predstavu o fungovaní segmentu. Výhoda takýchto sond je zrejmá: umožňujú získať informácie o všetkých hlavných dátových skupinách RMON za relatívne nízku cenu. Nevýhodou je v prvom rade nie príliš vysoký výkon, čo sa prejavuje najmä v tom, že vstavané sondy často podporujú zďaleka nie všetky dátové skupiny RMON. Nie je to tak dávno, čo spoločnosť 3Com oznámila svoj zámer vydať ovládače s podporou RMON pre sieťové adaptéry Etherlink III a Fast Ethernet. V dôsledku toho bude možné zbierať a analyzovať dáta RMON priamo z pracovných staníc v sieti.

Počítačové sondy sú jednoducho prepojené počítače s nainštalovaným softvérovým agentom RMON. Tieto sondy (ako napríklad Network General's Cornerstone Agent 2.5) sú rýchlejšie ako vstavané sondy a vo všeobecnosti podporujú všetky dátové skupiny RMON. Sú drahšie ako vstavané sondy, ale oveľa lacnejšie ako samostatné sondy. Navyše, počítačové sondy majú dosť veľká veľkosť, čo môže niekedy limitovať možnosti ich aplikácie.

Samostatné sondy majú najvyšší výkon; ako je ľahko pochopiteľné, sú to zároveň najdrahšie produkty zo všetkých opísaných. Samostatnou sondou je zvyčajne procesor (trieda i486 alebo RISC procesor) vybavený dostatočnou pamäťou RAM a sieťový adaptér. Lídrami v tomto sektore trhu sú Frontier a Hewlett-Packard. Sondy tohto typu majú malú veľkosť a sú vysoko mobilné – veľmi jednoducho sa pripájajú a odpájajú od siete. Pri riešení problému riadenia globálnej siete to, samozrejme, nie je veľmi dôležitá vlastnosť, ale ak sa nástroje RMON používajú na analýzu prevádzky stredne veľkej podnikovej siete, potom (vzhľadom na vysoké náklady na zariadenia), mobilita sond môže hrať veľmi pozitívnu úlohu.

Objekt RMON má v sade objektov MIB priradené číslo 16 a samotný objekt RMON je agregovaný v súlade s RFC 1271 a pozostáva z desiatich skupín údajov.

* Štatistiky - aktuálne nahromadené štatistiky o charakteristikách paketov, počte kolízií atď.

* História - štatistické údaje ukladané v určitých intervaloch pre následnú analýzu trendov ich zmien.

* Alarmy - štatistické prahy, pri prekročení ktorých agent RMON odošle správu manažérovi. Umožňuje používateľovi definovať množinu prahových úrovní (tieto prahové hodnoty sa môžu týkať rôznych vecí – ľubovoľný parameter zo skupiny štatistík, amplitúda alebo rýchlosť jeho zmeny a mnohé ďalšie), pri prekročení ktorých sa generuje alarm. Používateľ môže tiež určiť, za akých podmienok má byť prekročenie prahovej hodnoty sprevádzané alarmom - zabráni sa tak generovaniu signálu „nanič“, čo je zlé, po prvé, pretože nikto nevenuje pozornosť neustále horiacej červenej svetlo a po druhé, pretože prenos zbytočných alarmov cez sieť vedie k zbytočnému zaťaženiu komunikačných liniek. Alarm sa zvyčajne odovzdá skupine udalostí, kde sa určí, čo s ním ďalej robiť.

* Hostiteľ - údaje o hostiteľoch siete vrátane ich MAC adries.

* HostTopN - tabuľka najvyťaženejších hostiteľov v sieti. Tabuľka N top hostiteľov (HostTopN) obsahuje zoznam top N hostiteľov charakterizovaných maximálnou hodnotou daného štatistického parametra pre daný interval. Môžete si napríklad vyžiadať zoznam 10 hostiteľov, ktorí zaznamenali najviac chýb za posledných 24 hodín. Tento zoznam zostaví samotný agent a aplikácia na správu dostane iba adresy týchto hostiteľov a hodnoty zodpovedajúcich štatistických parametrov. Je vidieť, do akej miery tento prístup šetrí sieťové zdroje.

* TrafficMatrix – štatistiky o intenzite prevádzky medzi každým párom sieťových hostiteľov, usporiadané do matice. Riadky tejto matice sú očíslované podľa MAC adries staníc, ktoré sú zdrojmi správ, a stĺpce sú očíslované podľa adries prijímajúcich staníc. Maticové prvky charakterizujú intenzitu dopravy medzi príslušnými stanicami a počet chýb. Po analýze takejto matice môže používateľ ľahko zistiť, ktoré páry staníc generujú najintenzívnejšiu prevádzku. Túto maticu opäť tvorí samotný agent, takže nie je potrebné prenášať veľké množstvo dát do centrálneho počítača zodpovedného za správu siete.

* Filter - podmienky filtrovania paketov. Funkcie, podľa ktorých sú pakety filtrované, môžu byť veľmi rôznorodé – môžete napríklad požadovať odfiltrovať ako chybné všetky pakety, ktorých dĺžka je menšia ako niektoré nastavená hodnota. Dá sa povedať, že inštalácia filtra zodpovedá, ako to bolo, organizácii kanála na prenos paketu. Kam tento kanál vedie, určuje používateľ. Napríklad všetky chybné pakety môžu byť zachytené a odoslané do príslušnej vyrovnávacej pamäte. Okrem toho vzhľad balenia zodpovedajúceho nainštalovaný filter, možno považovať za udalosť (udalosť), na ktorú musí systém vopred určeným spôsobom reagovať.

* PacketCapture - podmienky pre zachytávanie paketov. Skupina zachytávania paketov obsahuje vyrovnávacie pamäte na zachytávanie, kde sa odosielajú pakety, ktorých charakteristiky spĺňajú podmienky formulované v skupine filtrov. V tomto prípade nie je možné zachytiť celý paket, ale povedzme len prvých niekoľko desiatok bajtov paketu. Obsah odpočúvacích vyrovnávacích pamätí je možné následne analyzovať pomocou rôznych softvérových nástrojov, čím sa odhalí množstvo veľmi užitočných charakteristík siete. Preskupením filtrov pre určité znaky je možné charakterizovať rôzne parametre prevádzky siete.

* Event - podmienky pre registráciu a generovanie udalostí. V skupine udalostí (udalosti) sa určuje, kedy sa má do riadiacej aplikácie odoslať alarm, kedy - zachytiť pakety a vo všeobecnosti - ako reagovať na určité udalosti vyskytujúce sa v sieti, napríklad na prekročenie prahu hodnoty ​​​​zadané v skupine alarmov: či nastaviť podľa znalosti riadiacej aplikácie, alebo stačí túto udalosť zaprotokolovať a pokračovať v práci. Udalosti môžu, ale nemusia súvisieť s prenosom alarmov – udalosťou je napríklad aj odoslanie paketu do vyrovnávacej pamäte.

Tieto skupiny sú očíslované v tomto poradí, takže napríklad skupina Hosts má číselný názov 1.3.6.1.2.1.16.4.

Desiatu skupinu tvoria špeciálne objekty protokolu TokenRing.

Celkovo štandard RMON MIB definuje asi 200 objektov v 10 skupinách, fixovaných v dvoch dokumentoch – RFC 1271 pre siete Ethernet a RFC 1513 pre siete TokenRing.

Charakteristickým znakom štandardu RMON MIB je jeho nezávislosť od protokolu sieťovej vrstvy (na rozdiel od štandardov MIB-I a MIB-II, ktoré sú orientované na protokoly TCP/IP). Preto je vhodné ho používať v heterogénnych prostrediach s použitím rôznych protokolov sieťovej vrstvy.

1 .2 Populárne systémy správy siete

Systém riadenia siete - hardvérové ​​a/alebo softvérové ​​nástroje na monitorovanie a správu sieťových uzlov. Softvér systému správy siete pozostáva z agentov, ktorí sú lokalizovaní na sieťových zariadeniach a prenášajú informácie na platformu správy siete. Spôsob výmeny informácií medzi riadiacimi aplikáciami a agentmi na zariadeniach je definovaný protokolmi.

Systémy riadenia siete musia mať niekoľko vlastností:

* skutočná distribúcia v súlade s konceptom klient / server,

* škálovateľnosť,

* otvorenosť vyrovnať sa s heterogénnym - od stolné počítače k sálovým počítačom - zariadenia.

Prvé dve vlastnosti spolu úzko súvisia. Dobrá škálovateľnosť je dosiahnutá vďaka distribúcii riadiaceho systému. Distribuované znamená, že systém môže obsahovať viacero serverov a klientov. Servery (správcovia) zhromažďujú údaje o aktuálnom stave siete od agentov (SNMP, CMIP alebo RMON) zabudovaných v sieťovom zariadení a akumulujú ich vo svojej databáze. Klienti sú grafické konzoly, ktoré používajú správcovia siete. Klientsky softvér riadiaceho systému prijíma požiadavky na vykonanie akejkoľvek akcie od administrátora (napríklad zostavenie podrobnej mapy časti siete) a vyžaduje potrebné informácie od servera. Ak má server správne informácie, potom ho ihneď prevedie klientovi, ak nie, tak sa ho pokúsi vyzdvihnúť u agentov.

Skoršie verzie riadiacich systémov spájali všetky funkcie v jednom počítači, ktorý používal administrátor. Pre malé siete alebo siete s malým množstvom spravovaných zariadení sa táto štruktúra ukazuje ako celkom uspokojivá, ale pri veľkom počte spravovaných zariadení sa jeden počítač, do ktorého prúdia informácie zo všetkých sieťových zariadení, stáva prekážkou. A sieť sa nedokáže vyrovnať s veľkým tokom dát a samotný počítač nemá čas na ich spracovanie. Okrem toho veľkú sieť zvyčajne spravuje viac ako jeden správca, preto by okrem niekoľkých serverov vo veľkej sieti malo existovať niekoľko konzol, za ktorými pracujú správcovia siete a každá konzola by mala poskytovať špecifické informácie, ktoré zodpovedajú aktuálnym potrebám. konkrétneho správcu.

Podobné dokumenty

Rozvoj štruktúry lokálnej počítačovej siete GBOU SPO „VPT“. Zdôvodnenie topológie, výber hardvéru na prepínanie a segmentáciu. Inštalácia a konfigurácia sieťových protokolov a služieb. Monitorovací systém pre sieťové uzly a sieťovú prevádzku.

práca, pridané 25.10.2013


Typy sieťových káblov LAN. Funkcie nastavenia bezdrôtového pripojenia Wi-Fi. Výpočet náročnosti práce na vytvorenie LAN, náklady na jej vývoj a inštaláciu. Predpokladaný zisk z predaja LAN, kapitálové náklady kupujúceho.

ročníková práca, pridaná 27.12.2010


Analýza administračného softvéru lokálnej siete. Štruktúra sieťových operačných systémov. Plánovanie a sieťová architektúra lokálnej siete. Využitie sieťových prostriedkov na príklade podniku poskytujúceho služby poskytovateľa internetu.

kontrolné práce, doplnené 15.12.2010


Analýza a praktická implementácia využitia správy a monitoringu siete v podniku. Proces vytvárania mapy siete v programe LANState. Sieťové programy pre správcov systému, programy na monitorovanie siete. Popis lokálnej počítačovej siete.

ročníková práca, pridaná 15.02.2017


Klasifikácia lokálnej siete. Typy topológií lokálnej počítačovej siete. Model interakcie medzi systémami OSI. Sieťové zariadenia a prostriedky komunikácie. Typy sieťových káblov. Konfigurácia serverových počítačov, zariadení pracovných staníc.

ročníková práca, pridaná 01.05.2013


Topológia a princípy správy káblovej siete, voľba spôsobu pripojenia sieťových zariadení. Navrhovanie lokálnej siete. Predpokladané náklady na realizáciu systému štruktúrovanej kabeláže a systému neprerušiteľného napájania.

práca, pridané 28.10.2013


Funkčný diagram lokálnej siete. Plánovanie štruktúry a topológie siete. IP adresovanie a TCP/IP protokol. Nastavenie sieťovej tlačiarne a antivírusového systému NOD32. Technológia kabeláže. Technológia na vytvorenie prepojovacieho kábla.

semestrálna práca, pridaná 8.8.2015


Metódy klasifikácie sietí. Vývoj a popis štruktúry lokálnej siete umiestnenej v päťposchodovej budove. Technické detaily, hierarchická hviezdicová topológia. klientsky hardvér. Inštalácia a konfigurácia servera.

ročníková práca, pridaná 27.07.2011


Výber pasívnych sieťových zariadení. Zdôvodnenie potreby modernizácie lokálnej počítačovej siete podniku. Voľba operačný systém pre úlohy a server. Porovnávacie charakteristiky prepínačov D-Link. Lokálne sieťové diagramy.

ročníková práca, pridaná 10.10.2015


Pojem a účel lokálnej siete, koncepcia jej výstavby, voľba topológie. Vývoj konfigurácie a výpočtu sieťových charakteristík LAN LLC "Don Terminal": technické a softvérové ​​komponenty, náklady; Informačná bezpečnosť.

27.06.2011 Nate McAlmond

Vybral som troch kandidátov: WhatsUp Gold Premium od Ipswitch, OpManager Professional od ManageEngine a ipMonitor od SolarWinds. Každý z týchto sieťových skenerov stojí menej ako 3 000 USD (na 100 zariadení) a každý z nich má skúšobná doba prevádzky, počas ktorej si môžete vybraný produkt bezplatne otestovať

Pracujem pre stredne veľkú spoločnosť a už asi sedem rokov používame rovnaký systém monitorovania siete. Našim administrátorom poskytuje základné informácie o dostupnosti serverov a služieb a odosiela textové správy SMS na naše mobilné telefóny v prípade problémov. Dospel som k záveru, že potrebujete upgradovať systém, alebo aspoň pridať efektívny nástroj, ktorý dokáže poskytnúť lepší výkon a poskytne podrobné informácie o stave terminálových serverov, Exchange systémov a SQL hostovaných vo vašej sieti. . Porovnajme našich kandidátov.

Proces objavovania

V rámci prípravy na testovanie bolo prvým krokom povolenie služby SNMP na všetkých zariadeniach vrátane serverov Windows. Zmenou nastavení služby SNMP som nastavil prístup len na čítanie na všetkých zariadeniach, na ktoré sa má vzťahovať monitorovací proces. V systémoch Windows Server 2003/2000 sa služba SNMP inštaluje pomocou sprievodcu súčasťami systému Windows, ktorý sa nachádza na paneli Pridať alebo odstrániť programy a v systém Windows Komponenty SNMP servera 2008 sa pridávajú pomocou sprievodcu správcom servera. Po dokončení sprievodcu musíte spustiť modul Služby nachádzajúci sa v priečinku Ovládací panel a nakonfigurovať službu SNMP - nie je to ťažké. Spravované sieťové zariadenia, ako sú brány firewall, prepínače, smerovače a tlačiarne, majú tiež nástroje na správu služieb SNMP a proces konfigurácie je zvyčajne pomerne jednoduchá operácia. Ďalšie informácie o službe SNMP nájdete v dokumente „Simple Network Management Protocol“ (technet.microsoft.com/en-us/library/bb726987.aspx).

Ďalej som nainštaloval všetky tri monitorovacie systémy na jeden z mojich dvoch pracovných systémov s Windows XP SP3. Po inštalácii sa každý systém skladal z dvoch častí: databázy a webového servera. Každý z vybraných systémov môže cez webové rozhranie spravovať viacero administrátorov a máte možnosť nastaviť účty s rôznymi úrovňami prístupu. Spoločné pre tieto tri systémy je, že každý používateľ má možnosť pridávať, odstraňovať a presúvať panely vo svojom pracovnom priestore. Panely zobrazujú rovnaký typ údajov, ako je zaťaženie procesora alebo využitie pamäte pre rôzne zariadenia v sieti.

Pred spustením skenovania siete (nazývaného proces zisťovania) som nastavil nastavenia účtu, ktoré by mal každý systém použiť na získanie prístupu k zariadeniam objaveným v sieti. Ako je uvedené v porovnávacej tabuľke, systém Ipswitch WhatsUp Gold Premium vám umožňuje nastaviť účet pre služby SNMP, WMI, Telnet, SSH, ADO a VMware. ManageEngine OpManager Professional podporuje protokoly SNMP, WMI, Telnet, SSH a URL, zatiaľ čo SolarWinds ipMonitor podporuje protokoly SNMP, WMI a URL.

Po konfigurácii služby SNMP na sieťových zariadeniach a účtoch (Windows a SNMP) pre každý zo systémov monitorovania siete som začal proces zisťovania pre rad IP adries v mojej lokálnej sieti. Všetky systémy rozpoznali približne 70 zariadení. Pomocou predvolených nastavení skenovania testované systémy fungovali dobre pri identifikácii typov zariadení, ako aj pri poskytovaní podrobných informácií o stave zariadenia. Všetky tri systémy obsahujú senzory pre kľúčové zariadenia a výkon servera, ako je zaťaženie procesora, využitie pamäte, využitie/plnosť disku, strata/oneskorenie paketov, stav služieb Exchange, Lotus, Active Directory a všetky služby Windows. Každý zo systémov mal možnosť pridať senzory pre jednotlivé zariadenia aj veľké skupiny zariadení.

Balíky OpManager a WhatsUp Gold poskytujú rozhranie na identifikáciu a zhromažďovanie servisných udalostí VMware zo serverov a hostí. Okrem toho majú oba produkty funkciu výziev správcu portov prepínačov, ktorá vám ukáže, ktoré zariadenia sú pripojené k rôznym portom na spravovaných prepínačoch. Tieto informácie vám môžu pomôcť určiť, ktorý port prepínača sa pripája ku konkrétnej podnikovej aplikácii, bez potreby manuálneho sledovania káblov v serverových miestnostiach. Môžete ďalej konfigurovať výstrahy pre konkrétne porty prepínača. Pri práci s balíkom OpManager na získanie výsledkov polling portov stačí vybrať prepínač a spustiť nástroj Switch Port Mapper – systém vráti výsledky v priebehu niekoľkých sekúnd. Podobný nástroj, ktorý je súčasťou WhatsUp Gold, sa nazýva MAC adresa a musí byť spustený so začiarknutou možnosťou Získať pripojenie. WhatsUp Gold trvá dlhšie, kým sa získa výsledok, pretože sa pokúša skenovať zariadenia a zhromažďovať informácie o pripojení v celej sieti.

Ipswitch WhatsUp Gold Premium

Ipswitch WhatsUp Gold Premium
ZA: poskytuje najpresnejšie výsledky spomedzi troch konkurentov, umožňuje vytvárať vlastné senzory, poskytuje komplexné monitorovacie nástroje pre systémy VMware, integruje sa s AD.
PROTI: menej vstavaných senzorov a vyššie náklady v porovnaní s konkurenciou (ak si zakúpite licenciu pre menej ako 500 zariadení).
STUPEŇ: 4,5 z 5.
CENA: 7495 USD za 500 zariadení, 2695 USD za 100 zariadení, 2195 USD za 25 zariadení.
ODPORÚČANIA Odpoveď: WhatsUp Gold IT odporúčam oddeleniam, ktoré obsluhujú veľké prostredia VMware alebo si chcú vybudovať vlastné senzory.
KONTAKTNÉ INFORMÁCIE: ipswitch www.ipswitch.com

Pri práci so systémami IpMonitor a OpManager som sa občas stretol s nezrozumiteľnými údajmi, ktoré ma zmiatli. V IpMonitor mohli panely zobrazovať záporné hodnoty, keď úroveň využitia procesora výrazne klesla. V inom prípade, keď sa zaťaženie procesora blížilo k nule, systém IpMonitor mi poslal upozornenie, že procesor je vyťažený na 11,490 %! Systém OpManager pri sledovaní a odosielaní správnych informácií o využití disku doménovými radičmi v niektorých prípadoch nezaradil žiadny z radičov do zoznamu 10 serverov s maximálnym využitím miesta na disku. Susedný panel zároveň oznámil, že jeden z mojich doménových radičov by ani nemal byť v prvej desiatke, ale v prvej trojke. Pri používaní WhatsUp Gold som sa s takýmito situáciami nestretol. WhatsUp Gold sleduje vyťaženie procesorových jadier vo svojich paneloch a keď som porovnal výsledky z panelov WhatsUp Gold s údajmi z Windows Performance Monitor, zhodovali sa presne pre každé z jadier. Podobne informácie o využití pevného disku boli správne nahlásené všetkým relevantným aplikáciám pracovného priestoru.

WhatsUp Gold má vstavanú knižnicu senzorov, ktorá vám umožňuje vytvárať nové senzory na základe existujúcich. Pre veľké organizácie môže byť táto funkcia užitočná, pretože vám umožňuje vytvoriť jednu sadu senzorov na monitorovanie rôznych typov zariadení – toto je najefektívnejší spôsob konfigurácie senzorov pre skupinu zariadení.

WhatsUp Gold nemá snímače pre konkrétnych výrobcov (okrem snímača pre zdroje Napájací zdroj APC UPS), na rozdiel od balíka OpManager, ktorý používa vlastné senzory pre zariadenia Dell, HP a IBM, ale umožňuje vytvárať senzory ako Active Script. Tento typ vám umožňuje vyvinúť vlastné monitorovacie procesy pomocou programovacích jazykov VBScript a JScript. Senzory Active Script majú online centrum podpory, kde môžu používatelia WhatsUp Gold získať a stiahnuť hotové skripty.

Jediné vylepšenie, ktoré by som chcel pridať k systému WhatsUp Gold, je rozhranie (obrázok 1), hlavne preto, že je príliš lineárne. Napríklad na návrat z okna Active Monitor Library späť do pracovného priestoru je potrebných až 5 kliknutí na tlačidlá Zrušiť a Zavrieť. Systém WhatsUp Gold tiež nemá senzor (pokiaľ ho, samozrejme, nenapíšete ručne), ktorý kontroluje stav stránky, ale môže byť potrebný, najmä v prípadoch, keď je stránka hosťovaná na serveri tretej strany. a neexistujú žiadne iné spôsoby, ako sa k nemu dostať.

Obrázok 1: Rozhranie WhatsUp Gold Premium

Ak chcete zvládnuť situácie, keď boli zariadenia nejaký čas nečinné, môžete nakonfigurovať odosielanie upozornení každé 2, 5 a 20 minút. Týmto spôsobom môžete upozorniť správcu na nedostatok odozvy z najdôležitejších uzlov na určitý čas.

WhatsUp Gold je jediný uvažovaný systém, ktorý má schopnosť integrácie do prostredia LDAP – tento moment môže byť zásadný pri výbere riešenia pre veľké siete.

ManageEngine OpManager

ManageEngine OpManager
ZA: najlepšie používateľské rozhranie spomedzi troch produktov; viac vstavaných senzorov ako ostatné dva systémy; najviac nízka cena pri zakúpení licencie pre 50 a menej zariadení.
PROTI: počas testov sa nezobrazovali správne všetky indikátory zariadenia; môže chvíľu trvať ladenie, kým bude systém plne funkčný.
STUPEŇ: 4,5 z 5.
CENA: 1995 USD za 100 zariadení, 995 USD za 50 zariadení, 595 USD za 25 zariadení.
ODPORÚČANIA: IT oddelenia, ktoré chcú z krabice vyťažiť maximum (s výnimkou integrácie AD), ocenia OpManager Professional. Pri kúpe licencií v rozsahu 26-50 zariadení je jeho cena takmer polovičná v porovnaní s ostatnými dvoma produktmi.
KONTAKTNÉ INFORMÁCIE: ManageEngine www.manageengine.com

Po nainštalovaní systému OpManager som zistil, že je jednoduché nakonfigurovať obrovské množstvo funkcií a pohodlne sa medzi nimi pohybovať. OpManager poskytuje možnosť odosielať (spolu s e-mailmi a SMS) priame správy na účet Twitter – príjemná alternatíva k e-mailu. Toto používanie účtov na Twitteri ma informuje o tom, čo sa deje online, ale keďže môj telefón nezvoní, keď doručujem správy zo systému Twitter, chcem súbežne dostávať textové upozornenia o najdôležitejších udalostiach. Môžem zobraziť prahové hodnoty na ľubovoľnom serveri prostredníctvom správ Twitter, a tak mať protokol o aktuálnych udalostiach v sieti, ale nie je potrebné používať túto schému posielať núdzové výstrahy.

Okrem štandardných senzorov ponúka systém OpManager technológie monitorovania výkonu SNMP vyvinuté dodávateľmi pre zariadenia ako Dell Power-Edge, HP Proliant a IBM Blade Center. OpManager môže byť tiež integrovaný s rozhraním Google Maps API, aby ste doň mohli pridávať svoje zariadenia google mapa. Vyžaduje si to však zakúpenie účtu Google Maps API Premium (pokiaľ neplánujete sprístupniť svoju mapu verejnosti) v súlade s licenčnými podmienkami. bezplatná verzia Systémy Google Maps API.

Na zvládnutie situácií, keď správca dostane upozornenie, ale určitý čas naň nereaguje, môže byť OpManager nakonfigurovaný na odoslanie dodatočného upozornenia inému správcovi. Napríklad zamestnanec, ktorý je zvyčajne zodpovedný za spracovanie kritických udalostí pre určitú skupinu serverov, môže byť zaneprázdnený alebo chorý. V takom prípade má zmysel nastaviť dodatočné upozornenie, ktoré upúta pozornosť iného správcu, ak prvé upozornenie nebolo zobrazené alebo vymazané do stanoveného počtu hodín/minút.

Spomedzi troch hodnotených produktov mal iba systém OpManager časť venovanú monitorovaniu kvality VoIP ústrední na WAN. Používanie nástrojov na monitorovanie VoIP vyžaduje, aby zariadenia v zdrojovej aj cieľovej sieti podporovali technológiu Cisco IP SLA. Okrem toho rozhranie OpManager zobrazené na obrázku 2 obsahuje viac senzorov a palubných dosiek ako ktorýkoľvek z konkurenčných produktov.

Obrázok 2: Profesionálne rozhranie OpManager

IPMonitor SolarWinds

IPMonitor SolarWinds
ZA: neobmedzený počet zariadení za veľmi nízku cenu; jednoduchosť použitia.
PROTI: neexistuje mechanizmus na koordináciu činností správcov.
STUPEŇ: 4 z 5.
CENA: 1995 $ Neobmedzené zariadenia (25 senzorov zadarmo).
ODPORÚČANIA: Ak je váš rozpočet obmedzený a potrebujete monitorovať veľké množstvo zariadení, ak proces monitorovania nevyžaduje zložité riešenia a ak vám vyhovuje bezsystémový prístup ku koordinácii správcu, SolarWinds je pre vás riešením.
KONTAKTNÉ INFORMÁCIE: solarwinds www.solarwinds.com

Po mojom prvom úvode do ipMonitor bolo rozhranie zobrazené na obrázku 3 pre mňa mätúce. Trvalo mi takmer večnosť, kým som našiel miesto, kde je nakonfigurovaná frekvencia kontroly jednotlivých systémových senzorov systémom (štandardne sa anketa vykonávala každých 300 sekúnd). Avšak po niekoľkých týždňoch používania ipMonitor som zistil, že je veľmi ľahko použiteľný a celkom schopný vykonávať kvalitné monitorovanie siete. Pomocou ipMonitor môžete nakonfigurovať „predvolené“ kontroly tak, aby sa do budúcich kontrol vždy zahrnuli akékoľvek nastavenia služby alebo výkonu. Okrem štandardných (a vyššie uvedených) senzorov ponúka ipMonitor log senzor Udalosti systému Windows A, ktoré možno použiť na odosielanie upozornení, keď sa zistia kritické udalosti.

Obrázok 3: Rozhranie SolarWinds ipMonitor

Na druhej strane systém ipMonitor nemá mechanizmy na sledovanie/priraďovanie cieľov výstrahy. Nezáleží na tom, či je vo firme iba jeden správca siete, ale väčšie IT oddelenia budú pravdepodobne považovať za značnú nevýhodu neschopnosť systému potvrdiť príjem upozornení, prideliť príjemcov a upozornenia resetovať. Ak administrátori zabudnú koordinovať svoje aktivity mimo systému, môže nastať situácia, že viacerí administrátori dostanú rovnaké upozornenie a začnú pracovať na rovnakom probléme. Na vyriešenie takýchto konfliktov však stačí vyvinúť konzistentný algoritmus na reakcie na varovania - ak napríklad zdieľate zodpovednosť za sieťové zariadenia medzi administrátormi, nebudú žiadne otázky o tom, kto by sa mal zaoberať konkrétnym problémom.

Čas urobiť rozhodnutie

Sama som sa už rozhodla, ktorý z troch produktov je pre moje prostredie vhodnejší. Pre systém ManageEngine OpManager s licenciou 50 zariadení som sa usadil z niekoľkých dôvodov.

V prvom rade potrebujem mať možnosť sledovať maximálny počet parametrov svojho prostredia, pretože je to najlepší spôsob, ako sa vyhnúť neočakávaným poruchám. V tejto veci je systém OpManager určite pred konkurenciou. Druhým dôvodom je rozpočet. Môžem naďalej používať naše staré nástroje na monitorovanie zapnutia/vypnutia pre pracovné stanice a tlačiarne a vyhnúť sa tak nákladom na ďalšie licencie. Nakoniec sa mi veľmi páčil prístup tímu ManageEngine pri vývoji OpManager s cieľom využiť výhody nových technológií a plne odôvodňujem náklady na získanie ročného balíka údržby a podpory, ktorý vám umožňuje sťahovať aktualizácie podľa vývoja produktu.

Nate McAlmond ( [e-mail chránený]) je riaditeľom IT v agentúre sociálnych služieb s certifikáciou MCSE, Security a Network+, ktorá sa špecializuje na riešenia tenkých klientov a medicínske databázy.

ESAY

Tento dokument je technickým projektom na vývoj a implementáciu systému monitorovania siete pre verejnú sieť prenosu údajov mesta Verkhnepyshma spoločnosti Gerkon LLC. Projekt zahŕňal štúdiu existujúcich sieťových monitorovacích systémov, analýzu súčasnej situácie v podniku a zdôvodnil výber konkrétnych komponentov sieťového monitorovacieho systému.

Dokument obsahuje popis konštrukčných riešení a špecifikácie zariadení.

Výsledkom návrhu sú vyvinuté riešenia pre implementáciu a využitie systému:

§ Úplný popis všetkých fáz návrhu, vývoja a implementácie systému;

§ System Administration Guide, ktorá obsahuje popis používateľského rozhrania systému.

Tento dokument predstavuje kompletné konštrukčné riešenia a možno ho použiť na implementáciu systému.

ZOZNAM LISTOV GRAFICKÝCH DOKUMENTOV

Tabuľka 1 - Zoznam listov grafických dokumentov

1 -systémový monitoring siete220100 4010002ologická štruktúra siete220100 4010003algoritmus jadra monitorovania siete a výstrahy 220100 4010004 štruktúra záťažového analyzátora analyzátor sieťových rozhraní 220100 4010000 žurnál00 2010005 Udalosti005

ZOZNAM SYMBOLOV A POJMOV

Ethernet je štandard prenosu dát vydaný IEEE. Určuje spôsob prenosu alebo príjmu údajov z bežného komunikačného média. Tvorí nižšiu transportnú vrstvu a používajú ho rôzne protokoly vyššej úrovne. Poskytuje rýchlosť prenosu dát 10 Mbps.

Fast Ethernet je technológia prenosu dát rýchlosťou 100 Mb/s pomocou metódy CSMA/CD, rovnako ako 10Base-T.

FDDI - Fiber Distributed Data Interface - optické rozhranie na distribuovaný prenos dát - technológia prenosu dát rýchlosťou 100 Mbps metódou token ring.

IEEE - Institute of Electrical and Electronic Engineers (Institute of Electrical and Electronic Engineers) - organizácia, ktorá vyvíja a vydáva normy.

LAN - Local Area Network - lokálna sieť, LAN. adresa - Media Access Control - identifikačné číslo sieťového zariadenia, zvyčajne určené výrobcom.

RFC - Request for Comments - súbor dokumentov vydaných organizáciou IEEE, vrátane popisu noriem, špecifikácií atď.

TCP/IP - Transmission Control Protocol/ Internet Protocol - protokol riadenia prenosu/Internetový protokol.

LAN - Local Area Network.

OS - Operačný systém.

ON - Softvér.

SCS - Systém štruktúrovanej kabeláže.

DBMS - Systém správy databáz.

Trend – Dlhodobá štatistika, ktorá umožňuje zostaviť trend tzv.

POČÍTAČ - Elektronický počítač.

ÚVOD

Informačná infraštruktúra moderného podniku je komplexný konglomerát sietí a systémov rôzneho rozsahu a rozmanitosti. Ak chcete, aby fungovali hladko a efektívne, potrebujete podnikovú platformu na správu s integrovanými nástrojmi. Až donedávna však samotná štruktúra odvetvia správy sietí bránila vytvoreniu takýchto systémov – „hráči“ tohto trhu sa snažili viesť vydávaním produktov obmedzeného rozsahu, využívaním nástrojov a technológií, ktoré nie sú kompatibilné so systémami iných výrobcov. predajcovia.

Dnes sa situácia mení k lepšiemu – existujú produkty, ktoré tvrdia, že univerzálne spravujú celú škálu podnikových informačných zdrojov, od desktopových systémov po sálové počítače a od lokálnych sietí po sieťové zdroje. Zároveň prichádza poznanie, že riadiace aplikácie musia byť otvorené riešeniam od všetkých dodávateľov.

Relevantnosť tejto práce je daná tým, že v súvislosti s rozšírením osobných počítačov a vytváraním automatizovaných pracovných staníc (AWP) na ich základe vzrástol význam lokálnych sietí (LAN), ktorých diagnostika je tzv. objekt našej štúdie. Predmetom výskumu sú hlavné metódy organizácie a diagnostiky moderných počítačových sietí.

"Diagnostika lokálnej siete" - proces (kontinuálnej) analýzy stavu informačnej siete. V prípade poruchy sieťových zariadení sa skutočnosť poruchy zaznamená, určí sa jej poloha a typ. Odošle sa chybové hlásenie, zariadenie sa vypne a nahradí sa zálohou.

Správca siete, ktorý je najčastejšie zodpovedný za diagnostiku, by mal začať študovať vlastnosti svojej siete už v štádiu jej formovania, t.j. poznať sieťovú schému a podrobný popis konfigurácie softvéru s uvedením všetkých parametrov a rozhraní. Na registráciu a ukladanie týchto informácií sú vhodné špeciálne sieťové dokumentačné systémy. Pomocou nich bude správca systému vopred poznať všetky možné „skryté chyby“ a „úzke miesta“ svojho systému, takže v prípade núdze bude vedieť, aký je problém s hardvérom alebo softvérom, program je poškodený, resp. chyba viedla k zásahu operátora.

Správca siete by mal mať na pamäti, že z pohľadu používateľov je rozhodujúca kvalita aplikačného softvéru v sieti. Všetky ostatné kritériá, ako je počet chýb pri prenose dát, miera využitia sieťových zdrojov, výkon zariadenia atď., sú druhoradé. „Dobrá sieť“ je taká, ktorej používatelia si nevšimnú, ako funguje.

Spoločnosť

Predgraduálna prax prebiehala vo firme „Gerkon“ LLC na oddelení podpory ako správca systému. Spoločnosť ponúka služby prístupu na internet v mestách Verkhnyaya Pyshma a Sredneuralsk pomocou technológie Ethernet a dial-up kanálov od roku 1993 a je jedným z prvých poskytovateľov internetových služieb v týchto mestách. Pravidlá poskytovania služieb upravuje verejná ponuka a predpisy.

Vedecké a výrobné úlohy divízie

Oddelenie podpory rieši v rámci podniku nasledujúce spektrum úloh:

§ technická a technologická organizácia poskytovania prístupu k internetu prostredníctvom dial-up a vyhradených kanálov;

§ technická a technologická organizácia bezdrôtového prístupu k internetu;

§ prideľovanie diskového priestoru na ukladanie a prevádzku stránok (hosting);

§ podpora poštových schránok alebo virtuálneho poštového servera;

§ umiestnenie zariadenia klienta na mieste poskytovateľa (kolokácia);

§ prenájom dedikovaných a virtuálnych serverov;

§ zálohovanie dát;

§ nasadzovanie a podpora firemných sietí súkromných podnikov.

1. SYSTÉMY MONITOROVANIA SIETE

Napriek množstvu techník a nástrojov na zisťovanie a odstraňovanie problémov v počítačových sieťach je „zem pod nohami“ správcov sietí stále dosť vratká. Počítačové siete čoraz viac obsahujú optické a bezdrôtové komponenty, ktoré robia tradičné technológie a nástroje navrhnuté pre konvenčné medené káble bezpredmetnými. Navyše, pri rýchlostiach nad 100 Mbps tradičné diagnostické prístupy často zlyhávajú, aj keď je prenosovým médiom bežný medený kábel. Avšak asi najvýznamnejšou zmenou v technológii počítačových sietí, ktorej museli správcovia čeliť, bol nevyhnutný prechod od zdieľaných ethernetových sietí na prepínané siete, v ktorých jednotlivé servery alebo pracovné stanice často fungujú ako prepínané segmenty.

Je pravda, že s technologickými transformáciami sa niektoré staré problémy vyriešili sami. Koaxiálny kábel, ktorý bolo vždy ťažšie odhaliť elektrické poruchy ako krútená dvojlinka, sa stáva v podnikových prostrediach vzácnosťou. Siete Token Ring, ktorých hlavným problémom bola odlišnosť od Ethernetu (a už vôbec nie technická slabosť), sú postupne nahrádzané prepínanými sieťami Ethernet. Protokoly, ktoré generujú početné chybové hlásenia protokolov sieťovej vrstvy, ako napríklad SNA, DECnet a AppleTalk, sa nahrádzajú protokolom IP. Samotný zásobník IP protokolov sa stal stabilnejším a ľahšie sa udržiava, o čom svedčia milióny klientov a miliardy webových stránok na internete. Dokonca aj zarytí odporcovia Microsoftu musia uznať, že pripojenie nového klienta Windows k internetu je oveľa jednoduchšie a spoľahlivejšie ako inštalácia zásobníkov TCP/IP tretích strán a samostatného softvéru na telefonické pripojenie.

Akokoľvek je dnes zložité riešiť problémy a spravovať sieťový výkon pomocou viacerých technológií, situácia by mohla byť ešte hrozivejšia, ak by sa technológia ATM rozšírila na úrovni PC. Pozitívnu úlohu zohralo aj to, že koncom 90-tych rokov, ešte pred získaním prijatia, boli odmietnuté aj niektoré ďalšie technológie vysokorýchlostnej výmeny dát, vrátane Token Ring so šírkou pásma 100 Mbps, 100VG-AnyLAN a pokročilých sietí ARCnet. Napokon, veľmi zložitý zásobník protokolov OSI (ktorý je však legalizovaný radom európskych vlád) bol v USA odmietnutý.

Uvažujme o niektorých naliehavých problémoch, ktoré vznikajú pre správcov sietí podnikov.

Hierarchická topológia počítačových sietí s gigabitovými ethernetovými chrbticami a dedikovanými prepínacími portami 10 alebo dokonca 100 Mbps pre jednotlivé klientske systémy umožnila zvýšiť maximálnu šírku pásma potenciálne dostupnú pre používateľov najmenej 10-20 krát. Samozrejme, vo väčšine počítačových sietí existujú úzke miesta na úrovni serverov alebo prístupových smerovačov, pretože šírka pásma na jednotlivého používateľa je výrazne nižšia ako 10 Mbps. Preto nahradenie 10 Mb/s portu rozbočovača vyhradeným 100 Mb/s portom prepínača pre koncový uzol nevedie vždy k výraznému zvýšeniu rýchlosti. Ak si však uvedomíte, že náklady na prepínače sa nedávno znížili a väčšina podnikov nainštalovala kábel kategórie 5, ktorý podporuje technológiu Ethernet 100 Mbps, a nainštalovala sieťové karty, ktoré môžu pracovať rýchlosťou 100 Mbps ihneď po reštarte systému, stane sa to je jasné, prečo je také ťažké odolať pokušeniu modernizácie. V tradičnej zdieľanej sieti LAN môže analyzátor protokolu alebo monitor preskúmať všetku prevádzku v danom segmente siete.

Ryža. 1.1 - Tradičná LAN so zdieľanými médiami a analyzátorom protokolov

Zatiaľ čo výkonnostná výhoda prepínanej siete je niekedy nepatrná, šírenie prepínaných architektúr bolo pre tradičné diagnostické nástroje katastrofálne. V silne segmentovanej sieti môžu sledovači protokolov vidieť iba unicastovú prevádzku na jedinom porte prepínača, na rozdiel od staršej topológie siete, kde by mohli skúmať akýkoľvek paket v kolíziovej doméne. Za takýchto podmienok tradičné monitorovacie nástroje nemôžu zbierať štatistiky o všetkých „konverzáciách“, pretože každý „hovoriaci“ pár koncových bodov v skutočnosti používa svoju vlastnú sieť.

Ryža. 1.2 - Komutovaná sieť

V prepínanej sieti môže analyzátor protokolu v jednom bode „vidieť“ iba jeden segment, ak prepínač nie je schopný zrkadliť viacero portov súčasne.

Na udržanie kontroly nad silne segmentovanými sieťami ponúkajú predajcovia prepínačov množstvo nástrojov na obnovenie plnej viditeľnosti siete, no na ceste je veľa výziev. Prepínače, ktoré sa teraz dodávajú, zvyčajne podporujú „zrkadlenie“ portov, keď je prevádzka jedného z nich duplikovaná na predtým nepoužívanom porte, ku ktorému je pripojený monitor alebo analyzátor.

„Zrkadlenie“ má však množstvo nevýhod. Po prvé, vždy je viditeľný iba jeden port, takže je veľmi ťažké identifikovať problémy, ktoré ovplyvňujú viacero portov naraz. Po druhé, zrkadlenie môže zhoršiť výkon prepínača. Po tretie, zlyhania fyzickej vrstvy sa na zrkadlovom porte zvyčajne nereprodukujú a niekedy sa dokonca stratia označenia VLAN. Nakoniec, v mnohých prípadoch nie je možné plne zrkadliť plne duplexné ethernetové linky.

Čiastočným riešením pri analýze agregovaných prevádzkových parametrov je využitie monitorovacích schopností mini-RMON agentov, najmä preto, že sú zabudované do každého portu väčšiny ethernetových prepínačov. Hoci agenti mini-RMON nepodporujú skupinu objektov RMON II Capture, ktoré poskytujú plnohodnotnú analýzu protokolov, stále dokážu vyhodnotiť využitie prostriedkov, chybovosť a objem multicast.

Niektoré z nedostatkov technológie zrkadlenia portov možno prekonať inštaláciou „pasívnych odbočovačov“, ako sú tie od spoločnosti Shomiti. Tieto zariadenia sú predinštalovanými Y-konektormi a umožňujú analyzátorom protokolov alebo iným zariadeniam monitorovať skutočný signál, nie ten regenerovaný.

Ďalším aktuálnym problémom je problém s vlastnosťami optiky. Správcovia počítačových sietí zvyčajne používajú na riešenie problémov s optickými káblami iba špecializované diagnostické zariadenia optickej siete. Bežný štandardný softvér na správu zariadení SNMP alebo CLI dokáže odhaliť problémy na prepínačoch a smerovačoch s optickými rozhraniami. A len niekoľko správcov siete čelí potrebe diagnostikovať zariadenia SONET.

Pri optických kábloch je podstatne menej dôvodov na výskyt prípadných porúch v nich ako v prípade medeného kábla. Optické signály nespôsobujú presluchy, ku ktorým dochádza, keď signál na jednom vodiči indukuje signál na inom, čo je faktor, ktorý sťažuje diagnostické zariadenia medených káblov. Optické káble sú odolné voči elektromagnetickému šumu a indukovaným signálom, takže nemusia byť umiestnené mimo elektromotorov výťahov a žiariviek, t.j. všetky tieto premenné môžu byť vylúčené z diagnostického scenára.

Sila signálu alebo optický výkon v danom bode je skutočne jedinou premennou, ktorú je potrebné merať pri riešení problémov s optickými sieťami. Ak je možné určiť stratu signálu cez optický kanál, potom bude možné identifikovať takmer akýkoľvek problém. Lacné prídavné moduly pre testery medených káblov umožňujú optické merania.

Podniky, ktoré nasadili veľkú optickú infraštruktúru a sami si ju udržiavajú, si možno budú musieť zakúpiť reflektometer OTDR (Optical Time Domain Reflectometer), ktorý vykonáva rovnaké funkcie pre optické vlákno ako reflektometer časovej domény (TDR) pre medený kábel. Zariadenie funguje ako radar: vysiela impulzné signály po kábli a analyzuje ich odrazy, na základe čoho deteguje poruchy vodiča alebo inú anomáliu a následne povie odborníkovi, kde má v kábli hľadať zdroj problému. .

Zatiaľ čo rôzni predajcovia káblových konektorov a konektorov zjednodušili ukončenie a rozvetvenie optických vlákien, stále si to vyžaduje určitú úroveň špecializovaných zručností a so správnou politikou bude musieť podnik s rozvinutou optickou infraštruktúrou školiť svojich zamestnancov. Bez ohľadu na to, ako dobre je káblová sieť položená, vždy existuje možnosť fyzického poškodenia kábla v dôsledku neočakávanej udalosti.

Môže sa vyskytnúť aj odstraňovanie problémov s bezdrôtovými sieťami LAN 802.11b. Samotná diagnostika je rovnako jednoduchá ako v prípade ethernetových sietí založených na rozbočovačoch, keďže bezdrôtové prenosové médium zdieľajú všetci majitelia klientskych rádiových zariadení. Spoločnosť Sniffer TechHlogies bola prvá, ktorá ponúkla riešenie analýzy protokolov pre takéto siete až do 11 Mbps, a následne väčšina popredných predajcov analyzátorov predstavila podobné systémy.

Na rozdiel od káblového ethernetového rozbočovača nie je kvalita bezdrôtových klientskych pripojení ani zďaleka konzistentná. Mikrovlnné rádiové signály používané vo všetkých miestnych prenosoch sú slabé a niekedy nepredvídateľné. Aj malé zmeny v polohe antény môžu vážne ovplyvniť kvalitu pripojenia. Bezdrôtové prístupové body LAN sa dodávajú s konzolou na správu zariadenia, čo je často efektívnejšia diagnostická metóda ako návšteva bezdrôtových klientov a monitorovanie priepustnosti a chybových stavov pomocou ručného analyzátora.

Hoci problémy so synchronizáciou údajov a inštaláciou zariadení, s ktorými sa stretávajú používatelia osobných digitálnych asistentov (PDA), prirodzenejšie zodpovedajú úlohám tímu technickej podpory než povinnostiam správcu siete, nie je ťažké predvídať, že v blízkej budúcnosti bude takéto zariadenia sa vyvinú zo samostatných pomocných nástrojov, ktoré dopĺňajú PC, v plnohodnotných sieťových klientoch.

Všeobecným pravidlom je, že prevádzkovatelia podnikových bezdrôtových sietí budú (alebo by mali) odrádzať od nasadzovania príliš otvorených systémov, v ktorých má každý používateľ v dosahu siete s kompatibilnou kartou rozhrania prístup ku každému informačnému rámcu systému. Bezdrôtový bezpečnostný protokol WEP (Wired Equivalent Privacy) poskytuje autentifikáciu používateľa, zabezpečenie integrity a šifrovanie údajov, ale ako to zvyčajne býva, pokročilé zabezpečenie sťažuje analýzu príčin sieťových problémov. V zabezpečených sieťach s podporou WEP musia diagnostici poznať kľúče alebo heslá, ktoré chránia informačné zdroje a riadia prístup do systému. Pri prístupe v režime príjmu všetkých paketov bude analyzátor protokolu schopný vidieť všetky hlavičky rámcov, ale informácie v nich obsiahnuté bez prítomnosti kľúčov budú bezvýznamné.

Pri diagnostike tunelovaných spojení, ktoré mnohí predajcovia označujú ako virtuálne privátne siete so vzdialeným prístupom, vznikajú problémy podobné tým, ktoré sa vyskytujú pri analýze šifrovaných bezdrôtových sietí. Ak prevádzka neprechádza cez tunelované spojenie, príčina zlyhania sa nedá ľahko určiť. Môže ísť o chybu autentifikácie, zlyhanie na jednom z koncových bodov alebo preťaženie verejnej internetovej zóny. Pokúšať sa použiť analyzátor protokolov na detekciu chýb vysokej úrovne v tunelovanej prevádzke by bolo zbytočné, pretože obsah údajov, ako aj hlavičky aplikácie, prenosu a sieťovej vrstvy sú šifrované. Opatrenia prijaté na zlepšenie bezpečnosti podnikových sietí majú vo všeobecnosti tendenciu sťažiť identifikáciu porúch a problémov s výkonom. Firewally, proxy servery a systémy detekcie narušenia môžu ešte viac skomplikovať riešenie problémov.

Problém diagnostiky počítačových sietí je teda aktuálny a v konečnom dôsledku je diagnostika porúch úlohou manažmentu. Pre väčšinu kriticky dôležitých podnikových systémov sú zdĺhavé snahy o obnovu neprijateľné, takže jediným riešením je použitie redundantných zariadení a procesov, ktoré dokážu prevziať potrebné funkcie ihneď po výskyte zlyhania. V niektorých podnikoch majú siete vždy dodatočný redundantný komponent pre prípad, že hlavný komponent zlyhá, to znamená n x 2 komponentov, kde n je počet primárnych komponentov požadovaných na zabezpečenie prijateľného výkonu. Ak je stredná doba opravy (MTTR) dostatočne vysoká, môže byť potrebná väčšia redundancia. Ide o to, že čas na riešenie problémov nie je ľahké predvídať a značné náklady počas nepredvídateľného obdobia obnovy sú znakom zlého riadenia.

V prípade menej kritických systémov nemusí byť redundancia ekonomicky životaschopná, v takom prípade má zmysel investovať do najefektívnejších nástrojov (a do školenia personálu), aby sa proces diagnostiky a riešenia problémov v závode čo najrýchlejšie urýchlil. Okrem toho možno podporu pre určité systémy zadať externe, buď outsourcingom do podniku, alebo využitím možností externých dátových centier, alebo kontaktovaním poskytovateľov aplikačných služieb (ASP) alebo poskytovateľov služieb správy. Za najvýznamnejší faktor ovplyvňujúci rozhodnutie využiť služby organizácií tretích strán možno popri nákladoch považovať úroveň spôsobilosti vlastného personálu. Správcovia siete musia zvážiť, či konkrétna funkcia tak úzko súvisí so špecifickými úlohami podniku, že nemožno očakávať, že špecialista tretej strany odvedie lepšiu prácu, než akú by odviedli zamestnanci spoločnosti.

Takmer okamžite po nasadení prvých podnikových sietí, ktorých spoľahlivosť zostala v nedohľadne, výrobcovia a vývojári predložili koncept „samoopravných sietí“. Moderné siete sú určite spoľahlivejšie ako v 90. rokoch, ale nie preto, že by sa problémy začali samé opravovať. Riešenie problémov so softvérovými a hardvérovými poruchami v súčasných sieťach si stále vyžaduje ľudský zásah a neočakáva sa, že by sa tento stav v krátkodobom horizonte zásadne zmenil. Diagnostické metódy a nástroje sú celkom v súlade s modernými postupmi a technológiami, ale zatiaľ nedosiahli úroveň, ktorá by výrazne šetrila sieťovým administrátorom čas v boji so sieťovými problémami a výkonnostnými medzerami.

1.1 Diagnostický softvér

Medzi softvérom na diagnostiku počítačových sietí možno vyčleniť špeciálne systémy riadenia siete (Network Management Systems) - centralizované softvérové ​​systémy, ktoré zhromažďujú údaje o stave sieťových uzlov a komunikačných zariadení, ako aj údaje o premávke v sieti. Tieto systémy nielen monitorujú a analyzujú sieť, ale tiež vykonávajú akcie správy siete v automatickom alebo poloautomatickom režime - povoľovanie a zakázanie portov zariadení, zmena parametrov mostov adresných tabuliek mostov, prepínačov a smerovačov atď. Príkladmi riadiacich systémov sú populárne systémy HPOpenView, SunNetManager, IBMNetView.

Nástroje na správu systému vykonávajú funkcie podobné funkciám systémov správy, ale s ohľadom na komunikačné zariadenia. Niektoré funkcie týchto dvoch typov systémov správy sa však môžu prekrývať, napríklad nástroje na správu systému môžu vykonávať základnú analýzu sieťovej prevádzky.

Expertné systémy. Tento typ systému zhromažďuje ľudské znalosti o identifikácii príčin abnormálnej prevádzky siete a možných spôsoboch, ako priviesť sieť späť do zdravého stavu. Expertné systémy sú často implementované ako samostatné podsystémy rôznych nástrojov na monitorovanie a analýzu siete: systémy riadenia siete, analyzátory protokolov, analyzátory siete. Najjednoduchšou verziou expertného systému je kontextový systém pomoci. Zložitejšie expertné systémy sú takzvané znalostné bázy s prvkami umelej inteligencie. Príkladom takéhoto systému je expertný systém zabudovaný do riadiaceho systému Spectrum spoločnosti Cabletron.

1.1.1 Analyzátory protokolov

V priebehu navrhovania novej alebo modernizácie starej siete je často potrebné kvantifikovať niektoré charakteristiky siete, ako je napríklad intenzita dátových tokov cez sieťové komunikačné linky, oneskorenia, ktoré sa vyskytujú v rôznych fázach spracovania paketov, odozva. časov na požiadavky toho či onoho druhu, frekvenciu výskytu určitých udalostí a iné charakteristiky.

Na tieto účely možno použiť rôzne prostriedky a predovšetkým monitorovacie nástroje v systémoch riadenia siete, o ktorých už bola reč vyššie. Niektoré merania v sieti je možné vykonávať aj softvérovými meračmi zabudovanými v operačnom systéme, príkladom je OS Windows Performance Monitor. Dokonca aj dnešné testery káblov sú schopné zachytávať pakety a analyzovať ich obsah.

Najpokročilejším nástrojom na výskum siete je však analyzátor protokolov. Proces analýzy protokolu zahŕňa zachytávanie paketov cirkulujúcich v sieti, ktoré implementujú konkrétny sieťový protokol, a skúmanie obsahu týchto paketov. Na základe výsledkov analýzy je možné vykonávať rozumné a vyvážené zmeny akýchkoľvek sieťových komponentov, optimalizovať ich výkon a odstraňovať problémy. Je zrejmé, že na to, aby bolo možné vyvodiť závery o vplyve zmeny na sieť, je potrebné analyzovať protokoly pred a po vykonaní zmeny.

Analyzátor protokolov je buď nezávislé špecializované zariadenie alebo osobný počítač, zvyčajne prenosný, triedy Htebook, vybavený špeciálnou sieťovou kartou a súvisiacim softvérom. Použitá sieťová karta a softvér musia zodpovedať topológii siete (kruh, zbernica, hviezda). Analyzátor sa pripája k sieti rovnakým spôsobom ako bežný uzol. Rozdiel je v tom, že analyzátor môže prijímať všetky dátové pakety prenášané cez sieť, zatiaľ čo bežná stanica môže prijímať len tie, ktoré sú jej adresované. Softvér analyzátora pozostáva z jadra, ktoré podporuje činnosť sieťového adaptéra a dekóduje prijaté dáta, a dodatočného programového kódu v závislosti od typu topológie skúmanej siete. Okrem toho sa dodáva množstvo dekódovacích rutín špecifických pre protokol, ako napríklad IPX. Súčasťou niektorých analyzátorov môže byť aj expertný systém, ktorý môže užívateľovi poskytnúť odporúčania, aké experimenty by sa mali v danej situácii vykonať, čo môže znamenať určité výsledky meraní, ako eliminovať určité typy výpadkov siete.

Napriek relatívnej rozmanitosti analyzátorov protokolov na trhu existujú niektoré funkcie, ktoré sú do určitej miery vlastné všetkým z nich:

Užívateľské rozhranie. Väčšina analyzátorov má vyvinuté užívateľsky prívetivé rozhranie, zvyčajne založené na Windows alebo Motif. Toto rozhranie umožňuje užívateľovi: zobraziť výsledky analýzy intenzity dopravy; získať okamžité a priemerné štatistické hodnotenie výkonu siete; nastaviť určité udalosti a kritické situácie na sledovanie ich výskytu; dekódovať protokoly rôznych úrovní a prezentovať obsah paketov v zrozumiteľnej forme.

Zachytiť vyrovnávaciu pamäť. Pufry rôznych analyzátorov sa líšia objemom. Vyrovnávacia pamäť môže byť umiestnená na nainštalovanej sieťovej karte alebo jej môže byť pridelené miesto v pamäti RAM jedného z počítačov v sieti. Ak je vyrovnávacia pamäť umiestnená na sieťovej karte, potom je riadená hardvérom a vďaka tomu sa zvyšuje vstupná rýchlosť. To však vedie k zvýšeniu nákladov na analyzátor. V prípade nedostatočného vykonania postupu zachytávania sa niektoré informácie stratia a analýza nebude možná. Veľkosť vyrovnávacej pamäte určuje schopnosť analyzovať viac či menej reprezentatívne vzorky zachytených dát. Ale bez ohľadu na to, aký veľký je zachytávací buffer, skôr či neskôr sa zaplní. V tomto prípade sa buď zachytávanie zastaví, alebo plnenie začne od začiatku vyrovnávacej pamäte.

Filtre. Filtre vám umožňujú kontrolovať proces zachytávania údajov, a tým šetriť miesto vo vyrovnávacej pamäti. V závislosti od hodnoty určitých polí v pakete špecifikovanej ako podmienka filtra sa paket buď ignoruje, alebo sa zapíše do vyrovnávacej pamäte. Použitie filtrov výrazne urýchľuje a zjednodušuje analýzu, pretože vylučuje prezeranie balíkov, ktoré momentálne nie sú potrebné.

Prepínače sú určité podmienky na spustenie a zastavenie procesu zachytávania dát zo siete, ktoré určuje operátor. Takýmito podmienkami môže byť vykonanie manuálnych príkazov na spustenie a zastavenie procesu snímania, čas dňa, trvanie procesu snímania, výskyt určitých hodnôt v dátových rámcoch. Prepínače možno použiť v spojení s filtrami, čo umožňuje podrobnejšiu a jemnejšiu analýzu, ako aj produktívnejšie využitie obmedzeného množstva vyrovnávacej pamäte.

Vyhľadávanie. Niektoré analyzátory protokolov vám umožňujú automatizovať kontrolu informácií vo vyrovnávacej pamäti a nájsť v nej údaje podľa špecifikovaných kritérií. Zatiaľ čo filtre kontrolujú vstupný tok v porovnaní s podmienkami filtra, funkcie vyhľadávania sa aplikujú na údaje, ktoré sú už nazhromaždené vo vyrovnávacej pamäti.

Metodika analýzy môže byť prezentovaná vo forme nasledujúcich šiestich etáp:

Zachytávanie údajov.

Zobrazte zachytené údaje.

Analýza dát.

Hľadajte chyby. (Väčšina syntaktických analyzátorov uľahčuje túto prácu identifikáciou typov chýb a identifikáciou stanice, z ktorej chybný paket prišiel.)

Výkonnostná štúdia. Vypočíta sa využitie šírky pásma siete alebo priemerný čas odozvy na požiadavku.

Podrobná štúdia jednotlivých úsekov siete. Obsah tejto fázy je špecifikovaný pri vykonávaní analýzy.

Proces analýzy protokolu zvyčajne trvá relatívne málo času – 1 – 2 pracovné dni.

Väčšina moderných analyzátorov umožňuje analyzovať niekoľko WAN protokolov naraz, ako sú X.25, PPP, SLIP, SDLC/SNA, frame relay, SMDS, ISDN, mostové/routerové protokoly (3Com, Cisco, Bay Networks a iné). Takéto analyzátory umožňujú merať rôzne parametre protokolov, analyzovať sieťovú prevádzku, konvertovať medzi protokolmi LAN a WAN, oneskorenie na smerovačoch počas týchto konverzií atď. Pokročilejšie zariadenia poskytujú možnosť simulácie a dekódovania WAN protokolov, "záťažové" testovanie, meranie maxima priepustnosť, testovanie kvality poskytovaných služieb. Z dôvodu univerzálnosti implementujú takmer všetky analyzátory WAN protokolu funkcie testovania LAN a všetkých hlavných rozhraní. Niektoré prístroje sú schopné analyzovať telefónne protokoly. A najmodernejšie modely dokážu dekódovať a prezentovať všetkých sedem vrstiev OSI pohodlným spôsobom. Nástup ATM viedol výrobcov k tomu, aby svojim analyzátorom poskytli prostriedky na testovanie týchto sietí. Tieto prístroje dokážu plne otestovať siete ATM E-1/E-3 s podporou monitorovania a simulácie. Súbor servisných funkcií analyzátora je veľmi dôležitý. Niektoré z nich, ako napríklad možnosť diaľkového ovládania zariadenia, sú jednoducho nenahraditeľné.

Moderné analyzátory protokolu WAN/LAN/DTM teda dokážu odhaliť chyby v konfigurácii smerovačov a mostov; nastaviť typ prenosu odosielaného cez globálnu sieť; určiť použitý rozsah rýchlosti, optimalizovať pomer medzi šírkou pásma a počtom kanálov; lokalizovať zdroj nesprávnej návštevnosti; vykonávať testovanie sériového rozhrania a úplné testovanie ATM; vykonávať úplné monitorovanie a dekódovanie hlavných protokolov na akomkoľvek kanáli; analyzovať štatistiky v reálnom čase, vrátane analýzy prevádzky LAN cez siete WAN.

1.1.2 Monitorovacie protokoly

Protokol SNMP (anglicky Simple Network Management Protocol - jednoduchý protokol správy siete) je protokol na správu komunikačných sietí založený na architektúre TCP / IP.

Na základe konceptu TMN v rokoch 1980-1990. rôzne normalizačné orgány vyvinuli množstvo protokolov na správu dátových sietí s rôznym spektrom implementácie funkcií TMN. Jedným typom takéhoto riadiaceho protokolu je SNMP. Protokol SNMP bol vyvinutý na testovanie funkčnosti sieťových smerovačov a mostov. Následne sa rozsah protokolu rozšíril aj na ďalšie sieťové zariadenia, ako sú huby, brány, terminálové servery, servery LAN Manager, počítače so systémom Windows NT atď. Okrem toho protokol umožňuje vykonávať zmeny vo fungovaní týchto zariadení.

Táto technológia je navrhnutá tak, aby poskytovala správu a kontrolu nad zariadeniami a aplikáciami v komunikačnej sieti prostredníctvom výmeny riadiacich informácií medzi agentmi umiestnenými na sieťových zariadeniach a manažérmi umiestnenými na riadiacich staniciach. SNMP definuje sieť ako súbor staníc pre správu siete a sieťových prvkov (hostiteľov, brán a smerovačov, terminálových serverov), ktoré spolu zabezpečujú administratívnu komunikáciu medzi stanicami správy siete a sieťovými agentmi.

Pri používaní SNMP existujú riadené a riadiace systémy. Riadený systém obsahuje komponent nazývaný agent, ktorý posiela správy do riadiaceho systému. SNMP agenti v podstate odovzdávajú manažérske informácie riadiacim systémom ako premenné (ako napríklad „voľná pamäť“, „názov systému“, „počet spustených procesov“).

Agent v protokole SNMP je procesný prvok, ktorý poskytuje manažérom umiestneným na staniciach riadenia siete prístup k hodnotám premenných MIB a umožňuje im tak implementovať funkcie správy a monitorovania zariadení.

Softvérový agent je rezidentný program, ktorý vykonáva riadiace funkcie a tiež zbiera štatistiky na ich prenos do informačnej základne sieťového zariadenia.

Hardvérový agent - vstavaný hardvér (s procesorom a pamäťou), ktorý ukladá softvérových agentov.

Premenné prístupné cez SNMP sú usporiadané v hierarchii. Tieto hierarchie a ďalšie metaúdaje (napríklad typ a popis premennej) sú opísané v riadiacich informačných bázach (MIB).

Dnes existuje niekoľko štandardov pre riadiace informačné databázy. Hlavnými sú štandardy MIB-I a MIB-II, ako aj verzia databázy pre diaľkové ovládanie RMON MIB. Okrem toho existujú štandardy pre špeciálne MIB zariadenia určitého typu (napríklad MIB pre rozbočovače alebo MIB pre modemy), ako aj súkromné ​​MIB konkrétnych výrobcov zariadení.

Pôvodná špecifikácia MIB-I definovala iba operácie na čítanie hodnôt premenných. Operácie na zmenu alebo nastavenie hodnôt objektov sú súčasťou špecifikácií MIB-II.

Verzia MIB-I (RFC 1156) definuje až 114 objektov, ktoré sú rozdelené do 8 skupín:

Systém – všeobecné údaje o zariadení (napríklad ID predajcu, čas poslednej inicializácie systému).

Rozhrania – popisuje parametre sieťových rozhraní zariadenia (napríklad ich počet, typy, výmenné kurzy, maximálna veľkosť paketov).

AddressTranslationTable – popisuje súlad medzi sieťovými a fyzickými adresami (napríklad prostredníctvom protokolu ARP).

InternetProtocol - údaje súvisiace s IP protokolom (adresy IP brán, hostiteľov, štatistiky o IP paketoch).

ICMP - údaje súvisiace s protokolom výmeny riadiacich správ ICMP.

TCP - údaje súvisiace s protokolom TCP (napríklad o TCP spojeniach).

UDP - údaje súvisiace s protokolom UDP (počet prenesených, prijatých a chybných UPD datagramov).

EGP - údaje súvisiace s protokolom výmeny smerovacích informácií ExteriorGatewayProtocol používaným na internete (počet správ prijatých s chybami a bez chýb).

Z tohto zoznamu skupín premenných je zrejmé, že štandard MIB-I bol vyvinutý so silným zameraním na správu smerovačov, ktoré podporujú protokoly zásobníka TCP/IP.

Vo verzii MIB-II (RFC 1213), prijatej v roku 1992, sa výrazne (až na 185) rozšírila sada štandardných objektov a počet skupín sa zvýšil na 10.

Agenti RMON

Najnovším prírastkom funkcionality SNMP je špecifikácia RMON, ktorá poskytuje vzdialenú komunikáciu s MIB.

Štandard RMON vznikol v novembri 1991, keď skupina Internet Engineering Task Force vydala RFC 1271 s názvom „Informačná základňa riadenia vzdialeného monitorovania siete“. Tento dokument obsahoval popis RMON pre siete Ethernet - protokol na monitorovanie počítačových sietí, rozšírenie SNMP, ktorý je podobne ako SNMP založený na zbere a analýze informácií o charaktere informácií prenášaných cez sieť. Rovnako ako v SNMP, informácie sú zhromažďované hardvérovými a softvérovými agentmi, z ktorých sa údaje odosielajú do počítača, kde je nainštalovaná aplikácia na správu siete. Rozdiel medzi RMON a jeho predchodcom je predovšetkým v povahe zhromažďovaných informácií - ak v SNMP tieto informácie charakterizujú iba udalosti vyskytujúce sa na zariadení, kde je nainštalovaný agent, potom RMON vyžaduje, aby prijaté údaje charakterizovali prevádzku medzi sieťou zariadení.

Pred príchodom RMON sa SNMP nedalo používať na diaľku, umožňovalo len lokálnu správu zariadení. RMON MIB má vylepšenú sadu vlastností pre vzdialenú správu, pretože obsahuje súhrnné informácie o zariadení, čo nevyžaduje prenos veľkého množstva informácií cez sieť. Objekty RMON MIB zahŕňajú dodatočné počítadlá chýb paketov, flexibilnejšie grafické trendy a štatistickú analýzu, výkonnejšie filtrovacie nástroje na zachytávanie a analýzu jednotlivých paketov a sofistikovanejšie výstražné podmienky. Agenti RMON MIB sú inteligentnejší ako agenti MIB-I alebo MIB-II a vykonávajú veľkú časť práce pri spracovaní informácií o zariadení, ktorú robili manažéri. Títo agenti môžu byť umiestnení vo vnútri rôznych komunikačných zariadení, ako aj implementovaní ako samostatné softvérové ​​moduly bežiace na univerzálnych PC a notebookoch (ako príklad môže poslúžiť LANalyzerНvell).

Inteligencia agentov RMON im umožňuje vykonávať jednoduché odstraňovanie porúch a varovné akcie - napríklad v rámci technológie RMON môžete zbierať údaje o bežnom fungovaní siete (t. j. vykonávať tzv. baselining) a následne vydávať varovné signály, keď sa prevádzkový režim siete odchýli od základnej línie – môže to naznačovať najmä to, že zariadenie nie je plne funkčné. Zhromaždením informácií od agentov RMON môže aplikácia na správu pomôcť správcovi siete (napríklad vzdialenému tisíce kilometrov) lokalizovať problém a vypracovať najlepší akčný plán na jeho vyriešenie.

Informácie RMON zhromažďujú hardvérové ​​a softvérové ​​sondy pripojené priamo k sieti. Na vykonanie úlohy zberu a primárnej analýzy údajov musí mať sonda dostatok výpočtových zdrojov a RAM. V súčasnosti sú na trhu tri typy sond: vstavané sondy, počítačové sondy a samostatné sondy. Produkt sa považuje za produkt s povoleným RMON, ak implementuje aspoň jednu skupinu RMON. Samozrejme, čím viac dátových skupín RMON je v danom produkte implementovaných, tým je na jednej strane drahší a na druhej strane kompletnejšie informácie o prevádzke siete poskytuje.

Vstavané sondy sú rozširujúce moduly pre sieťové zariadenia. Takéto moduly vyrába mnoho výrobcov, najmä také veľké spoločnosti ako 3Com, Cabletron, Bay Networks a Cisco. (Mimochodom, 3Com a Bay Networks nedávno získali Axon a ARMON, uznávaných lídrov v dizajne a výrobe nástrojov na správu RMON. Takýto záujem o túto technológiu zo strany hlavných výrobcov sieťových zariadení opäť ukazuje, aké nevyhnutné je vzdialené monitorovanie pre používateľov.) Väčšina rozhodnutí vkladanie modulov RMON do rozbočovačov sa zdá prirodzené, pretože práve z pozorovania týchto zariadení si možno urobiť predstavu o fungovaní segmentu. Výhoda takýchto sond je zrejmá: umožňujú získať informácie o všetkých hlavných dátových skupinách RMON za relatívne nízku cenu. Nevýhodou je v prvom rade nie príliš vysoký výkon, čo sa prejavuje najmä v tom, že vstavané sondy často podporujú zďaleka nie všetky dátové skupiny RMON. Nie je to tak dávno, čo spoločnosť 3Com oznámila svoj zámer vydať ovládače s podporou RMON pre sieťové adaptéry Etherlink III a Fast Ethernet. V dôsledku toho bude možné zbierať a analyzovať dáta RMON priamo z pracovných staníc v sieti.

Počítačové sondy sú jednoducho prepojené počítače s nainštalovaným softvérovým agentom RMON. Tieto sondy (ako napríklad Network General's Cornerstone Agent 2.5) sú rýchlejšie ako vstavané sondy a vo všeobecnosti podporujú všetky dátové skupiny RMON. Sú drahšie ako vstavané sondy, ale oveľa lacnejšie ako samostatné sondy. Navyše, počítačové sondy sú pomerne veľké, čo môže niekedy obmedziť ich použitie.

Samostatné sondy majú najvyšší výkon; ako je ľahko pochopiteľné, sú to zároveň najdrahšie produkty zo všetkých opísaných. Samostatnou sondou je zvyčajne procesor (trieda i486 alebo RISC procesor) vybavený dostatočnou pamäťou RAM a sieťovým adaptérom. Lídrami v tomto sektore trhu sú Frontier a Hewlett-Packard. Sondy tohto typu majú malú veľkosť a sú vysoko mobilné – veľmi jednoducho sa pripájajú a odpájajú od siete. Pri riešení problému riadenia globálnej siete to, samozrejme, nie je veľmi dôležitá vlastnosť, ale ak sa nástroje RMON používajú na analýzu prevádzky stredne veľkej podnikovej siete, potom (vzhľadom na vysoké náklady na zariadenia), mobilita sond môže hrať veľmi pozitívnu úlohu.

Objekt RMON má v sade objektov MIB priradené číslo 16 a samotný objekt RMON je agregovaný v súlade s RFC 1271 a pozostáva z desiatich skupín údajov.

Štatistika – aktuálne nahromadené štatistiky o charakteristikách paketov, počte kolízií atď.

História - štatistické údaje ukladané v určitých intervaloch pre následnú analýzu trendov ich zmien.

Alarmy - štatistické prahy, pri prekročení ktorých agent RMON odošle správu manažérovi. Umožňuje používateľovi definovať množinu prahových úrovní (tieto prahové hodnoty sa môžu týkať rôznych vecí – ľubovoľný parameter zo skupiny štatistík, amplitúda alebo rýchlosť jeho zmeny a mnohé ďalšie), pri prekročení ktorých sa generuje alarm. Používateľ môže tiež určiť, za akých podmienok má byť prekročenie prahovej hodnoty sprevádzané alarmom - zabráni sa tak generovaniu signálu „nanič“, čo je zlé, po prvé, pretože nikto nevenuje pozornosť neustále horiacej červenej svetlo a po druhé, pretože prenos zbytočných alarmov cez sieť vedie k zbytočnému zaťaženiu komunikačných liniek. Alarm sa zvyčajne odovzdá skupine udalostí, kde sa určí, čo s ním ďalej robiť.

Hostiteľ - údaje o hostiteľoch siete vrátane ich MAC adries.

HostTopN - tabuľka najvyťaženejších hostiteľov v sieti. Tabuľka N top hostiteľov (HostTopN) obsahuje zoznam top N hostiteľov charakterizovaných maximálnou hodnotou daného štatistického parametra pre daný interval. Môžete si napríklad vyžiadať zoznam 10 hostiteľov, ktorí zaznamenali najviac chýb za posledných 24 hodín. Tento zoznam zostaví samotný agent a aplikácia na správu dostane iba adresy týchto hostiteľov a hodnoty zodpovedajúcich štatistických parametrov. Je vidieť, do akej miery tento prístup šetrí sieťové zdroje.

TrafficMatrix – štatistika intenzity prevádzky medzi každým párom sieťových hostiteľov, usporiadaná vo forme matice. Riadky tejto matice sú očíslované podľa MAC adries staníc, ktoré sú zdrojmi správ, a stĺpce sú očíslované podľa adries prijímajúcich staníc. Maticové prvky charakterizujú intenzitu dopravy medzi príslušnými stanicami a počet chýb. Po analýze takejto matice môže používateľ ľahko zistiť, ktoré páry staníc generujú najintenzívnejšiu prevádzku. Túto maticu opäť tvorí samotný agent, takže nie je potrebné prenášať veľké množstvo dát do centrálneho počítača zodpovedného za správu siete.

Filter - podmienky filtrovania paketov. Kritériá, podľa ktorých sa pakety filtrujú, môžu byť veľmi rôznorodé – napríklad môže byť potrebné odfiltrovať ako chybné všetky pakety, ktorých dĺžka je menšia ako určitá špecifikovaná hodnota. Dá sa povedať, že inštalácia filtra zodpovedá, ako to bolo, organizácii kanála na prenos paketu. Kam tento kanál vedie, určuje používateľ. Napríklad všetky chybné pakety môžu byť zachytené a odoslané do príslušnej vyrovnávacej pamäte. Navyše, výskyt paketu, ktorý vyhovuje nastavenému filtru, možno považovať za udalosť (udalosť), na ktorú musí systém reagovať vopred určeným spôsobom.

PacketCapture - podmienky pre zachytávanie paketov. Skupina zachytávania paketov obsahuje vyrovnávacie pamäte na zachytávanie, kde sa odosielajú pakety, ktorých charakteristiky spĺňajú podmienky formulované v skupine filtrov. V tomto prípade nie je možné zachytiť celý paket, ale povedzme len prvých niekoľko desiatok bajtov paketu. Obsah odpočúvacích vyrovnávacích pamätí je možné následne analyzovať pomocou rôznych softvérových nástrojov, čím sa odhalí množstvo veľmi užitočných charakteristík siete. Preskupením filtrov pre určité znaky je možné charakterizovať rôzne parametre prevádzky siete.

Udalosť – podmienky registrácie a generovania udalostí. V skupine udalostí (udalosti) sa určuje, kedy sa má do riadiacej aplikácie odoslať alarm, kedy - zachytiť pakety a vo všeobecnosti - ako reagovať na určité udalosti vyskytujúce sa v sieti, napríklad na prekročenie prahu hodnoty ​​​​zadané v skupine alarmov: či nastaviť podľa znalosti riadiacej aplikácie, alebo stačí túto udalosť zaprotokolovať a pokračovať v práci. Udalosti môžu, ale nemusia súvisieť s prenosom alarmov – udalosťou je napríklad aj odoslanie paketu do vyrovnávacej pamäte.

Tieto skupiny sú očíslované v tomto poradí, takže napríklad skupina Hosts má číselný názov 1.3.6.1.2.1.16.4.

Desiatu skupinu tvoria špeciálne objekty protokolu TokenRing.

Celkovo štandard RMON MIB definuje asi 200 objektov v 10 skupinách, fixovaných v dvoch dokumentoch – RFC 1271 pre siete Ethernet a RFC 1513 pre siete TokenRing.

Charakteristickým znakom štandardu RMON MIB je jeho nezávislosť od protokolu sieťovej vrstvy (na rozdiel od štandardov MIB-I a MIB-II, ktoré sú orientované na protokoly TCP/IP). Preto je vhodné ho používať v heterogénnych prostrediach s použitím rôznych protokolov sieťovej vrstvy.

1.2 Populárne systémy správy siete

Systém riadenia siete - hardvérové ​​a/alebo softvérové ​​nástroje na monitorovanie a správu sieťových uzlov. Softvér systému správy siete pozostáva z agentov, ktorí sú lokalizovaní na sieťových zariadeniach a prenášajú informácie na platformu správy siete. Spôsob výmeny informácií medzi riadiacimi aplikáciami a agentmi na zariadeniach je definovaný protokolmi.

Systémy riadenia siete musia mať niekoľko vlastností:

skutočná distribúcia podľa konceptu klient/server,

škálovateľnosť

otvorenosť vyrovnať sa s heterogénnym vybavením – od stolných počítačov po sálové počítače.

Prvé dve vlastnosti spolu úzko súvisia. Dobrá škálovateľnosť je dosiahnutá vďaka distribúcii riadiaceho systému. Distribuované znamená, že systém môže obsahovať viacero serverov a klientov. Servery (správcovia) zhromažďujú údaje o aktuálnom stave siete od agentov (SNMP, CMIP alebo RMON) zabudovaných v sieťovom zariadení a akumulujú ich vo svojej databáze. Klienti sú grafické konzoly, ktoré používajú správcovia siete. Klientsky softvér riadiaceho systému prijíma požiadavky na vykonanie akejkoľvek akcie od administrátora (napríklad zostavenie podrobnej mapy časti siete) a vyžaduje potrebné informácie od servera. Ak má server potrebné informácie, okamžite ich odovzdá klientovi, ak nie, pokúsi sa ich získať od agentov.

Skoršie verzie riadiacich systémov spájali všetky funkcie v jednom počítači, ktorý používal administrátor. Pre malé siete alebo siete s malým množstvom spravovaných zariadení sa táto štruktúra ukazuje ako celkom uspokojivá, ale pri veľkom počte spravovaných zariadení sa jeden počítač, do ktorého prúdia informácie zo všetkých sieťových zariadení, stáva prekážkou. A sieť sa nedokáže vyrovnať s veľkým tokom dát a samotný počítač nemá čas na ich spracovanie. Okrem toho veľkú sieť zvyčajne spravuje viac ako jeden správca, preto by okrem niekoľkých serverov vo veľkej sieti malo existovať niekoľko konzol, za ktorými pracujú správcovia siete a každá konzola by mala poskytovať špecifické informácie, ktoré zodpovedajú aktuálnym potrebám. konkrétneho správcu.

Podpora heterogénnych zariadení je v dnešných riadiacich systémoch skôr želaním ako realitou. Štyri najobľúbenejšie produkty na správu siete sú Spectrum Cabletron Systems, OpenView od Hewlett-Packard, NetView od IBM a SunSoft Solstice od SunMicrosystems. Tri zo štyroch spoločností vyrábajú komunikačné zariadenia sami. Prirodzene, Spectrum najlepšie funguje so zariadením Cabletron, OpenView so zariadením Hewlett-Packard a NetView so zariadením IBM.

Pri vytváraní sieťovej mapy, ktorá pozostáva zo zariadení od iných výrobcov, tieto systémy začínajú robiť chyby a berú jedno zariadenie za druhé a pri správe týchto zariadení podporujú iba ich hlavné funkcie a mnoho užitočných doplnkových funkcií, ktoré odlišujú toto zariadenie od zvyšok, riadiaci systém je jednoduchý nerozumie a preto ich nemôže používať.

Aby sa tento nedostatok odstránil, vývojári riadiacich systémov zahrnuli podporu nielen pre štandardné MIB I, MIB II a RMON MIB, ale aj pre mnohé proprietárne MIB od výrobných spoločností. Lídrom v tejto oblasti je systém Spectrum, ktorý podporuje okolo 1000 MIB. rôznych výrobcov.

Ďalším spôsobom, ako lepšie podporiť konkrétne zariadenia, je použiť aplikáciu spoločnosti, ktorá toto zariadenie vyrába, na akejkoľvek riadiacej platforme. Popredné spoločnosti - výrobcovia komunikačných zariadení - vyvinuli a dodávajú pre svoje zariadenia veľmi zložité a multifunkčné riadiace systémy. Medzi najznámejšie systémy tejto triedy patria Optiivity od BayNetworks, CiscoWorks od CiscoSystems a Transcend od 3Com. Systém Optiivity vám napríklad umožňuje monitorovať a spravovať siete pozostávajúce zo smerovačov, prepínačov a rozbočovačov od BayNetwork, pričom naplno využijete všetky ich možnosti a vlastnosti. Zariadenia iných výrobcov sú podporované na úrovni základných funkcií ovládania. Systém Optiivity beží na platformách OpenView spoločnosti Hewlett-Packard a SunNetManager (predchodca spoločnosti Solstice) od spoločnosti SunSoft. Práca na akejkoľvek riadiacej platforme s viacerými systémami, ako je Optiivity, je však príliš zložitá a vyžaduje, aby počítače, ktoré to všetko budú spúšťať, mali výkonné procesory a veľký RAM.

Ak však v sieti dominuje zariadenie od jedného výrobcu, potom aplikácia od tohto výrobcu pre populárnu platformu na správu umožňuje správcom siete úspešne vykonávať mnohé úlohy. Preto vývojári platforiem pre správu dodávajú so sebou nástroje, ktoré uľahčujú vývoj aplikácií, pričom dostupnosť takýchto aplikácií a ich počet sa považuje za veľmi dôležitý faktor pri výbere platformy na správu.

Otvorenosť riadiacej platformy závisí aj od formy, v akej sú uložené zozbierané dáta o stave siete. Väčšina popredných platforiem umožňuje ukladanie údajov v komerčných databázach, ako sú Oracle, Ingres alebo Informix. Použitie univerzálnych DBMS znižuje rýchlosť riadiaceho systému v porovnaní s ukladaním údajov do súborov operačného systému, ale umožňuje spracovávať tieto údaje ľubovoľnými aplikáciami, ktoré dokážu s týmito DBMS pracovať.

2. VYHLÁSENIE PROBLÉMU

V súlade so súčasnou situáciou bolo rozhodnuté vyvinúť a implementovať sieťový monitorovací systém, ktorý by vyriešil všetky vyššie uvedené problémy.

2.1 Referenčné podmienky

Vyviňte a implementujte monitorovací systém, ktorý umožňuje monitorovanie prepínačov, smerovačov od rôznych výrobcov a serverov z rôznych platforiem. Zamerajte sa na používanie otvorených protokolov a systémov s maximálnym využitím hotového vývoja z fondu slobodného softvéru.

2.2 Prepracované zadávacie podmienky

V rámci ďalšej formulácie problému a skúmania predmetnej oblasti, s prihliadnutím na ekonomické a časové investície, bola vykonaná špecifikácia zadania:

Systém musí spĺňať nasledujúce požiadavky:

§ minimálne požiadavky na hardvérové ​​zdroje;

§ otvorené zdrojové kódy všetkých komponentov komplexu;

§ rozšíriteľnosť a škálovateľnosť systému;

§ štandardné prostriedky poskytovanie diagnostických informácií;

§ dostupnosť podrobnej dokumentácie pre všetky používané softvérové ​​produkty;

§ Schopnosť pracovať so zariadeniami od rôznych výrobcov.

3. NAVRHOVANÝ SYSTÉM

1 Výber systému monitorovania siete

V súlade s revidovanými referenčnými podmienkami je systém Nagios najvhodnejší ako jadro systému monitorovania siete, pretože má nasledujúce vlastnosti:

§ existujú prostriedky na vytváranie diagramov;

§ existujú prostriedky na vytváranie správ;

§ existuje možnosť logického zoskupovania;

§ je tu zabudovaný systém na zaznamenávanie trendov a ich predpovedanie;

§ je možné automaticky pridávať nové zariadenia (Autodiscovery) pomocou oficiálneho pluginu;

§ existuje možnosť pokročilého monitorovania hostiteľa pomocou agenta;

§ podpora protokolu SNMP cez plugin;

§ podpora protokolu Syslog prostredníctvom doplnku;

§ podpora externých skriptov;

§ podpora samonapísaných pluginov a schopnosť rýchlo a jednoduchá tvorba;

§ vstavané spúšťače a udalosti;

§ plnohodnotné webové rozhranie;

§ možnosť distribuovaného monitorovania;

§ inventár prostredníctvom pluginu;

§ schopnosť ukladať údaje do súborov aj do databáz SQL, čo je veľmi dôležité pri zvyšovaní objemov;

§ licencia GPL, a teda bezplatná základná distribúcia, podpora a otvorené zdrojové kódy jadra systému a sprievodných komponentov;

§ dynamické a prispôsobiteľné mapy;

§ Riadenie prístupu;

§ vstavaný jazyk na popis hostiteľov, služieb a kontrol;

§ schopnosť sledovať používateľov.

Systém monitorovania siete Zabbix má podobnú sadu parametrov, no v čase implementácie mal oveľa menšiu funkcionalitu ako Nagios a mal status beta verzie. Štúdia tematických fór a spravodajských kanálov navyše ukázala najväčšiu prevalenciu medzi používateľmi Nagios, čo znamená prítomnosť používateľmi písanej dokumentácie a najpodrobnejší popis ťažkých momentov v konfigurácii.

Nagios umožňuje sledovať sieťové služby ako SMTP, TELNET, SSH, HTTP, DNS, POP3, IMAP, NNTP a mnohé ďalšie. Okrem toho môžete monitorovať využitie zdrojov servera, ako je spotreba miesta na disku, voľná pamäť a zaťaženie procesora. Je možné vytvoriť si vlastné obslužné programy udalostí. Tieto obslužné rutiny sa vykonajú, keď sa kontrolami služby alebo servera spustia určité udalosti. Tento prístup vám umožní aktívne reagovať na prebiehajúce udalosti a snažiť sa automaticky riešiť vzniknuté problémy. Môžete napríklad vytvoriť obsluhu udalosti, ktorá automaticky reštartuje zablokovanú službu. Ďalšou výhodou monitorovacieho systému Nagios je možnosť ovládať ho na diaľku pomocou wapového rozhrania mobilného telefónu. Pomocou konceptu „rodičovských“ hostiteľov je ľahké opísať hierarchiu a závislosti medzi všetkými hostiteľmi. Tento prístup je mimoriadne užitočný pre veľké siete, pretože umožňuje komplexnú diagnostiku. A táto kvalita zase pomáha rozlíšiť nepracujúcich hostiteľov od tých, ktorí momentálne nie sú k dispozícii kvôli poruchám medzičlánkov. Nagios dokáže zostaviť grafy monitorovaných systémov a mapy monitorovanej sieťovej infraštruktúry.

Zo svojich skúseností zo spolupráce s Nagiosom môže autor uviesť príklad, ktorý ukazuje, aké užitočné to bolo pre jeho osobnú prax. Externé sieťové rozhranie brány firewall začalo strácať pakety každých niekoľko hodín. Kvôli poruche vypadlo až 20 percent prejazdnej dopravy. Po minúte - druhé rozhranie začalo opäť fungovať podľa očakávania. Vzhľadom na občasný charakter tohto problému sa niekoľko týždňov nepodarilo zistiť, prečo dochádza pri používaní internetu k občasným občasným zlyhaniam. Bez Nagios by riešenie problémov trvalo dlho.

Mnoho administrátorov pozná predchodcu Nagios NetSaint. Hoci stránka projektu NetSaint stále funguje správne, nový vývoj je už založený na zdrojovom kóde Nagios. Preto sa odporúča, aby sa všetci pomaly presunuli do Nagiosu.

Dokumentácia dodávaná s Nagios hovorí, že bude dobre fungovať aj s mnohými ďalšími systémami podobnými Unixu. Na zobrazenie webového rozhrania Nagios potrebujeme server Apache. Môžete voľne používať akýkoľvek iný, ale v tejto práci bude Apache považovaný za najbežnejší webový server na platformách Unix. Monitorovací systém môžete nainštalovať úplne bez webového rozhrania, ale my to neurobíme, pretože to výrazne znižuje použiteľnosť.

4. VÝVOJ SOFTVÉRU

Ako hardvérovú súčasť implementovaného systému môžete použiť bežný počítač kompatibilný s IBM, avšak berúc do úvahy možnosť ďalšieho zvyšovania záťaže a požiadavky na spoľahlivosť a MTBF, ako aj GosSvyazNadzor, bolo certifikované serverové vybavenie od spoločnosti Aquarius. zakúpené.

Existujúca sieť aktívne využíva operačný systém Debian založený na jadre Linux, má bohaté skúsenosti s používaním tohto systému a väčšina operácií na správu, konfiguráciu a zabezpečenie jeho stability je odladená. Okrem toho je tento OS distribuovaný pod licenciou GPL, ktorá označuje jeho bezplatné a otvorené zdrojové kódy, čo zodpovedá aktualizovaným referenčným podmienkam pre navrhovanie systému monitorovania siete. (Celý názov je GNU / Linux, vyslovuje sa „gnu slash“ ́ Nux, tiež v niektorých jazykoch „GNU+Linux“, „GNU-Linux“ atď.) je bežný názov pre operačné systémy podobné UNIXu založené na jadre s rovnakým názvom a knižniciach, ktoré sú preň zostavené a systémové programy, vyvinutý v rámci projektu GNU./Linux, beží na PC kompatibilných systémoch rodiny Intel x86, ako aj na IA-64, AMD64, PowerPC, ARM a mnohých ďalších.

Operačný systém GNU/Linux tiež často obsahuje programy, ktoré tento operačný systém dopĺňajú, a aplikačné programy, ktoré z neho robia plnohodnotné multifunkčné operačné prostredie.

Na rozdiel od väčšiny ostatných operačných systémov sa GNU/Linux nedodáva s jediným „oficiálnym“ balíkom. Namiesto toho GNU/Linux prichádza vo veľkom množstve takzvaných distribúcií, ktoré spájajú programy GNU s jadrom Linuxu a inými programami. Najznámejšie distribúcie GNU/Linux sú Ubuntu, Debian GNU/Linux, Red Hat, Fedora, Mandriva, SuSE, Gentoo, Slackware, Archlinux. Ruské distribúcie - ALT Linux a ASPLinux.

Na rozdiel od Microsoft Windows (Windows NT), Mac OS (Mac OS X) a komerčných systémov podobných UNIX, GNU/Linux nemá geografické vývojové centrum. Neexistuje žiadna organizácia, ktorá vlastní tento systém; neexistuje ani jedno koordinačné centrum. Programy pre Linux sú výsledkom práce tisícov projektov. Niektoré z týchto projektov sú centralizované, niektoré sú sústredené vo firmách. Mnohé projekty združujú hackerov z celého sveta, ktorí sa poznajú len z korešpondencie. Každý môže vytvoriť svoj vlastný projekt alebo sa pripojiť k existujúcemu projektu a v prípade úspechu sa výsledky práce dozvedia milióny používateľov. Používatelia sa zúčastňujú testovania bezplatného softvéru, komunikujú priamo s vývojármi, čo im umožňuje rýchlo nájsť a opraviť chyby a implementovať nové funkcie.

História vývoja UNIXových systémov. GNU/Linux je kompatibilný so systémom UNIX, ale je založený na vlastnom zdrojovom kóde

Práve tento flexibilný a dynamický vývojový systém, ktorý je pre projekty s uzavretým zdrojovým kódom nemožný, určuje výnimočnú nákladovú efektívnosť [zdroj neuvedený 199 dní] GNU/Linux. Nízke náklady na bezplatný vývoj, dobre zavedené testovacie a distribučné mechanizmy, zapojenie ľudí z rôznych krajín s rôznymi víziami problémov, ochrana kódu licenciou GPL – to všetko sa stalo dôvodom úspechu slobodného softvéru. .

Samozrejme, takáto vysoká efektivita vývoja nemohla nezaujať veľké spoločnosti, ktoré začali otvárať svoje projekty. Takto sa objavil Mozilla (Netscape, AOL), OpenOffice.org (Sun), bezplatný klon Interbase (Borland) - Firebird, SAP DB (SAP). IBM uľahčila portovanie GNU/Linuxu na svoje sálové počítače.

Na druhej strane, open source výrazne znižuje náklady na vývoj. uzavreté systémy pre GNU/Linux a umožňuje znížiť cenu riešenia pre používateľa. To je dôvod, prečo sa GNU/Linux stal platformou často odporúčanou pre produkty ako Oracle, DB2, Informix, SyBase, SAP R3, Domino.

Komunita GNU/Linux komunikuje prostredníctvom skupín používateľov Linuxu.

Väčšina používateľov používa distribúcie na inštaláciu GNU/Linuxu. Distribučný kit nie je len súbor programov, ale množstvo riešení pre rôzne užívateľské úlohy, zjednotené spoločnými systémami pre inštaláciu, správu a aktualizáciu balíkov, konfiguráciu a podporu.

Najbežnejšie distribúcie na svete: - distribúcia, ktorá si rýchlo získala popularitu, zameraná na jednoduché učenie a používanie - bezplatná verzia distribúcie SuSE, ktorú vlastní Novell. Je ľahké ho nastaviť a udržiavať pomocou nástroja YaST. - podporované komunitou a korporáciou RedHat, predchádza vydaniam komerčnej verzie RHEL GNU / Linux - medzinárodná distribučná súprava vyvinutá veľkou komunitou vývojárov pre ne -komerčné účely. Slúžil ako základ pre vznik mnohých ďalších distribúcií. Vyznačuje sa prísnym prístupom k zahrnutiu neslobodného softvéru - francúzsko-brazílska distribúcia, ktorá je zlúčením bývalej Mandrake a Conectiva (anglicky) - jedna z najstarších distribúcií, vyznačujúca sa konzervatívnym prístupom vo vývoji a používaní - Distribučná súprava, ktorá je zostavená zo zdrojových kódov. Umožňuje veľmi flexibilné prispôsobenie koncového systému a optimalizáciu výkonu, preto sa často nazýva metadistribúcia. Zamerané na odborníkov a pokročilých používateľov - zamerané na aplikáciu toho naj najnovšie verzie Táto distribúcia je neustále aktualizovaná, podporuje binárne aj zdrojové inštalácie a je postavená na filozofii jednoduchosti KISS a je zameraná na skúsených používateľov, ktorí chcú všetku silu a modifikovateľnosť Linuxu bez obetovania času na údržbu.

Okrem tých, ktoré sú uvedené, existuje mnoho ďalších distribúcií, ktoré sú založené na tých, ktoré sú uvedené v zozname, aj vytvorené od začiatku a často navrhnuté na vykonávanie obmedzeného počtu úloh.

Každý z nich má svoj vlastný koncept, vlastnú sadu balíkov, svoje výhody a nevýhody. Žiadna z nich nedokáže uspokojiť všetkých používateľov, a preto popri lídroch existujú ďalšie firmy a programátorské združenia, ktoré ponúkajú svoje riešenia, svoje distribúcie, svoje služby. Na GNU/Linux je postavených mnoho LiveCD, ako napríklad Knoppix. LiveCD vám umožňuje spúšťať GNU/Linux priamo z CD bez inštalácie na váš pevný disk.

Pre tých, ktorí chcú dôkladne porozumieť GNU / Linuxu, je vhodná ktorákoľvek z distribúcií, pomerne často sa však na tento účel používajú takzvané zdrojové distribúcie, to znamená, že zahŕňajú samozostavenie všetkých (alebo častí) komponentov zo zdrojových kódov, ako sú LFS, Gentoo, ArchLinux alebo CRUX.

4.1 Inštalácia jadra systému

Nagios je možné nainštalovať dvoma spôsobmi – zo zdrojov a zo zostavených balíkov. Obe metódy majú výhody a nevýhody, zvážte ich.

Výhody inštalácie ich zdrojového balíka:

§ možnosť detailnej konfigurácie systému;

§ vysoký stupeň optimalizácie aplikácie;

§ najkompletnejšie zastúpenie programu.

Nevýhody inštalácie ich zdrojového balíka:

§ na zostavenie balíka je potrebný ďalší čas, ktorý často prekračuje čas na jeho konfiguráciu a ladenie;

§ nemožnosť odstrániť balík spolu s konfiguračnými súbormi;

§ nemožnosť aktualizovať balík spolu s konfiguračnými súbormi;

§ nemožnosť centralizovanej kontroly nad inštalovanými aplikáciami.

Pri inštalácii Nagios z vopred zostaveného balíka sa výhody surovej metódy inštalácie stanú nevýhodami a naopak. Ako však ukázala prax, vopred zostavený balík spĺňa všetky požiadavky na systém a nemá zmysel strácať čas manuálnym zostavovaním balíka.

Keďže oba spôsoby inštalácie boli pôvodne testované, zvážime každý z nich podrobnejšie.

4.1.1 Popis inštalácie systému jadra ich zdrojových kódov

Požadované balíčky.

Pred nasadením Nagios sa musíte uistiť, že sú nainštalované nasledujúce balíky. Podrobná diskusia o procese ich inštalácie presahuje rámec tejto práce.

· Apache 2

· PHP

· GCC kompilátor a vývojárske knižnice

· Vývojárske knižnice GD

Na ich inštaláciu môžete použiť apt-get (najlepšie aptitude):

% sudo apt-get install apache2

% sudo apt-get install libapache2-mod-php5

% sudo apt-get install build-essential

% sudo apt-get install libgd2-dev

1) Vytvorte si nový používateľský neprivilegovaný účet

Vytvorí sa nový účet na spustenie služby Nagios. Môžete to urobiť aj z účtu superužívateľa, čo vytvorí vážnu hrozbu pre bezpečnosť systému.

Staňte sa superužívateľom:

Vytvorte si nový používateľský účet nagios a zadajte mu heslo:

# /usr/sbin/useradd -m -s /bin/bash nagios

# passwd nagios

Vytvorte skupinu nagios a pridajte do nej používateľa nagios:

# /usr/sbin/groupadd nagios

# /usr/sbin/usermod -G nagios nagios

Vytvorte skupinu nagcmd, ktorá umožní spustenie externé príkazy prešiel cez webové rozhranie. Pridajme používateľov nagios a apache do tejto skupiny:

# /usr/sbin/groupadd nagcmd

# /usr/sbin/usermod -a -G nagcmd nagios

# /usr/sbin/usermod -a -G nagcmd www-data

2) Stiahnite si Nagios a jeho doplnky

Vytvorte adresár na uloženie stiahnutých súborov:

# mkdir ~/downloads

# cd ~/sťahovanie

Stiahnite si komprimované zdroje Nagios a jeho doplnkov (#"justify"># wget #"justify"># wget #"justify">3) Kompilujte a nainštalujte Nagios

Rozbaľme komprimované zdroje Nagios:

# cd ~/sťahovanie

# tar xzf nagios-3.2.0.tar.gz

# cd nagios-3.2.0

Spustite konfiguračný skript Nagios a odovzdajte mu názov skupiny, ktorú sme predtým vytvorili:

# ./configure --with-command-group=nagcmd

Úplný zoznam parametrov konfiguračného skriptu:

#./configure --help

`configure" nakonfiguruje tento balík tak, aby sa prispôsobil mnohým druhom systémov.: ./configure ... ...priraďte premenné prostredia (napr. CC, CFLAGS...), zadajte ich ako=VALUE. Popis niektorých z užitočných premenných. pre možnosti sú uvedené v zátvorkách.:

h, --help zobrazí túto pomoc a skončí

Help=krátke možnosti zobrazenia špecifické pre tento balík

Help=rekurzívne zobrazí krátku pomoc ku všetkým zahrnutým balíkom

V, --version zobrazí informácie o verzii a skončí

q, --quiet, --silent netlačí správy `checking..."

cache-file=SÚBOR Výsledky testu vyrovnávacej pamäte v FILE

C, --config-cache alias pre `--cache-file=config.cache"

n, --no-create nevytvára výstupné súbory

Srcdir=DIR nájsť zdroje v adresároch DIR:

Prefix=PREFIX inštaluje súbory nezávislé na architektúre v PREFIX

Exec-prefix=EPREFIX inštalovať súbory závislé od architektúry v EPREFIX predvolene, `make install" nainštaluje všetky súbory v `/usr/local/nagios/bin", `/usr/local/nagios/lib" atď. iná inštalačná predpona ako `/usr/local/nagios" pomocou `--prefix", napríklad `--prefix=$HOME".lepšie ovládanie, použite možnosti nižšie.ladenie inštalačných adresárov:

Bindir=DIR užívateľské spustiteľné súbory

Sbindir=Spustiteľné súbory správcu systému DIR

libexecdir=Spustiteľné súbory programu DIR

Datadir=DIR dáta nezávislé od architektúry len na čítanie

Sysconfdir=DIR iba na čítanie dát jedného počítača

Sharedstatedir=DIR upraviteľné dáta nezávislé od architektúry

Localstatedir=DIR upraviteľné údaje jedného počítača

Libdir=Knižnice objektového kódu DIR

Includedir=DIR C hlavičkové súbory

oldincludedir=DIR C hlavičkové súbory pre iné ako gcc

infodir=DIR informačná dokumentácia

Mandir=DIR typy dokumentácie man:

Build=BUILD konfigurácia pre budovanie na BUILD

Host=HOST krížová kompilácia na vytváranie programov na spustenie na HOST Funkcie:

Disable-FEATURE nezahŕňa FEATURE (rovnako ako --enable-FEATURE=no)

Enable-FEATURE[=ARG] obsahuje FEATURE

disable-statusmap=zakáže kompiláciu CGI statusmap

disable-statuswrl=zakáže kompiláciu statuswrl (VRML) CGI

Enable-DEBUG0 zobrazuje vstup a výstup funkcie

Enable-DEBUG1 zobrazuje všeobecné informačné správy

Enable-DEBUG2 zobrazuje varovné správy

Povoliť – DEBUG3 zobrazuje plánované udalosti (kontroly služby a hostiteľa... atď.)

Povoliť – DEBUG4 zobrazuje upozornenia služby a hostiteľa

Enable-DEBUG5 zobrazuje SQL dotazy

Enable-DEBUGALL zobrazí všetky ladiace správy

Enable-nanosleep umožňuje použitie nanospánku (namiesto spánku) pri načasovaní udalosti

Enable-event-broker umožňuje integráciu rutín sprostredkovateľa udalostí

Enable-embedded-perl povolí embedded Perl interpret

Enable-cygwin umožňuje stavať v prostredí CYGWIN Balíky:

With-PACKAGE[=ARG] použite PACKAGE

Bez-BALENIE nepoužívajte BALENIE (rovnaké ako --with-BALENIE=no)

With-nagios-user= nastaví používateľské meno na spustenie nagios

With-nagios-group= nastaví názov skupiny na spustenie nagios

With-command-user= nastavuje meno používateľa pre prístup k príkazom

With-command-group= nastavuje názov skupiny pre prístup k príkazom

S-mailom= Nastaví cestu k ekvivalentnému programu do pošty

With-init-dir= Nastavte adresár, do ktorého sa má umiestniť init skript

With-lockfile= Nastavte cestu a názov súboru zámku

With-gd-lib=DIR nastaví umiestnenie knižnice gd

With-gd-inc=DIR nastaví umiestnenie gd include súborov

With-cgiurl= nastavuje URL pre programy cgi (nepoužívajte koncovú lomku)

With-htmurl= nastaví URL pre verejné html

With-perlcache zapína ukladanie interne kompilovaných skriptov Perl do vyrovnávacej pamäte vplyvných premenných prostredia: Príkaz kompilátora C Príznaky prekladača kompilátora, napr. -L ak máte knižnice v adresári Príznaky preprocesora C/C++, napr. -Ja ak máte v neštandardnom adresári C predprocesoruje tieto premenné na potlačenie volieb vykonaných príkazom `configure' alebo na pomoc pri hľadaní knižníc a programov s neštandardnými názvami/umiestneniami.

Kompilácia zdrojového kódu Nagios.

Nainštalujte binárne súbory, inicializačný skript, vzorové konfiguračné súbory a nastavte povolenia v adresári externých príkazov:

# make install-init

# make install-config

# make install-commandmode

) Zmeňte konfiguráciu

Vzorové konfiguračné súbory sú nainštalované v adresári /usr/local/nagios/etc. Mali by okamžite pracovať. Pred pokračovaním musíte vykonať iba jednu zmenu.

Upravme konfiguračný súbor /usr/local/nagios/etc/objects/contacts.cfg pomocou ľubovoľného textového editora a zmeňte e-mailovú adresu spojenú s definíciou kontaktu nagiosadmin na adresu, na ktorú budeme dostávať hlásenia o problémoch.

# vi /usr/local/nagios/etc/objects/contacts.cfg

5) Nastavenie webového rozhrania

Nainštalujte konfiguračný súbor webového rozhrania Nagios do adresára Apache conf.d.

# make install-webconf

Vytvorte si účet nagiosadmin na prihlásenie do webového rozhrania Nagios

# htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin

Reštartujte Apache, aby sa zmeny prejavili.

# /etc/init.d/apache2 reload

Je potrebné prijať opatrenia na posilnenie bezpečnosti CGI, aby sa zabránilo krádeži tohto účtu, pretože monitorovacie informácie sú dosť citlivé.

) Zostavte a nainštalujte doplnky Nagios

Rozbaľme komprimované zdroje doplnkov Nagios:

# cd ~/sťahovanie

# tar xzf nagios-plugins-1.4.11.tar.gz

Kompilácia a inštalácia doplnkov:

# ./configure --with-nagios-user=nagios --with-nagios-group=nagios

#make install

) Spustite službu Nagios

Nastaviť Nagios pre automatické sťahovanie keď zapnete operačný systém:

# ln -s /etc/init.d/nagios /etc/rcS.d/S99nagios

Poďme skontrolovať syntaktickú správnosť vzorových konfiguračných súborov:

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg

Ak nie sú žiadne chyby, spustite Nagios:

# /etc/init.d/nagios štart

) Vstúpte do webového rozhrania

Teraz sa môžete prihlásiť do webového rozhrania Nagios pomocou nasledujúcej adresy URL. Budete vyzvaní na zadanie používateľského mena (nagiosadmin) a hesla, ktoré sme nastavili predtým.

#"justify">) Rôzne nastavenia

Ak chcete dostávať e-mailové pripomienky o udalostiach Nagios, musíte si nainštalovať balík mailx (Postfix):

% sudo apt-get install mailx

% sudo apt-get install postfix

Musíte upraviť príkazy Nagios pripomienky v /usr/local/nagios/etc/objects/commands.cfg a zmeniť všetky odkazy z "/bin/mail" na "/usr/bin/mail". Potom musíte reštartovať službu Nagios:

# sudo /etc/init.d/nagios reštart

Podrobná konfigurácia poštového modulu je popísaná v prílohe D.

4.1.2 Popis inštalácie jadra systému z úložiska

Ako je uvedené vyššie, inštalácia Nagios zo zdroja trvá značné množstvo času a má zmysel iba vtedy, ak vyžadujete starostlivú optimalizáciu aplikácie alebo chcete dôkladne pochopiť mechanizmus systému. V produkčných podmienkach sa väčšina softvéru inštaluje z repozitárov ako predkompilované balíky. V tomto prípade sa inštalácia zredukuje na zadanie jediného príkazu:

% sudo aptitude install nagios

Samotný správca balíkov uspokojí všetky závislosti a nainštaluje potrebné balíky.

4.2 Konfigurácia jadra systému

Pred podrobnou konfiguráciou by ste mali pochopiť, ako funguje jadro Nagios. Jeho grafický popis je uvedený nižšie na obrázku 6.2.

4.2.1 Popis činnosti jadra systému

Nasledujúci obrázok zobrazuje zjednodušený diagram fungovania služby Nagios.

Ryža. 4.1 - Jadro systému

Služba Nagios číta hlavný konfiguračný súbor, ktorý okrem hlavných parametrov služby obsahuje odkazy na zdrojové súbory, súbory s popisom objektov a konfiguračné súbory CGI.

Algoritmus a logika jadra monitorovania siete sú uvedené nižšie.

Ryža. 4.2 - Algoritmus výstrahy Nagios

2.2 Popis interakcie konfiguračných súborov

Adresár /etc/apache2/conf.d/ obsahuje súbor nagios3.conf, z ktorého webový server apache preberá nastavenia pre nagios.

Konfiguračné súbory nagios sa nachádzajú v adresári /etc/nagios3.

Súbor /etc/nagios3/htpasswd.users obsahuje heslá pre používateľov nagios. Príkaz na vytvorenie súboru a nastavenie hesla pre predvoleného používateľa nagios je uvedený vyššie. V budúcnosti bude potrebné pri nastavovaní hesla pre nového používateľa vynechať argument "-c", inak nový súbor staré odpadky.

Súbor /etc/nagios3/nagios.cfg obsahuje hlavnú konfiguráciu samotného nagios. Napríklad súbory denníka udalostí alebo cesta k iným konfiguračným súborom, ktoré nagios číta pri spustení.

Adresár /etc/nagios/objects obsahuje nových hostiteľov a služby.

4.2.3 Vypĺňanie popisov hostiteľa a služieb

Ako je uvedené vyššie, je možné nakonfigurovať jadro systému pomocou jedného súboru s popisom pre hostiteľov a služby, ale táto metóda nebude vhodná pri zvyšovaní počtu monitorovaných zariadení, takže je potrebné vytvoriť nejaký druh adresára a štruktúra súborov s popismi hostiteľov a služieb.

Vytvorená štruktúra je znázornená v prílohe H.

súbor hosts.cfg

Prvým krokom je popísať hostiteľov, ktorí budú monitorovaní. Môžete opísať toľko hostiteľov, koľko chcete, ale v tomto súbore sa obmedzíme na všeobecné parametre pre všetkých hostiteľov.

Tu opísaný hostiteľ nie je skutočný hostiteľ, ale šablóna, na ktorej sú založené popisy všetkých ostatných hostiteľov. Rovnaký mechanizmus možno nájsť v iných konfiguračných súboroch, keď je konfigurácia založená na preddefinovanom súbore predvolených hodnôt.

súbor hostgroups.cfg

Tu sú hostitelia pridaní do hostiteľskej skupiny. Dokonca aj v jednoduchej konfigurácii, keď existuje iba jeden hostiteľ, ho stále musíte pridať do skupiny, aby Nagios vedel, ktorú skupinu kontaktov použiť na odosielanie upozornení. Viac o kontaktnej skupine nižšie.

Contactgroups.cfg súbor

Definovali sme skupinu kontaktov a pridali používateľov do tejto skupiny. Táto konfigurácia zabezpečuje, že všetci používatelia dostanú varovanie, ak sa niečo pokazí na serveroch, za ktoré je skupina zodpovedná. Je pravda, že musíte mať na pamäti, že individuálne nastavenia pre každého používateľa môžu tieto nastavenia prepísať.

Ďalším krokom je zadanie kontaktných informácií a nastavení upozornení.

Contacts.cfg súbor

Okrem poskytnutia dodatočných kontaktných informácií pre používateľov v tomto súbore má jedno z polí, contact_name, ďalší účel. Skripty CGI používajú názvy uvedené v týchto poliach na určenie, či má používateľ právo na prístup k nejakému zdroju alebo nie. Musíte nastaviť autentifikáciu založenú na .htaccess, ale okrem toho musíte použiť rovnaké mená ako vyššie, aby používatelia mohli pracovať cez webové rozhranie.

Teraz, keď sú hostitelia a kontakty nakonfigurované, môžeme prejsť ku konfigurácii monitorovania jednotlivých služieb, ktoré by sa mali monitorovať.

Súbor Services.cfg

Tu, rovnako ako v súbore hosts.cfg pre hostiteľov, nastavujeme iba všeobecné parametre pre všetky služby.

K dispozícii je obrovské množstvo doplnkových modulov Nagios, ale ak vám stále chýba nejaký druh kontroly, môžete si ho kedykoľvek napísať sami. Napríklad neexistuje modul, ktorý by kontroloval, či je Tomcat spustený alebo nie. Môžete napísať skript, ktorý načíta stránku jsp zo vzdialeného servera Tomcat a vráti výsledok v závislosti od toho, či načítaná stránka obsahuje nejaký text alebo nie. (Pri pridávaní nového príkazu ho nezabudnite uviesť v súbore checkcommand.cfg, ktorého sme sa nedotkli).

Ďalej pre každého jednotlivého hostiteľa vytvoríme vlastný popisný súbor, do toho istého súboru uložíme popisy služieb, ktoré budeme pre tohto hostiteľa monitorovať. To sa robí pre pohodlie a logickú organizáciu.

Stojí za zmienku, že hostitelia Windows sú monitorovaní pomocou protokolu SNMP a NSClient. ktorý prichádza s Nagiosom. Nižšie je uvedený diagram, ako to funguje.

Ryža. 4.3 - Schéma monitorovania hostiteľov Windows

Zároveň sú *nix hostitelia monitorovaní aj cez SNMP, ako aj plugin NRPE. Schéma jeho práce je znázornená na obrázku.

Ryža. 4.4 - Schéma monitorovania *nix hostiteľov

2.4 Zásuvné moduly na písanie

Okrem písania inicializačných skriptov, definovania hostiteľov a služieb boli použité nasledujúce pluginy:

├── check_disk

├── check_dns

├── check_http

├── check_icmp

├── check_ifoperstatus

├── check_ifstatus

├── check_imap -> check_tcp

├── check_linux_raid

├── check_load

├── check_mrtg

├── check_mrtgtraf

├── check_nrpe

├── check_nt

├── check_ping

├── check_pop -> check_tcp

├── check_sensors

├── check_simap -> check_tcp

├── check_smtp

├── check_snmp

├── check_snmp_load.pl

├── check_snmp_mem.pl

├── check_spop -> check_tcp

├── check_ssh

├── check_ssmtp -> check_tcp

├── check_swap

├── check_tcp

├── check_time

Väčšina z nich prichádza s balíkom Nagios. Zdrojové texty zásuvných modulov, ktoré nie sú súčasťou dodávky a používajú sa v systéme, sú uvedené v prílohe I.

4.2.5 Konfigurácia SNMP na vzdialených hostiteľoch

Aby ste mohli monitorovať pomocou protokolu SNMP, musíte najprv nakonfigurovať agentov tohto protokolu na sieťovom zariadení. Schéma fungovania SNMP v spojení s jadrom systému monitorovania siete je znázornená na obrázku nižšie.

Ryža. 4.5 - Schéma monitorovania cez SNMP protokol

Parametre konfigurácie hostiteľa sú uvedené v prílohe H. Zabezpečenie poskytuje prispôsobenie paketový filter na každom z hostiteľov samostatne a organizovaním zabezpečených systémových podsietí, ku ktorým majú prístup iba oprávnení pracovníci podniku. Okrem toho je konfigurácia vykonaná tak, že pomocou protokolu SNMP môžete parametre iba čítať a nie zapisovať.

4.2.6 Konfigurácia agenta na vzdialených hostiteľoch

Ak chcete získať pokročilé možnosti monitorovania pre hostiteľov a služby, musíte na nich nainštalovať agenta Nagios, ktorý sa nazýva nagios-nrpe-server:

# aptitude install nagios-nrpe-server

Konfigurácia agenta je uvedená v prílohe K. Schéma činnosti agenta je znázornená na obrázku 4.5 vyššie.

4.4 Inštalácia a konfigurácia modulu sledovania sťahovania

MRTG (Multi Router Traffic Grapher) je služba, ktorá vám umožňuje prijímať informácie z niekoľkých zariadení prostredníctvom protokolu SNMP a zobrazovať grafy zaťaženia kanálov (prichádzajúca, odchádzajúca, maximálna, priemerná) v minútach, hodinách, dňoch a za rok vo vašom prehliadači. okno.

Požiadavky na inštaláciu

MRTG vyžaduje, aby fungovali nasledujúce knižnice:

§ gd - knižnica kreslenia grafov. Knižnica zodpovedná za vykresľovanie grafiky (#"justify">§ libpng - na vytvorenie grafiky png je potrebné gd (#"justify">V našom prípade sa inštalácia zredukuje na spustenie jedného príkazu, pretože je zvolený spôsob inštalácie predkompilovaného balíka z úložiska:

# aptitude install mrtg

Konfiguračné súbory môžete vytvoriť manuálne alebo môžete použiť generátory konfigurácií, ktoré sú súčasťou balíka:

#cfgmaker @ >

Po vygenerovaní konfiguračného súboru sa odporúča skontrolovať ho, pretože môže obsahovať popisy rozhraní, ktoré nemusíme analyzovať z hľadiska pracovného zaťaženia. V takom prípade sú niektoré riadky v súbore zakomentované alebo odstránené. Príklad konfiguračného súboru MRTG je uvedený v prílohe M. Kvôli veľkej veľkosti týchto súborov je zobrazený iba jeden vzorový súbor.

#indexmaker >

Indexové stránky sú normálne html súbory a ich obsah nie je zvlášť zaujímavý, preto nemá zmysel uvádzať ich príklady. V prílohe H je uvedený príklad zobrazenia grafov načítania rozhrania.

Na záver je potrebné zorganizovať plánovú kontrolu zaťaženia rozhraní. Najjednoduchší spôsob, ako to dosiahnuť, je pomocou operačného systému, konkrétne parametrov crontab.

4.5 Inštalácia a konfigurácia modulu na zber systémových protokolov udalostí

Ako modul na zber protokolov systémových udalostí bol zvolený balík syslog-ng.ng (syslog next generation) - ide o multifunkčnú službu na protokolovanie systémových správ. V porovnaní so štandardnou službou syslogd má niekoľko rozdielov:

§ pokročilá konfiguračná schéma

§ filtrovanie správ nielen podľa priorít, ale aj podľa ich obsahu

§ podpora pre regulárne výrazy (regulárne výrazy)

§ flexibilnejšiu manipuláciu a organizáciu protokolov

§ schopnosť šifrovať dátový kanál pomocou IPSec / Stunnel

Nasledujúca tabuľka obsahuje zoznam podporovaných hardvérových platforiem.

Tabuľka 4.1 - Podporované hardvérové ​​platformy

x86x86_64SUN SPARCppc32ppc64PA-RISCAIX 5.2 & 5.3НетНетНетДаПо запросуНетDebian etchДаДаНетНетНетНетFreeBSD 6.1 *ДаПо запросуПо запросуНетНетНетHP-UНет 11iНетНетНетНетНетДаIBM System iНетНетНетДаНетНетRed Hat ES 4 / CentOS 4ДаДаНетНетНетНетRed Hat ES 5 / CentOS 5ДаДаНетНетНетНетSLES 10 / openSUSE 10.0ДаПо запросуНетНетНетНетSLES 10 SP1 / openSUSE 10.1ДаДаНетНетНетНетSolaris 8НетНетДаНетНетНетSolaris 9По запросуНетДаНетНетНетSolaris 10По запросуДаДаНетНетНетWindowsДаДаНетНетНетНет Poznámka: *Prístup k databáze Oracle nie je podporovaný

Podrobné porovnanie technické vlastnosti uvedené v prílohe P.

Súbory na popis pravidiel a filtrov, ako aj konfigurácie vzdialených hostiteľov sú uvedené v prílohe P.

Existuje dokument RFC, ktorý podrobne popisuje protokol syslog, vo všeobecnosti môže byť činnosť kolektorového modulu syslog znázornená nasledujúcou schémou

Ryža. 4.6 - Schéma fungovania modulu na zber systémových logov

Na klientskom hostiteľovi si každá jednotlivá aplikácia zapisuje svoj vlastný protokol udalostí, čím tvorí zdroj. Ďalej tok správ pre protokoly prechádza určením miesta uloženia, potom sa pomocou filtrov určí jeho sieťový smer, po ktorom sa po príchode na protokolovací server znova určí miesto uloženia pre každú správu. Vybraný modul je vysoko škálovateľný a vysoko konfigurovateľný, napríklad filtre môžu byť rozvetvené tak, že správy o systémových udalostiach sa odosielajú vo viacerých smeroch v závislosti od viacerých podmienok, ako je znázornené na obrázku nižšie.

Ryža. 4.7 - Rozvetvenie filtra

Škálovateľnosť znamená, že na rozloženie záťaže správca nasadí sieť pomocných filtrovacích serverov, takzvaných relé.

Ryža. 4.8 - Škálovanie a vyrovnávanie záťaže

V konečnom dôsledku najjednoduchším spôsobom možno činnosť modulu opísať takto - klientski hostitelia prenášajú správy z protokolov udalostí rôznych aplikácií na vykladacie servery, ktoré ich zase môžu prenášať v reťazci prenosu atď. centrálne zberné servery.

Ryža. 4.9 - Zovšeobecnená schéma činnosti modulu

V našom prípade tok dát nie je taký veľký, aby sme nasadili systém vykladacích serverov, preto bolo rozhodnuté použiť zjednodušenú schému prevádzky klient-server.

Ryža. 4.10 - Prijatá schéma práce

5. PRÍRUČKA SPRÁVCA SYSTÉMU

Vo všeobecnosti sa správcovi systému odporúča dodržiavať existujúcu hierarchiu konfiguračných súborov a adresárov. Pridávanie nových hostiteľov a služieb do monitorovacieho systému spočíva vo vytváraní nových konfiguračných súborov a inicializačných skriptov, ako je uvedené v časti 5 - Vývoj softvéru, takže nemá zmysel znovu popisovať parametre a princípy konfigurácie systému v tejto práci, ale stojí za to sa pozastaviť nad detailnejším popisom rozhraní jednotlivých modulov systému.

5.1 Popis webového rozhrania systému

Pre interaktívny monitoring služieb bolo výhodnejšie integrovať do systému webové rozhranie. Webové rozhranie je dobré aj preto, že prostredníctvom šikovného používania grafických nástrojov a poskytovania ďalších štatistických informácií poskytuje ucelený obraz o systéme.

Keď sa prihlásite na webovú stránku Nagios, požiada vás o zadanie používateľského mena a hesla, ktoré sme nastavili počas procesu nastavenia. Úvodná stránka webového rozhrania je znázornená na obrázku nižšie.

Ryža. 5.1 - Úvodná stránka webového rozhrania systému

Na ľavej strane je navigačná lišta, vpravo vedie k rôznym zobrazeniam údajov o stave siete, hostiteľa a služby. Nás bude zaujímať predovšetkým sekcia Monitoring. Pozrime sa na stránku taktického prehľadu.

Ryža. 5.2 - Úvodná stránka webového rozhrania systému

Táto stránka obsahuje súhrnné informácie o všetkých parametroch monitorovania a stave hostiteľov a služieb, pričom nie sú uvedené žiadne podrobnosti, ak sa však vyskytnú nejaké problémy, sú zvýraznené špeciálnou farbou a stanú sa hypertextovým odkazom vedúcim k Detailný popis problém, ktorý nastal. V našom prípade je momentálne jeden nevyriešený problém medzi všetkými hostiteľmi a službami, nasledujme tento odkaz (1 Unhandled Problems).

Ryža. 5.3 - Zistený servisný problém

Tu v tabuľkovej forme sledujeme, na ktorom hostiteľovi sa problém vyskytol, aká služba ho spôsobila (v našom prípade ide o vysoké zaťaženie procesora na routeri), chybový stav (môže byť normálny, prahový a kritický), čas posledná kontrola, trvanie prítomnosti problému, číslo kontroly na účte v slučke a podrobné informácie s konkrétnymi hodnotami vrátenými použitým doplnkom.

Ryža. 5.4 - Podrobný popis stavu služby

Tu vidíme úplný popis problému, táto stránka je užitočná na hĺbkovú analýzu problému, keď príčina jeho výskytu nie je úplne jasná, napríklad môže byť v príliš striktne nastavenom kritickom stave alebo nesprávne nastavené spustenie pluginu parametre, ktoré systém taktiež vyhodnotí ako kritický stav. Okrem popisu je z tejto stránky možné vykonávať príkazy v službe, ako napríklad zakázať kontroly, naplánovať iný čas ďalšej kontroly, pasívne prijímať údaje, prijať problém na kontrolu, vypnúť upozornenia, odoslať manuálne upozornenie, naplánujte vypnutie služby, vypnite detekciu nestabilného stavu a napíšte komentár.

Poďme na stránku Podrobnosti o službe.

Ryža. 5.5 - Detailný pohľad na všetky služby

Tu vidíme zoznam všetkých hostiteľov a služieb bez ohľadu na ich aktuálny stav. Táto funkcia môže byť užitočná, ale prehľadávanie dlhého zoznamu hostiteľov a služieb nie je príliš pohodlné a je potrebné skôr na vizualizáciu množstva práce, ktorú systém z času na čas vykonáva. Tu je každý hostiteľ a služba, ako na obrázku 6.3, odkazom vedúcim k podrobnejšiemu popisu parametra.

Ryža. 5.6 - Kompletný podrobný zoznam hostiteľov

Táto tabuľka poskytuje úplný podrobný zoznam hostiteľov, ich stavy, čas poslednej kontroly, trvanie aktuálneho stavu a ďalšie informácie. V našom systéme sa akceptuje, že stav hostiteľa sa kontroluje pomocou kontroly dosiahnuteľnosti hostiteľa ICMP (8), teda príkazom ping, ale vo všeobecnosti môže byť kontrola akákoľvek. Ikony v stĺpci napravo od názvu hostiteľa označujú skupinu, do ktorej patrí, to sa robí pre pohodlie vnímania informácií. Ikona semaforu je odkaz vedúci na podrobný zoznam služieb pre tohto hostiteľa, túto tabuľku nemá zmysel popisovať samostatne, je úplne rovnaká ako na obrázku 10.4, len sú uvedené informácie o jednom hostiteľovi.

Nasledujúce odkazy v zozname sú rôznymi modifikáciami predchádzajúcich tabuliek a nebude ťažké pochopiť ich obsah. Najzaujímavejšou vlastnosťou webového rozhrania je možnosť zostavenia mapy siete v poloautomatickom režime.

Ryža. 5.7 - Kompletná kruhová mapa siete

Prostredníctvom nadradeného parametra každého hostiteľa a služby môžeme vytvoriť štruktúru alebo hierarchiu našej siete, ktorá bude určovať logiku sieťového monitorovacieho enginu a zastúpenie hostiteľov a služieb na mape siete. Režimov zobrazenia je niekoľko, okrem kruhového je najpohodlnejší režim vyváženého stromu a sférický.

Ryža. 5.8 - Mapa siete - Režim B-strom

Ryža. 5.9 - Mapa siete - guľový režim

Vo všetkých režimoch je obrázok každého hostiteľa odkazom na tabuľku služieb a ich stavov.

Ďalšou dôležitou súčasťou rozhrania monitorovacieho jadra je tvorca trendov. S jeho pomocou môžete naplánovať výmenu zariadení za produktívnejšie, uvedieme príklad. Kliknite na odkaz Trendy. Vyberte typ správy - služba.

Krok 1: Vyberte typ správy: Služba

Tretím krokom je výber obdobia počítania a vygenerovanie správy.

Ryža. 5.10 - Trend

Vygenerovali sme trend zaťaženia CPU pri smerovaní. Dá sa z nej usúdiť, že v priebehu mesiaca sa tento parameter neustále zhoršuje a je potrebné už teraz prijať opatrenia na optimalizáciu prevádzky hostiteľa alebo sa pripraviť na jeho výmenu za produktívnejšie.

5.2 Popis webového rozhrania modulu na sledovanie načítania rozhraní

Webové rozhranie modulu na sledovanie zaťaženia rozhrania je zoznam adresárov, ktoré obsahujú indexové stránky sledovaných hostiteľov s plánmi zaťaženia pre každé rozhranie.

Ryža. 5.11 - Úvodná stránka modulu sledovania zaťaženia rozhrania

Kliknutím na ktorýkoľvek z odkazov získame plány sťahovania. Každý graf je odkaz vedúci na štatistiky za týždeň, mesiac a rok.

5.3 Popis modulu na zber systémových protokolov udalostí

Momentálne nie je potrebné vylepšené filtrovanie systémových protokolov a možnosť prehľadávať ich cez jediné webové rozhranie, pretože. problémy vyžadujúce prezeranie týchto protokolov sú zriedkavé. Preto bol vývoj databázy pre tieto časopisy a webového rozhrania odložený. V súčasnosti sa k nim pristupuje cez ssh a prehliadanie adresárov Správca súborov mc .

Ako výsledok práce tohto modulu sme dostali nasledujúcu adresárovú štruktúru:

├── Apache2

├── hviezdička

├── bgp_router

├── dbconfig-common

├── inštalačný program

│ └── cdebconf

├── len58a_3lvl

├── monitorovanie

├── nagios3

│ └── archívy

├── ocsinventár-klient

├── server zásobovania

├── kvaga

├── router_krivous36b

├── router_lenina58a

├── router_su

├── router_ur39a

├── tvarovač

├── ub13_router

├── univer11_router

└── voip

Každý adresár je úložiskom protokolov udalostí pre každého jednotlivého hostiteľa.

Ryža. 5.13 - Prezeranie údajov zhromaždených modulom zberu denníka udalostí systému

6. TESTOVANIE PRÁCE

Počas implementácie systému sa postupne testovalo fungovanie jednotlivých komponentov, počnúc od jadra systému. Rozšírenie funkcionality bolo realizované až po finálnej úprave nižších hierarchických úrovní modulov sieťového monitorovacieho systému z dôvodu mnohých závislostí rôznych subsystémov. Vo všeobecnosti možno krok za krokom proces implementácie a testovania opísať takto:

) Inštalácia a ladenie jadra založeného na Nagios;

) Nastavenie monitorovania vzdialených hostiteľov základná funkčnosť Nagios;

) Úprava modulu pre sledovanie zaťaženia sieťových rozhraní pomocou MRTG;

) Rozšírenie funkčnosti jadra systému a jeho integrácia s modulom MRTG;

) Nastavenie modulu na zber systémových protokolov;

) Napísanie skriptu na inicializáciu paketového filtra monitorovacieho systému s cieľom zabezpečiť bezpečnosť systému.

7. Informačná bezpečnosť

1 Charakteristika pracoviska

Medzi škodlivé faktory ovplyvňujúce prácu pri používaní počítača patria:

· zvýšená hodnota napätia elektrického prúdu;

· hluk;

· elektromagnetická radiácia;

· elektrostatické pole.

Pre zabezpečenie najlepších podmienok pre efektívnu a bezpečnú prácu je potrebné vytvárať také pracovné podmienky, ktoré budú pohodlné a minimalizujú vplyv týchto škodlivých faktorov. Je potrebné, aby uvedené škodlivé faktory boli v súlade so stanovenými pravidlami a predpismi.

7.2 Bezpečnosť práce

2.1 Elektrická bezpečnosť

Navrhnutý softvérový nástroj je navrhnutý pre prácu na existujúcom serveri umiestnenom v špeciálne vybavenej technickej miestnosti. Je vybavená káblovodmi na vedenie káblov. Každý server je napájaný ~ 220V, frekvencia 50Hz, s funkčným uzemnením. Pred vstupom do napájacieho zdroja do miestnosti sú nainštalované automatické spínače, ktoré vypnú napájanie v prípade skratu. Samostatné ochranné uzemnenie.

Pri pripájaní počítača je nutné pripojiť skriňu zariadenia na ochranný uzemňovací vodič tak, aby v prípade poruchy izolácie alebo z iného dôvodu nemohlo pri dotyku osoby so skriňou zariadenia vzniknúť nebezpečné napätie napájacieho zdroja. nebezpečný prúd cez ľudské telo.

Na to sa používa tretí kontakt v elektrických zásuvkách, ktorý je pripojený k ochrannému uzemňovaciemu jadru. Puzdrá zariadenia sú uzemnené cez napájací kábel pozdĺž špeciálne určeného vodiča.

Na ochranu pred poškodením sa prijímajú technické opatrenia elektrický šok pri dotyku telesa elektroinštalácie v prípade poruchy izolácie častí pod prúdom, medzi ktoré patria:

· ochranné uzemnenie;

· ochranné nulovanie;

· ochranné vypnutie.

7.2.2 Ochrana proti hluku

Štúdie ukazujú, že v hlučných podmienkach sú primárne ovplyvnené sluchové funkcie. Vplyv hluku sa však neobmedzuje len na vplyv na sluch. Spôsobuje citeľné posuny v rade fyziologických mentálnych funkcií. Hluk nepriaznivo ovplyvňuje nervový systém a znižuje rýchlosť a presnosť senzomotorických procesov, zvyšuje sa počet chýb pri riešení intelektuálnych problémov. Hluk má citeľný vplyv na pozornosť človeka a spôsobuje negatívne emócie.

Hlavným zdrojom hluku v priestoroch, kde sa nachádzajú počítače, sú klimatizačné zariadenia, tlačové a kopírovacie zariadenia a v samotných počítačoch ventilátory chladiaceho systému.

Vo výrobnej miestnosti sa aktívne používajú tieto opatrenia na kontrolu hluku:

· použitie mechanizmov tichého chladenia;

· izolácia zdrojov hluku od okolia pomocou zvukovej izolácie a absorpcie zvuku;

· použitie materiálov pohlcujúcich zvuk na vnútorné obklady.

Na pracovisku sa vyskytujú tieto zdroje hluku:

· systémová jednotka (chladič (25dB), pevný disk (29dB), napájací zdroj (20dB));

· tlačiareň (49dB) .

Celkový hluk L emitovaný týmito zariadeniami sa vypočíta podľa vzorca:

kde Li je hladina hluku jedného zariadenia, dB= 10*lg(316,23+794,33+100+79432,82) = 10*4,91 = 49,1dB

Podľa SN 2.2.4 / 2.1.8.562-96 by hladina hluku na pracovisku matematikov-programátorov a videooperátorov nemala presiahnuť 50 dB.

7.2.3 Ochrana pred elektromagnetickým žiarením

Ochranu pred elektromagnetickým rušením zabezpečujú obrazovky s elektricky vodivým povrchom a použitie monitorov vybavených systémom Low Radiation, ktorý minimalizuje úroveň škodlivého žiarenia, ako aj monitory z tekutých kryštálov, v ktorých elektromagnetické žiarenie úplne chýba.

7.2.4 Elektrostatická ochrana

Na ochranu pred elektrostatickým nábojom sa používa uzemnený ochranný filter, zvlhčovače vzduchu, podlahy sú pokryté antistatickým náterom. Na udržanie normalizovaných hodnôt koncentrácie kladných a záporných iónov v priestoroch s počítačmi sú nainštalované klimatizácie, zariadenia na ionizáciu vzduchu a po každých 2 hodinách prevádzky sa vykonáva prirodzené vetranie najmenej 10 minút.

Aby sa predišlo škodlivým účinkom prachových častíc so vzduchom prenášanými časticami na telo pracujúcich ľudí, mokré čistenie priestorov sa vykonáva denne a prach sa odstraňuje z obrazoviek aspoň raz za zmenu, keď je monitor vypnutý.

7.3 Pracovné podmienky

3.1 Mikroklíma výrobnej miestnosti

Zariadenia uvažované v tomto projekte počas prevádzky neprodukujú žiadne škodlivé látky. Vzduchové prostredie v miestnosti, kde sa používajú, teda nemá škodlivé účinky na ľudský organizmus a spĺňa požiadavky kategórie I práce podľa GOST 12.1.005-88.

Optimálne normy pre teplotu, relatívnu vlhkosť a rýchlosť vzduchu v pracovnom priestore priemyselných priestorov sú štandardizované GOST 12.1.005-88 a sú uvedené v tabuľke 7.1.

Tabuľka 7.1 - Parametre mikroklímy

Normalizovaný parameterHodnotaOptimalPrípustnáSkutočná teplota vzduchu, С20 - 2218 - 2020Vlhkosť,% 40 - 60Nie viac ako 8045Rýchlosť vzduchu, m/s0.20.30..0.3

Mikroklíma zodpovedá optimálnym podmienkam.

3.2 Priemyselné osvetlenie

Na výpočet vyberáme oddelenie podpory spoločnosti Gerkon LLC v meste Verkhnyaya Pyshma, kde bol tento projekt vyvinutý:

· plocha miestnosti je 60 m2;

· plocha svetelných otvorov je 10 m2;

· Boli nainštalované 4 pracovné stanice.

Výpočet prirodzeného osvetlenia sa vykonáva podľa vzorca SNiP 23.05-95:

S0 \u003d Sp * en * Kz * N0 * KZD / 100 % * T0 * T1 (7.2)

Kde S0 je plocha svetelných otvorov, m2;

Sp - podlahová plocha miestnosti, m2, 60;

sk - koeficient prirodzeného osvetlenia, 1,6;

Kz - bezpečnostný faktor, 1,5;

N0 - svetelná charakteristika okien, 1;

KZD - koeficient zohľadňujúci zatemnenie okien protiľahlými budovami, 1,2;

T0 - celkový koeficient priepustnosti svetla, 0,48;

T1 - koeficient odrazu od povrchu miestnosti, 1.2.

Hodnoty všetkých koeficientov sú prevzaté z SNiP 23.05.-95.

Výsledkom výpočtu je: požadovaná plocha svetelných otvorov okien S0 = 3,4 m2. Skutočná plocha otvorov je 10 m2, čo presahuje minimálnu povolenú plochu svetelných otvorov pre priestory tohto typu a postačuje počas denného svetla.

Výpočet umelého osvetlenia miestnosti osvetlenej 15 žiarivkami typu LDC-60 s výkonom 60 W každá.

Podľa SNiP 23.05-95 musí byť množstvo osvetlenia žiarivkami najmenej 300 lm v horizontálnej rovine - pre všeobecný osvetľovací systém. S prihliadnutím na vysoko presnú vizuálnu prácu možno hodnotu osvetlenia zvýšiť až na 1000 lm.

Svetelný tok fluorescenčná lampa vypočítané podľa vzorca z SNiP 23.05.-95:

Phi = Yong * S * Z * K / N * η (7.3)

kde En - normalizované osvetlenie miestnosti, lx, 200;

S - podlahová plocha miestnosti, m2, 60;

Z - koeficient zohľadňujúci pomer priemerného osvetlenia k minimu, 1,1;

K - bezpečnostný faktor zohľadňujúci znečistenie ovzdušia, 1,3;

N - počet svietidiel, 15;

η - faktor využitia svetelného toku, 0,8.

Výsledkom je Phi = 1340lm, celkový svetelný tok všetkých lámp je 3740lm, teda osvetlenie laboratória je nad minimom prípustným.

7.4 Ergonómia pracoviska

4.1 Organizácia pracoviska

V súlade so SanPiN 2.2.2 / 4.2.1340-03 musí VDT (video zobrazovací terminál) spĺňať nasledujúce technické požiadavky:

· jas osvetlenia nie menej ako 100 cd/m2;

· minimálna veľkosť svetelného bodu nie je väčšia ako 0,1 mm pre farebný displej;

· kontrast obrazu znaku nie je menší ako 0,8;

· vertikálna skenovacia frekvencia nie menšia ako 7 kHz

· počet bodov nie je nižší ako 640;

· antireflexná vrstva obrazovky;

· veľkosť obrazovky nie menšia ako 31 cm diagonálne;

· výška znakov na obrazovke nie je menšia ako 3,8 mm;

· vzdialenosť od očí operátora k obrazovke by mala byť približne 40-80 cm;

VDT by mal byť vybavený otočným stolom, ktorý vám umožní pohybovať sa v horizontálnej a vertikálnej rovine v rozsahu 130-220 mm a meniť uhol obrazovky o 10-15 stupňov.

Promočný projekt bol realizovaný na počítači s VDT ViewSonic s uhlopriečkou 39 cm. Tento monitor je vyrobený v súlade s medzinárodnými normami a spĺňa všetky vyššie uvedené technické požiadavky.

Požiadavky na klávesnicu sú nasledovné:

· maľovanie puzdier v upokojujúcich jemných tónoch s rozptýleným rozptylom svetla;

· matný povrch s odrazivosťou 0,4 - 0,6 a bez lesklých detailov, ktoré môžu vytvárať odlesky;

Projekt bol realizovaný na klávesnici značky Logitech, ktorá spĺňa všetky vyššie uvedené požiadavky.

Systémové bloky sú inštalované na pracovisku s ohľadom na ľahký prístup k disketovým mechanikám a pohodlný prístup ku konektorom a ovládacím prvkom na zadnej strane. Často používané diskety sú uložené v blízkosti systémovej jednotky v prachovej a elektromagneticky chránenej bunke. Tlačiareň je umiestnená napravo od používateľa. Vytlačený text vidí operátor, keď je v hlavnej pracovnej polohe. Špeciálne priehradky ukladajú prázdny papier a ďalšie nevyhnutné spotrebné materiály v blízkosti tlačiarne.

Spojovacie káble sú uložené v špeciálnych kanáloch. Usporiadanie kanálov musí byť také, aby konektory neprekážali pri vyťahovaní káblov.

Pre manipulátor „myš“ napravo od používateľa na pracovnej doske je voľná plocha, ktorá by mala byť tvarom a veľkosťou identická s povrchom obrazovky.

Pracovisko operátora vyhovuje požiadavkám GOST 12.2.032-78 SSBT.

Priestorové usporiadanie pracoviska poskytuje optimálnu pracovnú polohu:

· hlava naklonená dopredu o 10 - 20 stupňov;

· chrbát má dôraz, pomer medzi ramenom a predlaktím, ako aj medzi stehnom a predkolením je pravý uhol.

Hlavné parametre pracoviska musia byť nastaviteľné. Tým je zabezpečená možnosť vytvorenia priaznivých pracovných podmienok pre jednotlivca s prihliadnutím na geoantropometrické charakteristiky.

Hlavné parametre pracoviska a nábytku vybaveného osobným počítačom (obr. 7.1)

Ryža. 7.1 - Pracovisko obsluhy počítača

· výška sedadla 42 - 45 cm;

· výška klávesnice od podlahy 70 - 85 cm;

· uhol klávesnice od horizontály 7 - 15 stupňov;

· vzdialenosť klávesnice od hrany stola 10 - 26 cm;

· vzdialenosť od stredu obrazovky k podlahe 90 - 115 cm;

· uhol sklonu obrazovky od vertikály 0 - 30 stupňov (optimálne 15);

· vzdialenosť obrazovky od okraja stola 50 - 75 cm;

· výška pracovnej plochy na písanie 74 - 78cm;

Na pracovisku je k dispozícii opierka nôh, odporúčaná pre všetky typy prác súvisiacich s dlhodobým sedením

Podľa SanPiN 2.2.2.542-96 sa povaha práce počítačového operátora považuje za ľahkú a patrí do kategórie 1A.

Prestávky sa stanovujú po 2 hodinách od začiatku pracovnej zmeny a 2 hodinách po obedňajšej prestávke v dĺžke 15 minút. Počas regulovaných prestávok, aby sa znížil neuro-emocionálny stres, únava a eliminoval vplyv hypodynamie, sa vykonávajú sady cvičení.

7.5 Požiarna bezpečnosť

Miestnosť, kde sa práce na tomto projekte vykonávali, má kategóriu požiarneho nebezpečenstva V NPB 105-03 - horľavé a nehorľavé kvapaliny, tuhé horľavé a nehorľavé látky a materiály vrátane prachu a vlákien, látky a materiály schopné vzájomného pôsobenia s vodou, kyslíkovým vzduchom alebo medzi sebou iba horia za predpokladu, že priestory, v ktorých sú k dispozícii alebo vytvorené, nepatria do kategórie A alebo B. Budova pre priestory I. stupňa požiarnej odolnosti podľa SNiP 21-01-97 .

Vo výrobnom priestore sa dodržiavajú nasledujúce bezpečnostné pravidlá:

· priechody, východy z priestorov, prístup k hasiacim prostriedkom sú voľné;

· prevádzkované zariadenie je v dobrom prevádzkovom stave a pred začatím práce sa kontroluje;

· po ukončení prác sú priestory skontrolované, napájanie je odpojené, priestory sú uzavreté.

Počet evakuačných východov z budov z areálu je dva. Šírka núdzového východu (dverí) je 2m. Únikové cesty využívajú konvenčné rebríky a krídlové dvere. Na schodiskách nie sú žiadne miestnosti, technologické komunikácie, východy výťahov a nákladných výťahov. Únikové cesty sú vybavené prirodzeným aj umelým núdzovým osvetlením.

Primárnym hasiacim prostriedkom v miestnosti sú ručné hasiace prístroje s oxidom uhličitým v počte dva v miestnosti.

Na zistenie počiatočného štádia požiaru a varovanie hasičského zboru sa používa automatický a požiarny poplachový systém (APS). Nezávisle aktivuje hasiace zariadenia, kým požiar nedosiahne veľkú veľkosť, a upozorní mestský hasičský zbor.

Objekty ES, okrem APS, musia byť vybavené stacionárnymi hasiacimi zariadeniami. Aplikácie plynových hasiacich zariadení, ktorých činnosť je založená na rýchlom naplnení miestnosti hasiacou plynnou látkou, v dôsledku čoho klesá obsah kyslíka vo vzduchu.

7.6 Núdzové situácie

V podmienkach tejto miestnosti s najväčšou pravdepodobnosťou pohotovosť môže dôjsť k požiaru. V prípade požiaru je potrebné evakuovať personál a udalosť nahlásiť hasičom. Plán evakuácie je znázornený na obrázku 7.2.

Ryža. 7.2 - Plán požiarneho úniku

8. EKONOMICKÁ ČASŤ

Táto časť pojednáva o nákladoch na vývoj sieťového monitorovacieho systému, jeho implementáciu a údržbu, ako aj súvisiace materiály a zariadenia.

Náklady na projekt odrážajú náklady na prostriedky a predmety práce spotrebované v procese vývoja a výroby (odpisy, náklady na zariadenia, materiál, palivo, energiu atď.), časť nákladov na životnú prácu (mzdy) , náklady na zakúpené systémové moduly.

V procese aktivity a zvyšovania objemu dodávok služieb vznikol problém proaktívneho odhaľovania chybných a slabých miest v organizácii siete, teda úlohou bolo implementovať riešenie, ktoré by umožnilo predpovedať potrebu výmeny alebo modernizácie. časti siete predtým, než poruchy ovplyvnia činnosť účastníckych uzlov.

S rastom klientskej základne a v dôsledku toho aj počtu aktívnych zariadení bolo potrebné rýchlo detailne sledovať stav siete ako celku a jej jednotlivých prvkov. Pred zavedením systému monitorovania siete sa musel správca siete pripojiť pomocou protokolov telnet, http, snmp, ssh atď. do každého uzla siete, ktorý vás zaujíma, a použite vstavané monitorovacie a diagnostické nástroje. V súčasnosti je kapacita siete 5000 portov, 300 prepínačov Layer 2, 15 smerovačov a 20 interných serverov.

Okrem toho sa preťaženie siete a občasné poruchy odhalili len vtedy, keď sa vyskytli vážne problémy používateľov, čo bránilo plánom na modernizáciu siete.

To všetko viedlo v prvom rade k neustálemu zhoršovaniu kvality ponúkaných služieb a zvyšovaniu záťaže správcov systému a technickej podpory používateľov, čo prinieslo obrovské straty.

V súlade so súčasnou situáciou bolo rozhodnuté vyvinúť a implementovať sieťový monitorovací systém, ktorý by vyriešil všetky vyššie uvedené problémy, ktoré možno zhrnúť takto:

Je potrebné vyvinúť a implementovať monitorovací systém, ktorý umožní monitorovanie prepínačov, smerovačov od rôznych výrobcov a serverov z rôznych platforiem. Zamerať sa na využívanie otvorených protokolov a systémov, s maximálnym využitím hotového vývoja z fondu slobodného softvéru, čo z ekonomického hľadiska znižuje náklady na licencovanie finálneho systému na nulu.

Systém musí z ekonomického hľadiska spĺňať nasledujúce požiadavky:

· minimálne požiadavky na hardvérové ​​zdroje (vedie k nižším nákladom na hardvérovú časť projektu);

· otvorené zdrojové kódy všetkých komponentov komplexu (umožňuje vám nezávisle meniť princíp systému bez toho, aby ste sa uchýlili k vývoju tretích strán a znižujú náklady na licencovanie produktov);

· rozšíriteľnosť a škálovateľnosť systému (umožňuje rozšíriť rozsah aplikácie bez toho, aby ste sa uchýlili k vývoju tretích strán a proprietárnemu vývoju, a znižuje náklady na licencovanie produktov);

· štandardné prostriedky poskytovania diagnostických informácií (umožňujú vám znížiť náklady na údržbu systému);

· dostupnosť podrobnej dokumentácie pre všetky používané softvérové ​​produkty (umožňuje rýchle zaškolenie nového zamestnanca);

· schopnosť pracovať so zariadeniami od rôznych výrobcov (umožňuje používať jeden softvérový produkt). (Úplný zoznam vybavenia nájdete v prílohe B).

Vo všeobecnosti vývoj projektu trval 112 hodín (2 týždne). Realizácia tohto projektu bude trvať 56 hodín (1 týždeň).

1 Výpočet nákladov na vývoj projektu

Náklady na vývoj projektu pozostávajú z:

· mzdové náklady;

· náklady na odpisy zariadení a softvérových produktov;

· náklady na elektrickú energiu;

· nad hlavou.

Výdavky na mzdy.

Pri kalkulácii mzdových nákladov berieme do úvahy, že tento projekt vypracovala jedna osoba: systémový inžinier.

Priemerný trhový plat systémového inžiniera požadovanej úrovne v regióne je 30 000 rubľov.

Vypočítajme si cenu 1 hodiny práce inžiniera na základe nasledujúcich údajov:

· prémia 25 %;

· okresný koeficient 15 %;

· fond pracovného času v roku 2010 podľa výrobného kalendára je 1988 hodín;

Sadzba teda pri zohľadnení regionálneho koeficientu bude:

RF \u003d 30 000 * 1,25 * 1,15 * 12 / 1988 \u003d 260 rubľov

Výpočet mzdových nákladov zohľadňuje zrážky vyplatené z časovo rozlíšených miezd, to znamená, že celková výška sadzby poistného sa bude rovnať maximálnej sadzbe UST - 26% vrátane:

· PFR - 20 %;

· FSSR – 2,9 %

· FFOMS - 1,1 %;

· GFOMS - 2 %;

· Povinné sociálne úrazové poistenie - 0,2 %.

Celkové odpočty budú:

CO \u003d RF * 0,262 \u003d 260 * 0,262 \u003d 68 rubľov

S prihliadnutím na pracovný čas inžiniera (112 hodín na vývoj a 56 hodín na implementáciu) vypočítame mzdové náklady:

ZP \u003d (112 + 56) * (RF + CO) \u003d 168 * 328 \u003d 55104 rubľov

Náklady na odpisy zariadení a softvérových produktov.

Vo fáze vývoja sieťového projektu bol ako hlavné zariadenie použitý osobný počítač a server AQUARIUS SERVER T40 S41. Cena počítača je v súčasnosti približne 17 000 rubľov, zatiaľ čo server je 30 000 rubľov.

Náklady na jednorazovú investíciu do zariadenia teda budú:

PBA = 47 000 rubľov

Počas životnosti počítača a servera je povolený ich upgrade, tento typ nákladov je tiež zohľadnený pri kalkulácii. 50% RV položíme na modernizáciu:

RMA \u003d PB * 0,5 \u003d 23500 rubľov

Počítač bol použitý v nasledujúcich krokoch:

· vyhľadávanie literatúry;

· hľadanie riešení pre návrh sieťového monitorovacieho systému;

· vývoj štruktúr a subsystémov;

· navrhovanie systému monitorovania siete;

· formátovanie dokumentu.

Server bol použitý pri implementácii systému a priamej práci so systémom.

Softvérové ​​produkty použité pri vývoji sú získané na základe bezplatných licencií, čo znamená, že ich cena je nulová a nie je potrebné ich odpisovať.

Celkové náklady na vybavenie, berúc do úvahy odpisy, teda budú:

OZA \u003d PVA + RMA \u003d 47000 + 23500 \u003d 70500 rubľov

Predpokladaná životnosť je 2 roky. Cena jednej hodiny práce je (za predpokladu počtu pracovných dní v mesiaci 22 a pri 8-hodinovom pracovnom dni):

SOCHR \u003d OZA / VR \u003d 70500 / 4224 \u003d 16,69 rubľov

V čase vývoja a implementácie budú náklady na odpočty odpisov, resp.

SACHRV \u003d SOCHR * TRV \u003d 16,69 * 168 \u003d 2803,92 rubľov

Náklady na elektrinu.

Náklady na elektrickú energiu sú súčtom nákladov spotrebovaných počítačom a nákladov vynaložených na osvetlenie. Náklady na elektrinu:

SEN \u003d 0,80 rubľov / kW * h (podľa dohody s majiteľom priestorov)

Рк,с = 200 W - výkon spotrebovaný počítačom alebo serverom.

Тrk = 168 h - čas prevádzky počítača v štádiu vývoja a implementácie systému.

Трс = 52 h - čas prevádzky servera vo fáze vývoja a implementácie systému.

Náklady na elektrickú energiu vo fáze vývoja a realizácie projektu teda budú:

SENP \u003d Rk * Trk * SEN + Rk * Trs * SEN \u003d (200 * 168 * 0,80 + 200 * 52 * 0,80) / 1 000 \u003d (26 880 + 8 320) / 1 030 \u000 rubľov

Pracovisko, kde táto práca, vybavená 100 W lampou. Vypočítajme si náklady na elektrickú energiu spotrebovanú svietidlom počas vývoja a implementácie systému:

SENO \u003d 100 * Trk * SEN \u003d (100 * 168 * 0,80) / 1000 \u003d 13,44 rubľov

Celkové náklady na elektrinu boli:

OZEN \u003d SENP + SENO \u003d 35,2 + 13,44 \u003d 48,64 rubľov

8.2 Výpočet režijných nákladov

Táto nákladová položka pokrýva náklady na ostatné zariadenia a spotrebné materiály aj nepredvídané udalosti.

Režijné náklady v rozpočte podniku predstavujú 400 % časovo rozlíšených miezd:

HP \u003d ZP * 4 \u003d 55104 * 4 \u003d 220416 rubľov.

Náklady na vývoj a realizáciu projektu teda dosiahli:

SRV = ZP + SACHRV + OZEN + HP = 55104 + 2803,92 + 48,64 + 220416 = 278372,56 rubľov

3 Účinnosť

V dôsledku vykonania ekonomických výpočtov bola minimálna cena za vývoj a implementáciu systému monitorovania siete stanovená na 278 372,56 rubľov.

Ako je zrejmé z výpočtov, prevažná väčšina nákladov na náklady pripadá na materiál a vybavenie. Vysvetľuje to skutočnosť, že hlavnými výrobcami zariadení sú zahraničné spoločnosti, a preto sú ceny týchto produktov uvedené v amerických dolároch pri sadzbe centrálnej banky Ruska + 3%. A zvýšenie ciel na dovážané produkty negatívne ovplyvňuje aj cenu pre koncových zákazníkov.

Aby sme ospravedlnili nezávislý vývoj systému, porovnajme jeho náklady s hotovými riešeniami na trhu:

· D-Link D-View - 360 000 rubľov

Aktívne sieťové vybavenie musí zabezpečiť dlhodobú a neprerušovanú prevádzku podnikovej siete. Včasné odhalenie a odstránenie porúch je kľúčom k úspešnému a efektívnemu fungovaniu spoločnosti. Preto je veľmi dôležité dávať Osobitná pozornosť monitorovací systém, ktorý by monitoroval stav aktívnych zariadení a oznamoval správcovi systému odchýlku od bežných ukazovateľov formou SMS, e-mailu alebo iným spôsobom oznamovania.

Monitorovací systém je súbor technických prostriedkov, ktoré neustále monitorujú a zbierajú informácie v lokálnej sieti na základe analýzy štatistických údajov s cieľom identifikovať chybné alebo nesprávne fungujúce uzly a upozorniť zodpovedné osoby. Funkčnosť moderných monitorovacích systémov vám umožňuje sledovať stav služieb, ako sú:

1) Dostupnosť hostiteľa

Pravidelným odosielaním ICMP Echo-Requests na adresu sieťového zariadenia

2) Dostupnosť webového servera

Odoslaním HTTP požiadavky na získanie stránky

3) Dostupnosť poštových služieb

Pravidelným odosielaním diagnostických správ SMTP

Okrem toho môžete merať čas odozvy týchto služieb.

Pravidelné kontroly tohto druhu vám umožňujú rýchlo určiť, na akej úrovni problém vznikol, a okamžite ho začať odstraňovať.

Vyššie uvedený obrázok ukazuje najjednoduchší príklad implementácie monitorovacieho systému, ktorý ovláda iba štyri zariadenia. V reálnych podmienkach môže mať aktívna flotila zariadení oveľa viac uzlov. Na vykonávanie kompetentného monitorovania sa spájajú odlišné typy hostiteľov do skupín, ako je skupina webových serverov alebo skupina smerovačov. Toto rozdelenie pomáha systematizovať štatistické informácie a uľahčuje proces pozorovania.

Väčšina monitorovacích systémov umožňuje automatizovať kontroly zariadení cez SNMP a vykonávať diagnostiku pomocou rôznych zásuvných modulov (vrátane tých manuálne vytvorených).

Protokol SNMP (Simple Network Management Protocol) – bol vytvorený špeciálne pre potreby monitorovania sieťových zariadení. Všetky aktívne zariadenia L2 a L3 obsahujú takzvanú Management Information Base (MIB), ktorá obsahuje hlavné parametre stavu zariadenia. Napríklad zaťaženie procesora, stav rozhrania, hlasitosť voľné miesto atď. Každý takýto záznam zodpovedá jedinečnému identifikátoru OID (Oject IDentifier). S požadovaným identifikátorom môžete získať informácie o parametri záujmu prostredníctvom protokolu SNMP. Moderné monitorovacie systémy umožňujú automatizovať tento proces. Systém sa pomocou protokolu SNMP pripojí k zariadeniu, požiada ho o požadované OID, prijme hodnotu parametra a porovná ju so zadanou hodnotou. Ak sa zistí nezrovnalosť medzi týmito dvoma hodnotami, monitorovací systém zareaguje a spustí proces oznamovania.

Pred priamou implementáciou monitorovacieho systému je potrebné vykonať prieskum LAN, ktorého výsledkom by mal byť zoznam monitorovaných zariadení, parametrov a schválený algoritmus pre eskaláciu monitorovacích udalostí. Na základe analýzy sieťovej infraštruktúry zákazníka vznikajú prvé riešenia, ktoré určujú architektúru budúceho monitorovacieho systému.

Ďalšou etapou je príprava špecifikácií a balíka projektovej dokumentácie s prihliadnutím na želania zákazníka.

Záverečnou fázou je škálovanie monitorovacieho systému, teda rozšírenie objemu sledovanej IT infraštruktúry na požadované zákazníka.

Implementácia monitorovacieho systému je dôležitým krokom k plnej automatizácii IT infraštruktúry, ktorá vedie k zvýšeniu efektivity jej využívania. Špecialisti našej spoločnosti opakovane vyvinuli riešenia, ktoré spĺňajú očakávania zákazníkov a už niekoľko rokov spoľahlivo fungujú.

Je pre vás tento článok užitočný?

Povedz mi, prosím, prečo?

Je nám ľúto, že článok pre vás nebol užitočný: (Ak to nie je ťažké, uveďte z akého dôvodu? Budeme veľmi vďační za podrobnú odpoveď. Ďakujeme, že nám pomáhate byť lepšími!