Virtualisointi koneista kontteihin: suorituskykyvertailu

Transkriptio

1 Virtualisointi koneista kontteihin: suorituskykyvertailu Anssi Junnola Pro gradu tutkielma Tietojenkäsittelytieteen laitos Tietojenkäsittelytiede Toukokuu 2019

2 ITÄ-SUOMEN YLIOPISTO, Luonnontieteiden ja metsätieteiden tiedekunta, Joensuu Tietojenkäsittelytieteen laitos Tietojenkäsittelytiede Opiskelija, Anssi Junnola: Virtualisointi koneista kontteihin: suorituskykyvertailu Pro gradu tutkielma, 86 s., 2 liitettä (2 s.) Pro gradu tutkielman ohjaaja: Simo Juvaste Toukokuu 2019 Tiivistelmä: Tietokoneiden virtualisointi on viime vuosina tullut yhä tärkeämmäksi tekniikaksi tietojenkäsittelytieteessä. Esimerkiksi pilvipalvelut perustuvat pitkälti virtualisointiin, ja niiden voidaan sanoa mullistaneen verkkopalvelut 2000-luvun puolesta välistä lähtien. Virtualisointityökalut voidaan jakaa kahteen eri päätyyppiin: hypervisor- ja konttipohjaisiin työkaluihin. Hypervisor-pohjaiset työkalut virtualisoivat koko tietokoneen, mukaan lukien laitteiston, joka voi tehdä niistä melko raskaita. Perinteisesti niiden suorituskyky on myös ollut verraten huono. Konttipohjaiset työkalut puolestaan virtualisoivat vain käyttöjärjestelmän, joka käyttää isäntäkoneensa resursseja hyväksi. Tämä tekee konteista virtuaalikoneita kevyempiä ja suorituskykyisempiä, joskin vähemmän joustavia. Eri virtualisointityökalujen suorituskykyä vertaillaan jatkuvasti, sillä ne muodostavat tärkeän osan nykypäivän verkkopalveluista. Toisaalta esimerkiksi niiden käytettävyyttä vertaillaan huomattavasti vähemmän. Tässä pro gradu -tutkielmassa esitellään virtualisointia eri näkökulmista. Virtualisoinnin tuomia mahdollisia hyötyjä ja haittoja sekä käyttökohteita käydään läpi. Tämän lisäksi hypervisor- ja konttipohjaisia tekniikoita esitellään hieman tarkemmin, tutustuen esimerkiksi niiden toimintaperiaatteisiin ja teknisiin toteutuksiin pintapuolisesti. Lisäksi tehdään kirjallisuuskatsaus eri virtualisointityökalujen suorituskykyihin vertailujen perusteella. Vaikka konttipohjaiset työkalut ovat historiallisesti olleet hypervisoreita suorituskykyisempiä, ovat erot kaventuneet viime vuosina. Lopuksi esitellään kirjoittajan tekemien suorituskykytestien tuloksia. Tuloksista on nähtävissä, että hypervisor-pohjaisten työkalujen suorituskyky on jatkanut parantumistaan, ja erot voivat olla jo hyvin pieniä. Kaiken kaikkiaan konttipohjaiset työkalut ovat kuitenkin edelleen hieman suorituskykyisempiä. Tässä tutkielmassa vertaillaan lisäksi päällisin puolin käytettävyyttä, joka on huomattavasti parempi konttipohjaisilla työkaluilla, etenkin Dockerilla. Virtualisointityökalua valittaessa onkin hyvä suorittaa myös omat, käyttötapauskohtaiset, suorituskykytestit. Avainsanat: virtualisointi, hypervisor, kontti, pilvi, suorituskyky, Docker, KVM, LXC ACM-luokat (ACM Computing Classification System, 1998 version): C.0, C.4, D.4.8 i

3 UNIVERSITY OF EASTERN FINLAND, Faculty of Science and Forestry, Joensuu School of Computing Computer Science Student, Anssi Junnola: Virtualization from machines to containers: a performance comparison Master s Thesis, 86 p., 2 appendixes (2 p.) Supervisor of the Master s Thesis: Simo Juvaste May 2019 Abstract: The virtualization of computers has recently become a very important technique in computer science. For example, cloud services are based largely on virtualization, and, it can be said that they have been revolutionizing web services since mid 2000s. Virtualization tools can be divided into two main categories: hypervisor-based and container-based tools. Hypervisors virtualize the whole computer, including their hardware, which can make them relatively heavy and inefficient. Container-based tools virtualize only the operating system, which can also take advantage of the host s resources. This often means that containers are more lightweight and efficient, but less flexible. Because different virtualization tools play such an important part in modern web services, their performance is continuously compared. On the other hand, their usability is compared far less often. In this master s thesis, virtualization is reviewed from different perspectives. Possible benefits and disadvantages of virtualization are listed, along with its uses. Hypervisor- and container-based tools are introduced more closely, and the reader is superficially familiarized with their operating principles and technical implementation. Also, the performance of different tools is reviewed based on literature. Even though containers have historically been more efficient compared to hypervisors, the difference has been narrowing lately. Finally, the results of the writer s performance tests are introduced. It can be seen, that hypervisors have kept getting more efficient, and the differences can already be small. However, overall, containers are still slightly more efficient. Usability is also compared superficially in this thesis. Containers-based tools, especially Docker, have significantly better usability. When choosing the virtualization tool, it is recommended to run use case specific tests. Keywords: virtualization, hypervisor, container, cloud, performance, Docker, KVM, LXC CR Categories (ACM Computing Classification System, 1998 version): C.0, C.4, D.4.8 ii

4 Lyhenneluettelo AWS HTTP KVM LXC NAT TCP UDP Amazon Web Services; pilvipalveluiden tarjoaja HyperText Transfer Protocol; tiedonsiirtoprotokolla verkkoa varten Kernel-based Virtual Machine; hypervisor Linux-käyttöjärjestelmille Linux Containers; konttipohjainen virtualisointityökalu Network Address Translation; tekniikka osoitteenmuutokseen verkossa Transmission Control Protocol; matalan tason tiedonsiirtoprotokolla verkkoa varten User datagram protocol; matalan tason tiedonsiirtoprotokolla verkkoa varten iii

5 Sisällysluettelo 1 Johdanto Virtualisoinnin hyödyt, haitat ja kohteet Virtualisoinnin hyötyjä Kustannusten hallinta Infrastruktuurin hallinta ja ylläpito Automatisointi Tietoturva Virtualisoinnin haittoja Virtualisointi käytännössä Pilvi Ohjelmistokehitys ja -testaus Pelikonsolit Verkot Virtualisointitekniikoista Hypervisor Hypervisor tyypit Hypervisorin toteutus Työkalut ja ohjelmistot Kontit Konttipohjaisen virtualisointityökalun arkkitehtuuri Konttipohjaisen virtualisoinnin tekninen toteutus Muita konttipohjaisia virtualisointityökaluja Virtualisointitekniikoiden aiempia vertailutuloksia Prosessorin suorituskyky Muistin suorituskyky Levyn suorituskyky Verkon suorituskyky Suorituskykymittauksia Prosessorin suorituskyky Muistin suorituskyky Levyn suorituskyky Verkon suorituskyky Verkkopalvelun suorituskyky Käytettävyys Tulosten analyysi Yhteenveto ja pohdinta...88 Viitteet Liitteet Liite 1: Dockerfile Liite 2: app.py

6 1 Johdanto Tietojenkäsittelyssä virtualisointi on tekniikka, jolla erilaisista fyysisistä resursseista luodaan niiden virtuaalisia versioita. Esimerkiksi yksi fyysinen resurssi voidaan virtualisoida useaksi virtuaaliseksi resurssiksi, tai vastaavasti usea fyysinen resurssi yhdeksi, tehokkaammaksi virtuaaliseksi resurssiksi. Virtuaalisille resursseille on ominaista, että ne vaikuttavat normaaleilta fyysisiltä resursseilta sekä itselleen että muille resursseille. Muun muassa muistia, tallennustilaa ja kokonaisia tietokoneita on mahdollista virtualisoida (Carlos et al., 2013). Tietokoneiden virtualisoinnilla tarkoitetaan tekniikkaa, jossa yhdellä fyysisellä koneella ajetaan yhtä tai useampaa virtuaalikonetta (virtual machine). Tämä voi johtaa merkittäviin hyötyihin. Monet fyysiset palvelinkoneet eivät usein tarvitse koko laskentatehoaan, joten jos niillä ajetaan useita virtuaalikoneita, on mahdollista säästää esimerkiksi laitteistokustannuksissa. Lisäksi virtuaalikoneita on usein mahdollista luoda ja poistaa ohjelmallisesti. Tämä on mahdollistanut muun muassa pilvilaskennan räjähdysmäisen kasvun 2000-luvun puolesta välistä lähtien. Tietokoneiden virtualisointi ei sinänsä ole uusi tekniikka. IBM kehitti jo vuonna 1965 M44/44X järjestelmän, joka pystyi simuloimaan usean virtuaalikoneen ajamista samaan aikaan. Vaikka se ei vielä virtualisoinut laitteistoa jokaiselle virtuaalikoneelle, toimi M44/44X pohjana myöhemmälle virtualisoinnin kehitykselle. Vuonna 1967 käyttöönotettu IBM:n CP-40 järjestelmä virtualisoi myös laitteiston virtuaalikoneille. Virtualisointitekniikoita paranneltiin vuosien saatossa seuraavien vuosikymmenien aikana, mutta seuraava suuri läpimurto tapahtui vasta 1990-luvun loppupuolella, kun VMware julkaisi ensimmäisen prosessorin koko x86-käskykanta-arkkitehtuurin virtualisoivan hypervisorin. Hypervisor on ohjelmisto, joka hallinnoi isäntäkoneella ajettavia virtuaalikoneita. Vaikka hypervisor ei tekniikkana ollut uusi, mahdollisti x86-arkkitehtuurin virtualisointi fyysisten prosessorien turvallisen ja verrattain tehokkaan jakamisen useiden virtuaalikoneiden kesken. 1

7 Ensimmäiset x86-arkkitehtuuria virtualisoivat hypervisorit virtualisoivat sitä ohjelmallisesti, joka oli erittäin monimutkaista ja melko raskasta. Vuonna 2006 prosessorien valmistajat, Intel ja AMD, julkaisivat laajennukset x86- käskykantoihinsa, jotka mahdollistivat osittaisesti niiden natiivin virtualisoinnin tukemisen. Tosin vasta myöhemmät, laajemmin virtualisointia tukevat prosessorit, mahdollistavat huomattavat suorituskyvyn parannukset ohjelmistoon perustuvaan virtualisointiin verrattuna luvun alussa kokonaisten tietokoneiden virtualisoinnille kehitettiin myös vaihtoehtoinen, kevyempi tekniikka. Käyttöjärjestelmätason virtualisointi (operating-system-level virtualization) on tekniikka, jossa isäntäkäyttöjärjestelmälle luodaan ohjelmallisesti eristettyjä ympäristöjä, joissa voidaan ajaa vieraskäyttöjärjestelmiä. Tämä voi olla virtuaalikoneisiin verrattuna huomattavan paljon kevyempi tekniikka, sillä esimerkiksi laitteistoa ei tarvitse virtualisoida lainkaan. Toisaalta koska vieraskäyttöjärjestelmät käyttävät isäntäkäyttöjärjestelmän resursseja hyväkseen, voi esimerkiksi Windows-käyttöjärjestelmän ajaminen Linuxpohjaisella käyttöjärjestelmällä olla hankalaa tai mahdotonta. Käyttöjärjestelmätason virtualisointia kutsutaan usein myös konttipohjaiseksi virtualisoinniksi (containerbased virtualization, containerization), ja myös tässä tutkielmassa käytetään tästä lähtien tätä termiä. Esimerkiksi pilvipalveluiden kasvun vuoksi erilaisia virtualisointityökaluja kehitetään ja niitä parannellaan yhä kiihtyvällä tahdilla. Niiden suorituskyvyn tutkimiseen käytetään myös paljon resursseja, sillä se vaikuttaa suoraan esimerkiksi monien pilvessä ajettavien verkkopalveluiden käytettävyyteen. Perinteisesti suorituskykyvertailut ovat päätyneet siihen lopputulokseen, että konttipohjaiset virtualisointityökalut ovat hypervisor-pohjaisia työkaluja suorituskykyisempiä. Toisaalta eritoten viime vuosien aikana monet hypervisorit ovat kuroneet tätä eroa kiinni. Tässä tutkielmassa esitellään ajan tasalla olevat suorituskykytestien tulokset eräillä suosituimmista virtualisointityökaluista. Monet kirjallisuudessa saatavilla olevat suorituskykyvertailut keskittyvät lähinnä korkean suorituskyvyn laskennan (High 2

8 Performance Computing, HPC) suorituskykyä mittaaviin testityökaluihin. Noiden työkalujen lisäksi tässä tutkielmassa on pyritty valitsemaan myös muitakin testityökaluja mahdollisimman monipuolisten tulosten saamiseksi. Lisäksi suurin osa tehdyistä vertailuista keskittyy vain joko prosessorin, muistin, verkon ja levyn I/O:n tai yksittäisten ohjelmistojen suorituskykyihin. Tässä tutkielmassa on ensin mainittujen lisäksi testattu myös oikeaa simuloivan, useasta eri ohjelmistosta koostuvan verkkopalvelun suorituskykyä. Lopuksi, lähes kaikki vertailut jättävät virtualisointityökalujen käytettävyyden korkeintaan maininnan asteelle, vaikka se on todellisuudessa tärkeä osa mitä tahansa työkalua. Vaikka tämäkin tutkielma keskittyy suorituskykyvertailuun, on myös käytettävyyteen kiinnitetty huomiota. Tutkielma koostuu kuudesta luvusta. Luvussa kaksi kerrotaan yleisesti virtualisoinnin mahdollisista hyödyistä ja haitoista sekä käydään läpi joitain virtualisointia hyödyntäviä esimerkkejä. Luvussa kolme esitellään tarkemmin eri virtualisointitekniikoita ja -työkaluja koneiden ja käyttöjärjestelmien virtualisoimiseen, sekä käydään läpi niiden toimintaperiaatteita ja teknistä toteutusta pintapuolisesti. Luvussa neljä esitellään suorituskykyvertailujen aiempia tuloksia kirjallisuuteen perustuen. Luvussa viisi raportoidaan kirjoittajan oman vertailun tulokset sekä suorituskyvyn että käytettävyyden näkökulmista. Lopuksi, luku kuusi on yhteenveto ja pohdinta. 3

9 2 Virtualisoinnin hyödyt, haitat ja kohteet Virtualisoinnille voi olla monia syitä, resurssista ja käyttötapauksesta riippuen. Sen avulla voidaan esimerkiksi pyrkiä laskemaan laitteiston ja ohjelmiston aiheuttamia kustannuksia, saamaan yhteensopimattomat ohjelmistot ja alustat toimimaan toistensa kanssa, parantamaan tietoturvaa ja katastrofeista palautumista, automatisoimaan prosesseja tai jopa pienentämään kasvihuonekaasuja ja käytetyn sähkön määrää. Virtualisoinnilla voidaan saavuttaa monesti huomattaviakin hyötyjä ei-virtualisoituihin ratkaisuihin verrattuna (Burger, 2012). Toisaalta virtualisoinnilla voi olla myös negatiivisia vaikutuksia. Se tekee järjestelmästä luonnostaan monimutkaisemman, koska esimerkiksi laitteistoa voidaan joutua virtualisoimaan. Virheitä voi tapahtua ohjelmiston ja fyysisen laitteiston lisäksi virtualisoidussa laitteistossa tai virtualisoivassa ohjelmistossa, joka voi tehdä niiden löytämisestä ja korjaamisesta vaikeampaa. Lisäksi jos haitallinen ohjelmisto saa virtuaalikonetta ajavan isäntäkoneen haltuunsa, voi se mahdollisesti saada pääsyn myös muille isäntäkoneella ajettaville virtuaalikoneille. Virtuaalikoneet joutuvat myös jakamaan isäntäkoneen laitteiston muiden virtuaalikoneiden kanssa, joka voi vaikuttaa niiden suorituskykyyn. Lienee tunnetuin ja nykyään ehdottomasti merkittävin virtualisoinnin mahdollistama tuote on pilvi. Eritoten viimeisen reilun kymmenen vuoden aikana pilvi on mahdollistanut erilaisten verkkopalveluiden määrän räjähdysmäisen kasvun tekemällä niiden luomisesta, käyttöönotosta ja ylläpitämisestä halvempaa, nopeampaa ja helpompaa. Virtualisointia voidaan käyttää hyväksi myös monella muulla tapaa, kuten pelikonsoleissa ja ohjelmistokehityksessä ja -testauksessa. Tässä luvussa käydään läpi virtualisoinnin tuomia hyötyjä, sen aiheuttamia haittoja ja sitä, mitä voidaan virtualisoida ja miksi. Kohdassa 2.1 eritellään syitä virtualisointiin sekä sen hyötyjä. Kohta 2.2 keskittyy virtualisoinnin aiheuttamiin mahdollisiin haittoihin. Lopuksi, kohdassa 2.3 esitellään käytännön esimerkkejä, joissa hyödynnetään virtualisointia, sekä kerrotaan miten ja miksi nämä esimerkit hyödyntävät virtualisointia. 4

10 2.1 Virtualisoinnin hyötyjä Erilaisten verkkopalveluiden määrä ja suosio on 2000-luvulla kasvanut räjähdysmäisesti. Esimerkiksi Facebookilla on yli 2 miljardia aktiivista käyttäjää maailmanlaajuisesti (Facebook Newsroom, 2019), ja vaikka sen kasvu on viime aikoina hieman tyrehtynyt, saavuttaa jokin uusi verkkopalvelu maailmanlaajuisen suosion lähes viikoittain. Tämä on luonut verkkopalveluiden ylläpitäjille ja kehittäjille uusia haasteita, kun käyttäjien määrän kasvuun tulee voida reagoida nopeasti ja uudenlaisia palveluja tulee saada markkinoille nopeasti kilpailijoiden tuotteita vastaamaan. Monien verkkopalveluiden käyttäjämäärät voivat lisäksi vaihdella riippuen esimerkiksi vuorokauden ajasta. Jos palvelinkoneita tarvitaan tietty määrä palvelemaan käyttäjiä päivän kiireisimpänä aikana, on tämä määrä todennäköisesti tarpeettoman suuri päivän muina aikoina. Tämä voi johtaa ylimääräisiin kustannuksiin jos palvelinkoneet pidetään toiminnassa päivän hiljaisempina aikoina, tai ylimääräiseen manuaalisen työhön, jos niitä sammutetaan ja käynnistetään tarpeen mukaan. Virtualisointi voi auttaa vastaamaan näihin haasteisiin. Sen avulla on mahdollista saada esimerkiksi uusia virtuaalisia palvelimia käyttöön jopa minuuteissa, ja toisaalta sammuttamaan niitä automaattisesti käyttäjämäärän vähentyessä. Lisäksi erilaisia laitteistokokoonpanoja on helpompi testata erilaisia käyttötapauksia varten, kun laitteistoa voidaan virtualisoida sen etukäteen ostamisen sijaan. Virtualisoinnin hyödyt voivat vaihdella hieman käyttötapauksesta riippuen. Eräitä osa-alueita, joissa virtualisoinnista on usein hyötyä ovat esimerkiksi: Kustannusten hallinta Infrastruktuurin hallinta ja ylläpito Automatisointi Tietoturva 5

11 Alakohdissa esitellään näitä hyötyjä tarkemmin ja kerrotaan miten virtualisointi auttaa saavuttamaan ne Kustannusten hallinta Etenkin liiketoiminnan kannalta virtualisoinnin mahdollisesti suurin hyöty on pienemmät laitteistokustannukset. VMwaren (2014) mukaan useimmat eivirtualisoidut palvelinkoneet käyttävät keskimäärin vain noin 12% laskentatehostaan suurimman osan ajasta. Jos käyttämätöntä laskentatehoa voidaan käyttää virtuaalikoneiden ajamiseen, tarvitaan fyysisiä koneita vähemmän. Virtualisointia käyttävät organisaatiot ajoivatkin jo vuonna 2014 keskimäärin 16 virtuaalikonetta samanaikaisesti yhdellä fyysisellä palvelinkoneella (Forrester, 2014). Tämä voi mahdollistaa Dawson & Wolf (2011) mukaan keskimäärin jopa kymmenien prosenttien säästöt laitteistokustannuksissa. Palvelinkeskuksille harvempien palvelinkoneiden ylläpidolla on myös muita hyötyjä kuin pelkkä laitteiston hinta. Palvelinkoneiden ylläpitoon tarvitaan vähemmän henkilöstöä, ne vievät vähemmän lattiatilaa palvelinkeskuksista ja kuluttavat vähemmän energiaa. Esimerkiksi vuonna 2010 palvelinkeskukset olivat vastuussa 1.1% - 1.5% maailmanlaajuisesta sähkönkulutuksesta (Koomey, 2012). Song et al. (2015) mukaan pelkkä palvelinkeskusten jäähdytys oli vastuussa 40% tästä. Pienempi sähkönkulutus johtaa luonnollisesti myös pienempään kasvihuonekaasujen tuottoon, mihin useat valtiolliset toimijat ovat viime vuosina kannustaneet (Burger, 2012). Eritoten pienet ja juuri perustetut yritykset ja organisaatiot voivat hyötyä virtualisoinnista merkittävästi. Niiden ei tarvitse ostaa, asentaa ja konfiguroida kalliita palvelinkoneita eikä palkata henkilöstöä ylläpitämään niitä saadakseen tuotteensa verkkoon, vaan ne voivat ostaa virtuaalikoneita pilvipalveluiden tarjoajilta. Esimerkiksi vuonna 2019 OVH ( tarjoaa yksityisen virtuaalisen palvelimen 3,7 eurolla kuukaudessa. Halvimmatkin fyysiset palvelinkoneet maksavat satoja euroja, jonka lisäksi niille pitää vuokrata tilaa palvelinkeskuksesta. Myös niiden asennus ja ylläpito maksaa. 6

12 Myös ohjelmistojen kehityksessä ja testauksessa voidaan säästää käyttämällä virtuaalikoneita useiden fyysisten koneiden sijaan. Monet ohjelmistot voivat toimia hieman eri tavoin esimerkiksi eri arkkitehtuureilla ja käyttöjärjestelmillä, minkä vuoksi ne on testattava niillä erikseen. Tämän suorittaminen virtuaalikoneella säästää useiden fyysisten koneiden ostamisen tarkoitusta varten. Lisäksi virtuaalikoneet ovat usein nopeampia luoda ja käynnistää kuin fyysiset koneet, mikä mahdollistaa kehittäjien ja testaajien tehokkaamman ajankäytön Infrastruktuurin hallinta ja ylläpito Koska virtualisoituja resursseja voidaan käsitellä abstrakteina kokonaisuuksina, voi virtualisointi johtaa infrastruktuurin yksinkertaisempaan hallintaan ja ylläpitoon. Esimerkiksi perinteisissä palvelinkeskuksissa jokaista palvelinkonetta täytyy käsitellä ja ylläpitää erillisenä resurssina. Jos yksittäinen palvelinkone rikkoutuu, täytyy se korvata uudella, joka pitää asentaa ja konfiguroida manuaalisesti. Tämä voi myös vaikuttaa koneen tarjoamien palveluiden saatavuuteen. Virtualisoidut resurssit ovat puolestaan usein rakennettu niin, etteivät yksittäisten fyysisten osien häiriöt vaikuta kokonaisuuteen. Vaikka yhdellä fyysisellä koneella olisikin ongelmia, voidaan sillä ajettavat virtuaalikoneet yleensä siirtää tarvittaessa toiselle fyysiselle koneelle. Tästä voi seurata suuria hyötyjä sillä VMware (2014) mukaan yhdeksän kymmenestä IT-osastosta käyttää peräti puolet ajastaan rutiininomaisiin hallinnollisiin tehtäviin. Monien virtualisointityökalujen tarjoamat hallintatyökalut voivat myös helpottaa infrastruktuurin ylläpitoa yksinkertaistamalla yksittäisten resurssien hallinnointia. Esimerkiksi uusien resurssin lisääminen ja vanhojen konfigurointi ja poisto voidaan usein tehdä ohjelmallisesti. Monet virtualisointityökalut helpottavat myös virheiden korjaamista ja ennaltaehkäisyä auttamalla infrastruktuurin riskien analysoinnissa ja minimoinnissa. Monia hallintaan liittyviä prosesseja voidaan myös automatisoida, joka voi helpottaa esimerkiksi katastrofeista palautumista (Forrester, 2014). Tästä kerrotaan lisää alakohdassa

13 2.1.3 Automatisointi Prosessien automatisointi on yksi suurimmista virtualisoinnin tuomista hyödyistä. Kuten edellisessä alakohdassa mainittiin, virtuaalisia resursseja voidaan luoda, muokata ja poistaa ohjelmallisesti. Tämän vuoksi infrastruktuurin hallintaa on usein mahdollista automatisoida. Esimerkiksi verkkopalveluiden käytettävyysaikaa voidaan parantaa automatisoiduilla prosesseilla. Monet virtualisointityökalut mahdollistavat virtuaalikoneiden automatisoidun luonnin ja poiston käyttäjän antamien parametrien mukaan. Jos johonkin verkkopalveluun tulee paljon yhtäaikaisia käyttäjiä, voidaan uusia virtuaalisia palvelimia luoda automaattisesti muiden palvelimien työkuormaa helpottamaan ennen kuin kasvaneesta liikenteestä tulee ongelma. Toisaalta käyttäjiä ollessa vähän, resursseja voidaan vähentää jolloin niiden ylläpidosta ei tarvitse maksaa esimerkiksi pilvipalvelua käytettäessä (VMware, 2014; Burger, 2012). Myös katastrofeista palautumista voidaan automatisoida. Virtuaalisten koneiden ja niillä ajettavien ohjelmistojen tila voidaan tallentaa tietyin aikavälein tilannekuvaksi (snapshot). Esimerkiksi isäntä- tai virtuaalikoneella tapahtuvan virheen sattuessa voidaan uusi virtuaalikone luoda automaattisesti, siirtää tilannekuva sille ja jatkaa ohjelmiston ajamista edellisestä tilasta. Tämä prosessi on yleensä verrattain nopea, kun uusien fyysisten koneiden asentaminen voi kestää jopa kymmeniä tunteja. Virtuaalikoneita voidaan myös pitää käynnissä varalla, mikä nopeuttaa palvelun palauttamista vielä entisestään (VMware, 2014). Lisäksi verkkopalvelua ei välttämättä tarvitse ajaa alas esimerkiksi uusien päivitysten ja ohjelmistojen asennuksen ajaksi. Jos palvelua tarjoaa yhtä aikaa usea virtuaalikone, uudet päivitykset voidaan ensin asentaa yhdelle näistä. Jos kaikki menee hyvin, asennetaan päivitys automaattisesti seuraavalle ja niin edelleen kunnes kaikki koneet on päivitetty. Näin palvelu on käytettävissä koko ajan, ja prosessin aikana osa käyttäjistä käyttää vanhaa versiota, osa uutta. VMwaren (2014) teettämän kyselyn mukaan 66% vastaajista raportoi virtualisoinnin vaikuttaneen positiivisesti käytettävyysaikoihin. 8

14 2.1.4 Tietoturva Virtualisointi voi myös parantaa tietoturvaa. Esimerkiksi jos haittaohjelma saastuttaa virtuaalikoneen ja saa sen hallintaansa, ei se välttämättä vaikuta isäntäkoneeseen, koska virtuaalikone on eristetty siitä loogisesti. Jotta haittaohjelma saisi myös isäntäkoneen hallintaansa, on sen karattava (jailbreak) virtualisoidusta ympäristöstä ja saatava haltuunsa muita virtuaalikoneita hallinnoivan virtuaalikoneen tai hypervisorin oikeudet, joka voi olla haastavaa. Lisäksi on kehitetty virtuaalikoneita valvovia automaattisia järjestelmiä jotka analysoivat virtuaalikoneen hypervisorille lähettämiä pyyntöjä ja pyrkivät analysoimaan ovatko ne saastuneet. Jos saastuneet virtuaalikoneet havaitaan näiden järjestelmien tai ylläpitäjien toimesta, ne voidaan asettaa karanteeniin, ja tarvittaessa poistaa (AbdElRahem et al., 2016; Yein Win et al., 2014). Virtuaalikoneiden ylläpitäjien on lisäksi mahdollista tehdä kaikkia virtuaalikoneita koskevia muutoksia. Esimerkiksi edellisessä alakohdassa esitellyn tekniikan avulla uusimmat tietoturvapäivitykset on helppo asentaa kaikille virtuaalikoneille sen sijaan että ne asennettaisiin yksi kerrallaan jopa kymmenille tuhansille palvelinkoneille yhdessä palvelinkeskuksessa. Ylläpitäjät voivat monesti myös asettaa kaikkia virtuaalikoneita koskevia tietoturva-asetuksia, pitää lokia käyttäjistä ja asettaa infrastruktuurin eri osille eri käyttöoikeuksia. Etenkin suuressa infrastruktuurissa näiden keskitetty hallinta voi parantaa tietoturvaa merkittävästi varmistamalla, että kaikkien eri osien tietoturva on ajan tasalla (VMware, 2014; Stuhlmuller, 2013). Myös virtuaaliset verkot voivat parantaa tietoturvaa. Niiden avulla esimerkiksi organisaatiot voivat helposti yhdistää organisaation sisäiset tietokoneet ja muut laitteet toisiinsa paljastamatta niitä verkon ulkopuolisille käyttäjille, vaikka tietokoneet eivät olisi samassa paikassa fyysisesti. Virtuaalisista verkoista kerrotaan lisää kohdassa 2.3 (Stuhlmuller, 2013). 9

15 2.2 Virtualisoinnin haittoja Virtualisoinnin lienee suurin yksittäinen haitta on virtuaalikoneiden heikompi suorituskyky. Virtuaalikoneita ajavat ohjelmistot voivat muun muassa joutua muuntamaan niiden antamia pyyntöjä ajon aikana eri muotoon. Virtuaalikoneet käyttävät laitteistoa aivan kuin olisivat tavallisia fyysisiä koneita, mutta hypervisor voi joutua emuloimaan tai virtualisoimaan joitain laitteiston osia, joita virtuaalikoneet eivät voi käyttää. Tämä voi johtaa huomattavastikin huonompaan suorituskykyyn. Lisäksi, jos yhdellä fyysisellä koneella ajetaan useita virtuaalikoneita, yksittäiselle koneelle varataan yleensä vain rajallinen määrä resursseja. Tämä voi hidastaa niitä eritoten suurten työkuormien aikana. Virtualisoinnin vaikutuksesta suorituskykyyn kerrotaan tarkemmin luvuissa 4 ja 5. Toinen virtualisoinnin huono puoli on virtualisoinnin luontainen monimutkaisuus. Vaikka virtualisoinnin lopputulos voi monesti yksinkertaistaa prosesseja, ovat virtualisoinnin mahdollistavat ohjelmistot ja työkalut erittäin monimutkaisia. Esimerkiksi Linux-käyttöjärjestelmien kerneliin sisäänrakennettu hypervisor Kernelbased Virtual Machine (KVM) sisältää riviä koodia (Bugnion et al., 2017). Toisessa hypervisorissa, Xenissä, on lähes riviä koodia (Xen, 2017). Lisätty monimutkaisuus voi johtaa muun muassa vaikeuksiin mahdollisten ongelmien syiden etsimisessä. Jos virtuaalikoneella esiintyy käyttöjärjestelmään liittyviä ongelmia, voi olla vaikea selvittää johtuuko ongelma itse käyttöjärjestelmästä, virtualisointityökalusta vai isäntäkoneesta. Lisäksi, vaikka virtualisoinnilla voi olla positiivisia vaikutuksia tietoturvan suhteen, ennen kaikkea huonosti konfiguroidut ja ylläpidetyt virtuaalikoneet voivat aiheuttaa myös tietoturvariskejä. Näitä ovat AbdElRahem et al. (2016) mukaan: Isäntäkoneen haltuunotto. Saastutetulla virtuaalikoneella oleva ohjelmisto saa isäntäkoneen haltuunsa jailbreak-tekniikan avulla. Tämä voi myös vaarantaa kaikkien muiden isäntäkoneella ajettavien virtuaalikoneiden tietoturvan. Toisaalta kuten alakohdassa todettiin, tätä vastaan on mahdollista varautua. 10

16 Palvelunestohyökkäys. Pahantahtoinen tai saastutettu virtuaalikone käyttää niin paljon isäntäkoneen resursseja, ettei niitä riitä muille virtuaalikoneille ja niiden suorituskyky kärsii. Tätä voi rajoittaa esimerkiksi säätämällä kaikille virtuaalikoneille rajoitukset miten paljon resursseja ne voivat käyttää. Hyökkäys migraation aikana. Virtuaalikoneet voivat siirtyä fyysiseltä isäntäkoneelta toiselle elinkaarensa aikana. Yleensä migraatio tapahtuu verkon välityksellä, ja pahantahtoisen tahon on mahdollista yrittää saastuttaa virtuaalikone tänä aikana. Siirto onkin tehtävä hyvin suojattujen kommunikaatiokanavien kautta ja jälkeenpäin on pystyttävä varmistamaan, ettei virtuaalikonetta ole muokattu siirron aikana. Hyökkäys isäntäkoneelle. Jos hyökkääjä saa isäntäkoneen haltuunsa, voi hyökkääjän olla mahdollista hallita virtuaalikonetta ja jopa päästä käsiksi virtuaalikoneen sisäiseen dataan. Isäntäkoneet onkin suojattava hyvin ja eristettävä yleisestä verkosta niin, ettei niitä vastaan ole helppo hyökätä. Käyttämättömien virtuaalikoneiden leviäminen. Koska virtuaalikoneita on helppo luoda lisää, on mahdollista, että niitä luodaan paljon esimerkiksi palvelemaan yhtäkkistä nousua verkkoliikenteessä, mutta niitä ei syystä tai toisesta poisteta jälkikäteen. Jos käyttämättömiä virtuaalikoneita kertyy ajan myötä paljon, vievät ne resursseja muilta virtuaalikoneilta, niiden ylläpito maksaa, eikä niiden tietoturva päivityksiä välttämättä pidetä ajan tasalla, joka voi altistaa ne hyökkäyksille. Päivitysten asennus. Vaikka päivitysten asennus on mahdollista suureksi osin automatisoida, on kuitenkin hyvä pitää huolta, että niiden asennus onnistuu. Jos automaattinen päivitysten asennus esimerkiksi epäonnistuu jollekin virtuaalikoneelle, on ylläpitäjän pidettävät huolta, että ne asennetaan tarvittaessa manuaalisesti. Virtuaalikone on myös mahdollista palauttaa aikaisempaan tilaansa, ja jos uudemmassa tilassa oli asennettu päivityksiä, on pidettävä huolta, että ne asennetaan uudestaan. Tämä voi muodostua hankalaksi ylläpitää ennen kaikkea, jos virtuaalikoneita on paljon. Saastuneet virtuaalikonekuvat. Virtuaalikonekuva on tiedosto tai tiedostopaketti, joka sisältää ohjeet siitä, miten virtuaalikone luodaan. Jos hyökkääjä on esimerkiksi luonut paketin, joka sisältää pahantahtoista koodia, 11

17 voi virtuaalikoneen asentaminen olla tietoturvariski. Virtuaalikonetta asennettaessa kuvasta onkin pidettävä huolta, että sen alkuperä on luotettava, sitä ei ole modifioitu ja se on myös hyvä skannata virusten varalta. Virtuaalikone loikka. Virtuaalikone loikassa virtuaalikone pyrkii saamaan toisen virtuaalikoneen suoraan haltuunsa, esimerkiksi hypervisorissa olevan haavoittuvuuden avulla. Virtuaalikoneet tulee eristää toisistaan hyvin tämän ehkäisemiseksi, jonka lisäksi niiden hypervisorille tekemiä pyyntöjä voidaan analysoida mahdollisten hyökkäysten havaitsemiseksi. Vaikka virtualisoinnilla voi olla monia haittapuolia, näitä voidaan usein rajoittaa esimerkiksi virtuaalikoneiden hyvällä konfiguroinnilla ja erilaisilla työkaluilla sekä pitämällä huolta tietoturvasta. Lisäksi monet tässä mainitut riskit eivät sinänsä koske vain virtuaalikoneita, vaan myös fyysisiä koneita. 2.3 Virtualisointi käytännössä Virtualisoinnin suosion kasvun myötä sitä on alettu käyttämään yhä useampaan ja moninaisempaan käyttötarkoitukseen. Kaikkien näiden käyttötarkoitusten listaaminen ei sinänsä ole mielekästä, sillä niitä on lukematon määrä, eikä se ole tämän tutkielman tarkoitus. Tässä kohdassa esitellään kuitenkin joitain tärkeimmistä kohteista. Alakohdissa käydään läpi joitain esimerkkejä, joissa hyödynnetään virtualisointia ja kerrotaan miten sitä hyödynnetään kyseiseen käyttötarkoitukseen Pilvi Pilvi, tai pilvilaskenta, on paradigma, jossa fyysisistä laitteista ja eri ohjelmistoista koostuva kokonaisuus on abstrahoitu pilveen, joka tarjoaa palveluita tarpeen mukaan. Nämä palvelut voivat vaihdella prosessorin kellosykleistä virtuaalikoneisiin ja aina kokonaisiin virtuaalisiin infrastruktuureihin (Wang et al., 2011). Ensimmäinen pilvipalvelu, Amazon Web Servicen (AWS, Elastic Compute Cloud (EC2), julkaistiin vuonna 2006 (AWS, 2006), ja sittemmin esimerkiksi Google ( IBM ( 12

18 ja Microsoft ( ovat myös julkaisseet omat pilvipalvelunsa. Pilvipalveluiden käyttö ja niiden arvo ovat kasvaneet nopeaa vauhtia: Gantz (2016) arvion mukaan pilveen tullaan käyttämään maailmanlaajuisesti 162 miljardia Yhdysvaltain dollaria vuonna Pilven tärkeimmät palvelut ovat Software as a Service (SaaS), Platfom as a Service (PaaS), Infrastructuce as a Service (IaaS) ja Function as a Service (FaaS). SaaS, eli ohjelmisto palveluna, tarkoittaa yksinkertaisesti ohjelmistoa joka tarjotaan pilvestä, ja jota voi käyttää esimerkiksi selaimen tai muun asiakasohjelmiston avulla. Tarjoamalla ohjelmistonsa palveluina yritykset voivat virtaviivaistaa toimitus- ja ylläpitoprosessejaan koska niiden ei tarvitse huolehtia esimerkiksi alustojen ja infrastruktuurin ylläpidosta, kaikki asiakkaat käyttävät automaattisesti ohjelmiston uusinta versiota asentamatta mitään omille koneilleen. Esimerkki SaaSista on selainpohjaiset sähköpostiohjelmistot kuten Gmail ( (Singh et al., 2015). PaaS, eli alusta palveluna, tarkoittaa että alusta jolla esimerkiksi SaaS ohjelmistoa ajetaan, tarjotaan palveluna. Käytännössä tämä tarkoittaa yleensä virtuaalikonetta. PaaSin käyttäjä voi yleensä hallita kolmannen osapuolen ohjelmistoja ja kirjastoja joita alustalla on asennettuna. Jotkin PaaS tarjoajat, kuten Microsoft Azure, tarjoavat myös sisäänrakennettuja työkaluja joiden avulla SaaS ohjelmistoja voidaan kehittää ja ylläpitää. PaaS voi myös tarkoittaa esimerkiksi tietokannan tai tietoverkon tarjoamista palveluna (Benedict, 2013; Microsoft Azure, PaaS, 2017). IaaS, infrastruktuuri palveluna, tarkoittaa nimensä mukaisesti koko infrastruktuurin tarjoamista palveluna. Käytännössä tämä voi tarkoittaa virtuaalikoneista ja -verkoista, tietokannoista ynnä muista resursseista koostuvia kokonaisuuksia sekä niiden hallintatyökaluja. IaaS antaa käyttäjälle enemmän vapautta ja valtaa valita muun muassa haluamansa käyttöjärjestelmän ja muut käytettävät komponentit. IaaSia käyttävien yritysten ei tarvitse investoida fyysiseen laitteistoon ja sen ylläpitoon. Tämä voi tuoda huomattaviakin säästöjä, kuten aikaisemmin on mainittu. Esimerkiksi Microsoft Azure ja AWS tarjoavat IaaS ratkaisuja (Singh et al., 2015; Microsoft Azure, IaaS, 2017) 13

19 Hiljattain kehitetty FaaS, eli funktio tai toiminnallisuus palveluna, on tarkoitettu yksittäisten toimintojen kertaluontoiseen ajamiseen pilvessä. FaaSin käyttöä kutsutaan joskus myös palvelittomaksi ohjelmoinniksi (serverless programming), ja sen pääasiallinen ero esimerkiksi SaaSiin verrattuna on se, että pilvessä ei ole prosessia, joka pitää FaaS funktiota ajossa koko ajan, vaan se luodaan vasta pyynnöstä. Suosittu käyttökohde FaaSille onkin epäsäännöllinen mutta intensiivinen tietojenkäsittely. Castro et al. (2017) mainitsee esimerkkinä kuvankäsittelynpalvelun, jossa kuvan lataaminen pilveen aiheuttaa kutsun FaaS-funktiolle, joka automaattisesti luo ja tallentaa kuvasta pienemmän version. AWS:n Lambda ( Google Cloud Function ( ja Microsoft Azure Functions ( ovat esimerkkejä FaaSeista Ohjelmistokehitys ja -testaus Ohjelmistojen kehittäminen ja testaaminen eri alustoilla toimivaksi voi nykypäivänä olla haastavaa monien erilaisten tietokone-ekosysteemien takia. Käyttöjärjestelmiä on monia erilaisia, muun muassa Windows, macos sekä sadat Linux- ja Unixpohjaiset käyttöjärjestelmät (operating-system.org, 2009). Lisäksi näillä voi olla eri versioita ja erilaisia laitteistokonfiguraatioita on käytännössä lukematon määrä. Ohjelmiston testaaminen voi kuitenkin olla haastavaa jo muutamalla tärkeimmällä ekosysteemillä, sillä niistä jokaiselle pitää olla oma koneensa, jolle pitää asentaa testiympäristö, ajaa testit ja mahdollisesti korjata ympäristö, jos jotain menee pieleen testauksen aikana (Dueñas et al., 2009). Virtuaalikoneiden avulla kehittäjät voivat ajaa erilaisia konfiguraatioita omilla koneillaan ja testata uusinta koodia niillä. Tämän lisäksi testaajien on esimerkiksi mahdollista automatisoida ohjelmistojen testaamista erilaisilla virtuaalikoneilla. Tämä voi tehdä kehitys- ja testausprosessista helpompaa, halvempaa ja nopeampaa (Dueñas et al., 2009). 14

20 2.3.3 Pelikonsolit Ensimmäisten sukupolvien pelikonsoleilla oli vain yksi käyttötarkoitus: pelaaminen. Tämän vuoksi konsoleiden kehittäjien ei tarvinnut huolehtia miten samalla koneella suoritettavat eri ohjelmat esimerkiksi käyttävät laitteiston resursseja. Pelikonsoleiden vaatimukset kuitenkin muuttuivat luvun puolessa välissä julkaistujen Sonyn Playstation 3:n ja Microsoftin Xbox 360:n kohdalla, kun niistä rakennettiin monipuolisia multimedia-alustoja, joiden piti muun muassa pystyä tukemaan pysyvää tiedontallennusta ja verkkoon liitettävyyttä. Toisaalta pelikehittäjät olivat tottuneet siihen, että peli saa koko alustan rajoittamattomaan käyttöönsä. Lisäksi ilman käyttöjärjestelmää pelin voitiin taata toimivan koko konsolin käyttöiän ajan, toisin kuin esimerkiksi tietokonepelien kohdalla, jotka saattavat vaatia päivityksen toimiakseen käyttöjärjestelmän uuden version kanssa. Uusien vaatimusten lisäksi konsolien kehittäjät halusivat pitää myös nämä ominaisuudet (Douglis & Krieger, 2013). Nämä ongelmat ratkaistiin hypervisorin avulla. IBM ja Sony kehittivät Playstation 3:lle Cell mikroprosessori-mikroarkkitehtuurin, jonka avulla pelejä voitiin ajaa suoraan virtualisoidulla laitteistolla ilman käyttöjärjestelmää. Lisäksi laitteiston muut osat ja resurssit olivat suojassa esimerkiksi huonosti toteutetulta peliltä. Myös nykyiset pelikonsolit käyttävät samaa lähestymistapaa. Esimerkiksi Microsoftin kahdeksannen sukupolven Xbox One -konsoli ajaa Microsoftin omaa Hyper-V -hypervisoria, jonka päällä ajetaan kahta käyttöjärjestelmää; Xbox OS:ää pelejä varten ja Windows-pohjaista käyttöjärjestelmää muita ohjelmistoja varten (Douglis & Krieger, 2013; Anthony, 2013) Verkot Virtuaalisten verkkojen perusperiaate on sama kuin virtuaalikoneiden: fyysinen toteutus erotetaan loogisesta palvelusta ohjelmiston ja laitteiston avulla. Verkkojen virtualisoinnista voi olla monia hyötyjä. Sen avulla voidaan esimerkiksi testata uusia verkkoarkkitehtuureja, joka voi muuten olla erittäin hankalaa verkon hajautetun 15

21 luonteen vuoksi (Anderson et al., 2005). Lisäksi virtuaalisilla verkoilla voidaan parantaa tietoturvaa, skaalautuvuutta, ylläpitoa ja eristyneisyyttä. Käytännön esimerkkejä virtualisoiduista verkoista ovat virtuaalilähiverkot (Virtual Local Area Network, VLAN), virtuaaliset erillisverkot (Virtual Private Network, VPN) ja päällekkäisverkot. VLANit ovat virtuaalisesti luotuja lähiverkkoja, joiden avulla laajemman verkon voi jakaa osiin riippumatta laitteiston fyysisestä sijainnista. Edellä mainittujen etujen lisäksi virtuaalisia verkkoja voi olla helpompi ylläpitää (Chowdhury & Boutaba, 2009). Monet pilvipalveluiden ylläpitäjistä käyttävät VLANeja eristäessään eri käyttäjien verkot toisistaan palvelinkeskuksissaan (Hu et al., 2014). VPN on verkko, joka yhdistää verkon eri osia luottamuksellisesti toisiinsa niiden fyysisestä sijainnista riippumatta. Tämä tapahtuu yleensä luomalla salattuja tunneleita yleisen verkon yli. Esimerkiksi organisaatiot voivat luoda organisaation sisäisiä VPN:iä, joihin vain niiden jäsenillä on pääsy, ja näin mahdollistaa muun muassa jäsenten välinen resurssien jakaminen luottamuksellisesti jäsenten sijainnista riippumatta (Chowdhury & Boutaba, 2009). Lisäksi VPN-palveluiden, kuten TunnelBearin ( avulla voidaan esimerkiksi kiertää valtioiden tai palveluiden asettamia sijaintiin perustuvia rajoituksia, sillä ne voivat reitittää käyttäjien verkkopyyntöjä tulemaan eri puolelta maailmaa. Päällekkäisverkot ovat nimensä mukaisesti verkon päälle rakennettuja loogisia verkkoja. Esimerkiksi Internet oli alkujaan puhelinverkon päälle rakennettu päällekkäisverkko. Päällekkäisverkot eivät vaikuta verkkoon, jonka päälle ne on rakennettu, jonka vuoksi niitä voidaan käyttää muun muassa uuden toiminnallisuuden mahdollistamiseen ja testaamiseen, tietoturvan ja palvelunlaadun parantamiseen sekä muun muassa tiedostojen jakamiseen (Anderson et al., 2005; Chowdhury & Boutaba, 2009). Myös esimerkiksi vertaisverkot (peer-to-peer network, P2P) ovat päällekkäisverkkoja. 16

22 3 Virtualisointitekniikoista Kuten johdannossa kerrottiin, virtualisointitekniikat voidaan jakaa karkeasti kahteen eri pääryhmään: hypervisor-pohjaisiin ja konttipohjaisiin tekniikoihin. Hypervisorpohjaisissa tekniikoissa ohjelmisto nimeltä hypervisor luo ja ylläpitää virtuaalikoneita, sekä esimerkiksi hallitsee niiden käytössä olevan laitteiston ja muiden resurssien käyttöä. Hypervisorin luomat virtuaalikoneet vaativat toimiakseen kokonaisen käyttöjärjestelmän ja virtualisoidun laitteiston, joka voi tehdä niistä melko raskaita ja resurssi-intensiivisiä. Konttipohjaisen virtualisoinnin luomia kontteja voidaan puolestaan ajaa suoraan käyttöjärjestelmän päällä ja ne voivat käyttää niitä ajavan käyttöjärjestelmän resursseja hyväkseen, jonka vuoksi ne voivat olla huomattavasti hypervisor-pohjaisia virtuaalikoneita kevyempiä. Toisaalta koska ne käyttävät esimerkiksi isäntäkäyttöjärjestelmänsä kerneliä, täytyy isäntäkoneen ja konttien käyttöjärjestelmien käyttää samaa kernel-arkkitehtuuria. (Morabito et al., 2015; Ramalho & Neto, 2016; Li et al., 2017). Hypervisor- ja kontti-tekniikoiden erojen vuoksi niitä käytetään yleensä hieman eri tarkoituksiin. Esimerkiksi pilvipalveluiden IaaS toteutetaan monesti hypervisoreiden avulla, kun taas PaaS voi olla luontevampaa toteuttaa konttien avulla (Ramalho & Neto, 2016). Toisaalta Felter et al. (2015) huomauttaa ettei esimerkiksi IaaSin toteuttamiselle konttien avulla sinänsä ole mitään teknistä estettä, ja voi joissain tapauksissa jopa johtaa parempaan suorituskykyyn ja helpompaan toteutukseen. Viime vuosina on lisäksi kehitetty virtualisointitekniikoita, joita ei voi suoraan jakaa hypervisor- tai kontti-pohjaisiin. Morabito et al. (2015) mainitsee esimerkiksi OSv:n ja ZeroVM:n. OSv ( on puhtaasti pilvipalveluille tarkoitettu käyttöjärjestelmä, jota ajetaan hypervisorin päällä. Se on suunniteltu ajamaan vain yhtä sovellusta kerrallaan, joka tekee siitä täysimittaista käyttöjärjestelmää kevyemmän ja nopeamman, mutta toisaalta myös rajoittuneemman. ZeroVM ( menee vielä askeleen pidemmälle, luomalla vain eristetyn ympäristön, jossa voidaan ajaa yhtä sovellusta. Esimerkiksi dataa käsittelevä ohjelmisto voidaan siirtää ympäristönsä kera tietokantaa ajavalle koneelle tekemään 17

23 työnsä sen sijaan että mahdollisesti suuret tietomäärät ladattaisiin toiselle koneelle käsiteltäväksi. Nämä tekniikat ovat kuitenkin yleisesti ottaen vielä lapsenkengissä, eikä niitä ole tarkoitettu täysimittaiseen laitteiston tai käyttöjärjestelmän virtualisointiin. Näitä tekniikoita ei tässä tutkielmassa esitellä tämän tarkemmin, mutta ne mainittiin demonstroimaan sitä, että virtualisointitekniikat kehittyvät jatkuvasti ja uusia työkaluja kehitetään ratkaisemaan olemassa olevien tekniikoiden ja työkalujen puutteita ja heikkouksia. Tässä luvussa kerrotaan miten virtualisointitekniikat käytännössä toimivat ja käydään pintapuolisesti läpi, miten ne toteutetaan, sekä esitellään tärkeimpiä käytännön työkaluja ja ohjelmistoja, joilla voi luoda virtuaalikoneita tai kontteja näitä tekniikoita hyväksikäyttäen. Kohdassa 3.1 kerrotaan hypervisorista ja kohdassa 3.2 konteista. 3.1 Hypervisor Kuten aiemmin todettiin, hypervisor on ohjelmisto, joka hallinnoi virtuaalikoneita läpi niiden elinkaaren. Se eristää jokaisen ylläpitämänsä virtuaalikoneen sekä isäntäjärjestelmästä että muista virtuaalikoneista, ja hallinnoi niiden välisiä vuorovaikutuksia. Hypervisor nimi on sanaleikki englannin kielen sanasta supervisor (valvoja). Supervisor on käyttöjärjestelmän osa, joka hallinnoi käyttöjärjestelmällä ajettavia ohjelmia, ja hyper on sanan super vahvempi muoto, joten virtuaalikoneita hallinnoiva ohjelmisto on siis hypervisor. Hypervisoria kutsutaankin joskus myös virtuaalikoneiden valvojaksi (virtual machine monitor, VMM). Hypervisor-termin alkuperästä ei ole täyttä varmuutta, mutta sitä käytetiin ensimmäisen kerran mahdollisesti jo 1960-luvun lopulla (Golden, 2008; StackExchange Software Engineer, 2013). Prosessoreiden x86-arkkitehtuurissa järjestelmän turvallisuus taataan neljällä eri käyttöoikeustasolla (privilege level, ring). Käyttöjärjestelmää ajetaan alimmalla, eli 0-tasolla, jolla ajettavilla prosesseilla on oikeus tehdä järjestelmäkutsuja ja käyttää laitteistoa rajoittamattomasti. Käyttäjän sovelluksia taas ajetaan tasolla 3, eivätkä ne voi tehdä mahdollisesti vaarallisia, niin sanottuja etuoikeutettuja kutsuja (privileged 18

24 call), kuten suojatun muistin lukua ja kirjoitusta tai I/O:n käyttöä. Tämä hierarkia voi kuitenkin olla ongelmallista virtuaalikoneiden kohdalla, sillä niitä ajetaan tasolla 3 mutta niiden käyttöjärjestelmät luulevat, että niillä on 0-tason oikeudet (RedHat, 2009). Ensimmäiset hypervisorit, pyrkivät ratkaisemaan tämän ongelman emuloimalla laitteistoa ohjelmallisesti. Laitteiston emulointi on kuitenkin erittäin resurssiintensiivistä, joka voi johtaa huonoon suorituskykyyn. Myöhemmin VMwaren kehittämässä tekniikassa laitteistoa ei emuloida, vaan hypervisor ottaa kiinni virtuaalikoneiden käyttöjärjestelmien tekemät etuoikeutetut kutsut, kääntää ne ja suorittaa ne turvallisesti. Tätä kutsutaan täydeksi virtualisoinniksi (full virtualization). Suorituskyvyn parantamiseksi VMware kehitti myös tekniikan nimeltä binäärikäännös (binary translation), jossa hypervisor lukee virtuaalikoneiden muistia, tunnistaa mahdollisesti tehtävät etuoikeutetut kutsut, suorittaa ne turvallisesti ja kirjoittaa tulokset virtuaalikoneiden muistiin ennen kuin niitä on edes tarve suorittaa. Tämä tapahtuu virtuaalikoneen käyttöjärjestelmän tietämättä, joten sitä ei tarvitse modifioida tukemaan tekniikkaa, eikä se ole tietoinen siitä, että sitä ajetaan virtuaalikoneella (Walters et al.; 2008, RedHat, 2009; Jones, 2011). Kutsujen kiinniottaminen tai tunnistaminen ja turvallinen suorittaminen voi kuitenkin huonontaa virtuaalikoneiden suorituskykyä, ja voi käännettävien kutsujen ruuhkautuessa vaikuttaa jokaisen samalla isäntäkoneella ajettavan virtuaalikoneen käytettävyyteen. Paremman suorituskyvyn toivossa Xen kehitti tekniikan nimeltä paravirtualisointi (paravirtualization), jossa virtuaalikoneella ajettavaa käyttöjärjestelmää muokataan tekemään yhteistyötä hypervisorin kanssa. Vieraskäyttöjärjestelmiä ajetaan vähän käytetyllä käyttöoikeustasolla 1, joka antaa niille laajemmat oikeudet tasolla 3 ajettaviin normaaleihin sovelluksiin verrattuna. Kun muokatun käyttöjärjestelmän pitää tehdä potentiaalisesti vaarallinen kutsu, tekee se kutsun tietoisesti suoraan hypervisorille tai tarkoitusta varten luodulle virtuaalikoneelle, joka voi suorittaa sen turvallisesti virtuaalikoneen puolesta. Näin hypervisorin ei tarvitse lukea virtuaalikoneiden muistia tai ottaa kiinni ja kääntää kutsuja reaaliajassa. Tämä voi parantaa suorituskykyä huomattavasti. Toisaalta ajettavan käyttöjärjestelmän lähdekoodia on muutettava tukemaan tätä tekniikkaa, 19

25 joka voi olla työlästä tai jopa mahdotonta suljetun lähdekoodin käyttöjärjestelmille elleivät niitä kehittävät tahot tee sitä itse (Barham et al., 2003; Walters et al. 2008; RedHat, 2009). Ensimmäisten hypervisoreiden suurimmat ongelmat olivat niiden huono suorituskyky ja monimutkaisuus, jotka johtuivat pitkälti siitä, ettei laitteisto tukenut virtualisointia luvun puolessavälissä sekä AMD että Intel julkaisivat virtualisointia tukevat laajennukset prosessoriensa x86-arkkitehtuureihin. Laajennusten avulla hypervisor pystyy pyytämään, että prosessori suorittaa tietyt käskyt niin sanotussa vierastilassa. Prosessori ottaa kiinni vierastilassa ajettavien käyttöjärjestelmien tekemät etuoikeutetut kutsut ja välittää ne hypervisorille, joka voi suorittaa ne turvallisesti. Vaikka ensimmäiset versiot laitteiston tukemasta virtualisoinnista eivät tuoneet merkittäviä parannuksia suorituskykyyn, tekivät ne hypervisoreista huomattavasti vähemmän monimutkaisia toteuttaa, koska niiden ei enää tarvinnut valvoa vieraskäyttöjärjestelmien tekemiä etuoikeutettuja kutsuja. Laitteiston tukea virtualisoinnille on kuitenkin kehitetty, ja kehitetään yhä, parantaen virtualisointityökalujen suorituskykyä ja vähentäen niiden monimutkaisuutta entisestään (RedHat, 2009). Alakohdassa kerrotaan hypervisorin eri tyypeistä. Alakohdassa käydään läpi, miten hypervisor voidaan toteuttaa käytännössä pintaa syvemmältä. Alakohdassa esitellään tärkeimpiä hypervisorin toteuttavia työkaluja ja ohjelmistoja Hypervisor tyypit Hypervisorit voidaan jakaa tyyppeihin yksi ja kaksi, jotka Goldberg määritteli jo vuonna 1973 väitöskirjassaan Architectural principles for virtual computer systems. Tyypin yksi hypervisor (niin sanottu bare metal hypervisor), asennetaan suoraan laitteiston päälle, kun taas tyypin kaksi hypervisor (niin sanottu isännöity eli hosted hypervisor) puolestaan asennetaan isäntäkoneella olevan käyttöjärjestelmän päälle. Käytännössä tyypin yksi hypervisor on siis ohut ohjelmistokerros, joka hallitsee sille asennettuja virtuaalikoneita ja tarjoaa niille laitteiston rajapinnat. 20

26 Tyypin kaksi hypervisorin avulla virtuaalikoneita voidaan taasen ajaa kuin tavallisia sovelluksia (Li et al., 2017; Ramalho & Neto, 2016). Tyypin yksi hypervisorin rakenne esitetään kuvassa 1 ja tyypin kaksi hypervisorin rakenne kuvassa 2. Kuva 1. Tyypin 1 hypervisor. 21

27 Käytännössä tyyppien määritelmät ovat kuitenkin joustavia hypervisorin arkkitehtuurin vaateiden mukaan. Esimerkiksi jotkin tyypin yksi paravirtualisoivat hypervisorit, kuten Xen, vaativat toimiakseen erikoisvirtuaalikoneen tai -ympäristön, domain 0:n (dom0). Dom0:lla on suora yhteys laitteistoon ja sen sijaan että muut, tavalliset, virtuaalikoneet olisivat yhteydessä suoraan hypervisoriin, ne tekevät laitteistoa tarvitsevat kutsunsa dom0:lle, joka puolestaan välittää ne hypervisorille. Dom0 tarjoaa myös esimerkiksi työkaluja muiden virtuaalikoneiden hallintaa varten (Xen Dom0, 2015). Tyyppien yksi ja kaksi erot hämärtyvät yhä enemmän KVM:n kohdalla. KVM on Linux-käyttöjärjestelmien kerneliin rakennettu moduuli, joka muuttaa kernelin hypervisoriksi. KVM on sinänsä tyypin yksi hypervisor, koska se periaatteessa muuntaa isäntäkoneen kernelin tyypin yksi hypervisoriksi, mutta itse virtuaalikoneet ja jopa virtualisoidut prosessorit ovat käyttöjärjestelmällä suoritettavia Linuxprosesseja, joka on taas ominaista tyypin kaksi hypervisoreille. KVM liitettiin osaksi Linuxin kerneliä versiossa vuonna 2007 (RedHat, 2009; Ramalho & Neto, 2017). 22

28 Koska KVM:n luomat virtuaalikoneet ovat Linux-prosesseja, voi se käyttää Linuxin kernelin muita moduuleja, kuten muistinhallintaa, laiteajureita, I/O:ta ja turvamekanismeja hyväkseen valvoessaan virtuaalikoneita. Kuva 3. esittää KVM:n rakennetta. Siitä näkee, että KVM on vain yksi moduuli muiden joukossa, ja sen ylläpitämät virtuaalikoneet ovat vain tavallisia prosesseja. RedHat (2009) toteaakin hypervisorin ja käyttöjärjestelmän tehtävien olevan pohjimmiltaan melko samanlaisia: Hypervisor on oikeastaan erikoistunut käyttöjärjestelmä joka ajaa virtuaalikoneita sovellusten sijaan. (RedHat, 2009). KVM:n osalta on myös huomautettava, ettei se sinänsä suorita laitteiston virtualisointia, vaan se vain mahdollistaa prosessorin virtualisointia tukevien laajennusten käytön. Itse laitteiston virtualisointiin KVM käyttää QEMUa (Quick Emulator, QEMU on avoimen lähdekoodin emulaattori, joka pystyy myös virtualisoimaan laitteistoa yhteistyössä KVM:n tai Xenin kanssa. (KVM FAQ, 2019) Hypervisorin toteutus Tässä alakohdassa tarkastellaan miten hypervisor voidaan toteuttaa teknisesti. Xeniä käytetään paljon esimerkkinä, sillä se on yksi vanhimmista ja laajimmin käytetyistä hypervisoreista. Xen on tyypin yksi hypervisor, ja kuten kohdan johdannossa todettiin, se keskittyy suurimmaksi osaksi paravirtualisointiin. Lisäksi sen lähdekoodi on avoin, joka tekee siitä hyvän tutkimuskohteen. Monet arkkitehtuuriset ja tekniset yksityiskohdat ja ratkaisut voivat kuitenkin olla yleistettävissä myös muihin hypervisoreihin. Teknisten ratkaisuiden tarkastelu jätetään kuitenkin tarkoituksella melko pintapuoliseksi, sillä niiden syvällisempi tarkastelu vaatisi myös käyttöjärjestelmien teknisen toteutuksen syvempää tarkastelua, joka ei kuulu tämän tutkielman piiriin (Xen Project Software Overview, 2018). Hypervisorin tulee toteuttaa ainakin seuraavat osat: muistinhallinnan (memory management unit, MMU), prosessorin ja laitteiden I/O:n virtualisointi. Hyvin pelkistetysti, käyttöjärjestelmien muistinhallinta huolehtii siitä, miten sovelluksille 23

29 näkyvä virtuaalisen muistin osoitteet käännetään fyysisen muistin osoitteiksi ja päinvastoin. Muistinhallinnan virtualisointi on monesti hyvin monimutkaista toteuttaa, sillä sen on oltava suorituskykyinen, jonka lisäksi sen on myös eristettävä virtuaalikoneet toisistaan ja hypervisorista. Lisäksi käyttöjärjestelmät odottavat voivansa lukea ja kirjoittaa muistia suoraan, mutta virtualisoidussa ympäristössä vain hypervisorilla on siihen suora pääsy (Hur, 2017; Barham et al., 2003; Alkassar et al., 2010). x86-arkkitehtuurissa virtuaalisen muistin osoitteiden käännökset fyysisen muistin osoitteisiin sivutetaan tietorakenteisiin nimeltä Page Tables (PT). Täyden virtualisoinnin toteuttavat ratkaisut käyttävät monesti, hyvin yksinkertaistetusti, tekniikkaa nimeltä Shadow Page Tables (SPT), jotka ovat virtualisoituja versioita varsinaisista PT:stä. Ne ylläpitävät tilaa, missä virtuaalikoneet luulevat virtuaalisen muistin olevan, ja estävät niitä käyttämästä muistia, johon niillä ei pitäisi olla pääsyä (Barham et al., 2003; VMware, 2005; Alkassar et al., 2010). Xen toteuttaa muistin hallinnan virtualisoinnin hieman eri tavalla. Virtuaalikoneilla on suora lukuoikeus niille tarkoitettuun fyysiseen muistiin ja ne voivat tarvittaessa myös luoda uusia sivua muistissa. Muistin kirjoittaminen on tosin rajoitettua ja hoidettava hypervisorin kautta, joka varmistaa, että muistia päivittävällä virtuaalikoneella oikeus siihen. Xenin mukaan tämä lähestymistapa yksinkertaistaa muistinhallintaa ja parantaa sen suorituskykyä (Barham et al. 2003; Xen X86 Paravirtualised Memory Management, 2015). Muistinhallintaa on mahdollista virtualisoida myös virtualisointia natiivisti tukevien prosessoreiden avulla. AMD:n käyttämä tekniikka on nimeltään Rapid Virtualization Indexing (RVI), tai Nested Page Tables (NPT), ja Intelin tekniikkaa kutsutaan nimeltä Extended Page Tables (EPT). Käytännössä, joskin jälleen yksinkertaistetusti, nämä tekniikat tekevät laitteiston avulla sen mitä SPT tekee ohjelmallisesti. Muistinhallinnan natiivi virtualisointi laitteiston avulla voi olla huomattavasti suorituskykyisempää ohjelmistopohjaiseen virtualisointiin verrattuna (Bhatia, 2008; Bhatia, 2009). 24

30 Prosessoreiden virtualisointitekniikoita esiteltiin jo tämän kohdan johdannossa. Eri ratkaisut käyttävät hyväkseen kutsujen kiinniottamista, eri käyttöoikeustasoja ja mahdollisesti prosessoreiden tarjoamaa natiivia tuke virtualisoinnille. Jos hypervisor ajaa useita virtuaalikoneita, jotka yrittävät käyttää isäntäkoneen prosessoreita samaan aikaan, hypervisor voi antaa niille siivuja prosessoreiden ajasta. Näin prosessorien laskentateho jaetaan tasaisesti eri virtuaalikoneiden kesken, ja virtuaalikoneet voivat luulla, että niillä on käytössään niin monta prosessoria kuin ne on konfiguroitu käyttämään (VMware vsphere 4, 2018). Laitteiden I/O:ta virtualisoidessa, tärkeimmät laitteet lienevät levy- ja verkkolaitteet. Täyden virtualisoinnin toteuttavat hypervisorit virtualisoivat I/O:ta monesti emuloimalla haluttua laitetta. Toisaalta esimerkiksi Xen abstrahoi I/O-laitteet kokonaan. Virtuaalikoneiden tehdessä I/O-kutsuja, ne käyttävät niille asennettuja laiteajureita (front-end driver), jotka välittävät kutsut dom0:lla sijaitseville laiteajureille (back-end driver). Dom0 on välittää sitten kutsut fyysisille laitteille ja palauttaa vastaukset virtuaalikoneille. Kaikki I/O-kutsut dom0:n ja muiden virtuaalikoneiden välillä kulkevat muistissa olevien puskureiden kautta, joissa kutsut voidaan muun muassa validoida (Barham et al., 2003; Park et al., 2015; Xen Paravirtualization, 2015). Xenissä vain dom0:lla on oikeudet lukea ja kirjoittaa levyä suoraan. Virtuaalikoneiden kirjoittaessa dataa, se siirretään puskureiden kautta dom0:lle. Puskurissa kutsut pyritään järjestämään tärkeysjärjestykseen suorittamalla esimerkiksi datan kirjoitus ennen spekulatiivista datan lukua. Kutsun siirtyessä dom0:lle, se esimerkiksi tarkistaa, että virtuaalikoneella on lupa suorittaa kutsu, tarkistaa halutun osoitteen levyllä ja suorittaa kutsun. Kutsun tulokset siirretään sitten takaisin virtuaalikoneelle (Barham et al., 2003; Park et al., 2015; Xen Paravirtualization, 2015). Verkkolaitteiden virtualisointi toimii Xenissä hyvin samalla tavalla kuin levyn virtualisointi. Virtuaalikoneilla oleva laiteajuri näyttää virtuaalikoneelle tavalliselta Ethernet-rajapinnalta, ja se on yhteydessä dom0:lla olevaan ajuriin jo mainitun I/Opuskurin kautta. Dom0 voi tarvittaessa myös luoda sääntöjä esimerkiksi datan 25

31 siirtoon puskurilla ja toimia palomuurina (Barham et al., 2003; Xen Networking, 2018) Työkalut ja ohjelmistot Erilaisia hypervisorin toteuttavia ohjelmistoja on suuri määrä. Ne vaihtelevat ilmaisista vapaaseen lähdekoodin perustuvista vain virtualisoinnin toteuttavista ratkaisuista, aina kalliisiin ja massiivisiin alustoihin, jotka tarjoavat myös esimerkiksi pitkälle kehitettyä virtuaalikoneiden hallintaa, automatisointia ja tarvittaessa tiettyjen ominaisuuksien räätälöintiä. Lisäksi eri hypervisorit voivat keskittyä tiettyjen ominaisuuksien optimointiin haluttuja käyttötapauksia varten. Tässä alakohdassa esitellään päällisin puolin joitakin tärkeimpiä hypervisoreita. Tämä lista ei ole missään tietyssä järjestyksessä eikä missään nimessä tyhjentävä. VMwaren ESXi ( on tyypin yksi, täyden virtualisoinnin toteuttava hypervisor. Se on yksi vanhimmista hypervisoreista ja ylivoimaisesti eniten käytetty markkinaosuuden perusteella (Tsai, 2016; Smart Profile, 2017). ESXi on pääasiallisesti tarkoitettu suurehkoille yrityksille ja VMware on kehittänyt paljon työkaluja sen tueksi, esimerkiksi virtuaalikoneiden hallintaa varten. Se voi toisaalta olla erittäin hinnakas ennen kaikkea, jos haluaa käyttää myös sitä tukevia työkaluja, mutta ESXistä on olemassa myös ilmainen versio vain virtuaalikoneiden perustarpeita varten. VMwaren tyypin kaksi hypervisor on nimeltään VMware Workstation Pro ( Workstation Pro on tarkoitettu useiden isännöityjen käyttöjärjestelmien ajamiseen samalla tietokoneella muun muassa ohjelmiston testausta varten, eikä esimerkiksi palvelinkoneille ajamaan useita virtuaalikoneita samaan aikaan. Workstation Pro on Linux- ja Windowspohjaisille käyttöjärjestelmille, mutta siitä on myös Mac-käyttöjärjestelmille tehty versio, VMware Fusion. Workstation Prosta on myös ilmainen mutta yksinkertaisempi versio, Workstation Player, jolla pystyy ajamaan vain yhtä isännöityä käyttöjärjestelmää kerrallaan. 26

32 Hyper-V ( on Microsoftin kehittämä tyypin yksi hypervisor. Se on ESXin suurin haastaja hypervisor markkinoilla, ollen toiseksi käytetyin hypervisor markkinaosuuden perusteella (Tsai, 2016; Smart Profile, 2017). Myös Hyper-V:lle on olemassa laaja työkalujen ekosysteemi, jonka lisäksi sen ilmainen versio tulee automaattisesti Windows Serverin mukana. Xen, tai Xen Project, on, kuten jo mainittiin, avoimeen lähdekoodiin perustuva tyypin yksi hypervisor. Alun perin se tuki vain paravirtualisointia, mutta nykyään sillä voi ajaa myös täysin virtualisoituja virtuaalikoneita. Tätä varten isäntäkoneen prosessorin on tuettava virtualisointia natiivisti ja Xenin on käytettävä virtualisoijaa, kuten QEMUa, hyväkseen. Lisäksi Xenillä on mahdollista ajaa nämä kaksi tekniikkaa yhdistäviä virtuaalikoneita, jotka hyödyntävät prosessorien natiivin virtualisoinnin tukea, mutta käyttävät esimerkiksi paravirtualisoituja I/O-ajureita. Tuki Xen-pohjaisten virtuaalikoneiden ajamiseen lisättiin Linuxin kerneliin versio 3.0 vuonna 2011 (Kurth, 2011; Xen Project For Beginner, 2018; Xen Project Software Overview, 2018). Eri yritykset ovat myös kehittäneet Xeniin perustuvia kaupallisia tuotteita, kuten Citrixin XenServer ( ja Oraclen VM Server ( Käytännössä esimerkiksi XenServer tarjoaa virtuaalikoneiden hallinta- ja muita työkaluja sekä tukea mahdollisiin ongelmiin maksua vastaan. Itse hypervisor ja muu ydintoiminnallisuus on avoimen lähdekoodin Xen (Kurth, 2013). Markkinaosuuden perusteella XenServer on käytetyin avoimeen lähdekoodiin perustuva hypervisor, kolmanneksi suurimmalla kokonaisosuudella (Tsai, 2016; Smart Profile, 2017). KVM esiteltiin lyhyesti jo alakohdassa Vaikka se on osa Linuxin kerneliä ja sinänsä ilmainen käyttää, on sen ympärille kehitetty myös kaupallisia ratkaisuja ja työkaluja, kuten Red Hat Virtualization ( Myös esimerkiksi AWS kehittänyt uuden KVM:ään perustuvan hypervisorin 27

33 pilvessään käytettäväksi (Sharwood, 2017a; Sharwood, 2017b; AWS EC2 FAQ, 2019). Muita hypervisoreita ovat muun muassa Oraclen VirtualBox ( Parallels ( ja Xvisor ( Monet virtualisointiratkaisut ovat pohjimmiltaan melko samanlaisia, ja suurimmat erot löytyvät virtualisointia tukevien ja hallintaa helpottavien työkalujen määrästä ja laadusta. Muutaman virtuaalikoneen ajamiseen ei välttämättä tarvitse järeitä työkaluja, vaan jokin halvempi tai jopa ilmainen ratkaisu voi olla täysin riittävä. Toisaalta, jos virtuaalikoneita on satoja tai tuhansia, joutuu hallintaan jo panostamaan enemmän. Tämä tulee kuitenkin todennäköisesti maksamaan kalliimman ratkaisun muodossa. 3.2 Kontit Konttipohjainen virtualisointi ei luo varsinaisia virtuaalikoneita, vaan suljettuja ympäristöjä, eli kontteja, jotka sisältävät ajettavat ohjelmistot ja niiden tarvitsemat ohjelmistokirjastot ja binääritiedostot. Kuten jo mainittiin, kontit käyttävät isäntäkäyttöjärjestelmän resursseja suoraan hyväkseen, joka voi tehdä niistä kevyempiä ja suorituskykyisempiä virtuaalikoneisiin verrattuna, mutta myös rajoittuneempia. Esimerkiksi saman kernelin käyttämisen vuoksi Linuxia ajavalla isäntäkoneella ei voi ajaa Windows-kontteja, mutta toisaalta eri Linux -variaatioiden, kuten Ubuntun ja Debianin, ajo samaan aikaan onnistuu. Konttipohjaisen järjestelmän rakenne esitetään kuvassa 4 (Morabito et al., 2015). 28

34 Kuva 4. Kontti. Konttien perusidean voidaan sanoa juontavan alkunsa vuonna jo 1979 julkaistusta Unixin chroot-komennosta (change root, juurihakemiston vaihto). Chrootin avulla voidaan käytännössä rajoittaa jonkin prosessin oikeuksia muokata ja käyttää muita tiedostoja, eristäen sen muusta järjestelmästä (Linux Programmer s Manual, chroot, 2018) luvun alussa useat eri tahot kehittivät ideaa eteenpäin: FreeBSD:n jailtoiminnallisuus vei chrootia pidemmälle, ja Virtuozzon ( ja sen avoimen lähdekoodin version OpenVZ:n ( sekä Solariksen zonesin voidaan sanoa olevan ensimmäisiä varsinaisia kontteja luovia ja ajavia työkaluja (Bernstein, 2014; Kovács, 2017; Riondato, 2018; Oracle Help Center, 2018). Näistä työkaluista kerrotaan lisää alakohdassa Linuxin kerneliin konttien luomisen ja ajamisen natiivi tuki lisätiin vuonna 2008 LXC:n ( muodossa. LXC on rakennettu Linuxin kernelin cgroups- ja namespaces-toiminnallisuuksien avulla. Näistä kerrotaan lisää alakohdassa Vaikka edellä mainitut työkalut ovat toimivia virtualisointityökaluja, ei konttipohjainen virtualisointi lyönyt kunnolla läpi ennen Dockeria ( Docker julkaistiin vuonna 2013 ja se on verrattain 29

35 lyhyessä ajassa saavuttanut suuren suosion. Dockerin ideana on tehdä konttien luomisesta ja hallinnasta mahdollisimman helppoa ja yksinkertaista. Kontteja voi määritellä yksinkertaisten Dockerfile-tiedostojen avulla, jonka jälkeen niitä voi luoda millä tahansa koneella, jolle on asennettu Docker. Tämä tekee Docker konteista erittäin siirrettäviä. Kuvassa 5 näytetään Dockerista, LXC:stä, Xenistä ja VMWare ESXistä tehdyt Google-haut aikavälillä Vaikka tämä ei sinänsä ole tieteellisesti pitävä mittari, voi siitä nähdä miten paljon mielenkiinto Dockeria kohtaan on kasvanut sen julkaisun jälkeen. Kuva 5. Virtualisointitekniikoiden herättämä kiinnostus Googlessa (Google, 2018). Alakohdassa esitellään millainen modernin konttipohjaisen virtualisointityökalun arkkitehtuuri voi olla, ja alakohdassa käydään läpi, miten se voidaan toteuttaa teknisesti. Alakohdassa kerrotaan tarkemmin eri työkaluista, jotka toteuttavat konttipohjaisen virtualisoinnin Konttipohjaisen virtualisointityökalun arkkitehtuuri Tässä alakohdassa esitellään millainen konttipohjaisen virtualisointityökalun arkkitehtuuri voi olla. Dockerin arkkitehtuuria käytetään esimerkkinä, sillä se on 30

36 ylivoimaisesti suosituin konttipohjainen virtualisointityökalu, jonka lisäksi se perustuu avoimeen lähdekoodiin. Vaikka arkkitehtuuri on kokonaisuudessaan hieman muista työkaluista poikkeava, ovat jotkin sen osat, kuten hieman myöhemmin esiteltävät kuvat ja itse kontit samankaltaisia muiden työkalujen, kuten LXC:n, kanssa. Lisäksi jokaisen työkalun arkkitehtuuri poikkeaa hieman muista, eikä tämän tutkielman tarkoituksena ole esitellä jokaista työkalua erikseen. Dockerin arkkitehtuuri on pohjimmiltaan melko yksinkertainen asiakas-palvelin -arkkitehtuuri. Asiakas voi olla esimerkiksi komentoriviohjelmisto, jolla annetaan eri komentoja palvelimelle. Palvelin on isäntäkoneella ajettava Docker daemontaustaprosessi (dockerd), joka kuuntelee asiakkaan antamia komentoja ja toteuttaa ne. Lisäksi se huolehtii myös muun muassa konteista ja niitä määrittelevistä kuvista sekä konttien verkko- ja levy-rajapinnoista. Kokonaisuuteen kuuluu myös Docker rekisteri (register), joka on käytännössä säilytyspaikka kuville. Arkkitehtuuri esitellään kuvassa 6 (Docker Engine, 2018). Kuva 6. Dockerin arkkitehtuuri (Docker Engine, 2018). 31

37 Asiakas ja palvelin kommunikoivat verkon välityksellä REST-rajapintojen (Representational State Tranfer) avulla. Dockerilla on oma komentoriviohjelmistonsa, Docker Cli, jonka lisäksi monille ohjelmointikielille, kuten Pythonille ja Go:lle, on myös tehty omat asiakaskirjastonsa. Toisaalta, koska kommunikointi tapahtuu REST-rajapintojen, myös vain HTTP-protokollan (Hypertext Transfer Protocol) käyttäminen on mahdollista (Docker Engine, 2018; Docker Develop, 2018; Inagaki et al., 2016). Dockerissa kontit voidaan määritellä kuvien avulla. Kuva on ohje, kuinka kontti pitää luoda, ja esimerkiksi mitä ohjelmistoja sille asennetaan. Se voi perustua jo olemassa olevaan kuvaan: kuva voi esimerkiksi perustua Debian-käyttöjärjestelmään mutta lisätä konttiin uusia kerroksia, kuten ohjelmistoja ja muita asetuksia. Dockerissa kuvia määritellään Dockerfile-tiedostoon määriteltävien ohjeiden avulla. Yksinkertaisesta Dockerfilestä ja sen ajamasta Python-ohjelmasta on esimerkit liitteissä 1 ja 2. Tulee kuitenkin huomata, ettei vain Docker käytä kuvia, vaan myös esimerkiksi LXC-kontit perustuvat kuviin. Dockerille ainutlaatuinen ominaisuus on edellä mainitut kerrokset, joissa jokainen ohje lisää kuvia rakentaessa niihin uuden kerroksen. Jos jokin kerroksista vaihdetaan, uutta kuvaa rakentaessa vain tämä ja sen päälle rakennetut kerrokset tulee rakentaa uudelleen ja muita kerroksia voidaan käyttää sellaisenaan, jos ne on tallennettu tietokoneen muistiin. Tämä tekee kuvien rakentamisesta ja muokkaamisesta nopeampaa siihen verrattuna, että koko kontti tulisi aina rakentaa uudestaan (Docker Engine 2018; Inagaki et al., 2016). Dockerissa itse kontit ovat rakennettuihin kuviin perustuvia ajettavia instansseja. Kontteja ajettaessa niille luodaan oma tiedostojärjestelmä ja verkkorajapinta, joiden avulla ne voivat luoda ja muokata kontin sisällä olevia tiedostoja ja kommunikoida ulkoisten verkkojen kanssa. Oletusarvoisesti kontit ovat melko eristettyjä isäntäkoneesta ja muista konteista, mutta esimerkiksi niiden tiedostojärjestelmän ja verkkorajapinnan eristyneisyyttä voidaan hallinnoida. Kontteja voidaan luoda, käynnistää, pysäyttää, siirtää ja poistaa tarpeen mukaan asiakasohjelmiston antamien komennon avulla (Docker Engine, 2018; Inagaki et al., 2016). 32

38 Docker-rekisteri on kuvien säilytyspaikka, johon käyttäjät ja organisaatiot voivat tallentaa kuviaan ja josta voi ladata muiden luomia kuvia. Tämä mahdollistaa kuvan siirtämisen koneelta toiselle nopeasti. Monista suosituista ohjelmistoista ja työkaluista on lisäksi olemassa niiden kehittäjien luomia virallisia kuvia. Lisäksi, jos Docker rakentaa uutta kuvaa paikallisesti, eikä kuvaa, johon se perustuu, löydy isäntäkoneelta, ladataan se automaattisesti rekisteristä, olettaen että se löytyy sieltä. Docker-kuvia on myös mahdollista ladata yksityisiin rekistereihin (Docker Engine, 2018) Konttipohjaisen virtualisoinnin tekninen toteutus Tässä alakohdassa esitellään, kuinka moderni konttipohjainen virtualisointi voidaan toteuttaa teknisesti. Dockeria käytetään jälleen esimerkkinä samoista syistä kuin edellisessä alakohdassa. Lisäksi Docker pitää sisällään joitain mielenkiintoisia yksityiskohtia, kuten mahdollisuuden käyttää LXC:tä konttien ajamiseen. Dockerin ensimmäisissä versioissa LXC olikin oletussuoritusajuri, joskin se on sittemmin vaihdettu Dockerin omaan libcontainer:iin (Hykes, 2014; Morabito, 2015). Konttityökalut voivat muutenkin käyttää toisia muita konttityökaluja hyväkseen. Esimerkiksi Oraclen Solaris käyttöjärjestelmään on sisäänrakennettu ominaisuus, jonka avulla Oracle Solaris Zones -konttityökalulla rakennettuja kontteja voidaan jakaa Dockeria käyttäen (Hardie, 2015). Vaikka monet työkalut on toteutettu omalla tavallaan, voidaan ainakin joitakin teknisiä yksityiskohtia yleistää myös muihin työkaluihin. Lisäksi viime vuosina monet suuret teknologiafirmat, kuten Docker, Google, Microsoft ja Amazon ovat ryhtyneet tekemään yhteistyötä yhteisten standardien luomiseen konttipohjaisille virtualisointityökaluille ja niiden käyttämille rajapinnoille Open Container Iniativen (OCI) muodossa ( Kuten kohdan johdannossa todettiin, kontit voidaan toteuttaa Linuxin kernelin cgroups- ja namespaces-toiminnallisuuksien avulla, ja Docker käyttääkin näitä hyväkseen. Cgroups, eli control groups (kontrolliryhmät) mahdollistavat prosessien jakamisen hierarkkisiin ryhmiin, joiden resurssien käyttöä voidaan valvoa ja 33

39 rajoittaa. Resurssien saatavuutta voidaan määritellä dynaamisesti esimerkiksi prosessien tarpeiden mukaan, antaen suurta tehtävää työstävälle prosessille suurempi osa resursseista kuin prosessille, joka odottaa seuraavaa tehtävää. Dockeria käytettäessä konttien resurssien käyttöä voidaan rajoittaa käyttäjän antamien asetusten avulla kontteja ajettaessa. Cgroupsin avulla voidaan myös rajoittaa prosessien oikeuksia käyttää laitteistoa, esimerkiksi levyltä lukemista tai sille kirjoittamista. Tämän avulla voidaan esimerkiksi parantaa tietoturvaa estämällä kontteja lukemasta isäntäkoneella olevia tiedostoja tai antamasta sille pahansuopia komentoja. Cgroups lisättiin Linuxin kerneliin vuonna 2007, versiossa (Linux Programmer s Manual, cgroups, 2018; Docker Engine, 2018). Vuonna 2002 versiossa Linuxin kerneliin lisättyä namespaces -toiminnallisuutta käytetään konttien eristämiseen toisistaan ja isäntäkoneesta. Niiden avulla tiettyjä prosesseja voidaan estää näkemästä ja käyttämästä isäntäkoneen muita resursseja ja prosesseja tarpeen mukaan. Namespaceja on erilaisia käyttöjärjestelmän eri toiminnallisuuksia varten. Kun Docker-kontti käynnistetään, Docker luo sille seuraavat namespacet (Linux Programmer s Manual, namespaces, 2018; Docker Engine, 2018): pid (Process id) prosessien eristämistä varten. net (Networking) verkon rajapintoja varten. ipc (InterProcess Commication) jaettujen resurssien käyttämistä varten. mnt (Mount) tiedostojärjestelmää varten. uts (Unix Timesharing System) kernelin eristämistä varten. Docker-kontit voivat tallentaa dataa tiedostojärjestelmään usealla eri tavalla. Oletusarvoisesti data tallennetaan konttien sisään, ja jos kontti poistetaan, myös sen sisällä oleva data poistetaan samalla. Jos data halutaan säilyttää konteista riippumatta, tai jos se halutaan esimerkiksi jakaa eri konttien kesken, on se myös mahdollista tallentaa konttien ulkopuolelle (Docker Storage, 2018). Suositeltu tekniikka datan säilyttämiseen konttien ulkopuolella on Dockerin hallitsemat loogiset levyt (volume). Loogisia levyjä voi luoda tarpeen mukaan ja kiinnittää (mount) yhteen tai useampaan konttiin. Docker myös pitää ne eristettynä 34

40 isäntäkoneesta, jonka lisäksi ne voivat myös sijaita esimerkiksi pilvessä. Kontit on myös mahdollista kiinnittää suoraan isäntäkoneella oleviin kansioihin (bind mount). Tämä voi olla hyvin suorituskykyinen tekniikka, mutta myös mahdollinen tietoturvariski, sillä se voi potentiaalisesti antaa kontille suoran pääsyn isäntäkoneella oleviin tiedostoihin. Kontti voidaan myös kiinnittää suoraan isäntäkoneen muistiin (tempfs mount), mutta tällä tekniikalla tallennettu tieto ei luonnollisesti säily, jos kontti pysäytetään tai poistetaan (Docker Storage, 2018). Datan tallentamiseksi konttien sisään Docker voi käyttää jotakin Union File System (UnionFS, UFS) varianteista ajurina. Kuten Docker kuvat, UFS-tiedostojärjestelmät ovat pinoja, jotka koostuvat eri kerroksista. UFS:n toimintaperiaate on yksinkertaistettuna seuraava: alimmainen taso voi esimerkiksi koostua tietystä tiedostojärjestelmässä olevasta kansiosta, ja sen päällä olevat tasot voivat lisätä, muuttaa tai piilottaa sen sisällä olevia tiedostoja ylemmällä olevilta tasoille. Tiedostot voivat myös esimerkiksi olla peräisin eri sijainneista, mutta UFS tekee niistä yhden loogisen kokonaisuuden union mount -nimisen tekniikan avulla, jossa union tulee joukko-opin unioni-termistä. Kun kontti esimerkiksi kirjoittaa johonkin olemassa olevaan tiedostoon, UFS käy tasot läpi ylhäältä alas päin, ja tiedoston löytäessään kopioi sen ylimmälle, kontille kuuluvalle, tasolle, jossa sitä voidaan muuttaa sen vaikuttamatta alempiin tasoihin. Tätä tekniikkaa kutsutaan nimeltä copy-on-write (CoW), ja se varmistaa, etteivät kontit muuta isäntäkoneella olevia tiedostoja, antaen niille samalla mahdollisuuden muokata omia kopioitaan niistä. CoW:n etuna on myös se, että useat kontit voivat käyttää samoja tiedostoja, eikä niistä tarvitse tehdä konteille omia kopioita elleivät kontit halua muokata niitä. Docker tukee seuraavia UFS variantteja (Docker Storage, 2018; Docker Engine, 2018; Inagaki et al., 2016): AUFS (Another Union File System) Brtfs Device Mapper OverlayFS ZFS VFS (Virtual File System) 35

41 Docker-kontit yhdistetään verkkoon Docker daemonin luomien ja ylläpitämien virtuaalisten verkon avulla. Kuten vuorovaikuttamisen tiedostojärjestelmän kanssa, myös konttien verkkojen hallinnoimisessa on mahdollista valita useamman verkkoajurin väliltä. Ne toteuttavat virtuaalisen verkon hieman eri tavoin, mutta kuitenkin niin ettei kontilla ajettavan ohjelmiston tarvitse olla toteutuksesta tietoinen. Eri ajureita ovat: bridge host overlay macvlan none (verkkoon yhdistäminen poistettu käytöstä) Kolmansien osapuolien toteuttamat ajurit Docker daemonin on mahdollista ylläpitää usempaa virtuaalista verkkoa samaan aikaan, ja yksittäisten konttien on mahdollista olla yhdistettynä niistä yhteen tai useampaan. Ulkoisten verkkojen lisäksi samalla isäntäkoneella olevien konttien on mahdollista kommunikoida toistensa kanssa suoraan näiden verkkojen kautta, jos ne ovat yhdistettyinä samoihin verkkoihin (Docker Network; Church, 2018; Inagaki et al, 2016). Edellä esiteltyjen toiminnallisuuksien, sekä muiden konttien ajamiseen tarvittavien kernelin tarjoamien toiminallisuuksien käyttöä varten Docker tarvitsee suoritusajurin, joka huolehtii muun muassa kernel-komponenttien käytöstä ja luo jokaiselle kontille oman suoritusympäristönsä. Kuten aiemmin mainittiin, Dockerin on mahdollista käyttää LXC:tä tähän tarkoitukseen, mutta oletusajurina käytetään libcontaineria, joka tarjoaa LXC:tä yhtenäisemmän rajapinnan kerneliin alustasta ja muista työkaluista riippumatta, sekä laajemmat mahdollisuudet käyttää muita teknologioita, kuten OpenVZ:tä, Solaris Zoneja ja chrootia, hyväkseen. Vuonna 2015 libcontainer liitettiin osaksi OCI-spesifikaatiota runc, jonka tarkoituksena määritellä universaali suoritusympäristö konteille (Hykes, 2014; Hykes, 2015). 36

42 3.2.3 Muita konttipohjaisia virtualisointityökaluja Tässä alakohdassa esitellään lyhyesti muita työkaluja, joilla voidaan toteuttaa konttipohjainen virtualisointi tai vastaava toiminnallisuus. Vaikka Docker on selvästi suurin tekijä, on muille työkaluille edelleen käyttötapauksensa, ja monia niistä kehitetään aktiivisesti. Lisäksi monet työkalut voivat toimia yhdessä. Dockeria tässä alakohdassa ei enää esitellä uudestaan. Kuten johdannossa todettiin, konttipohjaisen virtualisoinnin esikuvana voidaan pitää Unix-pohjaisten järjestelmien chroot-komentoa. Sillä voi vaihtaa halutun prosessin juurikansion, joka luo uuden eristetyn ympäristön, chroot jailin. Tämän avulla on mahdollista rajoittaa prosessin tai käyttäjän pääsyn vain tiettyyn kansioon, eristäen sen muusta järjestelmästä. Pelkästään chrootin käyttäminen prosessien ja käyttäjien eristämiseen voi kuitenkin olla tietoturvariski, sillä niiden on mahdollista paeta chroot jailista esimerkiksi jos jokin kansio siirretään ulos uuden juurikansion alta. Tulee myös huomata, että chroot ei sinänsä ole virtualisointitekniikka, vaan sen tarkoituksena on vain mahdollistaa prosessien eristäminen (Linux Programmer s Manual, chroot, 2018). Chrootin päälle rakennettu FreeBSD:n jail-toiminnallisuus on askeleen lähempänä konttipohjaista virtualisointia. Sen avulla on mahdollista esimerkiksi virtualisoida pääsy tiedostojärjestelmään, muihin käyttäjiin ja verkkorajapintoihin, tehden siitä chrootia joustavamman ja monipuolisemman. Jaileille on myös mahdollista esimerkiksi antaa omat IP-osoitteensa. Kuten chroot, myöskään jail-toiminnallisuus ei ole tietoturvan kannalta turvallinen ratkaisu, sillä myös niistä on mahdollista paeta (Riondato, 2018). Linux-VServer ( on vuonna 2001 esitelty, yksityisen virtuaalisen palvelimen toteuttava ohjelmisto. Se on avoimen lähdekoodin projekti ja joskin viimeisin virallinen julkaisu on vuodelta 2008, viimeisin ennakkojulkaisu julkistettiin vuonna Linux-VServer perustuu konseptiin nimeltä turvallisuuskontekstit (security contexts), joiden avulla voi luoda eristettyjä ympäristöjä, pitkälti chroot- ja FreeBSD-jailien tapaan. Niiden avulla luodut 37

43 virtuaaliset palvelimet käyttävät isäntäkoneen kerneliä hyväkseen, ja ne eristetään toisistaan osittain virtualisoinnin ja osittain muiden tekniikoiden avulla: esimerkiksi palvelimen saatavilla oleva muisti on virtualisoitu, mutta niiden verkot eristetään toisistaan kernelin avulla. Linux-VServer vaatiikin toimiakseen muokkauksia isäntäkoneen käyttöjärjestelmän kerneliin, mutta toisaalta tukee usean eri Linuxpohjaisen käyttöjärjestelmän ajamista samaan aikaan (Linux-VServer Paper, 2011). Ensimmäinen varsinaisen konttipohjaisen virtualisoinnin toteuttava ohjelmisto oli vuoden 2002 alussa Linux-käyttöjärjestelmille julkaistu Virtuozzo. Virtualisoitavia käyttöjärjestelmiä ei tosin vielä kutsuttu konteiksi, vaan virtuaalisiksi ympäristöiksi (virtual environment), mutta niiden toimintaperiaate oli jo alusta alkaen hyvin samankaltainen kuin modernien konttien: virtuaalisia ympäristöjä ajetaan aivan kuin normaaleja prosesseja, kernelin huolehtiessa niiden yhteisesti käyttämistä resursseista ja eristämisestä. Tämän vuoksi myös Virtuozzo vaatii muokkauksia isäntäkoneen kerneliin. Vuonna 2005 Virtuozzon lähdekoodi tehtiin avoimeksi ja nimettiin OpenVZ:ksi, ja Virtuozzoa jatkettiin siihen perustuvana kaupallisena projektina. Nykyään Virtuzzo voi konttien virtualisoinnin lisäksi toimia esimerkiksi hypervisorina (Lunev et al., 2000; OpenVZ Livejournal, 2015). Oracle Solariksen virtualisointityökalu oli ensimmäinen joka käytti termiä kontti (container): vuonna 2005 julkaistu Oracle Solaris Containers, joskin se on sittemmin nimetty Oracle Solaris Zonesiksi. Siinä sekä isäntäkäyttöjärjestelmää että virtualisoituja vieraskäyttöjärjestelmiä kutsutaan alueiksi (zone), jotka esimerkiksi modernien konttien tapaan jakavat isäntäkäyttöjärjestelmän resurssit, mutta ovat toisistaan muuten eristettyjä. Oracle Solaris Zonesin avulla voidaan luoda erilaisia alueita tarpeen mukaan: ne voivat esimeriksi olla täysin eristettyjä isäntäkäyttöjärjestelmästä, tai jakaa sen kanssa tiedostojärjestelmän osittain tai kokonaan. Tietynlaisilla alueilla voi myös ajaa Oracle Solariksen edellisiä versioita. Oracle Solaris Zones on osa Solaris-käyttöjärjestelmää ja vaatii sen isäntäkoneelle toimiakseen, mutta sen avulla on mahdollista luoda myös muita kuin Linux-pohjaisia alueita (Drewanz & Grimmer, 2013, Oracle Help Center, 2018). 38

44 Jo lyhyesti mainittu LXC toi kaikki konttipohjaiseen virtualisointiin tarvittavat työkalut Linuxin kerneliin. Sen toimintaperiaate on hyvin samantapainen Dockerin kanssa, sillä Docker on rakennettu pitkälti samoilla Linuxin kernelin työkaluilla kuin LXC. Suuri ero LXC:n ja Dockerin välillä on, että Dockerin tarkoituksena on ajaa yhtä ohjelmistoa per kontti ja tehdä yhteistyötä konttien välillä, kun LXC keskittyy enneminkin koko käyttöjärjestelmän virtualisointiin (Drewanz & Grimmer, 2013; Linux containers, 2019). LXC:n päälle on myös rakennettu konttien hallinnointiin tarkoitettu LXD ( jonka tavoitteena on tehdä konttien hallinnasta samanlaista kuin virtuaalikoneiden hallinnasta. Sen voidaankin sanoa olevan kevyt hypervisor, joka ajaa kontteja virtuaalikoneiden sijaan. Vaikka se on rakennettu LXC:n avulla, voidaan sillä ajaa myös esimerkiksi Docker-kontteja (Linux containers, 2019). Itse virtualisointityökalujen lisäksi on olemassa paljon työkaluja, jotka helpottavat esimerkiksi konttien luontia, ylläpitoa ja orkestrointia. Näitä ovat muiden muassa Googlen kehittämä Kubernetes ( Dockerin Swarm ( ja Ubuntun kehittämä LXD, sekä monien pilvipalveluiden sisäänrakennetut toiminnot, joiden avulla kontteja voi hallinnoida automaattisesti. Näitä työkaluja ei kuitenkaan käydä tässä tutkielmassa tarkemmin läpi, joskin luvun 5 vertailussa LXC:stä ajetaan LXD:n kanssa. 39

45 4 Virtualisointitekniikoiden aiempia vertailutuloksia Virtualisointitekniikoiden käyttö on viime vuosina kasvanut räjähdysmäisesti niiden kehittymisen ja Internetin suosion kasvun vuoksi. Kuten todettu, muun muassa pilvipalvelut on rakennettu pitkälti virtualisoinnin avulla, ja ne puolestaan ovat perustana suurelle osalle verkkopalveluista. Tämän seurauksena eri virtualisointitekniikoita on tutkittu ja niitä on vertailtu keskenään runsaasti, sekä tieteellisesti, että ei-tieteellisesti. Eritoten tieteellisessä kirjallisuudessa vertailu keskittyy yleensä eri tekniikoiden ja työkalujen suorituskyvyn vertailuun keskenään, käyttäen natiivia, eli ei-virtualisoitua, järjestelmää vertailukohtana. Monet tieteelliset lähteet jättävät esimerkiksi käytettävyyden vertailun vähemmälle, mutta siitä on helpompaa löytää ei-tieteellisiä lähteitä, kuten blogeja ja lehtiartikkeleita, jotka usein perustuvat ennemminkin vertailijoiden omiin subjektiivisiin mielipiteisiin ja kokemuksiin. Vaikka eri virtualisointitekniikoista on kirjoitettu paljon niitä vertailevia tutkimuksia, on niiden jatkuva vertailu kuitenkin tärkeää, sillä uusia työkaluja kehitetään ja olemassa olevia parannellaan jatkuvasti. Lisäksi koska virtualisoidut ympäristöt luonnostaan erittäin monimutkaisia kokonaisuuksia, ja niiden suorituskykyyn voi vaikuttaa useat eri tekijät aina isäntäkoneesta itse virtualisointityökaluun ja sen käyttämiin asetuksiin, on eri työkalujen vertailulla mahdollista löytää ennestään tuntemattomia heikkouksia, eritoten jos tulokset eroavat merkittävästi muista vastaavista vertailuista. Tässä luvussa esitellään joidenkin tutkimusten tuloksia eri virtualisointityökalujen suorituskyvyn näkökulmasta. Tutkimusten valinnassa on painotettu enemmän viime vuosina tehtyjä tutkimuksia, mutta mukana on myös muutama vanhempi tutkimus niiden virtualisointityökalujen vuoksi. On mielenkiintoista huomata, että vaikka ensimmäiset tässä tutkielmassa esitellyt tutkimukset ovat viime vuosikymmenen lopulta, ovat niiden tulokset pääosin samansuuntaisia aivan viime aikoina tehtyjen tutkimusten kanssa. Toisaalta on mielenkiintoista huomata joidenkin työkalujen, eritoten KVM:n, suorituskyvyn kehittyminen vuosien varrella. 40

46 Tässä tutkielmassa käytetään kirjallisuuteen perustuvan suorituskykyvertailun pohjana seuraavia tutkimuksia: Walters et al. (2008) vertailivat Xeniä, VMware Serveriä ja OpenVZ:tä. Morabito et al. (2015) vertailivat KVM:n, Dockerin, LXC:n ja OSv:n suorituskykyjä. OSv:n tuloksia ei tässä tutkmuksessa huomioida, sillä ne ovat vajavaiset. Felter et al. (2015) käyttivät vertailussaan Dockeria ja KVM:ää. Ramalho & Neto (2016) vertailivat myös Dockeria ja KVM:ää. Shirinbab et al. (2017) käyttivät vertailussaan Dockeria ja VMwaren ESXihypervisoria. Li et al. (2017) käyttivät vertailussaan Dockeria ja VMWare Workstationia. Tutkimuksista käyttämistä virtualisointityökaluista voidaan huomata, että eritoten viime vuosina Docker on ollut selvästi suosituin tutkimuskohde. Voidaan sanoa, että se on tärkein konttipohjaisen virtualisoinnin toteuttava työkalu, joka tekee siitä hyvän tutkimuskohteen. Myös eri hypervisor-pohjaiset työkalut ovat hyvin edustettuina VMwaren, Xenin ja KVM:n muodoissa. Tutkimuksissa vertaillaan yleensä eri tekniikoiden suorituskykyä neljältä eri kantilta: prosessorin, muistin sekä levyn ja verkon I/O:n. Kohdassa 4.1 esitellään tutkimusten prosessorin suorituskykyvertailujen tuloksia. Kohta 4.2 puolestaan keskittyy muistin vertailujen tuloksiin, joskin Walters et al. ja Shirinbab et al. eivät suoraan tutkineet muistin suorituskykyä, joten noita tutkimuksia ei kohdassa mainita. Kohdassa 4.3 esitellään levyn I/O:n vertailujen tuloksia, ja lopuksi kohdassa 4.4 käydään läpi verkon I/O:n vertailujen tuloksia. 4.1 Prosessorin suorituskyky Walters et al. käyttivät vertailussaan työkaluja, jotka on tarkoitettu mittaamaan korkean suorituskyvyn laskennan sovelluksien suorituskykyä. Testit mittasivat eri virtualisointityökalujen suorituskykyä sekä yhtä että useaa prosessoria käyttäen. Yhden prosessorin testeistä OpenVZ ja Xen suoriutuivat käytännössä yhtä hyvin 41

47 natiivin järjestelmän kanssa. VMWare Server suoriutui hieman huonommin, mutta senkin tulokset olivat pääosin alle 10% huonompia natiiviin verrattuna. Montaa prosessoria käytettäessä, tulokset olivat erilaisia. OpenVZ suoriutui kaikista testeistä lähes natiivin tasolla, mutta Xenin ja VMware Serverin tulokset olivat pahimmillaan jopa kymmeniä kertoja huonompia. Walter et al. kuitenkin huomauttavat, että nämä testit siirsivät dataa verkon kautta, joka on voinut vaikuttaa tuloksiin. Myös Morabito et al. käyttivät korkean suorituskyvyn laskennan työkaluja hyväkseen, ajaen sekä yhden että usean prosessorin testejä. Kaikkien testattujen virtualisointityökalujen tulokset olivat pääosin lähellä natiivia. Ainoat huomattavat erot olivat KVM:n huonompi suorituskyky kahdessa testissä, sen ollen huonoimmillaan noin 30% natiivia huonompi. Felter et al. käyttivät vertailussaan korkean suorituskyvyn laskennan työkaluja, jonka lisäksi he mittasivat suuren datamäärän kompressoinnin suorituskykyä. Docker suoriutui kaikista testeistä lähes natiivin tasolla, ollen vain 4% huonompi datan kompressoinnissa. KVM:n kohdalla erot olivat suurempia. Se oli 22% huonompi datan kompressoinnissa ja 17% korkean suorituskyvyn laskennan testeissä. Felter et al. saivat KVM:n kuitenkin lähes natiivin tasolle korkean suorituskyvyn laskennan testeissä kiinnittämällä virtuaalisen prosessorin oikeaan prosessoriin, joka voi parantaa voi prosessorin välimuistin käyttöä KVM:ssä. Myös Ramalho & Neto käyttivät korkean suorituskyvyn laskennan työkaluja. Docker suoriutui jälleen testeistä KVM:ää paremmin, ollen yhtä testiä lukuun ottamatta jokaisessa testissä korkeintaan reilun prosentin sisällä natiivin tuloksista. Myös KVM suoriutui testeistä pääosin kunnialla, päästen yhtä testiä lukuun ottamatta jokaisessa testissä reilun 4% päähän natiivin tuloksista. Kummatkin virtualisointityökalut kuitenkin suoriutuivat melko huonosti useita säikeitä käyttävästä testistä: Dockerin suoritusaika oli noin 35% natiivin suoritusaikaa hitaampia, ja KVM:n suoritusaika jopa lähes 1000% natiivia hitaampi. Shirinbab et al. testasivat virtualisointityökalujen suorituskykyä Cassandratietokantaa ( käytettäessä. Tutkimuksessa mitattiin prosessorien käyttöastetta ja operaatioiden viivettä (latency) datan eri 42

48 replikaatioasteilla, eli kuinka kauan ne vievät aikaa. Viive implikoi datan siirtonopeuden lisäksi myös, miten nopeasti operaatiot suoritettiin prosessoreissa. Docker selviytyi testeistä jälleen huomattavasti hypervisor-pohjaista työkalua paremmin, joskin senkin erot natiivin järjestelmän suorituskykyyn olivat keskimääräisesti suurempia kuin muissa tutkimuksissa ennen kaikkea prosessorin käyttöasteen kohdalla. Lopuksi, myös Li et al. käyttivät korkean suorituskyvyn laskennan työkaluja testeissään. Docker suoriutui jälleen kerran testeistä hypervisoria paremmin, joskin myös VMware Workstation ylsi pääosin verrattain lähelle natiivin järjestelmän tuloksia. On huomautettava, että VMware Workstationin tulosten vaihtelu yksittäisten testiajojen välillä oli melko suurta, joskin myös Docker kärsi tästä ongelmasta mutta pienemmässä määrin. Kaikkien tässä esiteltyjen tutkimusten tulokset olivat selviä prosessorin suorituskyvyn osalta. Konttipohjaiset virtualisointityökalut suoriutuivat lähes kaikista testeistä hypervisor-pohjaisia työkaluja paremmin, useasti jopa lähes natiivin järjestelmän tasolla. On tosin myös huomattava, että ennen kaikkea uudemmissa tutkimuksissa myös hypervisorit suoriutuivat testeistä huomattavasti paremmin vanhempien tutkimusten tuloksiin verrattuna. 4.2 Muistin suorituskyky Muistin suorituskyvyn mittaamiseen Morabito et al. käyttivät muistin jatkuvaa lukuja kirjoitusnopeutta mittaavaa työkalua. Kaikkien virtualisointityökalujen tulokset olivat huomattavan lähellä toisiaan. KVM suoriutui tasaisesti hieman muita työkaluja huonommin, mutta ero oli lähes häviävän pieni. On mielenkiintoista huomata, että LXC suoriutui kolmessa testissä neljästä natiivia järjestelmää paremmin, joskaan tutkimuksen tekijät eivät tätä noteeraa, mahdollisesti koska erot olivat myös todella pieniä ja näin ollen mahdollisesti mittausvirheitä. Felter et al. käyttivät samaa luku- ja kirjoitusnopeutta ja lisäksi satunnaissaannin nopeutta mittaavia työkalua. Luku- ja kirjoitusnopeutta mittaavan työkalun tulokset 43

49 olivat samanlaisia kuin Morabito et al. testeissä: kaikkien virtualisointityökalujen tulokset olivat hyvin lähellä toisiaan, mutta KVM oli jälleen hieman muita hitaampi. Myös satunnaissaantia mittaavassa testissä tulokset erosivat toisistaan häviävän vähän, joskin tässä KVM suoriutui aavistuksen Dockeria paremmin. Myös Ramalho & Neto käyttivät edellisten tutkimusten käyttämää muistin luku- ja kirjoitusnopeutta mittaavaa työkalua vertailussaan. Muiden tutkimusten tavoin molempien virtualisointityökalujen tulokset olivat hyvin lähellä natiivia, mutta Docker suoriutui jälleen KVM:ää hieman paremmin kaikissa testeissä, KVM:n ollen keskimäärin hieman yli 2% hitaampi. Li et al. käyttivät myös samaa muistin luku- ja kirjoitusnopeutta mittaavaa työkalua, saaden melko samankaltaisia tuloksia. Docker suoriutui lähes samalla tasolla natiivin järjestelmän kanssa ja jopa paremmin yhdessä testissä, joskin kirjoittavat uskovat tämän olleen mittausvirhe. Myös VMware Workstation suoriutui verrattain hyvin, ollen huonoimmillaan hieman yli 5% hitaampi, joka toki on hieman enemmän kuin erot KVM:n ja natiivin järjestelmän välillä muissa tutkimuksissa. Li et al. huomauttavat jälleen, että kummankin virtualisointityökalun tuloksissa oli melko paljon vaihtelua testiajojen välillä. Tutkimusten tuloksista voidaan huomata, että virtualisoinnin ei juuri pitäisi vaikuttaa muistin suorituskykyyn virtualisointitekniikasta ja -työkalusta riippumatta. Joskin konttipohjaiset työkalut vaikuttaisivat suoriutuvan pääosin hieman paremmin, myös hypervisor-pohjaisten työkalujen suorituskyky on muutaman prosentin sisällä natiiviin järjestelmään verrattuna. Lisäksi on mielenkiintoista huomata, että kaikki tutkimukset mittasivat muistin jatkuvaa luku- ja kirjoitusnopeutta, käyttäen vieläpä samaa työkalua, ja vain yksi tutkimus mittasi satunnaissaannin suorituskykyä. 4.3 Levyn suorituskyky Jo Walters et al. vertailun tuloksista voidaan huomata, että eri virtualisointitekniikoiden erot tulevat esiin levyn suorituskykyä mitattaessa. Kirjoittajat käyttivät vertailussaan työkalua joka muun muassa kirjoittaa ja lukee 44

50 levyä eri tavoin, mutta tilan puutteen vuoksi he esittivät tutkimuksessaan vain peräkkäisessä järjestyksessä tapahtuvan luvun ja kirjoituksen tulokset. OpenVZ suoriutui sekä luvusta että kirjoituksesta verrattain hyvin, ollen luvussa huonoimmillaan noin 10% hitaampi ja suoriutuen kirjoituksesta hieman paremmin. Xen puolestaan suoriutui levyn lukemisesta 46% ja sille kirjoittamisesta 40% natiivia järjestelmää hitaammin. Walters et al. eivät pystyneet testaamaan VMware Serverin levyn suorituskykyä lainkaan, sillä se oli yhteensopimaton testin asetusten kanssa. Morabito et al. käyttivät kolmea eri työkalua mittaamaan levyn suorituskykyä peräkkäisen luvun ja kirjoituksen, satunnaisen kirjoituksen ja haun sekä erityisessä muodossa olevien laitetiedostojen (/dev/zero/) luvun ja kirjoituksen osalta, vastaavasti. Peräkkäisen luvun ja kirjoituksen tulokset olivat samankaltaisia edellisen tutkimuksen kanssa. Sekä LXC:llä että Dockerilla oli huomion arvoinen, joskaan ei erityisen suuri ero natiiviin järjestelmään, LXC:n ollessa kummassakin tapauksessa hieman nopeampi. Toisaalta KVM:n lukunopeus oli vain noin yksi kolmasosa natiiviin verrattuna, kirjoitusnopeuden ollessa vieläkin huonompi yksi viidesosa. Satunnaisten lukujen osalta sekä LXC että Docker olivat kummatkin reilu 10% prosenttia natiivia hitaampia, ja KVM noin 50% hitaampi. LXC suoriutui myös satunnaisesta hausta vastaavasti, mutta mielenkiintoisesta Docker oli noin 43% hitaampi ja KVM jopa 93% hitaampi. Laitetiedostojen luvussa ja kirjoituksessa Docker toisaalta oli vain reilu 7% natiivia järjestelmää hitaampi, ja Morabito et al. raportoivat sen ollen jopa natiivia nopeampi joissakin testiajoissa. LXC:n suoritusnopeus oli noin 25% hitaampi ja KVM:n reilut 59% hitaampi natiiviin verrattuna. Felter et al. mittasivat levyn suorituskykyä peräkkäisen luvun ja kirjoituksen, satunnaisen luvun, kirjoituksen ja sekoitetun työkuorman (70% lukua ja 30% kirjoitusta), sekä luvun viiveen osalta yhdellä työkalulla. Docker suoriutui jokaisesta testistä lähes täysin natiivin järjestelmän tasolla. Peräkkäisen luvun ja kirjoituksen osalta KVM suoriutui myös erittäin hyvin, joskin kirjoituksessa sen suorituskyky vaihteli huomattavan paljon testiajojen välillä. Satunnaisen luvun ja kirjoituksen osalta KVM suoriutui huomattavasti huonommin, ollen parhaimmillaankin vajaa 45

51 puolet natiivia järjestelmää hitaampi. Myös luvun viive oli KVM:llä 2-3 kertaa natiivia järjestelmää ja Dockeria suurempi. Myös Ramalho & Neto mittasivat testeissään peräkkäisen luvun ja kirjoituksen sekä laitetiedostojen kirjoituksen ja luvun suorituskykyä. Peräkkäisen luvun ja kirjoituksen tulokset olivat lähes tismalleen samoja kuin Morabito et al. testeissä: Docker suoriutui lähes natiivin tasolla, kun KVM:n lukunopeus oli vain noin yksi kolmasosa ja kirjoitusnopeus reilu yksi viidesosa natiiviin järjestelmään verrattuna. Laitetiedostojen osalta tulokset olivat myös samansuuntaisia, joskin Docker suoriutui hieman paremmin kuin Morabito et al. testeissä, ollen vain 1.4% hitaampi lukiessa ja 0.4% hitaampi kirjoittaessa. KVM:n luku- ja kirjoitusnopeudet puolestaan olivat alle yhden viidesosan natiiviin verrattuna. Shirinbab et al. mittasivat Cassandran kirjoitusnopeutta, kun siihen vain kirjoitettiin dataa sekä kun siitä luettiin ja siihen kirjoitettiin dataa sekaisin. Docker suoriutui testeistä jälleen kerran lähellä natiivin järjestelmän tasoa, VMwaren ESXin ollessa selvästi hitaampi ennen kaikkea samanaikaisten luku- tai kirjoituspyyntöjen lisääntyessä. Li et al. raportoivat hieman muista tutkimuksista eriävistä tuloksista. He suorittivat testinsä mittaamalla datan kirjoitusnopeutta sekä tavuina että suurempina lohkoina. Joskin Docker suoriutui lohkojen lukemisesta ja kirjoittamisesta lähes natiivin järjestelmän tasolla, sen tavujen lukeminen ja kirjoittaminen olivat noin 50% ja reilu 40% hitaampia natiivin verrattuna, tässä järjestyksessä. Myös VMware Workstationion suorituskyky vaihteli testistä riippuen, ollen vain hieman natiivia hitaampi tavuja kirjoitettaessa, noin 30% hitaampi lohkoja kirjoitettaessa ja luettaessa, ja noin 40% hitaampi tavuja luettaessa. Kummankin työkalun tulosten vaihtelu ajojen välillä oli melko tasaista lukuun ottamatta VMwaren Workstationin vaihtelua tavuja luettaessa, jossa sen tulokset saattoivat vaihdella jopa 200% ajojen välillä. Li et al. mittasivat myös, kuinka monta kertaa eri virtualisointityökalut voivat suorittaa levyn suorituskykyä mittaavan työkalun testit tietyn ajan sisällä. Tästä testistä Docker suoriutui lähes natiivin järjestelmän tasolla, suorittaen 147 testiä 24 46

52 tunnin aikana verrattuna natiivin suorittamaan 150 testiin. VMware Workstation puolestaan kerkesi suorittamaan vain 101 testiä. Toisin kuin prosessorin ja muistin suorituskykyä mitattaessa, levyn suorituskyvyn testien tulokset olivat tutkimuksesta riippuen melko erilaisia. Vaikka konttipohjaiset työkalut suoriutuivat pääosin hypervisoreita paremmin, vaihtelivat niidenkin tulokset lähes natiivin järjestelmän tasosta huomattavasti huonompiin tuloksiin. Usean tutkimuksen kirjoittajat huomauttavat, että hypervisoreiden osalta suorituskykyä huonontaa se, että ne joutuvat virtualisoimaan tiedostojärjestelmän. Toisaalta, eritoten Dockerin tapauksessa, kontin asetukset voivat vaikuttaa tuloksiin huomattavasti. Esimerkiksi Morabito et al. ja Ramalho & Neto ajoivat Dockeria käyttäen AUFS-tiedostojärjestelmää, ja heidän tuloksissaan oli huomattava ero Dockerin suosittelemaan loogista levyä käyttävien Felter et al. tuloksiin. 4.4 Verkon suorituskyky Myös verkon suorituskykytestien eri tulokset vaihtelevat rajusti tutkimuksesta ja virtualisointityökalusta riippuen. Walters et al. mittasivat eri työkalujen läpäisyä (throughput) ja viivettä verkkopyyntöjen ja -vastausten (request, response) osalta TCP-protokollaa (Transmission Control Protocol) käyttäen. Viiveen osalta OpenVZ suoriutui lähes natiivin järjestelmän tasolla, sen viiveen ollessa keskimäärin hieman alle 6% huonompi natiiviin verrattuna, ja jopa natiivia parempi pakettien koon kasvaessa. Xenin viive oli toisaalta keskimäärin noin kaksinkertainen ja VMware Serverin viive yli kolminkertainen natiiviin järjestelmään verrattuna. Läpäisyn osalta tulokset olivat hieman erilaisia. Xen suoriutui erittäin hyvin, sen läpäisyn ollessa 94.5% natiiviin verrattuna. OpenVZ ja VMware Server suoriutuivat toisaalta huomattavan huonosti, 35.3% ja 25.9% läpäisyillä vastaavasti. Morabito et al. ajoivat testinsä käyttämällä sekä TCP- että UDP-protokollia (User Datagram Protocol) ja mitaten verkkopyyntöjen ja -vastausten viivettä sekä kaistanleveyttä. Sekä LXC:n että Dockerin mittaustulokset olivat melko samanlaisia verkkopyyntöjen ja -vastausten osalta. TCP:tä käytettäessä viive oli vajaa 20% huonompi natiiviin järjestelmään verrattuna, ja UDP:n osalta luku oli reilu 10%. 47

53 LXC suoriutui kummastakin testistä hieman Dockeria paremmin. KVM:n läpäisy oli toisaalta yli 45% natiivia huonompi kummankin protokollan tapauksessa. TCP:n kaistanleveyttä mitattaessa, kummatkin LXC ja Docker suoriutuivat käytännössä natiivin järjestelmän tasolla, mutta KVM:n suorituskyky oli reilu 28% huonompi. UDP:n kaistanleveyttä mitattaessa tulokset olivat huomattavan erilaisia LXC:n ja Dockerin osalta, kummankin suoriutuen reilu 42% natiivia huonommin. KVM:n vastaava luku oli reilu 54%. Morabito et al. huomauttavat että lähetysten pituus saattoi vaikuttaa näihin testituloksiin eritoten UDP:n osalta. Felter et al. testasivat eri virtualisointityökalujen prosessorin käyttöä suuria datamääriä siirrettäessä TCP-protokollan avulla sekä lähetyksen että vastaanoton kannalta. Tämän avulla voidaan päätellä miten paljon työkalut joutuvat tekemään työtä voidakseen käyttää verkkoa. Dockerin prosessorien käyttöaste oli noin 20% suurempi natiiviin järjestelmään verrattuna, kun KVM:n kohdalla luku oli alle 10%. Datan vastaanoton osalta, Dockerin prosessorin käyttöaste oli vajaa 20% natiivia suurempi, ja KVM:llä noin kolmasosan suurempi. Felter et al. mittasivat myös verkkopyyntöjen ja -vastausten viivettä TCP- ja UDP-protokollia käyttäen. Näissä Dockerin viive oli yli 100% suurempi kumpaakin protokollaa käytettäessä, ja KVM:n vastaava luku oli noin 80%. Morabito et al. tavoin, Ramalho & Neto mittasivat sekä verkkopyyntöjen ja -vastausten viivettä että kaistanleveyttä, joskin melko erilaisilla tuloksilla. Sekä TCP:n että UDP:n suorituskyky oli verkkopyyntöjen ja -vastausten osalta reilu 44% natiivia huonompi Dockeria osalta, ja jopa 80%-90% natiivia huonompi KVM:ää käytettäessä. Kaistanleveyttä testattaessa, Docker suoriutui lähes natiivin tasolla, ja KVM:n tulokset olivat noin 23% ja 18% natiivia huonompia TCP:llä ja UDP:llä, vastaavasti. Shirinbab et al. mittasivat työkalujen viivettä erilaisilla työkuormilla datan eri replikaatioasteille. Dockerin viiveet olivat pääosin samalla tasolla natiivin järjestelmän kanssa. Myös VMware ESXi suoriutui pääosin hyvin luku- ja kirjoituskuormista, mutta mielenkiintoisesti sekakuormien kohdalla sen viiveet olivat huonoimmillaan yli 250% natiivia suurempia. 48

54 Lopuksi, Li et al. mittasivat vain datan lähettämistä läpäisyn osalta. Heidän tuloksissaan Docker suoriutui lähes natiivin järjestelmän tasolla, ollen keskimäärin vain 2% natiivia hitaampi. Dockerin lähetysnopeus saattoi tosin vaihdella lähetyksen aikana yli 50% natiivin järjestelmän lähetysnopeuteen verrattuna. VMware Workstationin kohdalla luvut olivat huomattavasti suuremmat, 55% ja noin 130% vastaavasti. Li et al. huomauttavat, että he lähettivät dataa AWS:n EC2 -pilvipalveluun, joka saattoi vaikuttaa tuloksiin, esimerkiksi jos pilvessä oli paljon kilpailua resursseista. Verkon suorituskyvyn mittaustulokset heittelivät huomattavasti muita suorituskyvyn osa-alueiden mittaustuloksia enemmän, ollen myös keskenään melko ristiriitaisia. Kuten levyä testatessa, myös verkon suorituskyvyn testeissä virtualisointityökalujen ajoasetukset voivat vaikuttaa tuloksiin huomattavasti. Esimerkiksi Felter et al. huomauttavat että he ajoivat testinsä käyttämällä verkon osoitteenmuutosta (Network Addess Translation, NAT) Dockerilla, joka voi olla melko raskasta. He myös mainitsevat, että ilman osoitteenmuutosta Docker suoriutui testeistä käytännössä natiivin tasolla. Felter et al. mukaan viime vuosina on lisäksi tutkittu paljon sitä, miten hypervisoreiden verkon käyttöä voidaan nopeuttaa muun muassa ohittamalla hypervisor kokonaan joissain tapauksissa, ja he uskovatin esimerkiksi KVM:n hyvän lähetysnopeuden testissään olevan tämän ansiota. 49

55 5 Suorituskykymittauksia Tässä luvussa esitellään kirjoittajan tekemien suorituskykytestien tuloksia eri virtualisointityökaluilla. Testit on tehty pitkälti edellisessä luvussa esiteltyjen testien kaavalla ja jaettu samoihin osa-alueisiin: prosessorin, muistin, levyn ja verkon suorituskykyihin. Perinteisten suorituskykytestien lisäksi tässä tutkielmassa esitellään myös oikeaa (joskin yksinkertaista) verkkopalvelua simuloivan järjestelmän suorituskykyä. Lisäksi, toisin kuin muissa esitellyissä tutkielmissa, jotka eivät juuri ottaneet kantaa eri virtualisointityökalujen käytettävyyteen, tässä tutkielmassa vertaillaan myös hieman eri työkalujen käytettävyyttä. Vertailujen lähtökohtana on isäntäkoneen natiivin järjestelmän tulokset. Isäntäkone on Dell XPS seuraavalla laitteistolla: Intel i7-7560u 2.40GHz -kaksiydinprosessori neljällä säikeellä ja 4 MB:n L3 välimuistilla 16 GB keskusmuistia 1866MHz -taajuudella 512 GB SSD -kovalevy PCIe -tiedonsiirtoväylällä 100 Mb/s verkkorajapinta Testattavat virtualisointityökalut ovat: Docker versio (Community Edition) LXC versio ja LXD versio 3.6 KVM+QEMU versio Sekä isäntäkoneella, konteilla että KVM:n luomassa virtuaalikoneella ajettiin Ubuntu käyttöjärjestelmän 64 bittistä versiota. Kernelin versio isäntäkoneella (ja täten myös konteissa) oli ja KVM-virtuaalikoneella Konttien ja virtuaalikoneen käyttämän laitteiston yksityiskohdat ja niiden suorituskykyä testaavat työkalut käydään tarkemmin läpi kuhunkin suorituskyvyn osa-alueeseen keskittyvässä kohdassa. 50

56 Virtualisointityökalujen valinta perustui suurelta osin niiden saamin hyviin tuloksiin esitellyissä ja muissa suorituskykyvertailuissa. KVM ja LXC/LXD ovat erityisen kiinnostavia. KVM:n tulokset ovat parantuneet tasaisesti vuosien varrella ja se on alkanut jo haastaa konttipohjaisten työkalujen suorituskykyä. Esitellyistä tutkimuksista vain Morabito et al. (2015) käytti LXC:tä testeissään, ja se suoriutui monista testeistä esimerkiksi Dockeria paremmin. Se ei kuitenkaan ole koskaan saavuttanut Dockerin tasoista suosiota, joka lienee johtunut suurelta osin siitä, että se on alemman tason työkalu ja siten Dockeria vaikeakäyttöisempi. LXD kehitettiin osittain juuri käytettävyyden parantamiseksi. Tutkielmassa oli lisäksi tarkoitus testata Xeniä, mutta Xen ei toimi kunnolla isäntäkoneen käyttämän UEFI-rajapinnan (Unified Extensible Firmware Interface) kanssa. Vaikka Xenin saa asennettua ja käynnistettyä, se käynnistää koko järjestelmän uudelleen muutaman minuutin kuluttua, minkä vuoksi Xen jouduttiin jättämään vertailun ulkopuolelle. Kohdissa käydään läpi prosessorin, muistin, levyn ja verkon suorituskykytestien tuloksia tässä järjestyksessä. Kohdassa 5.5 puolestaan esitellään testattava verkkopalvelu ja sen eri osat sekä sen suorituskykytestien tulokset. Kohdassa 5.6 vertaillaan eri virtualisointityökalujen käytettävyyttä. Lopuksi, kohdassa 5.7 analysoidaan testien tuloksia ja havaintoja. 5.1 Prosessorin suorituskyky Prosessorin suorituskykyä testattaessa kumpaakin konttia ja virtuaalikonetta ajettiin mahdollisimman lähellä natiivin järjestelmän asetuksia. Käytännössä tämä tarkoittaa että Docker- ja LXC/LXD-kontteja ajettiin oletusasetuksilla, ja KVM-virtuaalikone kopioi isäntäkoneen prosessorin asetukset. Suorituskykytestit ajettiin kolmella eri ohjelmistolla: Geekbench 4:llä ( Linpackillä ( ja Hardinfolla 51

57 ( Kukin testi ajettiin 10 kertaa, ja tässä esitellään tulosten keskiarvot ja keskihajonnat. Geekbench testit pyrkivät mallintamaan reaalimaailman tehtäviä synteettisten testien sijaan. Se ajaa 25 eri testiä sekä yhdellä että usealla prosessorilla. Testit vaihtelevat AES-salauksesta HTML5:n jäsennykseen ja puheen tunnistukseen. Tulokset on jaettu neljään eri kategoriaan: kryptoon, kokonaisluku- ja liukulukulaskentaan sekä muistiin. Tässä esitellään näiden laajempien kategorioiden tulokset. Testien tulokset ilmoitetaan abstrakteina pisteinä, joissa suurempi luku on parempi tulos. Kaavio 1. Geekbench yhden prosessorin testitulokset. Kaavio 1: Geekbench yhden prosessorin testitulokset. Kaavio 2. Geekbench usean prosessorin testitulokset. 52

58 Taulukko 1. Geekbench yhden prosessorin testitulosten keskihajonta. Kategori Natiivi Docker LXC/LXD KVM Krypto 27,7 (0,9%) 20,2 (0,6%) 69,8 (2,2%) 57,1 (1,8%) Kokonaisluku 19,4 (0,3%) 24,6 (0,5%) 78,3 (1,5%) 139,4 (2,8%) Liukuluku 18,1 (0,4%) 25,5 (0,5%) 17,5 (0,4%) 116,5 (2,5%) Muisti 65,7 (1,7%) 82,7 (2,1%) 59,1 (1,5%) 69,6 (1,9%) Taulukko 2. Geekbench usean prosessorin testitulosten keskihajonta. Kategoria Natiivi Docker LXC/LXD KVM Krypro 7,3 (0,0%) 17,6 (0,2%) 77,3 (0,8%) 331,2 (3,3%) Kokonaisluku 115,0 (1,0%) 101,5 (0,9%) 105,4 (0.9%) 398,4 (3,6%) Liukuluku 160,4 (1,5%) 126,4 (1,2%) 158,9 (1,5%) 571,2 (5,9%) Muisti 15,6 (0,3%) 8,2 (0,2%) 9,0 (0,2%) 52,6 (1,9%) Kaavioissa 1 ja 2 esitellään Geekbench-testien tuloksien keskiarvot, sekä huonoimman ja parhaimman tuloksen välisen hajonnan. Taulukoissa 1 ja 2 esitellään testien keskihajonnat. Tulokset ovat melko samansuuntaisia monien muiden tutkimusten kanssa. Docker ja LXC suoriutuivat käytännössä natiivin tasolla jokaisesta testistä, KVM:n suoriutuen hieman heikommin. Ainoa huomattava poikkeus on KVM:n usean prosessorin muistitestien kohdalla, joiden tulos on noin 38% natiivin järjestelmän tuloksia huonompi ja jopa KVM:n yhden prosessorin muistitestien tuloksia huonompi. Felter et al. (2016) huomauttavat että KVM saattaa vaihtaa virtuaaliprosessorien ja virtuaalisen muistin fyysisiä vastineita itsekseen, joka voi selittää tämän tuloksen. Myös tulosten keskihajonnat ovat melko pieniä. KVM:n 53

59 keskihajonnat ovat keskimäärin hieman, mutteivat merkittävästi, muita alustoja suurempia. Hardinfo ajaa kuusi eri testiä, jotka mittaavat prosessorin nopeutta eri algoritmien suorittamisessa. Viisi testeistä ilmoittaa tulokset algoritmin suoritukseen kuluneessa ajassa, joten pienempi tulos on parempi. Yksi testeistä ilmoittaa tuloksen algoritmin suorittamisen nopeutena mebitavuissa sekunnissa, joten suurempi tulos on parempi. Kaavio 3. Hardinfo testituloksia. Kaavio 3: Hardinfo testituloksia. Kaavio 4. Hardinfon CryptoHash testitulokset. 54

60 Taulukko 3. Hardinfo testiulosten keskihajonta. Testi Natiivi Docker LXC/LXD KVM CPU Fibonacci 0,16s (12,2%) 0,03s (2,4%) 0,14s (11,7%) 0,22s (16,6%) CPU Blowfish 0,25s (9,9%) 0,14s (5,6%) 0,22s (8,8%) 0,12s (4,8%) CPU N-Queens 0,22s (5,1%) 0,25s (5,7%) 0,39s (8,7%) 0,32s (7,1%) CPU CryptoHash 67.0 MiB/s 36,6 MiB/s 60,1 MiB/s 28,3 MiB/s (14,9%) (7,5%) (13,3%) (6,1%) FPU FFT 0,01s (1,9%) 0,02s (2,8%) 0,02s (2,4%) 0,10s (12,9%) FPU Raytracing 0,22s (5,9%) 0,31s (8,1%) 0,37s (9,6%) 0,45% (11,5%) Kaavioissa 3 ja 4 esitetään Hardinfo testien tulokset, ja taulukossa 3 testitulosten keskihajonta. Tulokset ovat hieman mielenkiintoisempia kuin Geekbenchin testitulokset. Joskin kaikkiaan tulokset ovat jälleen melko lähellä toisiaan, esimerkiksi Docker suoriutui kaikista paitsi yhdestä testistä (FPU Raytracing) parhaiten, jopa natiivia järjestelmää paremmin. Lisäksi testiajojen tulosten keskihajonta on huomattavaa, ollen useissa testeissä yli 10%. Yksi mahdollinen syy tähän voi olla, että testit ovat niin nopeita ajaa, että lyhytkestoisetkin ulkoiset tekijät voivat vaikuttaa tuloksiin huomattavasti. Myös testien toteutus voi vaikuttaa niiden tulosten samankaltaisuuteen ajojen välillä. Jälleen on tosin nähtävissä, että KVM suoriutuu keskimäärin hieman muita alustoja heikommin. Linpack on alun perin 70-luvulla kehitetty ohjelmisto supertietokoneiden suorituskyvyn mittaamiseen, joskin nykyään sillä voi testata myös henkilökohtaisten ja palvelin koneiden suorituskykyä. Näissä testeissä käytettiin Intelin Math Kernel Libraryyn (2018, päivitys 3) pohjautuvaa versiota, joka optimoi itseään alustan ja saatavilla olevien resurssien mukaan. Linpack laskee erikokoisia lineaarisia yhtälöitä, keskittyen pitkälti liukulukulaskentaan ja ilmoittaa järjestelmän laskunopeuden. 55

61 Tulokset ilmoitetaan GFlopseissa (tuhansissa liukulukuoperaatioissa sekunnissa), ja suurempi tulos on parempi. Kaavio 5. Kaavio 5: Linpack testitulokset. Taulukko 4. Linpack testitulosten keskihajonta. Yhtälön koko Natiivi Docker LCX/LXD KVM GFlop/s 5.50 GFlop/s 8.05 GFlop/s GFlop/s (20.8%) (7.9%) (11.8%) (81.3%) GFlop/s 4.15 GFlop/s 6.41 GFlop/s 3.19 GFlop/s (4.0%) (5.0%) (7.5%) (5.0%) GFlop/s 6.95 GFlop/s 2.53 GFlop/s 4.14 GFlop/s (3.4%) (9.5%) (3.3%) (5.9%) GFlop/s 2.86 GFlop/s 1.89 GFlop/s 2.97 GFlop/s (2.0%) (3.8%) (2.5%) (4.3%) GFlop/s 0.92 GFlop/s 0.66 GFlop/s 0.45 GFlop/s (1.5%) (1.2%) (0.8%) (0.6%) 56

62 GFlop/s 0.45 GFlop/s 0.43 GFlop/s 0.82 GFlop/s (0.9%) (0.6%) (0.5%) (1.1%) GFlop/s 0.57 GFlop/s 1.18 GFlop/s 1.98 GFlop/s (0.6%) (0.7%) (1.5%) (2.6%) GFlop/s 0.53 GFlop/s 0.45 GFlop/s 0.35 GFlop/s (0.9%) (0.7%) (0.5%) (0.5%) GFlop/s 0.35 GFlop/s 0.42 GFlop/s 0.29 GFlop/s (0.8%) (0.4%) (0.5%) (0.4%) Kaaviossa 5 ja taulukossa 4 esitetään Linpackin testitulokset ja tulosten keskihajonnat. Tulokset ovat melko yhdenmukaisia Geekbench- ja Hardinfo-tulosten kanssa. Kontit ja natiivi suoriutuivat testeistä yleisesti ottaen samalla tasolla, KVM:n suoriutuessa jälleen hieman muita heikommin. Tuloksista ja keskihajonnoista on huomattavissa, että tulosten hajonnat pienenevät ja tulokset lähentyvät toisiaan yhtälöiden kokojen kasvaessa. Yhtälön koon ollessa 1000, testin suoritusaika lasketaan sekunnin sadasosissa, joka voi tehdä tuloksista hieman epäluotettavia. Lisäksi välimuisti voi vaikuttaa eritoten pienten testikokojen tuloksiin. Toisaalta, koon ollessa 40000, yhden testin ajaminen kestää yli 10 minuuttia, mutta tulosten keskihajonnat ovat jokaisella alustalla alle yhden prosentin. Tämä vaikuttaisi vahvistan Hardinfo-testitulosten esittelyssä tehtyä olettamusta siitä, että lyhytkestoiset testit ovat alttiita ulkoisille häiriöille tai muille tuloksiin vaikuttaville tekijöille. 5.2 Muistin suorituskyky Muistin suorituskykyä mitattaessa konttien ja virtuaalikoneen muisteja ei rajoitettu millään tavalla, vaan niillä oli tarvittaessa koko isäntäkoneen muisti käytössään. Suorituskykyä mitattiin kahdella eri työkalulla: jatkuvaa luku- ja kirjoitusnopeutta mittaavalla STREAMilla ( ja satunnaissaannin 57

63 viivettä mittaavalla tinymembenchillä ( Kuten edellisessä kohdissa, kukin testi ajettiin 10 kertaa, ja tässä esitellään tulosten keskiarvot ja keskihajonnat. Taulukko 5. STREAM testit. Operaatio Ydin Tavua/iteraatio FLOPia/iteraatio Kopio a(i) = b(i) 16 0 Skaala a(i) = q*b(i) 16 1 Summa a(i) = b(i) + c(i) 24 1 Kolmikko a(i) = b(i) + q*c(i) 24 2 STREAM mittaa muistin jatkuvaa luku- ja kirjoitusnopeutta suorittamalla yksinkertaisia laskuja vektoreilla. Operaatiot esitellään taulukossa 5. Testit ajettiin yhden, että usean prosessorin tilassa, käyttämällä kahta säiettä jälkimmäisessä. Tulokset ovat megatavuissa sekunnissa, joten suurempi tulos on parempi. Kaavio 6. STREAM yhden prosessorin testitulokset 58

64 Kaavio 7. STREAM usean prosessorin testitulokset. Taulukko 6. STREAM yhden prosessorin testitulosten keskihajonta. Operaatio Natiivi Docker LXC/LXD KVM Kopio 538,9 MB/s 467,7 MB/s 709,4 MB/s 814 MB/s (3,2%) (2,8%) (4,2%) (5,1%) Skaala 404,8 MB/s 433,7 MB/s 311 MB/s 192,5 MB/s (4,4%) (4,6%) (3,4%) (2%) Summa 465,5 MB/s 460,3 MB/s 416,3 MB/s 745,5 MB/s (2,7%) (2,7%) (2,5%) (4,7%) Kolmikko 60,4 MB/s 639,4 MB/s 87,1 MB/s 669,5 MB/s (0,6%) (6,3%) (0,9%) (6,5%) 59

65 Taulukko 7. STREAM usean prosessorin testitulosten keskihajonta. Operaatio Natiivi Docker LXC/LXD KVM Kopio 39,9 MB/s 34,9 MB/s 30 MB/s (0,2%) 81,7 MB/s (0,3%) (0,2%) (0,5%) Skaala 67,3 MB/s 147,1 MB/s 44,2 MB/s 82,3 MB/s (0,4%) (0,8%) (0,3%) (0,5%) Summa 57,6 MB/s 263 MB/s 47 MB/s (0,3%) 76,5 MB/s (0,3%) (1,4%) (0,4%) Kolmikko 45,4 MB/s 86,7 MB/s 71.3 MB/s 94,7 MB/s (0,3%) (0,6%) (0,5%) (0,6%) Kaavioissa 6 ja 7 näytetään STREAM testien tulokset, ja taulukoissa 6 ja 7 testitulosten keskihajonnat. Tuloksilla ei ole merkittävää eroa keskenään, joskin eritoten yhden prosessorin tuloksissa on mielenkiintoista huomata, että kahdessa testissä natiivi ja LXC/LXD suoriutuivat parhaiten, ja kahdessa testissä puolestaan Docker ja KVM. Usean prosessorin testeissä tulokset olivat huomattavasti tasaisemmat, konttien ja natiivin järjestelmän tulosten ollessa lähes tasoissa, KVM:n suoriutuessa hieman heikommin. On huomattavaa myös, että yhden prosessorin tulosten keskihajonnat olivat huomattavasti suurempia usean prosessorin tuloksiin verrattuna. Myös Felter et al. (2016), Morabito et al. (2015) ja Ramalho & Neto (2016) käyttivät tutkielmissaan STREAMia, ja kaikki raportoivat tulosten olevan hyvin lähellä toisiaan alustasta riippumatta. Näistä voi tehdä johtopäätöksen, että yhden prosessorin testien tuloksissa lienee pieniä mittausvirheitä. Tinymembenchillä voidaan mitata sekä muistin jatkuvaa luku- ja kirjoitusnopeutta että satunnaissaannin nopeutta. Tässä tutkielmassa sillä mitattiin vain satunnaissaannin nopeutta, sillä STREAM on tunnetuin ja käytetyin työkalu jatkuvan luku- ja kirjoitusnopeuden mittaamiseen. Tinymembench mittaa satunnaissaannin 60

66 nopeutta lukemalla eri kokoisia puskureita ja mittaamalla lukuajan. Lukuja tehdään sekä yksi kerrallaan että kaksi kerrallaan. Lisäksi testit ajetaan sekä MADV_HUGEPAGE- että MADV_NOHUGEPAGE-tiloissa. Nämä ottavat käyttöön tai käytöstä Transparent Huge Page (TPH) -toiminallisuuden, joka suurentaa muistisivujen kokoa ja voi auttaa muistin suorituskyvyssä, kun muistia on paljon käytössä (Linux Programmer s Manual, madvise, 2018). Tässä näytetään vain MADV_HUGEPAGE-tilan tulokset sillä kummankin tilat tulokset olivat lähes identtiset. Testien tulokset ilmoitetaan nanosekunneissa, ja pienempi tulos on parempi. Kaavio 8. Tinymembench MADV_HUGEPAGE testitulokset. Kaaviossa 8 ja taulukossa 8 (seuraavalla sivulla) esitellään tinymembench:n testitulokset MADV_HUGEPAGE -tilassa. Kaaviossa näkyvän yhtäkkisen nousun neljän megatavun kohdalla voidaan selittää prosessorin välimuistin loppumisella. Kaikki kahden luvun ajat nousevat jyrkemmin kuin yhden luvun ajat. Koska tulokset ovat niin samankaltaisia keskenään, kaavion kuvaajat menevät päällekkäin. Tuloksista näkee, etteivät ainakaan tässä testatut virtualisointityökalut vaikuta satunnaissaannin nopeuteen, vaan tulokset ovat lähes identtiset alustasta riippumatta. Tulos on yhdenmukainen esimerkiksi Felter et al. (2016) satunnaissaannin testitulosten kanssa. 61

67 Taulukko 8. Tinymembench MADV_HUGEPAGE testitulosten keskihajonta. Puskurin Natiivi 1 Natiivi Docker Docker LXC 1 LXC 2 KVM 1 KVM 2 koko luku 2 lukua 1 luku 2 lukua luku lukua luku lukua ns (0%) 0ns 0ns 0ns 0ns 0ns 0ns 0ns (0%) (0%) (0%) (0%) (0%) (0%) (0%) ns (0%) 0ns 0,0ns 0,1ns 0ns 0ns 0ns 0ns (0%) (2,1%) (1,7%) (0%) (0%) (0%) (0%) ns (0%) 0ns 0,0ns 0,1ns 0ns 0ns 0ns 0ns (0%) (1,9%) (1,7%) (1,9%) (1,7%) (0%) (0%) ns (0%) 0ns 0,1ns 0,1ns 0ns 0,0ns 0ns 0ns (0%) (1,4%) (1%) (0,9% (0,7%) (0%) (0%) ns (0%) 0ns 0,1ns 0,1ns 0ns 0,0ns 0ns 0ns (0%) (1,7%) (1,4%) (0,5%) (0,4%) (0%) (0%) ,2ns 0,1ns 0,2ns 0,2ns 0ns 0,0ns 0ns 0ns (2,1%) (1,9%) (2,8%) (2,5%) (0,4%) (0,4%) (0%) (0%) ,9ns 1,0ns 0,9ns 1,2ns 0,1ns 0,2ns 0,1ns 0,2ns (10,1%) (9,2%) (10,4%) (9,4%) (1,3%) (1,2%) (1,1%) (1%) ,8ns 4,6ns 0,4ns 0,2ns 0,5ns 1,6ns 0,5ns 0,3ns (4,7%) (3,3%) (0,7%) (0,5%) (0,8%) (0,6%) (0,9%) (0,6%) ,7ns 5,8ns 0,2ns 0,2ns 4,6ns 6,7ns 3,6ns 2,4ns (3,3%) (2,5%) (0,2%) (0,2%) (5,6%) (4,3%) (4,4%) (3,3%) ,1ns 0,4ns 0,1ns 0,1ns 0ns 0,7ns 1,6ns 1,1ns (0,1%) (0,1%) (0,1%) (0,1%) (0,1%) (0%) (1,7%) (1,4%) ,1ns 1,2ns 0,3ns 0,5ns 0,2ns 0,2ns 1,2ns 1,2ns (0,1%) (0,1%) (0,3%) (0,2%) (0,2%) (0,1%) (1,2%) (1%) 62

68 5.3 Levyn suorituskyky Levyn suorituskyvyn mittaaminen eri virtualisointitekniikoiden välillä on hieman hankalaa, sillä erilaisia muuttujia on todella paljon. Esimerkiksi käyttöjärjestelmä, tiedostojärjestelmä ja tiedostolohkojen koko voivat kaikki vaikuttaa tuloksiin. Eri muuttujat voivat myös vaikuttaa eri testityökaluihin eri tavoilla. Muuttujien minimoimiseksi konttien ja virtuaalikoneen ympäristöt pyrittiin saamaan mahdollisimman samanlaisiksi. Natiivin järjestelmän tiedostojärjestelmä oli ext4 (fourth extended file system). Docker-kontin testit ajettiin konttiin liitetyllä loogisella levyllä käyttäen local-ajuria. Tämä on Dockerin suosittelema tekniikka, jos data halutaan pitää kontin eliniän jälkeen. LXC/LXD-konttia ajettiin dir-ajurilla, joka kiinnittää isäntäjärjestelmän kansion konttiin. Vaikka tämä mahdollistaa isäntäjärjestelmän tiedostojärjestelmän käytön, se on LXD:n mukaan huonoin vaihtoehto kontin tiedostojärjestelmäksi, sillä se ei tue esimerkiksi konttien kopioimista. Suositetuilla btrfs- tai ZFS-tiedostojärjestelmillä tulokset eivät kuitenkaan olisi olleet vertailukelpoisia. Lopuksi, KVM:lle luotiin oma fyysinen osio, jolle asennettiin looginen levy lvm2:n (Logical Volume Mapper) avulla. Itse virtuaalikoneen sisällä loogisen levyn tiedostojärjestelmänä oli myös ext4. Ajurina käytettiin VirtIO:ta. Testit ajettiin fio- (flexible I/O tester, ja bonnie++ ( -työkaluilla. Edellisten kohtien testien mukaisesti, kukin testi ajettiin 10 kertaa, ja tässä esitellään tulosten keskiarvot ja -hajonnat. Fiolla voidaan mitata levyn suoritustehoa kirjoittamalla ja/tai lukemalla tiedostoja. Tiedostoja voi lukea ja kirjoittaa lohkoittain peräkkäisesti tai satunnaisessa järjestyksessä. Lisäksi fiolla on mahdollista säätää esimerkiksi tiedostolohkojen kokoa, testitiedostojen kokoa, testaavien prosessien määrää sekä monia muita muuttujia. Tässä tutkielmassa sekä lukua että kirjoitusta testattiin itsekseen ja sekaisin käymällä testitiedostoa läpi sekä peräkkäisessä järjestyksessä että satunnaisesti. Lukiessa ja kirjoittaessa sekaisin, testin ajoajasta 70% käytettiin lukemiseen ja 30% kirjoittamiseen. Testitiedoston koko oli 16 gigatavua ja jokainen 63

69 testi käytti 512 tavun, neljän kilotavun, kahdeksan kilotavun ja 64 kilotavun tiedostolohkokokoja, kutakin neljäsosan ajoajastaan. Tämän vuoksi testitulokset antavat hyvän yleiskuvan levyn suorituskyvystä eri käyttötarkoituksia varten, lohkokoosta riippumatta. Tulokset ilmoitetaan nopeutena megatavuissa sekunnissa, joten suurempi tulos on parempi. Kaavio 9. Fio testitulokset. Taulukko 9. Fio testitulosten selitteet. Testi Per. luku Per. kirj. Per. luku/kirj. luku Per. luku/kirj. kirj. Sat. luku Selite Peräkkäinen luku Peräkkäinen kirjoitus Peräkkäisen luvun ja kirjoituksen lukuosuus Peräkkäisen luvun ja kirjoituksen kirjoitusouus Satunnainen luku 64

70 Sat. kirj. Sat. luku/kirj. lukua Sat. luku/kirj. kirj. Satunnainen kirjoitus. Satunnaisen luvun ja kirjoituksen lukuosuus Satunnaisen luvun ja kirjoituksen kirjoitusouus Taulukko 10. Fio testitulosten keskihajonta. Testi Natiivi Docker LXC/LXD KVM Per. luku 18,09 MB/s 9,18 MB/s 44,65 MB/s 61,12 MB/s (1,5%) (0,7%) (3,6%) (5,9%) Per. kirj. 8,45 MB/s 10,33 MB/s 15,16 MB/s 17,73 MB/s (4,0%) (6,3%) (7,7%) (11,1%) Per. luku/kirj. 25,63 MB/s 20,43 MB/s 24,41 MB/s 15,09 MB/s luku (7,1%) (6,6%) (7,2%) (6,1%) Per. luku/kirj. 11 MB/s (7,1%) 8,77 MB/s 10,48 MB/s 6,48 MB/s kirj. (6,6%) (7,2%) (6,1%) Sat. luku 27,08 MB/s 12,78 MB/s 24,37 MB/s 37,54 MB/s (3,6%) (1,6%) (3,2%) (5,8%) Sat. kirj. 3,25 MB/s 2,71 MB/s 2,77 MB/s 2,42 MB/s (3,3%) (3,0%) (2,8%) (2,9%) Sat. luku/kirj. 8,32 MB/s 7,16 MB/s 5,48 MB/s 2,61 MB/s lukua (4,7%) (4,3%) (3,0%) (1,8%) Sat. luku/kirj. 3,57 MB/s 3,07 MB/s 2,35 MB/s 1,12 MB/s kirj. (4,7%) (4,3%) (3,0%) (1,8%) 65

71 Kaaviossa 9 esitellään fio-testien testitulokset, taulukossa 9 käytetyt lyhenteet ja taulukossa 10 tulosten keskihajonnat. Tulokset jatkavat melko tutulla linjalla, KVM:n suoriutuen muita alustoja jonkin verran huonommin, joka oli odotettavissa edellisessä luvussa esiteltyjen testien tuloksien perusteella. On tosin huomattava, että myös Docker suoriutui peräkkäisestä kirjoituksesta ja luvun ja kirjoituksen sekoituksesta hieman natiivia järjestelmää ja LXC/LXD-konttia huonommin, joka on outoa sillä konttiin kiinnitetyn loogisen levyn ei pitäisi olla juurikaan natiivia järjestelmää hitaampi. Kuten luvussa neljä todettiin, esimerkiksi Felter et al. (2016) käyttivät testeissään loogista levyä, ja Dockerin tulokset olivat identtiset natiivin järjestelmän tulosten kanssa. Heikompia tuloksia saaneet Docker-kontit käyttivät pääosin AUFS-tiedostojärjestelmää. Toisaalta myös bonnie++:n kirjoitus- ja lukutestit antoivat Dockerille noin 10% huonompia tuloksia natiiviin järjestelmään verrattuna pienillä lohkokoilla, jonka lisäksi myös LXC/LXD-kontti kärsi huonommasta suorituskyvystä samoissa testeissä. Tämä viittaa siihen, että konttien levyn suoritusteho voi kärsiä tehtävissä, joissa käytetään pieniä lohkokokoja, joka noteerattiin myös Li et al. (2017) tutkimuksessa. Olettamusta olisi kuitenkin hyvä tutkia tarkemmin. Bonnie++ mittaa levyn suorituskykyä fion tapaan kirjoittamalla ja lukemalla merkkejä (character, oletettavasti tavuja) ja lohkoja tiedostoon sekä peräkkäisessä järjestyksessä että satunnaisesti, ja luomalla, lukemalla ja poistamalla pieniä tiedostoja niin ikään peräkkäisesti ja satunnaisesti. Koska tiedoston lukeminen ja kirjoittaminen testattiin jo fiolla, tässä ei noiden testien tuloksia esitellä tarkemmin. Todettakoon kuitenkin, että tulokset olivat muilta osin samansuuntaiset kuin fiolla, lukuun ottamatta LXC/LXD-konttia, joka suoriutui hieman heikommin kuin fiotesteissä. Mielenkiintoisesti, LXC/LXC-kontin tulokset olivat lähes identtisiä Dockerin kanssa. Tulokset ilmoitetaan operaatioina sekunnissa, ja suurempi tulos on parempi. 66

72 Taulukko 11. Bonnie++ testitulosten selitteet. Testi Selite Per. tied. luon. Tiedostojen luonti peräkkäisessä järjestyksessä. Per. tied. luku Tiedostojen luku peräkkäisessä järjestyksessä. Per. tied. pois. Tiedostojen poisto peräkkäisessä järjestyksessä. Sat. tied. luon. Tiedostojen luonti satunnaisessa järjestyksessä. Sat. tied. luku Tiedostojen luku satunnaisessa järjestyksessä. Sat. tied. pois. Tiedostojen poisto satunnaisessa järjestyksessä. Kaavio 10. Bonnie++ testituloset. 67

73 Taulukko 12. Bonnie++ testitulosten keskihajonnat. Testi Natiivi Docker LXC/LXD KVM Per. tied. luon. 2273,47 (4,5%) 1871,39 (3,7%) 1380,24 (2,8%) 10017,01 (34,9%) Per. tied. luku 5540,63 (0,7%) 4099,63 (0,7%) 5332,29 (0,9%) 5536,68 (0,8%) Per. tied. pois. 864,75 (2,4%) 1240,18 (3,5%) 799,94 (2,3%) 3883,96 (10,5%) Sat. tied. luon. 3109,07 (4,6%) 725,79 (1,1%) 1103,37 (1,6%) 3581,77 (5,1%) Sat. tied. luku 2347,56 (0,3%) 7725,90 (1,0% 9809,88 (1,3% 10044,06 (1,4%) Sat. tied. pois. 371,18 (1,8%) 199,60 (1,0%) 358,82 (1,8%) 1390,57 (5,9%) Kaaviossa 10 esitellään bonnie++:n testitulokset, ja taulukoissa 11 ja 12 niiden selitteet ja keskihajonnat. Lukuun ottamatta peräkkäisten tiedostojen luonti -testin tulosta, tulokset ovat hyvin yllättävät. Vaikka Docker ja LXC/LXD suoriutuvat keskenään samalla tavalla jokaisesta testistä, ovat niiden tulokset natiivia järjestelmää huomattavasti huonommat testeissä, joissa tiedostoja luetaan. Vielä yllättävämpi tulos on KVM:n suoriutuminen jopa natiivia järjestelmää paremmin kolmessa testissä, ja kontteja paremmin neljässä. Vaikka tulosten epätasaisuus ennen kaikkea KVM:n osalla voi viitata siihen, ettei testityökalu ole täysin luotettava, viittaavat bonnie++:n ja fion testitulokset myös siihen, ettei etenkään Docker ole vielä aivan natiivin järjestelmän tasolla levyn suorituskyvyn osalta. Toisaalta on myös huomattava, etteivät erot loppujen lopuksi ole kovin suuria. 68

74 5.4 Verkon suorituskyky Verkon suorituskykyä mitattiin kaistanleveyden ja yksinkertaisen pyyntö-vastaus -protokollan avulla. Luvun johdannossa mainittu kone toimi testeissä palvelimena, ja MacBook 2016 asiakaskoneena. Koneet oli yhdistetty samaan paikallisverkkoon. Virtualisointitekniikoita testattaessa palvelinkoneelle asennettiin NAT-säännöt, jotka ohjasivat palvelinkoneelle tulevan verkkoliikenteen eteenpäin virtuaalikoneelle ja konteille, ja niiltä tulevan liikenteen oikeaan osoitteeseen. Tämä aiheuttaa isäntäkoneelle hieman lisätöitä jokaista verkkopyyntöä kohden. Lisäksi, kaikki testit suoritettiin sekä TCP- että UDP-protokollia käyttäen. Protokollien erona on se, että TCP:ssä pyynnön vastaanottaja lähettää jokaiseen pyyntöön kuittauksen siitä, että sai sen. Jos lähettäjä ei saa kuittausta, lähettää se pyynnön uudelleen. UDP:ssa puolestaan lähettäjä ei välitä meneekö pyyntö perille, vaan lähettää seuraavan pyynnön joka tapauksessa. Kaistanleveystestit suoritettiin iperf3:lla ( ja pyyntö-vastaus -protokolla testattiin kirjoittajan itse tekemällä yksinkertaisella Python-skriptillä. Vaikka tähänkin löytyy valmiita testiohjelmistoja, kuten Netperf ( ne eivät toimineet täysin luotettavasti NATia käytettäessä. Kaistanleveystesteissä asiakaskone lähetti ensin 10 minuutin ajan dataa palvelimelle, jonka jälkeen palvelin lähetti dataa 10 minuutin ajan asiakkaalle. Kummassakin tapauksessa lähetysnopeus mitattiin sekunnin välein. Koska sekä asiakas- että palvelinkoneen verkkorajapinta oli 100 Mb/s, UDP-testeissä lähetysnopeus rajoitettiin manuaalisesti tuohon nopeuteen, mutta muuten liikennettä ei rajoitettu. Tulokset ilmoitetaan nopeutena megabiteissä sekunnissa, ja suurempi tulos on parempi. 69

75 Kaavio 11. iperf3 testitulokset. Taulukko 13. iperf3 testitulosten keskihajonnat. Testi Natiivi Docker LXC/LXD KVM TCP lähetys 5,41 Mb/s 5,62 Mb/s 5,55 Mb/s 5,65 Mb/s (5,8%) (6,0%) (5,9%) (6,0%) TCP vastaanotto 5,67 (6,1%) Mb/s 5,14 Mb/s 5,43 Mb/s 5,48 Mb/s (5,5%) (5,8%) (5,9%) UDP lähetys 0,01 Mb/s 0,00 Mb/s 0,00 Mb/s 0,19 Mb/s (0,0%) (0,0%) (0,0%) (0,2%) UDP vastaanotto 5,47 Mb/s 7,40 Mb/s 5,04 Mb/s 4,99 Mb/s (5,9%) (8,0%) (5,4%) (5,3%) Kaaviossa 11 esitellään kaistanleveystestien tulokset ja taulukossa 13 niiden keskihajonnat. UDP-lähetystestien tuloksista on mainittava, että vaikka iperf3 ilmoitti lähetysnopeudeksi teoreettisen ylärajan virtualisointityökaluja käytettäessä, ei oikea lähetysnopeus ollut niin korkea. Palvelin ilmoitti noin 6,4% pakettihävion virtualisointityökalujen testejä ajettaessa, joten tulokset ovat oikeasti suurinpirtein samoja natiivin järjestelmän kanssa. Joko isäntäkoneen verkkokerros tai itse 70

76 virtualisointityökalu lienee tiputti paketit, joita ei pystynyt käsittelemään, testityökalun tietämättä. Tulokset ovat käytännössä identtiset virtualisointitekniikasta riippumatta. Vaikka luvussa neljä esitellyissä tutkimuksissa virtualisointitekniikoiden tulokset eivät yleensä päässeet aivan natiivin järjestelmän tasolle, voitaneen nämä tulokset selittää virtualisointitekniikoiden kehityksellä. Esitellyissä tutkimuksissa voidaan havaita eritoten KVM:n tulosten parantuminen vuosien varrella. Lisäksi kaistanleveystesteissä erot eivät muissakaan tutkimuksissa olleet erityisen suuria etenkään konttien kohdalla. Vaikka verkkopyynnöt joudutaan ohjaamaan uudelleen NATin avulla, ei vain yhden asiakkaan verkkoliikenne välttämättä vaikuta suorituskykyyn merkittävästi. Koska NAT aiheuttaa lisää töitä prosessorille, voi sen käyttö olla huomattavissa suuremmissa verkkopalveluissa, jotka vastaanottavat tuhansia pyyntöjä sekunnissa. Lopuksi, kaaviossa 11 näkyy että TCP-testeissä sekä UDP-vastaanoton testissä hajonta on ollut melko suurta, mutta tämä johtunee paikallisverkon ongelmista eikä niinkään testityökalusta tai käytetystä virtualisointitekniikasta. Lisäksi, koska keskihajonta on melko pientä jokaisessa testissä, voitaneen eritoten hajonnan alarajat sivuuttaa tuloksia tarkastellessa. Pyyntö-vastaus -testissä asiakas lähetti palvelimelle 100 tavun pyynnön kertaa ja palvelin lähetti jokaiseen takaisin 100 tavun vastauksen, ja toimenpiteen kokonaisaika mitattiin (roundtrip latency). On huomautettava, että koska Python on korkean tason ohjelmointikieli, aiheuttaa se tietokoneelle hieman lisätöitä esimerkiksi C:llä toteutettavaan testityökaluun verrattuna. Koska testit ovat yksinkertaisia ja käyttävät melko matalan tason soketti-kirjastoa, ei tämän lisätyön määrän kuitenkaan pitäisi olla suuri. Lisäksi se on sama jokaiselle alustalle, joten tulokset ovat keskenään vertailukelpoisia. Tulosten absoluuttisia arvoja ei kuitenkaan välttämättä ole mielekästä verrata muiden työkalujen tuloksiin. Lähdekoodi on haluttaessa saatavilla kirjoittajalta. Tulokset ilmoitetaan yhden pyyntö-vastaus operaation kokonaisaikana millisekunneissa, joten pienempi tulos on parempi. 71

77 Kaavio 12. Pyyntö-vastaus testitulokset. Taulukko 14. Pyyntö-vastaus testitulosten keskihajonnat. Testi Natiivi Docker LXC/LXD KVM TCP 2,14 ms 1,02 ms 0,85 ms 2,24 ms (58,2%) (26,0%) (22,9%) (59,9%) UDP 0,56 ms 1,92 ms 1,95 ms 0,85 ms (17,7%) (58,8%) (59,2%) (23,7%) Kaaviossa 12 esitellään pyyntö-vastaus -testien tulokset ja taulukossa 14 niiden keskihajonnat. Tulokset ovat jälleen verrattain lähellä toisiaan, joka jälleen kertoo verkon virtualisointitekniikoiden verkon suorituskyvyn parantumisesta viime vuosien aikana. Toisaalta kuten kaistanleveyden tulosten kohdalla todettiin, erot lienee suurenisivat jos palvelimen pitäisi palvella tuhansia asiakkaita samaan aikaan, ja resursseja pitäisi käyttää enemmän esimerkiksi NATia varten. Keskihajonnat ovat verkkoprotokollasta ja alustasta riippumatta melko korkeita, joka voitaneen laskea osittain paikallisverkon mahdollisten väliaikaisten ongelmien syyksi edellisen testin tavoin. Lisäksi koska yksittäisessä pyynnössä ja vastauksessa menee niin vähän aikaa, ovat ajallisesti pienetkin erot hajonnan kannalta suuria. Keskihajonnoista on myös mielenkiintoista huomata, että konteilla TCP:n keskihajonta oli huomattavasti 72

78 natiivia järjestelmää ja virtuaalikonetta pienempi, kun taas UDP:n kohdalla tilanne oli päinvastainen. Tämän syyn selvittäminen vaatisi lisätutkimuksia. 5.5 Verkkopalvelun suorituskyky Tässä tutkielmassa testattiin lisäksi yksinkertaisen verkkopalvelun suorituskykyä. Verkkopalvelu on yksinkertainen autokauppa, josta voidaan hakea, lisätä, päivittää ja poistaa tietoa eri autoista. Lähdekoodi on saatavissa kirjoittajalta. Verkkopalvelu koostui neljästä kerroksesta: Nginx-verkko- ja välityspalvelin ( versio Nginx voi esimerkiksi suodattaa liikennettä ja ohjata sitä eri palveluille, tallentaa verkkopalveluiden vastauksia välimuistiin ja toimia kuormituksen tasapainottajana. Tässä verkkopalvelussa Nginx toimi välityspalvelimena. Python Django -verkkosovellus, Python versio 2.7 ja Django versio Python on monikäyttöinen korkean tason ohjelmointikieli, joka on erityisen suosittu verkkosovelluksia ohjelmoitaessa. Django ( on yksi suosituimmista Python-kirjastoista verkkosovelluksia varten, ja se tarjoaa myös ORM-kerroksen (Object Relational Mapping) datan siirtämiseen Python-ympäristön ja tietokannan välillä. Tässä verkkopalvelussa Djangolla toteutettiin palvelun ohjelmointirajapinta, jonka kanssa voi kommunikoida HTTP-protokollan avulla. Data siirretään JSON-muodossa (JavaScript Object Notation, Testissä verkkosovellusta ajettiin Gunicorn HTTP -palvelimen ( päällä. Gunicornin versio oli Ohjelmointirajapinta esitellään taulukossa 14. Redis-avain-arvo -tietokanta ( versio 5.0. Redistä voi käyttää esimerkiksi nopeana välimuistina, tietokantana tai viestien välittäjänä. Tässä verkkopalvelussa sitä käytettiin välimuistina, johon joidenkin HTTP-kutsujen vastauksia tallennettiin. Jos samaa tietoa haetaan useaan kertaan, se on huomattavasti nopeampaa hakea välimuistista kuin itse tietokannasta. 73

79 MySQL-tietokanta ( versio 5.6. MySQL on suosittu relaatiotietokanta. Tässä verkkopalvelussa siihen tallennettiin tietoa autoista ja niiden myyjistä. Taulukko 15. Verkkopalvelun ohjelmointirajapinta. HTTP metodi URL Selite GET /cars/?page= Palauttaa listan autoja. Page -parametria käytetään sivutukseen, ja yhden sivun koko on 20 autoa. POST /cars/ Luo uuden auton välitetyn JSON-kuorman perusteella. GET /cars/:id:/ Palauttaa yhden auton tunnisteella id. PUT /cars/:id:/ Päivittää yhden auton tietoja tunnisteella id JSON-kuorman perusteella. DELETE /cars/:id:/ Poistaa yhden auton tunnisteella id. Verkkopalvelun eri osat pidettiin tarkoituksella melko yksinkertaisina, sillä tässä testissä ei ollut tarkoitus mitata yksittäisten ohjelmistojen suorituskykyä, vaan miten ne toimivat yhdessä eri virtualisointialustoilla. Natiivilla järjestelmällä, LXC/LXDkontilla ja KVM:llä kaikkia ohjelmistoja ajettiin samalla alustalla, ja Dockerin tapauksessa kaikkia ajettiin omissa konteissaan. Testejä varten tietokantaan luotiin autoa ja myyjää satunnaisesti. Itse testi suoritettiin tekemällä satunnaisia HTTP-kutsuja verkkopalvelun 74

80 ohjelmointirajapintaan Apache Jmeter 5.0 -ohjelmiston ( avulla. Asiakaskoneena käytettiin samaa konetta kuin aiemmin esitellyissä verkkotesteissä. HTTP-kutsuja tehtiin keskimäärin 250 sekunnissa noin viiden minuutin ajan. Kutsuista 40% oli GET-kutsuja /cars/ -URL:ään satunnaisella pageparametrilla, 40% GET-kutsuja cars/:id:/ -URL:ään satunnaisella tunnuksella, 10% POST-kutsuja satunnaisella datalla ja 5% PUT- ja 5% DELETE-kutsuja satunnaisella datalla ja tunnuksilla. Nämä määrät ovat karkeita arvioita siitä, miten oikea verkkoautakauppa voisi saada erilaisia kutsuja, joskin se olisi todennäköisesti jopa enemmän lukupainotteinen. Testissä mitattiin eri kutsujen kokonaisviiveet, ja lisäksi isäntäkoneen prosessorien käyttöaste testin ajan Linuxin uptime-työkalun avulla. Tulokset ovat yhden verkkopyynnön kokonaisaika millisekunneissa, joten pienempi tulos on parempi. Kaavio 13. Verkkopalvelun testitulokset. 75