Ostatko konesalipalvelua ulkoistuskumppanilta? Mietitkö mitä tehdä jatkon suhteen: Kannattaisiko vain jatkaa kuten ennenkin vai kannattaisiko konesali siirtää julkipilveen?
Vai oletko uudistamassa konesalin verkkolaitteita ja mietit, miltä verkon tulisi näyttää, jotta konesalista saataisiin paremmin pilvikelpoinen?
Käsittelen tässä kirjoituksessa neljää (4) ongelmaa, mitkä liittyvät perinteisen konesaliverkon rakenteeseen.
Tämä kirjoitus on osa pilviajan tietoliikennettä käsittelevää kirjoitussarjaa. Ensimmäinen artikkeli käsitteli aihetta Mikä on Software Defined Networking (SDN) ja mitä hyötyä siitä on?
Kirjoitus on kohtuullisen tekninen, mutta siltä ei oikein voi välttyä, jos haluaa ymmärtää kunnolla, miten pilvi toimii.
Aloitetaan kuitenkin siitä, millainen on perinteinen konesalin verkkoarkkitehtuuri.
Perinteisen konesaliverkon rakenne
Konesaliverkkoja on rakennettu 90-luvun loppupuolelta lähtien hyvin samalla kaavalla. Oheinen kuva esittää perinteistä tapaa rakentaa verkkoja. Konsepti perustuu 3-tasoiseen malliin, jossa on
- Kytkentätaso (Access), johon palvelimet kytketään (Layer 2)
- Kokoava taso (Aggregation), joka yhdistää kytkentätason laitteet (Layer 2/ Layer 3)
- Ydin (Core), joka osaa reitittää liikennettä ulkomaailmaan (Layer 3)
Verkot ovat pitkään olleet variaatioita tästä suunnitteluperiaatteesta. Pienemmissä ympäristöissä Aggregation- ja core -tasot on usein yhdistetty ja monesti reitittimet on korvattu palomuurilla, joka toimii sisäverkon suuntaan default gatewayna.
Eihän tässä rakenteessa voi olla mitään isompia ongelmia, koska rakenne on niin laajalti levinnyt. Vai voisiko sittenkin? Käsitellään seuraavaksi ongelmia yksi kerrallaan.
Ongelma nro 1: Perinteinen verkkoarkkitehtuuri haaskaa resursseja
Koska alempi osa toimii layer 2 -tasolla eli se ei reititä, tämä osa verkosta ei osaa valita reittiä, jos vaihtoehtoja on useampia kuin yksi. Jos reittejä on kaksi, muodostuu verkkoon silmukka eli looppi, joka sekoittaa verkon toiminnan.
Koska Layer 2 -verkoissa pitää välttää loopeja hinnalla millä hyvänsä, kaikkea verkkolaitteiden kapasiteettia ei saada käyttöön. Mistä on kyse? Otetaan esimerkki.
Tietokantojen ja sovellusten klusteroinnissa puhutaan usein aktiivi-aktiivi-klusterista ja aktiivi-passiivi-klusterista. Aktiivi-aktiivi-klusterissa klusterin molemmat noodit osallistuvat työkuormien käsittelyyn, kun taas aktiivi-passiivi-klusterissa vain toinen noodeista tekee työtä. Passiivinen noodi vain odottelee, josko aktiivinen noodi vikaantuisi.
Koska klusterit ovat kalliita, pyritään yleensä aktiivi-aktiivi-toteutuksiin, jos se vain on mahdollista.
Perinteisellä tavalla toteutettu verkko toimii vain aktiivi-passiivi-klusterina eli se haaskaa resursseja.
Perinteisellä tavalla toteutettu verkko toimii vain aktiivi-passiivi-klusterina eli se haaskaa resursseja, jos verkkolaitteiden voisi ajatella toimivan klusterissa.
Tätä ei ole pidetty ongelmana, koska verkkolaitteet ovat niin suorituskykyisiä, että pienemmissä palvelinkeskuksissa resurssit riittävät, vaikka niitä käytetään tehottomasti.
Isoissa palvelinkeskuksissa, kuten suurissa pilvikonesaleissa tällainen ei kuitenkaan vetele. Siellä verkot toteutetaan eri tavoin.
Tarkastellaan seuraavaksi toista ongelmaa, joka perinteisellä tavalla toteutettuun verkkoon liittyy.
Ongelma nro 2: Iso osa ympäristöä lamaantuu verkon vikaantuessa
Yksi IT-järjestelmien suunnitteluperiaate on rakentaa ne sellaisiksi, että yhden komponentin vikaantuminen vaikuttaa kokonaisuuteen mahdollisimman vähän.
Tällöin puhutaan vikaantumisalueen (failure domain) koosta. Vikaantumisalueesta pyritään siis rakentamaan mahdollisimman pieni.
Kun tarkastellaan perinteisen verkon vikaantumisaluetta, se ei näytä kovin hyvältä.
Jos esimerkiksi verkkolaitteiden välillä on kaksi linkkiä, jotka on yhdistetty (aggregoitu), yhden linkin menettäminen puolittaa verkon kapasiteetin. Mitä lähempänä corea linkki vikaantuu, sitä suurempi osa kaistasta menetetään.
Toinen esimerkki vikaantumisalueen suuruudesta on looppien synnyttämä broadcasting-myrsky. Aina välillä verkkoon syntyy silmukka, joka saa aikaan pakettimyrskyn, joka kuluttaa verkon koko kapasiteetin. Tällöin koko verkko voi lamaantua.
Perinteinen verkko ei siis pärjää kovin hyvin, jos tarkastellaan failure domainin kokoa.
Ongelma nro 3: Virtuaaliverkkojen (VLAN) konfigurointi on hankalaa
Yksi erityisesti palveluntarjoajia koskeva ongelma liittyy virtuaalilaneihin eli VLAN-verkkoihin.
Palveluntarjoajille asiakkaat sijoitetaan eri VLAN-verkkoihin, jotta ne eivät näkisi toistensa ympäristöjä. Kyse ei varsinaisesti ole tietoturvatekniikasta, mutta koska parempaakaan kustannustehokasta ratkaisua ei ole ollut käytössä, tällä on menty.
VLANiin liittyy montakin ongelmaa, mutta tässä pari keskeistä pilvipalveluihin liittyvää:
- VLANien konfigurointi on työlästä. Jotta VLANeihin perustuva verkko toimisi oikein, pitää kaikkien kytkinten tietää jokaisesta VLANista. Tämän vuoksi niiden konfigurointi on hidasta. Tästä johtuen verkkoasiantuntijat eivät ole kovin innostuneita, jos VLANit muuttuvat jatkuvasti. Pilvimaailmassa asiakkaat kuitenkin odottavat, että verkot konfiguroidaan silmänräpäyksessä. Verkot myös muuttuvat jatkuvasti. VLAN-tekniikka ei siis toimi kovin hyvin pilviympäristössä.
- Verkkojen määrä on rajallinen. Koska VLANin kuvaamiseen käytetään 12 bittiä, palveluntarjoajalla on yhdessä ympäristössä käytössään enintään 4096 eri virtuaalilania. Isoissa asiakasympäristöissä tämä muodostuu ongelmaksi, jota joudutaan kiertämään rakentamalla useita rinnakkaisia ympäristöjä. Siksi pilvipalvelujen tarjoajat haluavat käyttää muita tekniikoita.
Lisäksi VLANien tietoturva ei ole täydellinen. VLANin tietoturva perustuu siihen, että kytkin toimii juuri niin kuin halutaan. Eri asiakkaiden liikenne kulkee samassa kytkimessä ja on täysin kytkimen toiminnan varassa, että asiakkaiden paketit eivät päädy toisten verkkoihin. Toki yleisesti ajatellaan, että VLANien käsittely on suhteellisen luotettavaa (jos kytkimen ohjelmistosta ei löydetä virhettä…)
SDN-verkot toimivat tässä suhteessa eri tavoin. Voit lukea asiasta tarkemmin täältä.
Perinteisen verkon ongelmat eivät pääty tähän. Seuraava ongelma on vähintään yhtä perustavaa laatua oleva kuin VLAN-ongelma. Mistä on kyse? Lue eteenpäin, niin saat tietää.
Ongelma nro 4: Perinteinen verkko sopii huonosti mikropalveluihin
Perinteinen verkko on saanut muotonsa aikana, jolloin sovellukset perustuivat pääasiassa client-server-arkkitehtuuriin.
Client-server-arkkitehtuurissa verkkoliikenne on pääasiassa pohjois-etelä-suuntaista. Oheinen kuva näyttää esimerkkiä tällaisesta liikenteestä.
Kuvan mukainen client-server-arkkitehtuuri perustuu monoliittisiin sovelluksiin. Monoliittinen sovellus on yksi iso kokonaisuus, joka sisältää kaiken sovelluksen toiminnallisuuden.
Nykyään sovelluskehityksessä pyritään kuitenkin mikropalveluarkkitehtuuriin, jossa iso sovellusmöhkäle on pilkottu moneen pieneen palveluun, joista jokainen toteuttaa yhden sovelluksen tarvitseman toiminnallisuuden.
Jos haluat lukea lisää mikropalveluarkkitehtuurista, voit lukea kirjoitukseni Mitä mikropalvelut ovat?
Vaikka mikropalvelut ovat sovellusten kannalta hyvä juttu, perinteiselle verkolle ne tuottavat ongelmia. Miten niin?
Katso oheista kuvaa. Mitä tapahtuu, kun yhden käyttäjän tekemän kyselyn vastaus muodostetaan monen palvelun yhteistyöllä?
Kun sovellus toteutetaan mikropalveluilla, generoi se verkkoon huomattavan määrän konesalin sisäistä liikennettä.
Usein eri komponentteja sijoitetaan eri verkkoihin, jolloin liikenteen on pakko kiertää reitittävän kerroksen kautta. Jos yhtälöön lisätään palomuureja ja kuormantasausta, jotka toteutetaan yleensä tähän suunnitelluilla laitteilla eli applianceilla, liikenneprofiilista voi tulla hyvin monimutkainen.
Yksittäisten laitteiden, kuten palomuurin, suorituskyky tulee vastaan nopeammin, kun sovelluksia toteutetaan mikropalveluilla.
Ydin tässä on se, että perinteisen verkon ja sen yksittäisten laitteiden, kuten palomuurin, suorituskyky tulee vastaan nopeammin, kun sovelluksia toteutetaan mikropalveluilla.
Suorituskykyongelma voi tulla vastaan yllättävän nopeasti ihan tavallisissakin IT-ympäristöissä, mutta erityinen ongelma tämä on isoissa pilviympäristöissä, joissa sovellukset voivat olla todella isoja.
Tässä kohtaa voi tulla mieleen päästää liikenne läpi ilman sen ihmeempiä suodatuksia, koska sehän auttaa palomuurin suorituskykyongelmaan.
Jossain vaiheessa tulee vastaan piste, jossa esimerkiksi perinteisesti appliance-palomuurissa tehdyt suodatukset on pakko hajauttaa rautapalomuurista lähemmäs palvelimia.
Yhteenveto
Perinteisessä verkkoarkkitehtuurissa on useita ominaisuuksia, joiden vuoksi ne eivät ole optimaalisia pilviympäristöissä.
Monesti suomalaisten organisaatioiden ympäristöt ovat niin pieniä, että näiden ongelmien kanssa selvitään ainakin kapasiteettimielessä.
Kuitenkin mitä isompi ympäristö on kyseessä, sitä enemmän näitä asioita joutuu miettimään. Tällä hetkellä toimiva verkko voi muuttua liian hitaaksi, kun sovellukset alkavat generoimaan yhä enemmän itä-länsisuuntaista liikennettä.
Perinteisesti kapasiteettitarpeeseen on aina pystytty vastaamaan laitesukupolvien suorituskyvyn kasvun myötä. On tietysti laitevalmistajien etujen mukaista myydä aina tehokkaampia palomuureja ja verkkokomponentteja. On kuitenkin olemassa ratkaisuja, jotka skaalaavat aivan eri luokkaan kuin erillinen palomuuri, jonka kautta kaikki liikenne kierrätetään uudestaan ja uudestaan.
Vaikka kapasiteetti ei muodostaisikaan ongelmaa, VLAN-verkkojen hidas konfiguroitavuus muodostaa helposti ongelman ainakin sovelluskehittäjien ja muiden verkkoa tarvitsevien mielestä.
Koska julkipilvestä saa verkkoja ja kokonaisia ympäristöjä nopeasti, ei verkkojen konfiguroimiseen saisi mennä aikaa omassa konesaliverkossakaan. Tämä voi muodostua todelliseksi ongelmaksi perinteisille palveluntarjoajille.
Jotta konesalipalvelun tarjoajat pystyvät olemaan kilpailukykyisiä, pitää myös verkot rakentaa pilvikelpoisiksi. Niiden pitää mahdollistaa automaattinen (ohjelmallisesti) tapahtuva konfigurointi.
Mikä sitten ratkaisuksi? Tilaa uutiskirjeeni, niin saat ilmoituksen, kun julkaisen seuraavan tähän sarjaan kuuluvan kirjoituksen. Kerron seuraavassa verkkoja käsittelevässä kirjoituksessani siitä, miten pilviympäristössä rakennetaan verkkoja.