{"id":96767,"date":"2020-10-14T14:43:02","date_gmt":"2020-10-14T12:43:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/hystax-cloud-migration-skachem-po-oblakam"},"modified":"2020-10-14T14:43:02","modified_gmt":"2020-10-14T12:43:02","slug":"hystax-cloud-migration-skachem-po-oblakam","status":"publish","type":"post","link":"https:\/\/prohoster.info\/hr\/blog\/administrirovanie\/hystax-cloud-migration-skachem-po-oblakam","title":{"rendered":"Hystax Cloud Migration: presko\u010dimo oblake","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Jedan od mladih igra\u010da na tr\u017ei\u0161tu rje\u0161enja za obnovu nakon katastrofe je tvrtka Hystax \u2013 ruski startup iz 2016. godine. Budu\u0107i da je tema obnavljanja nakon nesre\u0107e vrlo popularna, a konkurencija na tr\u017ei\u0161tu izuzetno visoka, startup je odlu\u010dio fokusirati se na migraciju izme\u0111u razli\u010ditih cloud infrastruktura. Proizvod koji omogu\u0107uje jednostavnu i brzu migraciju u oblak bio bi vrlo koristan i klijentima tvrtke \u201eOnlanta\u201c \u2013 korisnicima Oncloud.ru<\/a><\/noindex>. Tako sam se upoznao s Hystaxom i po\u010deo testirati njegove mogu\u0107nosti. A \u0161to je od toga proiza\u0161lo, ispri\u010dat \u0107u u ovom \u010dlanku.<\/p>\n

\"Hystax<\/a><\/noindex>
\nGlavna zna\u010dajka Hystaxa je njegova \u0161iroka funkcionalnost u podr\u0161ci razli\u010ditih virtualizacijskih platformi, gostuju\u0107ih operativnih sustava i obla\u010dnih servisa, \u0161to omogu\u0107ava prijenos va\u0161ih radnih optere\u0107enja odakle god i kamo god \u017eelite.<\/p>\n

To omogu\u0107ava stvaranje ne samo DR-rje\u0161enja za pobolj\u0161anje otpornosti usluga, ve\u0107 i brzu, fleksibilnu migraciju resursa izme\u0111u razli\u010ditih lokacija i hiperskalera radi pove\u0107anja u\u0161teda i odabira najboljeg rje\u0161enja za odre\u0111enu uslugu u tom trenutku. Osim platformi navedenih na naslovnoj slici, tvrtka tako\u0111er aktivno sura\u0111uje s ruskim obla\u010dnim pru\u017eateljima usluga: Yandex.Cloud, KROK \u201eObla\u010dne usluge\u201c, Mail.ru i mnogima drugima. Tako\u0111er, vrijedi spomenuti da je tvrtka 2020. godine otvorila R&D centar smje\u0161ten u Skolkovu.\u00a0<\/p>\n

Odabir jednog rje\u0161enja od strane velikog broja igra\u010da na tr\u017ei\u0161tu ukazuje na dobru cjenovnu politiku i visoku primjenjivost proizvoda, \u0161to smo odlu\u010dili provjeriti u praksi.<\/p>\n

Dakle, na\u0161 testni zadatak sastojat \u0107e se od migracije s moje testne platforme VMware i fizi\u010dkih strojeva na platformu pru\u017eatelja koja tako\u0111er koristi VMware. Da, postoji mnogo rje\u0161enja koja mogu omogu\u0107iti takvu migraciju, ali Hystax smatramo univerzalnim alatom, a testirati migraciju u svim mogu\u0107im kombinacijama jednostavno je nerealna zada\u0107a. \u0160tovi\u0161e, oblak Oncloud.ru izgra\u0111en je upravo na VMware-u, stoga nas ova platforma kao ciljana najvi\u0161e zanima. Nadalje, opisat \u0107u osnovni princip rada, koji u cjelini ne ovisi o platformi, a VMware se s bilo koje strane mo\u017ee zamijeniti platformom drugih pru\u017eatelja usluga.\u00a0<\/p>\n

U prvoj fazi potrebno je implementirati Hystax Acura, koja je upravlja\u010dka plo\u010da sustava.<\/p>\n

\"Hystax<\/a><\/noindex>
\nOna se implementira iz predlo\u0161ka. Iz nekog razloga, u na\u0161em slu\u010daju predlo\u017eak nije bio posve ispravan i umjesto preporu\u010denih 8CPU, 16Gb, implementirao se s dvostruko manjim resursima. Stoga je va\u017eno promijeniti ih, ina\u010de se infrastruktura unutar VM-a, na kojoj je sve izgra\u0111eno, jednostavno ne\u0107e pokrenuti i portal \u0107e biti nedostupan. U Zahtijevi za implementaciju<\/a><\/noindex> detaljno su opisani potrebni resursi, kao i portovi za sve komponente sustava.\u00a0<\/p>\n

I s postavljanjem IP adrese putem predlo\u0161ka tako\u0111er su nastali problemi, pa smo je promijenili iz konzole. Nakon toga, mo\u017eete pre\u0107i u web su\u010delje administratorske plo\u010de i ispuniti po\u010detnog \u010darobnjaka za konfiguraciju.\u00a0<\/p>\n

\"Hystax<\/a><\/noindex>
\n\"Hystax<\/a><\/noindex>
\nEndpoint \u2013 IP ili FQDN na\u0161eg vCenter-a.\u00a0
\nLogin i Password \u2013 ovdje su jasni.\u00a0
\nTarget ESXi hostname \u2013 jedan od hostova na\u0161eg klastera na koji \u0107e se vr\u0161iti replikacija.\u00a0
\nTarget datastore \u2013 jedan od datastore-ova na\u0161eg klastera na koji \u0107e se vr\u0161iti replikacija.
\nHystax Acura Control Panel Public IP \u2013 adresa na kojoj \u0107e biti dostupna upravlja\u010dka plo\u010da.<\/p>\n

Trebalo bi malo poja\u0161njenja oko hosta i datastore-a. Naime, replikacija Hystax radi na razini hosta i datastore-a. Kasnije \u0107u objasniti kako se za tenant mo\u017ee promijeniti host i datastore, ali problem je u ne\u010dem drugom. Hystax ne podr\u017eava rad s resursnim bazenima, tj. replikacija \u0107e se uvijek odvijati u korijenu klastera (u vrijeme pisanja ovog materijala, ljudi iz Hystax-a objavili su a\u017euriranu verziju u kojoj su brzo implementirali moj zahtjev za dodatkom podr\u0161ke za resursne bazene). Tako\u0111er ne podr\u017eava ni vCloud Director, tj. ako, kao u mom slu\u010daju, tenant nema administrativna prava na cijeli klaster, ve\u0107 samo na odre\u0111eni resursni bazen, i dali smo mu pristup Hystax-u, on \u0107e mo\u0107i samostalno replicirati i pokrenuti ove VM-ove, ali ih ne\u0107e mo\u0107i vidjeti u VMware infrastrukturi kojoj ima pristup i, sukladno tome, dalje upravljati virtualnim strojevima. Potrebno je da administrator klastera premjesti VM u odgovaraju\u0107i resursni bazen ili uveze u vCloud Director.<\/p>\n

Za\u0161to toliko nagla\u0161avam ove aspekte? Zato \u0161to, koliko sam shvatio koncept proizvoda, kupac bi trebao imati mogu\u0107nost samostalno provesti svaku migraciju ili DR putem Acura panela. No, podr\u0161ka za VMware pomalo zaostaje u odnosu na podr\u0161ku za OpenStack, gdje su sli\u010dni mehanizmi ve\u0107 implementirani.\u00a0<\/p>\n

Vratimo se postavljanju. Prvo, nakon inicijalne konfiguracije panela, moramo izraditi prvog tenanta u na\u0161em sustavu.<\/p>\n

\"Hystax<\/a><\/noindex>
\nSva polja ovdje su jasna, re\u0107i \u0107u samo ne\u0161to o polju Cloud. Ve\u0107 imamo 'default' oblak koji smo stvorili tijekom inicijalne konfiguracije. No, ako \u017eelimo imati mogu\u0107nost postavljanja svakog tenanta na vlastiti datastore i u vlastiti resursni bazen, mo\u017eemo to ostvariti kreiranjem posebnih oblaka za svakog od na\u0161ih kupaca.<\/p>\n

\"Hystax<\/a><\/noindex>
\nU obrascu za dodavanje novog oblaka navodimo iste parametre kao i prilikom inicijalne konfiguracije (mo\u017eemo koristiti \u010dak i isti host), navodimo potreban datastore za konkretnog kupca, a sada u dodatnim parametrima mo\u017eemo ve\u0107 individualno navesti potreban resursni bazen {\u00abresource_pool\u00bb: \u00abYOUR_POOL_NAME\u00bb}\u00a0<\/p>\n

Kao \u0161to ste mogli primijetiti, u obrascu za izradu tenanta nema ni\u0161ta o dodjeli resursa ili bilo kakvim kvotama \u2013 ni\u0161ta od toga u sustavu ne postoji. Nije mogu\u0107e ograni\u010diti tenanta u broju istodobnih replikacija, broju ra\u010dunala za replikaciju ili prema nekim drugim parametrima. Dakle, izradili smo prvog tenanta. Sada postoji ne ba\u0161 logi\u010dna, ali obavezna stvar \u2013 instalacija Cloud-agenta. Nelogi\u010dna je jer se agent preuzima na stranici odre\u0111enog korisnika.<\/p>\n

\"Hystax<\/a><\/noindex>
\nPri tome se ne vezuje za stvoreni tenant, a preko njega \u0107e raditi svi na\u0161i korisnici (ili kroz nekoliko, ako ih implementiramo). Jedan agent podr\u017eava 10 istovremenih sesija. Jedna sesija se smatra jednom ma\u0161inom. Pri tome nije va\u017eno koliko ima diskova. Trenutno ne postoji mehanizam za skaliranje agenata unutar same Acura pod VMware. Postoji jo\u0161 jedan nezgodan trenutak \u2013 nemamo mogu\u0107nost iz panela Acura da pogledamo na 'iskori\u0161tenost' ovog agenta, kako bismo donijeli zaklju\u010dak treba li nam jo\u0161 jedan ili je trenutna instalacija dovoljna. Na kraju, postavka izgleda ovako:<\/p>\n

\"Hystax<\/a><\/noindex>
\nSljede\u0107i korak za pristup portalu na\u0161eg kupca je stvaranje korisni\u010dkog ra\u010duna (a prethodno jo\u0161 i uloge koja \u0107e se primjenjivati na tog korisnika).<\/p>\n

\"Hystax<\/a><\/noindex>
\n\"Hystax<\/a><\/noindex>
\nSada na\u0161 kupac mo\u017ee samostalno koristiti portal. Sve \u0161to treba u\u010diniti je preuzeti agente s portala i instalirati ih s njegove strane. Postoje tri vrste agenata: Linux, Windows i VMware.<\/p>\n

\"Hystax<\/a><\/noindex>
\nPrva dva se instaliraju na fizi\u010dke ili virtualne ma\u0161ine na bilo kojem hipervizoru osim VMware. Ovdje nije potrebno dodatno ni\u0161ta konfigurirati, agent se preuzima i ve\u0107 zna kamo treba da se javi, i doslovno za minutu ma\u0161ina \u0107e biti vidljiva u panelu Acura. Situacija s VMware agentom je malo slo\u017eenija. Problem je u tome \u0161to se agent za VMware tako\u0111er preuzima s portala ve\u0107 pripremljen i sa potrebnom konfiguracijom. No, agentu VMware osim znanja o na\u0161em portalu Acura, potrebno je znati jo\u0161 i o sustavu virtualizacije na kojem \u0107e biti implementiran.<\/p>\n

\"Hystax<\/a><\/noindex>
\nU su\u0161tini, te podatke sustav \u0107e nas tra\u017eiti da navedemo pri prvom preuzimanju VMware agenta. Problem je u tome \u0161to u na\u0161em dobu op\u0107e ljubavi prema sigurnosti, daleko nije svatko voljan navesti svoju adminsitratorsku lozinku na tu\u0111em portalu, \u0161to je sasvim razumljivo. Nakon implementacije, agenta vi\u0161e nije mogu\u0107e dodatno konfigurirati (mo\u017ee se samo promijeniti njegovo mre\u017eno pode\u0161avanje). Ovdje predvi\u0111am pote\u0161ko\u0107e s posebno opreznim kupcima.\u00a0<\/p>\n

Dakle, nakon instalacije agenata mo\u017eemo se vratiti u panel Acura i vidjeti sve na\u0161e ma\u0161ine.<\/p>\n

\"Hystax<\/a><\/noindex>
\nBudu\u0107i da ve\u0107 nekoliko dana radim sa sustavom, imam strojeve u razli\u010ditim stanjima. Svi se nalaze u grupi Default, ali postoji mogu\u0107nost stvaranja zasebnih grupa i premje\u0161tanja strojeva u njih, prema va\u0161im potrebama. To ne utje\u010de na ni\u0161ta \u2013 samo logi\u010dko predstavljanje podataka i njihovo grupiranje za lak\u0161e rukovanje. Prvo i najva\u017enije, \u0161to trebamo u\u010diniti nakon toga, jest pokrenuti proces migracije. To mo\u017eemo u\u010diniti ru\u010dno, prisilno, ili postaviti raspored, uklju\u010duju\u0107i i masovno za sve strojeve odjednom.<\/p>\n

\"Hystax<\/a><\/noindex>
\nPodsje\u0107am da se Hystax pozicionirao kao proizvod za migraciju. Stoga nije ni\u0161ta neobi\u010dno \u0161to za pokretanje na\u0161ih repliciranih strojeva trebamo stvoriti DR-plan. Plan se mo\u017ee sastaviti za strojeve koji su ve\u0107 u stanju Synced. Mo\u017ee se generirati za jednu odre\u0111enu VM ili za sve strojeve odjednom.<\/p>\n

\"Hystax<\/a><\/noindex>
\nSkup parametara pri generiranju DR-plana razlikovat \u0107e se ovisno o infrastrukturi u koju \u0107ete migrirati. Za VMware okru\u017eenje dostupna je minimalna skupina parametara. Tako\u0111er, Re-IP nije podr\u017ean za strojeve. U ovom planu zanimaju nas sljede\u0107e to\u010dke: u opisu VM parametar \u201esubnet\u201d: \u201eVMNetwork\u201d, gdje povezujemo VM s odre\u0111enom mre\u017eom u klasteru. Rank \u2013 va\u017ean je pri migraciji vi\u0161e VM, odre\u0111uje redoslijed njihova pokretanja. Flavor \u2013 opisuje konfiguraciju VM, u ovom slu\u010daju \u2013 1CPU, 2GB RAM. U sekciji subnets definiramo da je \u201esubnet\u201d: \u201eVMNetwork\u201d povezan s mre\u017eom \u201eVM Network\u201d VMware.\u00a0<\/p>\n

Pri stvaranju DR-plana nema mogu\u0107nosti \u201erasporediti\u201d diskove po razli\u010ditim datastorima. Oni \u0107e biti na istom datastoru koji je definiran za ovo klijentovo oblake, a ako imate diskove razli\u010ditih klasa, to mo\u017ee izazvati odre\u0111ene pote\u0161ko\u0107e prilikom pokretanja stroja, a nakon pokretanja i \u201eotcjepljenja\u201d VM od Hystax, bit \u0107e potrebna jo\u0161 jedna migracija diskova na potrebne datastore. Onda nam preostaje samo pokrenuti na\u0161 DR-plan i \u010dekati da se na\u0161i strojevi podignu. Proces konverzije P2V\/V2V tako\u0111er traje vrijeme. Na najve\u0107em mom testnom stroju od 100 GB s tri diska, to je trajalo maksimalno 10 minuta.<\/p>\n

\"Hystax<\/a><\/noindex>
\nNakon toga potrebno je provjeriti pokrenutu VM, usluge na njoj, konzistentnost podataka i obaviti ostale provjere.\u00a0<\/p>\n

Imaju\u0107i to u vidu, imamo dva puta:\u00a0<\/p>\n

    \n
  1. Obri\u0161i \u2013 uklonite pokrenuti DR plan. Ova radnja jednostavno isklju\u010duje pokrenutu VM. Podaci replikacije ne\u0107e nestati.\u00a0<\/li>\n
  2. Odvoji \u2013 odvojite replikacijsku ma\u0161inu od Acura, tj. zapravo zavr\u0161ite proces migracije.\u00a0<\/li>\n<\/ol>\n

    \nPrednosti rje\u0161enja:<\/strong>\u00a0<\/p>\n