27.06.2011 Nate McAlmond

Valisin kolm kandidaati: WhatsUp Gold Premium Ipswitchilt, OpManager Professional ManageEngine'ilt ja ipMonitor SolarWindsist. Kõik need võrguskannerid maksavad vähem kui 3000 dollarit (100 seadme kohta) ja igaühel neist on prooviperiood, mille jooksul saate valitud toodet tasuta testida

Töötan keskmise suurusega ettevõttes ja oleme kasutanud sama võrguseiresüsteemi juba umbes seitse aastat. See annab meie administraatoritele põhiteavet serverite ja teenuste saadavuse kohta ning saadab probleemide korral meie mobiiltelefonidele SMS-sõnumeid. Jõudsin järeldusele, et peate süsteemi uuendama või vähemalt lisama tõhusa tööriista, mis tagab parema jõudluse ja annab üksikasjalikku teavet teie võrgus hostitud terminaliserverite, Exchange'i süsteemide ja SQL-i oleku kohta. . Võrdleme oma kandidaate.

Avastamisprotsess

Testimiseks valmistumiseks oli esimene samm SNMP-teenuse lubamine kõigis seadmetes, sealhulgas Windowsi serverites. Muutes SNMP-teenuse seadeid, määran kirjutuskaitstud juurdepääsu kõigile seadmetele, mis peaksid olema jälgimisprotsessiga hõlmatud. Windows Server 2003/2000 süsteemides installitakse SNMP-teenus Windowsi komponentide viisardi abil, mis asub paneelil Programmide lisamine/eemaldamine, ja Windows Server 2008 puhul lisatakse SNMP-komponendid serverihalduri viisardi abil. Pärast viisardi lõpetamist peate käivitama juhtpaneeli kaustas asuva lisandmooduli Teenused ja konfigureerima SNMP-teenuse - see pole keeruline. Hallatavatel võrguseadmetel, nagu tulemüürid, kommutaatorid, ruuterid ja printerid, on ka SNMP teenusehaldustööriistad ning konfiguratsiooniprotsess on tavaliselt üsna lihtne toiming. SNMP-teenuse kohta lisateabe saamiseks vaadake dokumenti "Simple Network Management Protocol" (technet.microsoft.com/en-us/library/bb726987.aspx).

Järgmisena installisin kõik kolm jälgimissüsteemi ühte oma kahest töökorras Windows XP hoolduspaketiga SP3. Pärast installimist koosnes iga süsteem kahest osast: andmebaasist ja veebiserverist. Kõiki valitud süsteeme saavad veebiliidese kaudu hallata mitu administraatorit ja teil on võimalus seadistada erineva juurdepääsutasemega kontosid. Nendele kolmele süsteemile on ühine see, et igal kasutajal on võimalus oma tööruumis paneele lisada, eemaldada ja teisaldada. Paneelid kuvavad sama tüüpi andmeid, nagu protsessori koormus või mälukasutus võrgu erinevate seadmete jaoks.

Enne võrguskannimise (mida nimetatakse avastamisprotsessiks) alustamist seadistasin konto seaded, mida iga süsteem peaks kasutama võrgus avastatud seadmetele juurdepääsu saamiseks. Nagu on näidatud võrdlustabelis, võimaldab Ipswitch WhatsUp Gold Premium süsteem teil luua konto SNMP, WMI, Telneti, SSH, ADO ja VMware teenuste jaoks. ManageEngine OpManager Professional toetab SNMP-, WMI-, Telneti-, SSH- ja URL-protokolle, samas kui SolarWinds ipMonitor toetab SNMP-, WMI- ja URL-protokolle.

Pärast SNMP-teenuse konfigureerimist võrguseadmetes ja -kontodel (Windows ja SNMP) iga võrguseiresüsteemi jaoks alustasin oma kohalikus võrgus mitme IP-aadressi avastamisprotsessi. Kõik süsteemid tuvastasid umbes 70 seadet. Skannimise vaikesätteid kasutades suutsid testitavad süsteemid hästi tuvastada seadme tüüpe ja pakkuda üksikasjalikku seadme olekuteavet. Kõik kolm süsteemi sisaldavad andureid võtmeseadmete ja serveri jõudluse jaoks, nagu protsessori koormus, mälukasutus, ketta kasutus/täisus, pakettide kadu/viivitus, Exchange'i teenuste olek, Lotus, Active Directory ja kõik Windowsi teenused. Igal süsteemil oli võimalus lisada andureid nii üksikutele seadmetele kui ka suurtele seadmerühmadele.

Paketid OpManager ja WhatsUp Gold pakuvad liidest VMware teenuse sündmuste tuvastamiseks ja kogumiseks serveritest ja külalistest. Lisaks on mõlemal tootel kommutaatori pordihalduri küsitlusfunktsioon, mis näitab, millised seadmed on ühendatud hallatavate kommutaatorite erinevate portidega. See teave aitab teil kindlaks teha, milline kommutaatori port ühendub konkreetse ärirakendusega, ilma et peaksite serveriruumides kaableid käsitsi jälgima. Saate täiendavalt konfigureerida hoiatusi konkreetsete lülitiportide jaoks. OpManageri paketiga töötades valige pollimisportide tulemuste saamiseks lihtsalt lüliti ja käivitage tööriist Switch Port Mapper – süsteem tagastab tulemused mõne sekundi pärast. WhatsUp Goldiga kaasas olevat sarnast tööriista nimetatakse MAC-aadressiks ja seda tuleb käivitada, kui suvand Hangi ühenduvus on märgitud. WhatsUp Goldil kulub tulemuse saamiseks kauem aega, kuna see üritab skannida seadmeid ja koguda ühendusteavet kogu võrgus.

Ipswitch WhatsUp Gold Premium

Ipswitch WhatsUp Gold Premium
TAGA: annab kolme konkurendi seas kõige täpsemaid tulemusi, võimaldab luua oma andureid, pakub VMware süsteemidele terviklikke jälgimistööriistu, integreerub AD-ga.
VASTU: vähem sisseehitatud andureid ja kõrgem hind võrreldes konkurentidega (kui ostate litsentsi vähem kui 500 seadme jaoks).
HIND: 4,5 viiest.
HIND: 7495 dollarit 500 seadme eest, 2695 dollarit 100 seadme eest, 2195 dollarit 25 seadme eest.
SOOVITUSED V: Soovitan WhatsUp Gold IT-d osakondadele, mis teenindavad suuri VMware keskkondi või soovivad luua oma andureid.
KONTAKTINFO: ipswitch www.ipswitch.com

Süsteemidega IpMonitor ja OpManager töötades kohtasin aeg-ajalt arusaamatuid näitu, mis tekitasid minus hämmingut. IpMonitoris võivad armatuurlauad kuvada negatiivseid väärtusi, kui protsessori kasutustase oluliselt langes. Teisel juhul, kui protsessori koormus oli nullilähedane, saatis IpMonitori süsteem mulle teate, et protsessorit on kasutatud 11,490%! OpManageri süsteem, jälgides ja saatnud mulle õiget teavet domeenikontrollerite kettakasutuse kohta, ei sisaldanud mõnel juhul ühtegi kontrollerit 10 maksimaalse kettaruumikasutusega serveri loendis. Samal ajal teatas kõrvalasuv paneel, et üks minu domeenikontroller ei peaks olema isegi mitte esikümnes, vaid esikolmikus. WhatsUp Goldi kasutades ma selliseid olukordi ei kohanud. WhatsUp Gold jälgib oma paneelide protsessorituumade kasutamist ja kui võrdlesin WhatsUp Goldi paneelide tulemusi Windows Performance Monitori näitudega, olid need iga tuuma puhul täpselt samad. Samuti edastati kõvaketta kasutusteave õigesti kõikidele asjakohastele tööruumi rakendustele.

WhatsUp Goldil on sisseehitatud sensoriteek, mis võimaldab luua uusi andureid olemasolevate põhjal. Suurtele organisatsioonidele võib see funktsioon olla kasulik, kuna see võimaldab teil luua ühtse andurite komplekti, et jälgida erinevat tüüpi seadmeid – see on kõige tõhusam viis andurite konfigureerimiseks seadmete rühma jaoks.

WhatsUp Goldil pole andureid konkreetsete tootjate seadmete jaoks (välja arvatud APC UPS-i toiteallikate andur), erinevalt OpManageri paketist, mis kasutab Delli, HP ja IBMi seadmete jaoks oma andureid, kuid võimaldab teil luua aktiivseid Skripti tüüpi andurid. See tüüp võimaldab teil VBScripti ja JScripti programmeerimiskeeli kasutades arendada oma jälgimisprotsesse. Active Scripti anduritel on veebipõhine tugikeskus, kust WhatsUp Goldi kasutajad saavad valmis skripte hankida ja alla laadida.

Ainus parendus, mida tahaksin WhatsUp Gold süsteemi lisada, on liides (joonis 1), peamiselt seetõttu, et see on liiga lineaarne. Näiteks Active Monitor Library aknast tööalale naasmiseks kulub kuni 5 klõpsu nuppudel Tühista ja Sule. Samuti ei ole WhatsUp Gold süsteemil sensorit (kui te seda muidugi käsitsi ei kirjuta), mis kontrollib saidi olekut ja see võib osutuda vajalikuks, eriti juhtudel, kui saiti majutatakse kolmanda osapoole serveris ja sellele juurde pääsemiseks pole muid võimalusi.

Joonis 1: WhatsUp Gold Premium liides

Olukordade lahendamiseks, kus seadmed on mõnda aega jõude, saate konfigureerida teatisi saatma iga 2, 5 ja 20 minuti järel. Nii saate juhtida administraatori tähelepanu olulisemate sõlmede vastuse puudumisele teatud aja jooksul.

WhatsUp Gold on ainus kaalumisel olev süsteem, millel on võimalus integreeruda LDAP keskkonda – see hetk võib suurte võrkude jaoks lahenduse valimisel olla ülioluline.

ManageEngine OpManager

ManageEngine OpManager
TAGA: parim kasutajaliides kolme toote hulgast; rohkem sisseehitatud andureid kui kahes teises süsteemis; madalaim hind 50 või vähema seadme litsentsi ostmisel.
VASTU: testide ajal ei kuvatud kõiki seadme indikaatoreid õigesti; süsteemi täielikuks toimimiseks võib silumiseks kuluda veidi aega.
HIND: 4,5 viiest.
HIND: 1995 dollarit 100 seadme eest, 995 dollarit 50 seadme eest, 595 dollarit 25 seadme eest.
SOOVITUSED: IT-osakonnad, kes soovivad kastist maksimumi saada (välja arvatud AD-integratsioon), hindavad OpManager Professionali. Ostes litsentse vahemikus 26-50 seadet, on selle maksumus peaaegu poole väiksem kui kahel teisel tootel.
KONTAKTINFO: ManageEngine www.manageengine.com

Pärast OpManageri süsteemi installimist leidsin, et tohutul hulgal funktsioone on lihtne konfigureerida ja nende vahel on mugav liikuda. OpManager pakub võimalust saata (koos e-kirjade ja SMS-idega) otsesõnumeid Twitteri kontole – see on kena alternatiiv meilile. Selline Twitteri kontode kasutamine hoiab mind veebis toimuvaga kursis, aga kuna mu telefon ei helise, kui Twitteri süsteemist sõnumeid edastan, siis soovin saada paralleelselt ka tekstiteateid tähtsamate sündmuste kohta. Võin vaadata läveteavet mis tahes serveris, kasutades Twitteri sõnumeid ja seega pean võrgus jooksvate sündmuste logi, kuid kriitiliste hoiatuste saatmiseks pole seda skeemi vaja kasutada.

Lisaks standardsetele anduritele pakub OpManager SNMP jõudluse jälgimise tehnoloogiaid, mille on välja töötanud müüjad sellistele seadmetele nagu Dell Power-Edge, HP Proliant ja IBM Blade Center. OpManagerit saab integreerida ka Google Mapsi API-ga, et saaksite oma seadmeid Google'i kaardile lisada. Selleks peate aga ostma Google Maps API Premium konto (kui te ei kavatse oma kaarti avalikult kättesaadavaks teha) vastavalt Google Maps API süsteemi tasuta versiooni litsentsitingimustele.

Olukordade lahendamiseks, kus administraator saab hoiatuse, kuid ei vasta sellele teatud aja jooksul, saab OpManageri konfigureerida saatma teisele administraatorile täiendavat hoiatust. Näiteks võib töötaja, kes tavaliselt vastutab teatud serverirühma kriitiliste sündmuste käsitlemise eest, olla hõivatud või haige. Sellisel juhul on mõttekas seadistada lisahoiatus, mis tõmbab teise administraatori tähelepanu, kui esimest hoiatust pole määratud tundide/minutite arvu jooksul vaadatud või kustutatud.

Kolmest läbi vaadatud tootest oli ainult OpManageri süsteemil jaotis, mis oli pühendatud WAN-i VoIP-vahetuse kvaliteedi jälgimisele. VoIP-seiretööriistade kasutamiseks peavad nii lähte- kui ka sihtvõrgu seadmed toetama Cisco IP SLA tehnoloogiat. Lisaks sisaldab joonisel 2 näidatud OpManageri liides rohkem andureid ja armatuurlaudu kui ükski konkureeriv toode.

Joonis 2: OpManageri professionaalne liides

SolarWindsi ipMonitor

SolarWindsi ipMonitor
TAGA: piiramatu arv seadmeid väga madala hinnaga; kasutusmugavus.
VASTU: puudub administraatorite tegevuse koordineerimise mehhanism.
HIND: 4 viiest.
HIND: 1995 dollarit piiramatu arv seadmeid (25 andurit tasuta).
SOOVITUSED: Kui teie eelarve on kitsas ja teil on vaja jälgida suurt hulka seadmeid, kui jälgimisprotsess ei nõua keerukaid lahendusi ja kui teile meeldib süsteemivaba lähenemine administraatorite koordineerimisele, on SolarWinds teie jaoks lahendus.
KONTAKTINFO: solarwinds www.solarwinds.com

Pärast esimest ipMonitori tutvustust tundus joonisel 3 näidatud liides mulle üsna segane. Mul kulus peaaegu igavik, et leida koht, kus on konfigureeritud süsteemi üksikute süsteemiandurite kontrollimise sagedus (vaikimisi tehti küsitlus iga 300 sekundi järel). Kuid pärast mõnenädalast ipMonitori kasutamist leidsin, et seda on väga lihtne kasutada ja see on üsna võimeline kvaliteetselt võrgu jälgimiseks. ipMonitori abil saate konfigureerida vaikekontrollid nii, et kõik teenused või jõudluse sätted kaasatakse alati tulevastesse kontrollidesse. Lisaks standardsetele (ja ülalnimetatud) anduritele pakub ipMonitor Windowsi sündmuste logi andurit, mida saab kasutada kriitiliste sündmuste tuvastamisel hoiatuste saatmiseks.

Joonis 3: SolarWindsi ipMonitori liides

Teisest küljest ei ole ipMonitori süsteemil mehhanisme hoiatuse sihtmärkide jälgimiseks/määramiseks. Vahet pole, kui ettevõttes on ainult üks võrguadministraator, kuid suuremad IT-osakonnad peavad tõenäoliselt oluliseks puuduseks süsteemi suutmatust märguannete saamist kinnitada, adressaate määrata ja hoiatusi lähtestada. Kui administraatorid unustavad oma tegevusi süsteemiväliselt kooskõlastada, võib ette tulla olukordi, kus mitu administraatorit saavad sama märguande ja hakkavad sama probleemiga tegelema. Selliste konfliktide lahendamiseks piisab aga hoiatustele reageerimise järjepideva algoritmi väljatöötamisest – näiteks kui jagate võrguseadmete eest vastutust administraatorite vahel, siis ei teki küsimusi, kes peaks konkreetse probleemiga tegelema.

Aeg teha otsus

Olen juba ise otsustanud, milline kolmest tootest on minu keskkonda sobivam. Otsustasin ManageEngine OpManageri süsteemi 50 seadmelitsentsiga mitmel põhjusel.

Esiteks pean ma suutma jälgida oma keskkonna maksimaalset parameetrite arvu, sest nii saab kõige paremini vältida ootamatuid rikkeid. Selles küsimuses on OpManageri süsteem kindlasti konkurentidest ees. Teine põhjus on eelarve. Saan jätkata meie vanade sisse- ja väljalülitustööriistade kasutamist tööjaamade ja printerite jaoks ning seega vältida lisalitsentside kulusid. Lõpuks meeldis mulle väga ManageEngine'i meeskonna lähenemine OpManageri arendamisel uute tehnoloogiate ärakasutamiseks ja ma õigustan iga-aastase teenuse- ja tugipaketi kulusid, mis võimaldavad teil toote arenedes värskendusi alla laadida.

Nate McAlmond ( [e-postiga kaitstud]) on sotsiaalteenuste agentuuri IT-direktor, MCSE, Security ja Network+ sertifikaadiga, spetsialiseerunud õhukeste klientide lahendustele ja meditsiinilistele andmebaasidele.

Algne nimi: Võrguliikluse jälgimise ja analüüsi tehnikate kokkuvõte

Link originaaltekstile: http://www.cse.wustl.edu/~jain/cse567-06/ftp/net_monitoring/index.html

Soovitused: Pakutav tõlge ei ole professionaalne. Võimalikud on kõrvalekalded tekstist, teatud terminite ja mõistete ebaõige tõlgendamine, tõlkija subjektiivne arvamus. Kõik illustratsioonid sisalduvad tõlkes ilma muudatusteta.

Alisha Sessil

Ülevaade võrguliikluse analüüsi ja jälgimise meetoditest

Kuna eraettevõttesisesed võrgud kasvavad jätkuvalt, on ülioluline, et võrguadministraatorid oleksid teadlikud ja oskaksid käsitsi hallata nende võrgu kaudu liikuvat erinevat tüüpi liiklust. Liikluse jälgimine ja analüüs on hädavajalik, et tõhusamalt diagnoosida ja lahendada probleeme nende ilmnemisel, vältides nii võrguteenuste pikaajalist jõudeolekut. Saadaval on palju erinevaid tööriistu, mis aitavad administraatoritel võrguliiklust jälgida ja analüüsida. Selles artiklis käsitletakse ruuterile orienteeritud jälgimismeetodeid ja mitteruuterile orienteeritud jälgimismeetodeid (aktiivsed ja passiivsed meetodid). Artikkel annab ülevaate kolmest saadaolevast ja enamkasutatavast ruuteritesse sisseehitatud võrgu jälgimismeetodist (SNMP, RMON ja Cisco Netflow) ning annab teavet kahe uue seiremeetodi kohta, mis kasutavad passiivse ja aktiivse seiremeetodi kombinatsiooni (WREN ja SCNM) .

1. Võrgu jälgimise ja analüüsi tähtsus

Võrgu jälgimine (võrguseire) on keeruline ja nõudlik ülesanne, mis on võrguadministraatorite töö oluline osa. Administraatorid püüavad pidevalt oma võrku sujuvalt töötada. Kui võrk katkeb kasvõi lühikeseks ajaks, langeb tootlikkus ettevõttes ja (avalike teenuste osutajate puhul) satub ohtu ka põhiteenuste osutamise võime. Seetõttu peavad administraatorid jälgima võrguliikluse voogu ja jõudlust kogu võrgus ning kontrollima turvarikkumisi.

2. Seire- ja analüüsimeetodid

"Võrguanalüüs on võrguliikluse hõivamise ja selle kiire vaatamise protsess, et teha kindlaks, mis võrguga on juhtunud." - Angela Orebauh. Järgmistes jaotistes käsitletakse kahte võimalust võrgu jälgimiseks, üks on ruuterile orienteeritud ja teine ​​mitte-ruuterile orienteeritud. Ruuteritesse sisseehitatud ja täiendavat tarkvara või riistvara installimist mittevajavaid jälgimisfunktsioone nimetatakse ruuteripõhisteks meetoditeks. Mitteruuteripõhised meetodid nõuavad riist- ja tarkvara installimist ning pakuvad suuremat paindlikkust. Mõlemat tehnikat käsitletakse allpool nende vastavates jaotistes.

2.1. Ruuteripõhised jälgimismeetodid

Ruuteripõhised jälgimismeetodid on ruuteritesse ühendatud ja seetõttu on neil vähe paindlikkust. Allpool on antud selliseks seireks kõige sagedamini kasutatavate meetodite lühikirjeldus. Iga meetod on paljude aastate jooksul arenenud, enne kui see on muutunud standardseks seiremeetodiks.

2.1.1. Simple Network Monitoring Protocol (SNMP), RFC 1157

SNMP on rakenduskihi protokoll, mis on osa TCP/IP-protokollist. See võimaldab administraatoritel hallata võrgu jõudlust, leida ja parandada võrguprobleeme ning planeerida võrgu kasvu. See kogub statistikat liikluse kohta lõpphostile läbi passiivsete andurite, mida rakendatakse koos ruuteriga. Kuigi on kaks versiooni (SNMPv1 ja SNMPv2), kirjeldatakse selles jaotises ainult SNMPv1. SNMPv2 põhineb SNMPv1-l ja pakub mitmeid täiustusi, näiteks protokollitoimingute lisamist. Standardimisel on veel üks SNMP versioon. Versioon 3 (SNMPv3) on ülevaatamisel.

Protokolli jaoks SNMP-l on kolm põhikomponenti: hallatavad seadmed ( Hallatavad seadmed), agendid (agendid ) ja võrguhaldussüsteemid ( Võrguhaldussüsteemid – NMS-id). Need on näidatud joonisel fig. 1.

Riis. 1. SNMP komponendid

Hallatavad seadmed hõlmavad SNMP agenti ja võivad koosneda ruuteritest, lülititest, lülititest, jaoturitest, personaalarvutitest, printeritest ja muudest sellistest elementidest. Nad vastutavad teabe kogumise ja võrguhaldussüsteemile (NMS) kättesaadavaks tegemise eest.

Agendid hõlmavad tarkvara, mis omab haldusteavet ja tõlgib selle teabe SNMP-ga ühilduvale vormile. Need on juhtseadmele suletud.

Võrguhaldussüsteemid (NMS) käitavad rakendusi, mis jälgivad ja juhivad haldusseadmeid. Võrgu haldamiseks vajalikud protsessori- ja mäluressursid tagab NMS. Iga hallatava võrgu jaoks tuleb luua vähemalt üks haldussüsteem. SNMP võib tegutseda ainult NMS-i või agendina või täita oma ülesandeid jne.

SNMP NMS kasutab hallatavate seadmete jälgimiseks ja juhtimiseks 4 peamist käsku: toimingute lugemine, kirjutamine, katkestamine ja läbimine. Lugemisoperatsioon võtab arvesse muutujaid, mis on salvestatud hallatud seadmetes. Kirjutamiskäsk muudab muutujate väärtusi, mida hallatavad seadmed salvestavad. Läbimise toimingud on teadlikud, milliseid hallatud seadme muutujaid nad toetavad, ja koguvad teavet toetatud muutujate tabelitest. Katkestustoimingut kasutavad hallatavad seadmed, et teavitada NMS-i teatud sündmuste toimumisest.

SNMP kasutab järjekorras 4 protokollitoimingut: Get, GetNext, Set ja Trap. Käsku Hangi kasutatakse siis, kui NMS esitab hallatavate seadmete teabepäringu. SNMPv1 päring koosneb sõnumi päisest ja protokolli andmeühikust (PDU). Sõnum PDU sisaldab teavet, mis on vajalik päringu edukaks täitmiseks, mis saab kas agendilt teabe või määrab agendis väärtuse. Hallatav seade kasutab vajaliku teabe hankimiseks sellel asuvaid SNMP agente ja saadab seejärel NMS-ile "y" sõnumi koos vastusega päringule. Kui agendil pole päringu kohta teavet, ei tagasta ta midagi. Käsk GetNext võtab vastu järgmise objektieksemplari väärtuse.NMS-il on võimalik saata päring (Set-operatsioon) ka siis, kui ilma agentideta elementide väärtus on määratud.Kui agent peab NMS-i sündmustest aru andma, kasutab ta Lõksu operatsioon.

Nagu varem mainitud, on SNMP rakenduskihi protokoll, mis kasutab passiivseid andureid, et aidata administraatoril jälgida võrguliiklust ja võrgu jõudlust. Kuigi SNMP võib olla võrguadministraatorile kasulik tööriist, kujutab see endast turvariskide võimalust, kuna sellel puudub autentimisvõime. See erineb kaugseirest (RMON), mida käsitletakse järgmises jaotises, selle poolest, et RMON töötab võrgukihis ja allpool, mitte rakenduskihis.

2.1.2. Kaugseire (RMON), RFS 1757

RMON sisaldab erinevaid võrgumonitore ja konsoolisüsteeme võrgu jälgimise andmete muutmiseks. See on SNMP haldusteabe andmebaasi (MIB) laiendus. Erinevalt SNMP-st, mis peab saatma teabepäringuid, saab RMON seadistada hoiatusi, mis "jälgivad" võrku teatud kriteeriumide alusel. RMON annab administraatoritele võimaluse hallata nii kohalikke kui ka kaugvõrke ühest kindlast asukohast/punktist. Selle võrgukihi monitorid on näidatud allpool. RMON-il on kaks versiooni: RMON ja RMON2. See artikkel räägib aga ainult RMONist. RMON2 võimaldab jälgida kõikidel võrgukihtidel. See keskendub IP-liiklusele ja rakenduskihi liiklusele.

Kuigi RMON-seirekeskkonnal on kolm põhikomponenti, on siin loetletud ainult kaks neist. Need on näidatud joonisel fig. 2 allpool.

Riis. 2. RMON-i komponendid

RMON-i kaks komponenti on andur, mida tuntakse ka agendi või monitorina, ja klient, mida tuntakse ka juhtimisjaamana (haldusjaam). Erinevalt SNMP-st kogub ja salvestab andur või RMON-agent võrguteavet. Andur on võrguseadmesse (nt ruuterisse või lülitisse) sisseehitatud tarkvara. Andur võib töötada ka personaalarvutis. Iga erineva LAN- või WAN-segmendi jaoks tuleb paigaldada andur, kuna nad näevad liiklust, mis läbib ainult nende linke, kuid nad pole teadlikud liiklusest väljaspool neid. Klient on tavaliselt haldusjaam, mis on ühendatud anduriga, mis kasutab RMON-andmete vastuvõtmiseks ja parandamiseks SNMP-d.

RMON kasutab võrguteabe saamiseks 9 erinevat jälgimisgruppi.

• Statistika – anduri poolt mõõdetud statistika iga selle seadme jälgimisliidese kohta.
• Ajalugu – perioodiliste statistiliste proovide arvestamine võrgust ja nende salvestamine otsimiseks.
• Häire – võtab perioodiliselt statistilisi valimeid ja võrdleb neid sündmuse genereerimiseks läviväärtustega.
• Host – sisaldab statistikat, mis on seotud iga võrgust leitud hostiga.
• HostTopN – koostab tabelid, mis kirjeldavad hostide tippu (peamist hosti).
• Filtrid – lubab sündmuste hõivamise filtri võrrandil põhineva pakettide filtreerimise.
• Pakettide hõivamine – pakettide püüdmine pärast nende läbimist kanali kaudu.
• Sündmused - sündmuste genereerimise ja registreerimise juhtimine seadmest.
• Token ring – rõngasmärkide tugi.

Nagu eespool öeldud, RMON põhineb SNMP-protokollil. Kuigi seda meetodit kasutades saab teostada liiklusseiret, on SNMP ja RMONi abil saadud infoanalüüsi andmed kehva jõudlusega. Netflow utiliit, millest on juttu järgmises osas, töötab edukalt paljude analüütika tarkvarapakettidega, et administraatori tööd oluliselt lihtsamaks muuta.

2.1.3. Netflow, RFS 3954

Netflow on Cisco ruuterites kasutusele võetud laiendus, mis võimaldab koguda IP-võrgu liiklust, kui see on liideses konfigureeritud. Analüüsides Netflow pakutavaid andmeid, saab võrguadministraator kindlaks teha näiteks liikluse allika ja sihtkoha, teenuseklassi ja ummikute põhjused. Netflow sisaldab 3 komponenti: FlowCaching (vahemällu salvestav voog), FlowCollector (voogude kohta teabe koguja) ja Data Analyzer (andmeanalüsaator). Riis. 3 näitab Netflow infrastruktuuri. Kõiki joonisel näidatud komponente selgitatakse allpool.

Riis. 3. NetFlow infrastruktuur

FlowCaching analüüsib ja kogub andmeid liidesesse sisenevate IP-voogude kohta ning teisendab andmed eksportimiseks.

Netflow pakettidest saab hankida järgmist teavet:

• Allika ja sihtkoha aadress.
• Sissetuleva ja väljamineva seadme number.
• Allika ja sihtkoha pordi number.
• 4. taseme protokoll.
• Voos olevate pakettide arv.
• Voo baitide arv.
• Ajatempel voos.
• Lähte ja sihtkoha autonoomse süsteemi (AS) number.
• Teenuse tüüp (ToS) ja TCP lipp.

Standardset lülitusteed läbiva voo esimest paketti töödeldakse vahemälu loomiseks. Sarnaste vooomadustega pakette kasutatakse vookirje loomiseks, mis salvestatakse vahemällu kõigi aktiivsete voogude jaoks. See kirje märgib pakettide arvu ja baitide arvu igas voos. Vahemällu salvestatud teave eksporditakse seejärel perioodiliselt vookogujasse.

Flow Collector – vastutab andmete kogumise, filtreerimise ja salvestamise eest. See sisaldab teabe ajalugu liidese abil ühendatud voogude kohta. Andmete vähendamine toimub ka Flow Collectori abil ning valitud filtrite ja koondamise abil.

Data Analyzer (andmeanalüsaator) on vajalik siis, kui on vaja andmeid esitada. Nagu joonisel näha, saab kogutud andmeid kasutada erinevatel eesmärkidel, isegi peale võrgu jälgimise, nagu planeerimine, raamatupidamine ja võrgu loomine.

Netflow eeliseks teiste seiremeetodite (nt SNMP ja RMON) ees seisneb selles, et sellel on tarkvarapaketid, mis on loodud erinevate liiklusanalüüside jaoks, mis on olemas Netflow pakettidest andmete vastuvõtmiseks ja nende kasutajasõbralikumaks esitamiseks.

Kui kasutate selliseid tööriistu nagu Netflow Analyzer (see on ainus tööriist, mis on saadaval Netflow pakettide analüüsimiseks), saate ülaltoodud teavet Netflow pakettidest, et luua diagramme ja tavalisi graafikuid, mida administraator saab oma võrkude paremaks mõistmiseks uurida. Netflow kasutamise suurim eelis, erinevalt saadaolevatest analüütilistest pakettidest, on see, et sel juhul saab koostada arvukalt graafikuid, mis kirjeldavad võrgu tegevust igal ajahetkel.

2.2. Tehnoloogiad, mis ei põhine ruuteritel

Kuigi ruuterisse sisseehitamata tehnoloogiate võimalused on endiselt piiratud, pakuvad need suuremat paindlikkust kui ruuteritesse sisseehitatud. Need meetodid jagunevad aktiivseteks ja passiivseteks.

2.2.1. Aktiivne jälgimine

Aktiivne jälgimine teatab võrguprobleemidest, kogudes mõõtmised kahe lõpp-punkti vahel. Aktiivne mõõtesüsteem tegeleb selliste mõõdikutega nagu: utiliit, ruuterid/marsruudid, pakettide viivitus, pakettide kordus, pakettide kadu, värina saabumiste vahel, läbilaskevõime mõõtmine.

Peamiste aktiivsete mõõtmisvahendite näideteks on peamiselt selliste tööriistade kasutamine nagu ping-käsk, mis mõõdab latentsust ja paketikadu, ning traceroute, mis aitab määrata võrgu topoloogiat. Mõlemad tööriistad saadavad ICMP-proovi paketid sihtkohta ja ootavad, kuni see sihtkoht saatjale vastab. Riis. 4 on näide pingi käsust, mis kasutab aktiivset mõõtmismeetodit, saates allikast võrgu kaudu määratud punkti Echo päringu. Seejärel saadab vastuvõtja kajapäringu tagasi allikale, kust päring tuli.

Riis. 4. Ping-käsk (aktiivne mõõtmine)

See meetod ei saa mitte ainult koguda üksikuid mõõdikuid aktiivse mõõtmise kohta, vaid saab määrata ka võrgu topoloogia. Teine oluline näide aktiivsest mõõtmisest on iperf utiliit. Iperf on utiliit, mis mõõdab TCP- ja UDP-protokollide läbilaskevõimet. See teatab ribalaiuse, olemasoleva viivituse ja pakettide kadumise.

Aktiivse jälgimise probleem seisneb selles, et võrgus olevad sondid võivad tavalist liiklust häirida. Sageli käsitletakse aktiivseid sondeerimisaegu tavapärasest liiklusest erinevalt, mis seab kahtluse alla nendest sondidest saadava teabe väärtuse.

Ülalkirjeldatud üldise teabe kohaselt on aktiivne monitooring eraldivõetuna üliharuldane seiremeetod. Passiivne jälgimine seevastu suuri võrgukulusid ei nõua.

2.2.2. Passiivne jälgimine

Passiivne jälgimine, erinevalt aktiivsest jälgimisest, ei lisa võrku liiklust ega muuda võrgus juba olemasolevat liiklust. Samuti kogub passiivne jälgimine erinevalt aktiivsest monitooringust infot vaid ühe võrgupunkti kohta. Mõõtmised on palju paremad kui aktiivse monitooringuga kahe punkti vahel. Riis. Joonisel 5 on kujutatud passiivse seiresüsteemi seadistus, kus monitor on paigutatud ühele lingile kahe lõpp-punkti vahel ja jälgib liiklust, kui see lingist üle läheb.

Riis. 5. Passiivse monitooringu paigaldamine

Passiivsed mõõtmised käsitlevad sellist teavet nagu: liiklus ja protokollide segu, bittide arv (bitikiirus), pakettide ajastus ja aeg saabumise vahel. Passiivset jälgimist saab teha mis tahes programmiga, mis tõmbab pakette.

Kuigi passiivsel seirel ei ole selliseid kulusid, mis aktiivsel jälgimisel, on sellel omad puudused. Passiivse jälgimise korral saab mõõtmisi analüüsida ainult võrguühenduseta ja need ei kujuta kogumit. See tekitab probleeme mõõtmise käigus kogutavate suurte andmekogumite käsitlemisel.

Passiivne monitooring võib olla parem kui aktiivne jälgimine, kuna signaaliandmeid võrku ei lisata, kuid järeltöötlus võib olla väga aeganõudev. Seetõttu on nende kahe seiremeetodi kombinatsioon.

2.2.3. Kombineeritud seire

Pärast ülaltoodud jaotiste lugemist võib julgelt järeldada, et aktiivse ja passiivse jälgimise kombinatsioon on parem viis kui esimest või viimast eraldi kasutada. Kombineeritud tehnoloogiad kasutavad keskkondade nii passiivse kui ka aktiivse jälgimise parimaid omadusi. Allpool kirjeldatakse kahte uut tehnoloogiat, mis esindavad kombineeritud seiretehnoloogiaid. Need on End-of-Network Resource Viewer (WREN) ja Self-Configuring Network Monitor (SCNM).

2.2.3.1. End-to End ressursivaade (WREN)

WREN kasutab aktiivse ja passiivse seiretehnikate kombinatsiooni, töötledes andmeid aktiivselt, kui liiklus on väike, ja töötledes andmeid passiivselt suure liikluse ajal. See vaatab liiklust nii allikast kui ka sihtkohast, võimaldades täpsemaid mõõtmisi. WREN kasutab kasuliku läbilaskevõime mõõtmiseks pakettide jälgimist rakenduse loodud liiklusest. WREN jaguneb kaheks kihiks: peamine kiire pakettide töötlemise kiht ja kasutajataseme jälgimisanalüsaator.

Põhiline kiire pakettide töötlemise kiht vastutab sissetulevate ja väljaminevate pakettidega seotud teabe hankimise eest. Riis. 6 näitab iga paketi kohta kogutava teabe loendit. Nende omaduste kogumiseks lisatakse Web100-sse puhver. Puhvrile pääseb juurde kahe süsteemikõne abil. Üks kõne käivitab jälje ja annab selle kogumiseks vajaliku teabe, teine ​​kõne aga tagastab jälje kernelist.

Riis. 6. Pakettjälgede põhitasandil kogutud teave

Paketi jälgimise objekt- oskab koordineerida arvutusi erinevate masinate vahel. Üks masin äratab teise masina, seades väljamineva paketi päises lipu, et hakata töötlema mõningaid jälgitavaid pakette. Teine masin jälgib omakorda kõiki pakette, mille päises näeb sarnast lippu seatud. See koordineerimine tagab, et teavet sarnaste pakettide kohta salvestatakse igas lõpp-punktis, olenemata sidest ja nendevahelisest.

Kasutajataseme jälgimisanalüsaator on WREN-keskkonna teine ​​kiht. See on komponent, mis alustab iga paketi jälgimist, kogub ja töötleb tagastatud andmeid operaatori põhitasandil. Disaini järgi ei pea kasutajataseme komponendid kogu aeg paketijäljeobjektilt teavet lugema. Neid saab analüüsida kohe pärast jälje valmimist, et teha reaalajas järeldus, või salvestada andmed edasiseks analüüsiks.

Kui liiklus on väike, sisestab WREN aktiivselt võrku liiklust, säilitades samal ajal mõõtmisvoogude järjekorra. Pärast arvukaid uuringuid on leitud, et WREN pakub sarnaseid mõõtmisi üleküllastunud ja mitteüleküllastunud keskkondades.

WREN-i praeguses rakenduses ei ole kasutajad sunnitud jäädvustama ainult nende algatatud jälgi. Kuigi iga kasutaja saab jälgida teiste kasutajate rakenduste liiklust, on neil piiratud teave, mida saab teiste kasutajate jälgedest saada. Nad saavad ainult numbrite jada ja kinnituse, kuid ei saa pakettidest tegelikke andmesegmente.

Kokkuvõttes on WREN väga kasulik seadistus, mis kasutab nii aktiivset kui ka passiivset jälgimist. Kuigi see tehnoloogia on alles varajases arengujärgus, võib WREN pakkuda administraatoritele kasulikke ressursse nende võrkude jälgimiseks ja analüüsimiseks. Native Network Configuration Monitor (SCNM) on veel üks tööriist, mis kasutab nii aktiivseid kui ka passiivseid jälgimistehnoloogiaid.

2.2.3.2. Enesekonfiguratsiooniga võrgumonitor (SCNM)

SCNM on seiretööriist, mis kasutab passiivsete ja aktiivsete mõõtmiste kombinatsiooni, et koguda teavet penetratsioonikihi 3, väljuvate ruuterite ja muude oluliste võrgu jälgimispunktide kohta. SCNM-i keskkond sisaldab nii riist- kui ka tarkvarakomponenti.

Riistvara paigaldatakse võrgu kriitilistesse punktidesse. See vastutab pakettide päiste passiivse kogumise eest. Tarkvara töötab võrgu lõpp-punktis. Riis. Alloleval joonisel 7 on näidatud SCNM-keskkonna tarkvarakomponent.

Riis. 7. SCNM-i tarkvarakomponent

Tarkvara vastutab aktiveeritud pakettide loomise ja saatmise eest, mida kasutatakse võrgu jälgimise käivitamiseks. Kasutajad saadavad võrku aktiveerimispaketid, mis sisaldavad nende pakettide üksikasju, mida nad soovivad jälgimiseks ja kogumiseks saada. Kasutajad ei pea teadma SCNM-i hosti asukohta, eeldades, et kõik hostid on pakettide kuulamiseks avatud. Aktiveerimispaketis olemasoleva teabe põhjal paigutatakse filter andmekogumisvoogu, mis töötab ka lõpp-punktis. Kogutakse filtrile vastavad võrgu- ja transpordikihi paketipäised. Filter aegub automaatselt täpselt määratud aja möödudes, kui see saab muid rakenduspakette. SCNM-hostis töötav pakettide proovivõtuteenus kasutab tcpdump käsku (sarnaselt pakettide proovivõtuprogrammiga) vastuvõetud päringute järjekorras ja salvestab päringule vastava liikluse.

Kui probleem tuvastatakse passiivsete seirevahendite abil, saab liiklust genereerida aktiivsete seirevahendite abil, mis võimaldab koguda lisaandmeid, et probleemi üksikasjalikumalt uurida. Juurutades selle monitori võrku igas ruuteris, saame uurida ainult neid võrguosi, millel on probleeme.

SCNM on mõeldud installimiseks ja kasutamiseks peamiselt administraatoritele. Tavakasutajad saavad aga mõnda neist funktsioonidest kasutada. Kuigi tavakasutajad saavad kasutada SCNM-i jälgimiskeskkonna osi, on neil lubatud vaadata ainult oma andmeid.

Kokkuvõtteks võib öelda, et SCNM on veel üks kombineeritud jälgimise viis, mis kasutab nii aktiivseid kui ka passiivseid meetodeid, et aidata administraatoritel oma võrke jälgida ja analüüsida.

3. Järeldus

Valides privaatseid tööriistu, mida võrgujälgimisel kasutada, peab administraator esmalt otsustama, kas ta soovib kasutada juba aastaid kasutusel olnud väljakujunenud süsteeme või uusi. Kui olemasolevad süsteemid on parem lahendus, siis NetFlow on kõige kasulikum tööriist, kuna parsitud andmepakette saab kasutada koos selle utiliidiga andmete kasutajasõbralikumaks esitamiseks. Kui aga administraator on valmis uut süsteemi proovima, on kombineeritud jälgimislahendused nagu WREN või SCNM parim viis.

Võrgu jälgimine ja analüüs on süsteemiadministraatori töös üliolulised. Administraatorid peaksid püüdma hoida oma võrku korras nii ettevõttesiseselt hajutatult kui ka olemasolevate avalike teenustega suhtlemiseks. Ülaltoodud teabe kohaselt on saadaval mitmeid ruuteripõhiseid ja mitteruuteripõhiseid tehnoloogiaid, mis aitavad võrguadministraatoritel oma võrke igapäevaselt jälgida ja analüüsida. Siin on lühidalt kirjeldatud SNMP-d, RMON-i ja Cisco NetFlow-d – näide mitmest ruuteripõhisest tehnoloogiast.. Artiklis käsitletud mitteruuteripõhiste tehnoloogiate näideteks on aktiivne, passiivne jälgimine ja mõlema kombinatsioon.

Sissejuhatus

Viimastel aastatel on infotehnoloogia läbi teinud olulisi ja pidevaid muutusi. Mõnede hinnangute kohaselt on viimase viie aasta jooksul võrguliikluse maht kohalikes võrkudes kümnekordistunud. Seega peavad kohalikud võrgud pakkuma üha suuremat ribalaiust ja vajalikul tasemel teenuse kvaliteeti. Olenemata sellest, millised ressursid võrgul on, on need siiski piiratud, seega vajab võrk liikluse juhtimise võimalust.

Ja selleks, et olla võimalikult tõhus, peate suutma juhtida pakette, mis teie võrgus olevate seadmete vahel liiguvad. Samuti on administraatoril väga palju kohustuslikke igapäevaseid toiminguid. See hõlmab näiteks e-posti korrektse toimimise kontrollimist, logifailide vaatamist probleemide varajaste tunnuste tuvastamiseks, kohtvõrgu ühenduvuse jälgimist ja süsteemiressursside saadavuse jälgimist. Ja siin võivad appi tulla arvutivõrkude jälgimiseks ja analüüsimiseks kasutatavad vahendid.

Et mitte sattuda segadusse jälgimiseks loodud meetodite, tööriistade ja toodete mitmekesisuses, alustame nende toodete mitme suure klassi lühikirjeldusega.

Võrguhaldussüsteemid. Need on tsentraliseeritud tarkvarasüsteemid, mis koguvad andmeid võrgusõlmede ja sideseadmete oleku ning võrgus ringleva liikluse kohta. Need süsteemid mitte ainult ei jälgi ega analüüsi võrku, vaid teostavad ka automaat- või poolautomaatrežiimis võrguhaldustoiminguid – seadmete portide lubamine ja keelamine, sildade, kommutaatorite ja ruuterite aadressitabelite sillaparameetrite muutmine jne. Juhtimissüsteemide näideteks on populaarsed süsteemid HPOpenView, SunNetManager, IBMNetView.

Süsteemihaldustööriistad. Süsteemi juhtseadmed täidavad sageli juhtimissüsteemide funktsioonidega sarnaseid funktsioone, kuid on seotud muude objektidega. Esimesel juhul on juhtimisobjektiks võrguarvutite tarkvara ja riistvara ning teisel juhul sideseadmed. Siiski võivad nende kahte tüüpi haldussüsteemide mõned funktsioonid kattuda, näiteks saavad süsteemihaldustööriistad teha lihtsat võrguliikluse analüüsi.

Diagnostika- ja juhtimissüsteemid (Manussüsteemid). Neid süsteeme rakendatakse sideseadmetesse paigaldatud tarkvara- ja riistvaramoodulitena, samuti operatsioonisüsteemidesse sisseehitatud tarkvaramoodulitena. Nad täidavad ainult ühe seadme diagnostika ja juhtimise funktsioone ning see on nende peamine erinevus tsentraliseeritud juhtimissüsteemidest. Selle tööriistaklassi näide on jaoturi juhtmoodul Distrebuted 5000, mis rakendab tõrgete tuvastamisel portide automaatse segmenteerimise funktsioone, pordide määramist jaoturi sisemistele segmentidele ja mõnda muud. Reeglina toimivad osalise tööajaga sisseehitatud haldusmoodulid SNMP agentidena, mis edastavad haldussüsteemidele seadme olekuandmeid.

Protokolli analüsaatorid. Need on tarkvara või riistvara-tarkvarasüsteemid, mida erinevalt juhtimissüsteemidest piiravad ainult võrguliikluse jälgimise ja analüüsimise funktsioonid. Hea protokollianalüsaator suudab hõivata ja dekodeerida pakette paljudest võrkudes kasutatavatest protokollidest – tavaliselt mitmekümnest. Protokolli analüsaatorid võimaldavad teil seada üksikute pakettide hõivamiseks mõned loogilised tingimused ja teostada hõivatud pakettide täielikku dekodeerimist, see tähendab, et need näitavad spetsialistile sobival kujul erineva tasemega protokollipakettide üksteisesse pesastamist koos sisu dekodeerimisega. iga paketi üksikute väljade kohta.

Ekspertsüsteemid. Seda tüüpi süsteemid koguvad inimeste teadmisi võrkude ebanormaalse toimimise põhjuste tuvastamise ja võimalike viiside kohta, kuidas võrk terve olekusse viia. Ekspertsüsteeme rakendatakse sageli erinevate võrgu jälgimise ja analüüsi tööriistade eraldi alamsüsteemidena: võrguhaldussüsteemid, protokollianalüsaatorid, võrguanalüsaatorid. Ekspertsüsteemi lihtsaim versioon on kontekstitundlik abisüsteem. Keerulisemad ekspertsüsteemid on tehisintellekti elementidega nn teadmusbaasid. Sellise süsteemi näide on Cabletroni Spectrum juhtimissüsteemi sisseehitatud ekspertsüsteem.

Multifunktsionaalsed seadmed analüüsiks ja diagnostikaks. Viimastel aastatel on kohalike võrkude laialdase leviku tõttu tekkinud vajadus välja töötada odavaid kaasaskantavaid seadmeid, mis ühendavad endas mitme seadme funktsioonid: protokollianalüsaatorid, kaabliskannerid ja isegi mõned võrguhaldustarkvara funktsioonid. Seda tüüpi seadmete näide on Microtest, Inc. kompas. või 675 LANMeter firmalt FlukeCorp.

Juhtimissüsteemid

Hiljuti on kontrollisüsteemide valdkonnas täheldatud kahte üsna erinevat suundumust:

1. Võrkude ja süsteemide haldamise funktsioonide integreerimine ühte tootesse. (Selle lähenemise vaieldamatu eelis on süsteemi üksainus kontrollpunkt. Puuduseks on see, et kui võrk on tugevalt koormatud, ei pruugi installitud jälgimisprogrammiga server olla võimeline kõiki pakette töötlema ja olenevalt tootest kas ignoreerida mõned paketid või muutuvad süsteemi "kitsaks" kohaks).
2. juhtimissüsteemi jaotus, milles süsteemis on mitu konsooli, mis koguvad teavet seadmete ja süsteemide oleku kohta ning väljastavad juhtimistoiminguid. (Siin on vastupidi: seireülesanded on jaotatud mitme seadme vahel, kuid võimalikud on samade funktsioonide dubleerimine ja erinevate konsoolide juhtelementide ebakõla.)

Sageli ei täida juhtimissüsteemid mitte ainult võrgu töö jälgimise ja analüüsimise funktsioone, vaid hõlmavad ka võrgu aktiivse mõjutamise funktsioone - konfiguratsiooni ja turvahaldust (vt külgriba).

SNMP võrguhaldusprotokoll

Enamik inimesi, kes loovad ja haldavad võrke, armastavad standardite kontseptsiooni. See on arusaadav, kuna standardid võimaldavad neil valida võrgutarnija selliste kriteeriumide alusel nagu teenuse tase, hind ja toote jõudlus, selle asemel, et olla "aheldatud" ühe tootja patenteeritud lahendusega. Tänapäeva suurim võrk – Internet – põhineb standarditel. Internet Engineering Task Force (IETF) moodustati selle ja teiste TCP/IP-protokolle kasutavate võrkude arendustegevuse koordineerimiseks.

Levinuim võrguhaldusprotokoll on SNMP (SimpleNetworkManagementProtocol), mida toetavad sajad müüjad. SNMP-protokolli peamised eelised on lihtsus, kättesaadavus, sõltumatus tootjatest. SNMP-protokoll on mõeldud Interneti-ruuterite haldamiseks ja on osa TCP/IP-virust.

Mis on MIB – Man In Black?

Kui me räägime ettevõtte võrgu jälgimise tööriistadest, siis see lühend peidab endas mõistet Management Information Base. Mille jaoks see andmebaas on?

SNMP on protokoll, mida kasutatakse võrguseadmetelt nende oleku, jõudluse ja omaduste kohta teabe hankimiseks, mis salvestatakse spetsiaalsesse võrguseadmete andmebaasi, mida nimetatakse MIB-ks. On olemas standardid, mis määratlevad MIB struktuuri, sealhulgas selle muutujate tüüpide komplekti (ISO terminoloogias objektid), nende nimed ja nende muutujatega lubatud toimingud (näiteks lugemine). Lisaks muule teabele saab MIB salvestada seadmete võrgu- ja/või MAC-aadresse, töödeldud pakettide ja vigade loendurite väärtusi, numbreid, prioriteete ja teavet portide oleku kohta. MIB-puu struktuur sisaldab kohustuslikke (standardseid) alampuid; lisaks võib see sisaldada privaatseid alampuid, mis võimaldavad nutiseadmete tootjal oma spetsiifiliste muutujate alusel realiseerida mis tahes spetsiifilisi funktsioone.

SNMP-protokolli agent on töötlemiselement, mis annab võrguhaldusjaamades asuvatele halduritele juurdepääsu MIB-muutujate väärtustele ja võimaldab neil seeläbi rakendada seadmehaldus- ja seirefunktsioone.

Kasulik täiendus SNMP-funktsioonile on RMON-spetsifikatsioon, mis pakub kaugsuhtlust MIB-ga. Enne RMON-i ei saanud SNMP-d eemalt kasutada, see võimaldas ainult kohalikku seadmehaldust. RMON töötab aga kõige paremini jagatud võrkudes, kus see saab juhtida kogu liiklust. Kui aga võrgus on lüliti, mis filtreerib liiklust nii, et see on pordile nähtamatu, välja arvatud juhul, kui see on mõeldud selle pordiga seotud seadmele või ei pärine sellest seadmest, siis mõjutab see teie prooviandmeid.

Selle vältimiseks on tootjad pakkunud igale lülitiportile mõningaid RMON-funktsioone. See on skaleeritavam süsteem kui süsteem, mis küsib pidevalt kõiki lüliti porte.

Protokolli analüsaatorid

Uue võrgu projekteerimisel või vana võrgu uuendamisel tekib sageli vajadus kvantifitseerida teatud võrguomadused, nagu näiteks andmevoogude intensiivsus üle võrgu sideliinide, pakettide töötlemise erinevates etappides esinevad viivitused, reageerimine. aega ühe või teise taotluste esitamiseks, konkreetsete sündmuste esinemise sagedus jne.

Selles keerulises olukorras saate võrguhaldussüsteemides kasutada erinevaid tööriistu ja eelkõige seiretööriistu, millest on juba artikli eelmistes osades juttu olnud. Mõningaid võrgus olevaid mõõtmisi saab teostada ka operatsioonisüsteemi sisseehitatud tarkvaramõõturite abil, selle näiteks on Windows NTPerformanceMonitor OS komponent. See utiliit on välja töötatud arvutitegevuse reaalajas jäädvustamiseks. Tema abiga saate tuvastada enamiku "pudelikaelad", mis vähendavad jõudlust.

PerformanceMonitor põhineb loenduritel, mis salvestavad selliseid omadusi nagu kettatoimingute lõpetamist ootavate protsesside arv, ajaühikus edastatud võrgupakettide arv, protsessori kasutusprotsent jne.

Kuid kõige arenenum võrguuuringute tööriist on protokolli analüsaator. Protokolli analüüsi protsess hõlmab võrgus ringlevate pakettide hõivamist, mis rakendavad teatud võrguprotokolli, ja nende pakettide sisu uurimist. Analüüsi tulemuste põhjal on võimalik teha mõistlikke ja tasakaalustatud muudatusi mistahes võrgukomponentides, optimeerida selle jõudlust ja lahendada probleeme. Ilmselgelt on selleks, et teha järeldusi muudatuse mõju kohta võrgule, protokolle analüüsida enne ja pärast muudatuse tegemist.

Tavaliselt võtab protokolli analüüsi protsess üsna kaua aega (kuni mitu tööpäeva) ja sisaldab järgmisi samme:

1. Andmete kogumine.
2. Vaadake jäädvustatud andmeid.
3. Andmete analüüs.
4. Otsige vigu.
5. Tulemuslikkuse uuring. Võrgu ribalaiuse kasutuse või päringu keskmise reageerimisaja arvutamine.
6. Üksikasjalik uuring võrgu üksikute osade kohta. Töö sisu selles etapis sõltub võrgu analüüsimisel saadud tulemustest.

Siin saame lõpetada nende teoreetiliste punktide läbimõtlemise, mida oma võrgu seiresüsteemi ehitamisel arvesse võtta ning asuda edasi ettevõtte võrgu toimimise analüüsimiseks ja juhtimiseks loodud tarkvaratoodete käsitlemiseni.

Tooted monitooringuks ja analüüsiks

Võrdlev ülevaade HPOpenView ja CabletronSpectrum juhtimissüsteemidest

Iga selles jaotises käsitletav rakenduste komplekt jagab võrguhalduse ligikaudu neljaks valdkonnaks. Esimene on komplekti integreerimine üldisesse võrguhaldusinfrastruktuuri, mis eeldab sama tootja erinevat tüüpi seadmete tuge.

Järgmine funktsionaalne ala on vahendid üksikute võrguseadmete (nt jaotur, lüliti või sond) konfigureerimiseks ja haldamiseks.

Kolmas valdkond on globaalsed haldustööriistad, mis juba vastutavad seadmete rühmitamise ja nendevahelise suhtluse korraldamise eest, näiteks rakendused võrgu topoloogia diagrammi genereerimiseks.

Käesoleva artikli teemaks on neljas funktsionaalne valdkond – liiklusseire. Kuigi VLAN-i konfiguratsioonitööriistad ja globaalne haldus on võrguhalduse olulised aspektid, ei ole ametlikke võrguhaldusprotseduure üldiselt otstarbekas ühes Etherneti võrgus rakendada. Piisab, kui pärast paigaldamist võrku põhjalikult testida ja aeg-ajalt kontrollida koormustaset.

Ettevõtte võrguhaldussüsteemide heal platvormil peaksid olema järgmised omadused:

• skaleeritavus;
• tõeline levitamine vastavalt mõistele "klient / server";
• avatus heterogeense riistvara käsitlemiseks lauaarvutitest suurarvutiteni.

Esimesed kaks omadust on omavahel tihedalt seotud. Hea mastaapsus saavutatakse tänu juhtimissüsteemi jaotusele. Jaotus tähendab siin seda, et süsteem võib hõlmata mitut serverit ja klienti.

Heterogeensete seadmete toetamine on tänapäeva juhtimissüsteemides pigem soov kui reaalsus. Vaatleme kahte populaarset võrguhaldustoodet: CabletronSystemsi Spectrum ja Hewlett-Packardi OpenView. Mõlemad ettevõtted toodavad ise oma sideseadmeid. Loomulikult oskab Spectrum kõige paremini Cabletroni seadmeid ja OpenView Hewlett-Packardi seadmeid.

Kui võrgukaart on ehitatud teiste tootjate seadmetest, hakkavad need süsteemid tegema vigu ja eksitama ühte seadet teisega ning nende seadmete haldamisel toetavad nad ainult nende põhifunktsioone ja palju kasulikke lisafunktsioone, mis eristavad seda seadet teistest. , juhtimissüsteem lihtsalt ei mõista ja seetõttu ei saa neid kasutada.

Selle olukorra vältimiseks toetavad juhtimissüsteemide arendajad mitte ainult standardseid MIBI, MIBII ja RMONMIB andmebaase, vaid ka arvukaid erasektori MIB-i tootjaid. Selle valdkonna liider on Spectrum süsteem, mis toetab enam kui 1000 erinevate tootjate MIB-i.

OpenView vaieldamatu eelis on aga selle võime ära tunda mis tahes TCP / IP kaudu töötava võrgu võrgutehnoloogiaid. Spektri puhul on see võimalus piiratud Etherneti, TokenRingi, FDDI, ATM-i, WAN-i ja kommuteeritud võrkudega. Võrgus olevate seadmete suurenedes osutub Spectrum skaleeritavamaks, kus teenindatavate sõlmede arv ei ole millegagi piiratud.

Ilmselgelt, hoolimata kummagi süsteemi tugevatest ja nõrkadest külgedest, kui võrgus domineerivad ühe tootja seadmed, võimaldab selle tootja haldusrakenduste olemasolu mis tahes populaarse haldusplatvormi jaoks võrguadministraatoritel paljusid probleeme edukalt lahendada. Seetõttu tarnivad haldusplatvormide arendajad endaga kaasa tööriistu, mis hõlbustavad rakenduste arendamist ning selliste rakenduste saadavust ja hulka peetakse haldusplatvormi valikul väga oluliseks teguriks.

Süsteemid laia klassi võrkude jaoks

See on odavate süsteemide sektor võrkude jaoks, mis ei ole tõrgete suhtes väga kriitilised. Siia kuuluvad FoundationAgentMulti-Port, Foundation Probe, NetworkGenerali fondihaldur. Need on täielik RMON-põhine võrgujälgimissüsteem ja sisaldavad kahte tüüpi monitori agente – FoundationAgent ja FoundationProbe, aga ka FoundationManageri operaatorikonsooli.

FoundationAgentMulti-Port toetab kõiki standardse SNMP agendi ja täiustatud andmete kogumise ja filtreerimissüsteemi funktsioone ning võimaldab teil koguda teavet ka Etherneti või TokenRingi segmentidest ühe arvuti abil.

FoundationProbe on sertifitseeritud arvuti, millel on sertifitseeritud NIC ja eelinstallitud vastavat tüüpi FoundationAgent tarkvara. FoundationAgent ja FoundationProbe töötavad tavaliselt monitori ja klaviatuurita režiimis, kuna neid haldab tarkvara FoundationManager.

FoundationManageri konsoolitarkvara on saadaval kahes versioonis, üks Windowsile ja teine ​​UNIXile.

FoundationManageri konsool võimaldab graafiliselt kuvada statistikat kõigi jälgitavate võrgusegmentide kohta, määrata automaatselt keskmised võrguparameetrid ja reageerida lubatud parameetrite piiride ületamisele (näiteks käivitada käitleja programm, algatada SNMP-trap ja SNA-häire), luua graafiline dünaamiline liikluskaart jaamade vahel.

Süsteemid hajutatud võrkude jaoks

See on kallite tipptasemel süsteemide sektor, mis on mõeldud võrkude analüüsimiseks ja jälgimiseks kõrgeimate võimalike nõuetega töökindluse ja jõudluse tagamiseks. See sisaldab toodet DistributedSnifferSystem (DSS), mis koosneb mitmest võrgu kaudu levitatud riistvarakomponendist ja tarkvarast, mis on vajalik kõigi, sealhulgas kaugvõrgu segmentide pidevaks analüüsimiseks.

DSS-süsteem on üles ehitatud kahte tüüpi komponentidest – SnifferServer (SS) ja SniffMasterConsole (SM). Konsooliga suhtlemiseks saab liidestena kasutada Etherneti, TokenRingi või jadapordi kaarte. Seega on võimalik juhtida peaaegu iga võrgutopoloogia segmenti ja kasutada konsooliga suhtlemiseks erinevaid keskkondi, sealhulgas modemiühendusi.

Tarkvara SnifferServer koosneb kolmest alamsüsteemist – monitooringust, protokolli tõlgendamisest ja ekspertanalüüsist. Seire alamsüsteem on süsteem võrgu hetkeseisu kuvamiseks, mis võimaldab saada statistikat iga jaama ja võrgusegmendi kohta iga kasutatava protokolli kohta. Ülejäänud kaks alamsüsteemi väärivad eraldi arutelu.

Protokolli tõlgendamise alamsüsteemi funktsioonid hõlmavad hõivatud pakettide analüüsi ning paketipäiste iga välja ja selle sisu kõige täielikumat tõlgendamist. NetworkGeneral on loonud omataolise võimsaima alamsüsteemi - ProtocolInterpreter suudab täielikult dekodeerida enam kui 200 protokolli kõigist seitsmest ISO / OSI mudeli kihist (TCP / IP, IPX / SPX, NCP, DECnetSunNFS, X-Windows, SNAIBM protokoll perekond, AppleTalk, BanyanVINES, OSI, XNS, X.25, mitmesugused võrguprotokollid). Samal ajal saab teavet kuvada ühes kolmest režiimist - üldine, üksikasjalik ja kuueteistkümnendsüsteem.

Ekspertanalüüsisüsteemi (ExpertAnalysis) põhieesmärk on vähendada võrgu seisakuid ja kõrvaldada võrgu kitsaskohti, tuvastades automaatselt anomaalsed nähtused ja genereerides automaatselt meetodeid nende lahendamiseks.

ExpertAnalysis süsteem pakub seda, mida NetworkGeneral nimetab aktiivseks analüüsiks. Selle kontseptsiooni mõistmiseks kaaluge sama vigase sündmuse töötlemist võrgus traditsiooniliste passiivsete analüüsisüsteemide ja aktiivse analüüsisüsteemi abil.

Oletame, et kell 3:00 oli võrgus levitorm, mis põhjustas andmebaasi varundussüsteemi tõrke kell 3:05. Kell 4:00 torm peatub ja süsteemi parameetrid normaliseeruvad. Võrgus töötava passiivse liiklusanalüüsi süsteemi puhul pole kell 8.00 tööle tulnud administraatoritel midagi analüüsida peale teabe teise rikke kohta ja parimal juhul üldise öise liiklusstatistika – iga jäädvustamise suurus. puhver ei võimalda kogu öö jooksul võrgu kaudu edastatud liiklust salvestada. Tõenäosus sellises olukorras saatetormini viinud põhjuse kõrvaldamiseks on äärmiselt väike.

Vaatleme nüüd aktiivse analüüsisüsteemi reaktsiooni samadele sündmustele. Kell 03:00, kohe pärast saatetormi algust, tuvastab aktiivne analüüsisüsteem ebastandardse olukorra alguse, aktiveerib vastava eksperdi ning fikseerib andmebaasis tema antud info sündmuse ja selle põhjuste kohta. Kell 03:05 fikseeritakse uus ebastandardne olukord seoses arhiveerimissüsteemi rikkega ning fikseeritakse vastav info. Selle tulemusena saavad administraatorid kell 8.00 täieliku kirjelduse ilmnenud probleemidest, nende põhjustest ja soovitustest nende põhjuste kõrvaldamiseks.

Kaasaskantavad analüüsi- ja seiresüsteemid

Analüsaatori kaasaskantav versioon, mis on oma võimalustelt peaaegu sarnane DSS-iga, on rakendatud ExpertSnifferAnalyzeri (ESA) seeria toodetes, mida tuntakse ka kui TurboSnifferAnalyzer. DSS-seeria toodetest palju odavamalt pakub ESA administraatorile samad võimalused nagu täismahus DSS, kuid ainult selles võrgusegmendis, millega ESA on hetkel ühendatud. Olemasolevad versioonid pakuvad täielikku analüüsi, protokollide tõlgendamist, samuti ühendatud võrgusegmendi või segmentidevahelise sideliini jälgimist. Toetatakse samu võrgutopoloogiaid, mis DSS-süsteemide puhul. Reeglina kasutatakse ESA-sid mittekriitiliste võrgusegmentide perioodiliseks kontrollimiseks, mille puhul ei ole otstarbekas pidevalt analüsaatorit kasutada.

Novell LANalyser Protocol Analyzer

LANalyser tarnitakse võrguplaadi ja tarkvarana, mis tuleb installida personaalarvutisse, või arvutina, mille plaat ja tarkvara on juba installitud.

LANalyseril on välja töötatud kasutajasõbralik liides, mis võimaldab seadistada valitud töörežiimi. ApplicationLANalyser menüü on peamine tööriist pildistamisrežiimi konfigureerimiseks ja pakub valikut protokolle, filtreid, initsiaatoreid, häireid jne. See analüsaator võib töötada NetBIOS, SMB, NCP, NCPBurst, TCP/IP, DECnet, BanyanVINES, AppleTalk, XNS, SunNFS, ISO, EGP, NIS, SNA ja mõne muu protokolliga.

Lisaks sisaldab LANalyser ekspertsüsteemi, mis abistab kasutajat tõrkeotsingul.

Järeldus

Kõik ülaltoodud süsteemid on loomulikult vajalikud suurettevõtte võrgus, kuid need on liiga kohmakad organisatsioonidele, kus võrgukasutajate arv ei ületa 200-300 inimest. Pooled süsteemi funktsioonidest jäävad välja nõudmata ning jaotuskomplekti arve ehmatab pearaamatupidajat ja ettevõtte juhti. Pealegi on riistvaratõrgete ja süsteemi kitsaskohtade kontroll väikeses võrgus enamasti ühe-kahe administraatori võimuses ega vaja automatiseerimist.

Sellegipoolest peaks igasuguse mastaabiga võrgus meie arvates ühel või teisel kujul olemas olema võrguanalüüsi süsteem, tänu millele on administraatoril palju lihtsam oma majandust juhtida.

ComputerPress 7 "2001

ABSTRAKTNE

Käesolev dokument on tehniline projekt Gerkon LLC Verkhnepyshma linna avaliku andmeedastusvõrgu võrguseiresüsteemi arendamiseks ja juurutamiseks. Projekt hõlmas olemasolevate võrguseiresüsteemide uuringut, ettevõtte hetkeolukorra analüüsi ning põhjendas võrguseiresüsteemi konkreetsete komponentide valikut.

Dokument sisaldab projekteerimislahenduste kirjeldust ja seadmete spetsifikatsioone.

Disaini tulemuseks on välja töötatud lahendused süsteemi juurutamiseks ja kasutamiseks:

§ Süsteemi projekteerimise, arendamise ja rakendamise kõigi etappide täielik kirjeldus;

§ Süsteemihaldusjuhend, mis sisaldab süsteemi kasutajaliidese kirjeldust.

See dokument esindab terviklahendusi ja seda saab kasutada süsteemi juurutamiseks.

GRAAFILISTE DOKUMENTIDE LEHTIDE LOETELU

Tabel 1 - Graafiliste dokumentide lehtede loend

1 -süsteem võrguseire220100 4010002võrgu loogiline struktuur220100 4010003võrgu jälgimise ja teavituste tuuma algoritm 220100 4010004 võrguliideste laadimisanalüsaatori struktuur220100 4010005 süsteemide ajakiri Event240010100t

SÜMBOLIDE JA TERMINITE LOETELU

Ethernet on IEEE välja antud andmeedastusstandard. Määrab, kuidas andmeid ühiselt sidemeediumilt saata või vastu võtta. Moodustab madalama transpordikihi ja seda kasutavad erinevad kõrgema taseme protokollid. Pakub andmeedastuskiirust 10Mbps.

Fast Ethernet on 100 Mbps andmeedastustehnoloogia, mis kasutab CSMA/CD meetodit, nagu ka 10Base-T.

FDDI – Fiber Distributed Data Interface – fiiberoptiline hajutatud andmeedastusliides – andmeedastustehnoloogia kiirusega 100 Mbps token ring meetodil.

IEEE – Institute of Electrical and Electronic Engineers (Institute of Electrical and Electronic Engineers) – organisatsioon, mis töötab välja ja avaldab standardeid.

LAN – Local Area Network – kohtvõrk, LAN. aadress – Media Access Control – võrguseadme identifitseerimisnumber, mille määrab tavaliselt tootja.

RFC – Request for Comments – IEEE organisatsiooni väljastatud dokumentide kogum, mis sisaldab standardite, spetsifikatsioonide jms kirjeldust.

TCP / IP - edastuse juhtimisprotokoll / Interneti-protokoll - edastuse juhtimisprotokoll / Interneti-protokoll.

LAN – kohtvõrk.

OS – operatsioonisüsteem.

ON – tarkvara.

SCS – struktureeritud kaabeldussüsteem.

DBMS – andmebaasihaldussüsteem.

Trend – Pikaajaline statistika, mis võimaldab ehitada nn trendi.

ARVUTI – elektrooniline arvuti.

SISSEJUHATUS

Kaasaegse ettevõtte infoinfrastruktuur on mitmesuguse ulatusega ja mitmekesisusega võrkude ja süsteemide kompleksne konglomeraat. Nende tõrgeteta ja tõhusaks toimimiseks on teil vaja integreeritud tööriistadega ettevõttetasandi haldusplatvormi. Kuid kuni viimase ajani takistas võrguhalduse tööstuse struktuur selliste süsteemide loomist - selle turu "mängijad" püüdsid juhtida piiratud ulatusega tooteid, kasutades tööriistu ja tehnoloogiaid, mis ei ühildu teiste süsteemidega. müüjad.

Tänapäeval on olukord muutumas paremuse poole – on tooteid, mis väidetavalt haldavad universaalselt kõiki ettevõtte teaberessursse, alates lauaarvutisüsteemidest kuni suurarvutiteni ja kohalikest võrkudest kuni võrguressurssideni. Samal ajal saabub arusaam, et juhtimisrakendused peavad olema avatud kõikide tarnijate lahendustele.

Antud töö aktuaalsus on tingitud asjaolust, et seoses personaalarvutite leviku ja nende baasil automatiseeritud tööjaamade (AWP) loomisega on suurenenud kohtvõrkude (LAN) tähtsus, mille diagnostika on meie uuringu objekt. Uurimistöö teemaks on kaasaegsete arvutivõrkude organiseerimise ja diagnostika peamised meetodid.

"Kohaliku võrgu diagnostika" - infovõrgu seisundi (pideva) analüüsimise protsess. Võrguseadmete rikke korral registreeritakse rikke fakt, määratakse selle asukoht ja tüüp. Veateade edastatakse, seade lülitatakse välja ja asendatakse varukoopiaga.

Võrguadministraator, kes kõige sagedamini vastutab diagnoosimise eest, peaks hakkama oma võrgu funktsioone uurima juba selle moodustamise etapis, s.t. teadma võrguskeemi ja tarkvara konfiguratsiooni üksikasjalikku kirjeldust, näidates ära kõik parameetrid ja liidesed. Selle teabe registreerimiseks ja säilitamiseks sobivad spetsiaalsed võrgudokumentatsioonisüsteemid. Neid kasutades on süsteemiadministraatoril ette teada kõik oma süsteemi võimalikud "varjatud defektid" ja "pudelikaelad", et ta saaks hädaolukorras teada, milles on riist- või tarkvara probleem, programm on kahjustatud. või viinud veani.operaatori toimingud.

Võrguadministraator peaks meeles pidama, et kasutajate seisukohalt on määrav võrgus oleva rakendustarkvara kvaliteet. Kõik muud kriteeriumid, nagu andmeedastusvigade arv, võrgu ressursi kasutamise määr, seadmete jõudlus jne, on teisejärgulised. "Hea võrk" on selline, mille kasutajad ei märka selle toimimist.

Ettevõte

Lõpetamiseelne praktika toimus ettevõttes Gerkon LLC tugiosakonnas süsteemiadministraatorina. Ettevõte on pakkunud Interneti-juurdepääsu teenuseid Verkhnyaya Pyshma ja Sredneuralski linnades, kasutades Etherneti tehnoloogiat ja sissehelistamiskanaleid alates 1993. aastast ning on üks esimesi Interneti-teenuse pakkujaid neis linnades. Teenuste osutamise eeskirjad on reguleeritud avaliku pakkumise ja määrustega.

Jaoskonna teaduslikud ja tootmisülesanded

Tugiosakond lahendab ettevõttes järgmisi ülesandeid:

§ Interneti-juurdepääsu võimaldamise tehniline ja tehnoloogiline korraldamine sissehelistamis- ja spetsiaalsete kanalite kaudu;

§ juhtmeta Interneti-juurdepääsu tehniline ja tehnoloogiline korraldamine;

§ kettaruumi eraldamine saitide salvestamiseks ja käitamiseks (hostimine);

§ postkastide või virtuaalse meiliserveri tugi;

§ kliendi seadmete paigutamine teenusepakkuja asukohta (kolokatsioon);

§ spetsiaalsete ja virtuaalserverite rentimine;

§ andmete varundamine;

§ eraettevõtete korporatiivsete võrkude juurutamine ja toetamine.

1. VÕRGU JÄRELEMISSÜSTEEMID

Vaatamata paljudele arvutivõrkude tuvastamise ja tõrkeotsingu tehnikatele ja vahenditele on võrguadministraatorite "maa jalge all" siiski üsna kõikuv. Arvutivõrgud sisaldavad üha enam fiiberoptilisi ja juhtmevabasid komponente, mis muudavad traditsioonilised tehnoloogiad ja tööriistad, mis on mõeldud tavapärase vaskkaabli jaoks, mõttetuks. Lisaks sellele ebaõnnestuvad traditsioonilised diagnostikameetodid kiirusel üle 100 Mbps sageli isegi siis, kui edastuskandjaks on tavaline vaskkaabel. Kuid võib-olla kõige olulisem muudatus arvutivõrgu tehnoloogias, millega administraatorid on pidanud silmitsi seisma, on olnud paratamatu üleminek jagatud Etherneti võrkudelt kommuteeritud võrkudele, kus üksikud serverid või tööjaamad toimivad sageli kommuteeritud segmentidena.

Tõsi, tehnoloogiliste ümberkujundamiste käigus lahenesid mõned vanad probleemid iseenesest. Koaksiaalkaabel, mille elektririkkeid on alati olnud keerulisem tuvastada kui keerdpaar, on ettevõtetes muutumas harulduseks. Token Ring võrgud, mille peamiseks probleemiks oli nende erinevus Ethernetiga (ja mitte üldse tehniline nõrkus), asendatakse järk-järgult kommuteeritud Etherneti võrkudega. Protokollid, mis genereerivad arvukalt võrgukihi protokolli veateateid, nagu SNA, DECnet ja AppleTalk, asendatakse IP-ga. IP-protokollivirn ise on muutunud stabiilsemaks ja hõlpsamini hooldatavaks, mida tõendavad miljonid kliendid ja miljardid veebilehed Internetis. Isegi Microsofti paadunud vastased peavad tunnistama, et uue Windowsi kliendi ühendamine Internetti on palju lihtsam ja töökindlam kui kolmanda osapoole TCP/IP-virnade ja eraldiseisva sissehelistamistarkvara installimine.

Nii raske kui tänapäeva tehnoloogiate tõrkeotsing ja võrgu jõudluse haldamine on, võib olukord olla veelgi kohutavam, kui pangaautomaatide tehnoloogia leviks arvutite tasemel. Positiivset rolli mängis ka see, et 90ndate lõpus, enne heakskiidu saavutamist, lükati tagasi ka mõned muud kiired andmevahetustehnoloogiad, sealhulgas Token Ring ribalaiusega 100 Mbps, 100VG-AnyLAN ja täiustatud ARCneti võrgud. Lõpuks lükati USA-s tagasi väga keerukas OSI-protokollipakk (mille on aga legaliseerinud mitmed Euroopa valitsused).

Vaatleme mõningaid kiireloomulisi probleeme, mis ettevõtete võrguadministraatoritel tekivad.

Gigabit Etherneti magistraalide ja 10 või isegi 100 Mbps spetsiaalsete kommutaatoriportidega arvutivõrkude hierarhiline topoloogia üksikute kliendisüsteemide jaoks võimaldas suurendada kasutajatele potentsiaalselt saadaolevat maksimaalset ribalaiust vähemalt 10-20 korda. Loomulikult on enamikus arvutivõrkudes kitsaskohti serverite või juurdepääsuruuterite tasemel, kuna ribalaius üksiku kasutaja kohta on oluliselt väiksem kui 10 Mbps. Seetõttu ei põhjusta 10 Mbps jaoturi pordi asendamine lõppsõlme jaoks mõeldud 100 Mbps lülitipordiga alati kiiruse märkimisväärset suurenemist. Kui aga arvate, et lülitite hind on viimasel ajal langenud ja enamik ettevõtteid on paigaldanud 5. kategooria kaabli, mis toetab 100 Mbps Etherneti tehnoloogiat, ja installinud võrgukaardid, mis võivad töötada kiirusega 100 Mbps kohe pärast süsteemi taaskäivitamist, saab sellest see. on selge, miks on nii raske moderniseerimise kiusatusele vastu seista. Traditsioonilises jagatud kohtvõrgus saab protokolli analüsaator või monitor uurida kogu liiklust antud võrgusegmendis.

Riis. 1.1 - Traditsiooniline kohtvõrk jagatud meedia ja protokolli analüsaatoriga

Kuigi kommuteeritud võrgu jõudluse eelised on mõnikord peened, on kommuteeritud arhitektuuride levik olnud traditsiooniliste diagnostikavahendite jaoks hukatuslik. Tugevalt segmenteeritud võrgus suudavad protokolli nuusutajad näha unicast liiklust ainult ühes lülituspordis, erinevalt pärandvõrgu topoloogiast, kus nad saaksid kontrollida mis tahes paketti põrkepiirkonnas. Sellistel tingimustel ei saa traditsioonilised seirevahendid koguda statistikat kõigi "vestluste" kohta, kuna iga "rääkiv" lõpp-punkti paar kasutab tegelikult oma võrku.

Riis. 1.2 - kommuteeritud võrk

Kommuteeritud võrgus saab protokollianalüsaator ühes punktis "näha" ainult ühte segmenti, kui lüliti ei ole võimeline peegeldama mitut porti korraga.

Tugevalt segmenteeritud võrkude üle kontrolli säilitamiseks pakuvad lülitusmüüjad mitmesuguseid tööriistu võrgu täieliku nähtavuse taastamiseks, kuid sellel teel on palju väljakutseid. Nüüd tarnitavad lülitid toetavad tavaliselt "peegeldavaid" porte, kui neist ühe liiklus dubleeritakse varem kasutamata pordis, kuhu on ühendatud monitor või analüsaator.

"Peegeldamisel" on aga mitmeid puudusi. Esiteks on korraga nähtav ainult üks port, mistõttu on väga raske tuvastada probleeme, mis mõjutavad mitut porti korraga. Teiseks võib peegeldamine halvendada lüliti jõudlust. Kolmandaks, füüsilise kihi tõrkeid peegelpordis tavaliselt ei reprodutseerita ja mõnikord lähevad VLAN-i tähised isegi kaduma. Lõpuks ei saa paljudel juhtudel täisdupleksseid Etherneti linke täielikult peegeldada.

Osaline lahendus liikluse koondparameetrite analüüsimisel on kasutada mini-RMON agentide jälgimisvõimalusi, eriti kuna need on sisse ehitatud enamiku Etherneti kommutaatorite igasse porti. Kuigi mini-RMON agendid ei toeta RMON II Capture objektide rühma, mis pakub täielikku protokollianalüüsi, saavad nad siiski hinnata ressursikasutust, veamäärasid ja multisaadete mahtu.

Mõningaid pordi peegeldamise tehnoloogia puudusi saab ületada "passiivsete kraanide" paigaldamisega, näiteks Shomiti omadega. Need seadmed on eelinstallitud Y-pistikud ja võimaldavad protokollianalüsaatoritel või muudel seadmetel jälgida tegelikku signaali, mitte regenereeritud signaali.

Järgmine tegelik probleem on probleem optika omadustega. Arvutivõrgu administraatorid kasutavad tavaliselt spetsiaalseid optilise võrgu diagnostikaseadmeid ainult optilise kaabli probleemide tõrkeotsinguks. Tavaline standardne SNMP- või CLI-põhine seadmehaldustarkvara suudab tuvastada probleeme optiliste liidestega lülitites ja ruuterites. Ja ainult vähesed võrguadministraatorid seisavad silmitsi vajadusega SONET-seadmeid diagnoosida.

Fiiberoptiliste kaablite puhul on nende võimalike rikete tekkepõhjuseid oluliselt vähem kui vaskkaabli puhul. Optilised signaalid ei põhjusta ülekõla, mis tekib siis, kui ühel juhil olev signaal kutsub esile signaali teises, mis muudab vaskkaabli diagnostikaseadmed kõige keerulisemaks. Optilised kaablid on immuunsed elektromagnetilise müra ja indutseeritud signaalide suhtes, mistõttu ei pea neid liftimootoritest ja luminofoorlampidest eemal asuma, st kõik need muutujad võib diagnostikastsenaariumist välja jätta.

Signaali tugevus või optiline võimsus antud punktis on tõesti ainus muutuja, mida tuleb optiliste võrkude tõrkeotsingul mõõta. Kui on võimalik määrata signaali kadu kogu optilises kanalis, on võimalik tuvastada peaaegu iga probleem. Vaskkaablitesterite odavad lisamoodulid võimaldavad optilisi mõõtmisi.

Ettevõtted, kes on kasutusele võtnud suure optilise infrastruktuuri ja hooldavad seda ise, võivad vajada ostma optilise ajadomeeni peegeldusmõõturi (OTDR), mis täidab optilise kiu puhul samu funktsioone kui vaskkaabli ajadomeeni peegeldusmõõtur (TDR). Seade toimib nagu radar: saadab mööda kaablit alla impulsssignaale ja analüüsib nende peegeldusi, mille põhjal tuvastab juhtmevead või mõne muu anomaalia ning annab seejärel asjatundjale teada, kust kaablist probleemi allikat otsida. .

Kuigi mitmesugused kaablipistikute ja pistikute müüjad on muutnud optilise kiu lõpetamise ja hargnemise lihtsamaks, nõuab see siiski teataval tasemel erioskusi ning usaldusväärse poliitika korral peab arenenud optilise infrastruktuuriga ettevõte oma töötajaid koolitama. Olenemata sellest, kui hästi kaabelvõrk on paigaldatud, on alati võimalus mõne ootamatu vahejuhtumi tagajärjel kaabel füüsiliselt kahjustada.

Samuti võib esineda tõrkeotsing 802.11b traadita kohtvõrkude kohta. Diagnostika ise on sama lihtne kui jaoturipõhiste Etherneti võrkude puhul, kuna traadita edastusmeedium on jagatud kõigi kliendi raadioseadmete omanike vahel. Sniffer TechHlogies oli esimene, kes pakkus selliste võrkude jaoks protokollianalüüsi lahendust kiirusega kuni 11 Mbps ja seejärel tutvustas enamik juhtivaid analüsaatorite müüjaid sarnaseid süsteeme.

Erinevalt juhtmega Etherneti jaoturist ei ole traadita kliendiühenduste kvaliteet kaugeltki ühtlane. Kõigis kohalikes edastustes kasutatavad mikrolaine raadiosignaalid on nõrgad ja mõnikord ettearvamatud. Isegi väikesed muutused antenni asendis võivad ühenduste kvaliteeti tõsiselt mõjutada. Juhtmevaba kohtvõrgu pöörduspunktid on varustatud seadmehalduskonsooliga ja see on sageli tõhusam diagnostikameetod kui traadita klientide külastamine ning läbilaskevõime ja veatingimuste jälgimine pihuanalüsaatoriga.

Kuigi pihuarvutite (PDA) kasutajate poolt kogetavad andmete sünkroonimise ja seadmete paigaldamise probleemid vastavad loomulikumalt tehnilise toe meeskonna kui võrguadministraatori ülesannetele, ei ole raske ette näha, et lähitulevikus paljud sellised seadmed arenevad täisvõrgu klientides eraldi arvutit täiendavatest abitööriistadest.

Üldjuhul takistavad (või peaksid) ettevõtete traadita võrguoperaatorid kasutama liiga avatud süsteeme, kus iga võrgu levialas oleva ühilduva liidesekaardiga kasutaja pääseb juurde süsteemi igale teaberaamile. WEP (Wired Equivalent Privacy) traadita turvaprotokoll pakub kasutaja autentimist, terviklikkuse tagamist ja andmete krüptimist, kuid nagu tavaliselt, muudab täiustatud turvalisus võrguprobleemide algpõhjuste analüüsimise keeruliseks. Turvalistes WEP-võrkudes peavad diagnostikud teadma võtmeid või paroole, mis kaitsevad teaberessursse ja kontrollivad juurdepääsu süsteemile. Kui pääsete juurde kõigi pakettide vastuvõturežiimis, näeb protokollianalüsaator kõiki kaadripäiseid, kuid neis sisalduv teave ilma võtmeteta on mõttetu.

Tunnellinkide diagnoosimisel, mida paljud müüjad nimetavad kaugjuurdepääsuga virtuaalseteks privaatvõrkudeks, on tekkivad probleemid sarnased krüptitud traadita võrkude analüüsimisel tekkivate probleemidega. Kui liiklus ei läbi tunneldatud ühendust, ei ole rikke põhjust lihtne kindlaks teha. See võib olla autentimisviga, tõrge mõnes lõpp-punktis või ummikus avalikus Interneti-tsoonis. Protokolli analüsaatori kasutamine tunneliliikluses kõrgetasemeliste vigade tuvastamiseks oleks raisatud jõupingutused, kuna andmete sisu, aga ka rakenduse, transpordi ja võrgukihi päised on krüpteeritud. Üldiselt muudavad ettevõtete võrkude turvalisuse parandamiseks võetud meetmed vigade ja jõudlusprobleemide tuvastamise keerulisemaks. Tulemüürid, puhverserverid ja sissetungimise tuvastamise süsteemid võivad tõrkeotsingut veelgi keerulisemaks muuta.

Seega on arvutivõrkude diagnoosimise probleem aktuaalne ja lõppkokkuvõttes on rikete diagnoosimine juhtimisülesanne. Enamiku missioonikriitiliste ettevõttesüsteemide jaoks on pikad taastamispüüdlused vastuvõetamatud, seega on ainus lahendus kasutada üleliigseid seadmeid ja protsesse, mis suudavad vajalikud funktsioonid üle võtta kohe pärast rikke ilmnemist. Mõnes ettevõttes on võrkudel alati täiendav üleliigne komponent juhuks, kui põhikomponent ebaõnnestub, st n x 2 komponenti, kus n on vastuvõetava jõudluse tagamiseks vajalike põhikomponentide arv. Kui keskmine remondiaeg (MTTR) on piisavalt kõrge, võib vaja minna rohkem koondamist. Asi on selles, et tõrkeotsingu aega ei ole lihtne ennustada ja märkimisväärsed kulud ettearvamatu taastumisperioodi jooksul on märk halvast juhtimisest.

Vähem kriitiliste süsteemide puhul ei pruugi koondamine olla majanduslikult tasuv, sel juhul on mõttekas investeerida kõige tõhusamatesse vahenditesse (ja personali koolitusse), et kiirendada tehase võimalikult kiiret diagnoosimise ja tõrkeotsingu protsessi. Lisaks saab teatud süsteemide tuge tellida väljast, kas ettevõttele allhanget tehes või väliste andmekeskuste võimalusi kasutades või rakendusteenuse pakkujate (ASP) või haldusteenuse pakkujatega ühendust võttes. Lisaks kuludele võib kõige olulisemaks teguriks, mis mõjutab otsust kasutada kolmandate osapoolte organisatsioonide teenuseid, pidada nende enda töötajate kompetentsi taset. Võrguadministraatorid peavad mõtlema, kas mõni konkreetne funktsioon on nii tihedalt seotud ettevõtte konkreetsete ülesannetega, et kolmanda osapoole spetsialistilt ei saa eeldada paremat tööd, kui seda teeksid ettevõtte töötajad.

Peaaegu kohe pärast esimeste korporatiivsete võrkude kasutuselevõttu, mille töökindlus jättis palju soovida, pakkusid tootjad ja arendajad välja "iseparanevate võrkude" kontseptsiooni. Kaasaegsed võrgud on kindlasti töökindlamad kui 90ndatel, kuid mitte sellepärast, et probleemid hakkasid iseenesest lahenema. Tarkvara- ja riistvaratõrgete tõrkeotsing tänapäeva võrkudes nõuab endiselt inimese sekkumist ning selles olukorras pole lähiajal põhimõttelist muutust ette näha. Diagnostikameetodid ja -vahendid on tänapäevaste tavade ja tehnoloogiatega üsna kooskõlas, kuid pole veel jõudnud tasemele, mis säästaks oluliselt võrguadministraatorite aega võrguprobleemide ja jõudluse puudujäägiga võitlemisel.

1.1 Diagnostikatarkvara

Arvutivõrkude diagnoosimise tarkvarast võib välja tuua spetsiaalsed võrguhaldussüsteemid (Network Management Systems) - tsentraliseeritud tarkvarasüsteemid, mis koguvad andmeid võrgusõlmede ja sideseadmete oleku kohta, samuti andmeid võrgus ringleva liikluse kohta. Need süsteemid mitte ainult ei jälgi ega analüüsi võrku, vaid teostavad ka automaat- või poolautomaatrežiimis võrguhaldustoiminguid – seadmete portide lubamine ja keelamine, sildade, kommutaatorite ja ruuterite aadressitabelite sillaparameetrite muutmine jne. Juhtimissüsteemide näideteks on populaarsed süsteemid HPOpenView, SunNetManager, IBMNetView.

Süsteemihaldustööriistad täidavad funktsioone, mis on sarnased juhtimissüsteemide funktsioonidega, kuid mis puudutavad sideseadmeid. Siiski võivad nende kahte tüüpi haldussüsteemide mõned funktsioonid kattuda, näiteks saavad süsteemihaldustööriistad teha lihtsat võrguliikluse analüüsi.

Ekspertsüsteemid. Seda tüüpi süsteemid koguvad inimeste teadmisi võrgu ebanormaalse töö põhjuste väljaselgitamise ja võimalike viiside kohta, kuidas võrk taastada terve oleku. Ekspertsüsteeme rakendatakse sageli erinevate võrgu jälgimise ja analüüsi tööriistade eraldi alamsüsteemidena: võrguhaldussüsteemid, protokollianalüsaatorid, võrguanalüsaatorid. Ekspertsüsteemi lihtsaim versioon on kontekstitundlik abisüsteem. Keerulisemad ekspertsüsteemid on tehisintellekti elementidega nn teadmusbaasid. Sellise süsteemi näide on Cabletroni Spectrum juhtimissüsteemi sisseehitatud ekspertsüsteem.

1.1.1 Protokolli analüsaatorid

Uue võrgu projekteerimisel või vana võrgu uuendamisel tuleb sageli mõõta mõningaid võrgu omadusi, nagu andmevoogude intensiivsus üle võrgu sideliinide, paketitöötluse eri etappides esinevad viivitused, reageerimisajad üht või teist liiki, teatud sündmuste esinemissagedust ja muid tunnuseid.

Nendel eesmärkidel saab kasutada erinevaid vahendeid ja eelkõige seirevahendeid võrguhaldussüsteemides, millest on juba varem juttu olnud. Mõningaid võrgus olevaid mõõtmisi saab teha ka operatsioonisüsteemi sisseehitatud tarkvaramõõturite abil, selle näiteks on Windows Performance Monitor OS komponent. Isegi tänapäevased kaablitestrid on võimelised jäädvustama pakette ja analüüsima nende sisu.

Kuid kõige arenenum võrguuuringute tööriist on protokolli analüsaator. Protokolli analüüsi protsess hõlmab võrgus ringlevate pakettide hõivamist, mis rakendavad teatud võrguprotokolli, ja nende pakettide sisu uurimist. Analüüsi tulemuste põhjal on võimalik teha mõistlikke ja tasakaalustatud muudatusi mistahes võrgukomponentides, optimeerida selle jõudlust ja lahendada probleeme. Ilmselgelt on selleks, et teha järeldusi muudatuse mõju kohta võrgule, protokolle analüüsida nii enne kui ka pärast muudatuse tegemist.

Protokollianalüsaator on kas iseseisev spetsialiseeritud seade või Htebook klassi personaalarvuti, tavaliselt kaasaskantav, mis on varustatud spetsiaalse võrgukaardi ja sellega seotud tarkvaraga. Kasutatav võrgukaart ja tarkvara peavad vastama võrgu topoloogiale (rõngas, siin, täht). Analüsaator ühendub võrku samamoodi nagu tavaline sõlm. Erinevus seisneb selles, et analüsaator suudab vastu võtta kõik võrgu kaudu edastatavad andmepaketid, tavajaam aga ainult talle adresseeritud. Analüsaatori tarkvara koosneb tuumast, mis toetab võrguadapteri tööd ja dekodeerib vastuvõetud andmeid ning täiendavast programmikoodist sõltuvalt uuritava võrgu topoloogia tüübist. Lisaks on kaasas mitmeid protokollispetsiifilisi dekodeerimisrutiine, näiteks IPX. Mõned analüsaatorid võivad sisaldada ka ekspertsüsteemi, mis võib anda kasutajale soovitusi, milliseid katseid antud olukorras läbi viia, mis võib tähendada teatud mõõtmistulemusi, kuidas teatud tüüpi võrgutõrkeid kõrvaldada.

Vaatamata turul olevate protokollianalüsaatorite suhtelisele mitmekesisusele on mõned funktsioonid, mis on mingil määral omased neile kõigile:

Kasutajaliides. Enamikul analüsaatoritest on välja töötatud kasutajasõbralik liides, mis põhineb tavaliselt Windowsil või Motiivil. See liides võimaldab kasutajal: kuvada liiklusintensiivsuse analüüsi tulemusi; saada vahetu ja keskmine statistiline hinnang võrgu jõudluse kohta; määrata teatud sündmused ja kriitilised olukorrad nende toimumise jälgimiseks; dekodeerida erineva tasemega protokolle ja esitada pakettide sisu arusaadaval kujul.

Jäädvustage puhver. Erinevate analüsaatorite puhvrid erinevad mahult. Puhver võib asuda installitud võrgukaardil või sellele võib eraldada ruumi mõne võrgus oleva arvuti RAM-is. Kui puhver asub võrgukaardil, siis juhib seda riistvara ja tänu sellele suurendatakse sisendkiirust. See aga toob kaasa analüsaatori maksumuse tõusu. Püüdmisprotseduuri ebapiisava täitmise korral läheb osa teabest kaotsi ja analüüs on võimatu. Puhvri suurus määrab võime analüüsida hõivatud andmete enam-vähem esinduslikke proove. Kuid ükskõik kui suur on püüdmispuhver, varem või hiljem see täitub. Sel juhul kas püüdmine peatub või täitmine algab puhvri algusest.

Filtrid. Filtrid võimaldavad teil juhtida andmete kogumise protsessi ja säästa seega puhverruumi. Olenevalt filtritingimusena määratud paketi teatud väljade väärtusest, paketti kas ignoreeritakse või kirjutatakse püüdmispuhvrisse. Filtrite kasutamine kiirendab ja lihtsustab oluliselt analüüsi, kuna välistab hetkel mittevajalike pakettide vaatamise.

Lülitid on teatud tingimused võrgust andmete kogumise protsessi käivitamiseks ja peatamiseks, mille on määranud operaator. Sellised tingimused võivad olla käsitsi käskude täitmine hõivamisprotsessi alustamiseks ja peatamiseks, kellaaeg, hõivamisprotsessi kestus, teatud väärtuste ilmumine andmekaadritesse. Lüliteid saab kasutada koos filtritega, mis võimaldab teha üksikasjalikumat ja peenemat analüüsi ning kasutada piiratud kogust püüdmispuhvrit produktiivsemalt.

Otsing. Mõned protokollianalüsaatorid võimaldavad automatiseerida puhvris oleva teabe ülevaatamist ja leida sealt andmeid vastavalt määratud kriteeriumidele. Kui filtrid kontrollivad sisendvoogu filtritingimuste suhtes, rakendatakse otsingufunktsioone puhvrisse juba kogutud andmetele.

Analüüsi metoodikat saab esitada järgmise kuue etapina:

Andmete kogumine.

Vaadake jäädvustatud andmeid.

Andmete analüüs.

Otsige vigu. (Enamik parsereid muudab selle töö lihtsamaks, tuvastades vigade tüübid ja tuvastades jaama, kust vigane pakett tuli.)

Tulemuslikkuse uuring. Arvutatakse võrgu ribalaiuse kasutus või päringule vastamise keskmine aeg.

Üksikasjalik uuring võrgu üksikute osade kohta. Selle etapi sisu täpsustatakse analüüsi läbiviimisel.

Tavaliselt võtab protokolli analüüsi protsess suhteliselt vähe aega – 1-2 tööpäeva.

Enamik kaasaegseid analüsaatoreid võimaldab analüüsida korraga mitut WAN-protokolli, nagu X.25, PPP, SLIP, SDLC/SNA, kaadrirelee, SMDS, ISDN, silla/ruuteri protokollid (3Com, Cisco, Bay Networks jt). Sellised analüsaatorid võimaldavad mõõta erinevaid protokolli parameetreid, analüüsida võrguliiklust, teisendada LAN- ja WAN-protokollide vahel, viivitada ruuteritel nende teisenduste ajal jne. Täiustatud seadmed võimaldavad simuleerida ja dekodeerida WAN-protokolle, "stress" testimist, mõõta maksimumi läbilaskevõime, pakutavate teenuste kvaliteedi testimine. Universaalsuse huvides rakendavad peaaegu kõik WAN-protokolli analüsaatorid LAN-i ja kõigi peamiste liideste testimise funktsioone. Mõned instrumendid on võimelised telefoniprotokolle analüüsima. Ja kõige kaasaegsemad mudelid suudavad kõiki seitset OSI kihti mugavalt dekodeerida ja esitada. ATM-i tulek on pannud tootjad pakkuma oma analüsaatoritele vahendeid nende võrkude testimiseks. Need seadmed suudavad täielikult testida E-1/E-3 sularahaautomaatide võrke koos seire- ja simulatsioonitoega. Analüsaatori teenindusfunktsioonide komplekt on väga oluline. Mõned neist, näiteks võimalus seadet kaugjuhtida, on lihtsalt asendamatud.

Seega suudavad kaasaegsed WAN/LAN/DTM-protokolli analüsaatorid tuvastada ruuterite ja sildade konfiguratsiooni vigu; määrake globaalse võrgu kaudu saadetava liikluse tüüp; määrata kasutatav kiirusvahemik, optimeerida ribalaiuse ja kanalite arvu suhet; lokaliseerida vale liikluse allikas; teostada jadaliidese testimist ja täielikku sularahaautomaatide testimist; teostada mis tahes kanalil põhiprotokollide täielikku jälgimist ja dekodeerimist; analüüsida reaalajas statistikat, sealhulgas LAN-liikluse analüüsi WAN-ide kaudu.

1.1.2 Seireprotokollid

SNMP-protokoll (inglise Simple Network Management Protocol – lihtne võrguhaldusprotokoll) on TCP / IP-arhitektuuril põhinev sidevõrkude haldamise protokoll.

TMN kontseptsiooni alusel 1980.-1990. erinevad standardiorganisatsioonid on välja töötanud mitmeid protokolle andmevõrkude haldamiseks, millel on erinev TMN-funktsioonide rakendusspekter. Üks sellise haldusprotokolli tüüp on SNMP. SNMP-protokoll töötati välja võrguruuterite ja sildade funktsionaalsuse testimiseks. Seejärel laienes protokolli ulatus ka teistele võrguseadmetele, nagu jaoturid, lüüsid, terminaliserverid, LAN Manageri serverid, Windows NT masinad jne. Lisaks võimaldab protokoll nende seadmete töös muudatusi teha.

See tehnoloogia on loodud sidevõrgu seadmete ja rakenduste haldamiseks ja juhtimiseks, vahetades juhtimisteavet võrguseadmetes asuvate agentide ja juhtimisjaamades asuvate haldurite vahel. SNMP defineerib võrgu kui võrguhaldusjaamade ja võrguelementide (hostid, lüüsid ja ruuterid, terminaliserverid) kogumit, mis koos pakuvad haldussuhtlust võrguhaldusjaamade ja võrguagentide vahel.

SNMP kasutamisel on hallatavad ja haldussüsteemid. Hallatav süsteem sisaldab komponenti, mida nimetatakse agendiks ja mis saadab aruandeid haldussüsteemi. Põhimõtteliselt edastavad SNMP agendid haldusteavet haldussüsteemidele muutujatena (nt "vaba mälu", "süsteemi nimi", "töötavate protsesside arv").

SNMP-protokolli agent on töötlemiselement, mis annab võrguhaldusjaamades asuvatele halduritele juurdepääsu MIB-muutujate väärtustele ja võimaldab neil seeläbi rakendada seadmehaldus- ja jälgimisfunktsioone.

Tarkvaraagent on residentprogramm, mis täidab haldusfunktsioone ja kogub ka statistikat selle ülekandmiseks võrguseadme infobaasi.

Riistvaraagent – ​​sisseehitatud riistvara (koos protsessori ja mäluga), mis salvestab tarkvaraagente.

SNMP kaudu juurdepääsetavad muutujad on korraldatud hierarhias. Neid hierarhiaid ja muid metaandmeid (nagu muutuja tüüp ja kirjeldus) kirjeldavad juhtimisteabe baasid (MIB).

Tänapäeval on juhtimisteabe andmebaaside jaoks mitu standardit. Peamised neist on MIB-I ja MIB-II standardid, samuti RMON MIB-i kaugjuhtimise andmebaasi versioon. Lisaks on olemas standardid teatud tüüpi spetsiaalsete seadmete MIB-ide jaoks (näiteks MIB-id jaoturite jaoks või MIB-id modemite jaoks), samuti konkreetsete seadmetootjate privaatsed MIB-id.

Algne MIB-I spetsifikatsioon määratles toimingud ainult muutujate väärtuste lugemiseks. Objekti väärtuste muutmise või määramise toimingud on osa MIB-II spetsifikatsioonidest.

MIB-I versioon (RFC 1156) määratleb kuni 114 objekti, mis on jagatud 8 rühma:

Süsteem – üldised andmed seadme kohta (näiteks hankija ID, viimane süsteemi lähtestamise aeg).

Liidesed – kirjeldab seadme võrguliideste parameetreid (näiteks nende arv, tüübid, vahetuskursid, maksimaalne paketi suurus).

AddressTranslationTable – kirjeldab võrgu- ja füüsiliste aadresside vastavust (näiteks ARP-protokolli kaudu).

InternetProtocol - IP-protokolliga seotud andmed (IP-lüüside aadressid, hostid, IP-pakettide statistika).

ICMP – ICMP juhtsõnumite vahetusprotokolliga seotud andmed.

TCP - TCP-protokolliga seotud andmed (näiteks TCP-ühenduste kohta).

UDP - UDP-protokolliga seotud andmed (edastatud, vastuvõetud ja vigadega UPD datagrammide arv).

EGP - Internetis kasutatava marsruutimise infovahetusprotokolliga ExteriorGatewayProtocol seotud andmed (vigadega ja vigadeta vastuvõetud sõnumite arv).

Sellest muutujarühmade loendist on näha, et MIB-I standard töötati välja, keskendudes tugevalt TCP/IP-virna protokolle toetavate ruuterite haldamisele.

1992. aastal vastu võetud versioonis MIB-II (RFC 1213) laiendati standardobjektide komplekti oluliselt (kuni 185-ni) ja rühmade arv suurenes 10-ni.

RMON agendid

SNMP-funktsioonide uusim täiendus on RMON-spetsifikatsioon, mis pakub kaugsuhtlust MIB-ga.

RMON-standard võeti kasutusele 1991. aasta novembris, kui Interneti-tehnoloogia töörühm andis välja RFC 1271 pealkirjaga "Remote Network Monitoring Management Information Base". See dokument sisaldas Etherneti võrkude RMON-i kirjeldust – arvutivõrkude jälgimise protokolli, SNMP laiendust, mis sarnaselt SNMP-ga põhineb teabe kogumisel ja analüüsil võrgu kaudu edastatava teabe olemuse kohta. Nagu SNMP puhul, koguvad teavet riist- ja tarkvaraagendid, mille andmed saadetakse arvutisse, kuhu võrguhaldusrakendus on installitud. Erinevus RMON-i ja selle eelkäija vahel seisneb ennekõike kogutava teabe olemuses - kui SNMP-s iseloomustab see teave ainult sündmusi, mis toimuvad seadmes, kuhu agent on installitud, siis RMON nõuab, et saadud andmed iseloomustaksid võrkude vahelist liiklust. seadmeid.

Enne RMONi tulekut ei saanud SNMP-d eemalt kasutada, see võimaldas ainult kohalikku seadmehaldust. RMON MIB-il on täiustatud atribuutide komplekt kaughalduse jaoks, kuna see sisaldab seadme kohta koondatud teavet, mis ei nõua suurte teabekoguste ülekandmist võrgu kaudu. RMON MIB objektide hulka kuuluvad täiendavad pakettide vealoendurid, paindlikumad graafilised trendid ja statistika analüüs, võimsamad filtreerimistööriistad üksikute pakettide hõivamiseks ja analüüsimiseks ning keerukamad hoiatustingimused. RMON MIB agendid on intelligentsemad kui MIB-I või MIB-II agendid ja täidavad suure osa seadme teabe töötlemise tööst, mida haldurid varem tegid. Need agendid võivad asuda erinevates sideseadmetes, samuti saab neid rakendada eraldi tarkvaramoodulitena, mis töötavad universaalsetes personaalarvutites ja sülearvutites (näiteks võib olla LANalyzerНvell).

RMON agentide intelligentsus võimaldab neil teha lihtsaid tõrkeotsingu ja hoiatustoiminguid - näiteks RMON-tehnoloogia raames saate koguda andmeid võrgu normaalse toimimise kohta (st teha nn baasjoonimist) ja seejärel väljastada. hoiatussignaalid, kui võrgu töörežiim kaldub algtasemest kõrvale – see võib viidata eelkõige sellele, et seadmed ei ole täielikult töökorras. RMON-agentidelt teavet koondades võib haldusrakendus aidata võrguadministraatoril (näiteks tuhandete miilide kaugusel) probleemi asukoha leida ja selle lahendamiseks välja töötada parima tegevusplaani.

RMON-teavet koguvad otse võrku ühendatud riist- ja tarkvarasondid. Andmete kogumise ja esmase analüüsi ülesande täitmiseks peab sondil olema piisavalt arvutusressursse ja RAM-i. Praegu on turul kolme tüüpi sonde: sisseehitatud sondid, arvutipõhised sondid ja eraldiseisvad sondid. Toode loetakse RMON-toega, kui see rakendab vähemalt ühte RMON-rühma. Muidugi, mida rohkem RMON-i andmerühmi antud tootes rakendatakse, seda kallim see ühelt poolt on ja teisest küljest seda täielikumat teavet võrgu toimimise kohta see annab.

Sisseehitatud sondid on võrguseadmete laiendusmoodulid. Selliseid mooduleid toodavad paljud tootjad, eriti sellised suured ettevõtted nagu 3Com, Cabletron, Bay Networks ja Cisco. (Muide, 3Com ja Bay Networks ostsid hiljuti Axoni ja ARMONi, mis on tunnustatud juhid RMON-i haldustööriistade disainis ja valmistamises. Suurte võrguseadmete tootjate huvi selle tehnoloogia vastu näitab taaskord, kui vajalik on kaugseire kasutajatele.) Enamik otsuseid RMON-moodulite jaoturitesse põimimine tundub loomulik, sest just neid seadmeid jälgides saab aimu segmendi tööst. Selliste sondide eelis on ilmne: need võimaldavad saada teavet kõigi suuremate RMON-i andmerühmade kohta suhteliselt madala hinnaga. Esiteks on puuduseks mitte liiga kõrge jõudlus, mis väljendub eelkõige selles, et sisseehitatud sondid toetavad sageli mitte kõiki RMON-i andmerühmi. Mitte kaua aega tagasi teatas 3Com oma kavatsusest vabastada Etherlink III ja Fast Etherneti võrguadapterite jaoks RMON-toega draiverid. Selle tulemusena on võimalik koguda ja analüüsida RMON-andmeid otse võrgu tööjaamadest.

Arvutipõhised sondid on lihtsalt võrku ühendatud arvutid, millesse on installitud RMON-tarkvaraagent. Need sondid (nt Network Generali Cornerstone Agent 2.5) on kiiremad kui sisseehitatud sondid ja toetavad tavaliselt kõiki RMON-i andmerühmi. Need on kallimad kui sisseehitatud sondid, kuid palju odavamad kui eraldiseisvad sondid. Lisaks on arvutipõhised sondid üsna suured, mis võib mõnikord piirata nende kasutamist.

Eraldiseisvad sondid on kõrgeima jõudlusega; Nagu on lihtne mõista, on need samal ajal kõige kallimad tooted kõigist kirjeldatud toodetest. Tavaliselt on eraldiseisev sond protsessor (i486-klassi või RISC-protsessor), mis on varustatud piisava RAM-i ja võrguadapteriga. Selle turusektori liidrid on Frontier ja Hewlett-Packard. Seda tüüpi sondid on väikese suurusega ja väga mobiilsed – neid on väga lihtne võrku ühendada ja lahti ühendada. Globaalse võrguhaldusprobleemi lahendamisel pole see muidugi väga oluline omadus, kuid kui keskmise suurusega ettevõtte võrgu toimimise analüüsimiseks kasutatakse RMON-i tööriistu, siis (arvestades seadmete kõrget hinda) on sondi mobiilsus. võib mängida väga positiivset rolli.

RMON-objektile omistatakse MIB-objektikomplektis number 16 ja RMON-objekt ise on koondatud vastavalt RFC 1271-le, koosneb kümnest andmerühmast.

Statistika – jooksev kogutud statistika pakettide omaduste, kokkupõrgete arvu jms kohta.

Ajalugu - teatud ajavahemike järel salvestatud statistilised andmed nende muutuste suundumuste hilisemaks analüüsimiseks.

Häired – statistilised läved, mille ületamisel saadab RMON agent haldurile teate. Võimaldab kasutajal määrata mitmeid lävitasemeid (need läved võivad viidata mitmesugustele asjadele – mis tahes parameetrile statistikarühmast, selle muutumise amplituudile või kiirusele ja paljule muule), mille ületamisel genereeritakse häire. Samuti saab kasutaja määrata, millistel tingimustel peaks läviväärtuse ületamisel kaasnema häiresignaal – nii väldite "millegi eest" signaali teket, mis on halb esiteks seetõttu, et keegi ei pööra pidevalt põlemisele tähelepanu. punane tuli ja teiseks , kuna tarbetute häirete edastamine üle võrgu toob kaasa sideliinide tarbetu koormuse. Häire edastatakse tavaliselt sündmuste gruppi, kus määratakse, mida sellega edasi teha.

Host – andmed võrgu hostide kohta, sealhulgas nende MAC-aadressid.

HostTopN - võrgu kõige aktiivsemate hostide tabel. Tabel N top hosts (HostTopN) sisaldab N populaarseimat hosti loendit, mida iseloomustab antud statistilise parameetri maksimaalne väärtus antud intervalli kohta. Näiteks saate taotleda loendit 10 hostist, millel on viimase 24 tunni jooksul esinenud kõige rohkem vigu. Selle loendi koostab agent ise ja haldusrakendus saab ainult nende hostide aadressid ja vastavate statistiliste parameetrite väärtused. On näha, mil määral säästab selline lähenemine võrguressursse.

TrafficMatrix – iga võrguhosti paari vahelise liikluse intensiivsuse statistika, mis on järjestatud maatriksi kujul. Selle maatriksi read nummerdatakse vastavalt sõnumiallikateks olevate jaamade MAC-aadressidele ja veerud nummerdatakse vastavalt vastuvõtujaamade aadressidele. Maatriksielemendid iseloomustavad vastavate jaamade vahelise liikluse intensiivsust ja vigade arvu. Pärast sellise maatriksi analüüsimist saab kasutaja hõlpsalt teada, millised jaamapaarid tekitavad kõige intensiivsema liikluse. Selle maatriksi moodustab jällegi agent ise, seega pole vaja edastada suuri andmemahtusid võrgu haldamise eest vastutavasse keskarvutisse.

Filter – pakettide filtreerimise tingimused. Pakettide filtreerimise kriteeriumid võivad olla väga erinevad – näiteks võite nõuda kõigi pakettide vigaste filtreerimist, mille pikkus on väiksem kui mõni määratud väärtus. Võime öelda, et filtri paigaldamine vastab justkui paketi edastamise kanali korraldamisele. Kuhu see kanal viib, määrab kasutaja. Näiteks saab kõik vigased paketid kinni püüda ja vastavasse puhvrisse saata. Lisaks saab määratud filtrile vastava paketi ilmumist käsitleda sündmusena (sündmusena), millele süsteem peab reageerima etteantud viisil.

PacketCapture – pakettide hõivamise tingimused. Pakettide püüdmise grupp sisaldab püüdmispuhvreid, kuhu saadetakse paketid, mille omadused vastavad filtrirühmas sõnastatud tingimustele. Sel juhul ei pruugita jäädvustada kogu paketti, vaid näiteks ainult paketi paarkümmend esimest baiti. Pealtkuulamispuhvrite sisu saab hiljem erinevate tarkvaratööriistade abil analüüsida, paljastades mitmeid võrgu väga kasulikke omadusi. Teatud märkide jaoks filtreid ümber paigutades on võimalik iseloomustada võrgu toimimise erinevaid parameetreid.

Sündmus - sündmuste registreerimise ja genereerimise tingimused. Sündmuste rühmas (sündmused) määratakse kindlaks, millal tuleb haldusrakendusele häire saata, millal - pakettide pealtkuulamiseks ja üldiselt - kuidas reageerida teatud võrgus toimuvatele sündmustele, näiteks läve ületamisele. häirete rühmas määratud väärtused: kas seada teadmised haldusrakendusest või peate lihtsalt selle sündmuse logima ja töötama. Sündmused võivad, aga ei pruugi olla seotud häirete edastamisega – näiteks paketi saatmine püüdmispuhvrisse on samuti sündmus.

Need rühmad on nummerdatud selles järjekorras, nii et näiteks rühma Hosts on numbriline nimi 1.3.6.1.2.1.16.4.

Kümnes rühm koosneb TokenRingi protokolli eriobjektidest.

Kokku määratleb RMON MIB standard umbes 200 objekti 10 rühmana, mis on fikseeritud kahes dokumendis - RFC 1271 Etherneti võrkude jaoks ja RFC 1513 TokenRing võrkude jaoks.

RMON MIB standardi eripäraks on selle sõltumatus võrgukihi protokollist (erinevalt MIB-I ja MIB-II standarditest, mis on orienteeritud TCP/IP protokollidele). Seetõttu on seda mugav kasutada heterogeensetes keskkondades, kasutades erinevaid võrgukihi protokolle.

1.2 Populaarsed võrguhaldussüsteemid

Võrguhaldussüsteem – riist- ja/või tarkvaratööriistad võrgusõlmede jälgimiseks ja haldamiseks. Võrguhaldussüsteemi tarkvara koosneb agentidest, mis on lokaliseeritud võrguseadmetes ja edastavad teavet võrguhaldusplatvormile. Juhtrakenduste ja seadmetes olevate agentide vahelise teabevahetuse meetod on määratletud protokollidega.

Võrguhaldussüsteemidel peab olema mitmeid omadusi:

tõeline jaotus vastavalt kliendi/serveri kontseptsioonile,

skaleeritavus

avatus toime tulla heterogeensete - lauaarvutitest suurarvutiteni - seadmetega.

Esimesed kaks omadust on omavahel tihedalt seotud. Hea mastaapsus saavutatakse tänu juhtimissüsteemi jaotusele. Distributed tähendab, et süsteem võib sisaldada mitut serverit ja klienti. Serverid (haldurid) koguvad võrguseadmetesse sisseehitatud agentidelt (SNMP, CMIP või RMON) andmeid võrgu hetkeseisu kohta ja koguvad need oma andmebaasi. Kliendid on graafilised konsoolid, mida kasutavad võrguadministraatorid. Juhtimissüsteemi klienttarkvara võtab administraatorilt vastu taotlusi mis tahes toimingu sooritamiseks (näiteks võrguosa üksikasjaliku kaardi koostamine) ja nõuab serverilt vajalikku teavet. Kui serveril on vajalik info olemas, siis edastab ta selle kohe kliendile, kui ei, siis proovib seda agentidelt koguda.

Haldussüsteemide varasemad versioonid ühendasid kõik funktsioonid ühes arvutis, mida kasutas administraator. Väikeste võrkude või väikese hallatava varustusega võrkude puhul osutub see struktuur üsna rahuldavaks, kuid suure hulga hallatavate seadmete puhul muutub kitsaskohaks üksainus arvuti, kuhu info liigub kõikidest võrguseadmetest. Ja võrk ei suuda suure andmevooga toime tulla ja arvutil endal pole aega neid töödelda. Lisaks haldab suurt võrku tavaliselt rohkem kui üks administraator, seetõttu peaks suures võrgus lisaks mitmele serverile olema mitu konsooli, mille taga töötavad võrguadministraatorid ning iga konsool peaks esitama konkreetset infot, mis vastab hetkevajadustele. konkreetse administraatori kohta.

Heterogeensete seadmete toetamine on tänapäeva juhtimissüsteemides pigem soov kui reaalsus. Neli populaarseimat võrguhaldustoodet on Cabletron Systemsi Spectrum, Hewlett-Packardi OpenView, IBM-i NetView ja SunMicrosystemsi divisjoni SunSofti Solstice. Kolm ettevõtet neljast toodavad sideseadmeid ise. Loomulikult töötab Spectrum kõige paremini Cabletroni seadmetega, OpenView koos Hewlett-Packardi seadmetega ja NetView IBMi seadmetega.

Teiste tootjate seadmetest koosneva võrgukaardi koostamisel hakkavad need süsteemid tegema vigu ja võtma ühe seadme teise vastu ning nende seadmete haldamisel toetavad nad ainult nende põhifunktsioone ja palju kasulikke lisafunktsioone, mis eristavad seda seadet puhata, juhtimissüsteem on lihtne, ei saa aru ja seetõttu ei saa neid kasutada.

Selle puuduse parandamiseks toetavad juhtimissüsteemide arendajad mitte ainult standardseid MIB I, MIB II ja RMON MIB-e, vaid ka arvukaid tootmisettevõtete patenteeritud MIB-e. Selle valdkonna liider on Spectrum süsteem, mis toetab umbes 1000 erinevate tootjate MIB-d.

Teine võimalus konkreetse seadme paremaks toetamiseks on kasutada seda seadet tootva ettevõtte rakendust, mis põhineb mõnel juhtimisplatvormil. Juhtivad ettevõtted - sideseadmete tootjad - on oma seadmete jaoks välja töötanud ja tarninud väga keerukaid ja multifunktsionaalseid juhtimissüsteeme. Selle klassi tuntuimate süsteemide hulka kuuluvad Optiivity firmalt BayNetworks, CiscoWorks firmalt CiscoSystems ja Transcend firmalt 3Com. Optiivity süsteem võimaldab näiteks jälgida ja hallata BayNetworki ruuteritest, kommutaatoritest ja jaoturitest koosnevaid võrke, kasutades ära nende kõiki võimalusi ja omadusi. Põhiliste juhtimisfunktsioonide tasemel toetatakse teiste tootjate seadmeid. Optiivity süsteem töötab Hewlett-Packardi OpenView ja SunSofti SunNetManager (Solstice'i eelkäija) platvormidel. Mis tahes mitmest süsteemist koosneva juhtimisplatvormi (nt Optiivity) käitamine on aga liiga keeruline ja nõuab, et seda kõike käivitavatel arvutitel oleks väga võimsad protsessorid ja palju muutmälu.

Kui aga võrgus domineerivad ühe tootja seadmed, võimaldab selle tootja haldusrakenduste olemasolu populaarse haldusplatvormi jaoks võrguadministraatoritel edukalt täita paljusid ülesandeid. Seetõttu tarnivad haldusplatvormide arendajad endaga kaasa tööriistu, mis hõlbustavad rakenduste arendamist ning selliste rakenduste saadavust ja hulka peetakse haldusplatvormi valikul väga oluliseks teguriks.

Haldusplatvormi avatus oleneb ka sellest, millisel kujul kogutud andmeid võrgu seisukorra kohta talletatakse. Enamik juhtivaid platvorme võimaldab salvestada andmeid kommertsandmebaasides, nagu Oracle, Ingres või Informix. Universaalse DBMS-i kasutamine vähendab juhtimissüsteemi kiirust võrreldes andmete salvestamisega operatsioonisüsteemi failidesse, kuid võimaldab neid andmeid töödelda mis tahes rakendustega, mis võivad nende DBMS-idega töötada.

2. PROBLEEMIDE VÄLJAKIRJELDUS

Vastavalt hetkeolukorrale otsustati välja töötada ja juurutada võrguseiresüsteem, mis lahendaks kõik eelnimetatud probleemid.

2.1 Lähtetingimused

Töötada välja ja juurutada seiresüsteem, mis võimaldab jälgida nii lüliteid, erinevate tootjate ruutereid kui ka erinevate platvormide servereid. Keskenduge avatud protokollide ja süsteemide kasutamisele, kasutades maksimaalselt ära vabatarkvarafondi valmisarendusi.

2.2 Täpsustatud lähteülesanne

Probleemi edasise sõnastamise ja ainevaldkonna uurimise käigus, arvestades majandus- ja ajainvesteeringuid, viidi läbi lähteülesande täpsustamine:

Süsteem peab vastama järgmistele nõuetele:

§ miinimumnõuded riistvararessurssidele;

§ kompleksi kõigi komponentide avatud lähtekoodid;

§ süsteemi laiendatavus ja skaleeritavus;

§ standardsed diagnostilise teabe edastamise vahendid;

§ üksikasjaliku dokumentatsiooni olemasolu kõigi kasutatud tarkvaratoodete kohta;

§ Võimalus töötada erinevate tootjate seadmetega.

3. KAVANDATAVAD SÜSTEEM

1 Võrgu jälgimissüsteemi valimine

Vastavalt muudetud lähteülesannetele sobib Nagiose süsteem kõige paremini võrgu jälgimissüsteemi tuumaks, kuna sellel on järgmised omadused:

§ on olemas vahendid diagrammide koostamiseks;

§ on olemas vahendid aruannete koostamiseks;

§ on loogilise rühmitamise võimalus;

§ trendide salvestamiseks ja prognoosimiseks on sisseehitatud süsteem;

§ ametliku pistikprogrammi abil on võimalik automaatselt lisada uusi seadmeid (Autodiscovery);

§ on võimalus hosti täiustatud jälgimiseks agendi abil;

§ SNMP-protokolli tugi pistikprogrammi kaudu;

§ Syslogi protokolli tugi pistikprogrammi kaudu;

§ väliste skriptide tugi;

§ ise kirjutatud pluginate tugi ning võimalus neid kiiresti ja lihtsalt luua;

§ sisseehitatud päästikud ja sündmused;

§ täisfunktsionaalne veebiliides;

§ hajutatud monitooringu võimalus;

§ inventar pistikprogrammi kaudu;

§ võimalus salvestada andmeid nii failidesse kui ka SQL andmebaasidesse, mis on mahtude suurendamisel väga oluline;

§ GPL-litsents ja seega tasuta põhilevitus, tugi ja süsteemituuma ning kaasnevate komponentide avatud lähtekoodid;

§ dünaamilised ja kohandatavad kaardid;

§ juurdepääsu kontroll;

§ sisseehitatud keel hostide, teenuste ja kontrollide kirjeldamiseks;

§ kasutajate jälgimise võimalus.

Võrgujälgimissüsteemil Zabbix on sarnane parameetrite komplekt, kuid juurutamise ajal oli sellel palju vähem funktsioone kui Nagios ja see oli beetaversiooni staatuses. Lisaks näitas temaatiliste foorumite ja uudistevoogude uuring Nagiose kasutajate seas suurimat levimust, mis tähendab kasutaja kirjutatud dokumentatsiooni olemasolu ja konfigureerimise keeruliste hetkede kõige üksikasjalikumat kirjeldust.

Nagios võimaldab teil jälgida võrguteenuseid, nagu SMTP, TELNET, SSH, HTTP, DNS, POP3, IMAP, NNTP ja palju muud. Lisaks saate jälgida serveriressursside kasutamist, näiteks kettaruumi tarbimist, vaba mälu ja protsessori koormust. Võimalik on luua oma sündmuste käitlejad. Need töötlejad käivitatakse, kui teenuse või serveri kontrollimine käivitab teatud sündmused. Selline lähenemine võimaldab teil aktiivselt reageerida käimasolevatele sündmustele ja proovida tekkinud probleeme automaatselt lahendada. Näiteks saate luua sündmuste töötleja, mis taaskäivitab riputatud teenuse automaatselt. Nagiose monitooringusüsteemi eeliseks on ka selle kaugjuhtimise võimalus mobiiltelefoni wap-liidese abil. Kasutades mõistet "vanemhostid", on lihtne kirjeldada kõigi hostide vahelist hierarhiat ja sõltuvusi. See lähenemisviis on suurte võrkude jaoks äärmiselt kasulik, kuna võimaldab keerukat diagnostikat. Ja see kvaliteet aitab omakorda eristada mittetöötavaid hoste nendest, mis pole praegu vahelinkide talitlushäirete tõttu saadaval. Nagios suudab koostada jälgitavate süsteemide graafikuid ja jälgitava võrguinfrastruktuuri kaarte.

Oma Nagiosega töötamise kogemusest võib autor tuua näite, mis näitab, kui kasulik on see tema isiklikule praktikale olnud. Tulemüüri väline võrguliides hakkas iga paari tunni tagant pakette kaotama. Rikke tõttu läks kaduma kuni 20 protsenti mööduvast liiklusest. Minuti pärast hakkas teine ​​liides taas ootuspäraselt tööle. Selle probleemi katkendlikkuse tõttu ei õnnestunud mitu nädalat välja selgitada, miks Interneti kasutamisel vahelduvad katkendlikud tõrked tekivad. Ilma Nagioseta võtaks tõrkeotsing kaua aega.

Paljud administraatorid tunnevad Nagiose esivanemat NetSaint. Kuigi NetSaint projekti sait töötab endiselt korralikult, põhinevad uued arendused juba Nagiose lähtekoodil. Seetõttu on soovitatav kõigil aeglaselt Nagiosesse kolida.

Nagiosega kaasas olev dokumentatsioon ütleb, et see töötab hästi ka paljude teiste Unixi sarnaste süsteemidega. Nagiose veebiliidese kuvamiseks vajame Apache serverit. Võite vabalt kasutada mis tahes muud, kuid selles töös peetakse Apache'i Unixi platvormidel kõige levinumaks veebiserveriks. Jälgimissüsteemi saab installida ka ilma veebiliideseta, kuid seda me ei tee, sest see vähendab oluliselt kasutatavust.

4. TARKVARA ARENDUS

Realiseeritud süsteemi riistvaralise osana saab kasutada tavalist IBM-iga ühilduvat arvutit, kuid arvestades koormuse edasise suurendamise võimalust ning töökindluse ja MTBF-i nõudeid ning GosSvyazNadzorit, osteti Aquariuse sertifitseeritud serveriseadmed. .

Olemasolev võrk kasutab aktiivselt Linuxi tuumal põhinevat Debiani operatsioonisüsteemi, selle süsteemi kasutamisel on laialdased kogemused, enamik selle haldamise, seadistamise ja stabiilsuse tagamise toiminguid on silutud. Lisaks levitatakse seda OS-i GPL-i litsentsi all, mis näitab selle tasuta ja avatud lähtekoodid, mis vastavad võrgu jälgimissüsteemi kavandamise uuendatud juhendile. (Täisnimi on GNU / Linux, hääldatakse "gnu kaldkriips" ́ Nux, ka mõnes keeles GNU+Linux, GNU-Linux jne) on UNIX-i sarnaste operatsioonisüsteemide üldnimetus, mis põhinevad samanimelisel tuumal ning selle jaoks koostatud teekidel ja süsteemiprogrammidel, mis on välja töötatud osana GNU projekt./ Linux töötab arvutiga ühilduvates süsteemides Intel x86 perekonnast, aga ka IA-64, AMD64, PowerPC, ARM ja paljudes teistes.

GNU/Linuxi operatsioonisüsteem sisaldab sageli ka programme, mis seda operatsioonisüsteemi täiendavad, ja rakendusprogramme, mis muudavad selle täisväärtuslikuks multifunktsionaalseks töökeskkonnaks.

Erinevalt enamikust teistest operatsioonisüsteemidest ei ole GNU/Linuxil kaasas ühtki "ametlikku" komplekti. Selle asemel on GNU/Linux saadaval paljudes niinimetatud distributsioonides, mis seovad GNU programmid Linuxi tuuma ja muude programmidega. Tuntuimad GNU/Linuxi distributsioonid on Ubuntu, Debian GNU/Linux, Red Hat, Fedora, Mandriva, SuSE, Gentoo, Slackware, Archlinux. Vene distributsioonid - ALT Linux ja ASPLinux.

Erinevalt Microsoft Windowsist (Windows NT), Mac OS-ist (Mac OS X) ja kaubanduslikest UNIX-i sarnastest süsteemidest ei ole GNU/Linuxil geograafilist arenduskeskust. Pole ühtegi organisatsiooni, kellele see süsteem kuuluks; pole isegi ühtset koordineerimiskeskust. Linuxi programmid on tuhandete projektide töö tulemus. Mõned neist projektidest on tsentraliseeritud, mõned on koondunud ettevõtetesse. Paljud projektid toovad kokku häkkerid üle kogu maailma, kes tunnevad üksteist vaid kirjavahetuse teel. Igaüks võib luua oma projekti või liituda juba olemasolevaga ning edu korral saavad töö tulemused teada miljonitele kasutajatele. Kasutajad osalevad tasuta tarkvara testimises, suhtlevad otse arendajatega, mis võimaldab kiiresti leida ja parandada vigu ning juurutada uusi funktsioone.

UNIX-süsteemide arengu ajalugu. GNU/Linux on UNIX-iga ühilduv, kuid põhineb oma lähtekoodil

Just see paindlik ja dünaamiline arendussüsteem, mis on suletud lähtekoodiga projektide puhul võimatu, määrab [allikas pole määratud 199 päeva] GNU/Linuxi erakordse kuluefektiivsuse. Tasuta arenduse madal hind, väljakujunenud testimis- ja levitamismehhanismid, erinevatest riikidest pärit inimeste kaasamine erineva nägemusega probleemidest, koodi kaitsmine GPL-litsentsiga – see kõik on saanud vaba tarkvara edu põhjuseks. .

Loomulikult ei saanud nii kõrge arendusefektiivsus jätta huvitamata suurettevõtteid, kes hakkasid oma projekte avama. Nii ilmusid Mozilla (Netscape, AOL), OpenOffice.org (Sun), Interbase'i (Borland) tasuta kloon - Firebird, SAP DB (SAP). IBM hõlbustas GNU/Linuxi portimist oma suurarvutitesse.

Teisest küljest vähendab avatud lähtekoodiga oluliselt GNU/Linuxi suletud süsteemide arendamise kulusid ja vähendab lahenduse hinda kasutaja jaoks. Seetõttu on GNU/Linuxist saanud platvorm, mida sageli soovitatakse sellistele toodetele nagu Oracle, DB2, Informix, SyBase, SAP R3, Domino.

GNU/Linuxi kogukond suhtleb Linuxi kasutajarühmade kaudu.

Enamik kasutajaid kasutab GNU/Linuxi installimiseks distributsioone. Jaotuskomplekt ei ole lihtsalt programmide komplekt, vaid hulk lahendusi erinevate kasutajaülesannete jaoks, mida ühendavad ühised süsteemid pakettide installimiseks, haldamiseks ja värskendamiseks, konfigureerimiseks ja toeks.

Kõige levinumad distributsioonid maailmas: - kiiresti kasvav distributsioon, mis keskendub õppimise ja kasutamise lihtsusele - SuSE distributsiooni tasuta versioon, mis kuulub Novellile. Lihtne seadistada ja hooldada YaST-i utiliidi abil. - kogukonna ja ettevõtte RedHat toetatud, eelneb RHEL-i kommertsversiooni väljaandmisele. GNU / Linux - rahvusvaheline levikomplekt, mille on välja töötanud suur arendajate kogukond mitteäriliseks kasutamiseks eesmärkidel. See oli paljude teiste distributsioonide loomise aluseks. Seda eristab range lähenemine mittevaba tarkvara kaasamisele. - Prantsuse-Brasiilia distributsioon, endise Mandrake'i ja Conectiva (inglise keeles) liitmine - Üks vanimaid distributsioone, seda eristab konservatiivne lähenemine arendamine ja kasutamine – lähtekoodidest koostatud levikomplekt. Võimaldab väga paindlikku lõppsüsteemi kohandamist ja jõudluse optimeerimist, mistõttu nimetab see end sageli meta-jaotuseks. See distributsioon on keskendunud ekspertidele ja edasijõudnud kasutajatele. See on keskendunud uusimatele tarkvaraversioonidele ja seda pidevalt värskendatakse, toetades võrdselt nii binaar- kui ka allikainstallatsioone ning tuginedes KISS-i lihtsuse filosoofiale. See distributsioon on suunatud pädevatele kasutajatele, kes soovivad saada kogu võimsust ja muudetavust. Linuxi jaoks, kuid ei ohverda hooldusaega.

Lisaks loetletutele on palju muid distributsioone, mis põhinevad loetletud ja on loodud nullist ja on sageli mõeldud piiratud arvu ülesannete täitmiseks.

Igal neist on oma kontseptsioon, oma pakettide komplekt, oma eelised ja puudused. Ükski neist ei suuda rahuldada kõiki kasutajaid ja seetõttu on juhtide kõrval ka teised ettevõtted ja programmeerijate ühendused, kes pakuvad oma lahendusi, distributsioone, teenuseid. GNU/Linuxi peale on ehitatud palju LiveCD-sid, näiteks Knoppix. LiveCD võimaldab teil käivitada GNU/Linuxi otse CD-lt, ilma seda kõvakettale installimata.

Neile, kes soovivad GNU/Linuxist põhjalikult aru saada, sobib ükskõik milline distributsioon, kuid üsna sageli kasutatakse selleks nn allikapõhiseid distributsioone, st need hõlmavad kõigi (või osade) distributsioonide isekoostamist. komponendid lähtekoodidest, nagu LFS, Gentoo, ArchLinux või CRUX.

4.1 Süsteemi tuuma installimine

Nagiosid saab installida kahel viisil - allikatest ja ehitatud pakettidest. Mõlemal meetodil on eelised ja puudused, kaaluge neid.

Nende lähtepaketi installimise eelised:

§ süsteemi üksikasjaliku konfigureerimise võimalus;

§ rakenduste kõrge optimeerimise tase;

§ programmi kõige täielikum esitus.

Nende lähtepaketi installimise miinused:

§ paketi kokkupanemiseks on vaja lisaaega, mis sageli ületab selle konfigureerimiseks ja silumiseks kuluvat aega;

§ suutmatus eemaldada paketti koos konfiguratsioonifailidega;

§ suutmatus värskendada paketti koos konfiguratsioonifailidega;

§ installitud rakenduste tsentraliseeritud kontrolli võimatus.

Eelehitatud paketist Nagiose installimisel muutuvad toorpaigaldusmeetodi eelised puudusteks ja vastupidi. Kuid nagu praktika on näidanud, vastab eelehitatud pakett kõik süsteemile esitatavad nõuded ja pole mõtet raisata aega paketi käsitsi ehitamisele.

Kuna algselt testiti mõlemat paigaldusmeetodit, käsitleme neid kõiki üksikasjalikumalt.

4.1.1 Nende lähtekoodide tuumasüsteemi installimise kirjeldus

Vajalikud paketid.

Enne Nagiose juurutamise alustamist peate veenduma, et järgmised paketid on installitud. Nende paigaldamise protsessi üksikasjalik arutelu ei kuulu selle töö raamesse.

· Apache 2

· PHP

· GCC kompilaatorite ja arendajate teegid

· GD arendajate raamatukogud

Saate kasutada apt-get (eelistatavalt aptitude) nende installimiseks järgmiselt:

% 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) Looge uus privilegeeritud kasutajakonto

Nagiose teenuse käivitamiseks luuakse uus konto. Seda saab teha ka superkasutaja konto alt, mis tekitab tõsise ohu süsteemi turvalisusele.

Hakka superkasutajaks:

Looge uus nagiose kasutajakonto ja andke sellele parool:

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

# passwd nagios

Looge nagiose grupp ja lisage sellele nagiose kasutaja:

# /usr/sbin/groupadd nagios

# /usr/sbin/usermod -G nagios nagios

Loome grupi nagcmd, et võimaldada veebiliidese kaudu edastatavate väliste käskude täitmist. Lisame sellesse gruppi nagios ja apache kasutajad:

# /usr/sbin/groupadd nagcmd

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

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

2) Laadige alla Nagios ja selle pistikprogrammid

Looge allalaaditud failide salvestamiseks kataloog:

# mkdir ~/allalaadimised

# cd ~/allalaadimist

Laadige alla Nagiose ja selle pistikprogrammide tihendatud allikad (#"justify"># wget #"justify"># wget #"justify">3) Kompileerige ja installige Nagios

Pakime lahti tihendatud Nagiose allikad:

# cd ~/allalaadimist

# tar xzf nagios-3.2.0.tar.gz

# cd nagios-3.2.0

Käivitage Nagiose konfiguratsiooniskript, edastades sellele varem loodud rühma nime:

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

Konfiguratsiooniskripti parameetrite täielik loend:

#./configure --help

`configure" seadistab selle paketi kohanema mitmesuguste süsteemidega.: ./configure ... ...määrake keskkonnamuutujad (nt CC, CFLAGS...), määrake need väärtusega = VALUE. Mõnede süsteemide kirjeldusi vaadake allpool kasulikest muutujatest. suvandid on määratud sulgudes.:

h, --help kuvab selle spikri ja välju

Help=sellele paketile omased lühikesed kuvavalikud

Help=rekursiivne kuvab kõigi kaasasolevate pakettide lühispikri

V, --version kuvab versiooniteabe ja välju

q, --quiet, --silent ei prindi `kontrolli..." sõnumeid

cache-file=FILE vahemälu testi tulemused failis FILE

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

n, --no-create ei loo väljundfaile

Srcdir=DIR otsi allikaid DIR-kataloogidest:

Prefix=PREFIX paigalda arhitektuurist sõltumatud failid PREFIX-i

Exec-prefix=EPREFIX installi arhitektuurist sõltuvad failid EPREFIX-i vaikimisi, `make install" installib kõik failid kaustadesse `/usr/local/nagios/bin, `/usr/local/nagios/lib jne. Saate määrata paigalduse eesliide peale `/usr/local/nagios, kasutades `--prefiksit, näiteks `--prefix=$HOME.parem juhtimine, kasuta allolevaid valikuid.installikataloogide häälestamine:

Bindir=DIR kasutaja käivitatavad failid

Sbindir=DIR süsteemiadministraatori käivitatavad failid

libexecdir=DIR programmi käivitatavad failid

Datadir=DIR-kirjutuskaitstud arhitektuurist sõltumatud andmed

Sysconfdir=DIR-kirjutuskaitstud ühe masina andmed

Sharedstatedir=DIR-i muudetavad arhitektuurist sõltumatud andmed

Localstatedir=DIR-iga muudetavad ühe masina andmed

Libdir=DIR objekti kooditeegid

Includedir=DIR C päisefailid

oldincludedir=DIR C päisefailid mitte-gcc jaoks

infodir=DIR info dokumentatsioon

Mandir=DIR mehe dokumentatsiooni tüübid:

Build=BUILD konfiguratsioon BUILD-i ehitamiseks

Host=HOST ristkompileerimine, et luua programme, mis töötavad HOSTi funktsioonidega:

Disable-FEATURE ei sisalda funktsiooni FEATURE (sama mis --enable-FEATURE=no)

Luba – FEATURE[=ARG], kaasa arvatud FEATURE

disable-statusmap=keelab olekukaardi CGI kompileerimise

disable-statuswrl=keelab statuswrl (VRML) CGI kompileerimise

Enable-DEBUG0 näitab funktsiooni sisenemist ja väljumist

Enable-DEBUG1 näitab üldisi teabesõnumeid

Enable-DEBUG2 kuvab hoiatusteateid

Luba-DEBUG3 näitab ajastatud sündmusi (teenuse ja hosti kontrollid jne)

Luba-DEBUG4 näitab teenuse ja hosti teatisi

Enable-DEBUG5 näitab SQL-päringuid

Luba-DEBUGALL näitab kõiki silumissõnumeid

Luba nanounerežiim võimaldab sündmuste ajastamisel kasutada nanounerežiimi (unerežiimi asemel).

Sündmuste vahendaja lubamine võimaldab integreerida sündmuste vahendaja rutiinid

Enable-embedded-perl lubab manustatud Perli tõlgi

Enable-cygwin võimaldab ehitada CYGWIN-i keskkonnapakettide alla:

Koos-PACKAGE[=ARG] kasutage PAKTI

Ilma PAKENDita ära kasuta PAKTI (sama mis --with-PACKAGE=no)

With-nagios-user= määrab nagios käivitamiseks kasutajanime

With-nagios-group= määrab nagios käivitamiseks rühma nime

With-command-user= määrab käsu juurdepääsuks kasutajanime

With-command-group= määrab käsu juurdepääsuks rühma nime

Postiga = Määrab samaväärse programmi tee postiga

Koos-init-dir= Määrake kataloog, kuhu algskripti paigutada

With-lockfile= Määrake lukustusfaili tee ja failinimi

With-gd-lib=DIR määrab gd teegi asukoha

With-gd-inc=DIR määrab gd-failide asukoha

Koos-cgiurl= määrab cgi-programmide URL-i (ärge kasutage lõppu kaldkriipsu)

Koos-htmurl= määrab avaliku html-i URL-i

With-perlcache lülitab sisse sisemiselt kompileeritud Perli skripti vahemällu salvestamise, mis mõjutavad keskkonnamuutujaid:C kompilaatori käskC kompilaatori lipulinkeri lipud, nt. -L kui teil on kataloogis teeke C/C++ eelprotsessori lipud, nt. - Mina kui teil on mittestandardses kataloogis C eeltöötleb neid muutujaid, et alistada 'configure' tehtud valikud või aidata leida mittestandardsete nimede/asukohtadega teeke ja programme.

Nagiose lähtekoodi koostamine.

Installige binaarfailid, initsialiseerimisskript, konfiguratsioonifailide näidisfailid ja määrake õigused välise käskude kataloogi:

# make install-init

# make install-config

# tee install-commandmode

) Muutke konfiguratsiooni

Näidiskonfiguratsioonifailid installitakse kataloogi /usr/local/nagios/etc. Nad peaksid kohe tööle hakkama. Enne jätkamist peate tegema ainult ühe muudatuse.

Redigeerime konfiguratsioonifaili /usr/local/nagios/etc/objects/contacts.cfg mis tahes tekstiredaktoriga ja muudame nagiosadmini kontakti definitsiooniga seotud e-posti aadressi aadressiks, kuhu veateateid saadame.

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

5) Veebiliidese seadistamine

Installige Nagiose veebiliidese konfiguratsioonifail Apache conf.d kataloogi.

# make install-webconf

Looge Nagiose veebiliidesesse sisselogimiseks nagiosadmini konto

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

Muudatuste jõustumiseks taaskäivitage Apache.

# /etc/init.d/apache2 laadige uuesti

Selle konto varguse vältimiseks on vaja võtta meetmeid CGI turvalisuse tugevdamiseks, kuna jälgimisteave on üsna tundlik.

) Kompileerige ja installige Nagiose pistikprogrammid

Pakime lahti Nagiose pistikprogrammide tihendatud allikad:

# cd ~/allalaadimist

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

Pluginate kompileerimine ja installimine:

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

#pake install

) Käivitage Nagiose teenus

Seadistagem Nagios automaatselt käivitama, kui operatsioonisüsteem on sisse lülitatud:

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

Kontrollime näidiskonfiguratsioonifailide süntaktilist õigsust:

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

Kui vigu pole, käivitage Nagios:

# /etc/init.d/nagios start

) Sisestage veebiliides

Nüüd saate Nagiose veebiliidesesse sisse logida, kasutades järgmist URL-i. Teilt küsitakse kasutajanime (nagiosadmin) ja parooli, mille me varem määrasime.

#"justify">) Mitmesugused seaded

Nagiose sündmuste kohta e-kirjade meeldetuletuste saamiseks peate installima paketi mailx (Postfix):

% sudo apt-get install mailx

% sudo apt-get install postfix

Peate redigeerima Nagiose meeldetuletuskäske failis /usr/local/nagios/etc/objects/commands.cfg ja muutma kõik viited "/bin/mail" asemel "/usr/bin/mail". Pärast seda peate Nagiose teenuse taaskäivitama:

# sudo /etc/init.d/nagios restart

Üksikasjalikku postimooduli konfiguratsiooni on kirjeldatud lisas D.

4.1.2 Hoidlast süsteemituuma installimise kirjeldus

Nagu ülal näidatud, võtab Nagiose allikast installimine palju aega ja on mõttekas ainult siis, kui vajate rakenduse hoolikat optimeerimist või kui soovite süsteemi mehaanikat üksikasjalikult mõista. Tootmistingimustes installitakse suurem osa tarkvara hoidlatest eelkompileeritud pakettidena. Sel juhul taandub installimine ühe käsu sisestamiseks:

% sudo aptitude install nagios

Paketihaldur ise rahuldab kõik sõltuvused ja installib vajalikud paketid.

4.2 Süsteemi tuuma seadistamine

Enne üksikasjalikku seadistamist peaksite mõistma, kuidas Nagiose tuum töötab. Selle graafiline kirjeldus on toodud allpool joonisel 6.2.

4.2.1 Süsteemi tuuma töö kirjeldus

Järgmisel joonisel on Nagiose teenuse toimimise lihtsustatud diagramm.

Riis. 4.1 – süsteemi tuum

Nagiose teenus loeb põhikonfiguratsioonifaili, mis sisaldab lisaks teenuse põhiparameetritele linke ressursifailidele, objektikirjeldusfailidele ja CGI konfiguratsioonifailidele.

Allpool on näidatud võrgu jälgimise tuuma algoritm ja loogika.

Riis. 4.2 – Nagiose hoiatusalgoritm

2.2 Konfiguratsioonifailide koostoime kirjeldus

Kataloog /etc/apache2/conf.d/ sisaldab faili nagios3.conf, millest apache veebiserver võtab nagiose seaded.

Nagiose konfiguratsioonifailid asuvad kataloogis /etc/nagios3.

Fail /etc/nagios3/htpasswd.users sisaldab nagiose kasutajate paroole. Faili loomise ja vaikimisi nagiose kasutaja parooli määramise käsk on antud ülal. Edaspidi tuleb uuele kasutajale parooli seadmisel argument "-c" ära jätta, vastasel juhul kirjutab uus fail vana üle.

Fail /etc/nagios3/nagios.cfg sisaldab nagiose enda põhikonfiguratsiooni. Näiteks sündmuste logifailid või muude konfiguratsioonifailide tee, mida nagios käivitamisel loeb.

Kataloog /etc/nagios/objects sisaldab uusi hoste ja teenuseid.

4.2.3 Hosti ja teenuse kirjelduste sisestamine

Nagu ülal näidatud, on võimalik süsteemituuma konfigureerida ühe hostide ja teenuste kirjeldusfaili abil, kuid see meetod ei ole jälgitavate seadmete arvu suurenemise korral mugav, seetõttu on vaja luua kataloogi- ja failistruktuur. koos hostide ja teenuste kirjeldustega.

Loodud struktuur on näidatud lisas H.

faili hosts.cfg

Esimene samm on kirjeldada jälgitavaid hoste. Saate kirjeldada nii palju hoste, kui soovite, kuid selles failis piirdume kõigi hostide üldiste parameetritega.

Siin ei ole kirjeldatud host päris host, vaid mall, millel põhinevad kõigi teiste hostide kirjeldused. Sama mehhanismi võib leida ka teistest konfiguratsioonifailidest, kui konfiguratsioon põhineb vaikeväärtuste eelmääratletud komplektil.

fail hostgroups.cfg

See on koht, kus hostid lisatakse hostrühma. Isegi lihtsa konfiguratsiooni korral, kui on ainult üks host, peate selle ikkagi gruppi lisama, et Nagios teaks, millist kontaktrühma kasutada hoiatuste saatmiseks. Lisateavet allpool oleva kontaktgrupi kohta.

Contactgroups.cfg fail

Oleme määratlenud kontaktirühma ja lisanud sellesse gruppi kasutajaid. See konfiguratsioon tagab, et kõik kasutajad saavad hoiatuse, kui grupi vastutava serveriga läheb midagi valesti. Tõsi, peate meeles pidama, et iga kasutaja individuaalsed sätted võivad need seaded alistada.

Järgmine samm on määrata kontaktteave ja hoiatusseaded.

Contacts.cfg faili

Lisaks selles failis olevate kasutajate jaoks täiendava kontaktteabe andmisele on ühel väljal kontakti_nimi muu eesmärk. CGI-skriptid kasutavad nendel väljadel antud nimesid, et teha kindlaks, kas kasutajal on õigus mõnele ressursile juurde pääseda või mitte. Peate seadistama autentimise .htaccess-i alusel, kuid peale selle peate kasutama samu nimesid, mis ülal, et kasutajad saaksid veebiliidese kaudu töötada.

Nüüd, kui hostid ja kontaktid on konfigureeritud, saame edasi liikuda üksikute teenuste jälgimise konfigureerimise juurde, mida tuleks jälgida.

Services.cfg fail

Siin, nagu hostide faili hosts.cfg, määrame kõigi teenuste jaoks ainult üldised parameetrid.

Saadaval on tohutult palju täiendavaid Nagiose mooduleid, kuid kui mõni tšekk on ikka puudu, saate selle alati ise kirjutada. Näiteks pole ühtegi moodulit, mis kontrolliks, kas Tomcat töötab või mitte. Saate kirjutada skripti, mis laadib Tomcati kaugserverist jsp-lehe ja tagastab tulemuse olenevalt sellest, kas laaditud lehel on lehel teksti või mitte. (Uue käsu lisamisel mainige seda kindlasti failis checkcommand.cfg, mida me ei puudutanud).

Järgmisena loome iga üksiku hosti jaoks oma kirjeldusfaili, samas failis salvestame teenuste kirjeldused, mida selle hosti puhul jälgime. Seda tehakse mugavuse ja loogilise korralduse huvides.

Väärib märkimist, et Windowsi hoste jälgitakse SNMP-protokolli ja NSClienti abil. a mis tuleb Nagiosega kaasa. Allpool on diagramm selle toimimise kohta.

Riis. 4.3 - Windowsi hostide jälgimise skeem

Samal ajal jälgitakse *nix hoste ka SNMP ja NRPE pistikprogrammi kaudu. Selle töö skeem on näidatud joonisel.

Riis. 4.4 - *nix hostide jälgimise skeem

2.4 Pluginate kirjutamine

Lisaks initsialiseerimisskriptide kirjutamisele, hostide ja teenuste määratlemisele kasutati järgmisi pistikprogramme:

├── 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

├── kontrollandurid

├── 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

├── kontrolli_aeg

Enamik neist on kaasas Nagiose paketiga. Tarnekomplekti mittekuuluvate ja süsteemis kasutatavate pistikprogrammide lähtetekstid on toodud I lisas.

4.2.5 SNMP konfigureerimine kaughostides

SNMP-protokolli abil jälgimiseks peate esmalt konfigureerima selle protokolli agendid võrguseadmetes. SNMP töö skeem koos võrguseiresüsteemi tuumaga on näidatud alloleval joonisel.

Riis. 4.5 - SNMP-protokolli kaudu jälgimise skeem

Hostide konfiguratsiooniparameetrid on toodud lisas H. Turvalisus tagatakse pakettfiltri konfigureerimisega igas hostis eraldi ja turvaliste süsteemi alamvõrkude korraldamisega, millele pääsevad ligi ainult ettevõtte volitatud töötajad. Lisaks on konfiguratsioon tehtud nii, et SNMP-protokolli kasutades saate parameetreid ainult lugeda, mitte neid kirjutada.

4.2.6 Agendi konfigureerimine kaughostides

Hostide ja teenuste täiustatud jälgimisvõimaluste saamiseks peate neile installima Nagiose agendi, mida nimetatakse nagios-nrpe-serveriks:

# aptitude install nagios-nrpe-server

Agendi konfiguratsioon on toodud lisas K. Agendi toimimise skeem on näidatud ülaltoodud joonisel 4.5.

4.4 Allalaadimise jälgimise mooduli installimine ja konfigureerimine

MRTG (Multi Router Traffic Grapher) on teenus, mis võimaldab teil SNMP-protokolli kaudu saada teavet mitmest seadmest ja kuvada oma brauseris kanalite koormusgraafikud (sissetulev liiklus, väljaminev, maksimaalne, keskmine) minutites, tundides, päevades ja aastas. aken.

Paigaldusnõuded

MRTG tööks on vaja järgmisi teeke:

§ gd - graafiku joonistusteek. Graafika renderdamise eest vastutav raamatukogu (#"justify">§ libpng - gd on vajalik png-graafika loomiseks (#"justify">Meie puhul taandub installimine ühe käsu täitmiseks, kuna valitakse hoidlast eelkompileeritud paketi installimise meetod:

# aptitude install mrtg

Konfiguratsioonifaile saate luua käsitsi või kasutada paketis sisalduvaid konfiguratsioonigeneraatoreid:

#cfgmaker @ >

Pärast konfiguratsioonifaili genereerimist on soovitatav seda kontrollida, kuna see võib sisaldada liideste kirjeldusi, mida me ei pea töökoormuse jaoks analüüsima. Sellisel juhul kommenteeritakse või eemaldatakse faili teatud read. MRTG konfiguratsioonifaili näide on toodud lisas M. Nende failide suure suuruse tõttu kuvatakse ainult üks näidisfail.

#indeksitegija >

Registrilehed on tavalised html-failid ja nende sisu ei paku erilist huvi, mistõttu pole mõtet nende kohta näiteid tuua. Lisas H on näide liidese laadimisgraafikute kuvamisest.

Kokkuvõtteks on vaja korraldada liideste koormuse ajakava kontroll. Lihtsaim viis seda saavutada on operatsioonisüsteemi, nimelt crontab parameetrite abil.

4.5 Süsteemi sündmuste logide kogumise mooduli paigaldamine ja seadistamine

Süsteemisündmuste logide kogumise mooduliks valiti pakett syslog-ng.ng (syslog next generation) – see on multifunktsionaalne teenus süsteemiteadete logimiseks. Võrreldes tavalise syslogd-teenusega on sellel mitmeid erinevusi:

§ täiustatud konfiguratsiooniskeem

§ sõnumite filtreerimine mitte ainult prioriteetide, vaid ka nende sisu järgi

§ regulaaravaldiste (regulaaravaldiste) tugi

§ logide paindlikum manipuleerimine ja organiseerimine

§ võimalus krüpteerida andmekanalit IPSec / Stunneli abil

Järgmises tabelis on loetletud toetatud riistvaraplatvormid.

Tabel 4.1 – Toetatud riistvaraplatvormid

x86x86_64SUN SPARCppc32ppc64PA-RISCAIX 5.2 & 5.3НетНетНетДаПо запросуНетDebian etchДаДаНетНетНетНетFreeBSD 6.1 *ДаПо запросуПо запросуНетНетНетHP-UНет 11iНетНетНетНетНетДаIBM System iНетНетНетДаНетНетRed Hat ES 4 / CentOS 4ДаДаНетНетНетНетRed Hat ES 5 / CentOS 5ДаДаНетНетНетНетSLES 10 / openSUSE 10.0ДаПо запросуНетНетНетНетSLES 10 SP1 / openSUSE 10.1ДаДаНетНетНетНетSolaris 8НетНетДаНетНетНетSolaris 9По запросуНетДаНетНетНетSolaris 10По запросуДаДаНетНетНетWindowsДаДаНетНетНетНет Märkus. *Juurdepääsu Oracle'i andmebaasile ei toetata

Tehniliste omaduste üksikasjalik võrdlus on toodud lisas P.

Failid reeglite ja filtrite ning kaughostide konfiguratsiooni kirjeldamiseks on toodud lisas P.

On olemas RFC dokument, mis kirjeldab üksikasjalikult syslogi protokolli, üldiselt saab syslogi koguja mooduli tööd kujutada järgmise skeemi abil

Riis. 4.6 - Süsteemi logide kogumise mooduli tööskeem

Kliendihostis kirjutab iga rakendus oma sündmuste logi, moodustades seega allika. Järgmisena läbib logide sõnumivoog salvestuskoha määramise, seejärel määratakse filtrite kaudu selle võrgu suund, misjärel logimisserverisse jõudes määratakse iga sõnumi jaoks uuesti salvestuskoht. Valitud moodul on suurel määral skaleeritav ja hästi konfigureeritav, näiteks saab filtreid hargneda, nii et süsteemi sündmuste teateid saadetakse mitmes suunas sõltuvalt mitmest olukorrast, nagu on näidatud alloleval joonisel.

Riis. 4.7 - Filtri hargnemine

Skaleeritavus eeldab, et koormuse jaotamiseks juurutab administraator täiendavate filtreerimisserverite võrgu, nn releed.

Riis. 4.8 – Skaleerimine ja koormuse tasakaalustamine

Lõppkokkuvõttes võib mooduli toimimist kõige lihtsustatult kirjeldada järgmiselt - kliendihostid edastavad erinevate rakenduste sündmuste logidest teateid mahalaadimisserveritele, mis omakorda saavad neid edastada mööda releeahelat jne. kesksetesse kogumisserveritesse.

Riis. 4.9 - Mooduli töö üldistatud skeem

Meie puhul ei ole andmevoog nii suur, et võtta kasutusele serverite mahalaadimise süsteem, mistõttu otsustati kasutada lihtsustatud klient-server tööskeemi.

Riis. 4.10 - Aktsepteeritud tööskeem

5. SÜSTEEMIADMINISTRAATORI JUHEND

Üldiselt soovitatakse süsteemiadministraatoril järgida olemasolevat konfiguratsioonifailide ja kataloogide hierarhiat. Uute hostide ja teenuste lisamine seiresüsteemi taandub uute konfiguratsioonifailide ja lähtestamisskriptide loomisele, nagu on näidatud jaotises 5 – Tarkvaraarendus, seega pole mõtet selles töös süsteemi konfigureerimise parameetreid ja põhimõtteid uuesti kirjeldada. kuid tasub pikemalt peatuda süsteemi üksikute moodulite liideste kirjeldusel.

5.1 Süsteemi veebiliidese kirjeldus

Teenuste interaktiivse jälgimise teostamiseks oli mugavam integreerida süsteemi veebiliides. Veebiliides on hea ka seetõttu, et annab süsteemist tervikliku pildi läbi graafiliste tööriistade oskusliku kasutamise ja täiendava statistilise info pakkumise.

Nagiose veebilehele sisselogimisel palutakse teil sisestada kasutajanimi ja parool, mille seadsime häälestusprotsessi käigus. Veebiliidese avaleht on näidatud alloleval joonisel.

Riis. 5.1 – süsteemi veebiliidese avaleht

Vasakul on navigeerimisriba, paremal on võrgu, hostide ja teenuste oleku erinevate vaadete tulemused. Meid huvitab eelkõige seire sektsioon. Vaatame taktikalise ülevaate lehte.

Riis. 5.2 - Süsteemi veebiliidese avaleht

See leht sisaldab kokkuvõtlikku teavet kõigi seireparameetrite ning hostide ja teenuste oleku kohta, kuid üksikasju ei esitata, kuid probleemide ilmnemisel tõstetakse need erivärviga esile ja muutuvad hüperlingiks, mis viib probleemi üksikasjaliku kirjelduseni. Meie puhul on praegu kõigi hostide ja teenuste seas üks lahendamata probleem, järgime seda linki (1 käsitlemata probleemid).

Riis. 5.3 – Tuvastatud teenuseprobleem

Siin vaatleme tabeli kujul, millisel hostil probleem tekkis, milline teenus selle põhjustas (meie puhul on see ruuteri protsessori suur koormus), vea olekut (see võib olla normaalne, lävi ja kriitiline), aega viimane kontroll, probleemi olemasolu kestus, tsüklis oleva konto kontrollimise number ja üksikasjalik teave konkreetsete väärtustega, mille kasutatud pistikprogramm tagastab.

Riis. 5.4 – Teenuse oleku üksikasjalik kirjeldus

Siin näeme probleemi täielikku kirjeldust, see leht on kasulik probleemi süvaanalüüsiks, kui selle esinemise põhjus pole täiesti selge, näiteks võib see olla liiga jäigalt seatud kriitilise oleku lävedes või valesti seadistatud pistikprogrammi käivitamine parameetrid, mida süsteem hindab ka kriitiliseks olekuks . Lisaks kirjeldusele on sellel lehel võimalik teenuses käivitada käske, näiteks keelata kontrollid, ajastada teistsugune järgmine kontrollaeg, aktsepteerida andmeid passiivselt, nõustuda probleemiga ülevaatamiseks, välja lülitada hoiatusi, saata käsitsi hoiatus, ajastada teenuse seiskamine, lülitada välja ebastabiilse oleku tuvastamine ja kirjutada kommentaar.

Läheme teenuse üksikasjade lehele.

Riis. 5.5 – kõigi teenuste üksikasjalik vaade

Siin näeme kõigi hostide ja teenuste loendit, olenemata nende praegusest olekust. See funktsioon võib olla kasulik, kuid pika hostide ja teenuste loendi sirvimine pole eriti mugav ja seda on rohkem vaja süsteemi aeg-ajalt tehtava töö mahu visualiseerimiseks. Siin on iga host ja teenus, nagu joonisel 6.3, link, mis viib parameetri üksikasjalikuma kirjelduse juurde.

Riis. 5.6 – täielik üksikasjalik hostide loend

See tabel sisaldab täielikku üksikasjalikku hostide loendit, nende olekut, viimase kontrolli aega, hetkeoleku kestust ja lisateavet. Meie süsteemis on aktsepteeritud, et hosti olekut kontrollitakse ICMP (8) hosti ligipääsetavuskontrolli ehk ping-käsu abil, kuid üldjuhul võib kontroll olla ükskõik milline. Hosti nimest paremal asuvas veerus olevad ikoonid näitavad rühma, kuhu see kuulub, seda tehakse teabe tajumise hõlbustamiseks. Valgusfoori ikoon on link, mis viib selle hosti üksikasjaliku teenuste loendi juurde, seda tabelit pole mõtet eraldi kirjeldada, see on täpselt sama, mis joonisel 10.4, teave on esitatud ainult ühe hosti kohta.

Järgmised lingid loendis on eelmiste tabelite erinevad modifikatsioonid ja nende sisust pole raske aru saada. Veebiliidese kõige huvitavam omadus on võimalus koostada poolautomaatses režiimis võrgukaart.

Riis. 5.7 – võrgu täielik ringkaart

Iga hosti ja teenuse vanemparameetri kaudu saame luua oma võrgu struktuuri või hierarhia, mis määrab võrgu jälgimismootori loogika ning hostide ja teenuste esituse võrgukaardil. Ekraanirežiime on mitu, lisaks ringikujulisele on mugavaim tasakaalustatud puurežiim ja sfääriline.

Riis. 5.8 - Võrgukaart - B-puu režiim

Riis. 5.9 - Võrgukaart - pallirežiim

Kõigis režiimides on iga hosti pilt link selle teenuste tabeli ja nende olekute juurde.

Järelevalve põhiliidese järgmine oluline osa on trendi koostaja. Tema abiga saab planeerida seadmete väljavahetamist tootlikumate vastu, toome näite. Klõpsake lingil Trends. Valige aruande tüüp – teenus.

1. samm: valige aruande tüüp: teenus

Kolmas samm on loendusperioodi valimine ja aruande koostamine.

Riis. 5.10 - Trend

Oleme loonud marsruutimisel protsessori koormuse trendi. Sellest võime järeldada, et kuu jooksul see parameeter pidevalt halveneb ja nüüd on vaja võtta meetmeid kas hosti töö optimeerimiseks või valmistuda selle asendamiseks produktiivsemaga.

5.2 Liideste laadimise jälgimise mooduli veebiliidese kirjeldus

Liidese koormuse jälgimise mooduli veebiliides on loend kataloogidest, mis sisaldavad jälgitavate hostide registrilehti koos iga liidese laadimisgraafikutega.

Riis. 5.11 – liidese koormuse jälgimise mooduli avaleht

Klõpsates mis tahes lingil, saame allalaadimise ajakava. Iga graafik on link, mis viib nädala, kuu ja aasta statistika juurde.

5.3 Süsteemi sündmuste logide kogumise mooduli kirjeldus

Hetkel ei ole süsteemilogide täiustatud filtreerimine ja nende kaudu ühe veebiliidese kaudu otsimise võimalus vajalik, sest. Probleemid, mis nõuavad nende logide vaatamist, on haruldased. Seetõttu on nende ajakirjade andmebaasi ja veebiliidese arendamine edasi lükatud. Praegu pääseb neile juurde mc failihalduris ssh-i ja kataloogide sirvimise kaudu.

Selle mooduli töö tulemusena saime järgmise kataloogistruktuuri:

├── apache2

├── tärn

├── bgp_ruuter

├── dbconfig-common

├── paigaldaja

│ └── cdebconf

├── len58a_3lvl

├── monitooring

├── nagios3

│ └── arhiivid

├── ocsinventory-klient

├── ocsinventory-server

├── quagga

├── ruuter_krivous36b

├── ruuter_lenina58a

├── ruuter_su

├── ruuter_ur39a

├── vormija

├── ub13_ruuter

├── univers11_ruuter

└── voip

Iga kataloog on iga üksiku hosti sündmuste logide hoidla.

Riis. 5.13 - Süsteemi sündmuste logi kogumismooduli kogutud andmete vaatamine

6. TÖÖ TESTIMINE

Süsteemi juurutamise käigus viidi läbi iga komponendi töö järkjärguline testimine, alustades süsteemi tuumast. Funktsionaalsuse laiendamine viidi läbi alles pärast võrguseiresüsteemi moodulite madalamate hierarhiatasemete lõplikku kohandamist erinevate alamsüsteemide paljude sõltuvuste tõttu. Üldiselt saab samm-sammult rakendamise ja testimise protsessi kirjeldada järgmiselt:

) Nagiosel põhineva kerneli installimine ja silumine;

) Nagiose põhifunktsioonidega kaughostide jälgimise seadistamine;

) MRTG abil võrguliideste koormuse jälgimise mooduli reguleerimine;

) Süsteemi tuuma funktsionaalsuse laiendamine ja integreerimine MRTG mooduliga;

) Süsteemi logide kogumise mooduli seadistamine;

) Skripti kirjutamine seiresüsteemi pakettfiltri lähtestamiseks, et tagada süsteemi turvalisus.

7. Infoturve

1 Töökoha omadused

Arvuti kasutamisel tööd mõjutavad kahjulikud tegurid on järgmised:

· elektrivoolu pinge suurenenud väärtus;

· müra;

· elektromagnetiline kiirgus;

· elektrostaatiline väli.

Tõhusaks ja ohutuks tööks parimate tingimuste tagamiseks on vaja luua sellised töötingimused, mis oleksid mugavad ja vähendaksid nende kahjulike tegurite mõju. On vaja, et loetletud kahjulikud tegurid oleksid kooskõlas kehtestatud eeskirjade ja eeskirjadega.

7.2 Tööohutus

2.1 Elektriohutus

Kavandatud tarkvaratööriist on mõeldud töötama olemasolevas serveris, mis asub spetsiaalselt varustatud tehnilises ruumis. See on varustatud kaablikanalitega kaablite vedamiseks. Iga server on varustatud toitega ~ 220V, sagedusega 50Hz, töötava maandusega. Enne toiteallika sisenemist ruumi paigaldatakse automaatsed lülitid, mis lülitavad lühise korral toite välja. Eraldi kaitsemaandus.

Arvuti ühendamisel tuleb seadme korpus ühendada kaitsemaandusjuhtmega, et isolatsiooni tõrke korral või muul põhjusel ei saaks inimese seadme korpust puudutades tekkida toiteallika ohtlik pinge. ohtlik vool läbi inimkeha.

Selleks kasutatakse elektripistikupesades olevat kolmandat kontakti, mis on ühendatud kaitsemaandusjuhiga. Seadme korpused on maandatud läbi toitekaabli mööda spetsiaalset juhet.

Pinge all olevate osade isolatsiooni purunemise korral rakendatakse tehnilisi meetmeid, et tagada kaitse elektrilöögi eest elektripaigaldise korpuse puudutamisel, mille hulka kuuluvad:

· kaitsev maandus;

· kaitsev nullimine;

· kaitsev väljalülitamine.

7.2.2 Mürakaitse

Uuringud näitavad, et mürarohketes tingimustes kahjustatakse eelkõige kuulmisfunktsioone. Kuid müra mõju ei piirdu ainult mõjuga kuulmisele. See põhjustab märgatavaid nihkeid mitmetes füsioloogilistes vaimsetes funktsioonides. Müra mõjutab negatiivselt närvisüsteemi ja vähendab sensomotoorsete protsesside kiirust ja täpsust, suureneb vigade arv intellektuaalsete probleemide lahendamisel. Müra mõjutab märgatavalt inimese tähelepanu ja tekitab negatiivseid emotsioone.

Peamiseks müraallikaks ruumides, kus arvutid asuvad, on kliimaseadmed, printimis- ja paljundusseadmed ning arvutites endis jahutussüsteemi ventilaatorid.

Tootmisruumis kasutatakse aktiivselt järgmisi müratõrjemeetmeid:

· vaiksete jahutusmehhanismide kasutamine;

· müraallikate isoleerimine keskkonnast heliisolatsiooni ja helineeldumise abil;

· helisummutavate materjalide kasutamine sisekatteks.

Töökohal esinevad järgmised müraallikad:

· süsteemiüksus (jahuti (25dB), kõvaketas (29dB), toiteplokk (20dB));

· printer (49dB) .

Nende seadmete kogumüra L arvutatakse järgmise valemi abil:

kus Li on ühe seadme müratase, dB= 10*lg(316,23+794,33+100+79432,82) = 10*4,91 = 49,1 dB

Vastavalt SN 2.2.4 / 2.1.8.562-96 ei tohiks matemaatikute-programmeerijate ja videooperaatorite töökohal müratase ületada 50 dB.

7.2.3 Kaitse elektromagnetkiirguse eest

Elektromagnetiliste häirete eest pakuvad kaitset elektrit juhtiva pinnaga ekraanid ja madala kiirguse süsteemiga varustatud monitoride kasutamine, mis minimeerib kahjuliku kiirguse taset, samuti vedelkristallkuvarid, milles elektromagnetkiirgus täielikult puudub.

7.2.4 Elektrostaatiline kaitse

Elektrostaatilise laengu eest kaitsmiseks kasutatakse maandatud kaitsefiltrit, õhuniisutajaid, põrandad on kaetud antistaatilise kattega. Positiivsete ja negatiivsete ioonide kontsentratsiooni normaliseeritud väärtuste säilitamiseks ruumides, kus on arvutid, kliimaseadmed, õhuionisatsiooniseadmed ja loomulik ventilatsioon viiakse läbi vähemalt 10 minutit iga 2 töötunni järel.

Vältimaks õhus lendlevate osakestega tolmuosakeste kahjulikku mõju töötavate inimeste kehale, tehakse ruumide märgpuhastust iga päev ja ekraanidelt eemaldatakse tolm vähemalt kord vahetuses, kui monitor on välja lülitatud.

7.3 Töötingimused

3.1 Tootmisruumi mikrokliima

Käesolevas lõputöös käsitletud seadmed ei tekita töö käigus kahjulikke aineid. Seega ei avalda õhukeskkond ruumis, kus neid kasutatakse, inimkehale kahjulikku mõju ja vastab I kategooria töö nõuetele vastavalt GOST 12.1.005-88.

Tööstusruumide tööpiirkonna temperatuuri, suhtelise niiskuse ja õhu kiiruse optimaalsed standardid on standarditud GOST 12.1.005-88-ga ja on toodud tabelis 7.1.

Tabel 7.1 – Mikrokliima parameetrid

Normaliseeritud parameeterVäärtusOptimaalne LubatavTegelik õhutemperatuur, С20 - 2218 - 2020 Niiskus,% 40 - 60 Mitte rohkem kui 8045 Õhukiirus, m/s0,20,30...0,3

Mikrokliima vastab optimaalsetele tingimustele.

3.2 Tööstusvalgustus

Arvutamiseks valime Verkhnyaya Pyshma linna Gerkon LLC tugiosakonna, kus see projekt välja töötati:

· ruumi pindala on 60m2;

· valgusavade pindala on 10 m2;

· Paigaldati 4 töökohta.

Loodusliku valgustuse arvutamine toimub vastavalt valemile SNiP 23.05-95:

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

kus S0 on valgusavade pindala, m2;

Sp - ruumi põrandapind, m2, 60;

et - loomuliku valgustuse koefitsient, 1,6;

Kz - ohutustegur, 1,5;

N0 - akendele iseloomulik valgus, 1;

KZD - koefitsient, mis võtab arvesse akende tumenemist vastandlike hoonete poolt, 1,2;

T0 - summaarne valguse läbilaskvuse koefitsient, 0,48;

T1 - ruumi pinnalt peegelduskoefitsient, 1.2.

Kõikide koefitsientide väärtused on võetud SNiP-st 23.05.-95.

Arvutuse tulemusena saame: akende valgusavade nõutav pindala S0 = 3,4 m2. Tegelik avade pindala on 10m2, mis ületab seda tüüpi ruumide minimaalset lubatud valgusavade pinda ja on piisav päevavalgustundidel.

Kunstliku valgustuse arvutamine ruumi jaoks, mida valgustab 15 LDC-60 tüüpi luminofoorlampi võimsusega 60 W.

Vastavalt standardile SNiP 23.05-95 peab luminofoorlampide valgustuse hulk horisontaaltasandil olema vähemalt 300 lm - üldvalgustussüsteemi jaoks. Arvestades ülitäpset visuaalset tööd, saab valgustuse väärtust tõsta kuni 1000lm.

Luminofoorlambi valgusvoog arvutatakse SNiP 23.05.-95 valemi järgi:

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

Kus En - ruumi normaliseeritud valgustus, lx, 200;

S - ruumi pind, m2, 60;

Z - koefitsient, võttes arvesse keskmise valgustuse ja minimaalse suhet, 1,1;

K - õhusaastet arvestav ohutustegur, 1,3;

N - kinnitusdetailide arv, 15;

η - valgusvoo kasutustegur, 0,8.

Selle tulemusena saame Phi = 1340lm, kõigi lampide summaarne valgusvoog on 3740lm, seega on labori valgustus üle minimaalselt lubatava.

7.4 Töökoha ergonoomika

4.1 Töökoha korraldus

SanPiN 2.2.2 / 4.2.1340-03 kohaselt peab VDT (videoekraani terminal) vastama järgmistele tehnilistele nõuetele:

· valgustuse heledus mitte alla 100cd/m2;

· valguspunkti minimaalne suurus ei ole värviekraanil suurem kui 0,1 mm;

· märgi kujutise kontrastsus ei ole väiksem kui 0,8;

· vertikaalse skaneerimise sagedus vähemalt 7 kHz

· punktide arv ei ole väiksem kui 640;

· peegeldusvastane ekraanikate;

· ekraani suurus diagonaalselt vähemalt 31 cm;

· märkide kõrgus ekraanil ei ole väiksem kui 3,8 mm;

· kaugus operaatori silmadest ekraanini peaks olema umbes 40-80 cm;

VDT peaks olema varustatud pöördlauaga, mis võimaldab seda horisontaal- ja vertikaaltasandil liigutada 130-220 mm piires ja muuta ekraani nurka 10-15 kraadi võrra.

Lõputöö viidi läbi arvutis VDT ViewSonicuga, mille diagonaal on 39 cm. See monitor on valmistatud vastavalt maailma standarditele ja vastab kõigile ülaltoodud tehnilistele nõuetele.

Klaviatuurinõuded on järgmised:

· ümbrismaaling rahustavates pehmetes toonides hajutatud valguse hajutamisega;

· matt pind peegeldusteguriga 0,4–0,6 ja läikivate detailideta, mis võivad tekitada pimestamist;

Projekt viidi läbi Logitechi kaubamärgiga klaviatuuril, mis vastab kõigile ülaltoodud nõuetele.

Süsteemiplokid paigaldatakse töökohale, võttes arvesse lihtsat juurdepääsu disketiseadmetele ning mugavat juurdepääsu tagaküljel asuvatele pistikutele ja juhtnuppudele. Sageli kasutatavaid diskette hoitakse süsteemiüksuse lähedal tolmu ja elektromagnetiliselt kaitstud rakus. Printer asub kasutajast paremal. Prinditud tekst on operaatorile nähtav, kui ta on põhitööasendis. Spetsiaalsetes sektsioonides hoitakse printeri lähedal tühja paberit ja muid olulisi tarvikuid.

Ühenduskaablid asetatakse spetsiaalsetesse kanalitesse. Kanalite paigutus peab olema selline, et pistikud ei segaks kaablite väljatõmbamist.

"Hiire" manipulaatori jaoks on kasutajast paremal lauaplaadil vaba ala, mis peaks olema oma kuju ja suurusega identne ekraani pinnaga.

Käitaja töökoht vastab GOST 12.2.032-78 SSBT nõuetele.

Töökoha ruumiline korraldus tagab optimaalse tööasendi:

· pea kallutatud ettepoole 10-20 kraadi;

· selg on rõhuasetusega, suhe õla ja küünarvarre, samuti reie ja sääre vahel on täisnurk.

Töökoha peamised parameetrid peavad olema reguleeritavad. See tagab võimaluse luua inimesele soodsad töötingimused, võttes arvesse geoantropomeetrilisi omadusi.

Personaalarvutiga varustatud töökoha ja mööbli peamised parameetrid (joonis 7.1)

Riis. 7.1 - Arvuti operaatori töökoht

· istme kõrgus 42 - 45 cm;

· klaviatuuri kõrgus põrandast 70 - 85 cm;

· klaviatuuri kaldenurk horisontaalselt 7–15 kraadi;

· klaviatuuri kaugus laua servast 10 - 26 cm;

· kaugus ekraani keskosast põrandani 90 - 115 cm;

· ekraani kaldenurk vertikaalselt 0 - 30 kraadi (optimaalne 15);

· ekraani kaugus laua servast 50 - 75 cm;

· tööpinna kõrgus kirjutamiseks 74 - 78cm;

Töökohal on jalatugi, mis on soovitatav igat tüüpi tööks, mis on seotud pikaajalise istumisega

SanPiN 2.2.2.542-96 järgi peetakse arvutioperaatori töö olemust lihtsaks ja see kuulub kategooriasse 1A.

Vaheajad määratakse pärast 2 tunni möödumist töövahetuse algusest ja 2 tundi pärast lõunapausi, kumbki 15 minutit. Reguleeritud pauside ajal tehakse neuro-emotsionaalse stressi, väsimuse ja hüpodünaamia mõju kõrvaldamiseks harjutuste komplekte.

7.5 Tuleohutus

Ruumil, kus selle projekti kallal tööd tehti, on tuleohu kategooria. NPB 105-03 -süttivad ja mittesüttivad vedelikud, tahked põlevad ja mittesüttivad ained ja materjalid, sealhulgas tolm ja kiud, ained ja materjalid, mis võivad omavahel suhelda veega, hapnikuga õhuga või üksteisega ainult põletada, tingimusel et ruumid, kus need on saadaval või moodustatud, ei kuulu A või B kategooriasse. Hoone I tulepüsivusastmega ruumidele vastavalt SNiP 21-01-97 .

Tootmispiirkonnas järgitakse järgmisi ohutuseeskirju:

· läbipääsud, väljapääsud ruumidest, juurdepääs tulekustutusvahenditele on vabad;

· töökorras seadmed on heas töökorras ja neid kontrollitakse iga kord enne tööle asumist;

· tööde lõpetamisel ruumide ülevaatus, elektrivarustus pingevaba, ruumid suletakse.

Evakuatsiooniväljapääsude arv hoonetest ruumidest on kaks. Avariiväljapääsu (ukse) laius on 2m. Evakuatsiooniteedel kasutatakse tavalisi redeleid ja hingedega uksi. Trepikodadel puuduvad ruumid, tehnoloogilised kommunikatsioonid, liftide ja kaubaliftide väljapääsud. Evakuatsiooniteed on varustatud nii loomuliku kui ka kunstliku turvavalgustusega.

Esmase tulekustutusvahendina ruumis on manuaalsed süsihappegaaskustutid koguses kaks.

Tulekahju algfaasi avastamiseks ja tuletõrje teavitamiseks kasutatakse automaat- ja tulekahjusignalisatsioonisüsteemi (APS). See käivitab iseseisvalt tulekustutusseadmed, kuni tulekahju on saavutanud suure ulatuse, ja teavitab linna tuletõrjet.

EK objektid, välja arvatud APS, peavad olema varustatud statsionaarsete tulekustutusseadmetega. Gaaskustutusseadmete kasutusalad, mille toime põhineb ruumi kiirel täitumisel tulekustutusgaasi ainega, mille tulemusena väheneb hapnikusisaldus õhus.

7.6 Hädaolukorrad

Selles keskkonnas oleks kõige tõenäolisem hädaolukord tulekahju. Tulekahju korral on vajalik personal evakueerida ja juhtunust tuletõrjet teavitada. Evakuatsiooniplaan on näidatud joonisel 7.2.

Riis. 7.2 – Tuletõrjeplaan

8. MAJANDUSOSA

Selles jaotises käsitletakse võrguseiresüsteemi väljatöötamise, selle juurutamise ja hoolduse ning sellega seotud materjalide ja seadmete kulusid.

Projekti maksumus kajastab arendus- ja tootmisprotsessis kulutatud tööjõuvahendite ja -objektide maksumust (amortisatsioon, seadmete, materjalide, kütuse, energia jms maksumus), osa elujõulisuse kuludest (palk) , ostetud süsteemimoodulite maksumus.

Tegevuse ja teenuste osutamise mahu suurenemise käigus kerkis esile probleem vigade ja nõrkade kohtade proaktiivsel tuvastamisel võrgukorralduses ehk ülesandeks oli juurutada lahendus, mis võimaldaks prognoosida väljavahetamise või uuendamise vajadust. võrgulõigud enne rikkeid mõjutavad abonendisõlmede tööd.

Kliendibaasi ja sellest tulenevalt ka aktiivsete seadmete arvu kasvuga tekkis vajadus kiiresti ja üksikasjalikult jälgida võrgu kui terviku ja selle üksikute elementide seisukorda. Enne võrguseiresüsteemi kasutuselevõttu pidi võrguadministraator looma ühenduse telneti, http, snmp, ssh jne protokolle kasutades. igale huvipakkuvale võrgusõlmele ja kasutage sisseehitatud jälgimis- ja diagnostikatööriistu. Hetkel on võrgu võimsuseks 5000 porti, 300 Layer 2 switchi, 15 ruuterit ja 20 siseserverit.

Lisaks avastati võrgu ülekoormus ja katkendlikud vead alles siis, kui kasutajatel tekkisid tõsised probleemid, mis takistasid võrgu uuendamise plaane.

Kõik see tõi esiteks kaasa pakutavate teenuste kvaliteedi pideva halvenemise ning süsteemiadministraatorite ja kasutajate tehnilise toe koormuse suurenemise, mis tõi kaasa tohutuid kahjusid.

Vastavalt hetkeolukorrale otsustati välja töötada ja juurutada võrguseiresüsteem, mis lahendaks kõik ülaltoodud probleemid, mida võib kokkuvõtlikult väljendada järgmiselt:

Vajalik on välja töötada ja juurutada seiresüsteem, mis võimaldab jälgida nii lüliteid, erinevate tootjate ruutereid kui ka erinevate platvormide servereid. Keskenduge avatud protokollide ja süsteemide kasutamisele, kasutades maksimaalselt vabatarkvarafondi valmisarendusi, mis majanduslikust aspektist vähendab lõpliku süsteemi litsentsimise kulud nullini.

Majanduslikus mõttes peab süsteem vastama järgmistele nõuetele:

· miinimumnõuded riistvararessurssidele (see toob kaasa väiksemad kulud projekti riistvaraosale);

· kompleksi kõigi komponentide avatud lähtekoodid (võimaldab iseseisvalt muuta süsteemi põhimõtet ilma kolmandate osapoolte arendusi kasutamata ja vähendab toote litsentsimise kulusid);

· süsteemi laiendatavus ja mastaapsus (võimaldab laiendada rakenduse ulatust ilma kolmandate osapoolte ja varaliste arenduste abita ning vähendab toote litsentsimise kulusid);

· standardsed diagnostilise teabe edastamise vahendid (võimaldab vähendada süsteemi hoolduskulusid);

· kõigi kasutatavate tarkvaratoodete üksikasjaliku dokumentatsiooni olemasolu (võimaldab uue töötaja kiiret koolitamist);

· oskus töötada erinevate tootjate seadmetega (võimaldab kasutada ühte tarkvaratoodet). (Täieliku varustuse loetelu leiate lisast B).

Üldiselt võttis projekti arendus 112 tundi (2 nädalat). Selle projekti elluviimiseks kulub 56 tundi (1 nädal).

1 Projekti arenduskulude arvestus

Projekti arenduskulud koosnevad:

· palgakulud;

· seadmete ja tarkvaratoodete amortisatsioonikulud;

· elektrikulud;

· pea kohal.

Palgakulud.

Palgakulude arvutamisel võtame arvesse, et selle projekti töötas välja üks inimene: süsteemiinsener.

Vajaliku tasemega süsteemiinseneri keskmine turupalk piirkonnas on 30 000 rubla.

Arvutame inseneri töö 1 tunni maksumuse järgmiste andmete põhjal:

· lisatasu 25%;

· ringkonnakoefitsient 15%;

· tööajafond on 2010. aastal vastavalt tootmiskalendrile 1988 tundi;

Seega on määr, võttes arvesse piirkondlikku koefitsienti, järgmine:

RF = 30000 * 1,25 * 1,15 * 12 / 1988 \u003d 260 rubla

Palgakulude arvutamisel võetakse arvesse kogunenud töötasust tehtud mahaarvamisi, see tähendab, et kindlustusmakse määra kogusumma võrdub maksimaalse UST määraga - 26%, sealhulgas:

· PFR - 20%;

· FSSR – 2,9%

· FFOMS - 1,1%;

· GFOMS - 2%;

· Kohustuslik sotsiaalne õnnetusjuhtumikindlustus - 0,2%.

Mahaarvamiste kogusumma on:

CO \u003d RF * 0,262 \u003d 260 * 0,262 \u003d 68 rubla

Arvestades inseneri tööaega (112 tundi arenduseks ja 56 tundi teostamiseks), arvestame palgakulud:

ZP \u003d (112 + 56) * (RF + CO) \u003d 168 * 328 \u003d 55104 rubla

Seadmete ja tarkvaratoodete amortisatsioonikulud.

Võrguprojekti arendamise etapis kasutati põhiseadmetena personaalarvutit ja AQUARIUS SERVER T40 S41 serverit. Arvuti hind on hetkel umbes 17 000 rubla, serveri hind aga 30 000 rubla.

Seega on ühekordse investeeringu maksumus seadmetesse:

PBA = 47000 rubla

Arvuti ja serveri eluea jooksul on lubatud neid uuendada, seda tüüpi kulu arvestatakse ka arvestuses. Paigaldame 50% haagismajast moderniseerimiseks:

RMA \u003d PB * 0,5 \u003d 23500 rubla

Arvutit kasutati järgmistes etappides:

· kirjanduse otsing;

· lahenduste otsimine võrguseiresüsteemi projekteerimiseks;

· struktuuride ja allsüsteemide arendamine;

· võrguseiresüsteemi projekteerimine;

· dokumendi vormindamine.

Serverit kasutati süsteemi juurutamise ja vahetu töö käigus süsteemiga.

Arenduses kasutatavad tarkvaratooted on hangitud tasuta litsentside alusel, mis tähendab, et nende maksumus on null ja nende amortisatsiooni vajadus puudub.

Seega on seadmete kogumaksumus, võttes arvesse amortisatsiooni,:

OZA \u003d PVA + RMA \u003d 47000 + 23500 \u003d 70500 rubla

Eeldatakse, et kasutusiga on 2 aastat. Ühe töötunni maksumus on (arvestades tööpäevade arvu kuus 22 ja 8-tunnise tööpäevaga):

SOCHR \u003d OZA / VR \u003d 70500 / 4224 \u003d 16,69 rubla

Väljatöötamise ja rakendamise ajal on amortisatsiooni mahaarvamise maksumus vastavalt:

SACHRV \u003d SOCHR * TRV \u003d 16,69 * 168 \u003d 2803,92 rubla

Elektrikulud.

Elektrikulu on arvuti tarbitud ja valgustusele kulunud summa. Elektrikulu:

SEN \u003d 0,80 rubla / kW * h (kokkuleppel ruumide omanikuga)

Рк,с = 200 W - arvuti või serveri tarbitav võimsus.

Тrk = 168 h - arvuti tööaeg süsteemi arendamise ja juurutamise etapis.

Трс = 52 h - serveri tööaeg süsteemi arendamise ja juurutamise etapis.

Seega on elektrienergia maksumus projekti väljatöötamise ja elluviimise etapis:

SENP \u003d Rk * Trk * SEN + Rk * Trs * SEN \u003d (200 * 168 * 0,80 + 200 * 52 * 0,80) / 1000 \u003d (26880 + 8320) / 100,2 rubla 3 rubla

Töökoht, kus see töö tehti, on varustatud 100 W lambiga. Arvutame välja valgustusseadme poolt süsteemi väljatöötamise ja juurutamise ajal tarbitud elektrienergia maksumuse:

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

Elektrikulu kokku oli:

OZEN \u003d SENP + SENO \u003d 35,2 + 13,44 \u003d 48,64 rubla

8.2 Üldkulude arvestus

See kuluartikkel hõlmab muude seadmete ja kulumaterjalide kulusid, samuti ettenägematuid kulusid.

Ettevõtte eelarves on üldkulud 400% kogunenud töötasust:

HP \u003d ZP * 4 \u003d 55104 * 4 = 220416 rubla.

Seega moodustasid projekti arendamise ja elluviimise kulud:

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

3 Tõhusus

Majandusarvutuste tegemise tulemusena määrati võrguseiresüsteemi arendamise ja juurutamise miinimumhinnaks 278 372,56 rubla.

Nagu arvutustest näha, langeb valdav osa kulutustest materjalidele ja seadmetele. Seda seletatakse asjaoluga, et peamised seadmete tootjad on välisettevõtted ja vastavalt sellele on nende toodete hinnad esitatud USA dollarites Venemaa keskpanga kursiga + 3%. Ja imporditud toodete tollimaksude tõus mõjutab lõpptarbijate hinda negatiivselt.

Süsteemi iseseisva arendamise õigustamiseks võrdleme selle maksumust turul olevate valmislahendustega:

· D-Link D-View - 360 000 rubla