Toiming "Migratsioon": kuidas liikuda DataLine'i pilve

Umbes 7 aastat tagasi kolisid kõige esimesed projektid meie pilve lihtsalt ja pretensioonitult. Virtuaalmasina pildid laaditi üles FTP-serverisse või edastati need kõvakettale. Seejärel laaditi VM-id spetsiaalse importserveri kaudu pilve üles.

Kui kliendi jaoks ei ole probleemiks virtuaalmasinat päevaks-paariks välja lülitada (või pole muid võimalusi), siis saab seda teha. Aga kui seisak peaks olema maksimaalselt tund, siis see meetod ei tööta. Täna räägin teile, millised tööriistad aitavad teil minimaalse seisakuajaga pilve üle minna ja kuidas meie migratsiooniprotsess ise toimib.

Toiming "Migratsioon": kuidas liikuda DataLine'i pilve

Migreerimine Veeami varundamise ja replikatsiooniga

Kõik teavad Veeami varundust ja replikatsiooni kui varukoopiate ja koopiate loomise tööriista. Kasutame seda oma saitide vahel migreerimiseks ja klientide transportimiseks privaatsest virtualiseerimisest meie pilve. Kliendi virtuaalsed masinad kopeeritakse meie vCenterisse, misjärel insener lisab need vCloud Directorisse.

Esmane replikatsioon toimub sisselülitatud virtuaalmasinas. Kokkulepitud ajal lülitatakse kliendipoolne masin välja. Pärast esimest replikatsiooni toimunud muudatuste ülekandmiseks käitatakse replikatsioon uuesti. Pärast seda käivitub virtuaalne masin meie pilves.

Toiming "Migratsioon": kuidas liikuda DataLine'i pilve

Tavaliselt ei möödu masina kliendi infrastruktuuris väljalülitamise hetkest kuni selle meie pilves sisselülitamiseni rohkem kui pool tundi, vaid pigem 15–20 minutit.

Sel juhul jääb algne virtuaalmasin kliendi saidile. Kui äkki midagi läheb valesti, saate alati tagasi keerata ja sisse lülitada. See meetod on kliendile mugav ka selle poolest, et ei nõua talt Veeami olemasolu.

Juhtum 1
Kliendil oli oma VMware-l põhinev virtuaalne infrastruktuur – 40 VM-i mahuga 30 TB. Seadmed, millel klastrit juurutati, olid juba aegunud ja klient otsustas uute ostmisega mitte vaeva näha ning kolis avalikku pilve. Kriitiliste süsteemide seisakunõue ei olnud üle tunni. Tööriistaks valiti Veeam Replication. Plussiks oli ka see, et meie andmekeskuses oli kohal kliendi internetipakkuja, mis võimaldas korraldada hea kanali. Migratsioon kestis umbes kuu, seisakuid oli ümberlülitumisel kuni 30 minutit virtuaalmasinate rühma kohta.

Migreerige Veeam Cloud Connectiga

Veeam Cloud Connect on tööriist, mis aitab teil seadistada virtuaalmasina replikatsiooni ja käivitada teenusepakkuja pilves koopiaid. Pärast värskendamist 2019 aastal sai võimalikuks virtuaalmasinate kopeerimine otse vCloud Directorisse. Ainus tingimus on, et kliendi poolel peab Veeam Backup and Replication juurutama vähemalt versiooni 9. Lühidalt (üksikasjalik versioon siin), siis näeb kogu protsess välja selline.

VCloud Directoris luuakse vajalike ressursside ja võrkudega organisatsioon. Veeam Cloud Connectis loome konto, klient loob sellega ühenduse oma Veeam B&R-ist, valib DataLine'i pakkuja ja organisatsiooni ning konfigureerib replikatsiooni ülesanded. Lisaks sellele, et sellise migratsiooni ajal jääb seisakuid 15–20 minuti piiresse, ei sõltu klient kuidagi teenusepakkuja tehnilisest toest ja juhib kogu protsessi iseseisvalt: loob replikatsiooniülesanded, replikatsiooni ise, lülitub välja masinad ja käivitab need uuel saidil.

Toiming "Migratsioon": kuidas liikuda DataLine'i pilve

Juhtum 2
Kliendi infrastruktuur, kust migratsioon kavandati, asus Valgevenes. Transportida oli vaja 90 VM-i kogumahuga 27 TB, vaatamata sellele, et internetikanaliks oli 100 Mbit/sek. Kui teete varukoopia ja laadite selle kohe meie pilve, siis mõnel VM-il kuluks selleks mitu päeva. Selle aja jooksul oleks VM-il kasvanud suur delta ja see võib masinate jõudlust negatiivselt mõjutada või, mis veelgi hullem, oleks andmesalves ruum otsa saanud. Toimisime järgmiselt: esmalt tegi klient kohaliku täieliku varukoopia ja kandis Veeam Cloud Connecti kaudu selle koopia meie pilve. Seejärel tegin ja kandsin juurdekasvu pilve. Algne virtuaalmasin jätkas töötamist. Pärast VM-i sulgemist tegi klient veel ühe juurdekasvu ja edastas selle ka pilve. Meie poolel juurutasime virtuaalse masina täielikust varukoopiast ja seejärel lisasime sellele kaks sammu. Lõppkokkuvõttes võimaldas see skeem vähendada meie saidile üleminekul seisakuid 2 tunnini.

Migreerimine VMware vCloudi saadavuse abil

Selle aasta märtsis andis VMware välja vCloud Availability 3.0, mis võimaldab migreerida virtuaalmasinaid erinevate pilvede vahel (vCloud Director – vCloud Director) ja privaatkliendi virtualiseerimise stendidelt pilve (vCenter – vCloud Director). Peamine mugavus on integreerimine vCloud Directori liidesega. See lihtsustab oluliselt replikatsioonihaldusprotsessi ja minimeerib ümberlülituste ajal tekkivaid seisakuid.

Selle tööriista abil migreerisime ühe klientidest oma Moskva pilvest meie pilve Peterburis. Transportida oli vaja 18 virtuaalmasinat kogumahuga 14 TB. Kliendile loodi organisatsioon Peterburi pilves ja korrastati vajalikud võrgud. Järgmisena läks klient vCloud Directori liidesest vCloudi saadavuse seadetesse, lõi replikatsioonitööd ja lülitus talle sobival ajal Peterburi saidile. Lülituse ajal oli seisak 12 minutit.

Toiming "Migratsioon": kuidas liikuda DataLine'i pilve
Migratsiooniskeem DataLine'i pilvede vahel Peterburis ja Moskvas.

vCloudi saadavusel on mehhanism VM-ide migreerimiseks kliendi saidilt meie pilve. Selleks juurutatakse kliendi vCenteris spetsiaalne vCloudi saadavuse rakendus. Pärast lihtsat seadistamist loote ühenduse pilvega ja konfigureerite migratsioonitoimingud. Samuti juhib klient kogu protsessi iseseisvalt ning migratsiooniaeg on viidud miinimumini.

Toiming "Migratsioon": kuidas liikuda DataLine'i pilve
Skeem virtuaalmasinate migreerimiseks privaatinstallatsioonist pilve.

VMware vCloudi saadavusel on palju muid kasutusjuhtumeid; me räägime neist peagi eraldi artiklis.

Migratsiooniks valmistumine

Tööriista valimiseks ja migratsiooni alustamiseks peate otsustama järgmiste punktide üle.

Kust me rändame? Kui lähete eralahenduselt üle, on teil tööriistade valikul täielik vabadus. Kui lähete teenusepakkujast eemale, on see keerulisem. Tõenäoliselt ei toimi turvakaalutlustel kahe pakkuja infrastruktuuride ühendamine ja lihtsalt virtuaalse masina lohistamine. Mõnikord hakkab teenuseosutaja, kellest klient keeldub, vallatuks ja jääb aja peale. Saate teenusepakkujast eemalduda vanamoodsal viisil: laadides VM-id üles ketastele ja FTP-le või migreerides rakenduse tasemel. Viimase nimi on tingimuslik ja näeb välja umbes selline.

Juhtum 3
Vaja oli migreerida kliendi SAP-süsteem Euroopa pakkujalt: 34 VM-i mahuga 54 TB. Kliendile eraldati meie pilves ressursid. Võrguühendus korraldati meie ja Euroopa pakkuja infrastruktuuri vahel. Rakendusserverid juurutati uuesti koos vajalike konfiguratsioonidega. Suured andmebaasid migreeriti meie pilve varukoopiate üleslaadimise kaudu. Järgmisena konfigureeriti replikatsioon meie ja algsaitide andmebaaside vahel. Kokkulepitud ajal läksime oma pilves üle andmebaasidele.

Andmemaht ja Interneti-kanal. Tavaliselt palume kliendil esitada süsteemipõhine üleslaadimine koos mälu, protsessori ja ketta parameetritega. Hindame, kas kanalist piisab virtuaalmasinate koopiate või varukoopiate otse saatmiseks.

Vastuvõetav seisakuaeg. Erinevate süsteemide ja vastavalt ka virtuaalmasinate puhul võib see sõltuvalt nende ärikriitilisusest erineda. Tavaliselt on kliendil migratsiooniaegse seisaku jaoks kaasas valmis nõuded ning sellest lähtuvalt valime sobiva tööriista ja migratsiooniplaani. Lõpliku ülemineku püüame ajastada ööseks või nädalavahetuseks nii, et ka väiksemad seisakud poleks kliendi lõppkasutajatele märgatavad.

Nende andmete põhjal saate valida tööriista ja alustada ise migreerimist. Järgmisena juhtub järgmine.

  1. Võrguühenduse seadistamine. Korraldame võrguühenduse oma pilve ja kliendi infrastruktuuri vahel. Virtuaalmasinad kopeeritakse selle võrgu kaudu. Kui kasutada Veeam Backup and Replication, siis on selleks spetsiaalne kanal, harvem VPN kanal. Kui Veeam Cloud Connect, siis kõik käib interneti või sama spetsiaalse kanali kaudu.

    Seejärel konfigureeritakse võrk pilves oleva virtuaalse masina jaoks. Autod liiguvad tavaliselt rühmadena ja rohkem kui ühe päeva. Kui VM-id on meile toodud ja käivitatud, peavad nad suhtlema masinatega, mis on endiselt algses kohas.

  2. Migratsiooni ajakava. Kui autosid on palju, on mõttekas need rühmadesse jagada ja partiidena transportida. Koos kliendiga lepime kokku plaani, milles täpsustame, millal ja millised masinad liiguvad ning millal tehakse lõplik replikatsioon ja üleminek uuele saidile.
  3. Testi migratsiooni. Me migreerime test-virtuaalmasina ja kontrollime, kas kõik on õigesti seadistatud: võrguühendus saitide vahel, virtuaalmasina saadavus lähtesaidil olevate masinate jaoks, kontoõigused jne. See test aitab vältida takistusi lahingurände etapis.

See on minu jaoks kõik. Küsige kommentaarides küsimusi ja rääkige meile oma rändekogemusest.

Allikas: www.habr.com

Lisa kommentaar