Palvelimen Virtualisointi

Palvelimen Virtualisointi

Palvelimen Virtualisointi Tekijänoikeudet 2007 Lari Korpi

Sisällys 1. Johdanto... 1 Miksi virtualisoida?... 1 Miksi virtualisoida palvelimia?... 5 2. Käsitteitä... 6 Palvelinprosessi... 6 Palvelinkone... 6 Virtuaalipalvelin... 7 3. Kehityshistoria... 8 Käyttöjärjestelmät... 8 Ensimmäinen sukupolvi... 8 Toinen sukupolvi... 10 Multics... 11 Kolmas sukupolvi... 12 Neljäs sukupolvi... 15 Horisontissa viides sukupolvi... 16 Virtualisointi... 18 Virtuaalikoneet... 19 4. Menetelmät... 20 Looginen ositus... 20 Järjestelmäpyyntöjen tulkkaus... 20 Ryvästys... 20 Emulaatio... 21 Kokonaisemulointi... 21 Osittaisemulointi... 22 5. Toteutuksia... 24 Laitteisto... 24 Intel Vanderpool Technology... 24 AMD Pacifica... 25 LPAR... 25 Ohjelmisto... 25 Java-virtuaalikone... 25 MS Virtual Server 2005... 26 Parallel Virtual Machine... 26 User mode Linux... 26 VMware... 27 Xen virtual machine monitor... 28 6. Kohteita... 30 Referenssijärjestelmä... 30 Tietokannat... 31 Sovellukset... 31 Käyttöliittymät... 32 Kehitysympäristö... 32 Tarpeet... 32 Ratkaisut... 33 Referenssijärjestelmän kehitys virtualisoituna... 33 Testausympäristö... 34 Tarpeet... 34 Ratkaisut... 34 Referenssijärjestelmän testaus virtualisoituna... 34 Tuotantoympäristö... 35 Tarpeet... 35 iii

Palvelimen Virtualisointi Ratkaisut... Referenssijärjestelmän tuotanto virtualisoituna... 7. Yhteenveto... Lähteet... iv 36 36 38 39

Luku 1. Johdanto Virtualisatio perustuu abstraktioon virtualisoitavasta kohteesta. Abstraktion käyttämien tarkoittaa, että virtualisoitavan kohteen ominaisuudet irrotetaan reaalisesta ominaisuuden käsitteestä. Reaalisten ominaisuuksien poisto virtualisoinnin yhteydessä ohjaa virtualisointia käsitteleviä dokumentteja huomattavasti teoriapainotteisuuteen. Virtualisoinnilla poistetaan virtualisoitavan kohteen sidonnaisuuksia sitä toteuttavaan fyysiseen laitteeseen. Tietokonetekniikassa tietokoneiden virtualisoinnin alkuperäisenä tehtävänä oli monistaa useita ilmentymiä tietokoneesta, mutta myöhemmin myös usean tietokoneen yhteyttäminen yhdeksi virtuaalilaitteeksi tietokoneeksi on saanut kaupallisia sovelluksia. Virtualisoinnin eri toteutuksilla on näin ollen hyvin erilaisia tavoitteita, ja virtualisointitekniikoita on siis vaikea arvioida keskenään yleisesti yksiselitteisellä paremmuus järjestyksellä. Miksi virtualisoida? Logiikan perustana on käsitellä asioiden esityksiä tosina tai epätosina. Tämän kaltaisen loogisen ajattelun isänä pidetään Sokratesta. Sokrateen oppilaista tunnetuin oli Platon, joka mm. kirjoitti talteen Sokrateen puolustuspuheen. Platon jatkoi Sokrateen loogisen ajattelun mallia luomalla käsitteen ideamaailmasta. Ideamaailma on maailma, jossa ei ole lainkaan fyysisiä esineitä vaan esineiden tilalla niitä edustaa esineen idea. Ideamaailman ideat myös kuvaisisivat kaikki reaalimaailman samaa ideaa toteuttavia esineitä, eli esimerkiksi kaikkia reaalimaailman tuoleja edustaisi ideamaailmassa yksi tuolin idea. Virtualisoinnissa luodaan ympäristö, jossa ideamaailman tavoin tarvitaan vain idea virtualisoitavasta asiasta. Tietotekniikassa tämä asian idea kuvataan tietokoneohjelman avulla. Ohjelma saa näin ollen tietokonelaitteiston toimimaan tietokoneohjelman kuvaaman idean tavoin. Joseph-Marie Jacquardin kehittämä kutomokone toteutti tämän ohjelmoinnin periaatteen kutomisessa kutomalla kuvioita reikäkorttien ohjaamana. /1, s. 178./ 1

Johdanto Kuva 1. Ada Byron, Lovelacen herttuatar Kuten ideaa ideamaailmassakin niin myös tietokoneohjelmaa voidaan käyttää useassa tietokoneessa. Tietokoneohjelman ja ohjelmoitavan yleiskäyttöisen tietokoneen käsitteet ovat peräisin 1800-luvulta, jolloin Ada Byron, Lovelacen herttuatar (kuva 1) ja Charles Babbage rupesivat kehittämään Analyyttistä Konetta. Adaa, jonka Babbage palkkasi tekemään Analyyttisen Koneeseen ohjelmia, voidaan pitää ohjelmoijien ammattikunnan äitinä. Ada oivalsi, mitä hyötyä oli asioiden abstraktionnista ja abstraktiota käyttäen koneellisesta analysoinnista. Tämän oivalluksen hän muotoili seuraavasti: Voidaan hyvin sanoa, että Analyyttinen Kone kutoo algebrallisia kaavoja siinä missä Jacquardin kutomakone kukkia ja puiden lehtiä. Ada Byron /1, s. 179./ Erinäisten mekaanisten apuvälineiden käyttäminen laskennassa oli ennen taskulaskimia suosittua, mutta laitteet suunniteltiin vain tiettyjä laskuoperaatioita varten. Ennen Turingin (kuva 2.a) yleistä tilakonetta tiedonkäsittely jaettiin rakenteellisesti kolmeen luokkaan, jotka olivat kone, ohjelmisto ja tietoaineisto. Koneen käsite muodostui laitteen fyysisestä kokonaisuudesta. Ohjelma-käsite piti sisällään käskyt, joiden perusteella laitettiin kone operoimaan tietoaineistoa tietoaineiston ollessa syötettä, jonka kone/ ohjelmakokonaisuus muunsi tulosteeksi, kuten esimerkiksi reikäkorttilajittelijat. /1, s. 167./ 2

Johdanto Kuva 2.a Alan Mathison Turing 3

Johdanto Kuva 2.b John von Neumann Turing kehitti tilakoneensa teorian tutkiakseen yhtä jo ratkaistua matemaattista ongelmaa. Tämä ongelma oli Hilbertin mukaan nimetty Hilbertin ratkaisuongelma. Ratkaisuongelma on toinen 23:sta Hilbertin vuonna 1900 toisessa kansainvälisessä matemaatikkokongressissa esitetyistä matemaattisista ongelmista ja sen kysymyksenä oli Onko aksioomien ristiriidattomuus todistettavissa? /2, s. 851, 852/. Omaan tutkimukseensa Turing otti kysymykseksi Voidaanko kaikkien matemaattisten ongelmien ratkaisuille määrittää algoritmi?, joka kuvaa ratkaisun ongelmaa logiikan termein. /1, s. 148-150./ Turing aloitti tilakoneensa toiminnan kehittämisen kone, ohjelma ja tietoaineisto -jaon mukaisesti. Mutta todistettuaan, että kaikkien matemaattisten ongelmien ratkaisujen luomiseen ei ole algoritmia, häntä alkoi askarruttaa, olisiko olemassa yleistä tilakonetta, joka voisi toteuttaa toisten yleisten tilakoneiden operaatioita. Tämän yleisen tilakoneen hän kehitti liittämällä ohjelman osaksi koneen vastaanottamaa syötettä. /1, s. 167./ Turingin yleisen tilakoneen luomisen jälkeen on ohjelmiston ja laitteiston välille syntynyt sotatila. Tämän rajan vaikeutta sekä tulkinnan tapaa henkilöityä kuvaa siitä ensimmäiseksi taistelleet henkilöt Turing ja von Neumann (kuva 2.b). Von Neumannin kantaa ohjelmiston ja laitteiston rajasta kuvastaa hänen reaktionsa erään opiskelijan tarjoukseen laatia symbolisen konekielen kääntäjä, joka olisi automatisoinut normaalisti opiskelijoilla käsityönä teetetyn kääntämistyön. Von Neumannin piti tätä moukkamaisena ideana, sillä hänen mielestä arvokkaan tieteellisen työkalun valjastaminen puhtaasti mekaaniseen tehtävään olisi ollut järjetöntä. Turing puolestaan kirjoitti hänen ACE-tietokoneprojektia käsittelevässä raportissaan, että tietokoneen ohjelmoiminen on varmasti erittäin kiehtovaa. Ei ole syytä pelätä, että se muuttuu koskaan pelkäksi työlääksi puurtamiseksi, sillä kaikki puhtaasti mekaaniset tehtävät voidaan jättää koneen itsensä huoleksi. /1, s. 192./ 4

Johdanto Ohjelmistokehityksen osaamisen merkitys tietotekniikan projektien onnistumiselle tuli ilmeiseksi, kun yksityisen sektorin yritykset rupesivat kehittämään yleiskäyttöisiä tietokonejärjestelmiä. Ohjelmistokehityksen tutkimuksen kiihdyttämiseksi järjestettiin NATO:n Science Committeen alaisen tietotekniikan tutkimusryhmän toimesta ensimmäinen 'Software Engineering' -konferenssi. Konferenssin tavoitteena oli luoda ohjelmistokehityksestä oma tietotekniikantutkimuksen aihealue muiden tietotekniikkaa edistäneiden tutkimusalojen rinnalle. /3, s. 8, 70-72./ Miksi virtualisoida palvelimia? Syvimmillään tietokoneiden virtualisoinnin juuret ovat suurkoneympäristössä. Virtualisoinnin käyttöönotto alemman hintaluokan tietokonearkkitehtuurissa on tuonut mukanaan ensimmäisenä myönteisenä vaikutuksena alentuneet laitekustannukset, kun samalla laitteistolla on voitu toteuttaa useita eri palveluita. Koko ympäristön virtualisointi kehityksestä tuotantoon tuo mukanaan vielä lisää etuja. Tämän kaltaisessa järjestelmässä virtualisointi helpottaa kehitystyötä, koska sovellukset voidaan suunnitella yhdelle arkkitehtuurille eikä suunnittelijan tarvitse ottaa huomioon mm. mahdollista myöhempää järjestelmän hajauttamista. /4./ PC-pohjaisten palvelinten edullisten hankintakustannusten johdosta organisaatioiden palvelinkaluston määrä on kasvanut huomattavasti, koska organisaatiot ovat hankkineet palvelimia palvelemaan yksittäisiä järjestelmiä. Järjestelmien määrän kasvaessa ongelmaksi on tullut palvelintilojen tarpeen kasvu sekä hallintaan tarvittavien henkilöresurssien määrän kasvu. Järjestelmän kehityksen alkuvaiheessa on myös voitu arvioida väärin järjestelmän tuleva käyttäjämäärä ja käytön aikana voi tulla tarvetta jälkikäteen järjestelmän kapasiteetin kasvattamiseen. Jo olemassa olevan järjestelmän kapasiteetin kasvattaminen on aina hyvin työlästä ja voi pahimmassa tapauksessa olla mahdotonta, mikäli järjestelmä on vahvasti yhteen tietokonearkkitehtuurin sitoutunut. Palvelimen virtualisointia voidaan käyttää myös vanhojen sovellusten ajamiseen uudemmassa laitteistossa. PC-arkkitehtuurilla vanhempien ohjelmistojen käyttöiän jatkamisen on tehnyt ajankohtaiseksi Microsoftin ilmoitus laajasti hyödynnetyn Windows NT- ja Windows 2000 käyttöjärjestelmien tuen lopettamisesta. Myös Linux- ja Mac OS X -käyttöjärjestelmiin siirtyneet ovat käyttäneet mm. VMware:n ja Parallelsin tuotteita vanhojen Windowsohjelmiensa suorittamiseen. 5

Luku 2. Käsitteitä Tietotekniikka teknologianalana on ollut voimakkaan kehityksen kohde Toisen Maailmansodan jälkeen. Suurin osa tästä kehityksestä on tapahtunut ympäri maailmaa ja tästä johtuen tietotekniikan käsitteistö on hyvin kirjava ja moniselitteinen. Eri käsitteistä voi olla hyvin erilaisia tulkintoja. Tämän luvun tarkoitus on kuvata tässä työssä käytetyt käsitteet, jotta lukijoille tulisi yksiselitteinen kuva työn kuvaamista tekniikoista. Palvelinprosessi Prosessi on yksinkertaisimmillaan tietokoneohjelma, joka on ladattuna tietokoneeseen ja jota tietokone suorittaa. Käyttöjärjestelmän toimesta prosessille annetaan myös muita ominaisuuksia, joita voivat olla mm. oma muistialue. /5, s. 34./ Kuva 3. Asiakas-palvelin-malli Palvelinohjelman tehtävänä on tarjota asiakasprosessille tiettyjä resursseja palvelun muodossa /6, s. 21./. Kuvan 3 mukaisesti asiakas-palvelin -mallissa aktiivinen osapuoli on asiakas, joka esittää palvelimelle pyynnön. Palvelin antaa pyynnön käsittelyn tuloksena asiakkaalle vastauksen. Jotta palvelin pystyisi tähän, tarvitsee se itse puolestaan resursseja, jotka yleensä ovat palvelinprosessia suorittavalla tietokoneella. Palvelun tarjoamiseen tarvittavat resurssit voivat myös olla toisten palvelinprosessin tuottamia, kuten keskitetyn käyttäjähallinnan tarjoamat käyttäjätiedot tai tietokantahallintajärjestelmän tarjoama tietokanta. Usein palvelinprosessin tarkoitus on käsitellä useita palvelupyyntöjä eri asiakkailta samanaikaisesti. Asiakasohjelman tehtävänä on piilottaa resurssin todellinen sijainti ja tarjota palvelinprosessin resurssit omina ominaisuuksinaan. Palvelinprosessin suorittamat tehtävät ovat usein yksinkertaisempia verrattuna asiakasohjemaan, mutta useasta asiakasta syntyvä kuormitus on syynä palvelinkoneiden normaalia työasemaa suurempaan resurssitarpeeseen. Palvelinkone Palvelinkone on tietokone, joka suorittaa palvelinprosessia tai -prosesseja kuten kuvassa 4. Palvelinkoneiden toiminta vaikuttaa usean asiakkaan kykyyn suorittaa tehtäviään. Tästä johtuen palvelinkoneissa palvelun katkottomuuden eteen tehdään paljon työtä ja palvelinkoneen resurssit ovatkin yleensä vikasietoisia, mikä nostaa palvelinkoneen hankintakustannuksia suhteessa normaaliin työasemaan. 6

Käsitteitä Kuva 4. Palvelinprosessit osana palvelinta Vaikka palvelinprosesseilla voikin hetkittäin olla useita palvelupyyntöjä, suurin osa palvelinkoneen ajasta menee odottaessa palvelupyyntöjä asiakkailta, koska palvelinkoneen palvelua ei tarvita jatkuvasti. Mikäli yksi palvelinkone voi tarjota useampaa palvelua, saadaan odotteluaikaa vähennetyksi. Usean palvelun tarjoaminen samalla palvelinkoneella mutkistaa kuitenkin palvelinkoneen palvelinprosessien hallintaa ja tietoturvaa. Mikäli yhden palvelun päivitys tarvitsee koko palvelinkoneen uudelleenkäynnistämistä, joudutaan kaikki palvelut keskeyttämään uudelleenkäynnistyksen ajaksi. Tietoturva usean palvelun palvelinkoneessa on aina heikompi kuin yhden palvelun palvelinkoneessa, koska palveluiden itsensä sisältämät tietoturvariskit kasaantuvat yhdelle koneelle. Virtuaalipalvelin Virtuaalinen palvelin voidaan perustaa isäntäjärjestelmään, josta otetaan virtuaalipalvelimelle käyttöön tarvittava määrä eri resursseja. Resurssien tarpeen mukainen saanti alentaa resurssien ylläpidon kustannuksia, mikäli isäntäjärjestelmään jääviä resursseja voidaan edelleen hyödyntää toisten virtuaalipalvelinten käyttöön. Isäntäjärjestelmästä riippuen voidaan palvelulle perustamisen jälkeen tarvittaessa luovuttaa lisää resursseja ilman, että koko järjestelmä jouduttaisiin välillä täysin ajamaan alas. Kuva 5. Virtuaalipalvelimet palvelinprosessina Virtuaalipalvelin voidaan toteuttaa isäntäkoneen sisäisenä palvelinprosessina, kuten kuvassa 5 on esitetty. Tällöin virtuaalipalvelin ei isäntäkoneen näkökulmasta eroa muista palvelinprosesseista. Virtuaalipalvelimen käyttäjällä ei välttämättä ole mitään mahdollisuutta tietää, käyttääkö hän virtuaalipalvelinta tai virtualisoimatonta palvelinta. Virtuaalipalvelin voi myös olla rinnakkainen, eli ilman varsinaista isäntää. Tällöin erillinen ohjelmisto jakaa koneen osiin ilman käyttöjärjestelmää ja virtuaalipalvelinten hallinta tapahtuu virtuaalipalvelimien itsensä kautta erillisellä virtualisointikerroksen hallintaohjelmalla. 7

Luku 3. Kehityshistoria Käyttöjärjestelmät Käyttöjärjestelmien tehtävänä on hallita prosesseja ja tarjota niille niiden haluamia resursseja. Virtualisoinnin tehtävänä on puolestaan hallita usean eri käyttöjärjestelmän suoritusta samassa järjestelmässä. Virtualisoinnin kannalta on tärkeitä tietää käyttöjärjestelmän vaatimuksien laatu. Käyttöjärjestelmien kehitys voidaan nähdä jakautuvan neljään kehitysvaiheeseen. Ensimmäinen sukupolvi Yleiskäyttöisen tietokoneen perusta on ohjelmoitavuus. Kuva 6 näyttää yleistyksenä yksinkertaisimman tietokonejärjestelmän kuvauksen. Jotta yleiskäyttöinen tietokone olisi yleiskäyttöinen, voidaan ohjelmalla määrittää laitteiston toimintaa. Tämä yksinkertainen teoria ohjelmiston abstraktiosta oli perustana Charles Babbagen suunnittelemalle ja Ada Augusta Lovelacen ohjelmoimalle Analyyttiselle Koneelle, jonka mekaanista laitteistoa ei koskaan saatu toimimaan, mutta joka sai kuitenkin aikaiseksi kiinnostusta yleiskäyttöisen tietokoneen käsitettä kohtaan. /5, s. 14-15./ Kuva 6. Yksinkertainen tietokonejärjestelmä Kuva 7.a Colosus Mark II 8

Kehityshistoria Kuva 7.b ENIAC Toinen maailmansota loi kaksi erillistä tietojenkäsittelyn tarvetta, joiden ratkaisemiseksi tietokoneita alettiin kehittää. Liittoutuneet tarvitsivat laskentatehoa tieteelliseen laskentaan ja tämä tarve ajoi Britanniassa Colosus:en (kuva 7a) ja Yhdysvalloissa ENIAC:in (kuva 7b) kehittämiseen. Colosus, joka oli ensimmäinen elektroninen tietokone, rakennettiin murtamaan Natsi-Saksan ENIGMA -salauslaitteilla salattuja viestejä. Koska tämä työ oli sotilastiedustelua, kaikki projektiin liittynyt materiaali luokiteltiin 30 vuodeksi erittäin salaiseksi. Colosusen tietoteknisistä ratkaisuista ei näin ollen sodan jälkeen ollut apua tietotekniikan kehitykselle Britanniassa /5, s. 16/. ENIAC:ia puolestaan käytettiin vain tykistön ampumataulukoiden laatimiseen /7, s. 32./. Vaikka itse koneissa ei ollut käyttöjärjestelmää, niin käyttöjärjestelmän toiminnoista resurssienjako oli toteutettuna tietokonejärjestelmän ulkopuolella olleelle taululle. Tälle taululle merkattiin tietokoneen käyttövuorot ja ohjelmat ladattiin tietokoneeseen sen mukaisesti. /5, s. 6-7./ Kuva 8. Zuse Z1 Natsi-Saksassa ei uskottu ohjelmoitavien tietokoneiden hyödyllisyyteen, vaikka mm. Zuse vuonna 1936 kehitti Saksassa ensimmäisen releillä toimivan laskurin (kuva 8). Zuse ei kuitenkaan saanut valtion rahoitusta ja kehitys tyrehtyi /5, s 14 15./. Natsi-Saksa kuitenkin käytti suuressa määrin tietotekniikkaa 9

Kehityshistoria reikäkorttilaskureiden ja -lajittelijoiden muodossa. Niiden avulla natsit rakensivat infrastruktuurin mm. yleiseen terveydenhoitoon ja keskitysleireille. Ensimmäiset tietokoneet rakennettiin elektroniputkilla, joten putkien kulumisen johdosta tietokoneen keskeytymätön käyttöaika ei aina ollut riittävän pitkä koko ohjelman suorittamiseen /5, s. 7./. Putkien rikkoutumisen johdosta vuonna 1958 valmistunut SAGE-järjestelmällä, jota voidaan pitää ensimmäisen tietokonesukupolven huipentumana, saavutettiin mm. kahdennusta hyödyntävillä vikasietoisuus menetelmillä vain 97 %:n käytettävyys /8, s. 233./. 97 %:n käytettävyys tarkoittaa, että SAGE oli vuodesta yhteensä noin kymmenen ja puoli päivää poissa käytöstä. SAGE:n tehtävänä oli tarjota Pohjois-Amerikan kattava ilmavalvonta verkko, jotta Neuvostoliitto ei pystyisi tekemään Pohjoisnavan yli pommikoneilla yllätys hyökkäystä. SAGE-järjestelmä pystyi seuraamaan lentokoneita ja mikäli vihollinen havaittiin, se pystyi antamaan kohtaamispaikan koordinaatit sekä hävittäjälentäjille että ydinlatauksella toimiville ilmatorjuntaohjuksille. /9, s. 78-80./ Toinen sukupolvi Jatkuva laitekohtaisen koodin uudelleen kirjoittaminen loi tarpeen luoda yksinkertaisia käskyjä, jotka hoitaisivat yhden monivaiheisen tehtävän. Esimerkiksi nauhalta tietyn kohdan lukemista varten pitää ensin varmistaa, että nauha on asetettu nauhuriin. Kun on saatu tieto, että nauhurissa on nauha, joudutaan nauha kelaamaan alkuun. Alkuun kelatusta nauhasta täytyy tarkistaa, onko se haluttu nauha vai joku muu jne. Kuvan 9 mukaisesti käyttöjärjestelmä luotiin laitteiston ja ohjelmiston väliin yksinkertaistamaan laitteiston käyttöä ohjelmiston ja ohjelmoijan kannalta. Kuva 9. Toisen sukupolven järjestelmän hierarkia Kuva 10. Nasan lennonohjaksen tietokonesali, jossa kaksi IBM:n 7090:ä, vuodelta 1962 Ensimmäisen sukupolven käytettävyysongelmat voitiin toisen sukupolven tullessa ratkaista Texas Instruments:in vuonna 1954 esittelemien piitransistorien avulla. Transistorien periaate oli kehitetty jo vuonna 1947, mutta ensimmäiset germaniumtransistorit eivät kestäneet tarpeeksi lämpöä, jotta niitä olisi voitu hyödyntää tietokoneiden valmistuksessa. /10, s. 11, 74./ 10

Kehityshistoria Kuva 10. Kuvassa vasemmalta lukien IBM 1402 reikäkorttienlukija, 1402 prosessointiyksikkö, 1403 tulostin ja 729 magneettinauhayksiköt Kun koneiden huoltovälit pitenivät, voitiin yhden huoltovälin aikana suorittaa useita eri ohjelmia. Huollon määrän vähentyessä tietokoneen kapasiteetin hyödyntämisen pullonkaulaksi muodostui useiden töiden saaminen jonoon niin, että keskuskone olisi täystyöllistetty. Yksi ensimmäisten tietokoneeseen toteutettujen käyttöjärjestelmien tehtävistä olikin suorittaa ohjelmajonoja magneettinauhalta. Magneettinauhan ohjelmat oli syötetty reikäkortilta erillisellä koneella. /5, s. 7-8./ Multics 60-luvun alussa MIT:issa kehitettiin Compatible Time Sharing System (CTSS), joka oli ensimmäinen aikajakoa toteuttanut järjestelmä. CTSS:in laitteistona käytettiin MIT:n muunnelmaa IBM:n 7094:sta (kuva 9). Aikajaosta saadut positiiviset kokemukset rohkaisivat MIT:iä, Bell Labs:ia ja General Electric:ia käynnistämään yhteisprojektin, jonka nimeksi annettiin Multiplexed Information and Computing Service (MULTICS). /5, s. 12./ MULTICS:n alkuperäisenä liikeideana oli rakentaa tietokonejärjestelmä, jonka laskentatehoa voitaisiin tarjota kaikille halukkaille Bostonin alueella. Laitteiston laskenta teho oli noin Intel 386 -prosessorin luokkaa, mikä oli valtava ottaen huomioon 60-luvun ohjelmistot. MULTICS ei kuitenkaan saavuttanut kaupallista suosiota, koska sen mukanaan tuomat uudet tekniikat ja rakenteet osoittautuivat vaikeiksi toteuttaa. Järjestelmän viimeinen komponentti, PL/I-ohjelmointikielen kääntäjä, valmistui lopulta viisi vuotta kehitystyön aloittamisen jälkeen vuonna 1970. /5, s. 12./ 11

Kehityshistoria Kuva 11. MULTICS:n logo kangasmerkkinä Koska MULTICS suunniteltiin monen käyttäjän järjestelmäksi, oli myös tietoturvallisuus tärkeä suunnittelun näkökulma. MULTICS:ssa prosessien keskinäisen suojauksen perustana oli suoritustilojen kehähierarkia, joka nähtiin niin tärkeänä ominaisuutena, että MULTICS:in logo, joka on kuvassa 11, perustuu tuon kehähierarkian kuvaukseen. Myöhemmin kehähierarkiaa on sovellettu mm. Intel:in x86arkkitehtuurissa. /11./ Kehähierarkian periaatteena on erottaa kokonaisuudesta osia, joihin käsiksipääsemistä varten on mentävä erityisten tarkistuspisteiden läpi kuten: Sillä sen lainen oli Minas Tirith, että se oli rakennettu seitsemään tasoon ja jokaisen ympärille oli pystytetty muuri ja joka muurissa oli portti. Mutta portit eivät olleet peräkkäin: kaupunginmuurin Suuri Portti oli kehän itäreunalla, mutta seuraava antoi puolittain etelään, ja kolmas pohjoiseen ja niin edelleen edestakaisin yhä ylemmäksi. Taru Sormusten Herrasta /12./ Kehähierarkialla voidaan suojata ohjelmia toisten ohjelmien virheiltä, koska ohjelmien väliseen eristämiseen liittyvät toiminnot voitiin sijoittaa sisempiin kehiin. Jotta ohjelma pystyy käyttämään sisempien kehien resursseja, sen täytyy kutsua portinvarjoina toimivia järjestelmäkutsuja tarpeiden välittäjäksi./11./ Kuva 12. Honeywell 6180 vuodelta 1976 Vuonna 1969 Bell Labs vetäytyi MULTICS projektista ja osana Bell Labs:in MULTICS:ia kehitystä ollut Ken Thompson jäi ilman projektia. Uutta projektia odotellessaan hän kirjoitti vapaaksi jääneelle vanhalle PDP-7minitietokoneelle riisutun, yhden käyttäjän, version MULTICS:ista ja antoi sille nimeksi Uniplexed Information and Computing Service (UNICS). /5, s.672, 673./ MULTICS projektin ainoaksi kaupalliseksi organisaatioksi jäänyt GE myi vuonna 1970 koko tietokonetoimintansa Honeywellille, joka rupesi myymään MULTICS-järjestelmiä omalla nimellään (kuva 12). Kolmas sukupolvi Kolmannen käyttöjärjestelmäsukupolven mukana yhteiskäyttöisyys sai enemmän laitepohjaista tukea. Kuvan 13 esittämä järjestelmähierarkia vaatii laitetasolla suoritettavaa muistin suojaamista. Muutoin prosessien erotus toisistaan ei ole mahdollista. 12

Kehityshistoria Kuva 13. Kolmannen sukupolven järjestelmän hierarkia Kuva 14.a IBM 1800:en kuulunut kehikko, joka on kalustettu Solid Logic Technology (SLT) -piirikorteilla 13

Kehityshistoria Kuva 14.b Yksittäinen tuplaleveyksinen STL-kortti 1960-luvulla esitelty IBM:n System/360 ja sen käyttöjärjestelmä OS/360 toivat mukanaan keskeisiä ominaisuuksia, kuten moniajo ja muistinositus, joita tarvitaan usean asiakkaan palvelimen tuottamiseen. Myös tietokonehuoneet muuttuivat, sillä System/360:n kanssa ei tarvittu erillistä tietokonetta reikäkorttien lukemiseksi magneettinauhalle. System/360 koostui kuudesta eri tietokonekokonaisuudesta, joilla oli yhteinen arkkitehtuuri ja käskykanta. Nämä kokonaisuudet erosivat toisistaan vain hinnan ja tehokkuuden suhteen, joten käytännössä halvimmalle System/360-koneelle tehdyt ohjelmat toimivat myös kalleimmassa kokoonpanossa. /7, s. 37; 6, s. 9-11./ IBM:lle System/360:n kehitys oli valtava sijoitus ja kustannuksiltaan se oli suurempi kuin Yhdysvaltain toisen maailmansodan aikainen ydinaseohjelma /8, s. 346-347/. IBM:n System/360:n kehityksessä kohtaamat ongelmat tulivat ensimmäistä kertaa esiin ja niiden kautta ohjelmiston merkitys tietojenjärjestelmien toiminnalle alettiin ymmärtää /3, s. 67./. Yksi kolmannen sukupolven tuomista käyttöjärjestelmistä oli Unix. Unix on syntymänsä jälkeen ollut tietotekniikan musta hevonen, koska sen ominaisuuksista tärkein oli siirrettävyys muihin järjestelmiin. Kun Ken Thompson oli saanut UNICS:in valmiiksi, se todettiin niin onnistuneeksi, että siitä päätettiin tehdä versio PDP-11:lle, joka ei ollut yhteensopiva vanhemman PDP-7:n kanssa. /5, s. 672, 673./ 14

Kehityshistoria Kuva 15. Richie ja Thompson PDP-11:en ääressä PDP-11:n versiota varten Thompson ja hänen avukseen tullut Dennis Ritchie päättivät ensin muotoilla korkeamman asteen ohjelmointikielen, josta ohjelmat voitaisiin kääntää. Tämän kielen oli tarkoitus auttaa myöhemmin muihin laitteistoihin tehtävien mukautusten kanssa. Ensin he yrittivät kirjoittaa Unixia epäonnisesti Thompsonin suunnitteleman B-kielen kanssa, jonka jälkeen Ritchie suunnitteli C-kieleen, mistä tuli kaikkien myöhempien Unix:ien ja useiden muiden järjestelmien ohjelmoinnin perusta. /5, s. 673./ Unixin omistanut Bell Labs kuitenkin menetti oikeuden päätöksen johdosta kyvyn kaupallisesti hyödyntää Unixia, koska sen katsottiin tällöin käyttävän väärin määräävää markkina-asemaansa. Näin ollen Unixin lisenssit olivat halpoja ja sisälsivät myös oikeuden alkuperäiseen lähdekoodiin. Varsinkin Yhdysvaltalaiset yliopistot hankkivat Unix-lisenssejä ja näin syntyi sukupolvi tietotekniikan osaajia, joille Unix oli tutuin silloisista käyttöjärjestelmistä. Monet yliopistot tekivät myös omia muutoksiaan alkuperäiseen Unixiin ja jakoivat näitä muutoksia vapaasti toisille Unix-käyttäjille. /5, s. 672 676./ Neljäs sukupolvi PC-koneiden eli henkilökohtaisten tietokoneiden julkaisun myötä syntyi uusi tapa käyttää tietokoneita. Enää tietokoneita eivät käyttäneet ainoastaan niihin koulutetut insinöörit vaan myös toimistoissa sihteerit ja toimihenkilöt. Käyttöjärjestelmän piti näin ollen olla käyttäjäystävällinen ja käytettävien ohjelmien tarkoitus ei ollut ennustaa säätä vaan olla laskennan apuvälineenä ja korvata kirjoituskone dokumenttien tuotossa. 15

Kehityshistoria Kuva 15. IBM PC 5150 Tätä neljättä sukupolvea ei voi kaikkien ohjelmien näkökannalta pitää sukupolvena, sillä palvelinohjelmien näkökulmasta se on kolmannen sukupolven tekniikkaa. Sukupolven tietokoneet toimivat kolmannen sukupolven käyttöjärjestelmien periaatteilla, mutta tärkeimmät usean samanaikaisen käyttäjän palvelun ominaisuudet puuttuivat henkilökohtaisista tietokoneista. Kun toimistoissa alkoi olla useampia henkilökohtaisia tietokoneita, nousi tiedon jakamisen tarve ja harvemmin käytetyt resurssit, kuten tulostus, oli tarve keskittää henkilökohtaisten tietokoneiden käyttäjien kesken. 1980luvun puolivälissä tätä hajallaan olevan tiedon ja resurssien ongelmaa alettiin ratkaista lähiverkoilla ja lähiverkkojen kautta käytetyillä PC-palvelimilla. Alkuaikoina PCpalvelimet olivat vain kovalevyllä ja tulostimella terästettyjä henkilökohtaisia tietokoneita, jotka tarjosivat nämä resurssinsa muiden lähiverkon koneiden käyttöön. Suuremmissa organisaatioissa tietoa oli valmiiksi vietynä keskuskonejärjestelmiin. Koska henkilökohtainen tietokone tarjosi tehokkaamman alustan tehdä valmisteleva työ eräajo-ohjelmien laatimisessa ja raportoinnissa, haluttiin pian saada nämä kaksi eri tietokonetyyppiä keskustelemaan keskenään. Keskustelua varten tehtiin terminaaliemulaattoriohjelmia, joita voitaneen pitää ensimmäisinä asiakasohjelmina. Lähiverkkoympäristöjen tapaan keskuskoneisiin ei kuitenkaan ollut kaikilla pääsyä, vaan pääsy oli rajoitettu vastuuhenkilöille, minkä vuoksi keskuskoneet ruvettiin näkemään kalliina ja kankeana ratkaisuna tiedon hallintaan. Horisontissa viides sukupolvi Kun tavoitteena on saada lisää luotettavuutta ja kapasiteettia, alkavat laitteistolliset rajat tulla näkyviin. Tällöin virtualisoinnin kautta voidaan liittää usean laitteen resurssit virtuaaliseksi laitteeksi. Kuva 17 esittää yksinkertaista ryvästystä suorittavaa virtualisointia, jossa virtualisoinnin hoitaa käyttöjärjestelmä. Kuva 17. Hajautettu käyttöjärjestelmä 16

Kehityshistoria Vuonna 1997 näki päivänvalon SETI@home, yksi suurimmista hajautetun laskennan projekteista maailmassa. Projektissa käytetään useita henkilökohtaisia tietokoneita samanaikaisesti laskemaan yhden projektin vaatimia laskuja. SETI@home ei kuitenkaan ole käyttöjärjestelmä vaan projekti, jossa osallistujien tietokoneet hakevat projektin palvelimelta laskentayksiköitä ja laskutoimitusten tulos lähetetään takaisin projektin palvelimille. /13./ Kuva 18.a Kalustettu HP Proliant BL -korttipalvelin kehikko, josta on kaksi palvelinta osittain ulosvedettynä Kuva 18.b Yksittäinen HP Proliant BL30p -palvelin Saman tehtävien jaon pohjalle on myös kehitetty käyttöjärjestelmätasolla toimiva tietokoneiden ryvästys. Ryvästetyt koneet voivat näkyä verkossa yhtenä koneena ja ryppäälle tulevat pyynnöt käsitellään ryvästystekniikasta riippuen. Voidaan siis katsoa, että ryvästys on virtualisaatiota laitteistosta, jolla on useampia fyysisiä ilmentymiä kuin loogisia ilmentymiä. Kuvan 18 kaltaisella korttipalvelinlaitteistolla voidaan virtualisoinnin kautta yksinkertaistaa vikatilanteiden hallintaa, sillä järjestelmään (kuva 18a) voidaan ilman koko järjestelmän alasajoa vaihtaa uusi palvelin (kuva 18b) vioittuneen tilalle. 17

Kehityshistoria Virtualisointi Ensimmäinen virtualisaatiota toteuttava kaupallisesti merkittävä tuote oli IBM:n System/370, joka suoritti laskentaresurssien loogista ositusta aikajaolla. Loogisen osituksen tehtävänä System/370:ssä oli pilkkoa fyysisen tietokoneen laskentaresursseja loogisiin lohkoihin, jotka toimivat omina koneinaan. Näitä loogisia osoita käyttäjät pystyivät hallitsemaan päätteiltä, joiden syöte ja tuloste oli sidottu tiettyyn loogiseen osioon. Näin voitin palvella useita käyttäjiä samanaikaisesti ja tietokoneen käyttöaste parani / 5, s. 625; 5, s. 59./. Virtualisoinnin tarve tuotantokäytössä kuitenkin väheni, kun mikrotietokoneet ja käyttöjärjestelmäpohjainen moniajo tulivat laajamittaiseen käyttöön. Kuva 19. System/370 Model 138 Virtualisointi on kuitenkin aina ollut käytössä kehitysympäristöissä, koska emulaatioilla toteutetulla virtualisoinnilla voidaan tutkia kehityskohdetta valkoisen laatikon periaatteella. Emulaatiossa suoritus pystytään pysäyttämään ja tilatietoja tutkimalla voidaan nähdä, mitä virtualisoidun kohteen sisällä tapahtuu. Valkoisen laatikon periaatteen mukainen kehitys on tehokkaampaa verrattuna mustan laatikon periaatteeseen, jossa voidaan tutkia ainoastaan syötteiden ja tulosteiden välistä suhdetta etsittäessä vikaa ja optimoitavia ohjelman osia. Varsinkin sulautettujen järjestelmien kehitystyökalujen mukana on yleensä emulaattori kohdearkkitehtuurista, jotta koodin vikoja sekä suorituksen pullonkauloja voidaan korjata. 1900-luvun lopusta alkaen Internet-palveluiden rakentaminen on ruvennut vaatimaan yhä useamman erillisen palvelintietokoneen käyttöä. 2000-luvulla yli 10 000 käyttäjää päivässä palvelevat Internetpalvelut ovat yleistyneet ja niiden toteuttamisessa yleensä käytetään kolmikerroksista käyttöliittymä-, sovellus- ja tietokantapalvelinhierarkiaa. Kussakin kerroksessa voi olla useita erilaisia palvelimia hierarkian osa-alueille. Suuren järjestelmän käyttöönotto vaikeutuu käytettävien palvelimien määrän kasvaessa ja tarvittava testaus alkaa tulla liian kalliiksi tai aikaa vieväksi ottaen huomioon järjestelmän rakentamiseen ja käyttöönottoon annetut resurssit. Virtualisaation käyttö testauksessa voi tuoda helpotusta useaan testauksen järjestämisen ongelmaan, ja näin virtualisointitekniikat ovat nousseet uudelleen esiin. 18