Prije otprilike 7 godina, prvi projekti su se jednostavno i lako selili u naš oblak. Slike virtualnih mašina su se prenosile preko FTP servera ili su donošene na tvrdim diskovima. Nakon toga, putem posebnog servera za uvoz, VM su se učitavali u oblak.
Ako klijentu ne smeta isključiti virtualku na dan-dva (ili nema drugih opcija), može se to tako. No, ako downtime ne smije trajati duže od sat vremena, takav način nije primjeren. Danas ću objasniti koji alati mogu pomoći pri migraciji u oblak s minimalnim vremenom zastoja i kako je sam proces migracije organiziran kod nas.
Migracija pomoću Veeam Backup and Replication
Veeam Backup and Replication svi znaju kao alat za izradu backup-a i replikacija. Mi ga koristimo za migraciju između naših lokacija i za prebacivanje klijenata s privatne virtualizacije u naš oblak. Virtualne mašine klijenta se repliciraju na naš vCenter, nakon čega inženjer dodaje iste u vCloud Director.
Prva replikacija se izvodi na uključnoj virtualnoj mašini. U dogovoreno vrijeme, mašina na strani klijenta se isključuje. Replikacija se pokreće još jednom kako bi se prenijele promjene koje su se dogodile od prve replikacije. Nakon toga, virtualna mašina se pokreće već u našem oblaku.
Obično prolazi ne više od pola sata od isključivanja mašine na infrastrukturi klijenta do uključivanja u našem oblaku, a češće 15–20 minuta.
Pri tome na lokaciji klijenta ostaje izvorna virtualna mašina. Ako iznenada nešto krene po zlu, uvijek se može vratiti i uključiti je. Za klijenta je ta metoda povoljna jer ne zahtijeva od njega da ima Veeam.
Slučaj 1
Klijent je imao svoju virtualnu infrastrukturu na bazi VMware – 40 VM-a s kapacitetom od 30 TB. Oprema na kojoj je klaster bio postavljen već je zastarjela, pa je klijent odlučio ne baviti se nabavkom nove i preseliti se u javni oblak. Zahtjev za vremenom zastoja kritičnih sistema bio je ne više od sata. Kao alat je izabran Veeam Replication. Dodatna prednost bila je to što je internet provajder klijenta bio prisutan u našem podatkovnom centru, što je omogućilo stvaranje dobrog kanala. Migracija je trajala oko mjesec dana, a vrijeme zastoja prilikom prebacivanja iznosilo je do 30 minuta za jednu grupu virtualnih mašina.
Migracija pomoću Veeam Cloud Connect
Veeam Cloud Connect – alat koji pomaže u postavljanju replikacije virtualnih mašina i pokretanju replikata u oblaku pružatelja usluga. Nakon ažuriranja u godini omogućena je replikacija virtualnih mašina direktno u vCloud Director. Jedini uvjet je da klijent mora imati postavljen svoj Veeam Backup i Replication ne niži od verzije 9. U kratkim crtama (detaljna verzija ), cijeli proces izgleda ovako.
U vCloud Director se kreira organizacija s potrebnim resursima i mrežama. U Veeam Cloud Connectu kreiramo račun, klijent se povezuje s njim iz svog Veeam B&R, bira pružatelja DataLine i organizaciju, zatim postavlja zadatke za replikaciju. Osim što će jednostavnost migracije biti u rasponu od 15 do 20 minuta, klijent ne ovisi o podršci pružatelja i samostalno upravlja cijelim procesom: kreira zadatke za replikaciju, samu replikaciju, isključuje mašine i pokreće njihov start na novoj lokaciji.
Slučaj 2
Infrastruktura klijenta, s koje se planirala migracija, nalazila se u Bjelorusiji. Trebalo je prenijeti 90 VM-ova ukupnog volumena 27 TB, uz internet kanal od 100 mbit/s. Kada bi se radila sigurnosna kopija i odmah je slala u naše oblak, za neke VM-ove bi to trajalo nekoliko dana. U tom razdoblju bi na VM-ovima nastala velika delta, što bi moglo negativno utjecati na performanse mašina ili, još gore, ponestalo bi mjesta na datastoru. Postupili smo na sljedeći način: prvo je klijent napravio lokalnu potpunu sigurnosnu kopiju i prenio je kopiju u naše oblak putem Veeam Cloud Connect. Zatim je napravio i prenio inkrement. Izvorna virtualna mašina nastavila je raditi. Nakon isključivanja VM-a, klijent je napravio još jedan inkrement i također ga prenio u oblak. Na svojoj strani smo postavili virtualnu mašinu iz pune sigurnosne kopije, a zatim dodali dva inkrementa. Ova shema omogućila je konačno minimiziranje zastoja na 2 sata prilikom prebacivanja na našu lokaciju.
Migracija pomoću VMware vCloud Availability
U ožujku ove godine VMware je izbacio vCloud Availability 3.0, koji omogućava migraciju virtualnih mašina između različitih oblaka (vCloud Director – vCloud Director) i s privatnih virtualizacijskih platformi klijenata u oblak (vCenter – vCloud Director). Glavna pogodnost je integracija s vCloud Director sučeljem. To znatno pojednostavljuje proces upravljanja replikacijom i minimizira vrijeme zastoja tijekom prebacivanja.
Pomoću ovog alata migrirali smo jednog klijenta iz našeg moskovskog oblaka u naš oblak u Sankt Peterburgu. Trebalo je prenijeti 18 virtualnih mašina ukupnog kapaciteta 14 TB. Za klijenta je stvorena organizacija u peterburškom oblaku i organizirane potrebne mreže. Nakon toga, klijent je preko sučelja vCloud Director prešao na postavke vCloud Availability, stvorio zadatke replikacije i u skladu s vlastitim rasporedom prešao na peterburšku lokaciju. Vrijeme zastoja tijekom prebacivanja iznosilo je 12 minuta.
Shema migracije između oblaka DataLine u Peterburgu i Moskvi.
U vCloud Availability postoji mehanizam za migraciju VMs s platforme klijenta u naš oblak. Za to se u klijentovom vCenter-u postavlja posebni appliance vCloud Availability. Nakon jednostavne konfiguracije uspostavlja se veza s oblakom i postavljaju se migracijski zadaci. Klijent također samostalno upravlja cijelim procesom, a vrijeme migracije se minimizira.
Shema migracije virtualnih mašina iz privatne instalacije u oblak.
VMware vCloud Availability ima mnogo drugih scenarija korištenja, uskoro ćemo ih predstaviti u posebnom članku.
Priprema za migraciju
Kako bismo odabrali alat i zapravo započeli migraciju, potrebno je razjasniti sljedeće aspekte:
Odakle migriramo. Ako migrirate s privatnog rješenja, imate potpunu slobodu u odabiru alata. Ako se selite od pružatelja usluga, to je malo složenije. Vjerojatno nećete moći povezati infrastrukture dvaju pružatelja usluga i jednostavno premjestiti VM iz sigurnosnih razloga. Ponekad pružatelj s kojim se klijent želi isključiti počinje otežavati i odugovlačiti. Seljenje od pružatelja može se obaviti na tradicionalan način: iskopavanjem VM-ova na diskove i FTP ili migracijom na razini aplikacije. Naziv potonjeg je uvjetan, i to izgleda otprilike ovako.
Studija slučaja 3
Potrebno je bilo migrirati klijentovu SAP sustav s europskog pružatelja usluga: 34 VM s volumena od 54 TB. Klijentu su dodijeljeni resursi u našoj oblačnoj usluzi. Između nas i infrastrukture europskog pružatelja usluga organizirana je mrežna povezanost. Aplikacijski serveri ponovno su raspoređeni, sa potrebnim konfiguracijama. Velike baze podataka migrirane su putem učitavanja sigurnosnih kopija u naš oblak. Nakon toga postavljena je replikacija između baza podataka na našoj i izvornoj platformi. U dogovoreno vrijeme prebacili smo se na baze podataka u našem oblaku.
Obujam podataka i internetski kanal. Obično tražimo od klijenta da dostavi ispravke po sustavima s parametrima memorije, CPU, diskova. Procjenjujemo je li kanal dovoljan za izravno slanje replikacija ili sigurnosnih kopija virtualnih strojeva.
Dopustivo zastoja. Za različite sustave i, sukladno tome, virtualne strojeve može biti različito ovisno o njihovoj kritičnosti za poslovanje. Obično klijent dolazi s gotovim zahtjevima o zastoju tijekom migracije, a na temelju toga biramo odgovarajući alat i plan migracije. Pokušavamo planirati konačno prebacivanje u noćnim satima ili vikendima, tako da ni minimalni zastoj ne bude primjetan krajnjim korisnicima klijenta.
Na temelju ovih podataka može se izabrati alat i započeti sama migracija. Evo što se dalje događa.
- Postavljanje mrežne povezanosti. Organiziramo mrežnu povezanost između našeg oblaka i infrastrukture klijenta. Kroz ovu mrežu će se kopirati virtualni strojevi. Ako se koristi Veeam Backup and Replication, to je izdvojeni kanal, rjeđe – VPN kanal. Ako se koristi Veeam Cloud Connect, sve ide kroz internet ili isti taj izdvojeni kanal.
Zatim se postavlja mreža za VM u oblaku. Strojevi obično prelaze u grupama i ne danima. Nakon što su VM-ovi prebačeni k nama i pokrenuti, moraju komunicirati sa strojevima koji još uvijek ostaju na izvornoj platformi.
- Raspored migracije. Kada je mnogo strojeva, razumno je podijeliti ih u grupe i prevoziti u partijama. Zajedno s klijentom dogovaramo plan u kojem navodimo kada i koji strojevi prelaze te kada će biti izvršena konačna replikacija i prebacivanje na novu platformu.
- Testna migracija. Migriramo testnu virtualnu mašinu i provjeravamo je li sve ispravno postavljeno: mrežna povezanost između lokacija, dostupnost virtualne mašine za mašine na izvornoj lokaciji, prava korisničkog računa i druge stvari. Ova vrsta testa pomaže u izbjegavanju zastoja tijekom stvarne migracije.
To bi bilo to s moje strane. Postavite pitanja u komentarima i podijelite svoja iskustva migracije.
Izvor: habr.com
