1(60)
TEKNILLINEN KORKEAKOULU Sähkö-ja tietoliikennetekniikan osasto
Antti Aarnio
TIETOLIIKENTEEN KAPASITEETTITARPEEN ARVIOINTIMETODIIKKA PALVELINKONSOLIDOINNIN YHTEYDESSÄ
Diplomityö, joka on jätetty opinnäytteenä tarkastettavaksi diplomi-insinöörin tutkintoa varten Espoossa___ .___ .____
Työn valvoja Professori Antti Ylä-Jääski Työn ohjaaja Martti Airas, Novo Group
TEKNILLINEN KORKEAKOULU DIPLOMITYÖN TIIVISTELMÄ
Tekijä: Antti Aarnio Työn nimi:
Tietoliikenteen kapasiteettitarpeen arviointimetodiikka palvelinkonsolidoinnin yhteydessä
Päivämäärä: 7.8.2003
Sivumäärä: 60 Osasto:
Sähkö- ja tietoliikennetekniikan osasto Professuuri:
Tietoliikenne- ja tietojenkäsittelytekniikka Työn valvoja: Professori Antti Ylä-Jääski Työn ohjaaja: Martti Airas, Novo Group Tiivistelmäteksti:
Työ käsittelee tietoliikennekapasiteetin etukäteisarviointia tietojenkäsittelyn infrastruktuurin muutostilanteissa. Palvelimien konsolidoinnin suunnittelun yhteydessä ei ole ollut julkista menetelmää, jonka avulla voidaan etukäteen selvittää suunniteltujen muutosten aiheuttamia vaikutuksia. Infrastruktuuriin tehtävät muutokset, kuten palvelimien liikuttelu eri verkon sijainteihin, muuttavat tietoliikenteen reittejä ja määrää, mikä aiheuttaa muutospaineita liikennettä välittävien verkon osien kapasiteetteihin. Etenkin suurissa
ympäristöissä tehtävät muutokset voivat olla vaikutuksiltaan monimutkaisia, jolloin niiden etukäteen tutkiminen vaatii tehokkaan menetelmän.
Työssä esitellään ratkaisu, joka mahdollistaa tietoliikenteen muutosten simuloimisen konsolidoinnin suunnittelun yhteydessä. Simuloinnista saatavien tulosten avulla voidaan arvioida ja vertailla erilaisten vaihtoehtoisten muutosten vaikutuksia tietoliikenteeseen ja
tietoliikennekapasiteetteihin. Tämän avulla voidaan arvioida muutosten vaatimia kustannuksia, minkä avulla saadaan tärkeää tukea taloudellisille päätöksille konsolidointiprojekteissa.
Avainsanat:
Tietoliikennekapasiteetti, konsolidointi, simulointi
HELSINKI UNIVERSITY OF TECHNOLOGY ABSTRACT OF THE MASTER'S THESIS
Author:
Antti Aarnio
Name of the Thesis:
Simulation methodology of the capacity demand in server consolidation Number of pages:
Date: 7.8.2003 60
Department:
Department of Electrical and Communications Engineering Professorship:
Telecommunication and data processing technology Supervisor: Professor Antti Ylä-Jääski
Instructor: Martti Airas, Novo Group Abstract:
There is little methodology in the server consolidation planning process, which could, in advance, solve effects caused by the planned changes.
Changes to the infrastructure, for example moving servers to different locations in network, cause changes to the amount of traffic and its route thus leading to new capacity demands within the network infrastructure. In large environments the changes can be complex therefore an efficient technique is required to inspect changes in advance.
This work presents a novel solution to simulate different consolidation changes and predict the wide area network infrastructure capacity. Simula
tion results can be compared and analyzed thereby allowing the cost of the change to be estimated. This information supports resulting financial decisions.
Keywords:
Capacity, server consolidation, simulation.
Alkulause
Kiitos työn valvojalle professori Antti Ylä-Jääskelle. Kiitos myös Martti Airakselle, joka antoi arvokkaita neuvoja työn sisältöön ja ohjasi sen tekoa.
Lisäksi erityiskiitokset Juhani Timoselle, joka opasti ja auttoi työn kokonaisuuden hahmottamisessa ja yleisissä tietoliikenneasioissa, sekä Veli Väisäselle, joka neuvoi konsolidoinnin perusteissa ja sen yleisessä prosessissa.
Päivämäärä Allekirjoitus
1 JOHDANTO 7
2 ONGELMAN KUVAUS 9
2.1 TYÖN YHTEYDESSÄ KÄYTETTÄVIEN TERMIEN SELITYKSET...9
2.2 TYÖSSÄ KÄSITELTÄVÄ ONGELMA... 10
2.2. 1 Konsolidoinnin seuraukset... 7 0 2.2.2 Muutosten vaikutukset ja niiden taloudellinen merkitys...10
2.2.3 Liittymätarpeiden arvioinnin epätarkkuus ilman simulointia....Il 2.3 TYÖN TARKOITUS... 12
2.4 Työnrajaukset... 13
3 KRITEERIT SIMULOINTIMALLIN JA SEN KÄYTÖN ARVIOIMISEKSI... 14
3.1 Mallinyleinensoveltuvuus... 14
3.2 TOPOLOGIAMUUTOSTEN HUOMIOIMINEN... 14
3.3 Liikenteentuottajienhuomioiminen... 15
3.4 Liikennemäärienohjautuminentoisiinsijoituskohteisiin...15
3.5 Mallinjasenkäytönyhteystodellisuuteen... 15
3.6 Mallistasaatavattuotokset...16
3.7 Kriteeritvalittavalletyökalulle... 16
4 YLEINEN MALLI (KONSOLIDOINNIN SUUNNITTELUPROSESSI) 18 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 Konsolidoinninsuunnitteluprosessinkulku... Suunnitteluntavoitteet... Tiedonkeruumenetelmät... Kyselytiedonyhdistäminenjaanalysointimenetelmät.... Kohteet, joihinkonsolidoinnillavaikutetaan... Konsolidoinninkustannusarvio... Suunnittelustasaataviaraportteja... Markkinoillaoleviamuitaratkaisuja... Simulointimallinsoveltaminensuunnittelunyhteyteen .18 .18 .19 .19 .20 „22 „24 „25 „25 5 IMPLEMENTAATIO .27 5.1 Muidenyritystenkeinotinfrastruktuurinmuutostenvaikutustenselvittämiseen. 5.1.1 Tutkimuslaitosten aineistosta... 5.1.2 Tietoliikenneoperaattoreiden haastattelut... 5.1.2.1 Haastattelujen päämäärä... 5.1.2.2 Tapaamisiin valmistautuminen... 5.1.2.3 Haastattelujen anti... 5.1.3 Suurten laitevalmistajien arviointimenetelmistä... 5.1.4 Yhteenveto muiden mallien puutteista ja ansioista... 5.1.5 Syitä käyttökelpoisten menetelmien puuttumiseen... 5.1.6 Oman työn uniikkiuden varmistaminen tutkimusten perusteella... 5.2 Simulointimallinluominen... 5.2.1 Simulointimallin rakentamiseen tarvittavat elementit... 5.2.2 Maliin laskennallinen osio tehtävänasetteluun nojautuen... 5.2.3 Simulointimallista poisjätettävät asiat verrattuna todelliseen tilanteeseen... 5.2.4 Liikenne- ja topologiatiedon hankkiminen simulointimalliin... 5.2.5 Simulointityökalu ja sen valintakriteerit... 5.2.6 Simulointimallin rakentaminen työkaluun... 5.2.7 Muutostilanteiden simuloiminen mallin avulla... 5.2.8 Simuloinnista saatavat tulokset ja niiden vertailu... 5.2.9 Esimerkki simuloinnin kulusta... ... 27
...27
...28
... 28
... 28
... 29
...30
...31
...31
...32
... 33
...33
...35
...36
...37
...39
...41
...43
...45
...46
6.3 Liikenteentuottajienhuomioiminen...51
6.4 Liikennemäärienohjautuminentoisiinsijoituskohteisiin... 52
6.5 Mallinjasenkäytönyhteystodellisuuteen...53
6.6 Mallistasaatavattuotokset... 54
6.7 Kriteeritvalittavalletyökalulle...54
7 JOHTOPÄÄTÖKSET...57
8 LÄHDELUETTELO... 59
9 LIITTEET...60
1 Johdanto
Konsolidoinnin kaltainen toiminta sisältyi tietotekniikan palvelutalojen tarjontaan jo 10 vuotta sitten, vaikka itse sanaa konsolidointi ei silloin vielä käytetty.
Tuolloin pyrittiin asiakkaiden tietojenkäsittelyn infrastruktuurin hallinnan tehostamiseen vakioimalla työasemia sekä uudelleen järjestelemällä tietyn roolin palvelimia. Näillä toimilla tähdättiin pääasiallisesti ylläpidon tarpeen vähentämiseen.
Vuonna 2001 alkoi uuden suunnittelupalvelun kehitystyö, jossa tarkistukset ja uudelleenjäijestelytoimet koskivat kaiken tyyppisiä palvelimia. Tällöin suunnittelua varten kohteena olevasta ympäristöstä tarvittavan tiedon sisältö piti määritellä uudelleen. Tarvittiin aiempaa enemmän tietoa, jotta muutoksista saatavia kustannussäästöjä voitaisiin ennustaa. Koska tarkastelu koski nyt useampia palvelinympäristöjä, myös muutokset ja niiden vaikutukset tämän myötä olivat suurempia ja monimutkaisempia. Suuren tietomäärän vuoksi kehitettiin ja automatisoitiin analysointimenetelmiä, joiden avulla kerättyä tietoa voitaisiin käsitellä helpommin ja tehokkaammin.
Suureen palvelinjoukkoon kohdistuvat toimenpiteet saattavat aiheuttaa monimutkaisia muutoksia verkkoon. Aiemmin nämä muutokset olivat vähäisempiä, koska siirrettäviä kohteita oli rajoitetumpi määrä. Muutosten vaikutusten ennustamiseen etukäteen ei ole ollut varsinaista menetelmää. Tämän takia alettiin kehittää verkkokapasiteetin simulointia, joka toimisi apuvälineenä konsolidoinnin suunnittelussa.
Simulointimenetelmä mahdollistaa kerättyjen tietojen paremman hyödyntämisen, mikä laajentaa suunnitteluvalmiutta ja antaa paremmat edellytykset konsolidoinnille. Menetelmällä haetaan entistä parempaa suunnittelutarkkuutta.
Erityisesti yritysten toimipisteiden liittymätarpeiden tarkempi ennustaminen antaa
yhteistyöhön tietoliikenneoperaattoreiden kanssa, kun suunnitellaan yhteyksiä ja muutetaan tietojenkäsittelyn infrastruktuuria.
2 Ongelman kuvaus
2.1 Työn yhteydessä käytettävien termien selitykset Simulointimalli
Malli, jonka avulla pyritään etukäteen selvittämään tietotekniikan infrastruktuurin muutoksista aiheutuvia vaikutuksia tietoliikenneliittymiin
Konsolidointi
Menettely, jossa laitteita, erityisesti palvelimia ja niiden tarjoamia suoritteita, sovelluksia, tietovarastoja sekä ylläpito- ja verkkopalveluja pyritään keskittämään, vähentämään ja yhdenmukaistamaan
Liittymä
Tietoliikenneyhteys toimipisteen ulkopuolelle, esimerkiksi palveluntarjoajan verkkoon
T ietoliikennekapasiteetti
Tietoliikennelinjan liikennekuorman välityskyky aikayksikössä, bittiä/sekunnissa.
Lähiverkko, LAN
Local Area Network, eli lähi- tai toimipisteverkko. Lähiverkko on joukko tietokoneita ja muita tietojenkäsittelylaitteita, jotka käyttävät samaa verkkotekniikkaa sekä jakavat toimipisteen yhteisiä resursseja
Laajaverkko, WAN
Wide Area Network. Tietoliikenneverkko, joka yhdistää lähiverkkoja Palvelimen rooli
Ilmaisee palvelimen tehtävän verkossa. Esimerkkejä rooleista ovat nimipalvelin,
2.2 Työssä käsiteltävä ongelma
Konsolidoinnin suunnittelusta on puuttunut apuväline, jonka avulla pystytään ennustamaan tietoliikenneliittymien kapasiteettitarpeita suunnitellun muutoksen jälkeen. Tämä puute vaikeuttaa konsolidoinnista aiheutuvien kustannusten
arviointia liittymien osalta.
2.2.1 Konsolidoinnin seuraukset
Konsolidoinnin suunnittelun tuloksena pyritään taloudellisiin säästöihin poistamalla, siirtämällä ja keskittämällä palvelimia ja niiden rooleja, sovelluksia sekä tietovarastoja. Suunnitellut muutokset saattavat aiheuttaa merkittäviä muutoksia tietojenkäsittelyn infrastruktuuriin [1].
Käyttäjä, joka käyttää verkossa olevia palvelimia ja sovelluksia, aiheuttaa tietoliikennettä verkkoon. Palvelimessa ajettavan sovelluksen tai suoritteen siirtäminen toiseen paikkaan verkon topologiassa muuttaa eri verkkoliittymien liikennekuormia, mikä saattaa vaikuttaa verkosta saatavien palveluiden toimivuuteen ja laatuun [2].
2.2.2 Muutosten vaikutukset ja niiden taloudellinen merkitys
Jokaisella verkkoliittymällä on kapasiteetti, eli maksimaalinen läpäisykyky, jonka verran liikennettä kyseisessä liittymässä on mahdollista kulkea. Muuttuneet liikennemäärät aiheuttavat muutospaineita liittymien kapasiteettitarpeisiin. Näiden muutosten seurauksena joidenkin liittymien kapasiteetti saattaa jäädä riittämättömäksi, jolloin syntyy ongelmia verkon tarjoamien palveluiden toiminnassa. Ongelmat johtavat siihen, että liittymien kapasiteetteja on mahdollisesti muutettava. Tämä aiheuttaa kustannuksia sekä itse muutoksen takia,
mutta myös tietoliikenneoperaattoreiden hinnoittelun takia. Operaattorit veloittavat enemmän yhteyksistä, joiden kapasiteetti on suurempi.
Palvelimen siirtämisessä korostuu se, mistä kyseistä palvelinta käytetään. Käyttö voi tapahtua joko samasta lähiverkosta tai laajaverkon yli. Palvelimen siirtäminen aiheuttaa käytännössä sen, että aiemmin samassa lähiverkossa palvelimen kanssa olleiden ja sitä käyttäneiden käyttäjien tuottama liikenne ohjautuu muutoksen jälkeen laajaverkkoon, jonka liikennemäärä tämän myötä kasvaa. Toisaalta taas aiemmin palvelinta laajaverkon yli käyttäneet saattavat muutoksen jälkeen saada kyseisen palvelimen omaan lähiverkkoonsa, jolloin tämän toimipisteen laajaverkkoliikenne pienenee. Nämä muutokset vaikuttavat tietoliikennekustannuksiin, sillä tyypillisessä yhteyshinnoittelussa esimerkiksi verkosta saatavan palvelun käyttö laajaverkkoyhteyden yli on kalliimpaa kuin saman palvelun käyttäminen lähiverkossa. Tämä johtuu siitä, että yleensä yritys omistaa oman lähiverkkonsa. Sen sijaan laaj averkkoyhteydet vuokrataan ulkopuolisilta palveluntarjoajilta.
2.2.3 Liittymätarpeiden arvioinnin epätarkkuus ilman simulointia
Mallintamisen ja simuloinnin tärkeys syntyy kolmesta perustilanteesta [3]:
• Muuttuvan infrastruktuurin toimivuutta ei tiedetä ilman simulointia.
• Alkuperäiset liittymäresurssit saattavat olla riittämättömiä tai ylimitoitettuja muutosten jälkeen
• Olemassa olevilla ympäristöillä kokeileminen on liian kallista ja työlästä Simulointimallin puuttumisen vuoksi liittymätarpeiden suunnittelu on epätarkkaa.
Varsinkin suurissa ympäristöissä infrastruktuurin muutosten vaikutukset koskevat monia liittymiä, jolloin muuttuneiden liikennemäärien selvittäminen etukäteen on tärkeää. Uusia ja uudelleenohjautuneita liikennevirtoja voi olla useita tuhansia, jolloin laskutoimitukset ovat monimutkaisia suorittaa ilman apuvälinettä.
sijaitsevaa palvelinta siirretään uusiin sijoituskohteisiin. Tämä muutos vaikuttaa sekä kaikkien kymmenen palvelimen alkuperäisten toimipisteiden liittymien liikennemäärään että myös kaikkien uusien sijoituskohteiden liittymien liikennemäärään. Se voi vaikuttaa myös muiden toimipisteiden laajaverkkoliikenteeseen, jolloin simuloinnin merkitys korostuu.
2.3 Työn tarkoitus
Työllä on kaksi päämäärää:
1. Suunnitellaan ja rakennetaan simulointimalli, jonka avulla voidaan etukäteen arvioida konsolidoinnin seurauksena syntyvien tietoliikennemuutosten vaikutuksia. Käytännössä tämä tarkoittaa keinoa selvittää liikennemäärien sekä tietoliikenneliittymien kapasiteettitarpeiden muutoksia suurissa infrastruktuurin muutostilanteissa. Lisäksi työn tarkoituksena on mallia testaamalla suunnitella sille toimiva käyttötapa.
Simulointimalli luodaan yhdeksi osaksi konsolidoinnin suunnitteluprosessia, josta saatavia tietoja mallin on tarkoitus hyödyntää.
Mallista pyritään rakentamaan työkalu, jota on mahdollista käyttää toistuvasti konsolidoinnin suunnitteluprojekteissa.
2. Varsinaisen työn tekemisen yhteydessä syntyi sivutuotteena mahdollisuus yhteistyöhön tietoliikenneoperaattoreiden kanssa. Tämän johdosta työn tavoitteisiin lisättiin selvitys, jolla kartoitetaan, minkälaista yhteistyötä tietotekniikan palvelutalo ja operaattorit voisivat tulevaisuudessa tehdä käsiteltävän asian tiimoilta. Tarkoituksena oli selvittää:
• Jos simuloinnin avulla saadaan liittymille parempi arviointitapa ja suunnittelumahdollisuus, pystytäänkö tämän myötä kehittämään yhteistyötä, joka kohdistuisi yhteisille asiakkaille
suunnattujen palvelujen parantamiseen sekä yhteisen kyvykkyyden lisäämiseen asiakkaiden suuntaan.
2.4 Työn rajaukset
Työn aihe rajataan seuraavien pääkohtien perusteella:
• Simuloidaan palvelinympäristöjä. Simulointimallissa määriteltävien menetelmien avulla tutkitaan vaikutuksia, jotka ovat seurausta palvelimiin kohdistetuista muutostoimenp iteistä
• Simuloidaan olemassa olevia ympäristöjä ja niiden muutoksia.
Tarkoitus ei ole simuloinnin avulla ennustaa uusien järjestelmien käyttäytymistä
• Simuloinnin avulla tutkitaan kapasiteettitarve- ja liikennemuutoksia, jotka syntyvät, kun palvelimia liikutellaan verkon eri sijoituspaikkoihin. Palvelun laatu ja vasteaika-asiat rajataan työn ulkopuolelle.
• Simuloinnissa keskitytään tietoliikenneliittymien kapasiteettitarpeiden tutkimiseen. Muiden verkon osien, esimerkiksi yritysverkon alla olevan runkoverkon komponenttien tutkiminen rajataan pois.
3 Kriteerit simulointimallin ja sen käytön arvioimiseksi
Tässä kappaleessa luodaan kriteerit, joiden perusteella voidaan arvioida simulointimallin soveltuvuutta edellä määritellyn ongelman ratkaisemiseksi.
3.1 Mallin yleinen soveltuvuus
Mallilla on pystyttävä kuvaamaan tietoliikenneverkko ja verkon liikenne sellaisella tarkkuudella, että liittymäkohtainen liikennemäärä pystytään laskemaan kaikille mahdollisille muutostilanteille. Käytännössä tämä tarkoittaa mahdollisuutta kuvata verkossa olevat palvelimet ja niiden suoritteet, toimipisteet sekä toimipisteiden liittymät, eli yhteydet toisiinsa. Mallilla ei tarvitse pystyä kuvaamaan esimerkiksi palveluntaijoajan runkoverkkoa. Lisäksi mallin täytyy olla riittävän yleinen, jotta se on riippumaton käytettävästä työkalusta.
3.2 Topologiamuutosten huomioiminen
Mallissa mikä tahansa yksittäinen palvelin/palvelu pitää pystyä poistamaan kokonaan tai siirtämään mihin tahansa toiseen kohtaan topologiassa. Mallissa on myös pystyttävä käsittelemään tilanne, jossa palvelin/palvelu on alkutilanteessa käyttäjien kanssa samassa lähiverkossa, ja siirtyy sen jälkeen eri lähiverkkoon, ja sama kääntäen. Tämä tilanne on liittymien liikenteen kannalta oleellinen, sillä liittymä kuormittuu silloin, kun käyttäjät käyttävät palveluja, jotka ovat oman toimipisteen ulkopuolella.
Malliin pitää lisäksi pystyä luomaan uusia toimipisteitä, liittymiä ja palvelimia, joita alkutilanteessa ei ole ollut. Esimerkiksi uusien toimipisteiden ja liittymien luominen on tarpeellista tapauksessa, jossa yrityksen palvelimet keskitetään uuteen palvelukeskukseen.
3.3 Liikenteen tuottajien huomioiminen
Mallilla on pystyttävä havainnollistamaan, mikä on objekti, joka tuottaa tai vastaanottaa liikennettä. Tämän lisäksi pitää havainnollistaa, näiden objektien keskinäinen sijainti ja mahdollinen sijainnin muutos toisiinsa nähden topologiassa. Toisin sanoen mallin on tunnistettava, sijaitsevatko objektit samassa lähiverkossa, vai eivät. Tämä on tärkeää edellä mainitun liittymien kuormituksen takia.
3.4 Liikennemäärien ohjautuminen toisiin sijoituskohteisiin
Suunnitellun konsolidointimuutoksen jälkeen mallissa on pystyttävä ohjaamaan olemassa olevat liikennevirrat toisiin mallissa oleviin kohteisiin. Liikennevirrat on pystyttävä ohjaamaan myös uusiin kohteisiin, jotka muutoksen johdosta mahdollisesti syntyvät. Konsolidointimuutos on yleensä sellainen, että se ei vaikuta käyttäjien toimintaan. Toisin sanoen he käyttävät edelleen samoja palveluja, jotka tosin saattavat sijaita muualla kuin ennen.
Mallin on lisäksi pystyttävä automaattisesti muodostamaan liikenteen uusi reitti vaihtuneeseen kohteeseen. Tämä sen takia, että yleensä muutokset koskevat monia palvelimia ja suoritteita. Tällöin liikenteen reittien uudelleen luominen käsin on liian työlästä.
3.5 Mallin ja sen käytön yhteys todellisuuteen
Mallin pitää pystyä käyttämään hyödyksi todellisia konsolidoinnin suunnittelusta saatavia liikenne-, kapasiteetti ja topologiatietoja. Käytännössä rämä tiedot ovat sellaisia, joiden perusteella voidaan saada haluttuja tuotoksia mallin käytöllä.
Mallin kannalta tämä kriteeri merkitsee sitä, että sen on ymmärrettävä, mitä nämä tiedot ovat mallinnettavassa verkossa.
3.6 Mallista saatavat tuotokset
Mallin pitää tuottaa tietoja, joiden perusteella voidaan vertailla konsolidoinnin suunnittelussa tehtäviä vaihtoehtoisia muutoksia tietoliikenteen osalta. Vertailua voidaan tehdä tietoliikennekustannusten perusteella. Näiden tietojen perusteella on pystyttävä hahmottamaan konsolidoinnin toteutusprojekteja, ja sitä, miten voidaan saavuttaa nopeita voittoja sekä pitkän tähtäimen voittoja.
Mallista saatavien tulosten on oltava havainnollisia, eli helposti tulkittavissa.
Lisäksi kaikkien tuotosten on oltava realistisia, jotta niihin voidaan perustaa luottamusta.
3.7 Kriteerit valittavalle työkalulle
• Käytettävällä työkalulla on pystyttävä tuottamaan verkon topologian graafinen esitys sekä esitys, jonka perusteella voidaan havainnoida suunniteltu muutos alkutilanteeseen verrattuna. Tämä tarkoittaa yksinkertaista mahdollisuutta suorittaa haluttu muutos ja sen jälkeen palata takaisin alkutilanteeseen. Myöhemmän vertailun takia työkalun pitää pystyä säilyttämään mallinnetut muutostilanteet ja simulointitulokset.
• Työkalussa pitää olla useita mahdollisuuksia tuoda verkosta saatavia mittaustietoja sisään ohjelmaan, koska usein asiakkailla on omia ja erilaisia mittausvälineitä käytössään. Lisäksi mittaustietojen syöttäminen käsin pitää olla mahdollista, jos automaattisesti kerättyä tietoa ei ole saatavilla. Työkalulla pitää pystyä lukemaan siihen sisään syötettyjä liikennetietoja yksinkertaisella tavalla suunnittelun helpottamiseksi.
• Työkalun on pystyttävä saamaan tietoja analysoidusta tietokannasta, joka sisältää Inventory-ohjelmalla kerätyt lähtötiedot tarkasteltavasta tietojenkäsittely- ympäristöstä.
• Työkalun pitää pystyä muodostamaan uusia liikennepolkuja automaattisesti, kun palvelimia ja niiden suoritteita liikutetaan.
• Työkalun pitää pystyä suorittamaan simulointi kohtuullisessa ajassa.
4 Yleinen malli (Konsolidoinnin suunnitteluprosessi)
Tässä kappaleessa kuvataan konsolidoinnin suunnittelumetodiikan yleinen malli ja se, miten luotu simulointimalli liitetään siihen. Konsolidoinnista on olemassa useita erilaisia malleja, mutta mitään vakiintunutta standardia ei ole olemassa.
Tämän takia konsolidoinnilla tarkoitetaan asiayhteydestä riippuen eri asioita.
Tässä kappaleessa keskitytään tarkastelemaan yhtä monista malleista, joka käsittelee palvelimien konsolidointia.
4.1 Konsolidoinnin suunnitteluprosessin kulku 1. Toimeksianto
2. Automaattinen tiedonkeruu
3. Tiedonkeruu täydentävillä kysymyksillä 4. Palvelimien vähennyskriteerit
5. Muutosajurit
6. Kerättyjen tietojen yhdistäminen 7. Kustannustehokkuuden mallit 8. Muutospäätökset
9. Analyysi 10. Johtopäätökset
4.2 Suunnittelun tavoitteet
Konsolidoinnin suunnittelussa tärkein päämäärä on löytää keinoja taloudellisten etujen saavuttamiseen, mikä käytännössä tarkoittaa tietotekniikan infrastruktuurin ylläpidon kustannusten pienentämistä.
Taloudellisten tavoitteiden lisäksi suunnittelun päämääriä voivat olla hallinnan ja verkosta saatavien palveluiden laadun parantaminen sekä tekniset asiat, kuten
palveluiden käytettävissä olon ja tehokkuuden parantaminen sekä verkko rakenteiden yksinkertaistaminen ja tulevaan kehitykseen varautuminen [4].
Nämä tavoitteet tukevat usein taloudellisiin säästöihin tähtääviä toimia.
4.3 Tiedonkeruumenetelmät
Konsolidoinnin suunnittelua varten kerätään tietoa kohteena olevasta ympäristöstä. Käsiteltävässä suunnittelumallissa tiedonkeruuta suoritetaan kahdella eri tavalla, automaattisesti keräilyohjelmistolla sekä asiantuntijoille lähetettävien kyselylomakkeiden avulla.
Automaattisessa keruussa palvelimista ja toimipisteverkosta kerätään Inventory- ohjelmiston avulla tietoa. Inventory sisältää keräilyohjelman sekä tietokannan, jotka sijaitsevat keskitetysti. Keräilyohjelma tutkii verkossa olevien palvelimien ominaisuuksia ja resursseja ja tallentaa tiedot tietokantaan. Inventoryn keräämiä tietoja ovat esimerkiksi palvelimen muistin ja levytilan koko, prosessoriteho sekä käyttöjärjestelmä.
Automaattisen tiedon keruun lisäksi suoritetaan täydentäviä kyselyjä. Tällä menetelmällä saadaan asiantuntijoilta tietoja, joita Inventoryn avulla ei kerätä.
Kyselyissä toimipisteiden järjestelmän valvojille lähetetään sähköisiä www- kyselylomakkeita, joista vastaukset tallentuvat suoraan tietokantaan. Kyselyillä selvitetään esimerkiksi palvelimien roolit, fyysiset sijainnit sekä käyttäjien määrät.
Lomakkeet on suunniteltu seuraavan kappaleen analyysimenetelmiä silmällä pitäen.
4.4 Kyselytiedon yhdistäminen ja analysointimenetelmät
Tiedonkeruun jälkeen edellä mainitut kaksi tietokantaa yhdistetään jolloin saadaan yksi tarvittavat tiedot sisältävä kanta. Tietokannan analysoimiseen käytetään SQL- pohjaista analysointiohjelmistoa. Ohjelmisto sisältää joukon sääntöjä, joita on kymmeniä. Nämä säännöt muodostavat olennaisen osan koko konsolidoinnin suunnittelussa, joten niitä ei tässä työssä julkaista. Sääntöjä yhdistelemällä ja käyttämällä niitä rinnakkain, kannasta poimitaan pienempiä osajoukkoja, jotka täyttävät määrätyt ehdot.
Tarkoituksena on hakea edellytyksiä helpolle keskittämiselle. Tämä tarkoittaa, että etsitään palvelimia, joiden suoritteita on mahdollista yhdistää, siirtää ja poistaa. Tällaista joukkoa kutsutaan tästä lähtien potentiaaliksi.
Potentiaalin etsiminen tapahtuu suodattamalla pois sääntöjen avulla sellaisia palvelimia ja niiden palveluja, jotka eivät esimerkiksi verkon roolinsa tai sijaintinsa puolesta ole siirrettävissä. Jokaisen suodatuskerran jälkeen, jäljelle jääneet lajitellaan ja niihin kohdistetaan uusia sääntökriteerejä. Tätä suoritetaan niin kauan, että saadaan palvelinjoukko, jonka suoritteiden liikuttelu on mahdollista.
Analyysivaiheen tuloksena saatua potentiaalia konsultoidaan asiakkaalle.
4.5 Kohteet, joihin konsolidoinnilla vaikutetaan
Konsolidoinnin suunnittelumallissa muutoksen kohteena ovat palvelinten suoritteet sekä roolit. Suunnittelu sopii parhaiten suuriin ympäristöihin, joissa palvelinten rooleja on paljon ja ne ovat sijainniltaan hajautettuina. Tämä johtuu siitä, että suuresta roolimäärästä ja hajaantuneesta arkkitehtuurista on todennäköisempää löytää potentiaalisia säästökohteita kuin alun perin keskitetymmästä tai pienestä kokonaisuudesta. Suuriksi ympäristöiksi voidaan tässä laskea yli 50 palvelimen muodostama ympäristö. Luku on saatu
kokemusperäisesti asiakasprojekteista, mutta sitä ei voida pitää absoluuttisena arvona, ainoastaan suuntaa antavana.
Erilaisia konsolidointimuotoja on neljä kappaletta. Nämä ovat:
1. Palvelimien konsolidointi
Palvelimien konsolidoinnissa olemassa olevien palvelimien rooleja pyritään yhdistämään ja keskittämään tietyille paikkakunnille. Yhdellä palvelimella voi olla useita rooleja. Roolin siirtäminen tarkoittaa palvelimessa ajettavien sovellusten ja palveluiden siirtämistä johonkin toiseen palvelimeen. Yksittäisen palvelimen kaikkien roolien siirtäminen muualle saattaa mahdollistaa palvelimen fyysisen poistamisen verkosta.
2. Sovellusten konsolidointi
Sovellusten konsolidoinnissa on kyse erilaisten sovellusten ja niiden ohjelmistoympäristöjen lukumäärän supistamisesta. Tarkoituksena on yhdenmukaistaa yrityksen käyttämiä työkaluja. Erilaiset sovellukset ja käyttöj äijestelmät saattavat aiheuttaa yhteensopivuusongelmia, koska ne toimivat eri tavoin ja mahdollisesti vaativat järjestelmiltä eri asioita. Tämän takia jokaisella erityyppisellä sovelluksella ja ympäristöllä pitää olla oma asiantuntijansa, jotta mahdolliset ongelmatilanteet pystytään hoitamaan tehokkaasti.
3. Tietovarastojen konsolidointi
Tietovarastojen keskittämisessä pyritään muodostamaan suuria kokonaisuuksia, joihin tieto varastoidaan. Tämä voi tarkoittaa sekä eri toimipisteiden tiedostopalvelimien yhdistämistä ja keskittämistä, mutta myös muiden
4. Rakenteiden konsolidointi
Rakenteiden konsolidoinnissa pyritään ottamaan sovelluksia sekä palvelimien rooleja ulos rakenteista ja sijoittamaan ne muualle. Rakenteita syntyy esimerkiksi, kun yritys ulkoistaa palvelimiaan palvelukeskukseen Rakenteita muodostavat mm. palvelimet, jotka ovat rooliensa puolesta sidottu muihin järjestelmiin sekä järjestelmät, joissa sovellukset keskustelevat muiden sovellusten kanssa.
Tällaisissa tapauksissa sidokset vaikuttavat sovellusten ja roolien siirrettävyyteen.
4.6 Konsolidoinnin kustannusarvio
Tietotekniikan infrastruktuurin ylläpidon kustannusten lähteitä ovat:
• Työkustannukset
• Laitekulut, joihin sisältyvät esimerkiksi palvelimien ja verkon erilaisten komponenttien hankintamenot sekä huoltosopimukset
• Ohjelmistolisenssit, joihin kuuluvat mm. käyttöjärjestelmien, tietokantojen ja erilaiset sovellusten hankintamenot sekä ylläpitosopimukset
• Tietoliikennemaksut
Tietoliikenne 5 % Ohjelmistot 20 %,
Laitekulut 20 %
Työ 55 %
Kuva 1 Tietotekniikan infrastruktuurin kustannusjakauma (Lähde: IDC)
Koska työn osuus kustannuksista on suurin, on todennäköistä, että suurimmat säästöt saadaan vähentämällä ja tehostamalla tarvittavaa työmäärää. Joissakin tapauksissa tämä saattaa johtaa muiden kulujen lisäämiseen. Esimerkiksi sovelluspalvelimien keskittäminen todennäköisesti kasvattaa vastaanottavan toimipisteen tietoliikennekuluja, mutta samalla voi vähentää palvelimien ylläpitoon tarvittavaa työtä. Konsolidoinnin suunnittelussa keskitytään pääosin infrastruktuurin ylläpidon tarpeen pienentämiseen. Ylläpitot)ö koostuu toimista, joiden avulla ympäristöä pidetään toimintakykyisenä [5]. Näitä ovat mm.
• Asennustyöt ja konfiguroinnit
• Verkon valvonta (monitorointi)
• Sovellus- ja tietokantapäivitykset
• Varmuuskopioinnit
• Ongelmatilanteiden diagnosointi ja korjaukset
Jos yrityksen toimipisteet ovat erillään toisistaan, eikä niissä ole omaa ylläpito henkilökuntaa, muiden ylläpitäjien matkustustarve kasvaa. Tämä on kallista ja vie paljon aikaa.
olevien palvelimien ylläpitoon verrattuna keskitettyyn ratkaisuun [6]. Kyseinen luku haetaan kokemusperäisesti palveluympäristöistä konsolidoinnin suunnittelun tueksi. Yleistäen voidaan todeta, että hajautetun ympäristön ylläpidon ja hallinnoinnin vaatima työpanoskerroin verrattuna keskitettyyn on noin kaksi.
Tämä kertoo, että keskitetyn ratkaisun ylläpitokustannukset voivat olla alle puolet hajautetun ratkaisun vastaavista. Parhaimmassa tapauksessa voidaan päästä yli kahden arvoihin, mutta yleensä tehokkuuskerroin on alle kaksi. Huonoimmassa tapauksessa on mahdollista, että koituu ainoastaan lisäkustannuksia, eikä ollenkaan säästöjä, jolloin kerroin laskee alle yhden. Kertoimen avulla voidaan arvioida konsolidoinnin kannattavuutta erilaisissa tilanteissa.
Avainkysymys on siis, miten tarvittavaa työn määrää voidaan vähentää. Jos tämä ei ole mahdollista, on pyrkimyksenä saada parannettua tehtävän työn tehokkuutta.
Toisin sanoen pyritään vähentämään tarvittavaa palvelinkohtaista työn määrää.
Yritysten kustannussäästöt konsolidoinnissa eivät synny välittömästi. On syytä huomioida, että konsolidointi on aina investointi. Operaatio tuottaa hyötyä vasta muutamien vuosien kuluttua, kun poistettavista laitteista saatavat jäännösarvot vapautuvat ja konsolidoinnista aiheutuneet kustannussäästöt kasvavat suuremmiksi kuin muutokseen käytetyt investoinnit. Myös lyhyen tähtäimen säästöt ja nopeat voitot ovat mahdollisia, mutta ne vaativat hyvän ja tarkan metodiikan ja ovat vaikeammin saavutettavissa.
4.7 Suunnittelusta saatavia raportteja
Konsolidoinnin suunnittelun tuotoksena asiakkaalle esitetään toimeksiannon yhteydessä sovittuja raportteja. Tällaisia ovat mm:
• Taloudellisesti kannattavat muutokset
• Keskittämisen mukanaan tuomat mahdollisuudet
• Infrastruktuurin kehittäminen pitkällä aikavälillä
Suunnittelussa tuotetaan erilaisia keskittämisvaihtoehtoj a. Vaihtoehdoille on mahdollista selvittää taloudelliset tekijät. Eri vaihtoehdot vaativat erikokoisia investointeja, mutta myös tuottavat erilaisia kustannussäästöjä. Sekä investoinnit että säästöt riippuvat mm. siitä, kuinka suuri konsolidointimuutos on. Asiakas voi eri vaihtoehtojen joukosta valita tapaukseensa sopivan ratkaisun.
4.8 Markkinoilla olevia muita ratkaisuja
Markkinoilla on saatavilla erilaisia ratkaisuja, joiden avulla infrastruktuuria voidaan keskittää. Esimerkiksi Citrixin Metaframe-tyyppisellä ratkaisulla voidaan työaseman ohjelmistot keskittää palvelimille, joita työasemat käyttävät ohjelmia ja palveluja verkon yli, kuten päätteet [7]. SAN, eli Storage Area Network- ratkaisulla yrityksen tietovarastot voidaan keskittää yhdeksi suureksi kokonaisuudeksi [8].
Näillä menetelmillä voidaan varautua tulevaisuuteen, mutta ratkaisut eivät välttämättä ole taloudellisesti kannattavia. Hankkimalla keskittämisratkaisun väärin perustein, on mahdollista, että yritys ei loppujen lopuksi saa tarvitsemaansa lopputulosta.
Konsolidoinnin kautta yrityksen tarpeet voidaan tarkkaan suunnitella ja näiden tarpeiden pohjalta voidaan etsiä kustannustehokkain ratkaisu kuhunkin tilanteeseen.
4.9 Simulointimallin soveltaminen suunnittelun yhteyteen
Konsolidoinnin suunnittelusta saatavat tiedot otetaan sisään simulointimalliin.
Kerättyjen tietojen analysoinnin pohjalta saadaan määriteltyä potentiaalinen palvelinjoukko, jonka suoritteita ja palveluja poistetaan ja siirretään.
Mallin avulla selvitetään, mihin palvelimien palveluita on tarkoituksenmukaista sijoittaa tietoliikenteen kannalta, sekä mitä vaikutuksia siirroista aiheutuu toimipisteiden tietoliikenneliittymille. Simulointia varten tehdään useita vaihtoehtoisia mitä-jos muutostilanteita. Muutoksesta riippuen, simuloinnin tuotoksena saadaan erilaisia tuloksia, joissa liittymille on laskettu muuttuneet liikennekuormat.
Mallin käytöstä saatujen tietojen perusteella operaattorit voivat laskea asiakkaalle muutoksista aiheutuvien tietoliikennekustannusten suuruudet.
5 Implementaatio
5.1 Muiden yritysten keinot infrastruktuurin muutosten vaikutusten selvittämiseen
Tässä työssä käsiteltävä ongelma on senkaltainen, että sitä käsittelevää kiijoitettua aineistoa on vaikeaa löytää painettuna. Työn uniikkiuden selvittäminen suoritettiin tekemällä haastatteluja ja käymällä vuoropuhelua kotimaisten tietoliikenneoperaattoreiden kanssa, koska heidän voitiin olettaa suorittavan jonkinlaista simulointia. Tämän lisäksi tarkasteltiin alan tutkimuslaitosten materiaalia sekä otettiin selvää muutaman suuren laitevalmistajan mahdollisista simulointimenetelmistä.
5.1.1 Tutkimuslaitosten aineistosta
Työtä varten tutkittiin tutkimuslaitosten, kuten Gartner Groupin ja Metagroupin julkaisuja. Konsolidoinnista sekä sen suunnittelusta löytyy paljon erilaista materiaalia sekä tutkimuslaitosten artikkeleista että palvelutuottajien menetelmäkuvauksista. Lisäksi löytyy materiaalia ja tutkimustietoa yksittäisten toimenpiteiden, kuten uuden sovelluksen käyttöönoton vaikutusten arvioimisesta.
Saatavilla olevista julkaisuista ei kuitenkaan löytynyt tutkimuksia tai artikkeleita koskien tilannetta, jossa koko verkon tietoliikenne mahdollisesti järjestyy uudelleen. On mahdollista, että tällaisia ratkaisuja on olemassa eri yrityksillä, mutta niistä ei ole julkisia kuvauksia.
Gärtnerin aineistoista löytyi viitteitä, että useat tietotekniikka-alan yritykset kehittelevät omia simulointimenetelmiään. Aihe on siis uusi ja ajankohtainen.
Metagroupin tutkimuksesta paljastuu, että ennustavaa kapasiteetin hallintaa ei ole vielä yleisesti olemassa [9].
5.1.2 Tietoliikenneoperaattoreiden haastattelut
Haastattelujen kohteeksi valittiin operaattorit siitä syystä, että tietoliikenneliittymien mitoitus on osana heidän liiketoiminta-aluettaan.
5.1.2.1 Haastattelujen päämäärä Tapaamisten tarkoituksena oli:
1. Selvittää operaattoreiden valmiuksia, keinoja ja halua suorittaa liittymien kapasiteettien simulointia asiakkaiden erilaisissa infrastruktuurin muutostilanteissa
2. Näiden tietojen perusteella selvittää, onko operaattorien menetelmissä samankaltaisia piirteitä verrattuna omaan malliin. Lisäksi vertailemalla mallien eroavaisuuksia oli tarkoitus osoittaa oman mallin uniikkius
3. Saada palautetta ja mielipiteitä operaattorien näkökulmasta koskien simulointimallia
Seuraavat kaksi olivat myös tapaamisten tavoitteita, mutta eivät liity työn uniikkiuden selvittämiseen.
4. Saada selville operaattoreiden näkemyksiä simuloinnista ja sen tärkeydestä tulevaisuudessa
5. Kartoittaa yhteistyön mahdollisuuksia tämän pohjalta
5.1.2.2 Tapaamisiin valmistautuminen
Keskustelutilaisuuksiin valmistauduttiin valitsemalla kohteiksi kolme merkittävää suomalaista tietoliikenneoperaattoria. Tapaamisia varten suunniteltiin joukko
kysymyksiä, joiden avulla oman mallin uniikkiuden selvittäminen on mahdollista.
Kysymysten avulla tutkittiin:
o Suorittaako operaattori asiakkaan liittymien kapasiteettitarpeen simulointia, kun asiakkaan infrastruktuurissa tapahtuu palvelimien, sovellusten tai käyttäjämäärien muutoksia
o Millä tavoin ja kuinka tarkasti edellä mainittu simulointi suoritetaan ja mitä asioita arvioidaan
o Jos simulointia ei suoriteta, minkä takia ei
o Jos simulointia ei suoriteta, nähdäänkö sille tulevaisuudessa tarvetta
Lisäksi oman simulointimallin asioista luotiin esitysaineisto, joka esiteltäisiin operaattoreille. Esitysaineiston tarkoituksena oli johdattaa operaattorit aiheeseen ja selvittää omia näkemyksiä simuloinnista.
5.1.2.3 Haastattelujen anti
Haastatteluissa olivat mukana operaattorit А, В ja C. Kukaan operaattoreista ei tällä hetkellä suorita liittymien simulointia asiakkaidensa muutostilanteissa.
Muutoksissa liittymätarpeiden mitoitusvastuu on pitkälti asiakkailla.
Näissä tapauksissa operaattorit toimivat tavalla, joka perustuu arviointiin sekä kokemusperäisiin ja tilastollisiin tietoihin. Lisäksi he käyttävät apunaan yhteistyötä laite- ja ohjelmistovalmistajien kanssa. Arvioinnissa käytetyt tiedot eivät kuitenkaan välttämättä ole kyseessä olevasta ympäristöstä, vaan mahdollisesti vain vastaavanlaisista.
liikennemäärät. Käyttäjien sijaintia sekä palvelimien käytön intensiteettiä ei välttämättä huomioida. Etenkin käyttäjien sijainnilla verkosta saatavien palvelujen suhteen on merkitys, kun palvelimia siirretään uusiin sijoituskohteisiin.
Vaikka konkreettisia toimia simulointimallien kehittämiseksi operaattorien taholta ei ole tehty, aihetta on silti mietitty. Nykyisin kilpailu asiakkaista on kovaa ja mahdollisuudet asiakkaiden palvelun parantamiseksi pyritään ottamaan huomioon, jotta kilpailuetu paranisi. Tämä johtaa tilanteeseen, jossa pelkkä kapasiteetin myyminen ilman perusteluja ei tyydytä asiakasta, eikä siten ole operaattoreille enää kannattavaa.
Kaikki kolme teleoperaattoria näkivät tulevaisuudessa kiinnostusta simuloinnille.
Edellä mainitun asian lisäksi kiinnostusta aiheuttivat mahdollisuudet:
• selvittää uuden teknologian käyttöönoton vaikutuksia etukäteen
• saada väline, jonka avulla tietoliikenneratkaisujen toimivuus voidaan osoittaa havainnollisesti
• päästä vaikuttamaan asiakkaan ratkaisuihin entistä enemmän
5.1.3 Suurten laitevalmistajien arviointimenetelmistä
Muutkin yritykset ovat tehneet simulointimalleja. Tässä kappaleessa rajoitutaan tarkastelemaan malleja siltä osin, kun niistä on saatavilla julkista tietoa.
Laitevalmistajien malleilla tarkastellaan pääosin:
• Yritysten koon muutoksen myötä käyttäjämäärien vaihteluita ja niiden vaikutusta verkosta saatavien palvelujen toimintaan
• Uusien sovellusten ja laitteiden käyttöönoton vaikutuksia
Käyttäjämäärien lisääntyessä syntyy yksinkertaisia muutoksia infrastruktuuriin.
Todennäköistä on, että liikennemäärät kasvavat ja sitä kautta syntyy muutospaineita toimipisteiden liittymiin, mutta esimerkiksi palvelimien ja verkon palveluiden sijainnit eivät muutu tämän takia. Tällaisen tilanteen arvioiminen on yksinkertaisempaa verrattuna konsolidointitilanteisiin, sillä liikennevirrat eivät ohjaudu uudelleen.
Uusien sovellusten ja laitteiden käyttöönoton tilanteissa kyseiset tietotekniikkayritykset ennustavat malleillaan mm. omien tuotteidensa suorituskyvyn ja resurssien, kuten palvelimen prosessointitehon ja muistin, riittävyyttä muutosten jälkeen. Mallit on siis usein suunnattu jonkin tietyn tuotteen ominaisuuksien etukäteistarkaste luun.
5.1.4 Yhteenveto muiden mallien puutteista ja ansioista
Tämän työn ongelman ratkaisun kannalta edellä mainituissa arviointitavoissa on kaksi oleellista puutetta:
• Menetelmät soveltuvat tilanteisiin, joissa palvelinten suoritteet eivät siirry fyysisesti topologiassa
• Arviointiin käytettävät lähtötiedot ovat tilastollisia keskiarvoja
5.1.5 Syitä käyttökelpoisten menetelmien puuttumiseen
Toimipisteiden liittymien mitoitus on tyypillisesti ollut operaattoreiden työmaata.
Koska yleensä laajaverkkoyhteydet vuokrataan, ei yrityksillä tai laitevalmistajilla ole ollut suurta kiinnostusta näiden kapasiteetin analysoimiseen, vaan tämä on jätetty operaattoreille.
Operaattorit puolestaan eivät ole luoneet kapasiteetin simuloinnista
mahdollisimman paljon kapasiteettia asiakkailleen. Tästä syystä liittymien tarkka mitoitus ei operaattorien kannalta ole ollut tärkeää. Arvopohjainen mitoitus on ollut riittävää heidän toiminnalleen, koska asiakkaat eivät ole vaatineet mitään arvioiden tueksi.
Asiakkaiden ja operaattorien väliltä on puuttunut molempia osapuolia hyödyttävä yhteistyö, kun mitoituksia on tehty. Olemassa oleva valmius suorittaa simulointia voisi parantaa tätä yhteistyötä.
5.1.6 Oman työn uniikkiuden varmistaminen tutkimusten perusteella
Tämän työssä käsiteltävästä ongelmasta tekee vaativan se, että liikuteltavia objekteja on tuntematon ja potentiaalisesti suuri määrä. Lisäksi sijoitusvaihtoehtoja on useita. Toisin sanoen, mikä tahansa objekti voidaan poistaa tai sijoittaa mihin tahansa. Ongelma on luonteeltaan kombinatorinen ja se kasvaa nopeasti sellaiseksi, että sitä on vaikea hallita ilman hyvää metodiikkaa.
Muutokset voivat olla vaikutuksiltaan monimutkaisia, jolloin muuttuneiden liikennevirtojen käsin laskeminen on vaikeaa.
Simulointi mahdollistaa erilaisten permutaatioiden käsittelyn ja sitä kautta tarkemman arviointituloksen. Operaattorien käyttämä arviointitapa ei mahdollista tällaista. Suurten laitevalmistajien malleilla puolestaan arvioidaan ai asioita eri näkökulmista. Yhteistä näille menetelmille on se, että ne eivät kata asioita, joita tarvitaan suurten infrastruktuurin muutostilanteiden arviointiin.
Haastattelujen sekä julkisesti saatavilla olevan informaation perusteella voidaan olettaa, että tietoliikenneliittymien kapasiteetin simulointia konsolidoinnin yhteydessä ei tällä hetkellä suoriteta muiden toimesta. Tämän johdosta voidaan olettaa, että työssä luotu metodiikka on uniikki.
5.2 Simulointimallin luominen
5.2.1 Simulointimallin rakentamiseen tarvittavat elementit
Simulointimalli rakennetaan siten, että sen avulla on mahdollista kuvata yritysverkkoja. Mallin luomiseen tarvittavia peruselementtejä on viidenlaisia:
• Tietoliikennepolku
• Liikennevirta
• Liikennettä tuottava objekti, eli lähde
• Liikennettä vastaanottava objekti, eli kohde
• Verkon solmupisteobjekti
Verkon solmupisteet eivät tuota, eivätkä ota vastaan liikennettä. Ne ovat mukana mallissa ainoastaan helpottamassa tietoliikennepolun määrittelyä.
Varsinainen malli koostuu yksittäisistä segmenteistä, joita voidaan liittää peräkkäin. Segmentti koostuu kahden objektin välisestä yhteydestä. Objekti voi olla esimerkiksi palvelin tai verkon solmupiste. Polku on peräkkäisistä segmenteistä koostuva suunnattu yhteys kahden päätepisteen välillä.
Kuva 2 Peräkkäin liitetyt segmentit
Kuvasta 2 ilmenee, kuinka polku AE koostuu peräkkäisistä segmenteistä AB, BC ja CE.
Mallissa on myös objekteja, jotka mallintavat liikenteen tuottajia, eli lähteitä ja vastaanottajia, eli kohteita. Usein liikenne on kaksisuuntaista. Tällöin lähteestä kohteeseen kulkevan polun rinnalla on automaattisesti toinen vastakkaissuuntainen polku. Siinä lähteen ja kohteen roolit vaihtuvat siten, että lähde vaihtuu kohteeksi vastaanottaessaan paluusuuntaista liikennevirtaa, ja toisinpäin.
Lisäksi malli sisältää liikennevirtoja. Liikennevirta on elementti, joka käsittää kahden päätepisteen, lähteen ja kohteen, välillä kulkevan liikenteen. Liikenne kulkee tietoliikennepolkuja pitkin. Liikennevirtoja syntyy, kun esimerkiksi käyttäjä lataa tiedoston, käyttää palvelimessa ajettavaa sovellusta tai suorittaa tietokantakyselyn palvelimelta. Liikennevirtojen kuormat riippuvat vastaavasti ladattavan tiedoston koosta sekä ajettavan sovelluksen ja käytettävän tietokannan ominaisuuksista.
Mallissa on kahdenlaisia liikennevirtoja, joita tässä kutsutaan alkeisvirroiksi ja summavirroiksi. Alkeisvirta on yhden lähteen yhteen kohteeseen tuottama sovelluskohtainen liikenne. Yksi lähde voi synnyttää useita alkeisvirtoja.
Sovellukset identifioidaan verkossa porttinumeroilla. Kahdella eri alkeisvirralla voi olla samat päätepisteet, mutta eri porttinumerot. Yhdellä polulla voi olla useita alkeisvirtoja, kuten kuvan 3 polulla AE.
Oheisessa kuvassa on kaksi toimipistettä C ja D, joiden välillä on laajaverkkoyhteys. Lähteet A ja В sijaitsevat toimipisteessä C sekä kohteet E ja F toimipisteessä D. Lähteiden A ja В alkeisvirrat summautuvat segmentissä CD, eli laajaverkossa, ja erkanevat sen jälkeen kohteisiinsa E ja F. Segmentissä CD muodostuu siis summavirta.
5.2.2 Mallin laskennallinen osio tehtävänasetteluun nojautuen
Palvelimen suoritteen siirtäminen topologiassa toiseen paikkaan muuttaa verkossa kulkevia alkeisvirtoja ja tämän myötä summa virtoja. Simulointimalli laskee segmenttien summavirtoja alkeisvirtojen perusteella. Liikenteen lähteiden ja kohteiden uudelleensijoittelun vaikutukset verkon liikenteeseen nähdään vertaamalla ennen ja jälkeen muutosta tehtyjen laskelmien tuloksia. Liittymässä summavirta vastaa liittymän kokonaiskuormitusta. Esimerkki:
Lähde Toimipiste Portti# Kohde Toimipiste Portti# Alkeisvirta b/s
Userl T1 1020 Srv2 T2 21 50
Srv2 T2 21 Userl T1 1020 1200
User2 T2 1030 Srv3 T3 80 800
Srv3 T3 80 User2 T2 1030 960
Userl T1 1040 Srv2 T2 18 700
Srv2 T2 18 Userl T1 1040 200
User3 T3 1110 Srv1 T1 80 1200
Srv1 T1 80 User3 T3 1110 1150
User3 T3 1220 Srv1 T1 21 40
Srv1 T1 21 User3 T3 1220 1500
Taulukko 1 Esimerkki simulointimallin laskutoimituksista 1
Toimipisteen 1 littymän summavirta on sekä tästä toimipisteestä ulos lähtevien että toimipisteeseen sisään tulevien alkeisvirtojen summa. Kyseinen summavirta
on rivien 1, 2, 5, 6, 7, 8, 9 ja 10 alkeisvirtojen summa, eli 6040 b/s. Vastaavasti toimipisteiden 2 ja 3 summavirrat ovat 3910 b/s ja 5650 b/s.
Siirtämällä toimipisteen 1 palvelu, joka käyttää porttinumeroa 80, toimipisteeseen 2, rivien 7 ja 8 alkeisvirrat muuttuvat ja saadaan seuraavanlainen taulukko:
Lähde Toimipiste Portti# Kohde Toimipiste Portti# Alkeisvi rta
Usert T1 1020 Srv2 T2 21 50
Srv2 T2 21 Userl T1 1020 1200
User2 T2 1030 Srv3 T3 80 800
Srv3 T3 80 User2 T2 1030 960
Usert T1 1040 Srv2 T2 18 700
Srv2 T2 18 Userl T1 1040 200
User3 T3 1110 Srv1 T2 80 1200
Srvt T2 80 User3 T3 1110 1150
User3 T3 1220 Srv1 T1 21 40
Srvt T1 21 User3 T3 1220 1500
Taulukko 2 Esimerkki simulointimallin laskutoimituksista 2
Nyt summavirrat toimipisteittäin ovat muuttuneet ja ovat 3690 b/s, 6260 b/s, 5650 b/s. Yksi muutos vaikuttaa tässä tapauksessa kahden toimipisteen summa virtoihin.
Yksinkertaisissa tapauksissa, joissa muutoksia on vähän, summavirrat voidaan laskea manuaalisesti. Tapauksissa, joissa muutoksia on kymmeniä tuhansia, ei käsin laskenta ole mahdollista.
5.2.3 Simulointimallista poisjätettävät asiat verrattuna todelliseen tilanteeseen
Mallin elementit vastaavat luonnollisella tavalla todellisen tietoliikenneverkon liikennettä tuottavia, vastaanottavia ja välittäviä komponentteja.
Simulointimallin avulla tutkitaan yritysverkkoja. Yritysverkko voidaan katsoa koostuvan toimipisteistä, joissa on oma lähiverkko, sekä toimipisteitä yhdistävistä laajaverkkoyhteyksistä. Mallista voidaan yksinkertaisuuden vuoksi jättää pois todellisessa tilanteessa läsnä olevia komponentteja, jotka eivät vaikuta toimipisteiden liittymien kapasiteetin laskemiseen. Esimerkiksi yritysverkon alla olevan palveluntaijoajan koko runkoverkon ja sen osien mallintaminen läjätään pois. Tämä tehdään sen takia, että runkoverkon kuorma ei ole mitattavissa ja verkon kapasiteetin riittävyys on operaattorien vastuulla. Liittymien simuloinnin kannalta runkoverkko ei muodostu pullonkaulaksi laajaverkkojen toimivuudelle.
5.2.4 Liikenne- ja topologiatiedon hankkiminen simulointimalliin
Simulointi vaatii tietoa mallinnettavasta verkosta, liikenteestä ja palvelimien suoritteista. Tiedot voidaan saada suoraan valmiina asiakkaalta, tai sitten ne on pyrittävä jollakin tavoin keräämään. Konsolidoinnin suunnittelua varten kerätyistä tiedoista osa soveltuu simulointiin suoraan, mutta suuri osa on sen karmalta merkityksetöntä. Suoraan soveltuvia tietoja palvelimista ja niissä ajettavista sovelluksista ovat:
• Sijainti
• Rooli verkossa
• Kytkennät verkkoon Erilaisia rooleja ovat mm.
Palvelin T ehtävä
Tiedostopalvelin Tarjoaa levyresursseja verkon käyttäjille Tulostuspalvelin Ohjaa tulostamista/tulostusjonoja verkossa WWW-palvelin Tarjoaa www-sivuja verkon käyttäjille
Proxy-palvelin Välittää www-sivuja, joita pyydetään www-palvelimelta Tietokantapalvelin Ylläpitää tietokantaa
Palomuuri Palvelin, joka suojaa yrityksen verkkoa ulkopuolisilta Postipalvelin Ylläpitää sähköpostijärjestelmää
Edustapalvelin Palvelin, johon käyttäjä on suoraan yhteydessä Sovelluspalvelin Ajaa jotakin tiettyä sovellusta
Taulukko 3 Palvelimien rooleja
Sijaintitiedon ja verkkokytkennän merkitys simuloinnille on se, että sen avulla palvelimien suoritteiden liikuttelu eri paikkoihin voidaan havainnollistaa.
Suunnittelussa on olennaista tietää alkuperäinen sijainti, uusi sijoituspaikka sekä se, minkälaisella kytkennällä kyseessä oleva palvelin on yhteydessä verkkoon.
Roolitiedon perusteella seuraavassa mainittavat sovelluskohtaiset liikennetiedot pystytään yhdistämään mallissa oikeisiin kohteisiin.
Edellä mainittujen asioiden lisäksi tarvitaan tietoa sovelluksen ja sen käyttäjien tuottamasta liikenteestä verkkoon. Pelkän kokonaisliikennekuorman mittaaminen ei ole riittävää, sillä erilaiset sovellukset tuottavat erilaisia liikennemääriä ja yksi paljon kuormaa tuottava sovellus saattaa periaatteessa vaikeuttaa muiden vähemmän liikennettä tuottavien ohjelmien toimintaa. Lisäksi konsolidoitaessa on mahdollista, että ainoastaan jokin palvelimessa ajettavista sovelluksista siirretään uuteen sijoituskohteeseen. Tämän takia on tärkeää selvittää jokaisen sovelluksen tiedot erikseen, mikäli se on mahdollista.
Liikennettä voidaan mitata ja tarkastella erilaisilla liikenteenmittaustyökaluilla, joita on lukuisia eri tarkoituksiin. Nämä välineet tutkivat verkon liikennettä siitä pisteestä, mihin ne on asetettu. Mittaustyökalu voi olla joko erillinen laite, joka sijoitetaan verkkoon, tai pelkkä tietokoneessa käytettävä ohjelmisto. Liikenteestä voidaan selvittää monia asioita riippuen halutusta simulointitarkkuudesta, mm.
protokolla, kuljettu reitti, pakettien koot. Välttämättömät liikennetiedot simuloinnin kannalta ovat:
1. Liikenteen kuorma (bittiä/sekunnissa)
2. Sovellus, joka liikennettä tuottaa ja/tai vastaanottaa
3. Liikenteen alku- ja loppupää, joiden välinen liikenne kuormittaa
Mittauksen jälkeen tiedot palvelimista sekä liikennetiedot kerätään yhteen tietokantaan.
Sovellusten tietojen lisäksi simulointia varten tarvitaan topologiakuvaus tutkittavasta verkosta, jotta palvelimien sidokset ja riippuvuudet verkkoon ja toisiinsa, sekä liikenteen verkossa käyttämät polut pystytään havainnollistamaan.
Topobgiakuvaus on mahdollista saada muodostettua automaattisesti verkosta käyttäen valmiita työkaluja, jotka piirtävät topologiaa tutkiessaan verkkoa. Toinen vaihtoehto on muodostaa kuvaus manuaalisesti. Molemmissa keinoissa on hyviä ja huonoja puolia.
Automaattisella muodostamisella saadaan parhaassa tapauksessa tarkka ajan tasalla oleva kuvaus koko verkosta. Mutta jos jokin verkon osa ei ole toiminnassa, sitä ei saada mukaan kuvaukseen. Lisäksi automaattinen keino tuottaa itsessään paljon liikennettä verkkoon, mikä saattaa haitata verkon palveluja.
Manuaalisen verkkokuvauksen tekeminen on puolestaan työlästä, jos kyseessä on suuri ja monimutkainen ympäristö.
Mikäli liikennetietoja ei ole saatavilla, tai niitä ei pystytä mittaamaan, simulointitehtävä vaikeutuu. Se ei kuitenkaan muutu mahdottomaksi. Tällaisessa tapauksessa on pyrittävä saamaan karkeita arvioita ajettavien sovellusten ominaisuuksista, esimerkiksi niiden valmistajilta sekä tietoja käyttäjien määrästä, ja näiden kautta arvioimaan liikennekuormia. Arvioiden käyttäminen heikentää simuloinnin tarkkuutta ja tuo mukanaan epävarmuustekijöitä. Tärkeiden tietojen, kuten käyttäjien sijainnin, siirrettävien tiedostojen koon sekä sovellusten käyttöintensiteetin arvioiminen on vaikeaa. Käyttöintensiteetti kertoo, mihin aikaan vuorokaudesta sekä kuinka paljon sovellusta käytetään. Useissa yrityksissä on todennäköistä, että arkisin päivällä sovellusten käyttö on vilkkaampaa kuin iltaisin ja viikonloppuisin. Tällöin päivisin liikennekuormat liittymissä ovat suurimmillaan, mikä on otettava huomioon yhteyksien mitoituksessa.
Simulointi työkalu on apuväline suurien ja monimutkaisten tietoliikenneympäristöjen muutosten suunnittelussa. Muutosten vaikutukset saattavat koskettaa hyvinkin monia kohteita. Hyvän simulointityökalun pitää räätälöityä käyttäjän tarpeisiin. Tämän takia on ensin tarkoin pystyttävä suunnittelemaan, minkälaiseen käyttöön työkalun pitäisi soveltua. Sopivimman välineen valitseminen ei välttämättä ole yksiselitteistä. Viime kädessä saatavilla olevan työkalun ominaisuudet pitää tuntea tarkoin.
Yleiset vaatimukset simulointityökalulle on mainittu kappaleessa 3.7.
Työkalun etsinnän aikana havaittiin, ettei markkinoilla ole monta ohjelmistoa, jossa on valmiiksi mahdollisuus ryhtyä toteuttamaan simulointimallia.
Useimmissa ohjelmissa on ominaisuus, joka pakottaa käyttäjänsä ensin valitsemaan erilaisista työkaluista tarvitsemansa ja tämän jälkeen itse kokoamaan käytettävän kokonaisuuden. Nämä ovat niin sanottuja ”työkalupakkeja”, jotka eivät suoranaisesti liity tietoliikenneverkkoihin, vaan mahdollistavat monenlaisen simuloinnin. Näiden etu on se, että niiden avulla voidaan saada aikaan tarkkoja arvioita ja pystyä mallintamaan mitä tahansa asioita, mutta niiden käyttö vaatii ohjelmointiin verrattavaa asiantuntemusta, joka ei ole tärkeää osaamista itse konsolidoinnin suunnittelussa.
Työhön valittiin Compuwaren tekemä Predictor-ohjelmisto v8.0, joka oli soveltuvin tarkastelluista simulointityökaluista. Se on valmis paketti, joka sisältää yleisimmät verkon toiminnan ominaisuudet ja se on suunniteltu tietoliikenneympäristöjen mallintamiseen. Ohjelmassa on paljon sisäänrakennettua älyä verkkoliikenteen simulointiin. Ohjelmistoon on mahdollista tuoda sisään sekä liikenne- että topologiatietoja suoraan yleisimmistä mittausohjelmista. Tietojen sisään tuominen ei onnistu suoraan sql-kannasta, joten myöskään analyysikannan suora liittäminen työkaluun ei ole mahdollista.
Tietokannan tiedot saadaan kuitenkin ohjelmaan muuttamalla sql-taulukot csv- tiedostoiksi, joiden liittäminen ohjelmaan onnistuu. Lisäksi vastaavien tietojen manuaalinen syöttäminen on mahdollista. Ohjelma sisältää graafisen käyttöliittymän, jonka avulla ohjelmiston käyttäminen on havainnollista ja
palaaminen johonkin tiettyyn vaihtoehtoon onnistuu. Muutosten tekeminen ja niiden peruuttaminen toimi oikein vasta ohjelmiston päivitysversion asennuksen jälkeen.
Työkalu sisältää työn kannalta tärkeimmät ominaisuudet. Lisäksi se tarjoaa lisätoimintoja, joita tämän työn yhteydessä ei tarvita. Tällaisia ovat mm.
valmistaja- ja laitekohtaiset parametrit sekä erilaiset reititysalgoritmit. Näitä voidaan hyödyntää simuloinnin mahdollisessa jatkokehityksessä.
5.2.6 Simulointimallin rakentaminen työkaluun
Tässä kappaleessa simulointimalli ymmärretään simulointityökalulla mallinnetuksi verkkokuvaukseksi, jota muutetaan konsolidointisuunnitelman mukaisin toimenpitein, ja jonka avulla muutosten vaikutuksia tutkitaan.
Itse simulointimallin rakentamisessa on kolme päävaihetta:
1. Verkkokuvauksen luominen työkaluun (manuaalisesti/automaattisesti) 2. Verkon komponenttien parametrien asettaminen
3. Liikennetietojen syöttäminen manuaalisesti tai lukeminen analyysikannasta tai suoraan mittausohjelmasta
Mallin rakentaminen työkaluun aloitetaan tuottamalla simulointiohjelmistoon topologiakuvaus tarkasteltavasta verkosta tai järjestelmästä. Tärkeää on sisällyttää kuvaan kaikki tarkastelussa olevat toimipisteet, palvelimet rooleineen sekä niiden väliset tietoliikenneyhteydet. Jos verkon kuvaus on tehty automaattisella välineellä, sen suora siirtäminen simulointityökaluun onnistuu. Mikäli kuvausta ei ole saatavilla se tehdään käsin lisäämällä työkalussa valmiina obvia komponentteja ja yhdistelemällä niitä asianmukaisesti toisiinsa. Jotta simuloinnin oikeellisuus ja hyödyllisyys voidaan maksimoida, on syytä huomioida, että kaikkien simuloin!ityökalussa käytettävien komponenttien, rakenteiden ja
Palvelinl Palvelin2
LähiverkkoS
Kuva 4 Esimerkki topologiasta
Kun verkon topologiakuvaus on tehty, määritellään simulointimalliin kaikkien käytössä olevien komponenttien ominaisuudet ja parametrit vastaamaan mallinnettavaa verkkokokoonpanoa. Tämä käsittää pääasiassa kaikkien tietoliikenne linkkien siirtokapasiteettien arvojen määrittelemistä sekä käyttäjämäärien asettamista.
Tämän jälkeen simulointiohjelmistoon syötetään tarkasteltavan verkon liikennetiedot. Liikennettä voidaan syöttää ohjelmaan suoraan liikennettä mittaavasta laitteesta tai tietokannasta. Tämän lisäksi on mahdollista syöttää manuaalisesti tietoja liikennetauluihin. Kussakin tapauksessa on tärkeää, että työkaluun asetettavat tiedot sisältävät liikenteen lähteen, kohteen, liikennekuorman sekä kyseessä olevan sovelluksen.
Lähde Kohde Sovellus/protokolla Liikennekuorma b/s
A В Ftp 20
В A Ftp 200
A C http 500
C A http 500
В C tcp/ip 12000
C В tcp/ip 1400
Syöttämisen jälkeen liikennetiedot liitetään tehtyyn topologiakuvaukseen liikenteen päätepisteiden perusteella. Tällöin alkeisvirrat ohjautuvat mallinnetuille reiteille.
5.2.7 Muutostilanteiden simuloiminen mallin avulla
Simuloinnin avulla tutkitaan, mitä valittujen palvelimien tai niiden suoritteiden poistaminen ja siirtäminen vaikuttaa eri toimipisteiden liittymiin ja liikennemääriin. Palvelimien suoritteita kutsutaan tästä lähtien yleisesti objekteiksi, sillä kaikki niihin kohdistuvat muutosoperaatiot tapahtuvat samalla tavalla.
Tehdystä mallista poistetaan tai siirretään kerrallaan joukko valittuja objekteja ja niihin liittyvät liikennevirrat ohjataan vastaanottaviin toimipisteisiin ja palvelimiin, eli toisiin objekteihin. Tällöin segmentti, jonka objekti on muodostanut, häviää. Tämän myötä liikennettä välittävät polut rakentuvat eri segmenteistä kuin ennen muutosta.
Kuva 5 Objektin poistaminen mallista
Esimerkissä objekti E poistetaan, jolloin segmentti CE häviää. Segmentin muutoksen myötä myös polut muuttuvat. Ennen muutosta polku AE rakentui segmenteistä AB, BC ja CE, kun taas muutoksen jälkeen kyseistä polkua ei enää
Objektin lisäämisessä malliin voi olla kaksi erilaista tapausta. Ensimmäisessä tapauksessa objekti lisätään paikkaan, jossa se muodostaa uuden segmentin.
Tällöin objektiin muodostetaan yhteys lähimpään toiseen objektiin. Tämä voidaan ymmärtää esimerkiksi uuden sovelluksen lisäämisenä toimipisteen lähiverkkoon.
Toisessa tapauksessa objekti lisätään jo olemassa olevaan segmenttiin. Tällöin vanha segmentti katkeaa ja tilalle syntyy uusi segmentti, jossa lisätty objekti muodostaa yhteyden viereisiin objekteihin.
Kuva 6 Objektin lisääminen malliin
Esimerkissä objekti F lisätään topologiaan ja se muodostaa yhteyden viereiseen objektiin D, jolloin syntyy segmentti DF. Lisäksi objekti G lisätään objektien Aja В väliseen segmenttiin, jolloin se muodostaa yhteyden molempiin objekteihin luoden kaksi uutta segmenttiä AG ja GB.
Objektin siirtämisessä tapahtuu samanlainen tilanne kuin edellä kuvatuissa tilanteissa. Ensin objekti irrotetaan mallista, jonka jälkeen se siirretään, eli lisätään, toiseen paikkaan.
Liikenteen uudelleenohj aaminen tapahtuu määrittelemällä muuttuville liikennevirroille uudet päätepisteet, eli liikenteen kohteet. Tämä tehdään muuttamalla liikennetaulusta rivejä, joissa on poistettava tai siirrettävä palvelimen suorite. Näistä liikenneriveistä muutetaan kohde vastaamaan uutta sijaintia. Tämä on kuvattu esimerkissä kappaleessa 5.2.9. Ideaalinen tilanne olisi, jos liikenteen uudelleen ohjaaminen tapahtuisi automaattisesti, jolloin liikennetauluja ei tarvitsisi itse muuttaa. Tämä on yksi asia, jolla tavalla käytössä ollutta
