🥇Hystax Cloud Migration: hüppame pilvedes

Üks nooremaid mängijaid katastroofide taastamise lahenduste turul on Hystax – Venemere start-up aastast 2016. Kuna katastroofide taastamise teema on väga populaarne ja turul on äärmiselt kõrge konkurents, otsustas start-up keskenduda migratsioonile erinevate pilveteenuste vahel. Toode, mis võimaldab korraldada lihtsat ja kiiret migratsiooni pilve, oleks väga kasulik ka 'Onlanta' klientidele – kasutajatele. Oncloud.ru. Nii tutvustasin ma Hystaxit ja hakkasin testima selle võimalusi. Kuidas mul see läks, räägin sellest artiklis.

Hystaxi peamine eelis on selle ulatuslik funktsionaalsus erinevate virtualiseerimise platvormide, külalissüsteemide ja pilveteenuste toetamisel, mis võimaldab transportida teie töökoormusi kõikjalt ja igale poole.

See võimaldab luua mitte ainult DR-lahendusi teenuste töökindluse tõstmiseks, vaid ka kiiresti ja paindlikult migreerida ressursse erinevate platvormide ja hüpermälu vahel, et säästa raha ning valida parim lahendus konkreetse teenuse jaoks antud hetkel. Lisaks platvormidele, mis on loetletud pealkirja pildil, teeb ettevõte aktiivselt koostööd ka Venemere pilveteenuse pakkujatega: Yandex.Cloud, KROK 'Pilveteenused', Mail.ru ja paljude teistega. Tasub märkida, et 2020. aastal avas ettevõte R&D keskuse, mis asub Skolkovo's.

Ühe lahenduse valik suure arvu turul olevate mängijate poolt näitab head hinnapoliitikat ja kõrget toote rakendatavust, mida otsustasime praktikas kontrollida.

Niisiis, meie testülesanne koosneb migratsioonist minu testimisplatvormilt VMware ja füüsilistelt masinatelt teenusepakkuja platvormile, mis töötab samuti VMware all. Jah, on palju lahendusi, mis suudavad sellist migratsiooni teostada, kuid me käsitleme Hystaxit universaalse vahendina, ja migreerimine kõigis võimalikes kombinatsioonides on lihtsalt uskumatu ülesanne. Oncloud.ru pilv on üles ehitatud just VMware-ile, seega huvitab meid see platvorm sihtkohana rohkem. Edasi kirjeldan põhimeetodit, mille tööpõhimõte ei sõltu üldiselt platvormist, ning VMware'i võib igal ajal asendada muu tootja platvormiga.

Esimese sammuna tuleb üles seada Hystax Acura, mis on süsteemi halduspaneel.

See seadistatakse mallist. Miks see meie puhul ei olnud täiesti korrektne ja soovitatud 8 CPU, 16 GB asemel seadistati poole väiksemate ressurssidega, on teadmata. Seetõttu ei tohi unustada neid muuta; vastasel juhul ei käivitu infrastruktuur lihtsalt VM-s, millele kõik rajatud, ja portaal pole kergesti ligipääsetav. Paigaldamise nõuded on üksikasjalikult kirjeldatud nõutavad ressursid ja kõikide süsteemi komponentide pordid.

Ja IP-aadressi määramine läbi malli osutus samuti keeruliseks, nii et muutsime seda konsoolist. Pärast seda saab liikuda administraatori veebiliidesesse ja täita esialgse seadistuse wizardit.

Lõpp-punkt – meie vCenteri IP või FQDN.
Kasutajanimi ja parool – see on aru saadav.
Siht-ESXi hostinimi – üks meie klastrite hostidest, kuhu toimub replikatsioon.
Siht-datastore – üks meie klastrite datastooridest, kuhu replikatsioon toimub.
Hystax Acura juhtpaneeli avalik IP – aadress, mille kaudu juhtpaneel on kergesti ligipääsetav.

Vaja on väikest täpsustust hosti ja datastoori osas. Asi on selles, et Hystaxi replikatsioon töötab hosti ja datastoori tasemel. Edasi räägin, kuidas rentnik saab hosti ja datastoori vahetada, aga probleem on muus. Hystax ei toeta töö tegemist ressursipoolidega, st replikatsioon toimub alati klastrite juures (artikli kirjutamise ajal väljastasid Hystaxi töötajad uuendatud versiooni, kus nad kiiresti integreerisid mu funktsioonitaotluse ressursipoolide toe osas). Samuti ei toeta see vCloud Directorit, st kui, nagu minu puhul, ei ole rentnikul administraatori õigusi kogu klastris, vaid ainult konkreetse ressursipooli osas, ja me andsime ligipääsu Hystaxile, siis saab ta iseseisvalt replitseerimist ja nende VM-de käivitamist teha, kuid ei suuda neid näha VMware infrastruktuuris, kuhu tal on ligipääs ja seega ka järgnevalt virtuaalmasinate haldamiseks. On vajalik, et klastri administraator liigutaks VM-i vajalikku ressursipoolis või importiks selle vCloud Directorisse.

Miks ma sellele tähelepanu juhin? Sest nii palju, kui ma toote kontseptsiooni mõistan, peaks kliendil olema võimalus iseseisvalt teostada igasuguseid migreerimisi või DR-i Acura paneeli abil. Kuid praegu jääb VMware tugi pisut maha sama OpenStacki toe tasemest, kus sellised mehhanismid on juba ellu viidud.

Kuid pöördume tagasi paigaldamise juurde. Esiteks, pärast paneeli esialgset seadistamist peame looma meie süsteemis esimese rendi.

Kõik väljundid siin on selged, räägin ainult Cloud väli kohta. Meil on juba «vaikimisi» pilv, mille meie esialgse konfigureerimise käigus lõime. Kuid kui me soovime võimalust paigutada iga rendi oma andmehoidlasse ja oma ressursikogusse, saame selle ellu viia, luues iga meie kliendi jaoks eraldi pilved.

Uue pilve lisamise vormis näitame samu parameetreid nagu esialgse konfigureerimise käigus (võime isegi sama hosti kasutada), määrame konkreetse kliendi jaoks vajaliku andmehoidla ja nüüd võime täiendavates parameetrites individuaalselt määrata vajalikku ressursikogusse {«resource_pool»: «YOUR_POOL_NAME»}.

Nagu olete ehk märganud, pole rendi loomise vormis midagi ressursside eraldamise või mingite kvotade kohta – süsteemis pole midagi sellist. Rendile ei saa piirata samaaegsete replikate arvu, replikeerimiseks mõeldud masinate arvu ega mingite muude parameetrite alusel. Nii et oleme loonud esimese rendi. Nüüd on olemas mitte just loogiline, aga vajalik asi – Cloud-agendi paigaldamine. See on ebaloogiline, kuna agent laaditakse alla konkreetse kliendi lehelt.

Selle protsessi käigus ei ole ta seotud loodud tenantiga, ning selle kaudu saavad töötada kõik meie kliendid (või mitu, kui me need deployime). Üks agent toetab 10 samaaegset sessiooni. Ühe sessiooni alla kuulub üks masin, olenemata selle ketaste arvust. Tänaseks, agentide skaleerimise mehhanismi Acura sees VMware'i jaoks ei ole. On veel üks ebameeldiv aspekt – meil pole võimalust Acura paneelist näha selle agendi 'kasutust', et teha järeldus, kas me vajame veel ühte või kas praegusest installatsioonist piisab. Lõpuks näeb stand välja järgmiselt:

Järgmiseks sammuks meie kliendi portaali juurde pääsemiseks on konto loomine (enne tuleb luua ka roll, mis sellele kasutajale rakendatakse).

Nüüd saab meie klient portaali iseseisvalt kasutada. Kõik, mida tal on vaja teha, on agentsite allalaadimine portaali kaudu ja nende paigaldamine enda poole. On kolm tüüpi agente: Linux, Windows ja VMware.

Esimeseid kahte saab paigaldada füüsilistele masinatele või mis tahes hüpervõrgustikus olevatele virtuaalmasinatele, välja arvatud VMware. Siin ei ole lisaks vajalik mingit konfigureerimist, agent allalaaditakse ja juba teab, kuhu suunduda, ja mõne minuti pärast on masin nähtav Acura paneelis. VMware agendi olukord on veidi keerulisem. Probleemiks on see, et VMware agent allalaaditakse portaalist koos vajaliku konfiguratsiooniga. Kuid VMware agendil, lisaks teadmisele meie Acura portaalist, peab olema ka teadlikkus virtualiseerimissüsteemist, millele see paigaldatakse.

Tegelikult küsib süsteem neid andmeid meie käest esmakordsel VMware agendi allalaadimisel. Probleem on selles, et meie kaasaegses julgeolekule orienteeritud maailmas ei soovi paljud inimesed jagada oma administreerimissekretäri parooli võõral portaalil, mis on täiesti arusaadav. Seestpoolt, pärast paigaldamist, ei saa agendi üle enam konfigureerida (ainult võib muuta selle võrgu seadeid). Siin ennustan ma raskusi erilise ettevaatlikkuse tõttu klientidega.

Nii et pärast agentide paigaldamist saame naasta Acura paneeli ja näha kõiki meie masinaid.

Kuna ma olen juba pikka aega selle süsteemiga töötanud, on mul masinaid erinevates olekutes. Kõik need asuvad mul grupis Default, kuid on võimalik luua eraldi gruppe ja üle kanda masinad sinna vastavalt vajadusele. See ei mõjuta midagi – see on vaid andmete loogiline esitamine ja rühmitamine mugavamaks tööks. Esimene ja kõige olulisem asi, mida peame pärast seda tegema, on migratsiooniprotsessi käivitamine. Saame seda teha nii sundkorras käsitsi kui ka seadistada ajakava, sealhulgas massiliselt kõigi masinate jaoks korraga.

Tuletan meelde, et Hystax positsioneeris end migratsioonitootena. Seetõttu ei ole midagi üllatavat, et meie kopeeritud masinate käivitamiseks on vajalik DR-plaani koostamine. Plaani saab koostada masinate jaoks, mis on juba olekus Synced. Saame genereerida plaani nii ühe konkreetse virtuaalmachi jaoks kui ka kohe kõigi masinate jaoks.

DR-plaani genereerimise parameetrite komplekt sõltub infrastuktuurist, kuhu te migreerite. VMware keskkonnas on saadaval minimaalne parameetrite komplekt. Samuti ei toeta Re-IP masinate jaoks. Antud plaanis on meil huvitavad järgmised punktid: virtuaalmasina (VM) kirjelduses on parameeter „subnet”: „VMNetwork”, kus seome VM konkreetse võrgu külge klastris. Rank – on oluline mitme VM migreerimise korral, määrab nende käivitamise järjekorra. Flavor – kirjeldab VM konfiguratsiooni, antud juhul – 1CPU, 2GB RAM. Subnetide sektsioonis määrame, et „subnet”: „VMNetwork” on seotud VMware võrgu „VM Network”.

DR-plaani koostamisel ei ole võimalik ‘jagada’ kettaid erinevatele datastooridele. Need jäävad samasse datastoori, mis on määratud sellele kliendi pilve, ja kui teil on erineva klassiga kettad, võib see tekitada teatud raskusi masina käivitamisel ning pärast masina käivitamist ja Hystaxist eemaldamist vajab see ka eraldi ketaste migratsiooni vajalikesse datastooridesse. Edasi jääb ainult meie DR-plaan käivitada ja oodata, kuni meie masinad tõusevad. P2V/V2V konverteerimise protsess võtab samuti aega. Minu suurimas testmasinas, mille maht on 100GB ja millel on kolm ketast, kestis see maksimaalselt 10 minutit.

Pärast seda tuleb kontrollida käivitatud virtuaalmachi, teenuseid sellel, andmete järjekindlust ja teha muid ülevaatusi.

Edasi on meil kaks teed:

Kustuta – lõpetada käivitatud DR-plaan. See toiming lihtsalt peatab käimasoleva VM-i. Replikaandmed ei kao kuhugi.
Eemalda – eraldada replikeeritud masin Acura-st, st lõpetada rändeprotsess.

Lahenduse plussid:

kliendi ja teenusepakkuja poolne lihtne installimine ja seadistamine;
müügi planeerimise lihtsus, DR-plaani loomine ja replikate käivitamine;
toetuse ja arendajate piisav reageerimiskiirus leitud probleemidele, mis kõrvaldatakse platvormi või agentide uuenduste kaudu.

Miinused

Ebapiisav tugi VMware-le.
Platvormi poolt tenantide jaoks ei ole ühegi kvoodi puudumine.

Olen ka koostanud Funktsiooni Soovituse, mille edastasime müüjale:

kasutuse ja juurutamise jälgimine Acura juhtpaneelilt Cloud-agentide jaoks;
kvootide olemasolu tenantide jaoks;
võimalus piirata samaaegsete replikatsioonide arvu ja kiirus iga tenantide jaoks;
toetada VMware vCloud Directorit;
toetada ressursigruppide haldamist (rakendati testimise käigus);
VMware-agendi seadistamise võimalus agent ja otse, ilma et oleks vaja klientide infrastruktuuri sisselogimisteavet Acura paneelis;
VM-i käivitamise protsessi "visualiseerimine" DR-plaani käivitamisel.

Ainus asi, mis mulle suurt rahulolematust põhjustas, oli dokumentatsioon. Ma ei armasta väga "mustade karpide" süsteemi ja eelistan, et see töötab toodete kohta üksikasjalik dokumentatsioon. Kui AWS ja OpenStack, toote kirjeldus on veel enam-vähem, siis VMware kohta on dokumentatsioon äärmiselt vähe.

On olemas Installation Guide, mis kirjeldab ainult Acura juhtpaneeli juurutamist, ega maini, et vajalik on ka Cloud-agent. Toote kohta on olemas täielik spetsifikatsioonide komplekt, mis on hea. On dokumentatsioon, mis kirjeldab seadistust "kõik" AWS ja OpenStack näidete kaudu (kuigi see meenutab mulle rohkem blogipostitust), ja on väga väike teadmistebaas.

Kokkuvõttes ei ole see täpselt see dokumentatsiooni formaat, millega olen harjunud, näiteks suuremate müüjate juures, seega ei olnud mul just mugav. Samuti ei leidnud ma nende süsteemide "teisest küljest" mõningate detailide kohta vastuseid ning väga palju küsimusi tuli selgitada tehnilise toe kaudu, mis pärssis oluliselt stendi juurutamise ja testimise protsessi.

Kokkuvõttes võin öelda, et üldiselt meeldis mulle toode ja ettevõtte lähenemine ülesande täitmisele. Jah, on puudujääke, on tõeliselt kriitiline funktsionaalsuse nappus (seoses VMware'iga). On selge, et ettevõte keskendub eelkõige avalikele pilvede lahendustele, eriti AWS-ile, ja mõnele inimesele võib sellest piisata. Sellise lihtsa ja mugava toote olemasolu tänapäeval, kui paljud ettevõtted valivad multi-pilve strateegia, on ülimalt oluline. Arvestades oluliselt madalamat hinda võrreldes konkurentidega, teeb see toote äärmiselt atraktiivseks.

Otsime oma meeskonda peaspetsialisti süsteemide jälgimise alal. Võib-olla olete just teie?

Allikas: habr.com

Hystax Cloud Migration: hüppame pilvedesse