Yhden valmistajan infrastruktuuri

Lukuaika 4 min

Perinteinen malli tietoteknisen infrastruktuurin rakentamisessa on ollut jakaa kokonaisuus teknologia-alueisiin ja hankkia kuhunkin omiin tarpeisiin parhaiten soveltuva teknologia – käytännössä siis valmistaja tai joissakin tapauksissa kaksi eri valmistajaa.

Tämä on tyypillisesti johtanut tilkkutäkkimäiseen kokonaisuuteen, jossa kaikki tekeminen hajaantuu usean eri järjestelmän kesken.

Tyypillisesti osaaminen muodostuu kaikkea rajoittavaksi tekijäksi – kun järjestelmiä on useita, ei yhdenkään täydelliseen hallintaan riitä aikaa tai muistikapasiteettia. Näin käyttöön otetaan tyypillisesti ainoastaan perusominaisuudet ja hyvänkin teknologian erinomaiset lisämahdollisuudet jäävät käyttämättä.

Lisäksi järjestelmien kesken on hyvin vähän integraatiota, joka johtaa siilomaiseen toimintamalliin.

Keskusteltuani eri asiakkaiden kanssa, syitä tähän malliin on yleensä kolme. Ensimmäinen liittyy teknologian soveltuvuuteen omiin tarpeisiin. Tyypillisesti tämän osalta eri valmistajat ovat esitelleet omien ratkaisuidensa paremmuutta muihin tuotteisiin verrattuna ja sitä kautta rakentaneet kivijalan, josta ponnistetaan tarjouskilpailun voittoon.

Toiset kaksi liittyvät monivalmistajastrategiaan, jonka kulmakivinä ovat ”jos valitaan vain yksi valmistaja, nostaa se hintoja heti kun ratkaisu on tehty” ja ”jos valmistaja poistuu markkinasta, ollaan pulassa”. Ensimmäisen osalta en ole yli 20 vuoden uralla nähnyt konkreettista esimerkkiä siitä, että hintoja olisi pystytty nostamaan sopimuskauden aikana.

Pikemminkin päin vastoin – mitä pidempi sopimus, sen enemmän hinnat laskevat. Toisen osalta vuosien varrella on toki nähty konkursseja ja tuotelinjojen lopetuksia, mutta jos perusinfrastruktuuri hankitaan vuosikymmeniä toimivilta vakavaraisilta valmistajilta, on tällaisen vaara hyvin pieni.

Perinteisen mallin perustelujen kestämättömyyden lisäksi ongelmaksi nousee sen istumattomuus nykyajan vaatimuksiin. Klassinen toimintatapa pohjautuu hyvin pitkälle komentorivipohjaiseen konfigurointiin ja vaikka olisi kuinka taitava, tulee sen kanssa helposti rajat vastaan.

Manuaalinen konfiguraatioiden syöttäminen on hidasta ja virheherkkää. Jos yhden toiminnallisuuden määrittäminen yhteen laitteeseen ottaa vaikkapa viisi minuuttia, menee 1000 laitteen verkossa aikaa yli kaksi työviikkoa. Ja koska organisaatioiden toiminnalliset muutokset tapahtuvat koko ajan ripeämmällä tahdilla, on infrastruktuuriosasto tyypillisesti aina jäljessä tekemisen suhteen.

Virheherkkyys korostuu erityisesti nykyisessä tietoturvaympäristössä, jossa yksikin väärin konfiguroitu kokonaisuus voi luoda tietoturva-aukon, jonka kautta organisaation verkkoon ja sitä kautta tietoihin voidaan päästä käsiksi. Ja on turha sanoa, että ”me emme tee virheitä”. Varmasti teette, se kuuluu ihmisen toimintaan.

Koodauspuolella arvioidaan, että jokaista 1000 koodiriviä kohtaan luodaan 70 bugia. Jos edellisen esimerkin mukaisesti arvioidaan, että jokaiseen 1000 laitteeseen tehdään yksi määritysrivi, niin 70 niistä on virheellisiä. Tämä voi hyvin pitää paikkaansa, erityisesti jos rivillä on muuttuvia parametrejä, kuten IP-osoitteita.

Perinteisessä maailmassa valvonnan puolella tyypillinen on pollauspohjainen malli, jossa ei kiinnitetä huomiota infrastruktuurin tarjoamaan palveluun, vaan siihen, että laitteet ja liitynnät ovat elossa.

Normaaleja mekanismeja tässä ovat ping-valvonta, SNMP-pollaus (Simple Network Management Protocol) ja syslog-ilmoitusten kerääminen (ja joskus myös analysointi). Jotkut kehittyneemmät tahot saattavat hyödyntää lisäksi esimerkiksi vuopohjaisen informaation keräämistä ja raportointia, sekä verkkolaitteiden aktiiviagenttien käyttämistä.

Valitettavasti vikatilanteissa näistä on ainoastaan indikaattoreiksi, ei avustamaan selvitys- ja korjaustyössä. Nämä osa-alueet ovat jokaisen verkkoinsinöörin harteilla ja ne sujuvat osaamisesta ja kokemuksesta riippuen loppukäyttäjän näkökulmasta hitaasti, hyvin hitaasti tai erittäin hitaasti.

Nykyaikainen verkko perustuu keskitettyyn kontrollerimallin, jossa kaikki osa-alueet ovat ohjelmisto-ohjattuja ja pystyvät kommunikoimaan keskenään.

Tällainen on esimerkiksi Ciscon ”SD-Enterprise” -malli, jossa kolme keskeistä teknologia-aluetta – lähiverkko, laajaverkko ja konesali ovat konvergoitumassa kohti yhtä kokonaisuutta.

Perusajatuksena on, että kutakin osa-aluetta ohjataan ja pyöritetään omilla keskuskomponenteilla – lähiverkkoa Cisco DNA Center-, laajaverkkoa vManage- ja konesalia APIC-kontrollerilla. Näiden kesken toteuttavalla integraatiolla pystytään tekemään asioita, joita perinteisillä työkaluilla voidaan vain haaveilla.

Kontrolleripohjaisen mallin edut jakautuvat kahteen osa-alueeseen – hallinta ja valvonta. Hallinnan osalta kontrollerin mahdollistama automaatio avaa uusia tapoja pyörittää infrastruktuuria. Esimerkiksi konfiguraation osalta jokaisen laitteen erillisen hipelöinnin sijasta haluttu konfiguraatio määritetään kontrollerille, joka levittää sen kaikkiin verkkolaitteisiin lähes reaaliaikaisesti.

Toisena esimerkkinä voisi ottaa ohjelmistopäivitykset, jotka tyypillisessä ympäristössä ovat erittäin haastavia. Modernissa kontrollerissa voidaan päivitykset tehdä erillisen työnkulun kautta, jossa ensin tarkistetaan päivitettävien laitteiden soveltuvuus päivitykseen, toisena määritetään haluttu ohjelmisto ja kolmannessa ajastetaan päivitys haluttuun ajankohtaan.

Myös valvonta nousee kontrolleripohjaisessa infrastruktuurissa täysin omalle tasolleen. Siinä voidaan erottaa kolme osa-aluetta. Ensimmäinen on puskupohjainen telemetriatiedon kerääminen infrastruktuurin komponenteilta kontrollerille (niin sanottu Streaming Telemetry).

Kontrollerille rakennetun älykkyyden ansiosta tiedosta voidaan muodostaa reaaliajassa erilaisia hälytyksiä vaikkapa vikatilanteissa tai syväluotaavia raportteja verkon tilasta. Esimerkiksi Ciscon DNA Centerin Assurance -osiossa tietoa jalostetaan kolmeen eri kokonaisuuteen; Lähiverkon laitteiden tila, päätelaitteiden tila ja sovellusten tila.

Toinen kokonaisuus on vianselvityksessä avustaminen. Tämän avulla ongelmatilanteissa kontrolleri pystyy ohjaamaan verkkoinsinöörin työtä ja täten auttaa palvelun palauttamisessa ja lopulta ongelman korjaamisessa. Näin kaikki ei ole yksittäisen henkilön harteilla, vaan kontrollerille voidaan kerätä tuhansien oikean elämän tapausten työnkulkua ja sitten helpottaa tekemistä.

Kolmas osa-alue on pilvipohjaisen tekoälyn – eli älykkäiden algoritmien – käyttäminen ympäristön tarkasteluun vertailuun muiden kanssa. Tämän avulla saadaan parempi ymmärrys oman ympäristön toiminnasta ja pystytään tekemään erilaisia optimointeja.

Merkittävää kolmen teknologia-alueen ratkaisussa on niiden integraatio kohti yhtä kokonaisuutta. On vaikea nähdä, että kontrollerielementit laitettaisiin yksiin kuoriin, mutta sovelluskehitysrajapintojen kautta niiden keskinäinen kommunikaatio mahdollistaa erilaisten ominaisuuksien levittämisen laajemmalle.

Esimerkiksi lähiverkon kontrolleri kommunikoi laajaverkon kontrollerin kanssa tarvittavan konfiguraation määrittämiseksi toimipisteiden reunalaitteisiin. Tai lähiverkon kontrolleri kommunikoi konesalin kontrollerin kanssa mikrosegmentoinnin mahdollistamiseksi päästä päähän. Tämä taas helpottaa tietoturvapolitiikkojen määrittämisessä.

Laaja integraatio auttaa myös näkyvyyden suhteen, vaikka toki jokaisella alueella onkin omat työkalut sen mahdollistamiseksi.

Mitä vahvemmaksi integraatio tulee, sen helpompi ylläpitäjän on tehdä määrityksiä teknologia-alueiden läpi ja hahmottaa myös kokonaisuuden toimintaa. Tämä tekee tekemisen yksinkertaisemmiksi ja tehokkaammiksi, sekä helpottaa vianselvityksessä.

Vaikka perinteisen teknologia-aluekohtaisen valmistajan valinnan tekemisen koulukunnalla on edelleen vahva kannatus, uskon että tilanne muuttuu tulevaisuudessa edellä esitettyjen seikkojen johdosta. Tämän vuoksi jokaisessa uusimistilanteessa kannattaa henkäistä hetki ja pohtia, mikä olisi paras vaihtoehto kokonaisuuden kannalta.

Jos sitten päädytään ottamaan eri valmistajien teknologiaa käyttöön eri osa-alueille, on se tietoinen valinta ja sen taustalla on ymmärrys, mitkä ovat ratkaisun varjopuolia.

Jos taas lopputuloksena on tavoitetila kohti yhden valmistajan infrastruktuuria, ollaan otettu ensimmäinen askel kohti yksinkertaisempaa, automatisoitua ja näkyvää verkkoa.

Haluatko keskustella lisää tulevaisuuden infrastruktuurin ratkaisuista, ota reilusti yhteyttä. Ja jos et vielä ole tutustunut syksyn Elisa ICT Day -ohjelmaan, katso ohjelma ja ilmoittaudu mukaan!