Haluaisitko laajentaa omaa konesalia pilveen ja rakentaa hybrid cloud -ympäristön?
Oletko miettinyt, miten voit käytännössä yhdistää oman konesalisi pilveen ja hyödyntää pilvipalvelujen etuja osana omaa konesalia?
Hybrid cloud sellaisenaan, mitä moni kuvittelee, ei välttämättä ole kovin hyvä ajatus.
Tässä artikkelissa kerron, mitä sinun pitää ymmärtää, kun suunnittelet konesalin laajentamista pilveen.
Luettuasi tämän kirjoituksen, tiedät, mitä ongelmia hybrid cloud tuo tullessaan, ja miten voit lähestyä asiaa.
Käsitellään aivan aluksi sitä, mistä hybrid cloud -mallissa on kyse. Kun luet seuraavan osuuden, ymmärrät, mitä tarkoitan hybrid cloud -ympäristöllä.
Mitä hybrid cloud tarkoittaa?
Hybrid cloud tarkoittaa yksinkertaisesti oman konesalin yhdistämistä yhteen tai useampaan julkiseen pilvipalveluun.
Netissä esiintyy jonkun verran yritystä kääntää hybrid cloud termillä hybridipilvi, mutta minusta parempi suomennos olisi yhdistelmäpilvi. Se kertoo suomeksi, mistä asiassa on kyse. Kyse on siitä, että liitetään omaan tai palveluntarjoajan konesaliin julkinen pilvi.
Ihan virallisesti hybrid cloud viittaa omaan konesaliin rakennetun yksityisen pilviympäristön liittämistä julkiseen pilvipalveluun. Tällaiset ympäristöt ovat kuitenkin melko harvinaisia, ja yleensä, kun puhutaan hybrid cloudista, tarkoitetaan vain konesalin liittämistä julkiseen pilvipalveluun.
Seuraava kuva esittää esimerkkiä tällaisesta tilanteesta.
Kuvassa omaan konesaliin on liitetty yhden pilven sijaan kaksi julkista pilvipalvelua (Amazon AWS ja Microsoft Azure).
Kaikessa yksinkertaisuudessaan hybrid cloud siis tarkoittaa sitä, että oman konesalin lisäksi käytössä on julkisen pilven palveluita.
Jotta voimme ymmärtää ongelmia, joita hybrid cloud tuo tullessaan, meidän pitää ymmärtää, miksi hybrid cloud on houkutteleva konsepti.
5 syytä, miksi hybrid cloud on houkutteleva vaihtoehto
Olen viime aikoina jutellut monen tietohallinnosta tai IT-infrasta vastaavan johtajan kanssa. Kun kysyn heidän suunnitelmistaan, vastaus on usein ”cloud first”.
Usein ajatus tuntuu olevan se, että hyödynnetään moderneita teknologioita. Ehkä taustalla on pelko jäädä kehityksessä jälkeen. Tarkoitus on tietysti hyvä: modernisoida omaa IT-infraa. Jotta pilvipalveluita kannattaisi ottaa käyttöön, pitäisi kuitenkin olla selvä käsitys siitä, mitä niillä tavoitellaan.
Seuraavassa on tyypillisiä tavoitteita pilvipalvelujen käyttöönotolle:
Kapasiteetin kasvatus. Oma konesaliympäristö ei ole kovin joustava ratkaisu, jos kapasiteettitarpeet vaihtelevat, tai jos tarvitaan nopeasti uutta kapasiteettia. Kenelläkään ei ole mahdollisuus pitää paljoa palvelimia vain odottamassa, jos niitä satuttaisiin tarvitsemaan. Pilvipalvelujen tarjoajilta kapasiteettia kuitenkin saa käyttöönsä muutamassa minuutissa.
Purskeiden hallinta. Tämä liittyy vahvasti edelliseen tarpeeseen. Joskus kapasiteettitarve on hyvin nopea. Perinteiset esimerkit verkkokauppojen kysyntäpiikeistä ovat malliesimerkkejä tästä. Pilvi on kätevä paikka palveluille, joiden kapasiteettitarve vaihtelee suuresti.
Varmuuskopiot. Datan säilyttäminen maksaa. Omat levyjärjestelmät maksavat. Pilvessä on tarjolla halpaa kapasiteettia datalle, jota tarvitaan harvoin. Juuri näistä syistä moni haaveilee harvoin tarvittavan datan tallentamisesta pilveen. Varmuuskopiot ovat yksi esimerkki tällaisesta datasta, joka olisi kätevä tallettaa pilveen.
Disaster Recovery. Kun tietojärjestelmistä on tullut liiketoiminnalle yhä kriittisempiä, yhä useampi organisaatio on alkanut miettimään, mitä tehdä, jos nykyinen konesali menetetään syystä tai toisesta. Pilvi varakonesalina on kiinnostava vaihtoehto.
Pilven palvelukatalogit käyttöön. Pilvipalveluissa on valtavasti palveluja, joiden käyttöönotto on nopeaa – paljon nopeampaa kuin omasta konesalista. Juuri palveluiden käyttöönoton nopeus on yksi merkittävimpiä syitä suosia pilvipalveluja.
Olen vertaillut omaa konesalia ja pilvipalveluja palveluiden käyttöönoton näkökulmasta kirjoituksessa, jonka löydät täältä.
Jos mietitään oman konesalin kapasiteetin kasvattamista, aika nopeasti tulee mieleen, että olisi hienoa, jos voisin siirtää virtuaalikoneita omasta konesaliympäristöstä pilveen ja tarvittaessa ottaa niitä takaisin omaan ympäristöön.
Tarkastellaan seuraavaksi tilannetta, mitä tällaisesta tavoitteesta seuraa käytännössä.
Virtuaalikoneiden siirtäminen ympäristöstä toiseen
Kun luet tämän osuuden, ymmärrät huomattavasti paremmin, mitä ongelmia virtuaalikoneen siirtämisestä omasta konesalista pilveen ja takaisin tarkoittaa käytännössä. Jatka siis lukemista.
Virtuaalikone on käytännössä tiedosto, joka sisältää kaikki palvelimen ajamiseksi tarvittavat tiedot. Ongelmaksi muodostuu nyt se, että tälle tiedostolle on useita formaatteja eli muotoja.
Suurimmassa osassa perinteisiä konesaleja ajetaan palvelinvirtualisointia VMwaren tekniikoilla. Silloin virtuaalikone on VMwaren vaatimassa muodossa.
Esimerkiksi Amazon AWS:n virtuaalikoneformaatti on nimeltään Amazon Machine Image. Sen vuoksi VMwaren virtuaalipalvelinta ei voi sellaisenaan ajaa AWS-palvelussa.
Microsoft Azure -pilvipalvelussa virtuaalikonetta ajetaan Hyper-V-alustan päällä. Siksi virtuaalikonekin näyttää erilaiselta Azuressa kuin VMware-ympäristössä.
Ratkaisu tähän ongelmaan on formaatin muuttaminen. Seuraava kuva selventää asiaa.
Kun virtuaalikone siirretään ajoympäristöstä toiseen, sen formaatti pitää muuttaa. AWS-ympäristöön VMwaren kone siirretään Amazonin Server Migration Servicen kautta. Lopputuloksena on Amazon Machine Image.
Jos taas VMware-kone siirretään Azureen, käytetään Azure Migration -palvelua ja lopputuloksena on Hyper-V-kone. Siirtäminen on siis periaatteessa yksinkertaista.
Homma on yksinkertaista niin kauan kuin siirretään koneita konesalista pilveen. Heti kun halutaan siirtää pilvessä oleva virtuaalikone pilvestä takaisin omaan konesaliin, asiat mutkistuvat.
Siirto on tietysti mahdollista, mutta vaatii taas migraatiotyökalujen käyttöä ja formaattien muuttamista. Sen vuoksi kukaan ei halua tehdä siirtoja jatkuvasti. Siirtäminen on suunniteltu ennemminkin kerran tehtäväksi.
Realistisempi hybrid cloud -vaihtoehto
Kuormien siirto edes takaisin pilven ja konesalin välillä ei ehkä kuitenkaan ole kovin realistista. Kun lisäksi koneiden siirtäminen ympäristöstä toiseen vaatii usein IP-osoitteisiinkin kajoamista, on se suhteellisen työlästä.
Seuraava kuva esittää askelta kehittyneempää vaihtoehtoa hybrid cloud -mallissa.
Aiemmin kuvaamani vaihtoehdot liittyvät IaaS-palvelun käyttöön. Realistisempi vaihtoehto on hyödyntää Platform-as-a-Service -palveluita eli PaaS-palveluita.
Jos tuntuu siltä, että kaipaat lisätietoja siitä, mitä IaaS- ja PaaS -palvelut ovat, voit lukea artikkelini, jossa kerron hieman tarkemmin pilvipalveluiden eroista. Löydät artikkelin täältä.
Järkevämpää kuin virtuaalikoneen ajaminen pilvessä, on usein PaaS-palvelun hyödyntäminen. Esimerkiksi SQL-palvelimen asentamisen sijaan voi olla järkevämpää käyttää SQL-palvelua, jossa pilvipalvelun tarjoaja pitää huolen alustasta ja asiakas huolehtii vain varsinaisen tietokannan ylläpidosta.
Toinen esimerkki samasta asiasta on Web Appien käyttö. Sen sijaan, että asiakas pitäisi yllä virtuaalipalvelinta ja asentaisi sen päälle IIS-palvelimen (Microsoftin Web-palvelin), voidaan ottaa käyttöön Web App, jossa palveluntarjoaja pitää yllä IIS-palvelimen tarvitsemaa alustaa, ja asiakas asentaa palveluun ainoastaan Web-sovelluksen.
Tietoliikenne hybrid cloud -mallissa
Yksi hybrid cloudin leviämistä hidastava tekijä on tietoliikenne ja siihen liittyvät kustannukset. Tyypillisesti liikennöinti pilven suuntaan on ilmaista, mutta liikenne pilvestä ulospäin maksaa erikseen.
Tämän vuoksi moni pilvipalvelu tulee käyttäjälleen paljon kalliimmaksi, mitä alun perin on arvioitu. Jos liikenteestä joutuu maksamaan, ei kuormien siirto edestakaisin pilveen ja pilvestä pois ole kovin järkevää.
Ratkaisu tähän on kiinteän yhteyden rakentaminen pilveen. Oheinen kuva esittää esimerkkiä, jossa näin on tehty. Käytännössä asiakas ostaa pilvipalvelun tarjoajalta tietoliikennepalvelun, joka sisältää vapaan liikennöinnin pilvestä pois.
Tässä esimerkissä pilvipalvelu liitetään osaksi MPLS-verkkoa, joka yhdistää pilven konesaliin ja toimipisteisiin. Aiemmin tällainen ratkaisu on ollut niin kallis, että se ei yleensä ole ollut vaihtoehto. Tilanne on kuitenkin muuttumassa.
Pilvipalvelun tarjoajat ovat muuttaneet hinnoitteluaan, ja tämän vuoksi kiinteä yhteys pilveen on nykyään mahdollinen aiempaa useammalle.
Oheinen kuva on ruutukaappaus Azuren sivuilta joulukuun alussa 2018. Esimerkiksi 50 Mbps -yhteys maksaa noin 250 euroa kuukaudessa. Tämän lisäksi tulee tietysti tietoliikenneoperaattorin yhteysmaksu. Hinnat alkavat kuitenkin olla hintaluokassa, joka on mahdollinen kenelle tahansa.
Tietoliikennekustannusten lisäksi hybrid cloud vaatii tietoliikennesuunnittelua. Verkkojen reititykset ja aliverkotus pitää miettiä aivan kuten omassakin konesalissa.
Yhteenveto
Hybrid cloud on kiinnostava tapa laajentaa omaa konesalia pilveen. Kuitenkin virtuaalikoneiden siirtely ympäristöstä toiseen on melkoisen hankalaa, joten siitä ei ole ratkaisuksi, jossa siirtoja tehdään usein moneen suuntaan.
Suunnittelussa pitää ottaa huomioon lisäksi tietoliikenteen vaatimukset, niin kustannukset kuin reititykseenkiin liittyvät näkökohdat.
Hybrid cloud on puutteistaankin huolimatta hyvä suunta monelle organisaatioille. Hyötyjen saaminen pilvestä vaatii usein uusien ajattelutapojen ja uusien teknologioiden käyttöönottoa.
Esimerkiksi kontit ovat hyvä vaihtoehto kuormien standardointiin ja siirrettävän datan minimointiin.
Jos haluat lukea perusasioita konttiteknologiasta, löydät siihen liittyvän artikkelini täältä.
Hybrid cloud tarjoaa yhden suunnan konesalin kehittämiseksi. Oikean arkkitehtuurin löytäminen vaatii käytännössä arkkitehtuurityön menetelmien soveltamista. Lue yksi erittäin suosittu artikkeli, jonka olen kirjoittanut tästä aiheesta.
Olen julkaisemassa opasta pilvistrategian laatimiseksi. Voit ennakkotilata oppaan täältä.
Käytännössä onnistunut pilviarkkitehtuuri vaatii monien eri asioiden huomioimista. Kirjoitan jatkossakin siitä, miten teknologiat tarkoittavat, ja miten niitä voi käytännössä hyödyntää.
Tilaa uutiskirjeeni, niin saat tiedon uusista asiaa käsittelevistä artikkeleista heti, kun julkaisen kirjoituksen.