🥇Hystax Cloud Migration: hüppame pilvedes

Üheks nooreks tegijaks hädaabiteenuste lahenduste turul on Hystax – Venemaa 2016. aasta idufirma. Kuna katastroofide taastamise teema on väga populaarne ja turul on väga kõrge konkurents, otsustas idufirma keskenduda erinevate pilvestruktuuride vahelisele migreerimisele. Toode, mis võimaldab lihtsat ja kiiret pilve migreerimist, oleks väga kasulik ka ettevõtte „Onlanta” klientidele — kasutajatele. Oncloud.ru. Nii kohtusin ma Hystaxiga ja hakkasin selle võimalusi katsetama. Kuidas see kõik välja kukkus, räägin ma käesolevas artiklis.

Hystaxi peamiseks eripäraks on selle ulatuslik funktsionaalsus erinevate virtualiseerimise platvormide, külg-OS-ide ja pilveteenuste toetamisel, mis võimaldab teie töökoormust edastada kust tahes ja kuhu tahes.

See võimaldab luua mitte ainult DR-lahendusi teenuste töökindluse suurendamiseks, vaid ka kiiresti ja paindlikult migreerida ressursse erinevate platvormide ja hüperkaljade vahel, et suurendada kulude kokkuhoidu ja valida parim lahendus konkreetse teenuse jaoks antud hetkel. Lisaks piltide peal loetletud platvormidele teeb ettevõte ka aktiivselt koostööd Venemaa pilveteenuse pakkujatega: Yandex.Cloud, KROK „Pilveteenused”, Mail.ru ja paljude muude. Samuti tasub märkida, et 2020. aastal avas ettevõte R&D keskuse, mis asub Skolkovo.

Ühe lahenduse valik paljude mängijate seas turul näitab head hinnapoliitikat ja produktsiooni kõrget kasutatavust, mida otsustasime praktikas testida.

Nii et meie testülesanne seisneb migratsioonis minu testimisplatvormilt VMware ja füüsilistelt masinatelt teenusepakkuja platvormile, mis samuti töötab VMware all. Jah, on palju lahendusi, mis suudavad sellise migratsiooni teostada, aga me vaatame Hystaxi kui universaalset vahendit. Testida migratsiooni kõigis võimalikes kombinatsioonides on lihtsalt uskumatu ülesanne. Ja Oncloud.ru pilv on tõepoolest rajatud VMware'ile, seega huvitab meid see platvorm sihtkohtadena rohkem. Edasi kirjeldan põhimõtet, mis üldiselt ei sõltu platvormist ja VMware'i võib igal juhul asendada teise tootjaga platvormiga.

Esimeses etapis on vajalik Hystax Acura juurutamine, mis on süsteemi juhtpaneel.

See juurutatakse mallist. Meie puhul oli see mingil põhjusel ebatäpne ja soovitatud 8CPU, 16Gb asemel juurutati see poole väiksemate ressurssidega. Seetõttu ei tohi unustada neid muuta, muidu ei käivitu infrastruktuuri konteinerid VM-i sees, millele kõik rajatakse, ja portaal jääb kättesaamatuks. Juhtimisnõuded kasutamiseks vajalikud ressursid ja kõigi süsteemi komponentide pordid on üksikasjalikult kirjeldatud.

Samuti ilmus probleeme IP-aadressi määramisega malli kaudu, seetõttu muutisime seda konsoolist. Pärast seda saab minna administraatori veebiliidese juurde ja täita algse seadistuse wizard'i.

Lõpp-punkt – meie vCenteri IP või FQDN.
Login ja parool – see on selge.
Siht-ESXi hostname – üks meie klastris olevatest hostidest, kuhu replikatsioon toimub.
Siht-datastore – üks meie klastris olevatest datastores, kuhu replikatsioon toimub.
Hystax Acura juhtpaneeli avalik IP – aadress, mille kaudu juhtepaneel on kättesaadav.

On vajalik väike täpsustus hosti ja andmestoori osas. Asi on selles, et Hystaxi replikatsioon töötab hosti ja andmestoori tasemel. Hiljem selgitan, kuidas tenant saab hosti ja andmestoori muuta, kuid probleem on mujal. Hystax ei toeta töö tegemist ressursside gruppidega, st replikatsioon toimub alati klastrijuure (selle materjali kirjutamise ajal vabastas Hystax värskendatud versiooni, kuhu nad kiiresti integreerisid minu funktsioonisoovi ressursside gruppide toe osas). Samuti ei toeta see vCloud Directori, st kui, nagu minu puhul, tenant'il ei ole admini õigusi kogu klastri üle, vaid ainult konkreetse ressursigruppide üle, ja me andsime Hystaxile juurdepääsu, siis suudab see iseseisvalt replitseeruda ja käivitada neid VM-e, kuid ta ei näe neid VMware infrastruktuuris, millele tal on juurdepääs ja vastavalt sellele ei saa ka virtuaalmasinaid hallata. On vajalik, et klastri administraator viiks VM-i õigesse ressursigruppi või importiks vCloud Directorisse.

Miks ma nendele punktidele nii suurt tähelepanu pööran? Sest minu arusaama järgi peab kliendil olema võimalus igasugune migreerimine või DR ise rakendada Acura juhtpaneeli kaudu. Kuid samas on VMware tugi hetkel veidi madalamal tasemel võrreldes OpenStackiga, kus sellised mehhanismid on juba olemas.

Kuid naaseme juurutamise juurde. Esmalt, pärast juhtpaneeli esialgset seadistamist, peame meie süsteemis looma esimese tenandi.

Kõik väljad siin on arusaadavad, räägin ainult Cloud väljast. Meil on juba olemas 'vaikimisi' pilv, mille me esialgse konfigureerimise käigus lõime. Kuid kui me soovime, et iga tenant saaks paigutada oma andmestoori ja oma ressursi kogumisse, saame seda rakendada, luues iga meie kliendi jaoks eraldi pilve.

Uue pilve lisamise vormis määrame samu parameetreid nagu esialgse konfiguratsiooni korral (saame kasutada isegi sama hosti), määrates konkreetse kliendi jaoks vajalikku andmestoru, ja nüüd saame täiendavates parameetrites individuaalselt määrata vajalikku ressursside basseini {«resource_pool»: «YOUR_POOL_NAME»}

Kuidas olete märganud, ei sisaldanud tenant-i loomise vormis mingeid ressursi eraldamise või kvotide teavet – sellist asja süsteemis ei ole. Tenant-i ei saa piirata samaaegsete koopiate arvu, replikatsiooni masinate arvu või muude parameetritega. Nii et oleme loonud esimese tenant-i. Nüüd on olemas veidi ebatavaline, kuid vajalik etapp – Cloud-agendi installimine. See on ebatavaline, kuna agent laaditakse alla konkreetse kliendi lehelt.

Sellega ei seondu loodud tenant, ja kõigi meie klientide tööd tehakse selle kaudu (või mitme, kui me need üles seame). Üks agent toetab 10 samal ajal toimivat sessiooni. Ühe sessiooni alla arvatakse üks masin. Oluline pole selle kettad. Tänaseks päevaks ei ole Acura-l VMware osas agentide skaleerimiseks mehhanismi. On veel üks ebameeldiv asi – me ei saa Acura paneelist vaadata selle agendi „kasutust”, et järeldada, kas me peame veel ühe käivitama või piisab praegusest installatsioonist. Kokkuvõttes näeb stend välja järgmine:

Järgmine etapp meie kliendi portaalile juurde pääsemiseks on konto loomine (enne seda tuleb luua ka roll, mis sellele kasutajale rakendatakse).

Nüüd saab meie klient portaalist iseseisvalt kasutada. Kõik, mida tal on vaja teha, on agentide allalaadimine portaalist ja nende paigaldamine oma poolele. On kolm tüüpi agente: Linux, Windows ja VMware.

Esimesed kaks installitakse füüsika või virtuaalmasinate peale, mis on erinevad VMware hüperviisorist. Siin ei ole vaja midagi lisaks konfigureerida, agent laaditakse alla ja teab juba, kuhu peab sisse logima, ning sõna otseses mõttes minuti pärast on masin nähtav Acura paneelis. VMware agendiga on olukord pisut keerulisem. Probleem seisneb selles, et VMware agent laaditakse samuti alla portaalist, kuid see on juba eelnevalt konfigureeritud. Kuid VMware agent peab lisaks teabele meie Acura portaalist tundma ka virtualiseerimisseadet, millele ta paigaldatakse.

Nii et need andmed küsib süsteem meilt esmakordsel VMware agendi allalaadimisel. Probleem on selles, et meie turvalisuse armastuse ajastul ei soovi kõik oma administraatori parooli võõras portaalis näidata, mis on täiesti arusaadav. Seestpoolt, pärast paigaldamist, ei saa agenti enam konfigureerida (ainult võrgu seadeid on võimalik muuta). Siin ennustan probleeme eriti ettevaatlike klientidega.

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

Kuna ma olen juba mõnda aega süsteemiga töötanud, on mul masinad erinevates olekutes. Kõik need kuuluvad mul rühma Default, kuid on võimalus luua eraldi rühmi ja üle kanda masinad vastavalt vajadusele. See ei mõjuta midagi — see on lihtsalt andmete loogiline esitus ja rühmitamine mugavamaks töötamiseks. Esimene ja kõige olulisem asi, mida me pärast seda tegema peame, on migratsiooniprotsessi käivitamine. Saame seda teha kas sundides käsitsi või seadistades ajakava, sealhulgas ka massiliselt kõigi masinate jaoks korraga.

Tuletan meelde, et Hystax positsioneeris end migratsioonitootena. Seega pole midagi üllatavat, et meie replikeeritud masinate käivitamiseks on meil vaja luua DR-plaan. Plani saab koostada masinate jaoks, mis on juba olekus Synced. Saame genereerida plaani nii ühe konkreetse VM-i jaoks kui ka kõigi masinate jaoks korraga.

DR-plaani genereerimise parameetrite kogum sõltub infrastruktuurist, kuhu te kavatsete migreerida. VMware keskkonna jaoks on saadaval minimaalne parameetrite kogum. Samuti ei toetata masinate Re-IP-d. Selle plaani raames on meil olulised järgmised punktid: VM kirjelduse parameeter "subnet": "VMNetwork", kus seome VM konkreetse võrgu külge klastris. Rank on oluline mitmete VM-ide migreerimise puhul ja määrab nende käivitamise järjekorra. Flavor kirjeldab VM konfiguratsiooni, antud juhul – 1CPU, 2GB RAM. Alajaotuses subnets määrame, et "subnet": "VMNetwork" on seotud võrgu "VM Network" VMware.

DR-plaane luues ei ole võimalik andmeid erinevatele andmehoidlatele „jaotada“. Need asuvad samas andmehoidlas, mis on määratud sellele kliendi pilvkeskkonnale, ja kui teil on erineva klassiga kettaid, võib see käivitamise ajal põhjustada teatud raskusi. Pärast masina käivitamist ja VM-i Hystax-ist „lahkumist“ vajab see veel eraldi ketaste migreerimist vajalikesse andmehoidlatesse. Järgmiseks peame lihtsalt käivitama meie DR-plaani ja ootama, kuni meie masinad üles tõusevad. P2V/V2V konverteerimise protsess võtab samuti aega. Minu suurimal 100 GB testmasinal kolmel kettal kestis see maksimaalselt 10 minutit.

Seejärel tuleb kontrollida käivitatud VM-i, teenuseid sellel, andmete järjepidevust ja teha muid kontrollimisi.

Edasi on meil kaks teed:

Kustuta – kustuta käivitatud DR-plaan. See tegevus lihtsalt peatab käivitatud VM-i. Duplikaadi andmed ei kao kuhugi.
Eralda – eralda replikatsiooniga masin Acura-lt, st lõpetada migreerimisprotsess.

Lahenduse eelised:

lihtne paigaldamine ja seadistamine nii kliendi kui ka teenusepakkuja poolt;
lihtne migreerimise seadistamine, DR-plaani loomine ja replikate käivitamine;
tugi ja arendajad reageerivad leitud probleemidele kiiresti ning lahendavad need platvormi või agentide uuenduste kaudu.

Miinused

Ebapiisav tugi VMware'i jaoks.
Platvormi poolt ei ole mingit koormusteenuse kvotimist.

Olen koostanud ka funktsioonide taotluse, mille edastasime müüjale:

Acuras juhtpaneelilt Cloud agentide kasutamise ja juurutamise jälgimine;
kvootide olemasolu tenantidele;
võimalus piirata samaaegsete replikeerimiste arvu ja kiirus iga tenant jaoks;
tugi VMware vCloud Directors;
tugi ressursside basseinidele (see realiseeriti testimise käigus);
võimalus konfigureerida VMware agenti otse agendi poolt, ilma et klientide infrastruktuuri kasutajanimesid peaks Acura paneeli sisestama;
VM-i käivitamise visualiseerimine DR-plaani käivitamisel.

Ainus asi, mis mulle tõsiselt ei meeldinud, oli dokumentatsioon. Ma ei armasta väga "mustade karpide" kontseptsiooni ja eelistan, et toote töö kohta oleks üksikasjalik dokumentatsioon. Kui AWS-i ja OpenStacki jaoks on toode enam-vähem kirjeldatud, siis VMware'i dokumentatsiooni on äärmiselt vähe.

On olemas Installation Guide, mis kirjeldab ainult Acura paneeli käivitamist, ja kus ei öelda sõnagi, et vajalik on ka Cloud-agent. On olemas täielik toote spetsifikatsioonide komplekt, mis on hea. On dokumentatsioon, mis kirjeldab seadistamist „alates ja kuni“ AWS ja OpenStacki näitel (kuigi see meenutab rohkem blogipostitust), ja on ka üsna väike Knowledge Base.

Kokkuvõttes pole see päris see dokumentatsiooni formaat, millega olen harjunud, ütleme, suuremate tarnijate juures, seega ei olnud mul selles osas mugav. Samuti ei leidnud ma dokumentatsioonist vastuseid mõnede süsteemi „sisemiste“ nüansside kohta – väga palju küsimusi tuli täpsustada tehnilise toe kaudu, mis tõi märkimisväärselt viivitusi stendi seadistamise ja testimise protsessi.

Kokkuvõttes võin öelda, et mulle meeldivad ettevõtte toode ja lähenemine ülesande täitmisele. Jah, esinevad puudujäägid, sealhulgas tõsised funktsionaalsuse puudujäägid (seoses VMware’iga). On selge, et ettevõte keskendub peamiselt avalikele pilvedele, eelkõige AWS-ile, ja mõnele võib see piisata. Sellise lihtsa ja mugava toote olemasolu täna, kui paljud ettevõtted valivad mitme pilve strateegia, on äärmiselt oluline. Arvestades selle oluliselt madalamat hinda võrreldes konkurentidega, teeb see toote äärmiselt atraktiivseks.

Otsime oma meeskonda juhtivat süsteemimonitorimise inseneri. Võib-olla oled see just sina?

Allikas: habr.com