Prije otprilike 7 godina, prvi projekti su jednostavno i nepretenciozno prešli u naš oblak. Slike virtualnog stroja učitane su na FTP poslužitelj ili su isporučene na tvrdim diskovima. Zatim su putem posebnog poslužitelja za uvoz VM-ovi učitani u oblak.
Ako klijentu nije problem isključiti virtualni stroj na dan-dva (ili nema drugih opcija), onda se to može učiniti. Ali ako bi zastoj trebao biti najviše sat vremena, tada ova metoda neće raditi. Danas ću vam reći koji će vam alati pomoći da migrirate u oblak s minimalnim zastojem i kako funkcionira sam proces migracije.
Migracija s Veeam Backupom i replikacijom
Svima je poznat Veeam Backup and Replication kao alat za izradu sigurnosnih kopija i replika. Koristimo ga za migraciju između naših stranica i za prijenos klijenata iz privatne virtualizacije u naš oblak. Klijentova virtualna računala repliciraju se u naš vCenter, nakon čega ih inženjer dodaje u vCloud Director.
Primarna replikacija događa se na uključenom virtualnom računalu. U dogovoreno vrijeme stroj na strani klijenta se isključuje. Replikacija se ponovno pokreće kako bi se prenijele promjene koje su se dogodile od prve replikacije. Nakon toga, virtualni stroj se pokreće u našem oblaku.
Tipično, od trenutka kada se stroj isključi na infrastrukturi klijenta do trenutka kada se uključi u našem oblaku, ne prođe više od pola sata, već 15-20 minuta.
U tom slučaju izvorni virtualni stroj ostaje na klijentskom mjestu. Ako iznenada nešto pođe po zlu, uvijek se možete vratiti i uključiti. Ova metoda je također pogodna za klijenta jer ne zahtijeva da ima Veeam.
Slučaj 1
Klijent je imao vlastitu virtualnu infrastrukturu temeljenu na VMware-u - 40 VM-a kapaciteta 30 TB. Oprema na kojoj je klaster postavljen bila je već zastarjela, a klijent je odlučio ne zamarati se kupnjom nove i preselio se u javni oblak. Zahtjev za prekid rada za kritične sustave nije bio dulji od jednog sata. Kao alat odabran je Veeam Replication. Još jedan plus bio je to što je klijentov internet provider bio prisutan u našem podatkovnom centru, što je omogućilo organiziranje dobrog kanala. Migracija je trajala oko mjesec dana, vrijeme prekida tijekom prebacivanja bilo je do 30 minuta po grupi virtualnih strojeva.
Migracija uz Veeam Cloud Connect
Veeam Cloud Connect je alat koji vam pomaže postaviti replikaciju virtualnog stroja i pokrenuti replike u oblaku pružatelja usluga. Nakon ažuriranja na godine postalo je moguće replicirati virtualne strojeve izravno u vCloud Director. Jedini uvjet je da na strani klijenta Veeam Backup and Replication mora biti implementiran najmanje verzija 9. Ukratko (detaljna verzija ), onda cijeli proces izgleda ovako.
U vCloud Directoru stvara se organizacija s potrebnim resursima i mrežama. U Veeam Cloud Connectu kreiramo račun, klijent se na njega povezuje sa svog Veeam B&R-a, odabire DataLine davatelja i organizaciju te konfigurira zadatke za replikaciju. Uz činjenicu da će tijekom takve migracije zastoj biti unutar 15-20 minuta, klijent ni na koji način ne ovisi o tehničkoj podršci pružatelja usluga i samostalno upravlja cijelim procesom: stvara zadatke replikacije, samu replikaciju, isključuje strojeve i pokreće ih na novom mjestu.
Slučaj 2
Klijentova infrastruktura, odakle je planirana migracija, nalazila se u Bjelorusiji. Bilo je potrebno transportirati 90 VM-ova ukupnog volumena 27 TB, unatoč tome što je internetski kanal bio 100 Mbit/sec. Ako napravite sigurnosnu kopiju i odmah je postavite u naš oblak, onda bi za neke VM-ove trebalo nekoliko dana. Tijekom tog vremena, velika delta bi narasla na VM, a to bi moglo imati negativan utjecaj na izvedbu strojeva ili, još gore, ponestalo bi prostora u pohrani podataka. Nastavili smo na sljedeći način: prvo je klijent napravio lokalnu punu sigurnosnu kopiju i prenio kopiju u naš oblak putem Veeam Cloud Connecta. Zatim sam napravio i prenio prirast u oblak. Izvorni virtualni stroj nastavio je raditi. Nakon gašenja VM-a, klijent je napravio još jedan inkrement i također ga prenio u oblak. S naše strane, implementirali smo virtualni stroj iz pune sigurnosne kopije, a zatim smo na njega dodali dva inkrementa. Ova je shema u konačnici omogućila smanjenje vremena prekida rada na 2 sata pri prelasku na našu stranicu.
Migracija s dostupnošću VMware vCloud
U ožujku ove godine VMware je izdao vCloud Availability 3.0 koji vam omogućuje migraciju virtualnih strojeva između različitih oblaka (vCloud Director - vCloud Director) i s privatnih postolja za virtualizaciju klijenata u oblak (vCenter - vCloud Director). Glavna pogodnost je integracija sa sučeljem vCloud Director. Ovo uvelike pojednostavljuje proces upravljanja replikacijom i minimizira vrijeme prekida tijekom prijelaza.
Pomoću ovog alata premjestili smo jednog od klijenata iz oblaka u Moskvi u oblak u St. Petersburgu. Bilo je potrebno transportirati 18 virtualnih strojeva ukupnog kapaciteta 14 TB. Za klijenta je napravljena organizacija u St. Petersburg oblaku i organizirane su potrebne mreže. Zatim, iz vCloud Director sučelja, klijent je otišao na postavke vCloud Availability, kreirao poslove replikacije i prebacio se na stranicu St. Petersburg u vrijeme koje mu odgovara. Zastoj tijekom prebacivanja bio je 12 minuta.
Shema migracije između DataLine oblaka u St. Petersburgu i Moskvi.
vCloud Availability ima mehanizam za migraciju VM-a s klijentove stranice na naš oblak. Da biste to učinili, posebna aplikacija vCloud Availability postavlja se u klijentov vCenter. Nakon jednostavnog postavljanja, povezujete se s oblakom i konfigurirate zadatke migracije. Klijent također samostalno upravlja cijelim procesom, a vrijeme migracije svedeno je na minimum.
Shema za migraciju virtualnih strojeva iz privatne instalacije u oblak.
VMware vCloud Availability ima mnogo drugih slučajeva upotrebe; o njima ćemo uskoro govoriti u zasebnom članku.
Priprema za migraciju
Da biste odabrali alat i stvarno započeli migraciju, morate odlučiti o sljedećim točkama:
Odakle mi migriramo? Ako prelazite s privatnog rješenja, tada imate potpunu slobodu u odabiru alata. Ako se odmaknete od svog pružatelja usluga, onda je to kompliciranije. Najvjerojatnije, povezivanje infrastruktura dva pružatelja usluga i jednostavno povlačenje i ispuštanje VM-a neće funkcionirati zbog sigurnosnih razloga. Ponekad ponuđač kojeg se klijent sprema odbiti počne biti nestašan i odugovlači s vremenom. Možete se udaljiti od pružatelja na staromodan način: učitavanjem VM-ova na diskove i FTP ili migracijom na razini aplikacije. Naziv potonjeg je uvjetan i izgleda otprilike ovako.
Slučaj 3
Bilo je potrebno migrirati klijentov SAP sustav od europskog provajdera: 34 VM-a kapaciteta 54 TB. Klijentu su dodijeljeni resursi u našem oblaku. Organizirana je mrežna povezanost između nas i infrastrukture europskog providera. Aplikacijski poslužitelji su ponovno raspoređeni, s potrebnim konfiguracijama. Velike baze podataka migrirane su učitavanjem sigurnosnih kopija u naš oblak. Zatim je konfigurirana replikacija između baza podataka na našim i izvornim stranicama. U dogovoreno vrijeme prešli smo na baze podataka u našem oblaku.
Količina podataka i internetski kanal. Obično tražimo od klijenta da omogući prijenos po sustavu s parametrima memorije, procesora i diska. Procjenjujemo je li kanal dovoljan za izravno slanje replika ili sigurnosnih kopija virtualnih strojeva.
Prihvatljivo vrijeme zastoja. Za različite sustave i, sukladno tome, virtualne strojeve, može biti različito ovisno o njihovoj poslovnoj kritičnosti. Obično klijent dolazi s gotovim zahtjevima za vrijeme zastoja za migraciju, a na temelju toga odabiremo odgovarajući alat i plan migracije. Završno prebacivanje nastojimo planirati noću ili vikendom kako krajnji korisnici klijenta ne bi primijetili ni manje zastoje.
Na temelju tih podataka možete odabrati alat i započeti samu migraciju. Evo što se dalje događa.
- Postavljanje mrežne veze. Organiziramo mrežno povezivanje našeg oblaka i infrastrukture klijenta. Virtualni strojevi kopirat će se preko ove mreže. Ako se koristi Veeam Backup and Replication, onda je to namjenski kanal, rjeđe VPN kanal. Ako se Veeam Cloud Connect, onda sve ide putem interneta ili istog namjenskog kanala.
Zatim se mreža konfigurira za VM u oblaku. Automobili se obično kreću u grupama i više od jednog dana. Nakon što nam se VM-ovi donesu i pokrenu, oni moraju komunicirati sa strojevima koji su još uvijek na izvornom mjestu.
- Raspored migracije. Kada ima mnogo automobila, ima smisla podijeliti ih u grupe i prevoziti u serijama. Zajedno s klijentom dogovaramo plan u kojem određujemo kada i koji strojevi će se preseliti te kada će se izvršiti završna replikacija i prebacivanje na novu stranicu.
- Testna migracija. Migriramo testni virtualni stroj i provjeravamo je li sve ispravno konfigurirano: mrežna povezanost između stranica, dostupnost virtualnog stroja strojevima na izvornom mjestu, prava računa itd. Ovaj test pomaže u izbjegavanju zastoja u fazi borbene migracije.
To je sve za mene. U komentarima postavljajte pitanja i recite nam svoje iskustvo migracije.
Izvor: www.habr.com