Jemma pilvessä

Mikä on yksi epäseksikkäimmistä IT-alan termeistä ja teknologia-alueista, mutta silti samaan aikaan oleellisen kriittinen osa yritysten toimintaa, liiketoiminnan jatkuvuutta sekä lakisääteinen velvoite monessa mielessä? No tietysti datan varmistus.

 

Kaikki sysadminit, IT-mangerit, tuotanto -ja palvelupäälliköt sekä iso joukko muita IT-duunareita ovat varmasti viimeisten vuosikymmenten aikana joutuneet miettimään miten tärkeiden ja bisnekselle kriittisten palvelinten, ja ennen kaikkea sen DATAn saadaan turvattua. Tuttua on myös varmasti tämän kaltainen tilanne: -”On meillä varmistukset kunnossa. Kyllä, ihan varmasti ne menee joka viikko fullina ja sitten öisin incrementinä. Ja Retentiopolitiikka antaa meidän palauttaa vuoden takaa toimarin tiedostot.” Mitäs sitten, kun tulee se hätä ja pitää palauttaa jotakin? Joskus onnistuu ja joskus aiheuttaa hillitöntä pään raapimista, jonka lopputuloksena joudutaan toteamaan, ettei kyseiseltä päivältä ole mennyt muuttuneita datoja, koska backupin aikaikkuna on ollut liian tiukka, varmistusprosessi ei ole ollut käynnissä tai parhaimmillaan levy on ollut lähes loppu.

 

Miten sitten nykyään kannattaa toteuttaa toimiva datan varmistus? Tietysti pilvipalveluna, käyttämällä jotain kevyttä, skaalautuvaa, agentless pilvinatiivi tuotetta. Jos tarkkoja ollaan termi ei ole varmistus, vaan kyseessä on datan hallintakokonaisuus. Tällöin dataa voidaan analysoida, luokitella sekä esimerkiksi poistaa tietyillä avainsanoilla tai hasheillä varmistusten joukosta. Voidaan siis vastata myös GDPR vaatimuksiin ketterästi.

 

Cloud2:lla olemme tutkineet tätäkin markkinaa. Tavoitteena on ollut löytää asiakkaille sekä palvelutuotannolle parhaat työkalut, joilla asiakkaiden tärkeä data saadaan turvaan ja hallituksi. Seuraavassa esittelyä pilvinatiivista Druva datahallinta ratkaisusta.

 

Druva Phoenix

Druva Phoenix Amazon AWS storage

Phoenix on palvelininfraan soveltuva data management ratkaisu, joka tekee kaikkea edellä mainittua eli varmistusta, datan hallintaa, disaster recoverya, arkistointia ja analytiikkaa. Druva käyttää taustalla Amazon AWS storagea, ja onkin globaalisti yksi suurimmista AWS data-asiakkaista tänä päivänä.

 

 
Druva Cloud Nutanix
 

Arkkitehtuuri on yksinkertainen. On-prem Datacenter keskustelee Druvan palveluun salattua liikennettä, ja kaikki hallinta tapahtuu pilven kautta. Paljon kaivattu agentless malli toteutuu tällä hetkellä Vmware, Nutanix ja Hyper-V infrastruktuurin kanssa. On-prem puolelle tulee VM proxy komponentti, ja käytännössä levyt varmistetaan turvaan suoraan hypervisor tasolta VADP API:n kautta.

 
Vmware Phoenix Cloud
 
 

Edellämainitun lisäksi kaikki virtuaaliset ja fyysisetkin raudat saadaan datahallinnan piiriin agent-mallilla, palvelimelle asennettavan komponentin avulla. Agentti juttelee niinikään salattua tcp443 liikennettä Druvan palveluun. Agenttia ladattaessa voi valita sopivan AWS regioonan johon varmistettu data siirtyy. Tuettuina käyttöjärjestelminä ovat MS Server ja useat Linux distrot.

Druva Phoenix MS Server Linux
 

Asennus on yksinkertainen, ja voidaan automatisoida palvelininfraan esimerkiksi alla olevan one-linerin kaltaisesti syöttämällä palvelusta löytyvä token suoraan parametriksi.

One-liner Druva Phoenix

Datan varmistus ja hallinta on siis nyt otettu käyttöön, mitä seuraavaksi? Nyt voidaan kirjautua phoenix.druva.com portaaliin ihailemaan graafista näkymää omasta datasta, luomaan backup policyt, retention ajat ja muut perusasetukset.

Phoenix tekee myös deduplikointia varmistetulle datalle, eli savings rate kerroin nousee tuttuun tapaan melko korkeaksi kun kyseessä on palvelininfraa.

Phoenix Dashboard tuottaa kattavan yleisnäkymän datan määrästä, varmistettavista kohteista, datan sijainnista, dedupista ja jobien tilasta.

 
Druva Dashboard
 

Palautusprosessi? Onko sitä testattu? Pilvinatiivin tuotteen etuna on, että legacymaailman tuottamat hajoavat komponentit puuttuvat prosessista. Palautus on suoraviivainen ja voidaan tehdä vaikka tiedostotasolle valitsemalla kohdepalvelin, haluttu aikaikkuna sekä palautettava sisältö.

 
Druva palautus
 
Druva palautus

Druva CloudRanger

Joskus edelleen kuulee kysyttävän, tarvitseeko pilvessä olevia palvelimia varmistaa. Totuus on, ettei mikään kolmesta suuresta public cloud vendorista vastaa virtuaalipalvelinten varmistuksista sen enempää kuin niiden eheydestäkään.

 

Noin vuosi sitten syksyllä 2017 Druva ilmoitti mielenkiintoisesta Cloud-to-Cloud varmistusratkaisusta nimeltä Apollo. Tuote ei ollut vielä saatavilla, mutta tutkimme sitä ja tahdoimme olla ensimmäisten joukossa mukana testaamassa ja implementoimassa ratkaisua tuotantoon. Kätevä työkalu joka korvaisi snapshotit ja skriptit oli siis tarpeen. Kesällä 2018 CloudRanger päätyi kaupan myötä Druvan salkkuun, ja samalla korvasi Apollo trackin heidän kehityksestä.

 

CloudRangerin konfigurointi on äärimmäisen suoraviivaista. Seuraavassa on kuvattu käyttöönoton stepit ylätasolla. Tällä hetkellä vain AWS on tuettu, mutta myös Google GCP ja Azure ovat roadmapilla.

 
CloudRanger tili ja AWS -yhteys

CloudRanger tilin luonnin jälkeen määritetään yhtyes AWS:ään.

 
 

Konsoli ohjaa AWS loginiin, jonka jälkeen automatisoitu CloudFormation template ajaa tarvittavat komponentit ja oikeudet AWS accountin alle.

 

CloudFormation AWS -account
 
 

Template on nähtävillä ja prosessi juoksee joitain minuutteja.

Template AWS CloudFormation
 

CloudFormationin tuottama Resource name ARN tulee ottaa talteen ja syöttää CloudRanger konsoliin.

CloudFormation Resource name ARN CloudRanger

Tämän jälkeen Amazon EC2 instanssit ilmestyvät CloudRanger hallintaan ja niille voi luoda policyt sekä asetukset.

 
Amazon EC2 instanssi CloudRanger hallinta
 
 

Jos politiikkoja ei vielä ole, niin luodaan uudet tässä vaiheessa. Määritetään aikaikkuna varmistusten ajolle, frekvenssi ja retentio. Voidaan myös valita luodaanko snapshotteja vai suoraan AMI imageja.

 

Snapshot ja AMI image
 

Tämän lisäksi voidaan määrittää ajastukset palvelinten automaattiselle powercyclelle. CloudRangerilla on oikeus käskyttää EC2 instanssien power statea, joten voidaan määrittää esim. alla olevan mukaan, että pidetään palvelimet päällä vain arkipäivisin. Pelkkää rahansäästöä!

 
EC2 instanssi power state
 
 
Disaster recovery AWS region

Tarvittaessa Disaster Recovery cross-region mallisesti on myös määritettävissä. Eli voidaan luoda säännöt, joiden mukaan EC2 virtuaalikoneet siirretään ja käynnistetään toisella AWS regionilla ongelman sattuessa.


 

Varmistuksille ja datan hallinnalle on siis edelleen kysyntää, ja jatkuvasti suuremmassa määrin, datamassojen noustessa. Datan analysointi, luokittelu ja ketterä hallinta ovat tärkeässä roolissa GDPR vaatimusten lisäksi myös jokapäiväisen tietoturvan takia. Tämä epäseksikäs varmistusgenre on siis kenties innovatiivisten pilvinatiivien ratkaisuiden myötä noussut edes vähän kuumemmaksi.