Prosessia, joka muodostuu verkon hallinnasta ja verkon valvonnasta, kutsutaan verkonhallinnaksi. Ohjelmistoa, jolla verkonhallintaa toteutetaan, kutsutaan verkonhallintajärjestelmäksi. Verkonhallintajärjestelmä on joukko integroituja sovelluksia, joilla voidaan hallita ja valvoa verkossa olevia laitteita.
Seuraavassa esitetään muutamia mittareita, jotka voivat olla hyödyllisiä suorituskyvyn valvonnan toteuttamiseksi. Ne voidaan jakaa kahteen ryhmään: palvelupohjaisiin ja tehokkuuspohjaisiin mittauksiin.
Tässä MTTR tarkoittaa vian keskimääräistä korjausaikaa (mean time to repair).
Järjestelmän saatavuus riippuu verkon yksittäisten komponenttien luotettavuudesta sekä järjestelmän rakenteesta. Joitakin laitteita on voitu kahdentaa, jolloin yhden laitteen vikaantuminen ei vaikuta järjestelmän toimintaan. Rakenne voi olla myös sellainen, että yhden laitteen menetys näkyy kapasiteetin vähenemisenä, vaikka itse järjestelmä toimii edelleen.
Vasteajan mittaamisessa on otettava huomioon useita asioita. Vaikka saattaa olla mahdollista suoraan mitata kokonaisvasteaika tietyssä verkkoympäristössä, sillä ei verkon suorituskyvyn valvonnan kannalta ole kovinkaan suurta merkitystä. Kokonaisvasteaika on jaettava pienempiin osiin, jotta pullonkaulat voidaan tunnistaa.
Esimerkiksi päätekäytössä vasteaika voidaan jakaa kuvan 2 mukaisesti seuraavasti:
Verkon liikenteeseen liittyvät mittaukset voidaan suorittaa laitteisiin rakennettujen mekanismien avulla. Niiltä kyetään kysymään esimerkiksi lähetettyjen ja vastaanotettujen pakettien tai tavujen määrää, yhteyksien lukumäärää jne. Tällaisten yksinkertaisten laskureiden avulla saadaan kerättyä tietoa lähinnä yksittäiseen laitteeseen kohdistuvan liikenteen määrästä.
Monimutkaisemman mekanismin sijoittaminen laitteeseen informaation lisäämiseksi ei yleensä kannata, sillä se tapahtuu aina laitteen varsinaisen käyttötarkoituksen kustannuksella.
Mikäli esimerkiksi reitittimeen rakennetaan mekanismit, joiden avulla se analysoi eri laitteiden välistä liikennettä, voi käydä niin, että kaikki laitteen prosessointi keskittyy analysointiin eikä reititykseen. Päinvastaisessa tapauksessa, eli kaiken prosessoinnin keskittyessä reititykseen, ei taas saada kaikkea liikennettä analysoitua, jolloin laitteelta saatava liikenneanalyysi ei pidä yhtä todellisuuden kanssa. Tehokkaampi ja monipuolisempi ratkaisu on sijoittaa verkkoon sopivaan paikkaan laite, joka suorittaa ainoastaan verkon liikenteen tarkkailua.
Myös protokollakohtaisesti voidaan laskea paketin koon mukainen jakauma. Tällä on harvemmin käytännön merkitystä verkon kapasiteetin uudelleen jakamiselle, koska pakettien koosta ei pystytä suoraan selvittämään mitä tietoa verkossa liikkuu ja mitä palveluja verkosta käytetään. Sen sijaan luokittelemalla tietyn protokollan paketit niiden tyypin perusteella saadaan tärkeää tietoa siitä, mitkä palvelut vievät eniten verkon kapasiteettia. Esimerkiksi IP-protokollan paketit voidaan luokitella melko tarkkaan niiden lähde- ja kohdeporttien perusteella. Tällä tavoin saadaan selville, onko tarpeen siirtää esimerkiksi levypalvelujen tarjoaminen omaan verkkoon.
Erityisesti TCP/IP-verkon liikenteen analysoinnissa on tärkeätä tietää törmäysten osuus kaikista paketeista. Törmäysten lukumäärän kasvaessa verkon siirtokyky heikkenee huomattavasti, kun laitteet joutuvat odottamaan ennen paketin uudelleenlähetystä.
Erityisesti kun on tarpeen jakaa verkko osiin, voidaan eniten verkkoa kuomittavat laitteet jakaa tasaisemmin verkon eri osiin. Tarkentamalla analyysiä lähettäjä-vastaanottajaparien aiheuttamaan liikenteeseen voidaan paremmalla menestyksellä pilkkoa verkko osiin, kun suurimmat liikenteen aiheuttajat voidaan eristää omaan kokonaisuuteensa, esimerkiksi sillan taakse. Näin niiden liikenne ei häiritse muuta verkon liikennettä, ja verkon tehokkuutta saadaan kasvatettua.
Laitteiden lähettämien ja vastaanottamien pakettien perusteella voidaan myös toteuttaa verkon käytön valvonnan yhteydessä suoritettava laskutus. Esimerkiksi verkon ylläpitoon liittyviä kustannuksia voidaan jakaa verkon kapasiteetin todellisen käytön perusteella. Tarkempi laskutus on mahdollista myös ottamalla tarkasteluun mukaan pakettien tyypin analysointi, jolloin laskutusperusteena voidaan pitää tiettyjen palvelujen käyttöä. Esimerkiksi sähköpostiyhteyksistä voitaisiin laskuttaa keskuspostikoneelle lähetettyjen pakettien perusteella.
Osa vioista voi olla sellaisia, että niitä ei voida havaita. Esimerkiksi kahden toisistaan riippuvan prosessin lukkiutuminen (deadlock) ei aina aiheuta havaittavaa ongelmaa. Joitakin vikoja taas ei huomata, koska vikaantunutta laittetta ei ole valmistettu niin, että se pitäisi kirjaa tapahtuneista virheistä.
Toisaalta monet viat ovat sellaisia, että ne voidaan havaita ainoastaan osittain. Tiedetään siis että vika on, muttei voida paikallistaa mikä vian itse asiassa aiheuttaa. Esimerkiksi jos laite ei vastaa kyselyyn, voi syy olla itse laitteessa tai verkossa itsessään tai verkon kuormitus aiheuttaa viiveitä niin, että sovellus ei saa vastausta riittävän nopeasti ja laitteen oletetaan olevan viallinen.
Sen lisäksi, että potentiaalisia vian aiheuttajia voi olla monia, voi myös yksi ainoa vika aiheuttaa useiden vikahavaintojen syntymisen. Tällöin voi olla hyvin vaikeata suodattaa pois nämä toissijaiset havainnot ja etsiä vioista se, joka aiheuttaa kaikki muut viat. Automaattisesti tapahtuvat vioista toipumiseen tähtäävät toimet vaikeuttavat myös vikojen syyn selvittämistä. Ne tuhoavat usein tärkeätä tietoa, jota tarvittaisiin vian luonteen selvittämiseksi. Suurin ongelma vikojen havaitsemisessa on automaattisten testausvälineiden puute.
Verkon laitteiden tilan säännöllinen kysely voi auttaa havaitsemaan viat suhteellisen nopeasti niiden synnyttyä. Tällaisilla kyselyillä on kuitenkin se huono puoli, että ne vievät verkon kapasiteettia varsinaiselta hyötykuormalta. On tasapainoiteltava havaintotarkkuuden ja käytettävän verkon kapasiteetin välillä, eli mitä suurempi havaintotarkkuus halutaan, sitä suurempi osa verkon siirtokapasiteetista käytetään. Muita kyselyvälin valintaan liittyviä asioita ovat seurattavien laitteiden lukumäärä sekä käytettävien linkkien kapasiteetti.
Kaikilla verkon ongelmilla ei ole yhtä suurta merkitystä. Osa on sellaisia, joista on saatava välittömästi tieto, osa taas sellaisia, jotka järjestelmän pitäisi itse osata hoitaa tai jättää kokonaan huomiotta. On kyettävä määrittelemään, mitkä viat ovat kaikkein merkittävimpiä tietyn verkon toiminnan kannalta. Tähän on useita syitä. Mikäli ongelmia on paljon, ei välttämättä ole edes mahdollista käsitellä niiden aiheuttaman informaation määrää. Toisaalta minimoimalla ilmoitusten määrää voidaan vähentää redundanttia tai turhaa informaatiota ja siten minimoida verkon kapasiteetin tuhlaus.
Siihen, mitä ongelmia hallitaan, vaikuttaa myös verkon koko sekä mahdollinen organisatorinen jako verkon eri osien välillä. Monet verkot on loogisesti jaettu osiin (runkoverkko ja aliverkkoja, kuva 3) siten, että keskusorganisaatio vastaa runkoverkosta ja niistä ongelmista, jotka vaikuttavat koko verkon toimintaan. Näin paikallisista aliverkoista vastaavat organisaatiot voivat keskittyä omien laitteidensa toiminnan seuraamiseen. Toisaalta paikallisten aliverkkojen käyttäjillä ei välttämättä ole resursseja verkonhallintaan. Tällöin on löydettävä jonkinlainen kompromissi. Keskusorganisaatio voi esimerkiksi valvoa aliverkkoja ja ilmoittaa vastaavalle organisaatiolle ongelmista ja niiden aiheuttajista, mutta jättää vian korjaamiset kyseisen organisaation vastuulle.
Tiedon eheyden (data integrity) testaamisessa tarkistetaan, että tieto ei muutu siirtoyhteyden yli. Erityisesti täytyy kiinnittää huomiota mahdolliseen pakettien häviämiseen siirron aikana. Testit täytyy aina suorittaa riittävän monella eri pakettikoolla, koska joissakin tapauksissa saattavat verkon fyysiset ominaisuudet (esimerkiksi heijastukset ethernetissä) aiheuttaa jonkin kokoisten pakettien katoamista.
Vasteaikatestissä tarkistetaan, että esimerkiksi jotain sovellusta käytettäessä havaittu ongelma ei johdu vasteaikojen kasvamisesta yli sallittujen rajojen. Kaikki yhteyden muodostamiseen tarvittavat laitteet on mahdollisuuksien mukaan syytä testata esimerkiksi laitteiden sisäisellä itsetestauksella (self-test).
Valvottavista resursseista voidaan kerätä esimerkiksi seuraavanlaista informaatiota:
Ennen varsinaisen valvontaan perustuvan laskutuksen aloittamista on käyttäjien kannalta erityisen tärkeätä pitää riittävän pitkä siirtymiskausi. Tämän ajanjakson kuluessa käyttäjiä informoidaan heidän käyttämistään resursseista ja niistä aiheutuvista kustannuksista, jotta he voivat ennakoida tulevia kustannuksia. Samalla voidaan laskutusperusteita tarkentaa yhteistyössä käyttäjien kanssa. Näin saadaan käyttäjät vakuuttuneiksi siitä, että resurssien käyttö on oikein mitattu ja käytöstä aiheutuvat kustannukset tullaan laskuttamaan todelliseen käyttöön perustuvilla mittauksilla.
Yksi käytön valvonnan toteutukseen liittyvistä ongelmista laskutusperusteiden määrittelyn lisäksi, on oikean mittauspisteen valinta. Mikäli on kyse yhteisen siirtotien käytön valvonnasta, voi seuraavanlainen malli olla varsin toimiva.
Kuvassa 4 esitetyn mallin mukaisesti mittauspisteessä oleva laite tai ohjelmisto tarkkailee runkoverkon liikennettä ja kirjaa kustakin aliverkosta tulleet paketit (ja niiden koot). Kirjatuista paketeista voidaan muodostaa laskutuksen kannalta tarpeelliset tietovuot (dataflow). Voidaan esimerkiksi laskea kustakin aliverkosta runkoverkkoon lähetettyjen pakettien tai tavujen suhteellinen osuus ja sen perusteella jakaa kustannukset eri aliverkkojen kesken. Mikäli halutaan tarkempaa laskutusta, voidaan mittausyksikkö konfiguroida niin, että se muodostaa kaikista runkoverkon paketista tietovuon, joka sisältää lähde- ja kohdelaitepareja, joista voidaan edelleen tarkemmin suorittaa laskutusta. Runkoverkossa voi olla erilaisia palveluja tarjoavia laitteita, joiden käytön laskutus voi vaihdella. Samalla informaatiolla voidaan myös suorittaa eri aliverkkojen välistä laskutusta, kun tiedetään aliverkkojen välisen liikenteen jakautuminen eri laitteiden kesken.
Verkon käytön valvontaa, perusteita ja politiikkaa kuvataan tarkemmin dokumenteissa [RFC1262], [RFC1272] ja [RFC1346].
Kokoonpanon hallinnassa käytettävä tieto kuvaa verkonhallinnan kannalta oleellisten resurssien tyypin ja tilan. Se kuvaa myös resurssien määrittelyn, sekä kunkin resurssin hallintaan tarvittavat attribuutit. Vaikka kaiken tarvittavan informaation on oltavat verkonhallinnan saatavissa, varsinaiset tiedot sijaitsevat yleensä hallittavassa laitteessa itsessään.
Laitteiden resursseja kuvaaviin attribuutteihin kohdistuvat toimenpiteet voidaan jakaa kolmeen ryhmään. Ensimmäiseen ryhmään kuuluvat ne toimenpiteet, jotka eivät vaikuta laitteen toimintaan. Eräs tällainen toimenpide on laitteesta vastaavan henkilön yhteystietojen muuttaminen. Toiseen ryhmään kuuluvat toimenpiteet, joiden avulla muutetaan laitteen jotain ominaisuutta kuvaavan olion arvoa ja siten vaikutetaan laitteen toimintaan. Voidaan esimerkiksi asettaa verkossa olevan laitteen jonkin verkkoliitynnän tilaa kuvaava tieto (attribuutti) sellaiseksi, että kyseinen liityntä ei enää ole käytössä. Kolmas ryhmä koostuu toimenpiteistä, joilla laite saadaan suorittamaan jokin haluttu toiminto, kuten käynnistämään itsensä uudelleen.
Pienissä verkoissa kokoonpanon hallinta ei juurikaan vaadi huomiota osakseen. Lähinnä verkkoa laajennettaessa tulee esiin toimintoja, joita tarvitaan verkon laitteiden toiminnan uudelleen määrittelemiseksi.
Laajoissa verkoissa yleisin kokoonpanon hallintaan liittyvä toimenpide on reititystietojen ylläpitäminen. Reititystietojen muuttaminen saattaa olla tarpeen esimerkikisi päivittäisten ruuhkahuippujen liikenteen tasaamiseksi tai jonkin vikaantuneen laitteen aiheuttamien häiriöiden vaikutuksen minimoimiseksi.
Yleisesti voidaan kuitenkin sanoa, että kokoonpanon hallinta ei ole pelkästään laitteiden tietojen ja toimintojen muuttamista. Kokoonpanon hallinnan toteutus vaatii hyvin usein pohjatiedoiksi vikojen ja suorituskyvyn valvonnasta saatavia raportteja ja analyyseja.
Passiivisista uhkista voidaan erottaa kaksi eri tyyppistä riskiä. Ensimmäinen on verkossa liikkuvan tiedon kaappaaminen. Kaappaamalla verkossa liikkuvia paketteja, voidaan niiden sisältö lukea ja saada selville esimerkiksi verkon käyttäjien luottamuksellisia tietoja. Toinen riski liittyy verkossa kulkevan liikenteen analysointiin. Vaikka siirrettävä tieto olisi salattua, voidaan joissain tapauksissa viestien pituuden ja liikenteen määrän perusteella tehdä arvauksia siirrettävän tiedon laadusta.
Passiivisia uhkia on hyvin vaikea havaita, sillä niissä ei millään tavalla muuteta siirrettävää tietoa tai estetä tiedon liikkumista. Niinpä lähes ainoa keino torjua passiivisten uhkien aiheuttamia vahinkoja on suojata tieto, eikä niinkään yrittää havaita mahdollisia hyökkäyksiä.
Aktiivisista uhkista voidaan muodostaa kolme ryhmää. Ensimmäinen on siirrettävän tiedon muuttaminen (modification). Tämä tarkoittaa yksinkertaisesti sitä, että viestin jotain osaa muutetaan, tai viestejä viivytetään, uudelleenlähetetään tai järjestetään uudelleen, niin että saadaan aikaan haluttu auktorisoimaton toiminto. Toinen uhkatyyppi on palvelun estäminen, joka joko estää kokonaan tai huomattavasti vaikeuttaa verkon normaalia käyttöä. Tämänkaltaisella hyökkäyksellä voidaan yrittää esimerkiksi katkaista jotkut tietoliikenneyhteydet tai kuormittaa verkkoa joillain viesteillä niin, että verkon suorituskyky laskee huomattavasti. Kolmas aktiivisen uhkan muoto on naamioituminen, jossa yritetään esittää jotain auktorisoitua viestin lähettäjää halutun palvelun tai toiminnon aikaansaamiseksi.
Aktiivisten uhkien luonne on miltei päinvastainen verrattuna passiivisiin uhkiin. Passiivisten uhkien havaitseminen on vaikeata, mutta niiden torjuminen on suhteellisten helppo. Aktiiviset uhkat on suhteellisen helppo havaita, mutta niiden totaalinen estäminen on huomattavan vaikeata. Estäminen vaatisi kaikkien yhteyksien fyysistä suojaamista ympäri vuorokauden. Aktiivisten hyökkäysten käsittelyssä pyritään lähinnä havaitsemaan ne ja toipumaan niiden aiheuttamista häiriöistä tai viiveistä.
Erilaisten salausmekanismien ja havaintomekanismien toteuttaminen saattaa useissa tapauksissa olla hyvin hankalaa. Se voi vaatia verkon rakenteen tai käytettävien yhteyskäytäntöjen radikaalia muutosta. On kuitenkin olemassa hyvin yksinkertaisia keinoja parantaa verkon turvallisuutta.
Joissakin reitittimissä on esimerkiksi mahdollisuus suodattaa (filter) paketteja niiden lähdeosoitteen perusteella. Eräät reitittimet tarjoavat tämän palvelun jopa niin, että tietyn tyyppisten pakettien reititys voidaan estää haluttujen aliverkkojen väliltä. Turvallisuuden kannalta kriittiset laitteet voidaan sijoittaa omaan aliverkkoonsa ja estää esimerkiksi organisaation ulkopuolelta tulevien pakettien reititys kyseiseen aliverkkoon.
Toinen mahdollisuus, joka sekään ei yleensä vaadi suuria muutoksia olemassaoleviin järjestelmiin, on yhteyspyyntöjen identifiointi ennen yhteyden avaamista. Kun palvelupyyntö saapuu, tarkistetaan, onko pyynnön esittävällä laitteella oikeutta saada pyydetty palvelu, ennen kuin yhteys avataan. Kaikki palvelupyynnöt ja niiden lähettäjät kirjataan lokiin, jota seurataan säännöllisesti.
Verkonhallintajärjestelmän toteutukselle ei ole mitään tiettyjä sääntöjä. Seuraavat asiat on kuitenkin syytä ottaa huomioon toteutusta suunniteltaessa [Leinwand93a]:
Yleisesti ottaen ohjelmiston rakenne voidaan jakaa kolmeen osaan, kuten kuvassa 5 esitetään:
Kuvan keskellä on monimutkaisempi kokonaisuus, joka esittää verkonhallintaohjelmistoa. Sen ylimmällä tasolla ovat eri verkonhallinnan osa-alueita tukevat ohjelmat, jotka tarjoavat palveluita käyttäjälle. Keskellä on joukko yleiskäyttöisiä, hyvin yksinkertaisia sovelluksia, jotka voivat suorittaa esimerkiksi erilaisia laskentarutiineja. Alimpana keskimmäisessä osassa on varsinainen verkonhallintaprotokolla, jonka avulla ohjelmisto kommunikoi verkon laitteiden kanssa.
Alimpana näkyvät ohjelmistot, jotka tarjoavat tietokantapalvelut verkonhallintaohjelmisolle sekä tiedonsiirron alemman tason yhteyskäytännön palvelut verkonhallintaprotokollalle.
Keskitetyssä arkkitehtuurissa on yksi suuri järjestelmä, joka hoitaa kaikki verkonhallinnan osa-alueisiin liittyvät toimenpiteet. Myös kaikki verkkoon liittyvä informaatio pidetään keskitetysti yhdessä tietovarastossa. Keskitetyn järjestelmän suurin ongelma on sen jäykkyydessä. Tällaisen järjestelmän muokkaaminen omia tarpeita vastaavaksi voi olla hyvin vaikeata. Keskitetty järjestelmä on myös hyvin haavoittuva, yhden osan vioittuminen saattaa pysäyttää koko verkonhallinnan.
Hajautetussa järjestelmässä on useita hallintajärjestelmiä, jotka samanaikaisesti tarkkailevat verkkoa. Järjestelmien välinen työnjako voidaan esimerkiksi määritellä verkon maantieteellisen jaon perusteella. Tämä ei kuitenkaan ole ainoa mahdollinen jakoperuste, vaan hallittavat laitteet voidaan jakaa eri järjestelmille myös laitteiden tyypin perusteella tai jollain muulla parhaaksi katsotulla perusteella. On kuitenkin huomattava, että vaikka hajautetussa järjestelmässä tiedon käsittely jaetaan useiden hallintajärjestelmien kesken, voi keskitetty tiedon varastointi olla erittäin hyödyllinen kokonaisuuden kannalta. Hajautetussa järjestelmässä on useita etuja. Se on hyvin joustava ja sitä on suhteellisen helppo laajentaa verkon kasvun mukana. Hajautetussa järjestelmässä myös verkonhallinnan aiheuttaman liikenteen määrä saadaan minimoitua. Suurin osa hallintainformaation aiheuttamasta liikenteestä on ainoastaan paikallista.
Kolmas mahdollinen arkkitehtuurityyppi yhdistää keskitetyn ja hajautetun järjestelmän metodit hierarkkiseksi arkkitehtuuriksi [Leinwand93a]. Tässä arkkitehtuurissa on keskusjärjestelmä hierakian juurena. Tämä keskusjärjestelmä kokoaa kaiken oleellisen informaation ja tarjoaa mahdollisuuden päästä käsiksi jokaiseen verkon osaan. Keskusjärjestelmän alaisuudessa voi siten toimia useita rinnakkaisia järjestelmiä, kuten hajautetussa arkkitehtuurissakin, joille keskusjärjestelmä voi delegoida verkonhallinnan osatehtäviä. Tällainen yhdistelmä on hyvin tehokas ja tarjoaa joustavan rakenteen verkonhallintajärjestelmän toteuttamiselle.
Ihannetapauksessa verkonhallintajärjestelmän ulkoinen arkkitehtuuri kuvastaa järjestelmää käyttävän organisaation rakennetta. Mikäli organisaation hallinto on keskitetty yhteen paikkaan, voi keskitetty verkonhallintajärjestelmä olla soveliain lähestymistapa verkonhallintaan. Toisaalta, jos organisaatio on hyvin litteä, eli hajautettu, voi hajautettu verkonhallintajärjestelmä olla kaikkein paras vaihtoehto.
