1. oodata kuniks infosüsteem jõuab elukaare lõpuni ja mitte migreerida;

2. luua uus infosüsteemi versioon Riigipilve ja migreerida ainult andmed;

3. migreerida infosüsteem “as-is” Riigipilve.

Järgnev protsessikirjeldus puudutab neist valikutest just viimast, “legacy” infosüsteemide migreerimist Riigipilve, võimalikult väheste muudatustega.

Ettevalmistused

Infosüsteemide migreerimine ükskõik kuhu ja mis iganes meetodil on reeglina üsna ajamahukas ning detailiderohke ettevõtmine, mille soorituse raskusastet planeerimisfaasis tihtipeale alahinnatakse. Põhjalikud ettevalmistused ja protsesside läbitestimised kulutavad küll rohkem töötunde, aga tagavad reeglina ka edu. Peamised ettevalmistustööd, millele migreerimisplaani ettevalmistamisel tähelepanu pöörata on:

• migreeritavate ressursside piiritlemine eraldi infosüsteemidena, mida migreeritakse eraldi terviklike tükkidena;

• iga migreeritava infosüsteemi ja selle ressursside kaardistamine - sealhulgas kindlasti ka andmemahtude ja erinevate komponentide omavaheliste sõltuvuste hindamine;

• migreerimisprotsessiks sobiva “tööriistakasti” valimine;

• selged kokkulepped, kes teeb mida ja millal - ehk vastutusmaatriksi/projektiplaani koostamine;

• detailsete infosüsteemide migratsiooniplaanide koostamine koos infosüsteemide seisaku vajaduste hinnanguga.

Eelmigratsioon

Antud etapi peamisteks eesmärkideks on infosüsteemi komponentide esialgne eksport ning migreerimisprotsessi ja valitud tööriistakasti testimine. Tulemuseks võiks olla infosüsteemi täiskoopia Riigipilves, milles sisalduv andmekoopia on ekspordi toimumise seisuga - võimaldades valideerida migreeritud infosüsteemi kui terviku Riigipilves ja täpsustada iga infosüsteemi puhul talle vajalikke samme migreerimisprotsessis.

Sõltuvalt migreeritava infosüsteemi alusplatvormist ja valitud tööriistakastist võib hinnang infosüsteemi seisaku vajadusele eelmigratsiooni etapis olla erinev. Tüüpjuhtudel antud faasis seisaku vajadus puudub või on minimaalne (kui on vajalik nt tervikliku tõmmise kindlustamiseks).

Eelmigratsiooni etappi võib ka vajadusel alati korrata - et uuendada andmekoopiat ja lihvida protsessi. Antud faasis tuleks ka hinnata andmete juurdekasvu kindlaksmääratud ajaperioodi kohta live süsteemis, mis on aluseks seisaku hinnangule järgnevas etapis.

Infosüsteemi migreerimine

Kui infosüsteemi migreerimise test sai edukalt läbitud, siis on võimalik edasi liikuda live infosüsteemi lõpliku kolimise ja rakendus(t)e teenuspunktide ümberlülitustega. Oluline on siin detailselt kirja panna ja kokku leppida järgmised asjad:

• kas sünkroniseeritakse vaid live süsteemis peale viimast eelmigratsiooni uuenenud andmeid, rakenduse tasemel (nt andmebaasi sisu) - või sünkroniseeritakse infosüsteemi täiskoopia (nt OS ketta/failisüsteemi tasemel)?

• mis meetodil toimub andmete sünkroniseerimine? Kas see meetod toetab ka uute andmete tuvastamist algallikas (ehk toetab incremental/delta sünkroniseerimist)? Kaua see protsess reaalselt aega võtaks?

• koostada live infosüsteemi seisaku hinnang - koos mõistliku varuga ettenägematuteks arenguteks ja riskide realiseerumisel tagasilülituseks (plaan-B). Andmekoopia tervikluse tagamiseks tuleb live süsteem viimaseks andmekoopia sünkroniseerimiseks sulgeda ning sellest hetkest hakkab jooksma seisaku aeg - kuniks värsked andmed on üle kantud ja infosüsteemi teenuspunktid Riigipilve ümber lülitatud;

• kokku leppida selge ajakava vana infosüsteemi sulgemiseks, viimaseks andmekoopia sünkroniseerimiseks, kolitud infosüsteemi valideerimiseks Riigipilves ja lõpetuseks rakendus(t)e avalike ja/või sisemiste teenuspunktide ümberlülitusteks (sh teenuspunktide DNS/IP muudatuste tegemiseks).

Tööriistakastist

Kuigi kõiki migreerimisel vajaminevaid samme on võimalik hea tahtmise juures ise teha ka käsitsi või koostades selleks oma “tööriistad”, on see reeglina üks aeganõudvamaid variante. Sõltuvalt olemasoleva infosüsteemi alusplatvormist ja komponentidest, leidub erinevaid tööriistakaste, mis aitavad protsesse automatiseerida.

VMware -> Riigipilv näide:

Üheks levinumaks virtualiseerimisplatvormiks olemasolevatele infosüsteemidele on siiani olnud VMware vSphere. Riigipilve IaaS teenus sisaldab Openstack privaatpilve saite - seega peaks sobiv tööriistakast ideaalis suutma teha järgmist:

• looma VMware vSphere kaudu kolitava VM-i ketastest CBT tõmmised ja neid eksportima;

• kaardistama, transleerima ja üle kandma Riigipilve VMware VM-idega seotud meta-objektid - nagu võrgupordid, VM ressursiprofiilid, kettad;

• kopeerima VMware-st VM ketaste CBT tõmmistest andmed Riigipilve loodud kettavolüümidesse (sh hiljem ka inkrementaalselt);

• taaslooma Riigipilves VM objektid koos üle kantud võrguportide, ressursiprofiilide ja ketastega.

Peamised riskikohad migreerimise protsessis

• andmehulkade ülekandmisega seotud ajalised riskid - võrguühenduste läbilaskevõime lähtekoha ja kliendi Riigipilve VPC vahel

• andmesalvestusmassiivi kirjutamise/lugemise läbilaskevõime lähtekohas ja kliendi poolt valitud Riigipilve VPC storage tier-is

• ebaõnnestunud tööriistakasti ja migreerimismeetodite valik

• andmete sünkroniseerimiseks kasutatava meetodi/tööriista läbilaskevõime

• andmete tervikluse tagamine ja kontroll

• migreeritud infosüsteemi komponentide seadistuste ja teenuspunktide muudatused (nt DNS kirjed)

• ebapiisav migreeritud infosüsteemi toimimise järelkontroll

Korduma Kippuvad Küsimused

Küsimus: Millised migreerimis- ja konsultatsiooniteenused on saadaval Riigipilve teenustekataloogist?

• OpenNode konsultatsiooni- ja migreerimisteenus

• Bytelife IT haldusteenus

• Telia konsultatsiooni- ja migreerimisteenus

Küsimus: Millised on võimalikud valikud tööriistakastide osas?

Tööriistakaste on mitmeid ning järgnev nimekiri ei ole kindlasti lõplik:

• Cloudbase Coriolis (kasutusel nt OpenNode migreerimisteenuse raames)

• Redhat CloudForms

• Redhat virt-v2v ja virt-p2v

• Commvault

• Hystax Acura

Küsimus: Miks Riigipilv ei paku VMware vSphere lahendust IaaS teenusena?

Riigipilv on oma arhitektuurilt multi-cloud lahendus, kuid läbi aegade on olnud erinevaid põhjuseid, miks Riigipilves ei ole senini realiseerunud VMware tehnoloogiatel põhinev IaaS pilvesegment. Alustada tuleks ilmselt sellest, et Riigipilve tehnilisteks nõueteks on 2016. aastal riigi IT Arhitektuurinõukogu poolt koostatud Riigipilve alusnõuded v2.0, mis soovitavad “vendor lock-in” olukordi vältida ning eelistada võimalikult kuluefektiivseid lahendusi. Riigipilve IaaS teenuste ja nende tehniliste lahenduste planeerimisel on regulaarselt analüüsitud sealhulgas ka VMware tehnoloogiate baasil IaaS pilvesegmendi loomist - kuid ei ole erinevate asjaolude kaalumisel jõutud lõpliku investeeringu otsuseni. Põhjused on olnud laias laastus järgmised:

• tavapärane VMware vCenter lahendus ei ole Riigipilve multitenant IaaS teenuse jaoks sobiv. Vajalik on kaasata ka teisi komponente, nt NSX võrgukihi täislahendus ja vCloud või VIO;

• VMware multitenant IaaS teenus Riigipilves eeldaks vCloud Director või VIO baasil rajatud lahendust, mille funktsionaalsus ja kasutuskogemus erineb samuti lõppkasutaja varasemast vCenter kasutuskogemusest;

• Openstack pilvesegmentide puhul on Riigipilvel võimalik valida erinevate vendorite/toodete vahel, VMware pilvesegmendi puhul mitte;

• litsentsimudelite, hinnastuse ja kuluefektiivsusega seotud aspektid IaaS teenuse operaatori jaoks (mis on erinevad tavapärasest lõpptarbijale suunatud litsentsimudelitest/hinnastusest);

• VMware vCenter kasutuskogemuse ja funktsionaalsuse säilitamine lõppkasutaja jaoks Riigipilves eeldaks BareMetal teenust ja VMware litsentside renditeenust;

• uute teenuse ja pilvesegmentide rajamine nõuaks investeeringuid, mille tagamiseks on siiani puudunud piisav kliendi huvi. Samuti oleks selleks vajalik laiapõhjalisem vajaduste kaardistamine ning kokkulepe nt riigi IT Arhitektuurinõukogu tasandil.