3 LIIKENTEEN ANALYSOINTI JA OHJELMAT
4.4 Network Node Managerin ja CiscoWorksin vertailua
Verkonvalvonnan käyttöliittymien vaihtoehtoina oli tarkkailla hälytyksiä DFM:n Alerts and Activities -ikkunasta tai NNM:n Alarm Browser -ikkunasta. Kuten luvussa 2 todettiin, verkonvalvonta onnistuu molemmilla, mutta vaaka kallistui NNM:n eduksi.
Vaatimukset työtä aloitettaessa olivat kutakuinkin, että yhdestä näkymästä pitäisi nähdä verkon tila ja vikojen ilmaantuessa nähdä niiden sijainti ja syy. Tähän NNM sopi hyvin, koska se antaa selkeän ja reaaliaikaisen karttakuvan verkosta. NNM:ssä myös värit auttavat havainnollistamisessa. Toimiessaan normaalisti laite tai aliverkko on kartalla vihreänä, mutta kun laite tippuu verkosta, se muuttuu punaiseksi. Vikojen syyt saa näkymään Alarm Browser -ikkunasta, joka ilmoittaa myös varoituksista, jotka eivät näy kartalla. CiscoWorksistakin vianvalvonta löytyy, mutta reaaliaikaisena on vain DFM:n Alerts and Activities -ikkuna, jonka hälytysilmoituksiin ei testausvaiheessa oltu täysin tyytyväisiä. NNM: n hälytykset olivat selkeämpiä ja luotettavampia ja kokonaisuudessaan se havaittiin käytettävyydeltään paremmaksi käyttäjien keskuudesssa.
DFM tosin täydentää NNM: n vian valvontaa. Koska se on erikoistunut Ciscón laitteisiin ja tuntee ne paremmin, DFM havaitsi virheitä, joita NNM ei havainnut. DFM huomasi esimerkiksi eräällä Ciscón tukiasemalla vähentyneen vapaan muistin tilan. DFM:lie jätettiin tällaisten tapausten varalta päälle laitteiden SNMP-pollaus, jotta myös tämänkaltaiset viat havaittaisiin. Ylläpitäjä voi tarkastaa säännöllisesti DFM:stä onko se havainnut uusia hälytyksiä.
Ohjelmia testattiin myös hiukan, jotta saataisiin niiden toimivuus varmistettua ennen käyttöönottoa. Testaus tapahtui osittain koekäytön aikana ja osittain testikytkimellä.
Koekäytön aikana havaittiin, että molemmat ohjelmat huomasivat, kun laite otettiin pois verkosta. Aluksi havaitsemiseen kuluneessa ajassa oli satunnaisia eroja molempiin suuntiin, mutta kun pollausväli laitettiin samaksi, havaitsemisajoissa ei ollut enää eroja.
Sekä NNM:stä että CiscoWorksista saa päälle sähköposti-ilmoitukset, jotka lähettävät sähköpostin ohjelman havaitessa hälytyksen. Sähköpostihälytykset säädettiin menemään sille ylläpitäjälle, joka vastaa kyseisestä verkkoalueesta. Jokainen oman alueensa ylläpitäjä saa haluamansa sähköposti-ilmoitukset vain omalta osastoltaan. Mutta koska
ei voida olettaa, että ylläpitäjä olisi koko ajan sähköpostin ääressä, hälytykset tulevat myös tekstiviestinä matkapuhelimeen. Tämä varmistaa sen, että ylläpitäjä saa tiedon häiriöstä välittömästi ja reagointinopeus paranee.
Sähköposti-ilmoitusten säädössä oli kuitenkin eroja ohjelmien välillä. NNM:ssä piti sähköposti-ilmoitus säätää erikseen jokaiselle hälytykselle, mistä halusi ilmoituksen.
Lisäksi piti määritellä sendmail-ohjelma Solariksessa kuntoon, jotta sähköpostien lähetys onnistui. Konfigurointi oli siis vaivalloista, mutta ilmoitukset oli helppo rajata tarkasti haluamistaan hälytyksistä. CiscoWorksissa ilmoitusten lähettäminen oli helpompi säätää kuntoon, mutta ohjelma antoi mahdollisuuden vain eri tasojen määrittämiseen. Tiukimmalla critical-tasollakin sähköpostihälytyksiä tuli ylläpitäjien mielestä liikaa.
Taulukossa 5 on vielä vertailtu ohjelmien eri ominaisuuksia verkonvalvonnan kannalta.
Vertailun kohteena CiscoWorksissa oli nimenomaan DFM, joka hoitaa vianhallintaa.
Ominaisuus HP OpenView NNM Cisco Works DFM
Verkkolaitteiden pollaus Helppo määritellä vapaasti Helppo määritellä vapaasti Trap-ilmoitusten
käsittely
Erittäin hyvä, parempi kuin DFM:ssä
Alarm Browser, parempi käyttää
Alerts and Activities Sähköposti-ja
tekstiviesti-hälytykset
Hankalahko konfiguroida, mutta saa tarkasti rajattua vain halutuista hälytyksistä.
Helppo määritellä.
Onnistuu hälytyksen tason mukaan, mutta liikaa hälytyksiä kriittiselläkin tasolla.
Yhtäaikainen tarkkailu eri työasemilta
OK, onnistuu WWW- selaimella
OK, onnistuu WWW- selaimella
Karttakuva verkon topologiasta
Selkeä aliverkkoihin jaoteltu kuva havainnollistavine väreineen
Kuva meni sekavaksi laitteiden määrän kasvaessa
Tuki eri valmistajien laitteille
Hyvin laaja Vain Ciscón laitteet
tuettuja. Kaikkia
tehdasalueen laitteita ei saa valvonnan alle.
Antti Palokangas - Tietoliikenneverkon valvonta eräässä yrityksessä
Sopivuus Erittäin sopiva Täyttää vaatimukset, mutta
verkonvalvonnan vaaka kallistuu NNM:n
ratkaisuksi yritykselle eduksi
Taulukko 5: Ohjelmien ominaisuuksien vertailu
Kokonaisuudessaan NNM siis oli parempi valinta verkon valvonnan käyttöliittymäksi.
Se vakuutti varsinkin käytettävyydellään ja sopivuudellaan kyseiseen tehtävään.
CiscoWorks suoriutui vaadituista tehtävistä, mutta NNM on verkonvalvonnassa parempi vaihtoehto. CiscoWorks ei kuitenkaan jää turhaksi, koska sillä on tärkeä osa Ciscón laitteiden kokoonpanon hallinnassa ja se täydentää verkonhallintaratkaisua.
Koska NNM valittiin käyttöliittymäksi verkonvalvontaan, voitiin laitteiden tilan pollaus jättää NNM:n vastuulle. NNM:stä asetettiinkin saavutettavuuden pollausväli kaikille verkkolaitteille 30 sekuntiin ja CiscoWorksista poistettiin saavutettavuuden pollaus turhana. SNMP-pollaukset, jotka tarkkailevat laitteiden muita ominaisuuksia kuin saavutettavuutta, jätettiin päälle molempiin, koska ne voivat täydentää toisiaan. Vaikka CiscoWorksia ei tarkkaiHakaan aktiivisesti, voidaan se jättää tarkkailemaan laitteita siltä varalta, että se sattuisi huomaamaan jotain, mitä NNM ei huomaa.
4.5 Verkonvalvoja käytännössä
Verkonvalvonnan käyttöliittymäksi valittiin siis NNM. Seuraavaksi piti määritellä, kuinka hälytysten suhteen käytännössä toimitaan. Tarkoitus oli, että operaattorit tarkkailevat hälytyksiä ja ilmoittavat tarvittaessa ylläpitäjille. Jokaisesta hälytyksestä ei ollut kuitenkaan järkevä soittaa ylläpitäjille, koska hälytyksiin haluttiin muun muuassa trap-ilmoituksia konfiguraatiomuutoksista. Nämä muutokset ovat yleensä ylläpitäjän itsensä aiheuttamia, joten niistä on turha soittaa. Teinkin jokaisesta hälytyksestä toimintaohjeen mitä pitäisi tehdä, kun kyseinen hälytys tulee Alarm Browseriin. Koska hälytyksiä tulee myös uusista asioista ja toimintaohjeet voivat ajan mittaan muuttua, tämä lista sijoitettiin tietokantaan, jossa sama tieto on kaikkien asianosaisten ulottuvilla ja muokattavissa.
Operaattorit ohjeistettiin toimimaan kuvan 11 vuokaavion mukaisesti. Jokaisesta tähän asti ilmenneestä hälytyksestä on tehty toimintaohje, jotta operaattori tietää miten toimia.
Toimintaohjeet kertovat esimerkiksi, kenelle operaattorin pitää soittaa tai jätetäänkö hälytys ylläpitäjän kuitattavaksi. Mikäli hälytys on uusi eikä siitä ole toimintaohjetta.
operaattorit soittavat kyseisen laitteen ylläpitäjälle ja ilmoittavat hälytyksestä. Ylläpitäjä selvittää hälytyksen syyn ja vakavuuden. Tämän jälkeen hän korjaa ongelman ja lisää toimintaohjeen tulevia tapauksia varten. Jos seuraavalla kerralla operaattori havaitsee, että ohje on epätäydellinen eikä tiedä mitä tehdä, hän soittaa uudestaan laitteen ylläpitäjälle. Ylläpitäjä korjaa ongelman ja täydentää toimintaohjetta. Näin toimintaohjeet pysyvät ajan tasalla, koska jos ylläpitäjä unohtaa täydentää toimintaohjetta, soitetaan hänelle uudestaan samasta asiasta hälytyksen toistuessa.
■Qpenationtiitiastaa
лпко hävtys telassa Operaattori toimi
ohjeen mukaan
Ylläpitäp korjaa hälytyksen p päivittää toimintaohje»;
Hälytys tutee Alarm Bronseiün
Ylläpitäjä koijaa hälytyksen ja päivittää toimima ohjeet Operaattori katioo kenen a kr ее la laite on p ilmoittaa
taiteen yllä petäjän»
Operaattori katsoo kenen alueella laite on p *rroiltaa
laitteen ylläpitäjälle
Kuva 11: Vuokaavio operaattoreiden toiminnasta
4.6 Proaktiivisuus
Tärkeä osa verkonvalvontaa on vikojen ennakointi ja niihin reagointi, ennen kuin ne ehtivät tapahtua. Tätä kutsutaan proaktiiviseksi verkonhallinnaksi.
Tässä järjestelmässä proaktiivisuutta tuo mukanaan muun muassa ympäristömuuttujien, kuten kytkimien lämpötilojen tarkkailu. Kun lämpötila laitteella nousee liian korkeaksi, lähtee laitteelta trap-ilmoitus verkonhallinta-asemalle. Tällöin ongelma havaitaan jo ennen laitteen vikaantumista ja käyttökatkon syntyä. Esimerkiksi jos vika on itse laitteessa, sen uusimiseen voidaan varautua ennalta ja tuoda varalaite paikalle valmiiksi.
Mikäli laite häiriöistä huolimatta toimii edelleen, sen vaihto voidaan suorittaa esimerkiksi myöhemmin illalla, jotta vaihdoksesta käyttäjille aiheutuva häiriö olisi minimaalinen.
NNM hoitaa myös proaktiivista verkonvalvontaa. Se kerää tietoja puolen tunnin välein pakettien virhemääristä ja porttien käyttöasteista. Jos reitittimen tietylle portille tulevista paketeista virheellisten pakettien osuus on yli 20 %, Alarm Browseriin tulee hälytys.
Hälytys tulee myös, jos portin käyttöaste on yli 70 %. Jos näitä hälytyksiä tulee toistuvasti, on selvää, että linkillä on jotain virheellistä. Havaintojen mukaan tämä johtui yleensä vääristä asetuksista joko reitittimellä tai yhteyden toisessa päässä olevalla verkkokortilla. Pakettivirheet ja suuret käyttöasteet voivat myös ennakoida vian syntymistä.
NNM hakee tiedot vain reitittimillä, joten kytkimillä ja tukiasemilla olevia virheellisiä portteja ei huomata. Jo reitittimen porttien seurannassa on tarpeeksi tekemistä ja jokaista kytkimen porttia ei haluttukaan tarkkailla. Lisäksi kytkimiä valvotaan välillisesti reitittimellä, koska kytkimet ovat yleensä suoraan kiinni reitittimessä ja jos kytkimeltä tulee paljon liikennettä, se huomataan reitittimellä.
Toinen vaihtoehto pakettivirheiden tarkkailuun olisi RMON, jonka käyttö esitellään seuraavaksi. RMON pystyy siis myös porttien virhemäärien tarkkailuun. RMON:in etuna NNM:n ratkaisuun verrattuna olisi se, että prosessointi jäisi reitittimen vastuulle ja vasta kun häiriöitä havaittaisiin, tulisi ilmoitus verkonhallinta-asemalle. Mutta koska valvonnan alla ovat vain reitittimet, NNM:n tarkkailu on riittävä ja helpompi ratkaisu.
Tietojen kysely pelkiltä reitittimillä puolen tunnin välein ei rasita liikaa verkonhallinta- asemaa eikä verkkoa. Lisäksi NNM:n ratkaisua on helpompi ylläpitää, koska muutokset pitää tehdä vain yhdessä paikassa. RMON:in arvoja muuttaessa pitää käydä läpi jokainen laite, jossa RMON on määriteltynä.
NNM:n etuna on myös mielekkäämpi pakettivirhemäärien tarkkailu. Siinä on valmiiksi rakennettuna pakettivirheiden suhteellisen osuuden laskenta. Siinä NNM laskee portilla kulkeneet paketit ja virheelliset paketit ja laskee näistä virheellisten pakettien prosentuaalisen osuuden koko liikenteestä. RMON:issa ei tätä ominaisuutta ole, mutta se pystyy tarkkailemaan joko absoluuttista arvoa tai aikavälillä muuttunutta
Antti Palokangas — Tietoliikenneverkon valvonta eräässä yrityksessä
44
pakettivirheiden määrää. Raja-arvojen määrittäminen voi olla tällöin hiukan hankalampaa.
RMON voidaan kuitenkin ottaa myöhemmin käyttöön, mikäli tarvetta sille havaitaan.
Ciscón verkkolaitteet tukevat vähintään RMON:in Alarms ja Event -ryhmiä, joten on mahdollista määritellä RMON tarkkailemaan porttien liikennemääriä tai virheellisiä paketteja ja ilmoittamaan trap-viestillä, kun määritellyt raja-arvot ylittyvät.
Myös verkkokapasiteettia voi suunnitella ja hallita proaktiivisesti. MRTG:n avulla hoidettua verkkokapasiteetin tarkkailua ja suunnittelua tarkastellaan kappaleessa 5.
4.7 Tietoturva
SNMP:ssä on turvallisuusaukkoja, kuten todettiin jo kirjallisuuskatsauksessa. Tässä työssä tietoturvauhat on otettu huomioon ja niitä on pyritty lieventämään mahdollisuuksien mukaan.
Yhteisötunnukset on pidetty salassa ja luonnollisesti muutettu oletusarvoista eli tunnuksista public ja private. Tämä onkin aina ensimmäinen neuvo, mitä SNMP:n käyttöönottoa harkitseville annetaan. Mutta vaikka tunnuksen pitäisi salassa, käytettävä SNMPv2c ei ratkaise vieläkään SNMP:n turvallisuusongelmaa, koska yhteisötunnus kulkee verkossa edelleen selväkielisenä. Työn toimeksiantajan ympäristössä yhteisötunnus kulkee kuitenkin vain sisäverkossa, joten mahdollisen tunkeutujan on ensiksi päästävä yrityksen sisäverkkoon, jotta hän voi yrittää selvittää yhteisötunnuksen.
SNMPv3 olisi ratkaisu tähän ongelmaan, mutta NNM ei tue tätä ilman kolmannen osapuolen tuotteita, joten tätä ei voida ainakaan vielä ottaa käyttöön. CiscoWorksin tuki SNMPv3-versiolle on myös rajallinen, koska sitä ei tueta datan salauksella.
Tietoturvan parantamiseksi on myös määritelty valvottaville laitteille pääsynvalvontalistat, jotka määrittävät, mistä IP-osoitteista SNMPdlä pääsee lukemaan tai muuttamaan tietoja. Tämä ratkaisu on edelleen haavoittuvainen osoitteen väärentämiselle, mutta on silti parempi kuin ei mitään. Koska vain verkonhallinta- aseman tarvitsee päästä laitteisiin SNMPdlä käsiksi, rajoitettiin sen IP-osoite ainoaksi osoitteeksi, josta pääsee lukemaan ja muuttamaan laitteiden tietoja SNMPdlä. Lisäksi autentikointivirheistä lähtee trap-ilmoitus NNMdle, kun joku yrittää päästä SNMPdlä
Antti Palokangas - Tietoliikenneverkon valvonta eräässä yrityksessä
käsiksi laitteisiin väärästä IP-osoitteesta tai väärällä yhteisötunnuksella. NNM:n Alarm Browseriin tuleva hälytys kertoo samalla, mistä osoitteesta autentikointia on yritetty.
4.8 Kokoonpanon hallinta
Vaikka kokoonpanon hallinta ei kuulukaan varsinaisesti verkonvalvontaan, on se tärkeä osa verkonhallintaa. Kokoonpanon hallinta esiteltiin lyhyesti kappaleessa 2.1.2. NNM ei voinut hoitaa kaikkia kokoonpanon hallinnassa tarvittavia tehtäviä, joten se jäi tässä järjestelmässä pääasiassa CiscoWorksin vastuulle. Kappaleessa 2.5.3 esitelty Resource
Manager Essentials (RME) piti pääosin huolen verkkolaitteiden kokoonpanoista.
RME ottaa varmuuskopiot Ciscón laitteiden konfiguraatiotiedostoista aina kun konfiguraatio! muuttuvat ja pitää viimeiset viisi versiota tallessa palvelimelle. Mikäli esimerkiksi kytkin vikaantuu ja korvataan uudella vastaavanlaisella, voidaan palvelimelta hakea käytössä ollut konfiguraatio ja asentaa se uuteen laitteeseen.
Varmuuskopiot voivat olla hyödyllisiä myös tilanteessa, jossa tehdyt muutokset laitteiden konfiguraatioon eivät olekaan toimineet halutulla tavalla ja tahdotaan palata muutoksia edeltäneeseen tilanteeseen.
RME sisältää myös laitteiden kokoonpanojen muokkaamista helpottavia työkaluja.
Netconfig-työkalulla saa näppärästi useiden laitteiden konfiguraatioita muokattua samalla kerralla. Tätä työtä tehdessä netconfig osoittautui hyvin hyödylliseksi, kun muokkasin verkkolaitteiden SNMP- ja syslog-asetuksia useaan kertaan. Ilman netconfigia laitteisiin olisi aina pitänyt tehdä muutokset laite kerrallaan.
Kuten aikaisemmin jo mainittiin, RME sisältää myös syslog-analysaattorin, joka ottaa vastaan verkkolaitteilta lähetetyt syslog-viestit. Laitteille asetettiin normaalien syslog- viestien lähettäminen tasolle warnings eli viesti lähtee varoituksista ja sitä vakavammista häiriöistä. Kynnys syslog-viestin lähettämiseen RMEdle oli siis matalampi kuin kynnys trap-viestin lähetykseen NNMdle. Tämän tarkoituksena oli, että NNM:n hälytysikkunaan tulee ilmoitukset vain kriittisistä virheistä ja vähemmän vakavia virheitä voi tarkastella RME:n syslog-raporteista.
RMEdle tulevat syslog-viestit sisältävät tietoa muun muassa viallisista porteista, joissa on jotain konfiguraatiovirheitä. Kun laitteet määriteltiin lähettämään syslog-viestit
46
RME:lle, huomattiin useita portteja, joissa oli korjattavaa. Näiden korjaamisen jälkeen laitteiden toiminta parani ja syslog-viestien määrä laski.
4.9 Yhteenveto
Tässä luvussa kuvattiin prosessi, kuinka yritykselle rakennettiin verkonvalvontajärjestelmä ja kerrottiin rakennetun järjestelmän ominaisuuksista. Aluksi käytiin läpi, millainen ympäristö piti saada verkonvalvonnan alle. Seuraavaksi esiteltiin verkkolaitteiden asetukset, jotta lukija saisi kuvan siitä, millaisista tapauksista laitteet ilmoittavat verkonhallinta-asemalle. Tämän jälkeen vertailtiin verkonvalvonnan käyttöliittymiä ja miksi NNM valittiin hoitamaan verkonvalvontaa. Lopuksi selvitettiin, kuinka verkonvalvonta hoidetaan käytännössä ja kerrottiin tarkemmin järjestelmän proaktiivisuudesta ja tietoturvasta. Lopuksi vielä esiteltiin, miten käyttöönotettu CiscoWorks parantaa verkonhallinnan tärkeää osa-aluetta, kokoonpanon hallintaa.
Koska verkonvalvontajärjestelmä otettiin tuotantokäyttöön vasta työn loppuvaiheissa, tässä työssä ei ole esitetty tarkemmin, millaisia tuloksia on saatu järjestelmän käyttöönoton jälkeen. Järjestelmää testattaessa ja käyttöönotettaessa huomattiin kuitenkin heti useita häiriöitä, jotka piti korjata. Tällaisia olivat muun muassa useat yhteydet, joilla virheellisten pakettien osuus oli korkea ja SNMP-pollaukset sellaisista lähteistä, joista niitä ei pitänyt tulla. Virheellisiä paketteja sisältäviä yhteyksiä löytyi noin kymmenen ja ne korjautuivat pääosin, kun konfiguraatiot tarkastettiin yhteyden molemmista päistä. SNMP-pollaukset saatiin vähenemään, kun pollaavan laitteen ylläpitäjää pyydettiin poistamaan aiheettomat peilaukset. Myös aloitettaessa syslog- viestien tarkkailu huomattiin noin kymmenen laitetta ja yhteyttä, joiden asetuksissa oli korjattavaa. Nämä sisälsivät pääasiassa virheitä kytkimien porttien ja niissä kiinni olevien työasemien asetuksissa. Näin osoitettiin, että järjestelmällä pystyttiin huomaamaan virheitä, joita ei muutoin oltu vielä huomattu ja verkon toimintaa saatiin parannettua korjaamalla virheet.
Kuvassa 12 näkyy hälytysten määrä yhden viikon aikana verkonvalvontajärjestelmän käyttöönoton alussa. Tämä on alkutilanne, jossa on vielä jäljellä joka päivä toistuvia hälytyksiä, joita ei ole korjattu. Muun muassa joka päivä tulee 20 Warning-tason hälytystä, jotka johtuvat SNMP-pollauksista, joita ei ole poistettu. Kun nämä ja muut vastaavat hälytykset on korjattu, voidaan hälytysten määrää alkaa tarkkailemaan
Antti Palokangas - Tietoliikenneverkon valvonta eräässä yrityksessä
paremmin. Esimerkiksi kuukausittaisella hälytysten määrän tarkkailulla voidaan karkeasti seurata, kuinka paljon verkossa on ollut häiriöitä ja korjaavatko ylläpitäjät hälytyksiä. Tiedot hälytysten määristä on helppo katsoa NNM:n Alarm Browserista.
Hälytysten määri eri tasoilla
120
Kuva 12: NNM:n hälytysten määrä viikon aikana
Tarkemman kuvan hälytysten yleisyydestä saa kuitenkin taulukosta 6, jossa on esitetty viikon aikana esiintyneiden hälytysten lukumäärät. Ajankohta on ollut sama kuin kuvan 12 tuloksissa, mutta tulokset näyttävät erilaisilta, koska niistä on poistettu esimerkiksi päivittäin toistuvat hälytykset vääristä SNMP-pollauksista. Näissäkin hälytyksissä on tosin toistoa, koska pakettivirheitä havaitaan viikon aikana useaan kertaan samoilla yhteyksillä, joita ei ole vielä korjattu. Virheellisiä yhteyksiä on siis vähemmän kuin 17.
Hälytykset lämpötilamuutoksista reitittimillä johtuvat taas siitä, että reitittimeen sisäänrakennettu lämpötilan tarkkailu on ollut poissa toiminnasta lyhyen hetken, mutta on palautunut heti normaaliin tilaan. Lämpötila ei ole siis noussut reitittimillä kriittiseksi. Taulukossa esiintyvien hälytysten korjaamiseen menee vaihtelevasti aikaa.
Esimerkiksi yhteyden, jolla on paljon virheellisiä paketteja, korjaamiseen voi kulua vain 10 minuuttia, jos korjaus onnistuu pelkästään tarkastamalla asetukset reitittimellä. Mutta siihen voi kulua myös päiviä, jos vika ei löydy helposti.
Hälytyksen syy Hälytyksen taso Hälytysten lukumäärä Lämpötilamuutoksia reitittimellä Critical/Normal 12
Pakettivirheitä havaittu yhteydellä Major 17
Väärä SNMP-autentikointi Warning 11
Vaihteleva poltin tila Warning 1
Pakettivirheet yhteydellä vähentyneet Normal 17 Laitteen konfiguraatiota muokattu Normal 30
Taulukko 6: NNM:n hälytyksiä ja niiden yleisyys viikon aikana
Hälytysten tasot ja niiden vakavuudet voi määritellä yleisesti ottaen seuraavasti. Critical on korkeimman tason hälytys ja se vaatii välitöntä korjausta. Major on toiseksi vakavin taso ja sen tason hälytyksiin pitää puuttua työpäivän aikana. Tämän tason hälytyksissä laite tai yhteys toimii edelleen, mutta toiminnassa on havaittu vakava ongelma. Minor on seuraava taso ja se kertoo ongelmasta, joka vaatii huomiota ja korjausta, mutta ei välttämättä edes saman työpäivän aikana. Warning-taso toimii nimensä mukaisesti varoituksena ja ylläpitäjän on hyvä huomioida nämä. Normal on ilmoitusluontoinen taso eikä vaadi korjaustoimenpiteitä. Nämä tasot antavat kuitenkin vain suuntaa hälytyksen vakavuudesta ja jokainen hälytys käsitelläänkin tapauskohtaisesti.
Antti Palokangas - Tietoliikenneverkon valvonta eräässä yrityksessä
5 LIIKENNEMÄÄRIEN TARKKAILU
Tässä luvussa analysoidaan verkon tilaa ja kapasiteettia. Mittasin kahden reitittimen linkkien kuormitusta ja analysoin niiltä saatuja tuloksia. Tarkoituksena oli tutkia huippuliikenneaikoja ja millaisia liikennemäärät yhteyksillä ovat. Tässä luvussa esitellään myös käytännön esimerkein, kuinka MRTGrtä voi käyttää verkonvalvonnassa.
5.1 Huippuliikenneajat
Liikenteen tarkkailu aloitettiin asentamalla MRTG ja tarkkailemalla yrityksen runkoreitittimiä. Tarkastelun kohteeksi otettiin Tietohallinnon reitittimet, koska niitä voidaan pitää tärkeimpinä. Niiden kautta kulkee esimerkiksi kaikki yrityksen ulkopuolelle menevä liikenne ja Tietohallinnossa on eniten muiden osastojen käyttämiä palveluja. Näin saatiin yleiskuva porttien käyttöasteesta ja siitä, mitkä olivat tärkeimmät yksittäiset portit. Ensimmäisenä tavoitteena oli selvittää, milloin yrityksen verkossa esiintyvät huippuliikenneajat ja mistä liikenne tällöin muodostuu.
5.1.1 Tietohallinto
Yleisesti ottaen eniten liikennettä reitittimillä aiheuttivat siinä kiinni olevat palvelimet ja erityisesti yöaikaan. Palvelimien aiheuttama liikenne oli selvästi vilkkaimmillaan yöaikoihin, kun niistä otettiin varmuuskopiot. Kuvassa 13 näkyy yleinen kuvio useimpien palvelimien liikennemalleista. Päiväsaikaan syntyvä liikenne on suhteessa mitätön verrattuna liikennehuippuihin, jotka syntyvät, kun palvelimelta otetaan varmuuskopio. Kyseinen kuva on verkonhallinta-asemalta ja siitä näkee myös, että verkonhallinta-aseman liikenne ei aiheuta liikaa kuormitusta verkkoon. Normaali liikennemäärä päiväsaikaan on noin 150-200 kbit/s. Liikennehuiput tällä palvelimella esiintyvät aamuyöstä neljän aikoihin, jolloin verkossa riittää kapasiteettia. Kyseisen linkin kapasiteetti riittää varmuuskopiointiinkin kevyesti, koska verkonhallinta-asema on kiinni reitittimessä 1 Gbit/s -nopeuksisella linkillä. Myös muiden palvelimien varmuuskopiot otetaan muutoin hiljaiseen yöaikaan.
50
Traffic Analysis for 96 - tihaOl - Verkonhallinta-asema
3.6 M
2.8 M
0.0 M
Kuva 13: Palvelimen liikenneproftili
MRTG:n kaavioita tarkastellessa kuvan 14 portti kiinnitti huomion, koska kyseisen linkin maksimikapasiteetti oli käytössä joka yö useita tunteja. Tässä portissa oli kiinni eräs palvelin ja öiset liikennemäärät aiheutuivat sen tiedostojen varmuuskopioinnista.
Varmuuskopioitavan tiedon määrä vaihteli välillä 50-130 gigatavua ja palvelin oli kiinni reitittimessä linkillä, jonka nopeus oli 100 Mbit/s.
Daily’ Graph (5 Minute Average)
Max Average Current
In 11.8 MB/s (94.7%) 1717.8 kB/s (13.7%) 36.0 кВ/з (0.3%) Out 2215.5 kB/s (17.7%) 41.1 кВ/s (0.3%) 6548.0 B/s (0.1%)
Kuva 14: Linkin maksimikapasiteetti käytössä
Linkin nopeus ei ollut riittävä tällaisen määrän siirtämiseen ja asian korjaamiseen oli kaksi vaihtoehtoa: joko vähentää varmuuskopioitavan tiedon määrää tai kasvattaa linkin nopeutta. Varmuuskopioitavaa tietoa tarkastellessa huomattiin, että siinä oli mukana paljon sellaista, mitä ei tarvitse joka yö kopioida. Näin ollen järkevin ratkaisu oli vähentää kopioitavan tiedon määrää. Samalla säästettiin verkon ja varmuuskopiointiin osallistuvien palvelinten resursseja. Kuvassa 15 näkyy selvä muutos, miten liikenteen määrä väheni linkillä varmuuskopioinnin optimoimisen jälkeen. Optimoinnin vaikutus näkyi myös palvelimella, jolle kopiot tallennetaan. Tämän varmuuskopiointipalvelimen jokaöinen urakka kesti ennen muutosta usein aamuseitsemään, mutta optimoinnin jälkeen liikennemäärät pienenivät jo aamuviiden aikoihin. Vaikka tämä ongelma olisi
Antti Palokangas — Tietoliikenneverkon valvonta eräässä yrityksessä
voitu havaita myös varmuuskopiointipalvelimen tiedoista, tässä nähtiin, kuinka verkon valvonta voi auttaa kiinnittämään huomioita ongelmakohtiin.
’Daily’ Graph (5 Minute Average)
12.ö И
0.0 n
Kuva 15: Liikennemäärän muutos varmuuskopioinnin optimoimisen jälkeen
Palvelimien varmuuskopioinnit eivät aiheuttaneet kuitenkaan kaikkea huippuliikennettä.
Tietohallinnon palvelimet ja runkoreitittimet on sijoitettu kahteen konesaliin ja nämä konesalien väliset linkit olivat myös vilkasliikenteiset, kuten kuvassa 16 näkyy.
Näissäkin yöllinen liikenne oli vilkkainta, johtuen toisessa konesalissa sijaitsevassa palvelimelta, johon varmuuskopiot tallennetaan. Edellisaamuna yhdeksän aikoihin esiintynyt piikki aiheutti kuitenkin suurimman yksittäisen liikennepiikin. Tällöin liikennettä oli kulkenut 13,0 MB/s eli 104 Mbit/s. Tämäkin on vain noin 10 % linkin kapasiteetista, joten kasvun varaa on vielä reilusti.
Traffic Analysts For 1 -- tihaOl - tihanvOÎ
Traffic Analysis For 2 — tihaOl - till aw, 02 13.2 П
9.9 N
3.3 »
12 10 8 о гг го is 16 i2 io e
Kuva 16: Liikenne konesalien välillä
5.1.2 Ulkoyhteydet
Tarkastellessa kuvan 17 porttia, jonka kautta kulkee yrityksen ulkopuolelle menevä liikenne, näkyi sellaisia tuloksia kuin sopi odottaa. Huippuliikenneajat tällä yhteydellä
ovat päiväsaikaan, kun työntekijöitä on eniten paikalla ja sisäänpäin tulevan liikenteen osuus on suurempi kuin ulospäin menevän. Näillä tiedoilla voi olettaa, että liikenne on
ovat päiväsaikaan, kun työntekijöitä on eniten paikalla ja sisäänpäin tulevan liikenteen osuus on suurempi kuin ulospäin menevän. Näillä tiedoilla voi olettaa, että liikenne on