27.06.2011 Nate McAlmond

Valitsin kolme ehdokasta: WhatsUp Gold Premium Ipswitchiltä, ​​OpManager Professional ManageEngineltä ja ipMonitor SolarWindsiltä. Jokainen näistä verkkoskannereista maksaa alle 3 000 dollaria (100 laitetta kohden), ja jokaisella niistä on kokeilujakso, jonka aikana voit testata valittua tuotetta ilmaiseksi

Työskentelen keskisuuressa yrityksessä ja olemme käyttäneet samaa verkonvalvontajärjestelmää nyt noin seitsemän vuotta. Se antaa ylläpitäjillemme perustiedot palvelimien ja palveluiden saatavuudesta ja lähettää tekstiviestejä matkapuhelimiimme ongelmatilanteissa. Olen tullut siihen tulokseen, että sinun on päivitettävä järjestelmä tai ainakin lisättävä tehokas työkalu, joka voi tarjota paremman suorituskyvyn ja antaa yksityiskohtaista tietoa verkossasi isännöityjen päätepalvelinten, Exchange-järjestelmien ja SQL:n tilasta. . Verrataanpa ehdokkaitamme.

Löytöprosessi

Testaukseen valmistautumista varten ensimmäinen askel oli ottaa SNMP-palvelu käyttöön kaikissa laitteissa, mukaan lukien Windows-palvelimet. Muutamalla SNMP-palvelun asetuksia asetin vain luku -oikeudet kaikille laitteille, jotka valvontaprosessin tulisi kattaa. Windows Server 2003/2000 -järjestelmissä SNMP-palvelu asennetaan ohjatun Windowsin komponenttien asennustoiminnon avulla, joka sijaitsee Lisää tai poista sovellus -paneelissa, ja Windows Server 2008:ssa SNMP-komponentit lisätään ohjatun palvelimen hallinnan avulla. Kun olet suorittanut ohjatun toiminnon, sinun on käynnistettävä Ohjauspaneeli-kansiossa oleva Services-laajennus ja määritettävä SNMP-palvelu - tämä ei ole vaikeaa. Hallittavissa verkkolaitteissa, kuten palomuureissa, kytkimissä, reitittimissä ja tulostimissa, on myös SNMP-palvelunhallintatyökalut, ja konfigurointiprosessi on yleensä melko yksinkertainen toimenpide. Lisätietoja SNMP-palvelusta on "Simple Network Management Protocol" -asiakirjassa (technet.microsoft.com/en-us/library/bb726987.aspx).

Seuraavaksi asensin kaikki kolme valvontajärjestelmää yhteen kahdesta toimivasta järjestelmästäni Windows XP SP3:lla. Kun järjestelmä oli asennettu, se koostui kahdesta osasta: tietokannasta ja verkkopalvelimesta. Useat järjestelmänvalvojat voivat hallita jokaista valituista järjestelmistä verkkokäyttöliittymän kautta, ja sinulla on mahdollisuus määrittää tilejä eri käyttöoikeustasoilla. Yhteistä näille kolmelle järjestelmälle on, että jokainen käyttäjä voi lisätä, poistaa ja siirtää paneeleja työtilassaan. Paneeleissa näkyy samantyyppisiä tietoja, kuten prosessorin kuormitus tai muistin käyttö verkon eri laitteissa.

Ennen kuin aloitan verkkoskannauksen (kutsutaan etsintäprosessiksi), määritin tiliasetukset, joita kunkin järjestelmän tulee käyttää päästäkseen käsiksi verkosta löydettyihin laitteisiin. Kuten vertailutaulukosta näkyy, Ipswitch WhatsUp Gold Premium -järjestelmän avulla voit luoda tilin SNMP-, WMI-, Telnet-, SSH-, ADO- ja VMware-palveluille. ManageEngine OpManager Professional tukee SNMP-, WMI-, Telnet-, SSH- ja URL-protokollia, kun taas SolarWinds ipMonitor tukee SNMP-, WMI- ja URL-protokollia.

Kun olin määrittänyt SNMP-palvelun verkkolaitteille ja tileille (Windows ja SNMP) jokaiselle verkon valvontajärjestelmälle, aloitin paikallisverkon IP-osoitteiden etsintäprosessin. Kaikki järjestelmät havaitsivat noin 70 laitetta. Oletusskannausasetuksia käyttämällä testattavat järjestelmät onnistuivat hyvin laitetyyppien tunnistamisessa ja yksityiskohtaisten laitteiden tilatietojen toimittamisessa. Kaikki kolme järjestelmää sisältävät antureita keskeisten laitteiden ja palvelinten suorituskyvylle, kuten suorittimen kuormitukselle, muistinkäytölle, levynkäytölle/täyteisyydelle, pakettien katoamiselle/viiveelle, Exchange-palvelujen, Lotuksen, Active Directoryn ja kaikkien Windows-palvelujen tilalle. Jokaisessa järjestelmässä oli mahdollisuus lisätä antureita sekä yksittäisille laitteille että suurille laiteryhmille.

OpManager- ja WhatsUp Gold -paketit tarjoavat käyttöliittymän VMware-palvelutapahtumien tunnistamiseen ja keräämiseen palvelimilta ja vierailta. Lisäksi molemmissa tuotteissa on kytkimen portinhallinnan kyselyominaisuus, joka näyttää, mitkä laitteet on kytketty hallittujen kytkimien eri portteihin. Nämä tiedot auttavat sinua määrittämään, mikä kytkinportti muodostaa yhteyden tiettyyn yrityssovellukseen, ilman, että sinun tarvitsee jäljittää kaapeleita manuaalisesti palvelinhuoneissa. Voit edelleen määrittää hälytyksiä tietyille kytkinporteille. Kun työskentelet OpManager-paketin kanssa, saadaksesi kyselyporttien tulokset valitsemalla kytkin ja suorittamalla Switch Port Mapper -työkalu - järjestelmä palauttaa tulokset muutamassa sekunnissa. Samanlainen WhatsUp Goldin mukana tuleva työkalu on nimeltään MAC Address, ja se on suoritettava niin, että Get Connectivity -vaihtoehto on valittuna. WhatsUp Goldin tulosten saaminen kestää kauemmin, koska se yrittää skannata laitteita ja kerätä yhteystietoja koko verkossa.

Ipswitch WhatsUp Gold Premium

Ipswitch WhatsUp Gold Premium
TAKANA: tarjoaa tarkimmat tulokset kolmesta kilpailijasta, voit luoda omia antureitasi, tarjoaa kattavat valvontatyökalut VMware-järjestelmille, integroituu AD:n kanssa.
VASTAAN: vähemmän sisäänrakennettuja antureita ja korkeammat kustannukset verrattuna kilpailijoihin (jos ostat lisenssin alle 500 laitteelle).
ARVOSANA: 4,5/5.
HINTA: 7495 dollaria 500 laitteella, 2695 dollaria 100 laitteella, 2195 dollaria 25 laitteella.
SUOSITUKSET V: Suosittelen WhatsUp Gold IT:tä osastoille, jotka palvelevat suuria VMware-ympäristöjä tai haluavat rakentaa omia antureita.
YHTEYSTIEDOT: ipswitch www.ipswitch.com

IpMonitor- ja OpManager-järjestelmien kanssa työskennellessäni törmäsin toisinaan käsittämättömiin lukemiin, jotka hämmentyivät. IpMonitorissa kojelaudat saattoivat näyttää negatiivisia arvoja, kun suorittimen käyttötaso laski merkittävästi. Toisessa tapauksessa, kun prosessorin kuormitus oli lähellä nollaa, IpMonitor-järjestelmä lähetti minulle ilmoituksen, että prosessori oli käytössä 11,490%! OpManager-järjestelmä, kun se seurasi ja lähetti minulle oikeat tiedot toimialueen ohjauskoneiden levynkäytöstä, ei joissain tapauksissa sisällyttänyt yhtään ohjainta 10 palvelimen luetteloon, joissa on maksimilevytilaa. Samaan aikaan viereinen paneeli ilmoitti, että yhden verkkoalueen ohjaimistani ei pitäisi olla edes kymmenen parhaan joukossa, vaan kolmen parhaan joukossa. WhatsUp Goldia käyttäessäni en törmännyt tällaisiin tilanteisiin. WhatsUp Gold tarkkailee paneeliensa prosessoriytimien käyttöä, ja kun vertasin WhatsUp Gold -paneelien tuloksia Windows Performance Monitorin lukemiin, ne olivat täsmälleen samat jokaiselle ytimelle. Samoin kiintolevyn käyttötiedot ilmoitettiin oikein kaikille asiaankuuluville työtilasovelluksille.

WhatsUp Goldissa on sisäänrakennettu anturikirjasto, jonka avulla voit luoda uusia antureita olemassa olevien antureiden perusteella. Suurille organisaatioille tämä ominaisuus saattaa olla hyödyllinen, koska sen avulla voit luoda yhden anturisarjan erityyppisten laitteiden valvontaa varten. Tämä on tehokkain tapa määrittää antureita laiteryhmälle.

WhatsUp Goldissa ei ole antureita tiettyjen valmistajien laitteille (lukuun ottamatta APC UPS -virtalähteiden anturia), toisin kuin OpManager-paketti, joka käyttää omia antureita Dellin, HP:n ja IBM:n laitteille, mutta sen avulla voit luoda Active Skriptityyppiset anturit. Tämän tyypin avulla voit kehittää omia valvontaprosessejasi VBScript- ja JScript-ohjelmointikielillä. Active Script -antureilla on online-tukikeskus, josta WhatsUp Gold -käyttäjät voivat saada ja ladata valmiita skriptejä.

Ainoa parannus, jonka haluaisin lisätä WhatsUp Gold -järjestelmään, on käyttöliittymä (kuva 1), lähinnä siksi, että se on liian lineaarinen. Esimerkiksi kestää jopa 5 napsautusta Peruuta- ja Sulje-painikkeilla palataksesi Active Monitor Library -ikkunasta takaisin työtilaan. WhatsUp Gold -järjestelmässä ei myöskään ole anturia (ellet tietenkään kirjoita sitä manuaalisesti), joka tarkistaa sivuston tilan, ja se voi olla tarpeen varsinkin tapauksissa, joissa sivustoa isännöi kolmannen osapuolen palvelin eikä siihen ole muita tapoja päästä käsiksi.

Kuva 1: WhatsUp Gold Premium -käyttöliittymä

Voit käsitellä tilanteita, joissa laitteet ovat käyttämättömänä jonkin aikaa, määrittämällä ilmoitukset lähetettäväksi 2, 5 ja 20 minuutin välein. Tällä tavalla voit kiinnittää järjestelmänvalvojan huomion siihen, että tärkeimmät solmut eivät vastaa tietyn ajan.

WhatsUp Gold on ainoa harkittava järjestelmä, jolla on kyky integroitua LDAP-ympäristöön - tämä hetki voi olla ratkaiseva valittaessa ratkaisua suuriin verkkoihin.

ManageEngine OpManager

ManageEngine OpManager
TAKANA: paras käyttöliittymä kolmen tuotteen joukossa; enemmän sisäänrakennettuja antureita kuin kaksi muuta järjestelmää; alin hinta, kun ostat lisenssin enintään 50 laitteelle.
VASTAAN: testien aikana kaikki laitteen ilmaisimet eivät näkyneet oikein; saattaa kestää jonkin aikaa, ennen kuin järjestelmä on täysin toimiva.
ARVOSANA: 4,5/5.
HINTA: 1995 dollaria 100 laitteella, 995 dollaria 50 laitteella, 595 dollaria 25 laitteella.
SUOSITUKSET: IT-osastot, jotka haluavat saada kaiken irti laatikosta (poikkeuksena AD-integraatio), arvostavat OpManager Professionalia. Kun ostat 26-50 laitteen lisenssejä, sen hinta on lähes puolet kahden muun tuotteen hinnasta.
YHTEYSTIEDOT: ManageEngine www.manageengine.com

OpManager-järjestelmän asennuksen jälkeen huomasin, että oli helppo konfiguroida valtava määrä toimintoja ja kätevä liikkua niiden välillä. OpManager tarjoaa mahdollisuuden lähettää (sähköpostien ja tekstiviestien lisäksi) suoria viestejä Twitter-tilille - mukava vaihtoehto sähköpostille. Tämä Twitter-tilien käyttö pitää minut ajan tasalla mitä verkossa tapahtuu, mutta koska puhelimeni ei soi, kun välitän viestejä Twitter-järjestelmästä, haluan myös saada tekstiviesti-ilmoituksia tärkeimmistä tapahtumista rinnakkain. Pystyn katsomaan kynnystietoja millä tahansa palvelimella Twitter-viestien avulla ja näin ollen minulla on loki verkon ajankohtaisista tapahtumista, mutta kriittisten hälytysten lähettämiseen ei ole välttämätöntä käyttää tätä järjestelmää.

Vakioanturien lisäksi OpManager tarjoaa toimittajien kehittämiä SNMP-suorituskyvyn seurantatekniikoita laitteille, kuten Dell Power-Edge, HP Proliant ja IBM Blade Center. OpManager voidaan myös integroida Google Maps -sovellusliittymään, jotta voit lisätä laitteesi Google-karttaan. Tämä edellyttää kuitenkin, että ostat Google Maps API Premium -tilin (ellet aio asettaa karttaasi julkisesti saataville) Google Maps API -järjestelmän ilmaisen version lisenssiehtojen mukaisesti.

Selvittääksesi tilanteet, joissa järjestelmänvalvoja saa hälytyksen, mutta ei vastaa siihen tiettyyn aikaan, OpManager voidaan määrittää lähettämään lisähälytys toiselle järjestelmänvalvojalle. Esimerkiksi työntekijä, joka yleensä vastaa tietyn palvelinryhmän kriittisten tapahtumien käsittelystä, voi olla kiireinen tai sairas. Tällaisessa tapauksessa on järkevää asettaa lisähälytys, joka kiinnittää toisen järjestelmänvalvojan huomion, jos ensimmäistä hälytystä ei ole katsottu tai tyhjennetty määritetyn tunti-/minuuttimäärän kuluessa.

Kolmesta tarkastetusta tuotteesta vain OpManager-järjestelmässä oli osio, joka oli tarkoitettu WAN-verkon VoIP-vaihdon laadun valvontaan. VoIP-valvontatyökalujen käyttämiseksi sekä lähde- että kohdeverkkojen laitteiden on tuettava Cisco IP SLA -tekniikkaa. Lisäksi kuvassa 2 näkyvä OpManager-käyttöliittymä sisältää enemmän antureita ja kojetauluja kuin mikään kilpailevista tuotteista.

Kuva 2: OpManager Professional -käyttöliittymä

SolarWinds ipMonitor

SolarWinds ipMonitor
TAKANA: rajoittamaton määrä laitteita erittäin alhaisella hinnalla; helppokäyttöisyys.
VASTAAN: järjestelmänvalvojien toiminnan koordinointia ei ole olemassa.
ARVOSANA: 4/5.
HINTA: 1995 $ Rajoittamaton määrä laitteita (25 anturia ilmaiseksi).
SUOSITUKSET: Jos budjettisi on tiukka ja sinun on valvottava suurta määrää laitteita, jos valvontaprosessi ei vaadi monimutkaisia ​​ratkaisuja ja jos olet tyytyväinen järjestelmättömään lähestymistapaan järjestelmänvalvojan koordinoinnissa, SolarWinds on ratkaisu sinulle.
YHTEYSTIEDOT: solarwinds www.solarwinds.com

Ensimmäisen ipMonitori-esittelyni jälkeen kuvassa 3 näkyvä käyttöliittymä vaikutti minusta melko hämmentävältä. Kesti melkein ikuisuuden löytää paikka, jossa järjestelmän yksittäisten järjestelmän antureiden tarkistustiheys on määritetty (oletusarvoisesti kysely suoritettiin 300 sekunnin välein). Kuitenkin, kun ipMonitoria käytin muutaman viikon ajan, huomasin sen olevan erittäin helppokäyttöinen ja melko kykenevä suorittamaan laadukasta verkon valvontaa. ipMonitorin avulla voit määrittää "oletustarkistukset" niin, että kaikki palvelu- tai suorituskykyasetukset sisällytetään aina tuleviin tarkistuksiin. Tavallisten (ja edellä mainittujen) antureiden lisäksi ipMonitor tarjoaa Windowsin tapahtumalokianturin, jota voidaan käyttää lähettämään hälytyksiä, kun kriittisiä tapahtumia havaitaan.

Kuva 3: SolarWinds ipMonitor -liitäntä

Toisaalta ipMonitor-järjestelmässä ei ole mekanismeja hälytyskohteiden seuraamiseksi/määrittämiseksi. Sillä ei ole väliä, jos yrityksessä on vain yksi verkon ylläpitäjä, mutta suuret IT-osastot pitävät järjestelmän kyvyttömyyttä kuitata hälytysten vastaanottamista, määrittää vastaanottajia ja nollata hälytyksiä todennäköisesti merkittävänä haittapuolena. Jos järjestelmänvalvojat unohtavat koordinoida toimintansa järjestelmän ulkopuolella, voi olla tilanteita, joissa useat järjestelmänvalvojat saavat saman hälytyksen ja alkavat käsitellä samaa ongelmaa. Tällaisten ristiriitojen ratkaisemiseksi riittää kuitenkin, että kehitetään johdonmukainen algoritmi varoituksiin vastaamiseksi - jos esimerkiksi jaat vastuun verkkolaitteista järjestelmänvalvojien kesken, ei ole kysymyksiä siitä, kenen pitäisi käsitellä tiettyä ongelmaa.

Aika tehdä päätös

Olen jo päättänyt itse, kumpi kolmesta tuotteesta sopii paremmin ympäristööni. Päädyin ManageEngine OpManager -järjestelmään 50 laitteen lisenssillä useista syistä.

Ensinnäkin minun on pystyttävä pitämään kirjaa ympäristöni parametrien enimmäismäärästä, koska se on paras tapa välttää odottamattomia vikoja. Tässä asiassa OpManager-järjestelmä on varmasti kilpailijoita edellä. Toinen syy on budjetti. Voin edelleen käyttää vanhoja on/off-valvontatyökalujamme työasemille ja tulostimille ja vältän näin lisälisenssien kustannukset. Lopuksi pidin todella lähestymistavasta, jonka ManageEngine-tiimi omaksui OpManagerin kehittämisessä uusien teknologioiden hyödyntämiseksi, ja oikeutan täysin vuosittaisen palvelu- ja tukipaketin hankintakustannukset, jonka avulla voit ladata päivityksiä tuotteen kehittyessä.

Nate McAlmond ( [sähköposti suojattu]) on IT-johtaja sosiaalipalvelutoimistossa, MCSE-, Security- ja Network+-sertifioitu, erikoistunut ohuisiin asiakasratkaisuihin ja lääketieteellisiin tietokantoihin.

Alkuperäinen nimi: Yhteenveto verkkoliikenteen valvonta- ja analysointitekniikoista

Linkki alkuperäiseen tekstiin: http://www.cse.wustl.edu/~jain/cse567-06/ftp/net_monitoring/index.html

Suositukset: Toimitettu käännös ei ole ammattimainen. Poikkeamat tekstistä, tiettyjen termien ja käsitteiden virheellinen tulkinta, kääntäjän subjektiivinen mielipide ovat mahdollisia. Kaikki kuvat sisältyvät käännökseen ilman muutoksia.

Alisha Sessil

Yleiskatsaus verkkoliikenteen analysointi- ja seurantamenetelmiin

Yksityisten yritysten sisäisten verkkojen kasvaessa on erittäin tärkeää, että verkon ylläpitäjät ovat tietoisia ja pystyvät hallitsemaan manuaalisesti verkon kautta kulkevaa erityyppistä liikennettä. Liikenteen seuranta ja analysointi on olennaista, jotta ongelmat voidaan diagnosoida ja ratkaista niiden ilmetessä tehokkaammin ja estää näin verkkopalveluita joutumasta käyttämättömänä pitkiä aikoja. Saatavilla on monia erilaisia ​​työkaluja, joiden avulla järjestelmänvalvojat voivat valvoa ja analysoida verkkoliikennettä. Tässä artikkelissa käsitellään reititinsuuntautuneita valvontamenetelmiä ja ei-reititinsuuntautuneita valvontamenetelmiä (aktiivisia ja passiivisia menetelmiä). Artikkeli antaa yleiskatsauksen kolmesta käytettävissä olevasta ja yleisimmin käytetystä reitittimiin sisäänrakennetusta verkon valvontamenetelmästä (SNMP, RMON ja Cisco Netflow) ja tarjoaa tietoa kahdesta uudesta seurantamenetelmästä, jotka käyttävät yhdistelmää passiivisia ja aktiivisia valvontamenetelmiä (WREN ja SCNM). .

1. Verkon seurannan ja analyysin merkitys

Verkonvalvonta (verkkovalvonta) on monimutkainen ja vaativa tehtävä, joka on olennainen osa verkonvalvojan työtä. Järjestelmänvalvojat pyrkivät jatkuvasti pitämään verkkonsa sujuvana. Jos verkko kaatuu edes lyhyeksi ajaksi, yrityksen tuottavuus heikkenee ja (julkisten palveluorganisaatioiden tapauksessa) jo peruspalvelujen kykykin heikkenee. Tämän vuoksi järjestelmänvalvojien on valvottava verkon liikennevirtaa ja suorituskykyä koko verkossa ja tarkistettava tietoturvaloukkauksia.

2. Seuranta- ja analyysimenetelmät

"Verkkoanalyysi on prosessi, jossa kerätään verkkoliikennettä ja tarkastellaan sitä nopeasti, jotta voidaan määrittää, mitä verkolle on tapahtunut" - Angela Orebauh. Seuraavissa osissa käsitellään kahta tapaa valvoa verkkoa, joista toinen on reititinsuuntautunut ja toinen ei-reititinsuuntautunut. Reitittimiin itseensä sisäänrakennettua valvontatoimintoa, joka ei vaadi lisäohjelmiston tai laitteiston asennusta, kutsutaan reititinpohjaisiksi menetelmiksi. Muut kuin reitittimeen perustuvat menetelmät vaativat laitteiston ja ohjelmiston asennuksen ja tarjoavat enemmän joustavuutta. Molempia tekniikoita käsitellään alla niiden vastaavissa osissa.

2.1. Reititinpohjaiset valvontamenetelmät

Reitittimiin perustuvat valvontamenetelmät on kytketty reitittimiin ja siksi niillä on vähän joustavuutta. Alla on lyhyt kuvaus yleisimmin käytetyistä menetelmistä tällaisessa seurannassa. Jokainen menetelmä on kehittynyt useiden vuosien aikana ennen kuin siitä on tullut standardoitu seurantamenetelmä.

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

SNMP on sovelluskerroksen protokolla, joka on osa TCP/IP-protokollaa. Sen avulla järjestelmänvalvojat voivat hallita verkon suorituskykyä, etsiä ja korjata verkkoongelmia sekä suunnitella verkon kasvua. Se kerää tilastoja liikenteestä loppuisäntään passiivisten antureiden kautta, jotka toteutetaan yhdessä reitittimen kanssa. Vaikka versioita on kaksi (SNMPv1 ja SNMPv2), tässä osassa kuvataan vain SNMPv1. SNMPv2 perustuu SNMPv1:een ja tarjoaa useita parannuksia, kuten protokollatoimintojen lisäämisen. Toinen SNMP-versio on standardoitumassa. Versio 3 (SNMPv3) on tarkistettavana.

Protokollaa varten SNMP:ssä on kolme avainkomponenttia: hallitut laitteet ( Hallitut laitteet), agentit (Agentit ) ja verkonhallintajärjestelmät ( Verkonhallintajärjestelmät - NMS:t). Ne on esitetty kuvassa. 1.

Riisi. 1. SNMP-komponentit

Hallittuihin laitteisiin kuuluu SNMP-agentti, ja ne voivat koostua reitittimistä, kytkimistä, kytkimistä, keskittimistä, henkilökohtaisista tietokoneista, tulostimista ja muista vastaavista kohteista. He ovat vastuussa tietojen keräämisestä ja asettamisesta verkonhallintajärjestelmän (NMS) saataville.

Agentit sisältävät ohjelmistoja, jotka omistavat hallintatiedot ja kääntävät nämä tiedot SNMP-yhteensopivaan muotoon. Ne on suljettu ohjauslaitteesta.

Verkonhallintajärjestelmät (NMS) käyttävät sovelluksia, jotka valvovat ja ohjaavat hallintalaitteita. NMS tarjoaa verkon hallintaan tarvittavat prosessori- ja muistiresurssit. Jokaista hallittua verkkoa varten on luotava vähintään yksi hallintajärjestelmä. SNMP voi toimia yksinomaan NMS:nä tai agenttina tai suorittaa omia tehtäviään jne.

SNMP NMS käyttää neljää pääkomentoa hallittujen laitteiden valvontaan ja ohjaukseen: luku-, kirjoitus-, keskeytys- ja läpikulkutoimintoja. Lukutoiminto ottaa huomioon muuttujat, jotka hallitut laitteet ovat tallentaneet. Kirjoituskomento muuttaa hallittujen laitteiden tallentamien muuttujien arvoja. Läpikulkutoiminnot ovat tietoisia siitä, mitä hallittuja laitemuuttujia ne tukevat, ja keräävät tietoa tuetuista muuttujataulukoista. Hallitut laitteet käyttävät keskeytystoimintoa ilmoittamaan NMS:lle, että tiettyjä tapahtumia on tapahtunut.

SNMP käyttää neljää protokollatoimintoa järjestyksessä: Get, GetNext, Set ja Trap. Get-komentoa käytetään, kun NMS lähettää tietopyynnön hallituille laitteille. SNMPv1-pyyntö koostuu viestin otsikosta ja protokollatietoyksiköstä (PDU). Sanoma PDU sisältää tiedot, jotka ovat tarpeen pyynnön onnistuneelle suorittamiselle, joka joko vastaanottaa tiedot agentilta tai asettaa arvon agenttiin. Hallittu laite käyttää siinä olevia SNMP-agentteja hankkiakseen tarvittavat tiedot ja lähettää sitten NMS:lle "y"-sanoman vastauksella pyyntöön. Jos agentilla ei ole pyyntöön liittyviä tietoja, se ei palauta mitään. GetNext-komento vastaanottaa seuraavan objektiinstanssin arvon.NMS voi myös lähettää pyynnön (Set-toiminto), kun elementtien arvo ilman agentteja on asetettu.Kun agentin on raportoitava NMS-tapahtumista, se käyttää Trap toiminta.

Kuten aiemmin mainittiin, SNMP on sovelluskerroksen protokolla, joka käyttää passiivisia antureita auttamaan järjestelmänvalvojaa valvomaan verkkoliikennettä ja verkon suorituskykyä. Vaikka SNMP voi olla hyödyllinen työkalu verkonvalvojalle, se tarjoaa mahdollisuuden turvallisuusriskeihin, koska sillä ei ole todennuskykyä. Se eroaa seuraavassa osiossa käsitellystä etävalvonnasta (RMON) siinä, että RMON toimii verkkokerroksessa ja sen alapuolella sovelluskerroksen sijaan.

2.1.2. Etävalvonta (RMON), RFS 1757

RMON sisältää erilaisia ​​verkkomonitoreja ja konsolijärjestelmiä verkonvalvontatietojen muokkaamiseen. Tämä on SNMP-hallintatietokannan (MIB) laajennus. Toisin kuin SNMP, jonka on lähetettävä tietopyyntöjä, RMON voi asettaa hälytyksiä, jotka "seuraavat" verkkoa tiettyjen kriteerien perusteella. RMON antaa järjestelmänvalvojille mahdollisuuden hallita paikallisia verkkoja sekä etäverkkoja yhdestä tietystä sijainnista/pisteestä. Sen verkkokerroksen näytöt näkyvät alla. RMON:lla on kaksi versiota RMON ja RMON2. Tässä artikkelissa puhutaan kuitenkin vain RMONista. RMON2 mahdollistaa seurannan kaikilla verkon kerroksilla. Se keskittyy IP-liikenteeseen ja sovellustason liikenteeseen.

Vaikka RMON-valvontaympäristössä on 3 avainkomponenttia, vain kaksi niistä on lueteltu tässä. Ne on esitetty kuvassa. 2 alla.

Riisi. 2. RMON-komponentit

RMON:n kaksi komponenttia ovat anturi, joka tunnetaan myös nimellä agentti tai monitori, ja asiakas, joka tunnetaan myös ohjausasemana (hallintaasemana). Toisin kuin SNMP, anturi tai RMON-agentti kerää ja tallentaa verkkotietoja. Anturi on verkkolaitteeseen (kuten reitittimeen tai kytkimeen) sisäänrakennettu ohjelmisto. Anturi voi toimia myös henkilökohtaisella tietokoneella. Jokaiselle eri LAN- tai WAN-segmentille on sijoitettava anturi, koska he näkevät vain linkkien kautta kulkevan liikenteen, mutta he eivät ole tietoisia niiden ulkopuolella olevasta liikenteestä. Asiakas on yleensä hallinta-asema, joka on kytketty anturiin, joka käyttää SNMP:tä RMON-tietojen vastaanottamiseen ja korjaamiseen.

RMON käyttää 9 eri valvontaryhmää verkkotietojen hankkimiseen.

• Tilastot - anturin mittaama tilasto jokaiselle tämän laitteen valvontaliittymälle.
• Historia - jaksoittaisten tilastonäytteiden kirjaaminen verkosta ja tallentaminen hakua varten.
• Hälytys – ottaa ajoittain tilastollisia näytteitä ja vertaa niitä tiettyihin kynnysarvoihin tapahtuman luomiseksi.
• Isäntä - sisältää tilastot, jotka liittyvät jokaiseen verkosta löytyvään isäntään.
• HostTopN - valmistelee taulukoita, jotka kuvaavat isäntien huippua (pääisäntä).
• Suodattimet – Mahdollistaa pakettisuodatuksen tapahtumien sieppaussuodatinyhtälön perusteella.
• Pakettien sieppaus - pakettien sieppaus sen jälkeen, kun ne ovat kulkeneet kanavan läpi.
• Tapahtumat - tapahtumien generoinnin ja rekisteröinnin ohjaus laitteesta.
• Token ring - tuki ring tokeneille.

Kuten yllä mainittiin, RMON perustuu SNMP-protokollaan. Vaikka liikenteen seuranta voidaan suorittaa tällä menetelmällä, SNMP:n ja RMON:n saamien tietojen analysointidata on huono. Netflow-apuohjelma, jota käsitellään seuraavassa osiossa, toimii menestyksekkäästi useiden analytiikkaohjelmistopakettien kanssa helpottaen järjestelmänvalvojan työtä huomattavasti.

2.1.3. Netflow, RFS 3954

Netflow on Ciscon reitittimissä käyttöön otettu laajennus, joka tarjoaa mahdollisuuden kerätä IP-verkkoliikennettä, jos se on määritetty rajapinnassa. Analysoimalla Netflow:n tarjoamia tietoja verkonvalvoja voi määrittää esimerkiksi liikenteen lähteen ja määränpään, palveluluokan ja ruuhkautumisen syyt. Netflow sisältää 3 komponenttia: FlowCaching (välimuistivirta), FlowCollector (virtatietojen kerääjä) ja Data Analyzer (datan analysaattori). Riisi. 3 näyttää Netflow-infrastruktuurin. Jokainen kuvassa näkyvä komponentti on selitetty alla.

Riisi. 3. NetFlow-infrastruktuuri

FlowCaching analysoi ja kerää tietoja IP-virroista, jotka tulevat käyttöliittymään ja muuntaa tiedot vientiä varten.

Netflow-paketeista voidaan saada seuraavat tiedot:

• Lähteen ja määränpään osoite.
• Saapuvan ja lähtevän laitteen numero.
• Lähteen ja kohteen portin numero.
• Tason 4 protokolla.
• Virran pakettien määrä.
• Virran tavujen määrä.
• Aikaleima streamissa.
• Lähteen ja kohteen autonomisen järjestelmän (AS) numero.
• Palvelutyyppi (ToS) ja TCP-lippu.

Standardin kytkentäpolun läpi kulkevan virran ensimmäinen paketti käsitellään välimuistin luomiseksi. Paketteja, joilla on samanlaiset vuoominaisuudet, käytetään luomaan vuomerkintä, joka tallennetaan välimuistiin kaikille aktiivisille virroille. Tämä merkintä merkitsee kunkin virran pakettien ja tavujen lukumäärän. Välimuistissa olevat tiedot viedään sitten säännöllisesti Flow Collectoriin.

Flow Collector - vastaa tietojen keräämisestä, suodattamisesta ja tallentamisesta. Se sisältää historian tietovirroista, jotka on yhdistetty käyttöliittymän avulla. Tietojen vähentäminen tapahtuu myös Flow Collectorin avulla ja valittujen suodattimien ja aggregoinnin avulla.

Data Analyzer (data-analysaattori) tarvitaan, kun haluat esittää tietoja. Kuten kuvasta näkyy, kerättyä tietoa voidaan käyttää erilaisiin tarkoituksiin, myös muihin tarkoituksiin kuin verkon seurantaan, kuten suunnitteluun, kirjanpitoon ja verkon rakentamiseen.

Netflow:n etuna muihin valvontamenetelmiin, kuten SNMP:hen ja RMON:iin, verrattuna on, että siinä on ohjelmistopaketteja, jotka on suunniteltu erilaisiin liikenneanalyyseihin, jotka ovat olemassa datan vastaanottamiseksi Netflow-paketteista ja niiden esittämisestä käyttäjäystävällisemmällä tavalla.

Kun käytät työkaluja, kuten Netflow Analyzer (tämä on ainoa työkalu, joka on käytettävissä Netflow-pakettien analysointiin), yllä olevat tiedot voidaan saada Netflow-paketteista luodaksesi kaavioita ja tavallisia kaavioita, joita järjestelmänvalvoja voi tutkia ymmärtääkseen paremmin verkkojaan. Netflow:n käytön suurin etu verrattuna saatavilla oleviin analyyttisiin pakkauksiin on se, että tässä tapauksessa voidaan rakentaa useita kaavioita, jotka kuvaavat verkon toimintaa kulloinkin.

2.2. Tekniikat, jotka eivät perustu reitittimiin

Vaikka tekniikat, joita ei ole rakennettu reitittimeen, ovat edelleen rajallisia, ne tarjoavat enemmän joustavuutta kuin reitittimiin sisäänrakennetut. Nämä menetelmät luokitellaan aktiivisiin ja passiivisiin.

2.2.1. Aktiivinen seuranta

Aktiivinen valvonta raportoi verkkoongelmista keräämällä mittauksia kahden päätepisteen välillä. Aktiivinen mittausjärjestelmä käsittelee mittareita, kuten: apuohjelma, reitittimet/reitit, pakettien viive, pakettien toisto, pakettien katoaminen, värinä saapuvien välillä, suorituskyvyn mittaus.

Pääasiassa työkalujen käyttö, kuten ping-komento, joka mittaa viivettä ja pakettihäviöitä, ja traceroute, joka auttaa määrittämään verkon topologian, ovat esimerkkejä tärkeimmistä aktiivisista mittaustyökaluista. Molemmat työkalut lähettävät ICMP-koetinpaketteja määränpäähän ja odottavat, että kohde vastaa lähettäjälle. Riisi. Kuva 4 on esimerkki ping-komennosta, joka käyttää aktiivista mittausmenetelmää lähettämällä Echo-pyynnön lähteestä verkon kautta määritettyyn pisteeseen. Vastaanotin lähettää sitten Echo Request -pyynnön takaisin lähteeseen, josta pyyntö tuli.

Riisi. 4. Ping-komento (aktiivinen mittaus)

Tämä menetelmä ei voi vain kerätä yksittäisiä mittareita aktiivisesta mittauksesta, vaan se voi myös määrittää verkon topologian. Toinen tärkeä esimerkki aktiivisesta mittauksesta on iperf-apuohjelma. Iperf on apuohjelma, joka mittaa TCP- ja UDP-protokollien suoritustehon laatua. Se raportoi kaistanleveyden, olemassa olevan viiveen ja pakettihäviön.

Aktiivisen valvonnan ongelmana on, että verkossa esitetyt anturit voivat häiritä normaalia liikennettä. Usein aktiivisia luotainaikoja käsitellään eri tavalla kuin normaalissa liikenteessä, mikä kyseenalaistaa näistä luotain antamien tietojen arvon.

Yllä kuvattujen yleisten tietojen mukaan aktiivinen seuranta on erillään tarkasteltuna erittäin harvinainen seurantamenetelmä. Passiivinen valvonta sen sijaan ei vaadi suuria verkkokustannuksia.

2.2.2. Passiivinen seuranta

Passiivinen valvonta, toisin kuin aktiivinen valvonta, ei lisää liikennettä verkkoon eikä muuta verkossa jo olevaa liikennettä. Lisäksi, toisin kuin aktiivinen valvonta, passiivinen valvonta kerää tietoa vain yhdestä verkon pisteestä. Mittaukset ovat paljon parempia kuin kahden pisteen välillä aktiivisella seurannalla. Riisi. Kuvassa 5 on passiivinen valvontajärjestelmä, jossa monitori sijoitetaan yhdelle linkille kahden päätepisteen välillä ja tarkkailee liikennettä sen kulkiessa linkin yli.

Riisi. 5. Passiivisen valvonnan asennus

Passiiviset mittaukset käsittelevät tietoja, kuten: liikenne ja protokollayhdistelmä, bittien määrä (bittinopeus), pakettien ajoitus ja saapumisten välinen aika. Passiivinen valvonta voidaan tehdä millä tahansa ohjelmalla, joka vetää paketteja.

Vaikka passiivisella seurannalla ei ole niitä kustannuksia kuin aktiivisella seurannalla, sillä on haittoja. Passiivisessa seurannassa mittauksia voidaan analysoida vain offline-tilassa, eivätkä ne edusta kokoelmaa. Tämä aiheuttaa ongelmia mittauksen aikana kerättyjen suurten tietojoukkojen käsittelyssä.

Passiivinen valvonta voi olla parempi kuin aktiivinen valvonta siinä mielessä, että signalointidataa ei lisätä verkkoon, mutta jälkikäsittely voi olla hyvin aikaa vievää. Tästä syystä on olemassa näiden kahden seurantamenetelmän yhdistelmä.

2.2.3. Yhdistetty seuranta

Yllä olevien osioiden lukemisen jälkeen voidaan turvallisesti päätellä, että aktiivisen ja passiivisen seurannan yhdistelmä on parempi tapa kuin käyttää ensin mainittua tai jälkimmäistä yksinään. Yhdistetyt tekniikat hyödyntävät sekä passiivisen että aktiivisen ympäristöjen valvonnan parhaita ominaisuuksia. Alla kuvataan kaksi uutta teknologiaa, jotka edustavat yhdistettyjä valvontatekniikoita. Nämä ovat End-of-Network Resource Viewer (WREN) ja Self-Configuring Network Monitor (SCNM).

2.2.3.1. Päästä päähän -resurssinäkymä (WREN)

WREN käyttää aktiivisen ja passiivisen valvontatekniikan yhdistelmää, prosessoimalla tietoja aktiivisesti, kun liikennettä on vähän, ja käsittelemällä tietoja passiivisesti suuren liikenteen aikoina. Se tarkastelee liikennettä sekä lähteestä että kohteesta, mikä mahdollistaa tarkemmat mittaukset. WREN käyttää pakettien seurantaa sovelluksen luomasta liikenteestä hyödyllisen suorituskyvyn mittaamiseen. WREN on jaettu kahteen kerrokseen: nopeaan paketinkäsittelykerrokseen ja käyttäjätason jäljitysanalysaattoriin.

Ydin nopea paketinkäsittelykerros on vastuussa saapuviin ja lähteviin paketeihin liittyvien tietojen hankkimisesta. Riisi. 6 esittää luettelon tiedoista, jotka kerätään jokaisesta paketista. Web100:een lisätään puskuri näiden ominaisuuksien keräämiseksi. Puskuriin päästään kahdella järjestelmäkutsulla. Yksi puhelu käynnistää jäljityksen ja antaa tarvittavat tiedot sen keräämiseen, kun taas toinen kutsu palauttaa jäljen ytimestä.

Riisi. 6. Pakettijälkien päätasolla kerätyt tiedot

Paketin jäljitysobjekti- osaa koordinoida laskelmia eri koneiden välillä. Yksi kone herättää toisen koneen asettamalla lipun lähtevän paketin otsikkoon, jotta se alkaa käsitellä joitakin sen jäljittämiä paketteja. Toinen kone puolestaan ​​jäljittää kaikki paketit, joiden otsikossa se näkee samanlaisen lipun. Tämä koordinointi varmistaa, että tiedot samanlaisista paketeista tallennetaan kuhunkin päätepisteeseen riippumatta tiedonsiirrosta ja siitä, mitä niiden välillä tapahtuu.

Käyttäjätason jäljitysanalysaattori on toinen kerros WREN-ympäristössä. Tämä on komponentti, joka aloittaa minkä tahansa paketin jäljittämisen, kerää ja käsittelee palautetut tiedot operaattorin ydintasolla. Suunnittelun mukaan käyttäjätason komponenttien ei tarvitse lukea tietoja pakettijäljitysobjektista koko ajan. Niitä voidaan analysoida välittömästi jäljityksen valmistuttua reaaliaikaisen johtopäätöksen tekemiseksi tai tiedot voidaan tallentaa jatkoanalyysiä varten.

Kun liikennettä on vähän, WREN lisää liikennettä aktiivisesti verkkoon säilyttäen samalla mittausvirtojen järjestyksen. Lukuisten tutkimusten jälkeen on havaittu, että WREN tarjoaa samanlaisia ​​​​mittauksia ylikyllästetyissä ja ei-ylikyllästetyissä ympäristöissä.

Nykyisessä WREN-toteutuksessa käyttäjiä ei pakoteta tallentamaan vain heidän aloittamiaan jälkiä. Vaikka kuka tahansa käyttäjä voi valvoa muiden käyttäjien sovellusliikennettä, heillä on rajoitettu tieto, joka voidaan saada muiden käyttäjien jäljistä. He voivat saada vain numeroiden sekvenssin ja kuittauksen, mutta eivät voi saada todellisia datasegmenttejä paketeista.

Kaiken kaikkiaan WREN on erittäin hyödyllinen asetus, joka hyödyntää sekä aktiivista että passiivista valvontaa. Vaikka tämä tekniikka on kehitysvaiheessa, WREN voi tarjota järjestelmänvalvojille hyödyllisiä resursseja verkkojensa seurantaan ja analysointiin. Native Network Configuration Monitor (SCNM) on toinen työkalu, joka käyttää sekä aktiivista että passiivista valvontatekniikkaa.

2.2.3.2. Network Monitor with Self Configuration (SCNM)

SCNM on seurantatyökalu, joka käyttää passiivisten ja aktiivisten mittausten yhdistelmää tiedon keräämiseen penetraatiokerroksesta 3, lähtevistä reitittimistä ja muista tärkeistä verkon valvontapisteistä. SCNM-ympäristö sisältää sekä laitteisto- että ohjelmistokomponentin.

Laitteisto asennetaan verkon kriittisiin kohtiin. Se on vastuussa pakettien otsikoiden passiivisesta keräämisestä. Ohjelmisto toimii verkon päätepisteessä. Riisi. Alla oleva kuva 7 näyttää SCNM-ympäristön ohjelmistokomponentin.

Riisi. 7. SCNM-ohjelmistokomponentti

Ohjelmisto vastaa aktivoitujen pakettien luomisesta ja lähettämisestä, joita käytetään verkon valvonnan käynnistämiseen. Käyttäjät lähettävät verkkoon aktivointipaketteja, jotka sisältävät tiedot paketeista, joita he haluavat vastaanottaa seurantaa ja keräilyä varten. Käyttäjien ei tarvitse tietää SCNM-isännän sijaintia olettaen, että kaikki isännät ovat avoinna kuuntelemaan paketteja. Aktivointipaketissa olevien tietojen perusteella suodatin sijoitetaan tiedonkeruuvirtaan, joka toimii myös päätepisteessä.. Suodatinta vastaavat verkko- ja siirtokerroksen pakettiotsikot kerätään. Suodatin aikakatkaisee automaattisesti täsmälleen määritetyn ajan kuluttua, jos se vastaanottaa muita sovelluspaketteja. SCNM-isännällä toimiva pakettinäytteenottopalvelu käyttää tcpdump-komentoa (samanlainen kuin pakettinäyteohjelma) vastaanotettujen pyyntöjen järjestyksessä ja tallentaa pyyntöä vastaavan liikenteen.

Kun ongelma tunnistetaan passiivisilla valvontatyökaluilla, voidaan aktiivisten valvontatyökalujen avulla generoida liikennettä, jolloin voidaan kerätä lisättyä dataa ongelman tutkimiseksi tarkemmin. Ottamalla tämän monitorin käyttöön verkossa jokaisessa reitittimessä matkan varrella voimme tutkia vain niitä verkon osia, joissa on ongelmia.

SCNM on tarkoitettu ensisijaisesti järjestelmänvalvojien asennettavaksi ja käytettäväksi. Tavalliset käyttäjät voivat kuitenkin käyttää joitain näistä toiminnoista. Tavalliset käyttäjät voivat käyttää osia SCNM-valvontaympäristöstä, mutta he voivat tarkastella vain omia tietojaan.

Yhteenvetona voidaan todeta, että SCNM on toinen tapa yhdistää valvontaan, joka käyttää sekä aktiivisia että passiivisia menetelmiä auttaakseen järjestelmänvalvojia valvomaan ja analysoimaan verkkojaan.

3. Johtopäätös

Valitessaan yksityisiä työkaluja verkonvalvontaan, pääkäyttäjän on ensin päätettävä, haluaako hän käyttää vakiintuneita, vuosia käytössä olleita järjestelmiä vai uusia. Jos olemassa olevat järjestelmät ovat parempi ratkaisu, NetFlow on hyödyllisin työkalu käytettäväksi, sillä jäsennettyjä datapaketteja voidaan käyttää yhdessä tämän apuohjelman kanssa tietojen esittämiseksi käyttäjäystävällisemmällä tavalla. Jos järjestelmänvalvoja on kuitenkin halukas kokeilemaan uutta järjestelmää, yhdistetyt valvontaratkaisut, kuten WREN tai SCNM, ovat paras tapa edetä.

Verkon valvonta ja analysointi ovat tärkeitä järjestelmänvalvojan työlle. Järjestelmänvalvojien tulee pyrkiä pitämään verkkonsa kunnossa sekä hajallaan toimivan yrityksen sisällä että kommunikoinnissa olemassa olevien julkisten palvelujen kanssa. Yllä olevien tietojen mukaan saatavilla on useita reitittimiin perustuvia ja ei-reititinpohjaisia ​​teknologioita, joiden avulla verkonvalvojat voivat valvoa ja analysoida verkkojaan päivittäin. SNMP, RMON ja Ciscon NetFlow on kuvattu lyhyesti tässä - esimerkki useista reititinpohjaisista teknologioista.Esimerkkejä artikkelissa käsitellyistä ei-reititinpohjaisista teknologioista ovat aktiivinen, passiivinen valvonta ja molempien yhdistelmä.

Johdanto

Tietotekniikka on viime vuosina kokenut merkittäviä ja jatkuvia muutoksia. Joidenkin arvioiden mukaan viimeisten viiden vuoden aikana verkkoliikenteen määrä paikallisissa verkoissa on kymmenkertaistunut. Siten paikallisten verkkojen on tarjottava jatkuvasti kasvava kaistanleveys ja vaadittu palvelun laatutaso. Riippumatta siitä, mitä resursseja verkossa on, ne ovat silti rajalliset, joten verkko tarvitsee kyvyn hallita liikennettä.

Ja ollaksesi mahdollisimman tehokas, sinun on pystyttävä hallitsemaan verkkosi laitteiden välillä kulkevia paketteja. Lisäksi ylläpitäjällä on paljon pakollisia päivittäisiä toimintoja. Tämä sisältää esimerkiksi sähköpostin toimivuuden tarkistamisen, lokitiedostojen tarkastelemisen ongelmien varhaisten merkkien varalta, lähiverkkoyhteyksien seurantaa ja järjestelmäresurssien saatavuuden valvontaa. Ja tässä tietokoneverkkojen valvontaan ja analysointiin käytetyt työkalut voivat tulla apuun.

Jotta ei hämmentyisi monissa seurantaan luoduissa menetelmissä, työkaluissa ja tuotteissa, aloitetaan lyhyellä kuvauksella useista suurista näiden tuotteiden luokista.

Verkonhallintajärjestelmät. Nämä ovat keskitettyjä ohjelmistojärjestelmiä, jotka keräävät tietoa verkon solmujen ja viestintälaitteiden tilasta sekä verkossa kiertävästä liikenteestä. Nämä järjestelmät eivät vain valvo ja analysoi verkkoa, vaan myös suorittavat verkonhallintatoimia automaattisessa tai puoliautomaattisessa tilassa - laiteporttien käyttöönotto ja poistaminen käytöstä, siltojen, kytkimien ja reitittimien osoitetaulukoiden siltaparametrien muuttaminen jne. Esimerkkejä ohjausjärjestelmistä ovat suositut järjestelmät HPOpenView, SunNetManager, IBMNetView.

Järjestelmänhallintatyökalut. Järjestelmäohjaukset suorittavat usein samanlaisia ​​toimintoja kuin ohjausjärjestelmät, mutta suhteessa muihin objekteihin. Ensimmäisessä tapauksessa ohjausobjektina ovat verkkotietokoneiden ohjelmistot ja laitteistot ja toisessa tapauksessa tietoliikennelaitteet. Jotkut näiden kahden hallintajärjestelmän toiminnot voivat kuitenkin olla päällekkäisiä, esimerkiksi järjestelmänhallintatyökalut voivat suorittaa yksinkertaisen verkkoliikenteen analyysin.

Sulautetut diagnostiikka- ja ohjausjärjestelmät (sulautetut järjestelmät). Nämä järjestelmät toteutetaan tietoliikennelaitteisiin asennettuina ohjelmisto- ja laitteistomoduuleina sekä käyttöjärjestelmiin sisäänrakennetuina ohjelmistomoduuleina. Ne suorittavat vain yhden laitteen diagnostiikka- ja ohjaustoiminnot, ja tämä on niiden tärkein ero keskitetyistä ohjausjärjestelmistä. Esimerkki tästä työkaluryhmästä on Distrebuted 5000 -keskittimen ohjausmoduuli, joka toteuttaa porttien automaattisen segmentoinnin toiminnot, kun vikoja havaitaan, porttien osoittamista keskittimen sisäisille segmenteille ja joitain muita. Sisäänrakennetut osa-aikaiset hallintamoduulit toimivat yleensä SNMP-agentteina, jotka toimittavat laitteen tilatietoja hallintajärjestelmille.

Protokolla-analysaattorit. Ne ovat ohjelmistoja tai laitteisto-ohjelmistojärjestelmiä, joita, toisin kuin ohjausjärjestelmiä, rajoittavat vain verkkoliikenteen valvonta- ja analysointitoiminnot. Hyvä protokolla-analysaattori voi siepata ja purkaa paketteja useista verkoissa käytetyistä protokollista - yleensä useista kymmenistä. Protokollaanalysaattoreiden avulla voit asettaa joitain loogisia ehtoja yksittäisten pakettien sieppaamiseen ja suorittaa kaapattujen pakettien täydellisen dekoodauksen, eli ne näyttävät asiantuntijalle sopivassa muodossa eritasoisten protokollapakettien sisäkkäisyyden toistensa kanssa sisällön dekoodaamisen kanssa. kunkin paketin yksittäisistä kentistä.

Asiantuntijajärjestelmät. Tämän tyyppiset järjestelmät keräävät ihmisten tietoa verkkojen poikkeavan toiminnan syiden tunnistamisesta ja mahdollisista tavoista saada verkko terveeseen tilaan. Asiantuntijajärjestelmät toteutetaan usein erillisinä alijärjestelminä erilaisista verkon valvonta- ja analysointityökaluista: verkonhallintajärjestelmät, protokolla-analysaattorit, verkkoanalysaattorit. Asiantuntijajärjestelmän yksinkertaisin versio on tilannekohtainen ohjejärjestelmä. Monimutkaisemmat asiantuntijajärjestelmät ovat niin sanottuja tietokantoja, joissa on tekoälyn elementtejä. Esimerkki tällaisesta järjestelmästä on Cabletronin Spectrum-ohjausjärjestelmään sisäänrakennettu asiantuntijajärjestelmä.

Monitoimilaitteet analysointiin ja diagnostiikkaan. Viime vuosina paikallisten verkkojen yleisyyden vuoksi on tullut tarpeelliseksi kehittää edullisia kannettavia laitteita, joissa yhdistyvät useiden laitteiden toiminnot: protokolla-analysaattorit, kaapeliskannerit ja jopa eräät verkonhallintaohjelmiston ominaisuudet. Esimerkki tällaisesta laitteesta on Microtest, Inc:n Compas. tai 675 LANMeter FlukeCorp.

Ohjausjärjestelmät

Viime aikoina valvontajärjestelmien alalla on havaittu kaksi melko selkeää suuntausta:

1. Verkkojen ja järjestelmien hallinnan toimintojen integrointi yhteen tuotteeseen. (Tämän lähestymistavan kiistaton etu on yksi järjestelmän ohjauspiste. Haittapuolena on, että kun verkko on raskaasti kuormitettu, palvelin, johon on asennettu valvontaohjelma, ei välttämättä pysty käsittelemään kaikkia paketteja ja tuotteesta riippuen joko jättää huomioimatta. osa paketeista tai niistä tulee järjestelmän "kapea" paikka.).
2. ohjausjärjestelmän jakelu, jossa järjestelmässä on useita konsoleita, jotka keräävät tietoa laitteiden ja järjestelmien tilasta ja antavat ohjaustoimenpiteitä. (Tässä on päinvastoin: valvontatehtävät on hajautettu useille laitteille, mutta samojen toimintojen päällekkäisyys ja epäjohdonmukaisuus eri konsolien ohjainten välillä ovat mahdollisia.)

Usein ohjausjärjestelmät eivät suorita vain verkon toiminnan valvonta- ja analysointitoimintoja, vaan sisältävät myös verkkoon aktiivisesti vaikuttavia toimintoja - konfiguroinnin ja turvallisuuden hallinnan (katso sivupalkki).

SNMP Network Management Protocol

Useimmat verkkoja rakentavat ja hallitsevat ihmiset pitävät standardien käsitteestä. Tämä on ymmärrettävää, sillä standardien avulla he voivat valita verkkotoimittajan esimerkiksi palvelutason, hinnan ja tuotteen suorituskyvyn perusteella sen sijaan, että ne olisivat "ketjutettu" yhden valmistajan omaan ratkaisuun. Tämän päivän suurin verkko - Internet - perustuu standardeihin. Internet Engineering Task Force (IETF) perustettiin koordinoimaan tämän ja muiden TCP/IP-protokollia käyttävien verkkojen kehitystyötä.

Yleisin verkonhallintaprotokolla on SNMP (SimpleNetworkManagementProtocol), jota sadat toimittajat tukevat. SNMP-protokollan tärkeimmät edut ovat yksinkertaisuus, saatavuus, riippumattomuus valmistajista. SNMP-protokolla on suunniteltu hallitsemaan Internetin reitittimiä, ja se on osa TCP/IP-pinoa.

Mikä on MIB - Man In Black?

Jos puhumme yritysverkon seurantatyökaluista, tämä lyhenne piilottaa termin Management Information Base. Mihin tämä tietokanta on tarkoitettu?

SNMP on protokolla, jota käytetään tiedon hankkimiseen verkkolaitteilta niiden tilasta, suorituskyvystä ja ominaisuuksista ja joka tallennetaan erityiseen verkkolaitetietokantaan nimeltä MIB. On olemassa standardeja, jotka määrittelevät MIB:n rakenteen, mukaan lukien sen muuttujien tyyppiset joukot (objektit ISO-terminologiassa), niiden nimet ja näiden muuttujien sallitut toiminnot (esimerkiksi lukeminen). Muiden tietojen ohella MIB voi tallentaa laitteiden verkko- ja/tai MAC-osoitteet, käsiteltyjen pakettien ja virheiden laskurien arvot, numerot, prioriteetit ja tiedot porttien tilasta. MIB-puurakenne sisältää pakolliset (standardi) alipuut; Lisäksi se voi sisältää yksityisiä alipuita, joiden avulla älylaitteiden valmistaja voi toteuttaa mitä tahansa tiettyjä toimintoja tiettyjen muuttujiensa perusteella.

SNMP-protokollan agentti on prosessointielementti, joka tarjoaa verkonhallinta-asemilla sijaitseville johtajille pääsyn MIB-muuttujien arvoihin ja mahdollistaa siten laitehallinta- ja valvontatoimintojen toteuttamisen.

Hyödyllinen lisäys SNMP-toimintoon on RMON-spesifikaatio, joka tarjoaa etäyhteyden MIB:n kanssa. Ennen RMON:a SNMP:tä ei voitu käyttää etänä, se salli vain paikallisen laitehallinnan. RMON toimii kuitenkin parhaiten jaetuissa verkoissa, joissa se voi hallita kaikkea liikennettä. Mutta jos verkossa on kytkin, joka suodattaa liikenteen niin, että se on näkymätön portille, ellei se ole tarkoitettu kyseiseen porttiin liittyvälle laitteelle tai se ei ole peräisin kyseiseltä laitteelta, tämä vaikuttaa koetintietoihisi.

Tämän välttämiseksi valmistajat ovat toimittaneet RMON-toimintoja jokaiseen kytkinporttiin. Tämä on skaalautuvampi järjestelmä kuin järjestelmä, joka jatkuvasti pollaa kaikkia kytkimen portteja.

Protokolla-analysaattorit

Uutta verkkoa suunniteltaessa tai vanhaa verkkoa päivitettäessä tulee usein tarpeelliseksi kvantifioida tietyt verkon ominaisuudet, kuten esimerkiksi tietovirtojen intensiteetti verkon tietoliikennelinjoilla, pakettien käsittelyn eri vaiheissa esiintyvät viiveet, vaste. aika jonkinlaisiin pyyntöihin, tapahtumien esiintymistiheys jne.

Tässä vaikeassa tilanteessa voit käyttää erilaisia ​​työkaluja ja ennen kaikkea valvontatyökaluja verkonhallintajärjestelmissä, joita on jo käsitelty artikkelin aiemmissa osissa. Jotkut verkon mittaukset voidaan suorittaa myös käyttöjärjestelmään sisäänrakennetuilla ohjelmistomittareilla, esimerkkinä tästä on Windows NTPerformanceMonitor OS -komponentti. Tämä apuohjelma on kehitetty tallentamaan tietokoneen toimintaa reaaliajassa. Sen avulla voit tunnistaa useimmat suorituskykyä heikentävät "pullonkaulat".

PerformanceMonitor perustuu sarjaan laskureita, jotka tallentavat sellaiset ominaisuudet kuin levytoiminnon valmistumista odottavien prosessien lukumäärä, aikayksikköä kohti lähetettyjen verkkopakettien määrä, prosessorin käyttöprosentti jne.

Mutta edistynein verkkotutkimustyökalu on protokolla-analysaattori. Protokollaanalyysiprosessi sisältää tietyn verkkoprotokollan toteuttavien verkossa kiertävien pakettien sieppauksen ja näiden pakettien sisällön tutkimisen. Analyysin tulosten perusteella on mahdollista tehdä järkeviä ja tasapainoisia muutoksia mihin tahansa verkkokomponenttiin, optimoida sen suorituskykyä ja etsiä ongelmia. On selvää, että jotta voidaan tehdä johtopäätöksiä muutoksen vaikutuksista verkkoon, on selvää, että protokollat ​​on analysoitava ennen muutoksen tekemistä ja sen jälkeen.

Yleensä protokolla-analyysiprosessi kestää melko pitkän ajan (jopa useita työpäiviä) ja sisältää seuraavat vaiheet:

1. Tiedon keräys.
2. Tarkastele tallennettuja tietoja.
3. Tietojen analysointi.
4. Etsi virheitä.
5. Suorituskykytutkimus. Verkon kaistanleveyden käytön tai pyyntöön keskimääräisen vasteajan laskeminen.
6. Yksityiskohtainen tutkimus verkon yksittäisistä osista. Työn sisältö tässä vaiheessa riippuu verkon analyysin tuloksista.

Tähän voimme lopettaa niiden teoreettisten kohtien tarkastelun, jotka on otettava huomioon rakennettaessa verkkosi valvontajärjestelmää, ja siirtyä tarkastelemaan ohjelmistotuotteita, jotka on luotu analysoimaan yritysverkon toimintaa ja ohjaamaan sitä.

Tuotteet seurantaan ja analysointiin

Vertaileva yleiskatsaus HPOpenView- ja CabletronSpectrum-ohjausjärjestelmistä

Jokainen tässä osiossa käsitelty sovellussarja jakaa verkonhallinnan noin neljään alueeseen. Ensimmäinen on paketin integrointi yleiseen verkonhallintainfrastruktuuriin, mikä tarkoittaa tukea saman valmistajan erityyppisille laitteille.

Seuraava toiminta-alue on välineet yksittäisten verkkolaitteiden, kuten keskittimen, kytkimen tai anturin, määrittämiseen ja hallintaan.

Kolmas alue on globaalit hallintatyökalut, jotka jo nyt vastaavat laitteiden ryhmittelystä ja niiden välisen viestinnän järjestämisestä, esimerkiksi verkkotopologiakaavion muodostavat sovellukset.

Tämän artikkelin aiheena on neljäs toiminta-alue - liikenteen seuranta. Vaikka VLAN-konfigurointityökalut ja globaali hallinta ovat tärkeitä verkonhallinnan näkökohtia, muodollisia verkonhallintamenettelyjä ei yleensä ole käytännöllinen toteuttaa yhdessä Ethernet-verkossa. Riittää, kun testaat verkon perusteellisesti asennuksen jälkeen ja tarkistat kuormitustasoa aika ajoin.

Hyvällä alustalla yritysten verkonhallintajärjestelmille tulee olla seuraavat ominaisuudet:

• skaalautuvuus;
• todellinen jakelu "asiakas/palvelin"-käsitteen mukaisesti;
• avoimuus käsitellä heterogeenisiä laitteita pöytäkoneista keskuskoneisiin.

Kaksi ensimmäistä ominaisuutta liittyvät läheisesti toisiinsa. Hyvä skaalautuvuus saavutetaan ohjausjärjestelmän hajautuksen ansiosta. Jakelu tarkoittaa tässä sitä, että järjestelmä voi sisältää useita palvelimia ja asiakkaita.

Heterogeenisten laitteiden tuki on nykypäivän ohjausjärjestelmissä enemmän toive kuin todellisuus. Tarkastellaan kahta suosittua verkonhallintatuotetta: CabletronSystemsin Spectrum ja Hewlett-Packardin OpenView. Molemmat yritykset valmistavat omia viestintälaitteitaan. Luonnollisesti Spectrum hallitsee parhaiten Cabletron-laitteita ja OpenView parhaiten Hewlett-Packardin laitteita.

Jos verkkokartta on rakennettu muiden valmistajien laitteista, nämä järjestelmät alkavat tehdä virheitä ja erehtyä yhdestä laitteesta toiseen, ja näitä laitteita hallittaessa ne tukevat vain niiden päätoimintoja ja monia hyödyllisiä lisätoimintoja, jotka erottavat tämän laitteen muista , ohjausjärjestelmä ei yksinkertaisesti ymmärrä eikä siksi voi käyttää niitä.

Tämän tilanteen välttämiseksi ohjausjärjestelmien kehittäjät tukevat standardien MIBI-, MIBII- ja RMONMIB-tietokantojen lisäksi myös lukuisia yksityisiä MIB-valmistajia. Johtava tällä alalla on Spectrum-järjestelmä, joka tukee yli 1000 MIB:tä eri valmistajilta.

OpenView'n kiistaton etu on kuitenkin sen kyky tunnistaa minkä tahansa verkon verkkoteknologiat, jotka toimivat TCP / IP:n yli. Spectrumissa tämä ominaisuus on rajoitettu Ethernet-, TokenRing-, FDDI-, ATM-, WAN- ja kytkentäverkkoihin. Verkon laitteiden lisääntyessä Spectrum muuttuu skaalautuvammaksi, jossa palveltujen solmujen määrää ei rajoita mikään.

On selvää, että kumman tahansa järjestelmän vahvuuksista ja heikkouksista huolimatta, jos verkkoa hallitsevat yhden valmistajan laitteet, kyseisen valmistajan hallintasovellusten läsnäolo millä tahansa suositulla hallintaympäristöllä mahdollistaa verkonvalvojien onnistuneen ratkaista monia ongelmia. Siksi hallintaalustojen kehittäjät toimittavat mukanaan työkaluja, jotka helpottavat sovellusten kehittämistä, ja tällaisten sovellusten saatavuus ja määrä katsotaan erittäin tärkeäksi tekijäksi hallintaalustaa valittaessa.

Järjestelmät laajan luokan verkkoihin

Tämä on halpojen järjestelmien ala verkkoille, jotka eivät ole kovin kriittisiä häiriöille. Siihen kuuluvat FoundationAgentMulti-Port, Foundation Probe, NetworkGeneralin Foundation Manager. Ne ovat täydellinen RMON-pohjainen verkonvalvontajärjestelmä ja sisältävät kahden tyyppisiä valvonta-agentteja - FoundationAgentin ja FoundationProben sekä FoundationManager-operaattorikonsolin.

FoundationAgentMulti-Port tukee kaikkia tavallisen SNMP-agentin ja edistyneen tiedonkeruu- ja suodatusjärjestelmän ominaisuuksia ja mahdollistaa myös tietojen keräämisen Ethernet- tai TokenRing-segmenteistä yhdellä tietokoneella.

FoundationProbe on sertifioitu tietokone, jossa on sertifioitu NIC ja sopiva FoundationAgent-ohjelmisto esiasennettuna. FoundationAgent ja FoundationProbe toimivat tyypillisesti näytöttömässä ja näppäimistöttömässä tilassa, koska niitä hallitsee FoundationManager-ohjelmisto.

FoundationManager-konsoliohjelmistoa on saatavana kahdessa eri muodossa, yksi Windowsille ja toinen UNIXille.

FoundationManager-konsolin avulla voit näyttää graafisesti tilastot kaikista valvotuista verkkosegmenteistä, määrittää automaattisesti keskimääräiset verkkoparametrit ja reagoida sallittujen parametrirajojen ylittymiseen (esimerkiksi käynnistää käsittelijäohjelman, käynnistää SNMP-trapin ja SNA-hälytyksen), rakentaa graafinen dynaaminen liikennekartta asemien välillä.

Järjestelmät hajautetuille verkkoille

Tämä on kalliiden huippuluokan järjestelmien ala, joka on suunniteltu analysoimaan ja valvomaan verkkoja, joilla on korkeimmat mahdolliset vaatimukset luotettavuuden ja suorituskyvyn varmistamiseksi. Se sisältää DistributedSnifferSystem (DSS) -tuotteen, joka on järjestelmä, joka koostuu useista verkon yli hajautetuista laitteistokomponenteista ja ohjelmistoista, jotka ovat tarpeen kaikkien verkkosegmenttien, mukaan lukien etäosien, jatkuvaan analysointiin.

DSS-järjestelmä on rakennettu kahdentyyppisistä komponenteista - SnifferServer (SS) ja SniffMasterConsole (SM). Ethernet-, TokenRing- tai sarjaporttikortteja voidaan käyttää liitäntöinä vuorovaikutukseen konsolin kanssa. Siten on mahdollista ohjata melkein minkä tahansa verkkotopologian segmenttiä ja käyttää erilaisia ​​ympäristöjä vuorovaikutukseen konsolin kanssa, mukaan lukien modeemiyhteydet.

SnifferServer-ohjelmisto koostuu kolmesta osajärjestelmästä - valvonnasta, protokollien tulkinnasta ja asiantuntija-analyysistä. Valvontaalijärjestelmä on verkon nykyisen tilan näyttämiseen tarkoitettu järjestelmä, joka mahdollistaa tilastojen saamisen jokaisesta asemasta ja verkkosegmentistä kullekin käytetylle protokollalle. Kaksi muuta alajärjestelmää ansaitsevat erillisen keskustelun.

Protokollatulkinta-alijärjestelmän toimintoihin kuuluu siepattujen pakettien analysointi ja pakettien otsikoiden kunkin kentän ja sen sisällön täydellisin tulkinta. NetworkGeneral on luonut lajissaan tehokkaimman alijärjestelmän - ProtocolInterpreter pystyy täysin purkamaan yli 200 protokollaa kaikista seitsemästä ISO / OSI-mallin kerroksesta (TCP / IP, IPX / SPX, NCP, DECnetSunNFS, X-Windows, SNAIBM-protokolla perhe, AppleTalk, BanyanVINES, OSI, XNS, X.25, erilaiset verkkoyhteyskäytännöt). Samanaikaisesti tiedot voidaan näyttää jossakin kolmesta tilasta - yleinen, yksityiskohtainen ja heksadesimaalinen.

Asiantuntijaanalyysijärjestelmän (ExpertAnalysis) päätarkoituksena on vähentää verkon seisokkeja ja poistaa verkon pullonkauloja tunnistamalla automaattisesti poikkeavia ilmiöitä ja generoimalla automaattisesti menetelmiä niiden ratkaisemiseksi.

ExpertAnalysis-järjestelmä tarjoaa sen, mitä NetworkGeneral kutsuu aktiiviseksi analyysiksi. Tämän käsitteen ymmärtämiseksi harkitse saman virheellisen tapahtuman käsittelyä verkossa perinteisillä passiivisilla analyysijärjestelmillä ja aktiivisella analyysijärjestelmällä.

Oletetaan, että verkossa oli lähetysmyrsky klo 3.00, joka aiheutti tietokannan varmuuskopiointijärjestelmän epäonnistumisen klo 3.05. Klo 4:00 mennessä myrsky lakkaa ja järjestelmäparametrit palautuvat normaaliksi. Verkossa toimivan passiivisen liikenneanalyysijärjestelmän tapauksessa kello 8:00 mennessä töihin tulleilla järjestelmänvalvojilla ei ole muuta analysoitavaa kuin tiedot toisesta viasta ja parhaimmillaan yön yleiset liikennetilastot - mahdollisen sieppauksen koko puskuri ei salli kaiken verkon yli kulkevan liikenteen tallentamista yön aikana. Lähetysmyrskyyn johtaneen syyn poistamisen todennäköisyys tällaisessa tilanteessa on erittäin pieni.

Tarkastellaan nyt aktiivisen analyysijärjestelmän reaktiota samoihin tapahtumiin. Klo 03:00, välittömästi lähetysmyrskyn alkamisen jälkeen, aktiivinen analyysijärjestelmä havaitsee epätyypillisen tilanteen puhkeamisen, aktivoi vastaavan asiantuntijan ja korjaa sen antamat tiedot tapahtumasta ja sen syistä tietokantaan. Klo 03:05 uusi arkistointijärjestelmän vikaan liittyvä epätyypillinen tilanne korjataan ja vastaavat tiedot korjataan. Tämän seurauksena järjestelmänvalvojat saavat kello 8.00 täydellisen kuvauksen kohdatuista ongelmista, niiden syistä ja suosituksia näiden syiden poistamiseksi.

Kannettavat analyysi- ja valvontajärjestelmät

Analysaattorin kannettava versio, joka on ominaisuuksiltaan lähes samanlainen kuin DSS, on toteutettu ExpertSnifferAnalyzer (ESA) -sarjan tuotteissa, joka tunnetaan myös nimellä TurboSnifferAnalyzer. Paljon halvemmalla kuin DSS-sarjan tuotteet, ESA tarjoaa järjestelmänvalvojalle samat ominaisuudet kuin täysimittainen DSS, mutta vain siinä verkkosegmentissä, johon ESA on tällä hetkellä kytketty. Nykyiset versiot tarjoavat täydellisen analyysin, protokollien tulkinnan sekä liitetyn verkkosegmentin tai segmenttien välisen tietoliikennelinjan valvonnan. Samoja verkkotopologioita tuetaan kuin DSS-järjestelmissä. Yleensä ESA:ita käytetään tarkistamaan säännöllisesti ei-kriittisiä verkkosegmenttejä, joissa ei ole käytännöllistä jatkuvasti käyttää analysaattoriagenttia.

Novell LANalyser Protocol Analyzer

LANalyser toimitetaan verkkokorttina ja ohjelmistona, joka on asennettava henkilökohtaiseen tietokoneeseen, tai PC:nä, johon kortti ja ohjelmisto on jo asennettu.

LANalyserissa on kehitetty käyttäjäystävällinen käyttöliittymä, jonka avulla voit asettaa valitun toimintatavan. ApplicationLANalyser-valikko on päätyökalu kaappaustilan määrittämiseen, ja se tarjoaa valikoiman protokollia, suodattimia, käynnistäjiä, hälytyksiä ja niin edelleen. Tämä analysaattori voi toimia NetBIOS, SMB, NCP, NCPBurst, TCP/IP, DECnet, BanyanVINES, AppleTalk, XNS, SunNFS, ISO, EGP, NIS, SNA ja joidenkin muiden protokollien kanssa.

Lisäksi LANalyser sisältää asiantuntijajärjestelmän, joka auttaa käyttäjää vianetsinnässä.

Johtopäätös

Kaikki edellä mainitut järjestelmät ovat tietysti välttämättömiä suuren yrityksen verkossa, mutta ne ovat liian hankalia organisaatioille, joissa verkon käyttäjien määrä ei ylitä 200-300 henkilöä. Puolet järjestelmän toiminnoista jää lunastamatta, ja jakelupaketin lasku pelottaa pääkirjanpitäjän ja yrityksen päällikön. Lisäksi laitteistovikojen ja järjestelmän pullonkaulojen hallinta pienessä verkossa on useimmiten yhden tai kahden järjestelmänvalvojan vallassa, eikä se vaadi automatisointia.

Siitä huolimatta kaiken mittakaavan verkostossa meidän mielestämme verkkoanalyysijärjestelmän tulisi olla läsnä muodossa tai toisessa, jonka ansiosta ylläpitäjän on paljon helpompi hallita talouttaan.

ComputerPress 7 "2001

ABSTRAKTI

Tämä asiakirja on tekninen hanke verkonvalvontajärjestelmän kehittämiseksi ja toteuttamiseksi Gerkon LLC:n Verkhnepyshman kaupungin julkiseen tiedonsiirtoverkkoon. Projekti sisälsi olemassa olevien verkonvalvontajärjestelmien selvityksen, yrityksen nykytilanteen analyysin ja perusteli verkonvalvontajärjestelmän tiettyjen komponenttien valintaa.

Dokumentti sisältää kuvauksen suunnitteluratkaisuista ja laitespesifikaatioista.

Suunnittelun tuloksena ovat kehitetyt ratkaisut järjestelmän toteuttamiseen ja käyttöön:

§ Täydellinen kuvaus järjestelmän suunnittelun, kehittämisen ja toteutuksen kaikista vaiheista;

§ Järjestelmänhallintaopas, joka sisältää kuvauksen järjestelmän käyttöliittymästä.

Tämä asiakirja edustaa kokonaisia ​​suunnitteluratkaisuja ja sitä voidaan käyttää järjestelmän toteuttamiseen.

LUETTELO GRAAFISET ASIAKIRJAT

Taulukko 1 - Luettelo graafisista asiakirjoista

1 -järjestelmän verkonvalvonta220100 4010002verkon tekninen rakenne220100 4010003verkon valvonnan ja ilmoitusten ytimen algoritmi 220100 4010004 verkkorajapintojen latausanalysaattorin rakenne220100 4010000 4010005 Event24010005 C40010005 C4000

LUETTELO SYMBOLISTA JA TERMEISTÄ

Ethernet on IEEE:n julkaisema tiedonsiirtostandardi. Määrittää, kuinka tietoja lähetetään tai vastaanotetaan yleisestä viestintävälineestä. Muodostaa alemman kuljetuskerroksen ja sitä käyttävät useat ylemmän tason protokollat. Tarjoaa 10 Mbps tiedonsiirtonopeuden.

Fast Ethernet on 100 Mbps tiedonsiirtotekniikka, joka käyttää CSMA/CD-menetelmää, aivan kuten 10Base-T.

FDDI - Fiber Distributed Data Interface - kuituoptinen hajautettu tiedonsiirtoliitäntä - tiedonsiirtotekniikka 100 Mbps nopeudella token ring -menetelmällä.

IEEE - Institute of Electrical and Electronic Engineers (Institute of Electrical and Electronic Engineers) - organisaatio, joka kehittää ja julkaisee standardeja.

LAN - Lähiverkko - lähiverkko, LAN. osoite - Media Access Control - verkkolaitteen tunnusnumero, jonka yleensä määrittää valmistaja.

RFC - Request for Comments - IEEE-organisaation julkaisema asiakirjasarja, joka sisältää kuvauksen standardeista, spesifikaatioista jne.

TCP / IP - Transmission Control Protocol / Internet Protocol - lähetyksen ohjausprotokolla / Internet-protokolla.

LAN - Lähiverkko.

OS - Käyttöjärjestelmä.

ON - Ohjelmisto.

SCS - Strukturoitu kaapelointijärjestelmä.

DBMS - Tietokannan hallintajärjestelmä.

Trend - Pitkän aikavälin tilastot, joiden avulla voit rakentaa niin sanotun trendin.

TIETOKONE - Elektroninen tietokone.

JOHDANTO

Nykyaikaisen yrityksen tietoinfrastruktuuri on monimutkainen ryhmittymä eri kokoisia ja monimuotoisia verkkoja ja järjestelmiä. Jotta ne toimivat sujuvasti ja tehokkaasti, tarvitset koko yritystason hallintaalustan integroiduilla työkaluilla. Kuitenkin aivan viime aikoihin asti verkonhallintateollisuuden rakenne esti tällaisten järjestelmien luomisen - näiden markkinoiden "toimijat" pyrkivät johtamaan markkinoille tuomalla rajoitetun laajuuden tuotteita käyttämällä työkaluja ja tekniikoita, jotka eivät ole yhteensopivia muiden järjestelmien kanssa. myyjät.

Nykyään tilanne on muuttumassa parempaan suuntaan – on tuotteita, jotka väittävät hallitsevansa yleisesti kaikkia yrityksen tietoresursseja työpöytäjärjestelmistä keskuskoneisiin ja paikallisista verkoista verkkoresursseihin. Samalla tulee ymmärrys siitä, että ohjaussovellusten on oltava avoimia kaikkien valmistajien ratkaisuille.

Tämän työn relevanssi johtuu siitä, että henkilökohtaisten tietokoneiden leviämisen ja niiden pohjalta automatisoitujen työasemien (AWP) luomisen yhteydessä on kasvanut lähiverkkojen (LAN) merkitys, joiden diagnostiikka on tutkimuksemme kohde. Tutkimuksen kohteena ovat nykyaikaisten tietokoneverkkojen tärkeimmät organisointi- ja diagnostiikkamenetelmät.

"Paikallisen verkon diagnostiikka" - tietoverkon tilan (jatkuva) analyysi. Verkkolaitteiden toimintahäiriön sattuessa toimintahäiriön tosiasia kirjataan, sen sijainti ja tyyppi määritetään. Vikailmoitus lähetetään, laite sammutetaan ja korvataan varmuuskopiolla.

Useimmiten diagnosoinnista vastaavan verkon ylläpitäjän tulee aloittaa verkkonsa ominaisuuksien tutkiminen jo sen muodostumisvaiheessa, ts. tuntea verkkokaavion ja yksityiskohtaisen kuvauksen ohjelmistokokoonpanosta, jossa ilmoitetaan kaikki parametrit ja liitännät. Näiden tietojen rekisteröintiin ja tallentamiseen soveltuvat erityiset verkkodokumentaatiojärjestelmät. Niiden avulla järjestelmänvalvoja tietää etukäteen kaikki mahdolliset järjestelmänsä "piilotetut viat" ja "pullonkaulat", jotta hän tietää hätätilanteessa, mikä laitteiston tai ohjelmiston ongelma on, ohjelma on vioittunut. tai johti virheeseen.

Verkon ylläpitäjän tulee pitää mielessä, että käyttäjien näkökulmasta verkon sovellusohjelmiston laatu on ratkaisevaa. Kaikki muut kriteerit, kuten tiedonsiirtovirheiden määrä, verkon resurssien käyttöaste, laitteiden suorituskyky jne., ovat toissijaisia. "Hyvä verkko" on sellainen, jonka käyttäjät eivät huomaa sen toimintaa.

Yhtiö

Valmistumista edeltävä harjoittelu tapahtui Gerkon LLC:n tukiosastolla järjestelmänvalvojana. Yritys on tarjonnut Internet-yhteyspalveluita Verkhnyaja Pyshman ja Sredneuralskin kaupungeissa Ethernet-teknologiaa ja puhelinverkkoyhteyksiä käyttäen vuodesta 1993 lähtien ja on yksi ensimmäisistä Internet-palveluntarjoajista näissä kaupungeissa. Palvelujen tarjoamisen sääntöjä säännellään julkisella tarjouksella ja määräyksillä.

Osaston tieteelliset ja tuotannolliset tehtävät

Tukiosasto ratkaisee seuraavat tehtävät yrityksen sisällä:

§ Tekninen ja teknologinen järjestäminen Internetiin pääsyn tarjoamiseksi puhelinverkkoyhteyden ja erityisten kanavien kautta;

§ Langattomien Internet-yhteyksien tekninen ja teknologinen organisointi;

§ levytilan jakaminen sivustojen tallennusta ja käyttöä varten (isännöinti);

§ tuki postilaatikoille tai virtuaaliselle sähköpostipalvelimelle;

§ asiakkaan laitteiden sijoittaminen palveluntarjoajan toimipisteeseen (sijoittaminen);

§ omistettujen ja virtuaalipalvelimien vuokraus;

§ datan varmuuskopio;

§ yksityisten yritysten yritysverkostojen käyttöönotto ja tuki.

1. VERKON SEURANTAJÄRJESTELMÄT

Huolimatta lukuisista tietokoneverkkojen havaitsemiseen ja vianetsintään liittyvistä tekniikoista ja työkaluista, verkonvalvojien "maa jalkojen alla" on edelleen melko horjunut. Tietokoneverkot sisältävät yhä enemmän kuituoptisia ja langattomia komponentteja, jotka tekevät perinteisistä tekniikoista ja työkaluista, jotka on suunniteltu tavanomaiseen kuparikaapelointiin, hyödyttömiä. Lisäksi yli 100 Mbps:n nopeuksilla perinteiset diagnostiikkamenetelmät epäonnistuvat usein, vaikka siirtoväline olisi tavallinen kuparikaapeli. Kuitenkin ehkä merkittävin muutos tietokoneverkkotekniikassa, jonka järjestelmänvalvojat ovat joutuneet kohtaamaan, on ollut väistämätön siirtyminen jaetuista Ethernet-verkoista kytkentäisiin verkkoihin, joissa yksittäiset palvelimet tai työasemat toimivat usein kytketyinä segmentteinä.

Totta, kun teknisiä muutoksia tehtiin, jotkut vanhat ongelmat ratkesivat itsestään. Koaksiaalikaapeli, jonka sähkövikoja on aina ollut vaikeampi havaita kuin kierrettyä paria, on tulossa harvinaisuus yritysympäristöissä. Token Ring -verkot, joiden suurin ongelma oli niiden eroavaisuus Ethernetin kanssa (eikä ollenkaan tekninen heikkous), korvataan vähitellen kytketyillä Ethernet-verkoilla. Protokollat, jotka tuottavat lukuisia verkkokerroksen protokollavirheilmoituksia, kuten SNA, DECnet ja AppleTalk, korvataan IP:llä. Itse IP-protokollapinosta on tullut vakaampi ja helpompi ylläpitää, mistä ovat osoituksena miljoonat asiakkaat ja miljardit Web-sivut Internetissä. Jopa Microsoftin paatuneiden vastustajien on myönnettävä, että uuden Windows-asiakkaan yhdistäminen Internetiin on paljon helpompaa ja luotettavampaa kuin kolmannen osapuolen TCP/IP-pinojen ja erillisen puhelinverkkoyhteysohjelmiston asentaminen.

Niin vaikeaa kuin nykypäivän useat tekniikat ovatkin verkon suorituskyvyn vianetsintä ja hallinta, tilanne voi olla vieläkin vakavampi, jos ATM-tekniikka yleistyisi PC-tasolla. Sillä oli myös myönteinen rooli, että 1990-luvun lopulla, ennen kuin ne saivat hyväksynnän, myös jotkut muut nopeat tiedonsiirtotekniikat hylättiin, mukaan lukien Token Ring, jonka kaistanleveys on 100 Mbps, 100VG-AnyLAN ja kehittyneet ARCnet-verkot. Lopuksi erittäin monimutkainen OSI-protokollapino (jonka useat Euroopan hallitukset ovat kuitenkin laillistaneet) hylättiin Yhdysvalloissa.

Tarkastellaanpa joitain kiireellisiä ongelmia, joita syntyy yritysten verkonvalvojille.

Tietokoneverkkojen hierarkkinen topologia Gigabit Ethernet -runkoverkoilla ja erilliset 10 tai jopa 100 Mbps:n kytkinportit yksittäisille asiakasjärjestelmille mahdollisti käyttäjien mahdollisesti käytettävissä olevan maksimikaistanleveyden kasvattamisen vähintään 10-20-kertaiseksi. Tietenkin useimmissa tietokoneverkoissa on pullonkauloja palvelimien tai pääsyreitittimien tasolla, koska kaistanleveys yksittäistä käyttäjää kohden on huomattavasti alle 10 Mbps. Siksi 10 Mbps:n keskitinportin korvaaminen erillisellä 100 Mbps:n kytkinportilla päätesolmulle ei aina johda merkittävään nopeuden kasvuun. Jos kuitenkin ajattelee, että kytkimien hinta on viime aikoina laskenut ja useimmat yritykset ovat asentaneet luokan 5 kaapelin, joka tukee 100 Mbps Ethernet-tekniikkaa, ja asentaneet verkkokortteja, jotka voivat toimia 100 Mbps:n nopeudella heti järjestelmän uudelleenkäynnistyksen jälkeen, siitä tulee se. on selvää, miksi on niin vaikea vastustaa modernisoinnin kiusausta. Perinteisessä jaetussa lähiverkossa protokolla-analysaattori tai monitori voi tutkia kaiken liikenteen tietyllä verkkosegmentillä.

Riisi. 1.1 - Perinteinen LAN, jossa on jaettu media ja protokolla-analysaattori

Vaikka kytketyn verkon suorituskykyetu on joskus hienovarainen, kytkettyjen arkkitehtuurien yleistyminen on ollut tuhoisaa perinteisille diagnostisille työkaluille. Voimakkaasti segmentoidussa verkossa protokollahauskijat pystyvät näkemään yksittäislähetysliikenteen vain yhdessä kytkinportissa, toisin kuin vanhassa verkkotopologiassa, jossa he voivat tutkia mitä tahansa pakettia törmäysalueella. Tällaisissa olosuhteissa perinteiset seurantatyökalut eivät voi kerätä tilastoja kaikista "keskusteluista", koska jokainen "puhuva" päätepistepari käyttää itse asiassa omaa verkkoaan.

Riisi. 1.2 - Kytketty verkko

Kytketyssä verkossa protokolla-analysaattori yhdessä kohdassa voi "nähdä" vain yhden segmentin, jos kytkin ei pysty peilaamaan useita portteja samanaikaisesti.

Voidakseen hallita voimakkaasti segmentoituja verkkoja, kytkintoimittajat tarjoavat erilaisia ​​työkaluja verkon täyden näkyvyyden palauttamiseksi, mutta matkan varrella on monia haasteita. Nyt toimitettavat kytkimet tukevat yleensä "peilaavia" portteja, kun yhden niistä liikenne kopioidaan aiemmin käyttämättömään porttiin, johon monitori tai analysaattori on kytketty.

"Peilauksella" on kuitenkin useita haittoja. Ensinnäkin vain yksi portti on näkyvissä kerrallaan, joten on erittäin vaikeaa tunnistaa ongelmia, jotka vaikuttavat useisiin portteihin kerralla. Toiseksi peilaus voi heikentää kytkimen suorituskykyä. Kolmanneksi fyysisen kerroksen vikoja ei yleensä toisteta peiliportissa, ja joskus VLAN-merkinnät jopa menetetään. Lopuksi monissa tapauksissa kaksisuuntaisia ​​Ethernet-linkkejä ei voida peilata täysin.

Osittainen ratkaisu aggregoitujen liikenneparametrien analysointiin on käyttää mini-RMON-agenttien valvontaominaisuuksia, varsinkin kun ne on sisäänrakennettu useimpien Ethernet-kytkimien jokaiseen porttiin. Vaikka mini-RMON-agentit eivät tue RMON II Capture -objektien ryhmää, joka tarjoaa täydellisen protokolla-analyysin, ne voivat silti arvioida resurssien käyttöä, virhesuhteita ja monilähetysvolyymia.

Jotkut porttien peilaustekniikan haitoista voidaan voittaa asentamalla "passiiviset hanat", kuten Shomitin valmistamat. Nämä laitteet ovat esiasennettuja Y-liittimiä, ja niiden avulla protokolla-analysaattorit tai muut laitteet voivat valvoa todellista signaalia, ei regeneroitua.

Seuraava todellinen ongelma on optiikan ominaisuuksien ongelma. Tietokoneverkkojen järjestelmänvalvojat käyttävät tavallisesti erikoistuneita optisen verkon diagnostiikkalaitteita vain optisten kaapelien vianmäärityksessä. Tavallinen SNMP- tai CLI-pohjainen laitehallintaohjelmisto voi havaita kytkimien ja reitittimien ongelmat optisilla liitännöillä. Ja vain harvat verkonvalvojat kohtaavat tarpeen diagnosoida SONET-laitteet.

Kuituoptisissa kaapeleissa on huomattavasti vähemmän syitä mahdollisten toimintahäiriöiden syntymiseen kuin kuparikaapelin tapauksessa. Optiset signaalit eivät aiheuta ylikuulumista, joka syntyy, kun signaali toisessa johtimessa indusoi signaalin toisessa, mikä tekee kuparikaapelin diagnostisista laitteista vaikeimman. Optiset kaapelit ovat immuuneja sähkömagneettiselle kohinalle ja indusoituneille signaaleille, joten niitä ei tarvitse sijoittaa kaukana hissien moottoreista ja loistelampuista, eli kaikki nämä muuttujat voidaan sulkea pois diagnoosiskenaariosta.

Signaalin voimakkuus tai optinen teho tietyssä pisteessä on oikeastaan ​​ainoa muuttuja, joka on mitattava optisten verkkojen vianmäärityksessä. Jos on mahdollista määrittää signaalihäviö koko optisessa kanavassa, on mahdollista tunnistaa melkein mikä tahansa ongelma. Kuparikaapelin testaajien edulliset lisämoduulit mahdollistavat optiset mittaukset.

Yritykset, jotka ovat ottaneet käyttöön suuren optisen infrastruktuurin ja ylläpitävät sitä itse, saattavat joutua ostamaan optisen aikaalueen heijastusmittarin (OTDR), joka suorittaa samat toiminnot optiselle kuidulle kuin kuparikaapelin Time Domain Reflectometer (TDR). Laite toimii kuin tutka: se lähettää pulssisignaaleja alas kaapelia pitkin ja analysoi niiden heijastukset, joiden perusteella se havaitsee johdinvian tai muun poikkeaman ja kertoo sitten asiantuntijalle, mistä kaapelista pitää etsiä ongelman lähdettä. .

Vaikka useat kaapeliliitin- ja liitintoimittajat ovat helpottaneet optisten kuitujen päättämistä ja haaroittamista, tämä vaatii silti jonkin verran erikoistaitoa, ja kunnollisen politiikan avulla yrityksen, jolla on kehittynyt optinen infrastruktuuri, on koulutettava työntekijänsä. Riippumatta siitä, kuinka hyvin kaapeliverkko on asennettu, on aina mahdollisuus fyysiseen vaurioitumiseen kaapelissa jonkin odottamattoman tapahtuman seurauksena.

Myös langattomien 802.11b-lähiverkkojen vianmääritys voi tapahtua. Itse diagnostiikka on yhtä yksinkertaista kuin keskitinpohjaisten Ethernet-verkkojen tapauksessa, koska langaton tiedonsiirtoväline on jaettu kaikkien asiakasradiolaitteiden omistajien kesken. Sniffer TechHlogies oli ensimmäinen, joka tarjosi protokolla-analyysiratkaisun tällaisille verkoille jopa 11 Mbps:iin asti, ja myöhemmin useimmat johtavista analysaattoritoimittajista esittelivät samanlaisia ​​järjestelmiä.

Toisin kuin langallisessa Ethernet-keskittimessä, langattomien asiakasyhteyksien laatu ei ole läheskään tasaista. Kaikissa paikallisissa lähetyksissä käytettävät mikroaaltoradiosignaalit ovat heikkoja ja joskus arvaamattomia. Pienetkin muutokset antennin asennossa voivat vaikuttaa vakavasti yhteyksien laatuun. Langattomien LAN-tukipisteiden mukana toimitetaan laitehallintakonsoli, ja tämä on usein tehokkaampi diagnostiikkamenetelmä kuin vierailla langattomilla asiakkailla ja tarkkailla suorituskykyä ja virheolosuhteita kädessä pidettävällä analysaattorilla.

Vaikka kämmenmikrojen (PDA) käyttäjien kokemat tiedon synkronoinnin ja laiteasennuksen ongelmat vastaavat luonnollisemmin teknisen tuen tehtäviä kuin verkonvalvojan tehtäviä, ei ole vaikea ennakoida, että lähitulevaisuudessa monet Tällaiset laitteet kehittyvät erillisistä aputyökaluista, jotka täydentävät PC:tä täysverkon asiakkaissa.

Yleissääntönä on, että yritysten langattomat verkko-operaattorit estävät (tai niiden pitäisi) estää sellaisten liian avoimien järjestelmien käyttöönottoa, joissa kuka tahansa verkon kantamalla oleva käyttäjä, jolla on yhteensopiva liitäntäkortti, voi päästä käsiksi järjestelmän jokaiseen tietokehykseen. Langaton WEP (Wired Equivalent Privacy) -suojausprotokolla tarjoaa käyttäjän todennuksen, eheyden ja tietojen salauksen, mutta kuten yleensäkin, kehittynyt suojaus vaikeuttaa verkko-ongelmien perimmäisten syiden analysointia. Turvallisissa WEP-verkoissa diagnostiikan on tiedettävä avaimet tai salasanat, jotka suojaavat tietoresursseja ja hallitsevat pääsyä järjestelmään. Kaikkien pakettien vastaanottotilassa protokolla-analysaattori pystyy näkemään kaikki kehysotsikot, mutta niiden sisältämä tieto ilman avaimia on merkityksetöntä.

Diagnosoitaessa tunneloituja linkkejä, joita monet toimittajat kutsuvat etäkäyttöisiksi virtuaalisiksi yksityisiksi verkoiksi, esiin tulevat ongelmat ovat samanlaisia ​​kuin salattuja langattomia verkkoja analysoitaessa. Jos liikenne ei kulje tunneloidun linkin kautta, vian syytä ei ole helppo määrittää. Tämä voi olla todennusvirhe, vika jossakin päätepisteessä tai ruuhka julkisella Internet-vyöhykkeellä. Protokollaanalysaattorin käyttäminen tunneloidun liikenteen korkean tason virheiden havaitsemiseen olisi turhaa, koska tietojen sisältö sekä sovellus-, kuljetus- ja verkkokerroksen otsikot ovat salattuja. Yleisesti ottaen yritysverkkojen turvallisuuden parantamiseksi tehdyt toimenpiteet vaikeuttavat vikojen ja suorituskykyongelmien tunnistamista. Palomuurit, välityspalvelimet ja tunkeutumisen havaitsemisjärjestelmät voivat vaikeuttaa vianmääritystä entisestään.

Näin ollen tietokoneverkkojen diagnosointiongelma on ajankohtainen ja vikojen diagnosointi on viime kädessä hallintatehtävä. Useimmissa kriittisissä yritysjärjestelmissä pitkiä palautuspyrkimyksiä ei voida hyväksyä, joten ainoa ratkaisu on käyttää redundantteja laitteita ja prosesseja, jotka voivat ottaa tarvittavat toiminnot heti vian ilmetessä. Joissakin yrityksissä verkoissa on aina ylimääräinen redundantti komponentti, jos pääkomponentti epäonnistuu, eli n x 2 komponenttia, missä n on hyväksyttävän suorituskyvyn edellyttämien ensisijaisten komponenttien lukumäärä. Jos keskimääräinen korjausaika (MTTR) on tarpeeksi korkea, voidaan tarvita lisää redundanssia. Asia on siinä, että vianetsintäaikaa ei ole helppo ennustaa, ja suuret kustannukset arvaamattoman toipumisjakson aikana ovat merkki huonosta johtamisesta.

Vähemmän kriittisissä järjestelmissä redundanssi ei välttämättä ole taloudellisesti kannattavaa, jolloin on järkevää investoida tehokkaimpiin työkaluihin (ja henkilöstön koulutukseen), jotta laitoksen diagnosointia ja vianmääritystä voidaan nopeuttaa mahdollisimman nopeasti. Lisäksi tiettyjen järjestelmien tuki voidaan ulkoistaa joko ulkoistamalla yritykselle tai käyttämällä ulkoisten datakeskusten ominaisuuksia tai ottamalla yhteyttä sovelluspalveluntarjoajiin (ASP) tai hallintapalveluntarjoajiin. Kustannusten lisäksi merkittävimpänä tekijänä, joka vaikuttaa päätökseen käyttää ulkopuolisten organisaatioiden palveluita, voidaan pitää oman henkilöstön osaamisen tasoa. Verkon ylläpitäjien on harkittava, liittyykö jokin tietty toiminto niin läheisesti yrityksen erityistehtäviin, ettei ulkopuolisen asiantuntijan voida odottaa tekevän parempaa työtä kuin yrityksen työntekijät tekisivät.

Melkein heti ensimmäisten yritysverkkojen käyttöönoton jälkeen, joiden luotettavuus jätti paljon toivomisen varaa, valmistajat ja kehittäjät esittivät "itsekorjautuvien verkkojen" käsitteen. Nykyaikaiset verkot ovat varmasti luotettavampia kuin 90-luvulla, mutta eivät siksi, että ongelmat alkoivat korjata itsestään. Ohjelmisto- ja laitteistovikojen vianmääritys nykyverkoissa vaatii edelleen ihmisen väliintuloa, eikä tässä asiassa ole odotettavissa oleellista muutosta lyhyellä aikavälillä. Diagnostiset menetelmät ja työkalut ovat melko yhdenmukaisia ​​nykyaikaisten käytäntöjen ja tekniikoiden kanssa, mutta ne eivät ole vielä saavuttaneet tasoa, joka säästäisi merkittävästi verkonvalvojien aikaa verkko-ongelmien ja suorituskyvyn puutteiden torjunnassa.

1.1 Diagnostiikkaohjelmisto

Tietokoneverkkojen diagnosointiohjelmistoista voidaan erottaa erityiset verkonhallintajärjestelmät (Network Management Systems) - keskitetyt ohjelmistojärjestelmät, jotka keräävät tietoa verkkosolmujen ja viestintälaitteiden tilasta sekä verkossa kiertävästä liikenteestä. Nämä järjestelmät eivät vain valvo ja analysoi verkkoa, vaan myös suorittavat verkonhallintatoimia automaattisessa tai puoliautomaattisessa tilassa - laiteporttien käyttöönotto ja poistaminen käytöstä, siltojen, kytkimien ja reitittimien osoitetaulukoiden siltaparametrien muuttaminen jne. Esimerkkejä ohjausjärjestelmistä ovat suositut järjestelmät HPOpenView, SunNetManager, IBMNetView.

Järjestelmänhallintatyökalut suorittavat samanlaisia ​​toimintoja kuin hallintajärjestelmät, mutta viestintälaitteiden osalta. Jotkut näiden kahden hallintajärjestelmän toiminnot voivat kuitenkin olla päällekkäisiä, esimerkiksi järjestelmänhallintatyökalut voivat suorittaa yksinkertaisen verkkoliikenteen analyysin.

Asiantuntijajärjestelmät. Tämän tyyppinen järjestelmä kerää ihmisten tietoa epänormaalin verkon toiminnan syiden tunnistamisesta ja mahdollisista tavoista saada verkko takaisin terveeseen tilaan. Asiantuntijajärjestelmät toteutetaan usein erillisinä alijärjestelminä erilaisista verkon valvonta- ja analysointityökaluista: verkonhallintajärjestelmät, protokolla-analysaattorit, verkkoanalysaattorit. Asiantuntijajärjestelmän yksinkertaisin versio on tilannekohtainen ohjejärjestelmä. Monimutkaisemmat asiantuntijajärjestelmät ovat niin sanottuja tietokantoja, joissa on tekoälyn elementtejä. Esimerkki tällaisesta järjestelmästä on Cabletronin Spectrum-ohjausjärjestelmään sisäänrakennettu asiantuntijajärjestelmä.

1.1.1 Protokollaanalysaattorit

Uutta verkkoa suunniteltaessa tai vanhaa verkkoa päivitettäessä tulee usein tarpeelliseksi kvantifioida joitain verkon ominaisuuksia, kuten tietovirtojen intensiteetti verkon tietoliikennelinjoilla, pakettien käsittelyn eri vaiheissa esiintyvät viiveet, vastausajat pyyntöihin. tavalla tai toisella, tiettyjen tapahtumien esiintymistiheys ja muut ominaisuudet.

Näihin tarkoituksiin voidaan käyttää erilaisia ​​keinoja ja ennen kaikkea verkonhallintajärjestelmien valvontatyökaluja, joista on jo aiemmin keskusteltu. Jotkut verkon mittaukset voidaan suorittaa myös käyttöjärjestelmään sisäänrakennetuilla ohjelmistomittareilla, esimerkkinä tästä on Windows Performance Monitor OS -komponentti. Nykyisetkin kaapelitestaajat pystyvät sieppaamaan paketteja ja analysoimaan niiden sisältöä.

Mutta edistynein verkkotutkimustyökalu on protokolla-analysaattori. Protokollaanalyysiprosessi sisältää tietyn verkkoprotokollan toteuttavien verkossa kiertävien pakettien sieppauksen ja näiden pakettien sisällön tutkimisen. Analyysin tulosten perusteella on mahdollista tehdä järkeviä ja tasapainoisia muutoksia mihin tahansa verkkokomponenttiin, optimoida sen suorituskykyä ja etsiä ongelmia. On selvää, että jotta voidaan tehdä johtopäätöksiä muutoksen vaikutuksista verkkoon, protokollat ​​on luonnollisesti analysoitava sekä ennen muutoksen tekemistä että sen jälkeen.

Protokollaanalysaattori on joko itsenäinen erikoislaite tai Htebook-luokan henkilökohtainen, tavallisesti kannettava tietokone, joka on varustettu erityisellä verkkokortilla ja siihen liittyvällä ohjelmistolla. Käytettävän verkkokortin ja ohjelmiston on vastattava verkon topologiaa (rengas, väylä, tähti). Analysaattori kytkeytyy verkkoon samalla tavalla kuin tavallinen solmu. Erona on se, että analysaattori voi vastaanottaa kaikki verkon kautta lähetetyt datapaketit, kun taas tavallinen asema vain sille osoitetut. Analysaattoriohjelmisto koostuu verkkosovittimen toimintaa tukevasta ja vastaanotetun tiedon dekoodaavasta ytimestä sekä lisäohjelmakoodista tutkittavan verkon topologian tyypistä riippuen. Lisäksi toimitetaan useita protokollakohtaisia ​​dekoodausrutiineja, kuten IPX. Joihinkin analysaattoreihin voi sisältyä myös asiantuntijajärjestelmä, joka voi antaa käyttäjälle suosituksia siitä, mitä kokeita tietyssä tilanteessa tulisi tehdä, mikä voi tarkoittaa tiettyjä mittaustuloksia, miten tietyntyyppiset verkkohäiriöt voidaan eliminoida.

Huolimatta markkinoilla olevien protokolla-analysaattoreiden suhteellisesta monimuotoisuudesta, on joitakin ominaisuuksia, jotka ovat jossain määrin luontaisia ​​niille kaikille:

Käyttöliittymä. Useimmissa analysaattoreissa on kehitetty käyttäjäystävällinen käyttöliittymä, joka perustuu yleensä Windowsiin tai Motifiin. Tämän käyttöliittymän avulla käyttäjä voi: näyttää liikenteen intensiteetin analyysin tulokset; saada välitön ja keskimääräinen tilastollinen arvio verkon suorituskyvystä; asettaa tiettyjä tapahtumia ja kriittisiä tilanteita niiden esiintymisen seuraamiseksi; purkaa eri tasoisia protokollia ja esittää pakettien sisältö ymmärrettävässä muodossa.

Kaappaa puskuri. Eri analysaattoreiden puskurit vaihtelevat tilavuudeltaan. Puskuri voi sijaita asennetussa verkkokortissa tai sille voidaan varata tilaa jonkin verkossa olevan tietokoneen RAM-muistista. Jos puskuri sijaitsee verkkokortilla, sitä ohjataan laitteistolla, ja tämän vuoksi syöttönopeus kasvaa. Tämä johtaa kuitenkin analysaattorin kustannusten nousuun. Jos sieppausmenettelyä ei suoriteta riittävästi, osa tiedoista katoaa ja analysointi on mahdotonta. Puskurin koko määrittää kyvyn analysoida enemmän tai vähemmän edustavia näytteitä kaapatuista tiedoista. Mutta ei väliä kuinka suuri sieppauspuskuri on, ennemmin tai myöhemmin se täyttyy. Tässä tapauksessa joko sieppaus pysähtyy tai täyttö alkaa puskurin alusta.

Suodattimet. Suodattimien avulla voit hallita tietojen talteenottoprosessia ja säästää siten puskuritilaa. Suodatinehtona määritetyn paketin tiettyjen kenttien arvosta riippuen paketti joko ohitetaan tai kirjoitetaan kaappauspuskuriin. Suodattimien käyttö nopeuttaa ja yksinkertaistaa huomattavasti analysointia, koska se sulkee pois tällä hetkellä tarpeettomien pakettien katselun.

Kytkimet ovat operaattorin määrittämiä tiettyjä ehtoja verkon tietojen talteenoton käynnistämiselle ja pysäyttämiselle. Tällaisia ​​ehtoja voivat olla manuaalisten komentojen suorittaminen sieppausprosessin aloittamiseksi ja lopettamiseksi, kellonaika, sieppausprosessin kesto, tiettyjen arvojen ilmestyminen tietokehyksiin. Kytkimiä voidaan käyttää yhdessä suodattimien kanssa, mikä mahdollistaa yksityiskohtaisemman ja hienovaraisemman analyysin sekä rajallisen sieppauspuskurin tehokkaamman käytön.

Hae. Joidenkin protokolla-analysaattoreiden avulla voit automatisoida puskurissa olevien tietojen tarkastelun ja etsiä tietoja siitä määritettyjen kriteerien mukaisesti. Samalla kun suodattimet tarkistavat tulovirran suodattimen olosuhteisiin nähden, hakutoimintoja sovelletaan puskuriin jo kerättyyn dataan.

Analyysimenetelmä voidaan esittää seuraavien kuuden vaiheen muodossa:

Tiedon keräys.

Tarkastele tallennettuja tietoja.

Tietojen analysointi.

Etsi virheitä. (Useimmat jäsentimet helpottavat tätä työtä tunnistamalla virhetyypit ja tunnistamalla aseman, josta virheellinen paketti tuli.)

Suorituskykytutkimus. Verkon kaistanleveyden käyttöaste tai keskimääräinen vastausaika pyyntöön lasketaan.

Yksityiskohtainen tutkimus verkon yksittäisistä osista. Tämän vaiheen sisältö määritellään analyysiä suoritettaessa.

Yleensä protokolla-analyysiprosessi vie suhteellisen vähän aikaa - 1-2 arkipäivää.

Useimmat nykyaikaiset analysaattorit antavat mahdollisuuden analysoida useita WAN-protokollia kerralla, kuten X.25, PPP, SLIP, SDLC/SNA, kehysvälitys, SMDS, ISDN, silta-/reititinprotokollat ​​(3Com, Cisco, Bay Networks ja muut). Tällaisten analysaattoreiden avulla voit mitata erilaisia ​​protokollaparametreja, analysoida verkkoliikennettä, muuntaa LAN- ja WAN-protokollien välillä, viiveitä reitittimissä näiden muunnosten aikana jne. Edistyneemmät laitteet tarjoavat mahdollisuuden simuloida ja purkaa WAN-protokollia, "stressitestausta" ja mittaamaan maksimiarvoja. suorituskyky, tarjottujen palvelujen laadun testaus. Yleisyyden vuoksi lähes kaikki WAN-protokollaanalysaattorit toteuttavat lähiverkon ja kaikkien tärkeimpien liitäntöjen testaustoiminnot. Jotkut laitteet pystyvät analysoimaan puhelinprotokollia. Ja nykyaikaisimmat mallit voivat purkaa ja esittää kaikki seitsemän OSI-kerrosta kätevällä tavalla. ATM:n tulo on saanut valmistajat tarjoamaan analysaattoreilleen keinot näiden verkkojen testaamiseen. Nämä laitteet voivat testata täysin E-1/E-3 ATM-verkkoja valvonta- ja simulointituella. Analysaattorin palvelutoimintojen joukko on erittäin tärkeä. Jotkut niistä, kuten kyky kauko-ohjata laitetta, ovat yksinkertaisesti korvaamattomia.

Siten nykyaikaiset WAN/LAN/DTM-protokollaanalysaattorit voivat havaita virheet reitittimien ja siltojen konfiguraatiossa; aseta globaalin verkon kautta lähetettävän liikenteen tyyppi; määrittää käytetyn nopeusalueen, optimoida kaistanleveyden ja kanavien lukumäärän välisen suhteen; paikallistaa väärän liikenteen lähde; suorittaa sarjaliitännän testaus ja täydellinen ATM-testaus; suorittaa pääprotokollien täysi valvonta ja dekoodaus millä tahansa kanavalla; analysoida reaaliaikaisia ​​tilastoja, mukaan lukien LAN-liikenteen analysointi WAN-verkkojen kautta.

1.1.2 Valvontaprotokollat

SNMP-protokolla (englanniksi Simple Network Management Protocol - yksinkertainen verkonhallintaprotokolla) on TCP/IP-arkkitehtuuriin perustuva protokolla viestintäverkkojen hallintaan.

Perustuu TMN-konseptiin vuosina 1980-1990. eri standardointielimet ovat kehittäneet useita protokollia tietoverkkojen hallintaan, joissa TMN-toimintojen toteutus on erilainen. Yksi tällainen hallintaprotokolla on SNMP. SNMP-protokolla kehitettiin testaamaan verkkoreitittimien ja siltojen toimivuutta. Myöhemmin protokollan soveltamisalaa laajennettiin myös muihin verkkolaitteisiin, kuten keskittimiin, yhdyskäytäviin, päätepalvelimiin, LAN Manager -palvelimiin, Windows NT -koneisiin ja niin edelleen. Lisäksi protokolla antaa mahdollisuuden tehdä muutoksia näiden laitteiden toimintaan.

Tämä tekniikka on suunniteltu tarjoamaan laitteiden ja sovellusten hallintaa ja hallintaa viestintäverkossa vaihtamalla ohjaustietoja verkkolaitteissa olevien agenttien ja ohjausasemilla sijaitsevien johtajien välillä. SNMP määrittelee verkon kokoelmaksi verkonhallintaasemia ja verkkoelementtejä (isännät, yhdyskäytävät ja reitittimet, päätepalvelimet), jotka yhdessä tarjoavat hallinnollista viestintää verkonhallintaasemien ja verkkoagenttien välillä.

SNMP:tä käytettäessä on olemassa hallinta- ja hallintajärjestelmiä. Hallittu järjestelmä sisältää komponentin nimeltä agentti, joka lähettää raportteja hallintajärjestelmään. Pohjimmiltaan SNMP-agentit välittävät hallintatietoja hallintajärjestelmille muuttujina (kuten "vapaa muisti", "järjestelmän nimi", "käytettävissä olevien prosessien lukumäärä").

SNMP-protokollan agentti on prosessointielementti, joka tarjoaa verkonhallinta-asemilla sijaitseville johtajille pääsyn MIB-muuttujien arvoihin ja mahdollistaa siten laitehallinta- ja valvontatoimintojen toteuttamisen.

Ohjelmistoagentti on pysyvä ohjelma, joka suorittaa hallintatoimintoja ja myös kerää tilastoja niiden siirtämistä varten verkkolaitteen tietokantaan.

Hardware agent - sisäänrakennettu laitteisto (prosessorilla ja muistilla), joka tallentaa ohjelmistoagentteja.

SNMP:n kautta käytettävissä olevat muuttujat on järjestetty hierarkiaan. Nämä hierarkiat ja muut metatiedot (kuten muuttujan tyyppi ja kuvaus) kuvataan Management Information Bases (MIB) -tietokannassa.

Nykyään johtamistietokantoille on olemassa useita standardeja. Tärkeimmät ovat MIB-I- ja MIB-II-standardit sekä RMON MIB:n kauko-ohjauksen tietokannan versio. Lisäksi on olemassa standardeja tietyntyyppisille erikoislaitteiden MIB:ille (esimerkiksi MIB:ille keskittimelle tai MIB:lle modeemille) sekä tiettyjen laitevalmistajien yksityisille MIB:ille.

Alkuperäinen MIB-I-spesifikaatio määritteli toiminnot vain muuttujien arvojen lukemiseen. Kohdearvojen muuttaminen tai asettaminen on osa MIB-II-spesifikaatioita.

MIB-I-versio (RFC 1156) määrittelee jopa 114 objektia, jotka on jaettu 8 ryhmään:

Järjestelmä - yleiset tiedot laitteesta (esimerkiksi toimittajan tunnus, viimeinen järjestelmän alustusaika).

Liitännät - kuvaa laitteen verkkoliitäntöjen parametrit (esimerkiksi niiden lukumäärä, tyypit, valuuttakurssit, pakettien enimmäiskoko).

AddressTranslationTable - kuvaa verkon ja fyysisten osoitteiden välistä vastaavuutta (esimerkiksi ARP-protokollan kautta).

InternetProtocol - IP-protokollaan liittyvät tiedot (IP-yhdyskäytävien osoitteet, isännät, IP-pakettien tilastot).

ICMP - ICMP-ohjaussanomien vaihtoprotokollaan liittyvät tiedot.

TCP - TCP-protokollaan liittyvät tiedot (esimerkiksi TCP-yhteyksistä).

UDP - UDP-protokollaan liittyvät tiedot (lähetettyjen, vastaanotettujen ja virheellisten UPD-datagrammien määrä).

EGP - Internetissä käytettävään ExteriorGatewayProtocolin liittyvät tiedot (virheellisesti ja virheettömästi vastaanotettujen viestien määrä).

Tästä muuttujaryhmien luettelosta voidaan nähdä, että MIB-I-standardi kehitettiin keskittyen voimakkaasti TCP/IP-pinon protokollia tukevien reitittimien hallintaan.

MIB-II:n versiossa (RFC 1213), joka hyväksyttiin vuonna 1992, standardiobjektien joukkoa laajennettiin merkittävästi (jopa 185) ja ryhmien lukumäärä kasvoi 10:een.

RMON-agentit

Viimeisin lisäys SNMP-toimintoihin on RMON-spesifikaatio, joka tarjoaa etäyhteyden MIB:n kanssa.

RMON-standardi syntyi marraskuussa 1991, kun Internet Engineering Task Force julkaisi RFC 1271:n nimeltä "Remote Network Monitoring Management Information Base". Tämä asiakirja sisälsi kuvauksen RMON:sta Ethernet-verkkoihin - protokolla tietokoneverkkojen valvontaan, SNMP:n laajennus, joka, kuten SNMP, perustuu tiedon keräämiseen ja analysointiin verkon kautta välitettävien tietojen luonteesta. Kuten SNMP:ssä, laitteisto- ja ohjelmistoagentit keräävät tietoja, joiden tiedot lähetetään tietokoneelle, johon verkonhallintasovellus on asennettu. Ero RMON:n ja sen edeltäjän välillä on ennen kaikkea kerättyjen tietojen luonteessa - jos SNMP:ssä tämä tieto luonnehtii vain tapahtumia, jotka tapahtuvat laitteessa, johon agentti on asennettu, niin RMON edellyttää, että vastaanotettu data luonnehtii verkkojen välistä liikennettä. laitteet.

Ennen RMONin tuloa SNMP:tä ei voitu käyttää etänä, se salli vain paikallisen laitehallinnan. RMON MIB:ssä on parannetut ominaisuudet etähallintaa varten, koska se sisältää koottua tietoa laitteesta, mikä ei vaadi suuria tietomääriä siirrettäväksi verkon yli. RMON MIB -objekteihin kuuluu ylimääräisiä pakettivirhelaskureita, joustavampi graafinen trendi- ja tilastoanalyysi, tehokkaammat suodatustyökalut yksittäisten pakettien sieppaamiseen ja analysointiin sekä kehittyneemmät hälytysolosuhteet. RMON MIB-agentit ovat älykkäämpiä kuin MIB-I- tai MIB-II-agentit ja suorittavat suuren osan laitetietojen käsittelystä, jota johtajat tekivät ennen. Nämä agentit voivat sijaita erilaisten viestintälaitteiden sisällä sekä toteuttaa erillisinä ohjelmistomoduuleina, jotka toimivat yleistietokoneissa ja kannettavissa tietokoneissa (LANalyzerНvell voi toimia esimerkkinä).

RMON-agenttien älykkyyden ansiosta he voivat suorittaa yksinkertaisia ​​vianetsintä- ja varoitustoimenpiteitä - esimerkiksi RMON-tekniikan puitteissa voit kerätä tietoja verkon normaalista toiminnasta (ts. suorittaa ns. perustason) ja antaa sitten tietoja. varoitussignaaleja, kun verkon toimintatila poikkeaa perustilasta - tämä voi olla merkki erityisesti siitä, että laite ei ole täysin toimintakunnossa. RMON-agenttien tiedot keräämällä hallintasovellus voi auttaa verkonvalvojaa (esimerkiksi tuhansien kilometrien päässä) paikantamaan ongelman ja kehittämään parhaan toimintasuunnitelman sen ratkaisemiseksi.

RMON-tiedot kerätään suoraan verkkoon kytketyillä laitteisto- ja ohjelmistotunnistimilla. Suorittaakseen tiedonkeruun ja ensisijaisen data-analyysin koettimella on oltava riittävät laskentaresurssit ja RAM. Tällä hetkellä markkinoilla on kolmen tyyppisiä antureita: sisäänrakennetut anturit, tietokonepohjaiset anturit ja erilliset anturit. Tuotteen katsotaan olevan RMON-yhteensopiva, jos se toteuttaa vähintään yhden RMON-ryhmän. Tietysti mitä enemmän RMON-tietoryhmiä on toteutettu tietyssä tuotteessa, sitä kalliimpaa se toisaalta on ja toisaalta sitä kattavampaa tietoa verkon toiminnasta se tarjoaa.

Sulautetut anturit ovat laajennusmoduuleja verkkolaitteille. Tällaisia ​​moduuleja valmistavat monet valmistajat, erityisesti sellaiset suuret yritykset kuin 3Com, Cabletron, Bay Networks ja Cisco. (Muuten, 3Com ja Bay Networks ostivat äskettäin Axonin ja ARMONin, tunnustetut johtajat RMON-hallintatyökalujen suunnittelussa ja valmistuksessa. Suurien verkkolaitteiden valmistajien kiinnostus tätä tekniikkaa kohtaan osoittaa jälleen kerran, kuinka tarpeellista etävalvonta on käyttäjille.) Suurin osa päätöksestä RMON-moduulien upottaminen keskittimiin vaikuttaa luonnolliselta, koska juuri näitä laitteita tarkkailemalla saa käsityksen segmentin toiminnasta. Tällaisten koettimien etu on ilmeinen: ne mahdollistavat tiedon saamisen kaikista tärkeimmistä RMON-tietoryhmistä suhteellisen alhaisella hinnalla. Ensinnäkin haittana ei ole liian korkea suorituskyky, mikä ilmenee erityisesti siinä, että sisäänrakennetut anturit tukevat usein kaukana kaikkia RMON-tietoryhmiä. Ei kauan sitten 3Com ilmoitti aikovansa julkaista RMON-yhteensopivia ajureita Etherlink III- ja Fast Ethernet -verkkosovittimille. Tuloksena on mahdollista kerätä ja analysoida RMON-tietoja suoraan verkon työasemilta.

Tietokonepohjaiset anturit ovat yksinkertaisesti verkkoon kytkettyjä tietokoneita, joihin on asennettu RMON-ohjelmistoagentti. Nämä anturit (kuten Network Generalin Cornerstone Agent 2.5) ovat nopeampia kuin sisäänrakennetut anturit ja tukevat yleensä kaikkia RMON-tietoryhmiä. Ne ovat kalliimpia kuin sisäänrakennetut anturit, mutta paljon halvempia kuin erilliset anturit. Lisäksi tietokonepohjaiset anturit ovat melko suuria, mikä voi joskus rajoittaa niiden käyttöä.

Erillisillä antureilla on paras suorituskyky; Kuten on helppo ymmärtää, nämä ovat samalla kalleimpia kuvatuista tuotteista. Tyypillisesti erillinen anturi on prosessori (i486-luokan tai RISC-suoritin), joka on varustettu riittävällä RAM-muistilla ja verkkosovittimella. Tämän markkinasektorin johtajia ovat Frontier ja Hewlett-Packard. Tämän tyyppiset anturit ovat kooltaan pieniä ja erittäin liikkuvia - ne on erittäin helppo yhdistää verkkoon ja irrottaa siitä. Maailmanlaajuista verkonhallintaongelmaa ratkaistaessa tämä ei tietenkään ole kovin tärkeä ominaisuus, mutta jos RMON-työkaluilla analysoidaan keskikokoisen yritysverkon toimintaa, niin (kun otetaan huomioon laitteiden korkeat kustannukset), anturin liikkuvuus. voi olla erittäin positiivinen rooli.

RMON-objektille on annettu numero 16 MIB-objektijoukossa, ja itse RMON-objekti on aggregoitu RFC 1271:n mukaisesti, koostuu kymmenestä tietoryhmästä.

Tilastot - nykyiset kertyneet tilastot pakettien ominaisuuksista, törmäysten määrästä jne.

Historia - tilastotiedot, jotka tallennetaan tietyin väliajoin niiden muutosten suuntausten myöhempää analysointia varten.

Hälytykset - tilastolliset kynnysarvot, joiden ylittyessä RMON-agentti lähettää viestin johtajalle. Antaa käyttäjän määrittää useita kynnystasoja (nämä kynnysarvot voivat viitata useisiin eri asioihin - mihin tahansa tilastoryhmän parametriin, sen muutoksen amplitudiin tai vauhtiin ja paljon muuta), joiden ylittyessä syntyy hälytys. Käyttäjä voi myös määrittää, missä olosuhteissa kynnysarvon ylitykseen tulee liittyä hälytyssignaali - näin vältytään "turhaan" -signaalin syntymiseltä, mikä on huono ensinnäkin, koska kukaan ei kiinnitä huomiota jatkuvasti palavaan. punainen valo, ja toiseksi, koska tarpeettomien hälytysten lähettäminen verkon yli kuormittaa tarpeettomasti viestintälinjoja. Hälytys välitetään yleensä tapahtumaryhmään, jossa päätetään, mitä sille tehdään seuraavaksi.

Isäntä - tiedot verkon isännistä, mukaan lukien niiden MAC-osoitteet.

HostTopN - taulukko verkon vilkkaimmista isännistä. Taulukko N ​​suosituimmat isännät (HostTopN) sisältää luettelon N suosituimmista isännistä, joille on tunnusomaista tietyn tilastollisen parametrin enimmäisarvo tietyllä aikavälillä. Voit esimerkiksi pyytää luettelon 10 isännästä, jotka ovat kokeneet eniten virheitä viimeisen 24 tunnin aikana. Tämän luettelon laatii agentti itse, ja hallintasovellus vastaanottaa vain näiden isäntien osoitteet ja vastaavien tilastollisten parametrien arvot. On nähtävissä, missä määrin tämä lähestymistapa säästää verkkoresursseja.

TrafficMatrix - tilastot liikenteen intensiteetistä kunkin verkkoisäntäparin välillä, järjestetty matriisin muodossa. Tämän matriisin rivit on numeroitu viestilähteinä olevien asemien MAC-osoitteiden mukaisesti ja sarakkeet numeroitu vastaanottavien asemien osoitteiden mukaisesti. Matriisielementit karakterisoivat vastaavien asemien välisen liikenteen voimakkuutta ja virheiden määrää. Tällaisen matriisin analysoinnin jälkeen käyttäjä voi helposti selvittää, mitkä asemaparit tuottavat voimakkainta liikennettä. Tämän matriisin taas muodostaa agentti itse, joten suuria tietomääriä ei tarvitse siirtää verkon hallinnasta vastaavalle keskustietokoneelle.

Suodatin - pakettisuodatusehdot. Pakettien suodatuskriteerit voivat olla hyvin erilaisia ​​- voit esimerkiksi vaatia suodattamaan virheellisiksi kaikki paketit, joiden pituus on pienempi kuin jokin määritetty arvo. Voimme sanoa, että suodattimen asennus vastaa ikään kuin kanavan järjestämistä paketin lähettämiseksi. Mihin tämä kanava johtaa, sen määrittää käyttäjä. Esimerkiksi kaikki virheelliset paketit voidaan siepata ja lähettää sopivaan puskuriin. Lisäksi asetettua suodatinta vastaavan paketin ilmestymistä voidaan pitää tapahtumana (tapahtumana), johon järjestelmän on reagoitava ennalta määrätyllä tavalla.

PacketCapture - ehdot pakettien sieppaamiseen. Pakettien sieppausryhmä sisältää sieppauspuskurit, joihin lähetetään paketteja, joiden ominaisuudet täyttävät suodatinryhmässä määritellyt ehdot. Tällöin ei saa kaapata koko pakettia, vaan vaikkapa paketin ensimmäiset kymmenet tavut. Sieppauspuskurien sisältöä voidaan myöhemmin analysoida käyttämällä erilaisia ​​ohjelmistotyökaluja, mikä paljastaa useita erittäin hyödyllisiä verkon ominaisuuksia. Järjestämällä suodattimet uudelleen tiettyjä merkkejä varten on mahdollista karakterisoida verkon toiminnan erilaisia ​​parametreja.

Tapahtuma - edellytykset tapahtumien rekisteröinnille ja luomiselle. Tapahtumaryhmässä (tapahtumat) määritetään milloin hallintasovellukselle tulee lähettää hälytys, milloin - siepata paketteja ja yleensä - miten reagoida tiettyihin verkossa tapahtuviin tapahtumiin, esimerkiksi kynnyksen ylittymiseen. Hälytysryhmässä määritetyt arvot: asetetaanko hallintasovelluksen tietoon vai täytyy vain kirjata tämä tapahtuma ja jatkaa työtä. Tapahtumat voivat liittyä tai olla liittymättä hälytysten lähettämiseen - esimerkiksi paketin lähettäminen kaappauspuskuriin on myös tapahtuma.

Nämä ryhmät on numeroitu tässä järjestyksessä, joten esimerkiksi Hosts-ryhmän numeerinen nimi on 1.3.6.1.2.1.16.4.

Kymmenes ryhmä koostuu TokenRing-protokollan erikoisobjekteista.

Yhteensä RMON MIB -standardi määrittelee noin 200 kohdetta 10 ryhmään, jotka on kiinnitetty kahteen asiakirjaan - RFC 1271 Ethernet-verkkoihin ja RFC 1513 TokenRing-verkkoihin.

RMON MIB -standardin erottuva piirre on sen riippumattomuus verkkokerroksen protokollasta (toisin kuin MIB-I- ja MIB-II-standardit, jotka ovat suuntautuneet TCP/IP-protokolliin). Siksi sitä on kätevää käyttää heterogeenisissä ympäristöissä eri verkkokerroksen protokollia käyttäen.

1.2 Suositut verkonhallintajärjestelmät

Verkonhallintajärjestelmä - laitteisto- ja/tai ohjelmistotyökalut verkkosolmujen valvontaan ja hallintaan. Verkonhallintajärjestelmäohjelmisto koostuu agenteista, jotka on lokalisoitu verkkolaitteille ja jotka välittävät tietoa verkonhallintaalustaan. Tietojen vaihtotapa ohjaussovellusten ja laitteissa olevien agenttien välillä on määritelty protokollilla.

Verkonhallintajärjestelmillä on oltava useita ominaisuuksia:

todellinen jakelu asiakas/palvelin-konseptin mukaan,

skaalautuvuus

avoimuus selviytyä heterogeenisistä laitteista pöytätietokoneista keskuskoneisiin.

Kaksi ensimmäistä ominaisuutta liittyvät läheisesti toisiinsa. Hyvä skaalautuvuus saavutetaan ohjausjärjestelmän hajautuksen ansiosta. Hajautettu tarkoittaa, että järjestelmä voi sisältää useita palvelimia ja asiakkaita. Palvelimet (managerit) keräävät tietoa verkon nykytilasta verkkolaitteistoon sisäänrakennetuilta agenteilta (SNMP, CMIP tai RMON) ja keräävät sen tietokantaansa. Asiakkaat ovat verkonvalvojien käyttämiä graafisia konsoleita. Ohjausjärjestelmän asiakasohjelmisto vastaanottaa pyynnöt minkä tahansa toimenpiteen suorittamisesta järjestelmänvalvojalta (esimerkiksi yksityiskohtaisen kartan rakentaminen jostakin verkon osasta) ja pyytää tarvittavat tiedot palvelimelta. Jos palvelimella on tarvittavat tiedot, se siirtää ne välittömästi asiakkaalle, jos ei, niin se yrittää kerätä ne agenteilta.

Hallintajärjestelmien varhaiset versiot yhdistivät kaikki toiminnot yhteen tietokoneeseen, jota järjestelmänvalvoja käytti. Pienille verkoille tai verkoille, joissa on pieni määrä hallittuja laitteita, tämä rakenne osoittautuu varsin tyydyttäväksi, mutta suurella määrällä hallittuja laitteita, yksi tietokone, johon tieto virtaa kaikista verkon laitteista, tulee pullonkaulaksi. Ja verkko ei pysty selviytymään suuresta tietovirrasta, eikä tietokoneella itsellään ole aikaa käsitellä niitä. Lisäksi isoa verkkoa hallitsee yleensä useampi kuin yksi järjestelmänvalvoja, joten suuressa verkossa pitäisi olla useiden palvelimien lisäksi useita konsoleita, joiden takana verkonvalvojat työskentelevät, ja jokaisessa konsolissa tulee esitellä tietyt tiedot, jotka vastaavat tämänhetkisiä tarpeita. tietyltä järjestelmänvalvojalta.

Heterogeenisten laitteiden tuki on nykypäivän ohjausjärjestelmissä enemmän toive kuin todellisuus. Neljä suosituinta verkonhallintatuotetta ovat Cabletron Systemsin Spectrum, Hewlett-Packardin OpenView, IBM:n NetView ja SunSoftin Solstice, SunMicrosystemsin divisioona. Kolme neljästä yrityksestä valmistaa itse viestintälaitteita. Luonnollisesti Spectrum toimii parhaiten Cabletron-laitteiden kanssa, OpenView Hewlett-Packardin laitteiden kanssa ja NetView IBM-laitteiden kanssa.

Kun rakennetaan muiden valmistajien laitteista koostuvaa verkkokarttaa, nämä järjestelmät alkavat tehdä virheitä ja ottamaan laitteita toiseen, ja näitä laitteita hallittaessa ne tukevat vain niiden päätoimintoja ja monia hyödyllisiä lisätoimintoja, jotka erottavat tämän laitteen levätä, ohjausjärjestelmä on yksinkertainen ei ymmärrä eikä siksi voi käyttää niitä.

Tämän puutteen korjaamiseksi ohjausjärjestelmien kehittäjät tukevat standardien MIB I:n, MIB II:n ja RMON MIB:n lisäksi myös lukuisia valmistusyritysten omistamia MIB:itä. Johtava tällä alueella on Spectrum-järjestelmä, joka tukee noin 1000 MIB:tä eri valmistajilta.

Toinen tapa tukea paremmin tiettyä laitetta on käyttää laitetta valmistavan yrityksen sovellusta, joka perustuu johonkin ohjausalustaan. Johtavat yritykset - viestintälaitteiden valmistajat - ovat kehittäneet ja toimittaneet erittäin monimutkaisia ​​ja monitoimisia ohjausjärjestelmiä laitteilleen. Tämän luokan tunnetuimpia järjestelmiä ovat BayNetworksin Optiivity, CiscoSystemsin CiscoWorks ja 3Comin Transcend. Optiivity-järjestelmän avulla voit esimerkiksi valvoa ja hallita BayNetwork-reitittimistä, kytkimistä ja keskittimistä koostuvia verkkoja hyödyntäen niiden kaikkia ominaisuuksia ja ominaisuuksia. Muiden valmistajien laitteita tuetaan perusohjaustoimintojen tasolla. Optiivity-järjestelmä toimii Hewlett-Packardin OpenView- ja SunSoftin SunNetManager-alustoilla (Solsticen edeltäjä). Minkä tahansa usean järjestelmän ohjausalustan, kuten Optiivityn, käyttäminen on kuitenkin liian monimutkaista ja vaatii sitä kaikkia käyttävillä tietokoneilla erittäin tehokkaita prosessoreita ja paljon RAM-muistia.

Kuitenkin, jos verkkoa hallitsevat yhden valmistajan laitteet, kyseisen valmistajan hallintasovellukset suosittuun hallintaalustaan ​​mahdollistavat verkon järjestelmänvalvojien suorittaa monia tehtäviä onnistuneesti. Siksi hallintaalustojen kehittäjät toimittavat mukanaan työkaluja, jotka helpottavat sovellusten kehittämistä, ja tällaisten sovellusten saatavuus ja määrä katsotaan erittäin tärkeäksi tekijäksi hallintaalustaa valittaessa.

Hallintaalustan avoimuus riippuu myös siitä, missä muodossa verkon tilasta kerätyt tiedot tallennetaan. Useimmat johtavat alustat mahdollistavat tietojen tallentamisen kaupallisiin tietokantoihin, kuten Oracle, Ingres tai Informix. Yleisen DBMS:n käyttö vähentää ohjausjärjestelmän nopeutta verrattuna tietojen tallentamiseen käyttöjärjestelmän tiedostoihin, mutta se mahdollistaa näiden tietojen käsittelyn kaikilla sovelluksilla, jotka voivat toimia näiden DBMS-järjestelmien kanssa.

2. ONGELMAN TOTEAMINEN

Vallitsevan tilanteen mukaisesti päätettiin kehittää ja ottaa käyttöön verkonvalvontajärjestelmä, joka ratkaisisi kaikki edellä mainitut ongelmat.

2.1 Tehtäväehdot

Kehitä ja ota käyttöön valvontajärjestelmä, joka mahdollistaa sekä kytkimien, eri valmistajien reitittimien että eri alustojen palvelimien valvonnan. Keskity avoimien protokollien ja järjestelmien käyttöön hyödyntäen maksimaalisesti ilmaisten ohjelmistojen rahaston valmiita kehityshankkeita.

2.2 Tarkennettu toimeksianto

Ongelman jatkomuotoilun ja aihealueen tutkimuksen yhteydessä taloudelliset ja aikainvestoinnit huomioon ottaen suoritettiin toimeksiannon tarkentaminen:

Järjestelmän tulee täyttää seuraavat vaatimukset:

§ laitteistoresurssien vähimmäisvaatimukset;

§ kompleksin kaikkien komponenttien avoimet lähdekoodit;

§ järjestelmän laajennettavuus ja skaalautuvuus;

§ standardikeinot diagnostisten tietojen tarjoamiseksi;

§ kaikkien käytettyjen ohjelmistotuotteiden yksityiskohtaisen dokumentaation saatavuus;

§ Kyky työskennellä eri valmistajien laitteiden kanssa.

3. EHDOTETTU JÄRJESTELMÄ

1 Verkonvalvontajärjestelmän valinta

Uudistetun toimeksiannon mukaan Nagios-järjestelmä soveltuu parhaiten verkonvalvontajärjestelmän ytimeksi, koska sillä on seuraavat ominaisuudet:

§ on olemassa keinoja luoda kaavioita;

§ on olemassa keinoja raporttien luomiseen;

§ looginen ryhmittely on mahdollista;

§ on sisäänrakennettu järjestelmä trendien tallentamiseen ja niiden ennustamiseen;

§ on mahdollista lisätä automaattisesti uusia laitteita (Autodiscovery) käyttämällä virallista laajennusta;

§ on mahdollisuus isännän edistyneeseen seurantaan agentin avulla;

§ tuki SNMP-protokollalle laajennuksen kautta;

§ Syslog-protokollan tuki laajennuksen kautta;

§ tuki ulkoisille skripteille;

§ tuki itse kirjoitetuille laajennuksille ja kyky luoda niitä nopeasti ja helposti;

§ sisäänrakennetut laukaisimet ja tapahtumat;

§ monipuolinen verkkokäyttöliittymä;

§ hajautetun seurannan mahdollisuus;

§ inventaario laajennuksen kautta;

§ kyky tallentaa tietoja sekä tiedostoihin että SQL-tietokantoihin, mikä on erittäin tärkeää määriä kasvatettaessa;

§ GPL-lisenssi, ja siksi ilmainen perusjakelu, tuki ja järjestelmäytimen ja siihen liittyvien komponenttien avoimet lähdekoodit;

§ dynaamiset ja mukautettavat kartat;

§ kulunvalvonta;

§ sisäänrakennettu kieli isäntien, palvelujen ja tarkistusten kuvaamiseen;

§ kyky seurata käyttäjiä.

Zabbix-verkonvalvontajärjestelmässä on samanlainen parametrijoukko, mutta toteutushetkellä siinä oli paljon vähemmän toimintoja kuin Nagios ja se oli beta-version tila. Lisäksi temaattisten foorumien ja uutissyötteiden tutkimus osoitti suurimman levinneisyyden Nagios-käyttäjien keskuudessa, mikä tarkoittaa käyttäjien kirjoittaman dokumentaation läsnäoloa ja yksityiskohtaisinta kuvausta konfiguroinnin vaikeista hetkistä.

Nagios antaa sinun seurata verkkopalveluita, kuten SMTP, TELNET, SSH, HTTP, DNS, POP3, IMAP, NNTP ja monia muita. Lisäksi voit valvoa palvelinresurssien käyttöä, kuten levytilan kulutusta, vapaata muistia ja prosessorin kuormitusta. On mahdollista luoda omia tapahtumakäsittelijöitä. Nämä käsittelijät suoritetaan, kun palvelu- tai palvelintarkistukset laukaisevat tietyt tapahtumat. Tämän lähestymistavan avulla voit reagoida aktiivisesti meneillään oleviin tapahtumiin ja yrittää ratkaista ilmenneet ongelmat automaattisesti. Voit esimerkiksi luoda tapahtumakäsittelijän, joka käynnistää ripustetun palvelun automaattisesti uudelleen. Toinen Nagios-valvontajärjestelmän etu on kyky ohjata sitä etänä matkapuhelimen wap-liittymän avulla. Käyttämällä käsitettä "emoisännät" on helppo kuvata kaikkien isäntien välistä hierarkiaa ja riippuvuuksia. Tämä lähestymistapa on erittäin hyödyllinen suurille verkoille, koska se mahdollistaa monimutkaisen diagnosoinnin. Ja tämä laatu puolestaan ​​​​auttaa erottamaan toimimattomat isännät niistä, joita ei tällä hetkellä ole saatavana välilinkkien toimintahäiriöiden vuoksi. Nagios pystyy rakentamaan kaavioita valvotuista järjestelmistä ja karttoja valvotusta verkkoinfrastruktuurista.

Nagioksen kanssa työskentelystään saadun kokemuksen perusteella kirjoittaja voi antaa esimerkin, joka osoittaa, kuinka hyödyllistä se on ollut hänen henkilökohtaiselle toiminnalleen. Palomuurin ulkoinen verkkoliitäntä alkoi menettää paketteja muutaman tunnin välein. Vian vuoksi jopa 20 prosenttia ohikulkevasta liikenteestä menetettiin. Hetken kuluttua toinen käyttöliittymä alkoi taas toimia odotetusti. Ongelman ajoittaisesta luonteesta johtuen useaan viikkoon ei ollut mahdollista saada selville, miksi Internetin käytössä ilmenee ajoittaisia ​​ajoittaisia ​​vikoja. Ilman Nagiosta vianetsintä kestäisi kauan.

Monet järjestelmänvalvojat tuntevat Nagiosin esi-isän NetSaint. Vaikka NetSaint-projektisivusto toimii edelleen kunnolla, uudet kehitystyöt perustuvat jo Nagios-lähdekoodiin. Siksi on suositeltavaa, että kaikki muuttavat hitaasti Nagiosiin.

Nagiosin mukana tuleva dokumentaatio sanoo, että se toimii hyvin myös monien muiden Unix-tyyppisten järjestelmien kanssa. Tarvitsemme Apache-palvelimen näyttääksemme Nagios-verkkokäyttöliittymän. Voit vapaasti käyttää mitä tahansa muuta, mutta tässä työssä Apachea pidetään yleisimpana verkkopalvelimena Unix-alustoilla. Voit asentaa valvontajärjestelmän ilman verkkokäyttöliittymää, mutta emme tee sitä, koska se heikentää merkittävästi käytettävyyttä.

4. OHJELMISTON KEHITTÄMINEN

Toteutetun järjestelmän laitteisto-osana voidaan käyttää tavallista IBM-yhteensopivaa tietokonetta, mutta ottaen huomioon mahdollisuus lisätä kuormitusta edelleen sekä luotettavuus- ja MTBF-vaatimukset sekä GosSvyazNadzor, ostettiin Aquariukselta sertifioituja palvelinlaitteita. .

Olemassa oleva verkko käyttää aktiivisesti Linux-ytimeen perustuvaa Debian-käyttöjärjestelmää, tämän järjestelmän käytöstä on laaja kokemus, useimmat sen hallinnan, konfiguroinnin ja vakauden varmistamisen toiminnot on debuggoitu. Lisäksi tätä käyttöjärjestelmää jaetaan GPL-lisenssillä, joka ilmaisee sen ilmaiset ja avoimet lähdekoodit, mikä vastaa päivitettyjä verkonvalvontajärjestelmän suunnittelun ehtoja (koko nimi on GNU / Linux, lausutaan "gnu slash" ́ Nux, myös joissain kielissä GNU+Linux, GNU-Linux jne.) on yleinen nimi UNIX-tyyppisille käyttöjärjestelmille, jotka perustuvat samannimiseen ytimeen ja sitä varten käännetyihin kirjastoihin ja järjestelmäohjelmiin, jotka on kehitetty osana GNU-projekti./ Linux toimii PC-yhteensopivissa järjestelmissä Intel x86 -perheestä, sekä IA-64, AMD64, PowerPC, ARM ja monet muut.

GNU/Linux-käyttöjärjestelmä sisältää usein myös ohjelmia, jotka täydentävät tätä käyttöjärjestelmää, ja sovellusohjelmia, jotka tekevät siitä täysimittaisen monitoimisen käyttöympäristön.

Toisin kuin useimmat muut käyttöjärjestelmät, GNU/Linux ei sisällä yhtä "virallista" pakettia. Sen sijaan GNU/Linux tulee suuressa määrässä niin sanottuja jakeluja, jotka yhdistävät GNU-ohjelmat Linux-ytimeen ja muihin ohjelmiin. Tunnetuimmat GNU/Linux-jakelut ovat Ubuntu, Debian GNU/Linux, Red Hat, Fedora, Mandriva, SuSE, Gentoo, Slackware, Archlinux. Venäläiset jakelut - ALT Linux ja ASPLinux.

Toisin kuin Microsoft Windows (Windows NT), Mac OS (Mac OS X) ja kaupalliset UNIX-tyyppiset järjestelmät, GNU/Linuxilla ei ole maantieteellistä kehityskeskusta. Ei ole organisaatiota, joka omistaa tämän järjestelmän; ei ole edes yhtä koordinointikeskusta. Linux-ohjelmat ovat tuhansien projektien tulosta. Osa näistä hankkeista on keskitetty, osa on keskittynyt yrityksiin. Monet projektit tuovat yhteen hakkereita kaikkialta maailmasta, jotka tuntevat toisensa vain kirjeenvaihdosta. Kuka tahansa voi luoda oman projektin tai liittyä olemassa olevaan, ja onnistuessaan työn tulokset tulevat miljoonien käyttäjien tiedoksi. Käyttäjät osallistuvat ilmaisten ohjelmistojen testaamiseen, kommunikoivat suoraan kehittäjien kanssa, jolloin he voivat nopeasti löytää ja korjata vikoja ja ottaa käyttöön uusia ominaisuuksia.

UNIX-järjestelmien kehityshistoria. GNU/Linux on UNIX-yhteensopiva, mutta perustuu omaan lähdekoodiinsa

Juuri tämä joustava ja dynaaminen kehitysjärjestelmä, joka on mahdoton suljetun lähdekoodin projekteissa, määrittää [lähdettä ei ole määritelty 199 päivää] GNU/Linuxin poikkeuksellisen kustannustehokkuuden. Ilmaisen kehityksen alhaiset kustannukset, vakiintuneet testaus- ja jakelumekanismit, eri maiden ihmisten osallistuminen erilaisiin näkemyksiin ongelmista, koodin suojaus GPL-lisenssillä - kaikki tämä on tullut syyksi ilmaisten ohjelmistojen menestykselle .

Tällainen korkea kehitystehokkuus ei tietenkään voinut olla kiinnostamatta suuria yrityksiä, jotka alkoivat avata projektejaan. Näin Mozilla (Netscape, AOL), OpenOffice.org (Sun), Interbasen (Borland) ilmainen klooni - Firebird, SAP DB (SAP) ilmestyivät. IBM helpotti GNU/Linuxin siirtämistä keskuskoneisiinsa.

Toisaalta avoin lähdekoodi vähentää merkittävästi GNU/Linuxin suljettujen järjestelmien kehittämiskustannuksia ja alentaa ratkaisun hintaa käyttäjälle. Tästä syystä GNU/Linuxista on tullut alusta, jota usein suositellaan tuotteille, kuten Oracle, DB2, Informix, SyBase, SAP R3, Domino.

GNU/Linux-yhteisö kommunikoi Linux-käyttäjäryhmien kautta.

Useimmat käyttäjät käyttävät jakeluja GNU/Linuxin asentamiseen. Jakelupaketti ei ole vain joukko ohjelmia, vaan useita ratkaisuja erilaisiin käyttäjätehtäviin, joita yhdistävät yhteiset pakettien asennus-, hallinta- ja päivitysjärjestelmät, konfigurointi ja tuki.

Yleisimmät jakelut maailmassa: - Nopeasti kasvava jakelu, joka keskittyy helppoon oppimiseen ja käyttöön - Ilmainen versio SuSE-jakelusta, jonka omistaa Novell. Helppo asentaa ja ylläpitää YaST-apuohjelman avulla. - Yhteisön ja RedHat-yhtiön tukema, edeltää RHEL:n kaupallisen version julkaisua GNU / Linux - laajan kehittäjäyhteisön kehittämä kansainvälinen jakelupaketti ei-kaupalliseen käyttöön tarkoituksiin. Toiminut perustana monien muiden jakelujen luomiselle. Sille on tunnusomaista tiukka lähestymistapa ei-vapaiden ohjelmistojen sisällyttämiseen - Ranskalais-brasilialainen jakelu, entisten Mandraken ja Conectivan (englanniksi) yhdistelmä - Yksi vanhimmista jakeluista, se erottuu konservatiivisesta lähestymistavasta kehittäminen ja käyttö - Lähdekoodeista koottu jakelupaketti. Mahdollistaa erittäin joustavan loppujärjestelmän mukauttamisen ja suorituskyvyn optimoinnin, minkä vuoksi se usein kutsuu itseään meta-jakeluksi. Keskittynyt asiantuntijoihin ja edistyneisiin käyttäjiin. - Keskittyy uusimpiin ohjelmistoversioihin ja päivitetään jatkuvasti, tukee yhtäläisesti sekä binääri- että lähdeasennuksia ja perustuu KISS-yksinkertaisuuden filosofiaan. Tämä jakelu on suunnattu päteville käyttäjille, jotka haluavat saada kaiken tehon ja muunnettavuuden. Linuxista, mutta ylläpitoaikaa ei uhrata.

Listattujen lisäksi on monia muita jakeluita, jotka molemmat perustuvat lueteltuihin ja jotka on luotu tyhjästä ja jotka on usein suunniteltu suorittamaan rajoitettu määrä tehtäviä.

Jokaisella niistä on oma konseptinsa, omat pakettinsa, omat etunsa ja haittansa. Yksikään niistä ei voi tyydyttää kaikkia käyttäjiä, ja siksi johtajien rinnalla on muitakin yrityksiä ja ohjelmoijayhdistyksiä, jotka tarjoavat ratkaisujaan, jakeluaan, palveluitaan. GNU/Linuxin päälle on rakennettu monia LiveCD-levyjä, kuten Knoppix. LiveCD:llä voit käyttää GNU/Linuxia suoraan CD-levyltä asentamatta sitä kiintolevyllesi.

Niille, jotka haluavat ymmärtää GNU / Linuxin perusteellisesti, mikä tahansa jakelu sopii, mutta melko usein tähän tarkoitukseen käytetään ns. lähdepohjaisia ​​jakeluja, eli niihin liittyy kaikkien (tai osien) itsekokoonpano. lähdekoodien komponentit, kuten LFS, Gentoo, ArchLinux tai CRUX.

4.1 Järjestelmäytimen asennus

Nagios voidaan asentaa kahdella tavalla - lähteistä ja rakennetuista paketeista. Molemmilla tavoilla on etuja ja haittoja, harkitse niitä.

Lähdepaketin asennuksen edut:

§ mahdollisuus järjestelmän yksityiskohtaiseen konfigurointiin;

§ korkea sovellusoptimointiaste;

§ ohjelman täydellisin esitys.

Niiden lähdepaketin asennuksen haitat:

§ Paketin kokoamiseen tarvitaan lisäaikaa, joka usein ylittää sen määrittämiseen ja virheenkorjaukseen kuluvan ajan;

§ kyvyttömyys poistaa pakettia yhdessä asetustiedostojen kanssa;

§ kyvyttömyys päivittää pakettia asetustiedostojen kanssa;

§ asennettujen sovellusten keskitetyn hallinnan mahdottomuus.

Kun asennat Nagios valmiiksi rakennetusta paketista, raaka-asennuksen eduista tulee haittoja ja päinvastoin. Kuitenkin, kuten käytäntö on osoittanut, valmiiksi rakennettu paketti täyttää kaikki järjestelmälle asetetut vaatimukset, eikä ole mitään järkeä tuhlata aikaa paketin manuaaliseen rakentamiseen.

Koska molemmat asennustavat testattiin alun perin, tarkastelemme kutakin niistä yksityiskohtaisemmin.

4.1.1 Kuvaus niiden lähdekoodien ydinjärjestelmän asennuksesta

Vaaditut paketit.

Sinun on varmistettava, että seuraavat paketit on asennettu ennen kuin aloitat Nagiosin käyttöönoton. Yksityiskohtainen keskustelu niiden asennusprosessista ei kuulu tämän työn piiriin.

· Apache 2

· PHP

· GCC-kääntäjä- ja kehittäjäkirjastot

· GD Developer Libraries

Voit asentaa ne seuraavasti:

% 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) Luo uusi käyttäjätili, jolla ei ole etuoikeuksia

Uusi tili luodaan Nagios-palvelun käynnistämiseksi. Voit tehdä tämän myös superkäyttäjätilin alta, mikä aiheuttaa vakavan uhan järjestelmän turvallisuudelle.

Ryhdy superkäyttäjäksi:

Luo uusi nagios-käyttäjätili ja anna sille salasana:

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

# passwd nagios

Luo nagios-ryhmä ja lisää nagios-käyttäjä siihen:

# /usr/sbin/groupadd nagios

# /usr/sbin/usermod -G nagios nagios

Luodaan nagcmd-ryhmä, joka mahdollistaa verkkokäyttöliittymän kautta välitettävien ulkoisten komentojen suorittamisen. Lisätään tähän ryhmään nagios- ja apache-käyttäjät:

# /usr/sbin/groupadd nagcmd

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

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

2) Lataa Nagios ja sen lisäosat

Luo hakemisto ladattujen tiedostojen tallentamiseen:

# mkdir ~/lataukset

# cd ~/lataukset

Lataa Nagiosin ja sen lisäosien pakatut lähteet (#"justify"># wget #"justify"># wget #"justify">3) Kääntää ja asentaa Nagios

Puretaan pakatut Nagios-lähteet:

# cd ~/lataukset

# tar xzf nagios-3.2.0.tar.gz

# cd nagios-3.2.0

Suorita Nagios-määritysskripti ja välitä sille aiemmin luomamme ryhmän nimi:

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

Täydellinen luettelo määritysskriptin parametreista:

#./configure --help

`configure" määrittää tämän paketin mukautumaan monenlaisiin järjestelmiin.: ./configure ... ...määritä ympäristömuuttujat (esim. CC, CFLAGS...), määritä ne muodossa = VALUE. Katso alta kuvaukset joistakin hyödyllisistä muuttujista. Vaihtoehdot on määritetty suluissa.:

h, --help näyttää tämän ohjeen ja poistu

Ohje = tälle paketille ominaiset lyhyet näyttövaihtoehdot

Help=rekursiivinen näyttää kaikkien mukana tulevien pakettien lyhyen ohjeen

V, --versio näyttää versiotiedot ja poistu

q, --quiet, --silent älä tulosta "tarkistaa..." -viestejä

cache-file=FILE välimuistitestin tulokset tiedostossa FILE

C, --config-cache alias kohteelle "--cache-file=config.cache"

n, --no-create eivät luo tulostiedostoja

Srcdir=DIR etsi lähteet DIR-hakemistoista:

Prefix=PREFIX asenna arkkitehtuurista riippumattomat tiedostot PREFIXiin

Exec-prefix=EPREFIX asenna arkkitehtuurista riippuvat tiedostot EPREFIX-oletuksena, `make install" asentaa kaikki tiedostot hakemistosta `/usr/local/nagios/bin, `/usr/local/nagios/lib jne. Voit määrittää muu asennusetuliite kuin `/usr/local/nagios" käyttäen `--etuliitettä", esimerkiksi `--prefix=$HOME".parempi hallinta, käytä alla olevia valintoja.tuning asennushakemistoista:

Bindir=DIR käyttäjän suoritettavat tiedostot

Sbindir=DIR-järjestelmänvalvojan suoritettavat tiedostot

libexecdir=DIR-ohjelman suoritettavat tiedostot

Datadir=DIR-vain luku-arkkitehtuurista riippumaton data

Sysconfdir=DIR-vain luku - yhden koneen tiedot

Sharedstatedir=DIR-muokattavissa oleva arkkitehtuurista riippumaton data

Localstatedir=DIR-muokattavat yhden koneen tiedot

Libdir=DIR-objektikoodikirjastot

Includedir=DIR C otsikkotiedostot

oldincludedir=DIR C-otsikkotiedostot muille kuin gcc:lle

infodir=DIR-tietodokumentaatio

Mandir=DIR-miehen dokumentaatiotyypit:

Build=BUILD-määritykset rakentamista varten BUILD

Host=HOST-ristikäännös ohjelmien luomiseksi, jotka toimivat HOSTin ominaisuuksilla:

Disable-FEATURE eivät sisällä OMINAISUUDET (sama kuin --enable-FEATURE=no)

Ota käyttöön-FEATURE[=ARG] sisältää OMINAISUUDEN

disable-statusmap=poistaa tilakartan CGI:n kokoamisen käytöstä

disable-statuswrl=poistaa statuswrl (VRML) CGI:n kääntämisen käytöstä

Enable-DEBUG0 näyttää funktion syöttämisen ja lopettamisen

Enable-DEBUG1 näyttää yleiset infoviestit

Enable-DEBUG2 näyttää varoitusviestit

Enable-DEBUG3 näyttää ajoitetut tapahtumat (palvelu- ja isäntätarkistukset jne.)

Enable-DEBUG4 näyttää palvelu- ja isäntäilmoitukset

Enable-DEBUG5 näyttää SQL-kyselyt

Enable-DEBUGALL näyttää kaikki virheenkorjausviestit

Enable-nanosleep mahdollistaa nanosleepin käytön (lepotilan sijaan) tapahtumien ajoituksessa

Enable-event-broker mahdollistaa tapahtumavälittäjärutiinien integroinnin

Enable-embedded-perl ottaa käyttöön upotetun Perl-tulkin

Enable-cygwin mahdollistaa rakentamisen CYGWIN-ympäristöpakettien alla:

Kanssa-PACKAGE[=ARG] käytä PAKKAUSTA

Ilman PAKKAUSTA älä käytä PAKKAUSA (sama kuin --with-PACKAGE=no)

With-nagios-user= asettaa käyttäjänimen suorittamaan nagios

With-nagios-group= asettaa ryhmän nimen suorittamaan nagios

With-command-user= asettaa käyttäjänimen komennon käyttöä varten

With-command-group= asettaa ryhmän nimen komennon käyttöön

Sähköpostilla = Asettaa polun vastaavaan ohjelmaan postiin

With-init-dir= Aseta hakemisto, johon init-skripti sijoitetaan

With-lockfile= Aseta polku ja tiedostonimi lukitustiedostolle

With-gd-lib=DIR määrittää gd-kirjaston sijainnin

With-gd-inc=DIR asettaa gd include -tiedostojen sijainnin

Kanssa-cgiurl= asettaa URL-osoitteen cgi-ohjelmille (älä käytä perässä olevaa kauttaviivaa)

Kanssa-htmurl= asettaa URL-osoitteen julkiselle html:lle

With-perlcache ottaa käyttöön sisäisesti käännettyjen Perl-skriptien välimuistin tallentamisen vaikuttaviin ympäristömuuttujiin:C-kääntäjä komentoC-kääntäjän lippulinkkiliput, esim. -L jos sinulla on kirjastoja hakemistossa C/C++ esiprosessorin liput, esim. -Minä jos olet epästandardissa hakemistossa C esiprosessoi nämä muuttujat ohittaaksesi `configure'-toiminnon tekemät valinnat tai auttaaksesi löytämään kirjastoja ja ohjelmia, joilla on epästandardinimi/sijainti.

Nagios-lähdekoodin kääntäminen.

Asenna binaarit, alustusskripti, mallimääritystiedostot ja aseta käyttöoikeudet ulkoiseen komentohakemistoon:

# tee install-init

# make install-config

# tee asennus-komentotila

) Muuta kokoonpanoa

Mallimääritystiedostot asennetaan hakemistoon /usr/local/nagios/etc. Niiden pitäisi toimia heti. Sinun tarvitsee tehdä vain yksi muutos ennen kuin jatkat.

Muokataan asetustiedostoa /usr/local/nagios/etc/objects/contacts.cfg millä tahansa tekstieditorilla ja muutetaan nagiosadminin yhteystietomääritykseen liittyvä sähköpostiosoite osoitteeksi, johon aiomme vastaanottaa ongelmaviestejä.

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

5) Verkkokäyttöliittymän asetukset

Asenna Nagios-verkkoliittymän määritystiedosto Apache conf.d -hakemistoon.

# make install-webconf

Luo nagiosadmin-tili kirjautuaksesi Nagios-verkkokäyttöliittymään

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

Käynnistä Apache uudelleen, jotta muutokset tulevat voimaan.

# /etc/init.d/apache2 lataa uudelleen

On tarpeen ryhtyä toimenpiteisiin CGI:n turvallisuuden vahvistamiseksi tämän tilin varkauksien estämiseksi, koska seurantatiedot ovat melko arkaluonteisia.

) Kääntää ja asentaa Nagios-laajennukset

Puretaan Nagios-laajennusten pakatut lähteet:

# cd ~/lataukset

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

Lisäosien kääntäminen ja asentaminen:

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

#tee asennus

) Käynnistä Nagios-palvelu

Määritetään Nagios käynnistymään automaattisesti, kun käyttöjärjestelmä käynnistetään:

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

Tarkistetaan mallimääritystiedostojen syntaktinen oikeellisuus:

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

Jos virheitä ei ole, suorita Nagios:

# /etc/init.d/nagios start

) Siirry verkkokäyttöliittymään

Voit nyt kirjautua Nagios-verkkokäyttöliittymään käyttämällä seuraavaa URL-osoitetta. Sinua pyydetään antamaan aiemmin asettamamme käyttäjätunnus (nagiosadmin) ja salasana.

#"justify">) Muut asetukset

Saadaksesi sähköpostimuistutuksia Nagios-tapahtumista, sinun on asennettava mailx (Postfix) -paketti:

% sudo apt-get install mailx

% sudo apt-get install postfix

Sinun on muokattava Nagios-muistutuskomentoja tiedostossa /usr/local/nagios/etc/objects/commands.cfg ja muutettava kaikki viittaukset arvosta "/bin/mail" muotoon "/usr/bin/mail". Sen jälkeen sinun on käynnistettävä Nagios-palvelu uudelleen:

# sudo /etc/init.d/nagios käynnistyy uudelleen

Yksityiskohtainen postimoduulin konfigurointi on kuvattu liitteessä D.

4.1.2 Kuvaus järjestelmäytimen asennuksesta arkistosta

Kuten yllä näkyy, Nagiosin asentaminen lähteestä vie huomattavasti aikaa ja on järkevää vain, jos tarvitset huolellista sovelluksen optimointia tai jos haluat ymmärtää järjestelmän mekaniikkaa yksityiskohtaisesti. Tuotantoolosuhteissa useimmat ohjelmistot asennetaan arkistoista esikäännetyinä paketteina. Tässä tapauksessa asennus pelkistetään yhden komennon antamiseen:

% sudo aptitude install nagios

Paketinhallinta itse täyttää kaikki riippuvuudet ja asentaa tarvittavat paketit.

4.2 Järjestelmän ytimen konfigurointi

Ennen yksityiskohtaista konfigurointia sinun tulee ymmärtää Nagios-ytimen toiminta. Sen graafinen kuvaus on alla kuvassa 6.2.

4.2.1 Järjestelmän ytimen toiminnan kuvaus

Seuraavassa kuvassa on yksinkertaistettu kaavio Nagios-palvelun toiminnasta.

Riisi. 4.1 - Järjestelmän ydin

Nagios-palvelu lukee pääkonfiguraatiotiedoston, joka sisältää palvelun pääparametrien lisäksi linkkejä resurssitiedostoihin, objektien kuvaustiedostoihin ja CGI-konfiguraatiotiedostoihin.

Verkonvalvontaytimen algoritmi ja logiikka on esitetty alla.

Riisi. 4.2 - Nagios-hälytysalgoritmi

2.2 Kuvaus asetustiedostojen vuorovaikutuksesta

Hakemisto /etc/apache2/conf.d/ sisältää nagios3.conf-tiedoston, josta apache-verkkopalvelin ottaa asetukset nagiosille.

Nagios-määritystiedostot sijaitsevat /etc/nagios3-hakemistossa.

/etc/nagios3/htpasswd.users-tiedosto sisältää salasanoja nagios-käyttäjille. Komento luoda tiedosto ja asettaa salasana oletusnagios-käyttäjälle on annettu yllä. Jatkossa "-c"-argumentti on jätettävä pois asetettaessa salasanaa uudelle käyttäjälle, muuten uusi tiedosto korvaa vanhan.

/etc/nagios3/nagios.cfg-tiedosto sisältää itse nagiosin pääkokoonpanon. Esimerkiksi tapahtumalokitiedostot tai polku muihin määritystiedostoihin, jotka nagios lukee käynnistyksen yhteydessä.

/etc/nagios/objects-hakemisto sisältää uusia isäntiä ja palveluita.

4.2.3 Isäntä- ja palvelukuvausten täyttäminen

Kuten yllä näkyy, on mahdollista määrittää järjestelmän ydin käyttämällä yhtä kuvaustiedostoa isännille ja palveluille, mutta tämä menetelmä ei ole kätevä valvottavien laitteiden määrän kasvaessa, joten on tarpeen luoda hakemisto- ja tiedostorakenne isäntien ja palvelujen kuvauksilla.

Luotu rakenne on esitetty liitteessä H.

hosts.cfg-tiedosto

Ensimmäinen vaihe on kuvata isännät, joita seurataan. Voit kuvata niin monta isäntäkonetta kuin haluat, mutta tässä tiedostossa rajoitamme kaikkien isäntien yleisiin parametreihin.

Tässä kuvattu isäntä ei ole todellinen isäntä, vaan malli, johon kaikkien muiden isäntien kuvaukset perustuvat. Sama mekanismi löytyy muista asetustiedostoista, kun kokoonpano perustuu ennalta määritettyyn oletusarvojen joukkoon.

hostgroups.cfg-tiedosto

Täällä isännät lisätään isäntäryhmään. Jopa yksinkertaisessa kokoonpanossa, kun isäntä on vain yksi, sinun on silti lisättävä se ryhmään, jotta Nagios tietää, mitä yhteysryhmää käyttää hälytyksiä lähettämään. Lisätietoja yhteysryhmästä alla.

Contactgroups.cfg-tiedosto

Olemme määrittäneet yhteystietoryhmän ja lisänneet käyttäjiä tähän ryhmään. Tämä kokoonpano varmistaa, että kaikki käyttäjät saavat varoituksen, jos jokin menee pieleen ryhmän vastuulla olevissa palvelimissa. On totta, että sinun on pidettävä mielessä, että kunkin käyttäjän yksittäiset asetukset voivat ohittaa nämä asetukset.

Seuraava vaihe on yhteystietojen ja hälytysasetusten määrittäminen.

contacts.cfg-tiedosto

Tämän tiedoston käyttäjien lisäyhteystietojen tarjoamisen lisäksi yhdellä kentistä, contact_name, on toinen tarkoitus. CGI-komentosarjat käyttävät näissä kentissä annettuja nimiä määrittääkseen, onko käyttäjällä oikeus käyttää jotakin resurssia vai ei. Sinun on määritettävä todennus, joka perustuu .htaccess-tiedostoon, mutta muuten sinun on käytettävä samoja nimiä kuin yllä, jotta käyttäjät voivat työskennellä Web-käyttöliittymän kautta.

Nyt kun isännät ja yhteystiedot on määritetty, voimme siirtyä valvottavien yksittäisten palveluiden valvonnan määrittämiseen.

Services.cfg-tiedosto

Tässä, kuten isäntien hosts.cfg-tiedostossa, asetamme vain yleiset parametrit kaikille palveluille.

Nagios-lisämoduuleja on saatavilla valtava määrä, mutta jos jonkinlainen tarkistus puuttuu, voit aina kirjoittaa sen itse. Esimerkiksi ei ole olemassa moduulia, joka tarkistaisi, onko Tomcat käynnissä vai ei. Voit kirjoittaa skriptin, joka lataa jsp-sivun Tomcat-etäpalvelimelta ja palauttaa tuloksen sen mukaan, onko ladatulla sivulla tekstiä vai ei. (Kun lisäät uutta komentoa, muista mainita se checkcommand.cfg-tiedostossa, johon emme koskeneet).

Seuraavaksi luomme kullekin yksittäiselle isännälle oman kuvaustiedoston, samaan tiedostoon tallennamme kuvaukset palveluista, joita valvomme tälle isännälle. Tämä tehdään mukavuuden ja loogisen järjestelyn vuoksi.

On syytä huomata, että Windows-isäntiä valvotaan SNMP-protokollan ja NSClientin avulla. joka tulee Nagioksen mukana. Alla on kaavio siitä, kuinka se toimii.

Riisi. 4.3 - Järjestelmä Windows-isäntien valvontaan

Samaan aikaan *nix-isäntiä valvotaan myös SNMP:n sekä NRPE-laajennuksen kautta. Sen työn kaavio on esitetty kuvassa.

Riisi. 4.4 - Järjestelmä *nix-isäntien seurantaan

2.4 Lisäosien kirjoittaminen

Alustusskriptien kirjoittamisen, isäntien ja palveluiden määrittämisen lisäksi käytettiin seuraavia laajennuksia:

├── check_disk

├── check_dns

├── check_http

├── check_icmp

├── check_ifoperstatus

├── check_ifstatus

├── check_imap -> check_tcp

├── check_linux_raid

├── check_load

├── check_mrtg

├── check_mrtgtraf

├── check_nrpe

├── check_nt

├── check_ping

├── check_pop -> check_tcp

├── check_sensors

├── check_simap -> check_tcp

├── check_smtp

├── check_snmp

├── check_snmp_load.pl

├── check_snmp_mem.pl

├── check_spop -> check_tcp

├── check_ssh

├── check_ssmtp -> check_tcp

├── check_swap

├── check_tcp

├── tarkistusaika

Useimmat niistä tulevat Nagios-paketin mukana. Toimitussarjaan kuulumattomien ja järjestelmässä käytettyjen laajennusten lähdetekstit on esitetty liitteessä I.

4.2.5 SNMP:n määrittäminen etäisännille

Jotta voit valvoa SNMP-protokollaa, sinun on ensin määritettävä tämän protokollan agentit verkkolaitteessa. SNMP:n toimintakaavio verkonvalvontajärjestelmän ytimen yhteydessä on esitetty alla olevassa kuvassa.

Riisi. 4.5 - Valvontakaavio SNMP-protokollan kautta

Isäntien konfigurointiparametrit on esitetty liitteessä H. Turvallisuus toteutetaan konfiguroimalla pakettisuodatin erikseen jokaiselle isännälle ja järjestämällä suojatut järjestelmäaliverkot, joihin vain yrityksen valtuutetulla henkilökunnalla on pääsy. Lisäksi konfigurointi on tehty siten, että SNMP-protokollaa käyttämällä voit vain lukea parametreja, etkä kirjoittaa niitä.

4.2.6 Agentin määrittäminen etäisännille

Saadaksesi edistyneitä seurantaominaisuuksia isännille ja palveluille, sinun on asennettava niihin Nagios-agentti, jota kutsutaan nimellä nagios-nrpe-server:

# aptitude asentaa nagios-nrpe-server

Agentin konfiguraatio on esitetty liitteessä K. Agentin toimintakaavio on esitetty yllä olevassa kuvassa 4.5.

4.4 Latausseurantamoduulin asennus ja konfigurointi

MRTG (Multi Router Traffic Grapher) on palvelu, jonka avulla voit vastaanottaa tietoja useista laitteista SNMP-protokollan kautta ja näyttää kanavan kuormituskaaviot (saapuva liikenne, lähtevä, maksimi, keskiarvo) minuuteissa, tunneissa, päivissä ja vuodessa selaimessasi. ikkuna.

Asennusvaatimukset

MRTG vaatii toimiakseen seuraavat kirjastot:

§ gd - kaaviopiirroskirjasto. Grafiikan hahmontamisesta vastaava kirjasto (#"justify">§ libpng - gd tarvitaan png-grafiikan luomiseen (#"justify">Meidän tapauksessamme asennus pelkistyy yhden komennon suorittamiseen, koska esikäännetyn paketin asennustapa arkistosta valitaan:

# aptitude install mrtg

Voit luoda asetustiedostoja manuaalisesti tai käyttää pakkauksessa olevia konfiguraatiogeneraattoreita:

#cfgmaker @ >

Konfigurointitiedoston luomisen jälkeen on suositeltavaa tarkistaa se, koska se voi sisältää kuvauksia liitännöistä, joita meidän ei tarvitse analysoida työmäärän vuoksi. Tällöin tietyt tiedoston rivit kommentoidaan tai poistetaan. Esimerkki MRTG-määritystiedostosta on liitteessä M. Näiden tiedostojen suuren koon vuoksi näytetään vain yksi esimerkkitiedosto.

#indeksintekijä >

Hakemistosivut ovat tavallisia html-tiedostoja, eikä niiden sisällöllä ole erityistä mielenkiintoa, joten esimerkkejä niistä on turha antaa. Liitteessä H on esimerkki käyttöliittymän latauskaavioiden näyttämisestä.

Lopuksi on tarpeen järjestää rajapintojen kuormituksen aikataulutarkastus. Helpoin tapa saavuttaa tämä on käyttöjärjestelmän, nimittäin crontab-parametrien avulla.

4.5 Järjestelmän tapahtumalokien keräämismoduulin asennus ja konfigurointi

Järjestelmätapahtumalokien keruumoduuliksi valittiin paketti syslog-ng.ng (syslog next generation) - tämä on monitoimipalvelu järjestelmäviestien kirjaamiseen. Tavalliseen syslogd-palveluun verrattuna sillä on useita eroja:

§ edistynyt konfigurointimalli

§ suodattaa viestejä ei vain prioriteettien, vaan myös niiden sisällön mukaan

§ tuki säännöllisille lausekkeille (säännölliset lausekkeet)

§ lokien joustavampi käsittely ja järjestäminen

§ kyky salata datakanava käyttämällä IPSec / Stunnel

Seuraavassa taulukossa luetellaan tuetut laitteistoympäristöt.

Taulukko 4.1 - Tuetut laitteistoympäristöt

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ДаДаНетНетНетНет Huomautus: *Oraclen tietokannan käyttöä ei tueta

Yksityiskohtainen teknisten ominaisuuksien vertailu on liitteessä P.

Sääntöjen ja suodattimien kuvaustiedostot sekä etäisäntien asetukset ovat liitteessä P.

On olemassa RFC-dokumentti, joka kuvaa syslog-protokollan yksityiskohtaisesti, yleisesti ottaen syslog-keräysmoduulin toiminta voidaan esittää seuraavalla kaaviolla

Riisi. 4.6 - Järjestelmälokien keräämismoduulin toimintakaavio

Asiakaspalvelimella jokainen yksittäinen sovellus kirjoittaa oman tapahtumalokin ja muodostaa siten lähteen. Seuraavaksi lokien viestivirta kulkee tallennuspaikan määrityksen läpi, sitten suodattimien kautta määritetään sen verkkosuunta, jonka jälkeen lokipalvelimelle päästään jokaiselle viestille määritetään jälleen tallennuspaikka. Valittu moduuli on erittäin skaalautuva ja hyvin konfiguroitavissa, esimerkiksi suodattimet voidaan haaroittaa niin, että järjestelmän tapahtumaviestit lähetetään useisiin suuntiin useista ehdoista riippuen, kuten alla olevasta kuvasta näkyy.

Riisi. 4.7 - Suodattimen haarautuminen

Skaalautuvuus tarkoittaa, että järjestelmänvalvoja ottaa kuorman jakamiseksi käyttöön ylimääräisten suodatuspalvelimien, ns. releiden, verkon.

Riisi. 4.8 - Skaalaus ja kuormituksen tasaus

Loppujen lopuksi yksinkertaisimmalla tavalla moduulin toimintaa voidaan kuvata seuraavasti - asiakasisännät lähettävät viestejä eri sovellusten tapahtumalokeista purkupalvelimille, jotka puolestaan ​​voivat välittää niitä välitysketjua pitkin ja niin edelleen keskuskeräyspalvelimille.

Riisi. 4.9 - Moduulin toiminnan yleinen kaavio

Meidän tapauksessamme tietovirta ei ole niin suuri, että palvelinten purkamisjärjestelmää voitaisiin ottaa käyttöön, joten päätettiin käyttää yksinkertaistettua asiakas-palvelin -toimintamallia.

Riisi. 4.10 - Hyväksytty työsuunnitelma

5. JÄRJESTELMÄNVALVOJAN OPAS

Yleensä järjestelmänvalvojaa kehotetaan noudattamaan olemassa olevaa asetustiedostojen ja hakemistojen hierarkiaa. Uusien isäntien ja palveluiden lisääminen valvontajärjestelmään edellyttää uusien konfigurointitiedostojen ja alustusskriptien luomista, kuten kohdassa 5 - Ohjelmistokehitys on esitetty, joten tässä työssä ei ole järkevää kuvata uudelleen järjestelmän konfiguroinnin parametreja ja periaatteita. mutta järjestelmän yksittäisten moduulien liitäntöjen kuvaukseen kannattaa kiinnittää huomiota.

5.1 Järjestelmän web-käyttöliittymän kuvaus

Palvelujen vuorovaikutteisen seurannan suorittamiseksi oli kätevämpää integroida järjestelmään web-käyttöliittymä. Verkkokäyttöliittymä on hyvä myös siksi, että se antaa kokonaiskuvan järjestelmästä graafisten työkalujen taitavan käytön ja tilastollisen lisäinformaation avulla.

Kun kirjaudut Nagios-verkkosivulle, se pyytää sinua syöttämään käyttäjänimen ja salasanan, jotka määritimme asennuksen aikana. Verkkokäyttöliittymän aloitussivu näkyy alla olevassa kuvassa.

Riisi. 5.1 - Järjestelmän web-käyttöliittymän aloitussivu

Vasemmalla on navigointipalkki, oikealla on tulokset verkon, isäntien ja palveluiden tilasta. Olemme ensisijaisesti kiinnostuneita Valvonta-osiosta. Katsotaanpa Tactical Overview -sivua.

Riisi. 5.2 - Järjestelmän web-käyttöliittymän aloitussivu

Tämä sivu sisältää yhteenvetotiedot kaikista valvontaparametreista sekä isäntien ja palveluiden tilasta, mutta yksityiskohtia ei anneta, mutta jos ongelmia ilmenee, ne korostetaan erityisellä värillä ja niistä tulee hyperlinkki, joka johtaa ongelman yksityiskohtaiseen kuvaukseen. Meidän tapauksessamme on tällä hetkellä yksi ratkaisematon ongelma kaikkien isäntien ja palveluiden joukossa, seuraa tätä linkkiä (1 Käsittelemättömät ongelmat).

Riisi. 5.3 - Havaittu palveluongelma

Täällä tarkkailemme taulukkomuodossa, millä isännillä ongelma ilmeni, mikä palvelu aiheutti sen (meidän tapauksessamme tämä on korkea prosessorikuormitus reitittimessä), virhetilan (se voi olla normaali, kynnys ja kriittinen), ajan. viimeinen tarkistus, ongelman kesto, silmukassa olevan tilin tarkistuksen numero ja käytetyn laajennuksen palauttamat yksityiskohtaiset tiedot erityisillä arvoilla.

Riisi. 5.4 - Yksityiskohtainen kuvaus palvelun tilasta

Täällä näemme täydellisen kuvauksen ongelmasta, tämä sivu on hyödyllinen ongelman syvälliseen analysointiin, kun sen esiintymisen syy ei ole täysin selvä, esimerkiksi se voi olla liian tiukasti asetettujen kriittisten tilojen kynnyksissä tai väärin asetettu laajennuksen käynnistys parametrit, jotka myös järjestelmä arvioi kriittiseksi tilan . Kuvauksen lisäksi tältä sivulta on mahdollista suorittaa palvelulle komentoja, kuten poistaa tarkistukset käytöstä, ajoittaa erilainen seuraava tarkistusaika, hyväksyä tiedot passiivisesti, hyväksyä ongelma tarkistettavaksi, kytkeä hälytykset pois päältä, lähettää manuaalinen hälytys, ajoita palvelun sammutus, poista epävakaan tilan tunnistus käytöstä ja kirjoita kommentti.

Siirrytään Palvelun tiedot -sivulle.

Riisi. 5.5 - Yksityiskohtainen näkymä kaikista palveluista

Täällä näemme luettelon kaikista isännistä ja palveluista niiden nykyisestä tilasta riippumatta. Tämä ominaisuus voi olla hyödyllinen, mutta pitkän isäntien ja palveluiden luettelon selaaminen ei ole kovin kätevää ja sitä tarvitaan enemmän järjestelmän ajoittain tekemän työn määrän visualisoimiseksi. Tässä jokainen isäntä ja palvelu, kuten kuvassa 6.3, on linkki, joka johtaa parametrin tarkempaan kuvaukseen.

Riisi. 5.6 - Täydellinen yksityiskohtainen luettelo isännistä

Tämä taulukko sisältää täydellisen yksityiskohtaisen luettelon isännistä, niiden tiloista, viimeisimmän tarkistuksen ajan, nykyisen tilan keston ja lisätietoja. Järjestelmässämme on hyväksytty, että isännän tila tarkistetaan ICMP (8) isännän saavutettavuustarkistuksen avulla eli ping-komennolla, mutta yleensä tarkistus voi olla mikä tahansa. Isäntänimen oikealla puolella olevan sarakkeen kuvakkeet osoittavat ryhmän, johon se kuuluu, tämä tehdään tiedon havaitsemisen helpottamiseksi. Liikennevalokuvake on linkki, joka johtaa tämän isännän yksityiskohtaiseen palveluluetteloon, tätä taulukkoa ei ole järkevää kuvata erikseen, se on täsmälleen sama kuin kuvassa 10.4, vain tiedot esitetään yhdestä isännästä.

Seuraavat listan linkit ovat erilaisia ​​muunnelmia aiemmista taulukoista, eikä niiden sisällön ymmärtäminen ole vaikeaa. Verkkokäyttöliittymän mielenkiintoisin ominaisuus on kyky rakentaa verkkokartta puoliautomaattisessa tilassa.

Riisi. 5.7 - Verkon täydellinen ympyräkartta

Jokaisen isännän ja palvelun yläparametrin avulla voimme luoda verkkomme rakenteen tai hierarkian, joka määrittää verkon valvontakoneen logiikan ja isäntien ja palveluiden esityksen verkkokartalla. Näyttötiloja on useita, pyöreän lisäksi kätevin on tasapainoinen puutila ja pallomainen.

Riisi. 5.8 - Verkkokartta - B-puutila

Riisi. 5.9 - Verkkokartta - pallotila

Kaikissa tiloissa kunkin isännän kuva on linkki sen palvelutaulukkoon ja niiden tiloihin.

Seuraava tärkeä osa seurannan ydinrajapintaa on trendien rakentaja. Sen avulla voit suunnitella laitteiden vaihtamisen tuottavampiin, annamme esimerkin. Napsauta Trends-linkkiä. Valitse raportin tyyppi - palvelu.

Vaihe 1: Valitse Raportin tyyppi: Palvelu

Kolmas vaihe on valita laskentajakso ja luoda raportti.

Riisi. 5.10 - Trendi

Olemme luoneet suorittimen kuormitustrendin reitityksessä. Siitä voimme päätellä, että kuukauden aikana tämä parametri heikkenee jatkuvasti ja nyt on ryhdyttävä toimenpiteisiin joko isännän toiminnan optimoimiseksi tai valmistaudutaan korvaamaan se tuottavammalla.

5.2 Rajapintojen latauksen valvontamoduulin web-rajapinnan kuvaus

Käyttöliittymän kuormituksenseurantamoduulin verkkokäyttöliittymä on luettelo hakemistoista, jotka sisältävät seurattujen isäntien hakemistosivut kunkin käyttöliittymän latausaikatauluineen.

Riisi. 5.11 - Käyttöliittymän kuormituksenseurantamoduulin aloitussivu

Napsauttamalla mitä tahansa linkkiä saamme latausaikataulut. Jokainen kaavio on linkki, joka johtaa viikon, kuukauden ja vuoden tilastoihin.

5.3 Järjestelmän tapahtumalokien keräämismoduulin kuvaus

Tällä hetkellä järjestelmälokien parannettua suodatusta ja mahdollisuutta etsiä niitä yhden verkkoliittymän kautta ei tarvita, koska. ongelmat, jotka edellyttävät näiden lokien katselua, ovat harvinaisia. Siksi näiden lehtien tietokannan ja verkkokäyttöliittymän kehittäminen on lykätty. Niitä käytetään tällä hetkellä ssh:n ja hakemiston selaamisen kautta mc-tiedostonhallinnassa.

Tämän moduulin työn tuloksena saimme seuraavan hakemistorakenteen:

├── apache2

├── tähti

├── bgp_router

├── dbconfig-common

├── asennusohjelma

│ └── cdebconf

├── len58a_3lvl

├── seuranta

├── nagios3

│ └── arkistot

├── ocsinventory-client

├── ocsinventory-palvelin

├── quagga

├── reititin_krivous36b

├── reititin_lenina58a

├── reititin_su

├── reititin_ur39a

├── muotoilija

├── ub13_router

├── univer11_router

└── voip

Jokainen hakemisto on kunkin yksittäisen isännän tapahtumalokien arkisto.

Riisi. 5.13 - Järjestelmän tapahtumalokin keräysmoduulin keräämien tietojen katselu

6. TYÖN TESTAUS

Järjestelmän käyttöönoton aikana suoritettiin kunkin komponentin toiminnan asteittainen testaus järjestelmän ytimestä alkaen. Toimivuuden laajentaminen toteutettiin vasta verkonvalvontajärjestelmän moduulien alempien hierarkiatasojen lopullisen säädön jälkeen eri osajärjestelmien monista riippuvuuksista johtuen. Askel askeleelta toteutus- ja testausprosessia voidaan yleensä kuvata seuraavasti:

) Nagios-pohjaisen ytimen asennus ja virheenkorjaus;

) Etäisäntien valvonnan määrittäminen Nagiosin perustoiminnoilla;

) Moduulin säätö verkkoliitäntöjen kuormituksen valvontaa varten MRTG:n avulla;

) Järjestelmäytimen toiminnallisuuden laajentaminen ja sen integrointi MRTG-moduuliin;

) Moduulin asettaminen järjestelmälokien keräämistä varten;

) Skriptin kirjoittaminen valvontajärjestelmän pakettisuodattimen alustamiseksi järjestelmän turvallisuuden varmistamiseksi.

7. Tietoturva

1 Työpaikan ominaisuudet

Tietokonetta käytettäessä työhön vaikuttavia haitallisia tekijöitä ovat mm.

· lisääntynyt sähkövirran jännitteen arvo;

· melu;

· elektromagneettinen säteily;

· sähköstaattinen kenttä.

Parhaiden olosuhteiden varmistamiseksi tehokkaalle ja turvalliselle työlle on luotava sellaiset työolosuhteet, jotka ovat mukavat ja minimoivat näiden haitallisten tekijöiden vaikutuksen. On välttämätöntä, että luetellut haitalliset tekijät ovat vakiintuneiden sääntöjen ja määräysten mukaisia.

7.2 Työturvallisuus

2.1 Sähköturvallisuus

Suunniteltu ohjelmistotyökalu on suunniteltu toimimaan olemassa olevassa palvelimessa, joka sijaitsee erityisesti varustetussa teknisessä huoneessa. Se on varustettu kaapelikanavilla kaapelien reititystä varten. Jokainen palvelin toimitetaan teholla ~ 220V, taajuudella 50Hz, toimivalla maadoituksella. Ennen virransyöttöä huoneeseen asennetaan automaattiset kytkimet, jotka katkaisevat virransyötön oikosulun sattuessa. Erillinen suojamaadoitus.

Tietokonetta kytkettäessä laitekotelo on kytkettävä suojamaadoitusjohtimeen, jotta eristysvian sattuessa tai jostain muusta syystä virtalähteen vaarallinen jännite, kun henkilö koskettaa laitekoteloa, ei voi aiheuttaa vaarallinen virta ihmiskehon läpi.

Tätä varten käytetään kolmatta kosketinta sähköpistorasioissa, joka on kytketty suojamaadoitusjohtimeen. Laitekotelot on maadoitettu virtajohdon kautta erityistä johdinta pitkin.

Teknisiä toimenpiteitä sovelletaan suojaamaan sähköiskua vastaan ​​koskettaessa sähköasennuksen runkoa jännitteisten osien eristyksen rikkoutuessa, mukaan lukien:

· suojaava maadoitus;

· suojaava nollaus;

· suojaava sammutus.

7.2.2 Melusuojaus

Tutkimukset osoittavat, että meluisissa olosuhteissa vaikutetaan ensisijaisesti kuulotoimintoihin. Mutta melun vaikutus ei rajoitu vaikutukseen vain kuuloon. Se aiheuttaa huomattavia muutoksia useissa fysiologisissa henkisissä toiminnoissa. Melu vaikuttaa haitallisesti hermostoon ja vähentää sensorimotoristen prosessien nopeutta ja tarkkuutta, virheiden määrä älyllisten ongelmien ratkaisemisessa kasvaa. Melu vaikuttaa huomattavasti ihmisen huomioimiseen ja aiheuttaa negatiivisia tunteita.

Suurin melulähde tiloissa, joissa tietokoneet sijaitsevat, ovat ilmastointilaitteet, tulostus- ja kopiolaitteet sekä itse tietokoneissa jäähdytysjärjestelmän tuulettimet.

Tuotantohuoneessa käytetään aktiivisesti seuraavia melunhallintakeinoja:

· hiljaisten jäähdytysmekanismien käyttö;

· melulähteiden eristäminen ympäristöstä äänieristyksen ja äänen absorption avulla;

· ääntä vaimentavien materiaalien käyttö sisäverhouksissa.

Työpaikalla esiintyy seuraavia melun lähteitä:

· järjestelmäyksikkö (jäähdytin (25 dB), kiintolevy (29 dB), virtalähde (20 dB));

· tulostin (49dB) .

Näiden laitteiden lähettämä kokonaismelu L lasketaan kaavalla:

missä Li on yhden laitteen melutaso, dB= 10*lg(316.23+794.33+100+79432.82) = 10*4.91 = 49.1dB

SN 2.2.4 / 2.1.8.562-96 mukaan melutaso matemaatikot-ohjelmoijat ja videooperaattorit työpaikalla ei saa ylittää 50 dB.

7.2.3 Suojaus sähkömagneettista säteilyä vastaan

Suojauksen sähkömagneettisia häiriöitä vastaan ​​tarjoavat näytöt, joissa on sähköä johtava pinta ja Low Radiation -järjestelmällä varustettujen näyttöjen käyttö, joka minimoi haitallisen säteilyn tason, sekä nestekidenäytöt, joissa sähkömagneettista säteilyä ei ole lainkaan.

7.2.4 Sähköstaattinen suojaus

Sähköstaattiselta varaukselta suojaamiseksi käytetään maadoitettua suojasuodatinta, ilmankostuttimia ja lattiat on päällystetty antistaattisella pinnoitteella. Positiivisten ja negatiivisten ionien pitoisuuden normalisoitujen arvojen ylläpitämiseksi tiloissa, joissa on tietokoneita, ilmastointilaitteita, ilman ionisaatiolaitteita asennetaan ja luonnollinen ilmanvaihto suoritetaan vähintään 10 minuutin ajan joka 2. käyttötunnin jälkeen.

Ilmassa olevien pölyhiukkasten haitallisten vaikutusten estämiseksi työssäkäyvien ihmisten kehoon, tilojen märkäpuhdistus suoritetaan päivittäin ja pöly poistetaan näytöiltä vähintään kerran vuorossa, kun näyttö sammutetaan.

7.3 Työolosuhteet

3.1 Tuotantohuoneen mikroilmasto

Tässä opinnäytetyössä käsitellyt laitteet eivät tuota haitallisia aineita käytön aikana. Siten huoneen ilmaympäristöllä, jossa niitä käytetään, ei ole haitallisia vaikutuksia ihmiskehoon ja se täyttää luokan I työn vaatimukset GOST 12.1.005-88 mukaisesti.

Optimaaliset standardit lämpötilalle, suhteelliselle kosteudelle ja ilman nopeudelle teollisuustilojen työskentelyalueella on standardoitu GOST 12.1.005-88:lla ja esitetään taulukossa 7.1.

Taulukko 7.1 - Mikroilmaston parametrit

Normalisoitu parametriArvoOptimaalinenSallittuTodellinenIlman lämpötila, С20 - 2218 - 2020 Kosteus, % 40 - 60 Enintään 8045Ilman nopeus, m/s0.20.30..0.3

Mikroilmasto vastaa optimaalisia olosuhteita.

3.2 Teollisuusvalaistus

Laskemista varten valitsemme tukiosaston Gerkon LLC:ssä Verkhnyaya Pyshman kaupungissa, jossa tämä projekti kehitettiin:

· huoneen pinta-ala on 60m2;

· valo-aukkojen pinta-ala on 10 m2;

· Työpisteitä asennettiin 4 kpl.

Luonnollisen valaistuksen laskenta suoritetaan kaavan SNiP 23.05-95 mukaan:

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

missä S0 on valoaukkojen pinta-ala, m2;

Sp - huoneen pinta-ala, m2, 60;

en - luonnollisen valaistuksen kerroin, 1,6;

Kz - varmuuskerroin, 1,5;

N0 - ikkunoiden valoominaisuus, 1;

KZD - kerroin, jossa otetaan huomioon vastakkaisten rakennusten ikkunoiden himmennys, 1,2;

T0 - valon kokonaisläpäisykerroin, 0,48;

T1 - heijastuskerroin huoneen pinnasta, 1.2.

Kaikkien kertoimien arvot on otettu SNiP:stä 23.05.-95.

Laskennan tuloksena saadaan: ikkunoiden vaadittu valoaukkojen pinta-ala S0 = 3,4 m2. Todellinen aukkojen pinta-ala on 10m2, mikä ylittää tämän tyyppisten tilojen valoaukkojen vähimmäispinta-alan ja riittää valoisaan aikaan.

Keinotekoisen valaistuksen laskeminen huoneelle, joka on valaistu 15 LDC-60-tyyppisellä loistelampulla, joiden kunkin teho on 60 W.

SNiP 23.05-95 mukaan loistelamppujen valaistuksen määrän on oltava vähintään 300 lm vaakatasossa - yleisvalaistusjärjestelmässä. Kun otetaan huomioon erittäin tarkka visuaalinen työ, valaistusarvoa voidaan nostaa jopa 1000 lm:iin.

Loistelampun valovirta lasketaan SNiP 23.05.-95 kaavan mukaan:

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

Missä En - huoneen normalisoitu valaistus, lx, 200;

S - huoneen pinta-ala, m2, 60;

Z - kerroin, jossa otetaan huomioon keskimääräisen valaistuksen suhde minimiin, 1,1;

K - ilmansaasteet huomioiden turvakerroin, 1,3;

N - kiinnikkeiden lukumäärä, 15;

η - valovirran käyttökerroin, 0,8.

Tuloksena saadaan Phi = 1340lm, kaikkien lamppujen kokonaisvalovirta on 3740lm, joten laboratorion valaistus on yli sallitun vähimmäistason.

7.4 Työpaikan ergonomia

4.1 Työpaikan organisointi

SanPiN 2.2.2 / 4.2.1340-03 mukaisesti VDT:n (videonäyttöpäätteen) on täytettävä seuraavat tekniset vaatimukset:

· valaistuksen kirkkaus vähintään 100 cd/m2;

· valopisteen vähimmäiskoko on enintään 0,1 mm värinäytössä;

· kylttikuvan kontrasti on vähintään 0,8;

· pystypyyhkäisytaajuus vähintään 7 kHz

· pisteiden määrä on vähintään 640;

· heijastamaton näyttö pinnoite;

· näytön koko vähintään 31 cm diagonaalisesti;

· merkkien korkeus näytöllä on vähintään 3,8 mm;

· etäisyyden käyttäjän silmistä näyttöön tulee olla noin 40-80 cm;

VDT tulee varustaa kääntöpöydällä, jonka avulla voit siirtää sitä vaaka- ja pystytasossa 130-220 mm:n sisällä ja muuttaa näytön kulmaa 10-15 astetta.

Valmistumisprojekti suoritettiin tietokoneella, jossa oli VDT ViewSonic, jonka lävistäjä oli 39 cm. Tämä näyttö on valmistettu maailmanlaajuisten standardien mukaisesti ja täyttää kaikki yllä mainitut tekniset vaatimukset.

Näppäimistövaatimukset ovat seuraavat:

· kotelomaalaus rauhoittavilla pehmeillä sävyillä hajavalon sironnan kanssa;

· mattapinta, jonka heijastuskyky on 0,4 - 0,6, eikä siinä ole kiiltäviä yksityiskohtia, jotka voivat aiheuttaa häikäisyä;

Projekti toteutettiin Logitech-merkkisellä näppäimistöllä, joka täyttää kaikki yllä olevat vaatimukset.

Järjestelmälohkot asennetaan työpaikalle ottaen huomioon helppo pääsy levykeasemiin ja kätevä pääsy liittimiin ja säätimiin takapuolella. Usein käytetyt levykkeet on tallennettu järjestelmäyksikön lähelle pölyltä ja sähkömagneettisesti suojattuun kennoon. Tulostin on sijoitettu käyttäjän oikealle puolelle. Painettu teksti näkyy käyttäjälle, kun hän on päätyöasennossa. Erikoisosastoissa säilytetään tyhjää paperia ja muita tärkeitä tarvikkeita tulostimen lähellä.

Liitäntäkaapelit asetetaan erityisiin kanaviin. Kanavien järjestelyn tulee olla sellainen, että liittimet eivät häiritse kaapeleiden irrottamista.

"Hiiri"-manipulaattoria varten käyttäjän oikealla puolella pöydällä on vapaa alue, jonka tulee olla muodoltaan ja kooltaan identtinen näytön pinnan kanssa.

Käyttäjän työpaikka täyttää GOST 12.2.032-78 SSBT:n vaatimukset.

Työpaikan tilajärjestely tarjoaa optimaalisen työasennon:

· pää kallistettuna eteenpäin 10-20 astetta;

· selässä on korostus, olkapään ja kyynärvarren sekä reiden ja säären välinen suhde on suorassa kulmassa.

Työpaikan pääparametrien tulee olla säädettävissä. Tämä varmistaa mahdollisuuden luoda suotuisat työolosuhteet yksilölle geoantropometriset ominaisuudet huomioon ottaen.

Työpaikan ja henkilökohtaisella tietokoneella varustettujen huonekalujen pääparametrit (kuva 7.1)

Riisi. 7.1 - Tietokoneen käyttäjän työpaikka

· istuinkorkeus 42 - 45 cm;

· näppäimistön korkeus lattiasta 70 - 85 cm;

· näppäimistön kulma vaakasuuntaan 7 - 15 astetta;

· näppäimistön etäisyys pöydän reunasta 10 - 26 cm;

· etäisyys näytön keskustasta lattiaan 90 - 115 cm;

· näytön kallistuskulma pystysuorasta 0 - 30 astetta (optimaalinen 15);

· näytön etäisyys pöydän reunasta 50 - 75 cm;

· kirjoitustason työtason korkeus 74 - 78 cm;

Työpaikalla on jalkatuki, jota suositellaan kaikenlaisiin töihin, jotka liittyvät pitkäaikaiseen istumiseen

SanPiN 2.2.2.542-96 mukaan tietokoneoperaattorin työn luonnetta pidetään helppona ja se kuuluu luokkaan 1A.

Tauot asetetaan 2 tunnin kuluttua työvuoron alkamisesta ja 2 tunnin kuluttua 15 minuutin lounastauosta. Säänneltyjen taukojen aikana suoritetaan harjoitussarjoja neuro-emotionaalisen stressin, väsymyksen ja hypodynamian vaikutuksen poistamiseksi.

7.5 Paloturvallisuus

Huoneessa, jossa työ tehtiin tässä projektissa, on palovaaraluokka. NPB 105-03 - palavat ja palamattomat nesteet, kiinteät palavat ja palamattomat aineet ja materiaalit, mukaan lukien pöly ja kuidut, aineet ja materiaalit, jotka voivat olla vuorovaikutuksessa vedellä, happiilmalla tai vain toistensa kanssa, jos tilat, joissa ne ovat käytettävissä tai muodostuneet, eivät kuulu A- tai B-luokkaan. Rakennus I palonkestävyysasteen tiloille SNiP 21-01-97 mukaan .

Tuotantoalueella noudatetaan seuraavia turvallisuussääntöjä:

· käytävät, uloskäynnit tiloista, pääsy palonsammutusvälineisiin ovat ilmaisia;

· käytössä olevat laitteet ovat hyvässä toimintakunnossa ja tarkastetaan joka kerta ennen työn aloittamista;

· töiden päätyttyä tilat tarkastetaan, sähkönsyöttö katkaistaan, tilat suljetaan.

Evakuointiuloskäyntien määrä rakennuksista tiloista on kaksi. Hätäuloskäynnin (oven) leveys on 2m. Poistumisreiteillä käytetään tavanomaisia ​​tikkaita ja saranoituja ovia. Porraskäytävissä ei ole huoneita, teknisiä yhteyksiä, hissien ja tavarahissien uloskäyntejä. Poistumisreitit on varustettu sekä luonnollisella että keinotekoisella hätävalaistuksella.

Ensisijaisina palonsammutuskeinoina huoneessa on manuaalisia hiilidioksidisammuttimia, joita on kaksi kappaletta.

Tulipalon alkuvaiheen havaitsemiseen ja palokunnan hälyttämiseen käytetään automaattista palohälytysjärjestelmää (APS). Se aktivoi itsenäisesti palonsammutuslaitteistot, kunnes palo on saavuttanut suuren koon ja ilmoittaa siitä kaupungin palokunnalle.

EY:n kohteet, paitsi APS, on varustettava kiinteillä sammutuslaitteistoilla. Kaasusammutuslaitteistojen sovellukset, joiden toiminta perustuu tilan nopeaan täyttymiseen sammutuskaasulla, jonka seurauksena ilman happipitoisuus laskee.

7.6 Hätätilanteet

Tässä ympäristössä todennäköisin hätätilanne olisi tulipalo. Tulipalon sattuessa henkilökunta on evakuoitava ja siitä on ilmoitettava palokunnalle. Evakuointisuunnitelma on esitetty kuvassa 7.2.

Riisi. 7.2 - Palopoistumissuunnitelma

8. TALOUDELLINEN OSA

Tässä osiossa käsitellään verkonvalvontajärjestelmän kehittämisen, toteutuksen ja ylläpidon kustannuksia sekä siihen liittyviä materiaaleja ja laitteita.

Hankkeen kustannukset heijastavat kehitys- ja tuotantoprosessissa käytettyjen välineiden ja työvälineiden kustannuksia (poistot, laitteiden, materiaalien, polttoaineen, energian jne. kustannukset), osaa elinkustannuksista (palkoista) , ostettujen järjestelmämoduulien hinta.

Aktiviteetin ja palvelutoimitusten määrän kasvun aikana nousi esiin ongelma verkkoorganisaation viallisten ja heikkojen kohtien ennakoivasta havaitsemisesta, eli tehtävänä oli toteuttaa ratkaisu, joka mahdollistaisi vaihto- tai päivitystarpeen ennakoinnin. verkkoosiot ennen toimintahäiriöitä vaikuttavat tilaajasolmujen toimintaan.

Asiakaskunnan ja sen seurauksena aktiivisten laitteiden määrän kasvaessa tuli tarpeelliseksi seurata nopeasti koko verkon tilaa ja sen yksittäisiä elementtejä yksityiskohtaisesti. Ennen verkonvalvontajärjestelmän käyttöönottoa verkonvalvojan piti muodostaa yhteys käyttämällä telnet-, http-, snmp-, ssh- jne. protokollia. jokaiseen kiinnostavaan verkkosolmuun ja käytä sisäänrakennettuja valvonta- ja diagnostiikkatyökaluja. Tällä hetkellä verkon kapasiteetti on 5000 porttia, 300 Layer 2 -kytkintä, 15 reititintä ja 20 sisäistä palvelinta.

Lisäksi verkon ruuhkat ja ajoittaiset viat havaittiin vasta, kun käyttäjille oli vakavia ongelmia, jotka estivät verkkopäivityssuunnitelmia.

Kaikki tämä johti ennen kaikkea tarjottujen palvelujen laadun jatkuvaan heikkenemiseen ja järjestelmänvalvojien ja käyttäjien teknisen tuen kuormituksen lisääntymiseen, mikä aiheutti valtavia tappioita.

Vallitsevan tilanteen mukaisesti päätettiin kehittää ja ottaa käyttöön verkonvalvontajärjestelmä, joka ratkaisisi kaikki edellä mainitut ongelmat, jotka yhteenvetona voidaan ilmaista seuraavasti:

On tarpeen kehittää ja ottaa käyttöön valvontajärjestelmä, joka mahdollistaa sekä kytkimien, eri valmistajien reitittimien että eri alustojen palvelimien valvonnan. Keskity avoimien protokollien ja järjestelmien käyttöön hyödyntäen maksimaalisesti vapaiden ohjelmistojen rahaston valmiita kehityssuuntia, mikä vähentää taloudellisesta näkökulmasta lopullisen järjestelmän lisensointikustannukset nollaan.

Järjestelmän on täytettävä seuraavat taloudelliset vaatimukset:

· vähimmäisvaatimukset laitteistoresursseille (johtaa alhaisempiin kustannuksiin projektin laitteisto-osassa);

· kompleksin kaikkien komponenttien avoimet lähdekoodit (voit muuttaa itsenäisesti järjestelmän periaatetta turvautumatta kolmannen osapuolen omaan kehitykseen ja vähentää tuotteen lisensoinnin kustannuksia);

· järjestelmän laajennettavuus ja skaalautuvuus (mahdollistaa laajentaa sovelluksen laajuutta turvautumatta kolmannen osapuolen ja omaan kehitykseen ja vähentää tuotteen lisensoinnin kustannuksia);

· standardikeinot diagnostisten tietojen toimittamiseen (voit alentaa järjestelmän ylläpitokustannuksia);

· kaikkien käytettyjen ohjelmistotuotteiden yksityiskohtaisen dokumentaation saatavuus (mahdollistaa uuden työntekijän nopean kouluttamisen);

· kyky työskennellä eri valmistajien laitteiden kanssa (mahdollistaa yhden ohjelmistotuotteen käytön). (Katso täydellinen luettelo varusteista liitteessä B).

Yleisesti projektin kehittäminen kesti 112 tuntia (2 viikkoa). Tämän projektin toteuttaminen kestää 56 tuntia (1 viikko).

1 Hankkeen kehittämiskustannusten laskeminen

Hankkeen kehityskustannukset koostuvat:

· palkkakustannukset;

· laitteiden ja ohjelmistotuotteiden poistot;

· sähkökustannukset;

· yläpuolella.

Palkkakulut.

Palkkakuluja laskettaessa otamme huomioon, että tämän projektin on kehittänyt yksi henkilö: järjestelmäinsinööri.

Vaaditun tason järjestelmäinsinöörin keskimääräinen markkinapalkka alueella on 30 000 ruplaa.

Lasketaan 1 tunnin insinöörityön hinta seuraavien tietojen perusteella:

· palkkio 25 %;

· piirikerroin 15 %;

· työaikarahasto vuonna 2010 tuotantokalenterin mukaan on 1988 tuntia;

Siten korko, kun otetaan huomioon aluekerroin, on:

RF = 30 000 * 1,25 * 1,15 * 12 / 1988 \u003d 260 ruplaa

Palkkakulujen laskennassa otetaan huomioon kertyneistä palkoista tehdyt vähennykset, eli vakuutusmaksun kokonaismäärä on yhtä suuri kuin korkein UST-prosentti - 26%, mukaan lukien:

· PFR - 20 %;

· FSSR - 2,9 %

· FFOMS - 1,1 %;

· GFOMS - 2 %;

· Pakollinen tapaturmavakuutus - 0,2 %.

Vähennysten kokonaismäärä on:

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

Ottaen huomioon insinöörin työajan (112 tuntia kehittämiseen ja 56 tuntia toteutukseen) laskemme palkkakustannukset:

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

Laitteiden ja ohjelmistotuotteiden poistot.

Verkkoprojektin kehitysvaiheessa päälaitteistona käytettiin henkilökohtaista tietokonetta ja AQUARIUS SERVER T40 S41 -palvelinta. Tietokoneen hinta on tällä hetkellä noin 17 000 ruplaa, kun taas palvelimen hinta on 30 000 ruplaa.

Näin ollen kertaluonteisen laiteinvestoinnin kustannukset ovat:

PBA = 47000 ruplaa

Tietokoneen ja palvelimen käyttöiän aikana niitä saa päivittää, myös tämäntyyppiset kustannukset otetaan huomioon laskennassa. Asennamme 50 % matkailuautosta modernisointia varten:

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

Tietokonetta käytettiin seuraavissa vaiheissa:

· kirjallisuuden haku;

· etsiä ratkaisuja verkonvalvontajärjestelmän suunnitteluun;

· rakenteiden ja osajärjestelmien kehittäminen;

· verkon valvontajärjestelmän suunnittelu;

· asiakirjan muotoilu.

Palvelinta käytettiin järjestelmän käyttöönoton ja suoran työskentelyn aikana järjestelmän kanssa.

Kehityksessä käytetyt ohjelmistotuotteet hankitaan ilmaisilla lisensseillä, mikä tarkoittaa, että niiden hinta on nolla eikä niistä tarvitse tehdä poistoja.

Näin ollen laitteiden kokonaiskustannukset poistot huomioon ottaen ovat:

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

Käyttöiän oletetaan olevan 2 vuotta. Yhden työtunnin hinta on (olettaen kuukauden työpäivien lukumääräksi 22 ja 8 tunnin työpäivällä):

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

Poistovähennysten kustannukset kehitys- ja toteutushetkellä ovat vastaavasti:

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

Sähkökustannukset.

Sähkökustannukset ovat tietokoneen kulutuksen ja valaistukseen käytettyjen kulujen summa. Sähkön hinta:

SEN \u003d 0,80 ruplaa / kW * h (Sopimuksen mukaan tilan omistajan kanssa)

Рк,с = 200 W - tietokoneen tai palvelimen käyttämä teho.

Тrk = 168 h - tietokoneen toiminta-aika järjestelmän kehitys- ja toteutusvaiheessa.

Трс = 52 h - palvelimen käyttöaika järjestelmän kehitys- ja toteutusvaiheessa.

Näin ollen sähkön hinta hankkeen kehittämis- ja toteutusvaiheessa on:

SENP \u003d Rk * Trk * SEN + Rk * Trs * SEN \u003d (200 * 168 * 0,80 + 200 * 52 * 0,80) / 1000 \u003d (26880 + 8320) / 100.20 d 3 ruplaa

Työpaikka, jossa tämä työ tehtiin, on varustettu 100 W lampulla. Lasketaan valaisimen kuluttaman sähkön hinta järjestelmän kehittämisen ja käyttöönoton aikana:

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

Sähkön kokonaiskustannukset olivat:

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

8.2 Yleiskustannuslaskenta

Tämä kustannuserä kattaa muiden laitteiden ja tarvikkeiden kustannukset sekä ennakoimattomat menot.

Yrityksen budjetin yleiskustannukset ovat 400 % kertyneistä palkoista:

HP \u003d ZP * 4 \u003d 55104 * 4 \u003d 220416 ruplaa.

Näin ollen hankkeen kehittämisen ja toteuttamisen kustannukset olivat:

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

3 Tehokkuus

Taloudellisten laskelmien suorittamisen tuloksena verkonvalvontajärjestelmän kehittämisen ja käyttöönoton vähimmäishinnaksi määritettiin 278 372,56 ruplaa.

Kuten laskelmista voidaan nähdä, suurin osa kuluista kohdistuu materiaaleihin ja laitteisiin. Tämä selittyy sillä, että tärkeimmät laitevalmistajat ovat ulkomaisia ​​yrityksiä ja vastaavasti näiden tuotteiden hinnat on ilmoitettu Yhdysvaltain dollareina Venäjän keskuspankin kurssilla + 3%. Ja myös tuontituotteiden tullien nousu vaikuttaa negatiivisesti loppuasiakkaiden hintaan.

Järjestelmän itsenäisen kehittämisen perustelemiseksi verrataan sen kustannuksia markkinoilla oleviin valmiisiin ratkaisuihin:

· D-Link D-View - 360 000 ruplaa