Správa a monitorovanie IT infraštruktúry je jednou z hlavných úloh IT oddelenia každej spoločnosti. Softvérové ​​riešenia HP zjednodušia úlohu systémových administrátorov a organizujú efektívnu kontrolu siete organizácie

Moderná IT infraštruktúra je komplexná heterogénna sieť, ktorá zahŕňa telekomunikačné, serverové a softvérové ​​riešenia od rôznych výrobcov, fungujúce na základe rôznych štandardov. Jeho komplexnosť a rozsah predurčujú vysokú úroveň automatizovaných monitorovacích a kontrolných nástrojov, ktoré je potrebné použiť na zabezpečenie spoľahlivej prevádzky siete. Softvérové ​​produkty HP vám pomôžu vyriešiť úlohy monitorovania na všetkých úrovniach, od infraštruktúry (sieťové vybavenie, servery a úložné systémy) až po kontrolu kvality obchodných služieb a obchodných procesov.

Monitorovacie systémy: čo to je?

V moderných IT monitorovacích platformách existujú 3 smery vývoja a posúvania monitoringu na novú úroveň. Prvý sa nazýva „Most“ („Umbrella System“, „Manažér manažérov“). Jeho koncepciou je využiť investície do existujúcich systémov, ktoré plnia úlohy monitorovania jednotlivých častí infraštruktúry a premeniť samotné systémy na informačných agentov. Tento prístup je logickým vývojom konvenčného monitorovania IT infraštruktúry. Predpokladom pre implementáciu systému typu Bridge je rozhodnutie IT oddelenia konsolidovať rôznorodé monitorovacie systémy prejsť na monitorovanie IT služieb / systémov ako celku, nesúrodé systémy nie sú schopné zobraziť celý obraz, prípad nediagnostiky a závažné zlyhanie aplikácie a veľký počet varovaní a alarmov, nedostatok jednotného pokrytia, určovania priorít a identifikácie príčinných súvislostí.

Výsledkom implementácie bude automatizovaný zber všetkých dostupných udalostí a metrík IT infraštruktúry, porovnanie ich stavu a vplyvu na „zdravie“ služby. V prípade poruchy bude mať operátor prístup k panelu, ktorý zobrazuje hlavnú príčinu poruchy s odporúčaniami na jej odstránenie. V prípade typickej poruchy je možné priradiť skript, ktorý automatizuje potrebné úkony operátora.

Ďalší trend sa nazýva Anamaly Analytics. Tu, ako v prvom prípade, sa metriky a udalosti zhromažďujú z množstva systémov monitorovania infraštruktúry a navyše sa konfiguruje zhromažďovanie protokolov IT a zabezpečenia. Každú minútu sa tak nahromadí obrovské množstvo informácií a spoločnosť chce z ich využitia ťažiť. Existuje niekoľko dôvodov na implementáciu analýzy anomálií: ťažkosti so zachytením, ukladaním a analýzou všetkých údajov včas, potreba reaktívneho opravovania neznámych problémov, neschopnosť rýchlo identifikovať informácie dôležité pre riešenie problémov, ťažkosti s ručným vyhľadávaním. pre jednotlivé protokoly a potrebu identifikovať odchýlky a opakujúce sa zlyhania.

Implementácia systému umožní automatizovaný zber udalostí, metrík a protokolov, uchovávanie týchto informácií na požadované časové obdobie, ako aj analýzu akýchkoľvek informácií vrátane protokolov, informácií o výkone a systémových údajov. Okrem toho bude možné predvídať a riešiť akýkoľvek typ problému a predchádzať známym zlyhaniam.

A nakoniec – „Správa výkonu aplikácií“ alebo identifikácia a odstraňovanie zlyhaní v transakciách koncových používateľov. Takéto riešenie môže byť užitočným doplnkom, ktorý pracuje v úzkom kontakte s predchádzajúcimi dvoma. Zároveň môže takýto systém sám o sebe poskytnúť rýchly výsledok implementácie. V tomto prípade má spoločnosť aplikácie, ktoré sú dôležité pre podnikanie. Zároveň je dôležitá dostupnosť a kvalita služby, ktorej jedným z kľúčových prvkov je aplikácia (Internet banking, CRM, fakturácia a pod.). Pri poklese dostupnosti alebo kvality poskytovania tejto služby ide spravidla o proaktivitu a rýchle zotavenie. Takýto systém sa zvyčajne implementuje, keď je potrebné zlepšiť dostupnosť aplikačných služieb a výkonu, ako aj skrátiť strednú dobu do obnovy. Je to dobré aj na elimináciu nákladov a rizík spojených so zmluvami o úrovni služieb (SLA) a na predchádzanie odchodu zákazníkov (ochrana podnikania).

Výsledky implementácie sa môžu líšiť v závislosti od hlavnej úlohy. Vo všeobecnom prípade to umožňuje realizáciu typických užívateľských akcií „robotom“ z rôznych regiónov/segmentov siete, analýzu „zrkadlenej“ prevádzky, kontrolu dostupnosti a kvality služieb s identifikáciou úzkych miest, informovanie operátora o potreba obnoviť výkon s uvedením miesta degradácie. V prípade potreby je možné hlboko diagnostikovať fungovanie aplikácie, aby sa našli dôvody systematického zhoršovania služieb.

Vyššie uvedené prístupy je možné implementovať pomocou softvérových produktov HP, o ktorých sa bude diskutovať neskôr.

"Bridge" od spoločnosti HP

HP Operations Bridge predstavuje najnovšiu generáciu „zastrešujúcich monitorovacích systémov“. Riešenie kombinuje monitorovacie údaje od interných agentov, rôznych modulov na monitorovanie softvéru HP a monitorovacích nástrojov tretích strán. Tok udalostí zo všetkých zdrojov informácií je superponovaný na model zdroj-služba, aplikujú sa naň korelačné mechanizmy, aby sa určilo, ktoré udalosti sú príčiny, symptómy a dôsledky.

Samostatne by sme sa mali zaoberať modelom zdrojov a služieb, presnejšie modelmi, pretože takýchto modelov na analýzu informácií z rôznych uhlov môže existovať neobmedzený počet. Od jeho úplnosti a relevantnosti závisí od schopnosti rozhodnutia vykonať koreláciu toku udalostí. Pre aktuálnosť modelov sa využívajú spravodajské nástroje založené na agentoch a bezagentových technológiách, ktoré umožňujú získať detailné informácie o zložkách služby, vzťahoch medzi nimi a vzájomnom ovplyvňovaní sa navzájom. Taktiež je možné importovať dáta topológie služby z externých zdrojov – monitorovacích systémov.

Ďalším dôležitým aspektom je jednoduchosť použitia. V zložitých a dynamicky sa meniacich prostrediach je dôležité zabezpečiť prispôsobenie monitorovacieho systému pri zmene štruktúry systémov a pridávaní nových služieb. Operations Bridge obsahuje komponent Monitoring Automation, ktorý vám umožňuje automaticky konfigurovať systémy zavedené do monitorovacieho perimetra, pre ktoré sa používajú údaje modelu služby a prostriedkov. Zároveň je podporovaná konfigurácia a úprava predtým vykonaných nastavení monitorovania.

Ak starší správcovia mohli vykonávať rovnaké nastavenia rovnakého typu komponentov infraštruktúry (napríklad metriky na serveroch Windows, Linux alebo UNIX), čo si vyžadovalo značný čas a úsilie, teraz je možné dynamicky a centrálne konfigurovať prahové hodnoty pre metrika v kontexte služby alebo služby.

Aplikačná analýza

Použitie tradičného monitorovacieho prístupu znamená, že od začiatku viete, aké parametre monitorovať a aké udalosti monitorovať. Rastúca zložitosť a dynamika rozvoja IT infraštruktúr si vyžaduje hľadanie iných prístupov, keďže je čoraz ťažšie ovládať všetky aspekty systému.

HP Operations Analytics vám umožňuje zhromažďovať a ukladať všetky údaje o prevádzke aplikácie: protokolové súbory, telemetriu, obchodné a výkonnostné metriky, systémové udalosti atď. a používať analytické nástroje na identifikáciu trendov a predpovedanie. Riešenie prináša zozbierané údaje do jednotného formátu a následne kontextovým výberom zobrazí na časovej osi na základe údajov zo súborov denníka, čo sa stalo, v akom bode a na akom systéme. Produkt poskytuje niekoľko foriem vizualizácie údajov (napríklad interaktívnu „teplotnú mapu“ a topológiu vzťahov medzi súbormi protokolov) a pomocou pomocnej funkcie nájde celý súbor údajov zozbieraných za konkrétne obdobie v kontexte udalosti resp. dotaz zadaný do vyhľadávacieho panela. To pomáha operátorovi pochopiť, čo spôsobilo zlyhanie (alebo pri použití údajov HP SHA spolu s údajmi HP OA podľa toho predvídať), ako aj identifikovať vinníka aj hlavnú príčinu zlyhania, ku ktorému došlo. HP Operations Analytics vám dáva možnosť reprodukovať obraz fungovania služby a prostredia v čase zlyhania a izolovať ho v kontexte a čase.

Ďalším analytickým nástrojom je HP Service Health Analyzer. HP SHA zisťuje anomálne správanie prvkov riadenej infraštruktúry, aby sa predišlo prípadnému odmietnutiu služieb alebo porušeniu špecifikovaných parametrov pre ich poskytovanie. Produkt využíva špeciálne algoritmy na štatistickú analýzu údajov na základe topologického modelu služby a zdrojov HP BSM. S ich pomocou je možné zostaviť profil normálnych hodnôt výkonových parametrov zozbieraných zo softvérových a hardvérových platforiem a z iných modulov BSM (napríklad HP RUM, HP BPM), ktoré charakterizujú stav služieb. V takýchto profiloch sa zadávajú typické hodnoty parametrov, berúc do úvahy dni v týždni a dennú dobu. SHA vykonáva historickú a štatistickú analýzu nahromadených údajov (na pochopenie podstaty odhalených údajov) a tiež vykonáva porovnanie s existujúcim dynamickým profilom (základná línia).

Monitorovanie výkonu aplikácie

Pokiaľ ide o monitorovanie výkonu aplikácií, je potrebné zdôrazniť nasledujúce súčasti riešenia HP:

• HP Real User Monitoring (HP RUM) - kontrola prechodu transakcií skutočných používateľov;
• HP Business Process Monitoring (HP BPM) – kontrola dostupnosti aplikácií emuláciou akcií používateľa;
• HP Diagnostics - kontrola prechodu požiadaviek v rámci aplikácie.

HP RUM a HP BPM vám umožňujú posúdiť dostupnosť aplikácie z pohľadu koncového používateľa.

HP RUM analyzuje sieťovú prevádzku a odhaľuje transakcie skutočných používateľov v nej. Zároveň môžete riadiť výmenu údajov medzi komponentmi aplikácie: klientskou časťou, aplikačným serverom a databázou. To umožňuje sledovať aktivitu používateľov, čas spracovania rôznych transakcií, ako aj určiť vzťah medzi akciami používateľov a obchodnými metrikami. Pomocou HP RUM budú môcť operátori monitorovacích služieb dostávať okamžité upozornenia o problémoch s dostupnosťou služieb a informácie o chybách, s ktorými sa používatelia stretli.

HP BPM je aktívny monitorovací nástroj, ktorý pre monitorované systémy vykonáva syntetické používateľské transakcie, ktoré sú na nerozoznanie od skutočných. Na výpočet skutočnej SLA je vhodné použiť monitorovacie údaje HP BPM, keďže „robot“ vykonáva identické kontroly v rovnakých časových intervaloch, čím poskytuje stálu kontrolu nad kvalitou spracovania typických (alebo najkritickejších) požiadaviek. Nastavením sond na vykonávanie syntetických transakcií z viacerých miest (napríklad z rôznych kancelárií spoločnosti) môžete tiež vyhodnotiť dostupnosť služby pre rôznych používateľov, berúc do úvahy ich polohu a komunikačné kanály. Na emuláciu aktivity používa HP BPM nástroj Virtual User Generator (VuGen), ktorý sa používa aj v populárnom produkte testovania záťaže HP LoadRunner. VuGen podporuje obrovské množstvo rôznych protokolov a technológií, vďaka ktorým môžete kontrolovať dostupnosť takmer akejkoľvek služby, ako aj používať jednu sadu skriptov na testovanie a monitorovanie.
Ak je príčina porúch alebo spomalenia služby vo vnútri technológií ako Java, .NET atď., HP Diagnostics pomôže.

Riešenie poskytuje hĺbkovú kontrolu nad Java, .NET, Python na platformách Windows, Linux a Unix. Produkt podporuje rôzne aplikačné servery (Tomcat, Jboss, WebLogic, Oracle atď.), MiddleWare a databázy. Vyhradení agenti HP Diagnostics sa inštalujú na aplikačné servery a zhromažďujú údaje špecifické pre technológiu. Napríklad pri aplikácii Java môžete vidieť, aké požiadavky sa robia, aké metódy sa používajú a koľko času sa strávi ich spracovaním. Štruktúra aplikácie sa nakreslí automaticky, je jasné, ako sú zapojené jej komponenty. HP Diagnostics vám umožňuje sledovať priebeh obchodných transakcií v rámci komplexných aplikácií, identifikovať úzke miesta a poskytovať odborníkom potrebné informácie na prijímanie rozhodnutí.

Distribúcia riešení HP v

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ú dobu 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 v prípade problémov posiela SMS na naše mobilné telefóny. Dospel som k záveru, že je potrebné upgradovať systém, alebo aspoň pridať efektívny nástroj, ktorý dokáže poskytnúť lepší výkon a poskytnúť 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ť/odstrániť programy, av systéme Windows Server 2008 sa súčasti SNMP pridajú 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ť si úč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 napríklad 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 spustil proces zisťovania rozsahu adries IP 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 sú: 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 pomôžu 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í).
TRIEDA: 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 programe IpMonitor mohli ovládacie 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, boli pre každé z jadier úplne rovnaké. Podobne informácie o využití pevného disku boli správne hlá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 zariadenia konkrétnych výrobcov (s výnimkou snímača pre napájacie zdroje UPS APC), na rozdiel od balíka OpManager, ktorý používa vlastné snímače pre zariadenia Dell, HP a IBM, ale umožňuje vytvárať typ Active Script senzory. 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ď sú 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; najnižšiu cenu pri kúpe 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ý.
TRIEDA: 4,5 z 5.
CENA: 1995 dolárov za 100 zariadení, 995 dolárov za 50 zariadení, 595 dolárov 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 – pekná 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 z Twitteru, chcem súčasne dostávať textové upozornenia o najdôležitejších udalostiach. Môžem zobraziť informácie o prahovej hodnote na ľubovoľnom serveri pomocou správ Twitter, a tak mať denník aktuálnych udalostí v sieti, ale nie je potrebné používať túto schému na odosielanie kritických upozornení.

Okrem štandardných senzorov ponúka 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, takže môžete svoje zariadenia pridať do mapy Google. Vyžaduje si to však zakúpenie prémiového účtu Google Maps API (pokiaľ neplánujete svoju mapu sprístupniť verejnosti) v súlade s licenčnými podmienkami pre bezplatnú verziu systému Google Maps API.

Na zvládnutie situácií, keď správca dostane upozornenie, ale určitý čas naň nereaguje, môže byť OpManager nakonfigurovaný tak, aby odoslal ďalšie upozornenie 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. Ak chcete používať nástroje na monitorovanie VoIP, zariadenia v zdrojovej aj cieľovej sieti musia podporovať technológiu Cisco IP SLA. Okrem toho rozhranie OpManager zobrazené na obrázku 2 obsahuje viac senzorov a prístrojových panelov 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.
TRIEDA: 4 z 5.
CENA: 1995 $ Neobmedzené zariadenia (25 senzorov zadarmo).
ODPORÚČANIA: ak je váš rozpočet napätý a potrebujete monitorovať veľké množstvo zariadení, ak proces monitorovania nevyžaduje komplexné riešenia a ak máte radi celosystémový prístup ku koordinácii činností administrátorov, systém SolarWinds je vašou voľbou.
KONTAKTNÉ INFORMÁCIE: solarwinds www.solarwinds.com

Po mojom prvom predstavení ipMonitor sa mi rozhranie zobrazené na obrázku 3 zdalo dosť 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 v budúcich kontrolách boli vždy zahrnuté nastavenia služby alebo výkonu. Okrem štandardných (a vyššie uvedených) senzorov ponúka ipMonitor senzor denníka udalostí systému Windows, ktorý možno použiť na odosielanie upozornení pri zistení kritických udalostí.

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 má spoločnosť jedného správcu siete, no 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 správcovia zabudnú koordinovať svoje akcie mimo systému, môže nastať situácia, že viacerí správcovia 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 správcami, 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ší. Rozhodol som sa pre systém ManageEngine OpManager s licenciou 50 zariadení 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 služieb a podpory, ktorý vám umožňuje sťahovať aktualizácie podľa vývoja produktu.

Nate McAlmond ( [chránený e-mailom]) je riaditeľkou 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;

§ Príručka správy 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

1 Systems of Sieť Monitoring220100 4010002Logic štruktúry siete220100 4010003 Algoritmové systémy monitorovania sietí a upozornenia220100 4010004 ŠTRUKTÚRA INŠTALÁCIA INŠTALÁCIA Analyzátor siete Sieťové rozhrania220100 4010005 ŠTRUKTÚRY STANDARDOVÝCH SYSTÉMOVÝCH LOGÁCIE EDACTY20100 4010007 Rozhranie Nagios20100 4010007 Publikované monitorovacie monitorovanie siete SYSTEMS220100 4010007

ZOZNAM SYMBOLOV A POJMOV

Ethernet je štandard prenosu dát vydaný IEEE. Určuje spôsob odosielania alebo prijímania ú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 Mbps 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 platformu na správu na úrovni podniku 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 predajcov.

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í ho záloha.

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 častejšie zahŕňajú 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í k prepínaným sieťam, 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 sú 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ý.

Pozrime sa na niektoré naliehavé problémy, ktoré vznikajú pre správcov podnikových sietí.

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 aspoň 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, keďže šírka pásma na jednotlivého používateľa je výrazne menš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 schopné prevádzky rýchlosťou 100 Mbps ihneď po reštarte systému, 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 preskú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 zvyčajne nereprodukujú na zrkadlovom porte 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 Capture špecifikácie RMON II, ktorá poskytuje plnohodnotnú analýzu protokolov, stále môžu vyhodnotiť využitie zdrojov, chybovosť a objem multicastu.

Niektoré z nevýhod technológie zrkadlenia portov možno prekonať inštaláciou „pasívnych odbočovačov“, ako sú tie, ktoré vyrába 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čovej siete 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á sila 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ť kúpiť optický reflektometer časovej domény (OTDR), 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. .

Hoci 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 pri správnej politike 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 zariadení, č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), prirodzene zodpovedajú úlohám tímu technickej podpory ako 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 úplný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 základnej príčiny problémov so sieťou. 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 jedného z koncových bodov alebo preťaženie verejnej internetovej zóny. Pokus použiť analyzátor protokolov na detekciu chýb vysokej úrovne v tunelovanej prevádzke by bol plytvanie námahou, 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.

Pre menej kritické systémy 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 odstraňovania 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ých zamestnancov. 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 opravovať samé. Odstraňovanie softvérových a hardvérových porúch v moderných sieťach si stále vyžaduje ľudský zásah a v krátkodobom horizonte sa v tomto stave nepredpokladajú žiadne zásadné zmeny. Diagnostické metódy a nástroje sú celkom v súlade s modernými postupmi a technológiami, no 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 deficitmi.

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 správy 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ť jednoduchú 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ť iba 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 je potrebné 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:

Použí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äť. Pufre 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 aktuálne nepotrebných paketov.

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 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čítava 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, prevádzať 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 protokolov WAN, "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. Veľmi dôležitý je súbor servisných funkcií analyzátora. 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 na 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 premennej a popis) sú opísané v riadiacich informačných bázach (MIB).

V súčasnosti 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 RMON sa SNMP nedalo používať na diaľku, umožňovalo iba lokálnu správu zariadení. RMON MIB má vylepšenú sadu vlastností pre vzdialenú správu, pretože obsahuje agregované informácie o zariadení, čo si 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ú väčšinu 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 dostatočné výpočtové zdroje 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. Záujem o túto technológiu zo strany veľkých výrobcov sieťových zariadení opäť ukazuje, aké nevyhnutné je vzdialené monitorovanie pre používateľov.) Väčšina Rozhodnutie vkladanie modulov RMON do rozbočovačov vyzerá prirodzene, 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ä tým, že vstavané sondy často nepodporujú 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 so softvérovým agentom RMON nainštalovaným na nich. 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á priradené číslo 16 v sade objektov MIB 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 vzťahovať na rôzne veci – akýkoľvek 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é poplachovým signálom - zabráni sa tak generovaniu signálu „za nič“, čo je zlé, po prvé preto, že nikto nevenuje pozornosť neustálemu horeniu červené 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 o intenzite 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á takpovediac 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 vopred určeným spôsobom reagovať.

PacketCapture - podmienky pre zachytávanie paketov. Skupina zachytávania paketov zahŕňa 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 zachytá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 aplikácie na správu, 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 od administrátora požiadavky na vykonanie akejkoľvek akcie (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 prezentovať š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čnú robiť chyby a zaberú 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 od 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, 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. Prevádzka akejkoľvek riadiacej platformy 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 veľmi výkonné procesory a veľa pamäte 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 poskytovania 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 doplnkov a možnosť ich rýchleho a jednoduchého vytvárania;

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

§ plnohodnotné webové rozhranie;

§ možnosť distribuovaného monitorovania;

§ inventár prostredníctvom pluginu;

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

§ GPL licencia, 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.

Monitorovací systém 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, že Nagios je medzi používateľmi najbežnejší, čo znamená prítomnosť dokumentácie napísanej používateľom 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 spustia, 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 pozastavenú 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žiť ktorý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 s prihliadnutím na 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, s používaním tohto systému sú bohaté skúsenosti, 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 návrh systému monitorovania siete. (Celý názov je GNU / Linux, vyslovuje sa „gnu lomka ́ 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žniciam a systémovým programom, ktoré sú preň zostavené, vyvinuté ako súčasť projekt GNU./ Linux beží na systémoch kompatibilných s PC z rodiny Intel x86, ako aj 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ícok projektov. Niektoré z týchto projektov sú centralizované, niektoré sú sústredené vo firmách. Mnoho projektov spája hackerov z celého sveta, ktorí sa poznajú len korešpondenciou. 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ých systémov pre GNU/Linux a znižuje 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/Linux. 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: - Rýchlo rastúca distribúcia 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í, ktorá sa vyznačuje konzervatívnym prístupom v vývoj a použitie - Distribučný kit 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. - Táto distribúcia zameraná na používanie najnovších verzií softvéru a neustále aktualizovaná, podporuje rovnako binárne aj zdrojové inštalácie a je postavená na filozofii jednoduchosti KISS, je zameraná na kompetentných používateľov, ktorí chcú mať všetok výkon a modifikovateľnosť Linuxu, ale bez obetovania času údržby.

Okrem tých, ktoré sú uvedené, existuje mnoho ďalších distribúcií, ktoré sú založené na tých, ktoré sú uvedené, a sú vytvorené úplne 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 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í, ale pomerne často sa na tento účel používajú takzvané zdrojové distribúcie, to znamená, že ide o vlastnú montáž všetkých (alebo častí) komponenty 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 prax ukázala, vopred zostavený balík spĺňa všetky požiadavky na systém a nemá zmysel strácať čas ručným 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

Vytvorme skupinu nagcmd, ktorá umožní vykonávať externé príkazy prechádzajúce 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 vytvorili predtým:

# ./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 zobrazenie krátkej pomoci všetkých zahrnutých balíkov

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 do PREFIXu

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 dáta iba na čítanie z 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 budovanie v prostredí CYGWIN Balíky:

With-PACKAGE[=ARG] použite PACKAGE

Bez-BALENIE nepoužívajte BALENIE (rovnako 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 zásuvných modulov 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

Nakonfigurujme Nagios tak, aby sa automaticky spúšťal pri zapnutí operačného systému:

# 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 potrebujete starostlivo optimalizovať vašu aplikáciu alebo chcete dôkladne porozumieť mechanike 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 prepíše starý.

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é konfigurovať jadro systému pomocou jedného súboru s popisom pre hostiteľov a služby, ale táto metóda nebude vhodná s nárastom počtu monitorovaných zariadení, takže je potrebné vytvoriť určitú štruktúru adresárov a súborov. s popisom 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ú nakonfigurovaní hostitelia a kontakty, 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 len všeobecné parametre pre všetky služby.

K dispozícii je veľké 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ý kontroluje, č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 budeme ukladať 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žívané 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

Konfiguračné parametre hostiteľov sú uvedené v prílohe H. Bezpečnosť sa vykonáva individuálnou konfiguráciou paketového filtra na každom z hostiteľov samostatne a organizovaním bezpečný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 viacerý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 na fungovanie 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 je inštalácia obmedzená na vykonanie 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ú obyčajné html súbory a ich obsah nie je zvlášť zaujímavý, takže 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.3NetNetNetDaPo zaprosuNetDebian etchDaDaNetNetNetNetFreeBSD 6,1 * dapo zaprosuPo zaprosuNetNetNetHP-Unet 11iNetNetNetNetNetDaIBM systém iNetNetNetDaNetNetRed Hat ES 4 / CentOS 4DaDaNetNetNetNetRed Hat ES 5 / CentOS 5DaDaNetNetNetNetSLES 10 / openSUSE 10.0DaPo zaprosuNetNetNetNetSLES 10 SP1 / openSUSE 10.1DaDaNetNetNetNetSolaris 8NetNetDaNetNetNetSolaris 9Po zaprosuNetDaNetNetNetSolaris 10 Po zaprosuDaDaNetNetNetWindowsDaDaNetNetNetNet Poznámka: *Prístup k databáze Oracle nie je podporovaný

Podrobné porovnanie technických vlastností je uvedené v prílohe P.

Súbory s popisom 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, aby sa správy o systémových udalostiach odosielali 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

Zo škálovateľnosti vyplýva, ž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 prevádzku modulu opísať nasledovne - klientski hostitelia prenášajú správy z protokolov udalostí rôznych aplikácií na vykladacie servery, ktoré ich zase môžu prenášať pozdĺž reléového reťazca atď. na 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

Vľavo je navigačná lišta, vpravo sú výsledky rôznych zobrazení stavu siete, hostiteľov a služieb. 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 podrobnému popisu problému. 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 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ť zostaviť mapu 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 monitorovacieho mechanizmu siete 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 týchto časopisov a webového rozhrania odložený. V súčasnosti sa k nim pristupuje cez ssh a prehľadávanie adresárov v správcovi 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 - Zobrazenie údajov zhromaždených modulom zberu denníka udalostí systému

6. TESTOVANIE PRÁCE

Počas implementácie systému prebiehalo postupné testovanie funkčnosti 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 so základnou funkcionalitou 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. Bezpečnosť informácií

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 čo 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ý tak, aby fungoval 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 k ochrannému uzemňovaciemu vodiču 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 zabezpečenie ochrany pred úrazom elektrickým prúdom pri dotyku telesa elektroinštalácie v prípade poruchy izolácie živých častí sa uplatňujú technické opatrenia, ktoré zahŕňajú:

· 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 zvukovej pohltivosti;

· 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 s tekutými kryštálmi, 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 60W 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 žiarivky sa vypočíta 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 na obrazovke;

· 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 tanierom, 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.

Diplomový projekt bol realizovaný na počítači s VDT ViewSonic s uhlopriečkou 39 cm. Tento monitor je vyrobený v súlade so svetový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 „myš“ manipulátor napravo od používateľa na doske stola 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 na nohy, 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 sa vplyv hypodynamie, sa vykonávajú série 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 horieť 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 je skontrolované vždy pred začatím práce;

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

Počet evakuačných východov z budov z areálu sú 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 tomto prostredí by najpravdepodobnejšou núdzou bol požiar. 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 predvídať 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 zistili 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 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 zníženiu nákladov 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 elektrinu;

· 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, berúc do úvahy regionálny koeficient, teda 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é vybavenie 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 naznačuje ich nulovú cenu a absenciu potreby ich odpisovania.

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 \u002 rubľov

Pracovisko, kde sa tieto práce vykonávali, je 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é vybavenie a spotrebný materiál, ako aj nepredvídané výdavky.

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 by malo 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é venovať osobitnú pozornosť monitorovaciemu systému, ktorý by sledoval stav aktívnych zariadení a upozorňoval správcu systému na odchýlky od normálnych ukazovateľov formou SMS, e-mailu alebo iným spôsobom.

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ý riadi iba štyri zariadenia. V reálnych podmienkach môže mať aktívna flotila zariadení oveľa viac uzlov. Na implementáciu kompetentného monitorovania sa rôzne typy uzlov kombinujú do skupín, napríklad 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, ktoré sú vytvorené manuálne).

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, množstvo voľného miesta atď. Každému takémuto záznamu zodpovedá jedinečný identifikátor 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, výsledkom ktorého 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.

V ďalšej fáze sa vypracujú špecifikácie a balík 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 efektívnosti 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?

Ľutujeme, že článok pre vás nebol užitočný: (Ak to nie je zložité, 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!