Hystax Cloud Migration: preskočimo oblake

Jedan od mladih igrača na tržištu rješenja za oporavak nakon katastrofa je tvrtka Hystax – ruski startup iz 2016. godine. S obzirom na to da je tema oporavka nakon katastrofa vrlo popularna, a konkurencija na tržištu izuzetno visoka, startup je odlučio fokusirati se na migraciju između različitih oblaka. Proizvod koji omogućuje jednostavnu i brzu migraciju u oblak bio bi vrlo koristan i klijentima tvrtke „Onlanta“ — korisnicima. Oncloud.ru. Tako sam se upoznao s Hystaxom i počeo testirati njegove mogućnosti. A što je od toga proizašlo, ispričat ću u ovom članku.

Hystax Cloud Migration: preskočimo oblake
Glavna značajka Hystaxa je njegova široka funkcionalnost u podršci različitih virtualizacijskih platformi, gostujućih operativnih sustava i oblačnih servisa, što omogućava prijenos vaših radnih opterećenja odakle god i kamo god želite.

To omogućava stvaranje ne samo DR-rješenja za poboljšanje otpornosti usluga, već i brzu, fleksibilnu migraciju resursa između različitih lokacija i hiperskalera radi povećanja ušteda i odabira najboljeg rješenja za određenu uslugu u tom trenutku. Osim platformi navedenih na naslovnoj slici, tvrtka također aktivno surađuje s ruskim oblačnim pružateljima usluga: Yandex.Cloud, KROK „Oblačne usluge“, Mail.ru i mnogima drugima. Također, vrijedi spomenuti da je tvrtka 2020. godine otvorila R&D centar smješten u Skolkovu. 

Odabir jednog rješenja od strane velikog broja igrača na tržištu ukazuje na dobru cjenovnu politiku i visoku primjenjivost proizvoda, što smo odlučili provjeriti u praksi.

Dakle, naš testni zadatak sastojat će se od migracije s moje testne platforme VMware i fizičkih strojeva na platformu pružatelja koja također koristi VMware. Da, postoji mnogo rješenja koja mogu omogućiti takvu migraciju, ali Hystax smatramo univerzalnim alatom, a testirati migraciju u svim mogućim kombinacijama jednostavno je nerealna zadaća. Štoviše, oblak Oncloud.ru izgrađen je upravo na VMware-u, stoga nas ova platforma kao ciljana najviše zanima. Nadalje, opisat ću osnovni princip rada, koji u cjelini ne ovisi o platformi, a VMware se s bilo koje strane može zamijeniti platformom drugih pružatelja usluga. 

U prvoj fazi potrebno je implementirati Hystax Acura, koja je upravljačka ploča sustava.

Hystax Cloud Migration: preskočimo oblake
Ona se implementira iz predloška. Iz nekog razloga, u našem slučaju predložak nije bio posve ispravan i umjesto preporučenih 8CPU, 16Gb, implementirao se s dvostruko manjim resursima. Stoga je važno promijeniti ih, inače se infrastruktura unutar VM-a, na kojoj je sve izgrađeno, jednostavno neće pokrenuti i portal će biti nedostupan. U Zahtijevi za implementaciju detaljno su opisani potrebni resursi, kao i portovi za sve komponente sustava. 

I s postavljanjem IP adrese putem predloška također su nastali problemi, pa smo je promijenili iz konzole. Nakon toga, možete preći u web sučelje administratorske ploče i ispuniti početnog čarobnjaka za konfiguraciju. 

Hystax Cloud Migration: preskočimo oblake
Hystax Cloud Migration: preskočimo oblake
Endpoint – IP ili FQDN našeg vCenter-a. 
Login i Password – ovdje su jasni. 
Target ESXi hostname – jedan od hostova našeg klastera na koji će se vršiti replikacija. 
Target datastore – jedan od datastore-ova našeg klastera na koji će se vršiti replikacija.
Hystax Acura Control Panel Public IP – adresa na kojoj će biti dostupna upravljačka ploča.

Trebalo bi malo pojašnjenja oko hosta i datastore-a. Naime, replikacija Hystax radi na razini hosta i datastore-a. Kasnije ću objasniti kako se za tenant može promijeniti host i datastore, ali problem je u nečem drugom. Hystax ne podržava rad s resursnim bazenima, tj. replikacija će se uvijek odvijati u korijenu klastera (u vrijeme pisanja ovog materijala, ljudi iz Hystax-a objavili su ažuriranu verziju u kojoj su brzo implementirali moj zahtjev za dodatkom podrške za resursne bazene). Također ne podržava ni vCloud Director, tj. ako, kao u mom slučaju, tenant nema administrativna prava na cijeli klaster, već samo na određeni resursni bazen, i dali smo mu pristup Hystax-u, on će moći samostalno replicirati i pokrenuti ove VM-ove, ali ih neće moći vidjeti u VMware infrastrukturi kojoj ima pristup i, sukladno tome, dalje upravljati virtualnim strojevima. Potrebno je da administrator klastera premjesti VM u odgovarajući resursni bazen ili uveze u vCloud Director.

Zašto toliko naglašavam ove aspekte? Zato što, koliko sam shvatio koncept proizvoda, kupac bi trebao imati mogućnost samostalno provesti svaku migraciju ili DR putem Acura panela. No, podrška za VMware pomalo zaostaje u odnosu na podršku za OpenStack, gdje su slični mehanizmi već implementirani. 

Vratimo se postavljanju. Prvo, nakon inicijalne konfiguracije panela, moramo izraditi prvog tenanta u našem sustavu.

Hystax Cloud Migration: preskočimo oblake
Sva polja ovdje su jasna, reći ću samo nešto o polju Cloud. Već imamo 'default' oblak koji smo stvorili tijekom inicijalne konfiguracije. No, ako želimo imati mogućnost postavljanja svakog tenanta na vlastiti datastore i u vlastiti resursni bazen, možemo to ostvariti kreiranjem posebnih oblaka za svakog od naših kupaca.

Hystax Cloud Migration: preskočimo oblake
U obrascu za dodavanje novog oblaka navodimo iste parametre kao i prilikom inicijalne konfiguracije (možemo koristiti čak i isti host), navodimo potreban datastore za konkretnog kupca, a sada u dodatnim parametrima možemo već individualno navesti potreban resursni bazen {«resource_pool»: «YOUR_POOL_NAME»} 

Kao što ste mogli primijetiti, u obrascu za izradu tenanta nema ništa o dodjeli resursa ili bilo kakvim kvotama – ništa od toga u sustavu ne postoji. Nije moguće ograničiti tenanta u broju istodobnih replikacija, broju računala za replikaciju ili prema nekim drugim parametrima. Dakle, izradili smo prvog tenanta. Sada postoji ne baš logična, ali obavezna stvar – instalacija Cloud-agenta. Nelogična je jer se agent preuzima na stranici određenog korisnika.

Hystax Cloud Migration: preskočimo oblake
Pri tome se ne vezuje za stvoreni tenant, a preko njega će raditi svi naši korisnici (ili kroz nekoliko, ako ih implementiramo). Jedan agent podržava 10 istovremenih sesija. Jedna sesija se smatra jednom mašinom. Pri tome nije važno koliko ima diskova. Trenutno ne postoji mehanizam za skaliranje agenata unutar same Acura pod VMware. Postoji još jedan nezgodan trenutak – nemamo mogućnost iz panela Acura da pogledamo na 'iskorištenost' ovog agenta, kako bismo donijeli zaključak treba li nam još jedan ili je trenutna instalacija dovoljna. Na kraju, postavka izgleda ovako:

Hystax Cloud Migration: preskočimo oblake
Sljedeći korak za pristup portalu našeg kupca je stvaranje korisničkog računa (a prethodno još i uloge koja će se primjenjivati na tog korisnika).

Hystax Cloud Migration: preskočimo oblake
Hystax Cloud Migration: preskočimo oblake
Sada naš kupac može samostalno koristiti portal. Sve što treba učiniti je preuzeti agente s portala i instalirati ih s njegove strane. Postoje tri vrste agenata: Linux, Windows i VMware.

Hystax Cloud Migration: preskočimo oblake
Prva dva se instaliraju na fizičke ili virtualne mašine na bilo kojem hipervizoru osim VMware. Ovdje nije potrebno dodatno ništa konfigurirati, agent se preuzima i već zna kamo treba da se javi, i doslovno za minutu mašina će biti vidljiva u panelu Acura. Situacija s VMware agentom je malo složenija. Problem je u tome što se agent za VMware također preuzima s portala već pripremljen i sa potrebnom konfiguracijom. No, agentu VMware osim znanja o našem portalu Acura, potrebno je znati još i o sustavu virtualizacije na kojem će biti implementiran.

Hystax Cloud Migration: preskočimo oblake
U suštini, te podatke sustav će nas tražiti da navedemo pri prvom preuzimanju VMware agenta. Problem je u tome što u našem dobu opće ljubavi prema sigurnosti, daleko nije svatko voljan navesti svoju adminsitratorsku lozinku na tuđem portalu, što je sasvim razumljivo. Nakon implementacije, agenta više nije moguće dodatno konfigurirati (može se samo promijeniti njegovo mrežno podešavanje). Ovdje predviđam poteškoće s posebno opreznim kupcima. 

Dakle, nakon instalacije agenata možemo se vratiti u panel Acura i vidjeti sve naše mašine.

Hystax Cloud Migration: preskočimo oblake
Budući da već nekoliko dana radim sa sustavom, imam strojeve u različitim stanjima. Svi se nalaze u grupi Default, ali postoji mogućnost stvaranja zasebnih grupa i premještanja strojeva u njih, prema vašim potrebama. To ne utječe na ništa – samo logičko predstavljanje podataka i njihovo grupiranje za lakše rukovanje. Prvo i najvažnije, što trebamo učiniti nakon toga, jest pokrenuti proces migracije. To možemo učiniti ručno, prisilno, ili postaviti raspored, uključujući i masovno za sve strojeve odjednom.

Hystax Cloud Migration: preskočimo oblake
Podsjećam da se Hystax pozicionirao kao proizvod za migraciju. Stoga nije ništa neobično što za pokretanje naših repliciranih strojeva trebamo stvoriti DR-plan. Plan se može sastaviti za strojeve koji su već u stanju Synced. Može se generirati za jednu određenu VM ili za sve strojeve odjednom.

Hystax Cloud Migration: preskočimo oblake
Skup parametara pri generiranju DR-plana razlikovat će se ovisno o infrastrukturi u koju ćete migrirati. Za VMware okruženje dostupna je minimalna skupina parametara. Također, Re-IP nije podržan za strojeve. U ovom planu zanimaju nas sljedeće točke: u opisu VM parametar „subnet”: „VMNetwork”, gdje povezujemo VM s određenom mrežom u klasteru. Rank – važan je pri migraciji više VM, određuje redoslijed njihova pokretanja. Flavor – opisuje konfiguraciju VM, u ovom slučaju – 1CPU, 2GB RAM. U sekciji subnets definiramo da je „subnet”: „VMNetwork” povezan s mrežom „VM Network” VMware. 

Pri stvaranju DR-plana nema mogućnosti „rasporediti” diskove po različitim datastorima. Oni će biti na istom datastoru koji je definiran za ovo klijentovo oblake, a ako imate diskove različitih klasa, to može izazvati određene poteškoće prilikom pokretanja stroja, a nakon pokretanja i „otcjepljenja” VM od Hystax, bit će potrebna još jedna migracija diskova na potrebne datastore. Onda nam preostaje samo pokrenuti naš DR-plan i čekati da se naši strojevi podignu. Proces konverzije P2V/V2V također traje vrijeme. Na najvećem mom testnom stroju od 100 GB s tri diska, to je trajalo maksimalno 10 minuta.

Hystax Cloud Migration: preskočimo oblake
Nakon toga potrebno je provjeriti pokrenutu VM, usluge na njoj, konzistentnost podataka i obaviti ostale provjere. 

Imajući to u vidu, imamo dva puta: 

  1. Obriši – uklonite pokrenuti DR plan. Ova radnja jednostavno isključuje pokrenutu VM. Podaci replikacije neće nestati. 
  2. Odvoji – odvojite replikacijsku mašinu od Acura, tj. zapravo završite proces migracije. 

Prednosti rješenja: 

  • jednostavnost instalacije i postavljanja s obje strane, kako s korisničke tako i s pružateljske strane; 
  • jednostavnost postavljanja migracije, izrade DR plana i pokretanja replikacija;
  • podrška i programeri prilično brzo reagiraju na pronađene probleme i rješavaju ih putem ažuriranja platforme ili agenta. 

Nedostaci 

  • Nedovoljna podrška za Vmware.
  • Nedostatak bilo kakvog kvotiranja za tenant-e sa strane platforme. 

Također sam sastavio Feature Request koji smo poslali dobavljaču:

  1. monitoring korištenja i implementacija iz upravljačke konzole Acura za Cloud agente;
  2. postojanje kvota za tenant-e; 
  3. mogućnost ograničenja broja istovremenih replikacija i brzine za svakog tenant-a; 
  4. podrška za VMware vCloud Director; 
  5. podrška za resursne bazene (realizirano tijekom testiranja);
  6. mogućnost postavljanja VMware agenta sa strane samog agenta, bez unosa podataka iz korisničke infrastrukture u Acura panel;
  7.  vizualizacija procesa pokretanja VM prilikom pokretanja DR plana. 

Jedino što mi je zadalo velike prigovore – dokumentacija. Ne volim "crne kutije" i preferiram detaljnu dokumentaciju o tome kako proizvod djeluje iznutra. I dok je za AWS i OpenStack proizvod opisano više-manje, za VMware dokumentacije je izuzetno malo. 

Postoji Installation Guide koji opisuje samo implementaciju Acura panela, i gdje nema ni riječi o tome da je potreban i Cloud agent. Ima potpuni skup specifikacija za proizvod, što je dobro. Tu je dokumentacija koja opisuje postavke "od početka do kraja" na primjeru AWS i OpenStack (iako mi više nalikuje na blog članak), te postoji vrlo mala Baza znanja. 

Općenito, to nije baš format dokumentacije na koji sam navikao, recimo, kod većih dobavljača, stoga mi nije bilo baš ugodno. Ipak, odgovore o nekim nijansama rada sustava "iznutra" nisam uspio pronaći u ovoj dokumentaciji – puno pitanja sam morao razjašnjavati s tehničkom podrškom, što je prilično usporilo proces postavljanja i provođenja testiranja. 

Sumirajući, mogu reći da mi se u cjelini svidio proizvod i pristup tvrtke u rješavanju zadatka. Da, postoje nedostaci, postoji stvarno kritična dovoljnost funkcionalnosti (u suradnji s VMware-om). Vidljivo je da se tvrtka prije svega usredotočuje na javna oblaka, posebno AWS, i za neke će to biti dovoljno. Imati tako jednostavan i praktičan proizvod danas, kada mnoge tvrtke biraju višestrategiju oblaka, izuzetno je važno. Uzimajući u obzir znatno nižu cijenu u odnosu na konkurenciju, to čini proizvod vrlo privlačnim.

Tražimo novog člana našeg tima voditelja inženjera sustava nadzora. Možda ste to baš vi?

Izvor: habr.com

Kupite pouzdan hosting za web stranice s DDoS zaštitom, VPS VDS servere 🔥 Kupite pouzdan hosting za web stranice s DDoS zaštitom, VPS VDS servere | ProHoster