Hystaxi pilvede migratsioon: pilvede üle sõitmine

Üks noori tegijaid katastroofi taastamise lahenduste turul on Hystax, Venemaa idufirma alates 2016. aastast. Kuna katastroofi taastamise teema on väga populaarne ja turul ülimalt konkurents, otsustas startup keskenduda migratsioonile erinevate pilvetaristute vahel. Toode, mis võimaldab korraldada lihtsat ja kiiret pilve migratsiooni, oleks väga kasulik ka Onlanta klientidele – kasutajatele Oncloud.ru. Nii tutvusin Hystaxiga ja hakkasin selle võimalusi katsetama. Ma räägin teile selles artiklis, mis sellest tuli.

Hystaxi pilvede migratsioon: pilvede üle sõitmine
Hystaxi põhiomaduseks on lai funktsionaalsus erinevate virtualiseerimisplatvormide, külalisoperatsioonisüsteemide ja pilveteenuste toetamiseks, mis võimaldab oma töökoormust üle kanda kõikjalt ja igal pool.

See võimaldab luua mitte ainult DR-lahendusi teenuste tõrketaluvuse suurendamiseks, vaid ka kiiresti ja paindlikult migreerida ressursse erinevate saitide ja hüperskaalarite vahel, et suurendada kulude kokkuhoidu ja valida konkreetse teenuse jaoks antud hetkel parim lahendus. Lisaks tiitlipildil loetletud platvormidele teeb ettevõte aktiivselt koostööd ka Venemaa pilvepakkujatega: Yandex.Cloud, CROC Cloud Services, Mail.ru ja paljude teistega. Samuti väärib märkimist, et 2020. aastal avas ettevõte Skolkovos asuva teadus- ja arenduskeskuse. 

Paljude turul tegutsejate poolt ühe lahenduse valik viitab heale hinnapoliitikale ja toote kõrgele rakendatavusele, mida otsustasime ka praktikas katsetada.

Seega koosneb meie testülesanne minu VMware testisaidi ja füüsiliste masinate migreerimisest teenusepakkuja saidile, mida haldab samuti VMware. Jah, sellise migratsiooni teostamiseks on palju lahendusi, kuid me peame Hystaxi universaalseks tööriistaks ja migratsiooni testimine kõigis võimalikes kombinatsioonides on lihtsalt ebareaalne ülesanne. Ja Oncloud.ru pilv on ehitatud spetsiaalselt VMware'ile, nii et see platvorm kui sihtmärk pakub meile suuremat huvi. Järgmisena kirjeldan põhilist tööpõhimõtet, mis on üldiselt platvormist sõltumatu ja mis tahes poole VMware saab asendada mõne teise tootja platvormiga. 

Esimene samm on Hystax Acura juurutamine, mis on süsteemi juhtpaneel.

Hystaxi pilvede migratsioon: pilvede üle sõitmine
See avaneb mallist. Millegipärast ei olnud see meie puhul täiesti õige ja soovitatud 8CPU asemel võeti poole väiksema ressursiga kasutusele 16Gb. Seetõttu peate meeles pidama nende muutmist, vastasel juhul ei käivitu lihtsalt VM-i sees olev konteineri infrastruktuur, millele kõik on ehitatud ja portaal on kättesaamatu. IN Juurutamise nõuded Vajalikud ressursid on üksikasjalikult kirjeldatud, samuti kõigi süsteemikomponentide pordid. 

Samuti oli raskusi IP-aadressi määramisega malli kaudu, mistõttu muutsime seda konsoolist. Pärast seda saate minna administraatori veebiliidesele ja lõpetada esialgse konfiguratsiooniviisardi. 

Hystaxi pilvede migratsioon: pilvede üle sõitmine
Hystaxi pilvede migratsioon: pilvede üle sõitmine
Lõpp-punkt – meie vCenteri IP või FQDN. 
Sisselogimine ja parool – see on selge. 
Sihtmärgi ESXi hostinimi on üks meie klastri hostitest, millele replikatsioon tehakse. 
Sihtandmesalve on üks meie klastri andmesalvedest, kuhu replikatsioon tehakse.
Hystax Acura juhtpaneeli avalik IP – aadress, kus juhtpaneel on saadaval.

Hosti ja andmesalve kohta on vaja väikest selgitust. Fakt on see, et Hystaxi replikatsioon töötab hosti ja andmesalve tasemel. Järgmisena räägin teile, kuidas saate rentniku hosti ja andmesalve muuta, kuid probleem on erinev. Hystax ei toeta ressursikogumitega töötamist, st. koopia läheb alati klastri juure (selle materjali kirjutamise ajal andsid Hystaxi poisid välja värskendatud versiooni, kus nad rakendasid kiiresti minu funktsioonitaotluse ressursside kogumite toetamise kohta). Samuti ei toetata vCloud Directorit, st. kui, nagu minu puhul, pole rentnikul administraatoriõigusi kogu klastri, vaid ainult konkreetse ressursikogumi jaoks ja me andsime juurdepääsu Hystaxile, saab ta neid VM-e iseseisvalt paljundada ja käivitada, kuid ta teeb seda ei näe neid VMware infrastruktuuris, millele tal on juurdepääs ja mis vastavalt sellele haldab virtuaalmasinaid. Klastri administraatoril on vaja VM soovitud ressursikogumi teisaldada või vCloud Directorisse importida.

Miks ma neile punktidele nii palju keskendun? Sest niipalju kui mina toote kontseptsioonist aru saan, peaks klient Acura paneeli kasutades saama iseseisvalt teostada mis tahes migratsiooni või DR-i. Kuid seni on VMware tugi veidi alla jäänud OpenStacki toe tasemele, kus sarnaseid mehhanisme on juba rakendatud. 

Aga tuleme tagasi juurutamise juurde. Kõigepealt peame pärast paneeli esialgset seadistamist looma oma süsteemis esimese rentniku.

Hystaxi pilvede migratsioon: pilvede üle sõitmine
Kõik siinsed väljad on selged, ma räägin teile ainult Pilveväljast. Meil on juba vaikimisi pilv, mille lõime esialgse konfiguratsiooni käigus. Kuid kui tahame, et iga rentnik saaks paigutada oma andmesalve ja oma ressursikogumi, saame seda rakendada, luues iga kliendi jaoks eraldi pilved.

Hystaxi pilvede migratsioon: pilvede üle sõitmine
Uue pilve lisamise vormis määrame samad parameetrid, mis algse seadistamise ajal (saame kasutada isegi sama hosti), märgime konkreetsele kliendile vajaliku andmehoidla ja nüüd saame lisaparameetrites individuaalselt määrata vajaliku ressursi bassein {"resource_pool" : "YOUR_POOL_NAME"} 

Nagu olete võib-olla märganud, pole rentniku loomise vormis midagi ressursside jaotamise ega kvootide kohta – süsteemis seda pole. Üürniku samaaegsete koopiate arvu, replikatsioonimasinate arvu või muude parameetritega on võimatu piirata. Niisiis, oleme loonud esimese üürniku. Nüüd on mitte täiesti loogiline, kuid kohustuslik asi - pilvagendi installimine. See on ebaloogiline, kuna agent laaditakse alla konkreetse kliendi lehelt.

Hystaxi pilvede migratsioon: pilvede üle sõitmine
Samal ajal ei ole see seotud loodud rentnikuga ja kõik meie kliendid töötavad selle kaudu (või mitme kaudu, kui me neid juurutame). Üks agent toetab 10 samaaegset seanssi. Üks masin loetakse üheks seansiks. Pole tähtis, mitu ketast sellel on. Siiani pole Acuras endas VMware'i all ühtegi mehhanismi agentide skaleerimiseks. On veel üks ebameeldiv hetk - meil pole võimalust Acura paneelilt selle agendi "utiliseerimist" vaadata, et teha järeldus, kas peame rohkem juurutama või piisab praegusest installist. Selle tulemusena näeb stend välja selline:

Hystaxi pilvede migratsioon: pilvede üle sõitmine
Järgmine samm meie kliendiportaali juurde pääsemiseks on konto loomine (ja esiteks sellele kasutajale rakenduva roll).

Hystaxi pilvede migratsioon: pilvede üle sõitmine
Hystaxi pilvede migratsioon: pilvede üle sõitmine
Nüüd saab meie klient portaali iseseisvalt kasutada. Ta peab vaid agendid portaalist alla laadima ja oma poolele installima. Agente on kolme tüüpi: Linux, Windows ja VMware.

Hystaxi pilvede migratsioon: pilvede üle sõitmine
Esimesed kaks on installitud füüsikasse või virtuaalsetesse masinatesse mis tahes hüperviisorisse peale VMware. Midagi täiendavat konfigureerida pole vaja, agent on alla laaditud ja juba teab, kuhu koputada ning sõna otseses mõttes minuti pärast on auto Acura paneelil nähtav. VMware agendiga on olukord veidi keerulisem. Probleem on selles, et ka VMware agent laaditakse portaalist alla, mis on juba ettevalmistatud ja sisaldab vajalikku konfiguratsiooni. Kuid lisaks meie Acura portaali tundmisele peab VMware agent teadma ka virtualiseerimissüsteemist, millele see juurutatakse.

Hystaxi pilvede migratsioon: pilvede üle sõitmine
Tegelikult palub süsteem meil need andmed esitada VMware agendi esmakordsel allalaadimisel. Probleem on selles, et meie universaalse turvaarmastuse ajastul ei taha kõik kellegi teise portaalis oma administraatori parooli näidata, mis on täiesti arusaadav. Seestpoolt ei saa agenti pärast juurutamist kuidagi konfigureerida (muuta saab ainult selle võrgusätteid). Siin näen ette raskusi eriti ettevaatlike klientidega. 

Nii et pärast agentide paigaldamist saame minna tagasi Acura paneeli ja näha kõiki meie autosid.

Hystaxi pilvede migratsioon: pilvede üle sõitmine
Kuna olen süsteemiga juba mitu päeva töötanud, on mul autosid erinevates olekutes. Mul on need kõik Vaikimisi grupis, kuid on võimalik luua eraldi gruppe ja neisse autosid üle kanda vastavalt vajadusele. See ei mõjuta midagi – ainult andmete loogiline esitus ja nende rühmitamine mugavamaks tööks. Esimene ja kõige olulisem asi, mida me pärast seda tegema peame, on alustada migratsiooniprotsessi. Saame seda teha kas käsitsi või ajakava koostades, sh hulgi kõikide masinate jaoks korraga.

Hystaxi pilvede migratsioon: pilvede üle sõitmine
Lubage mul teile meelde tuletada, et Hystax positsioneeriti migratsioonitootena. Seetõttu pole üllatav, et meie paljundatud masinate käitamiseks peame looma DR-plaani. Plaani saab teha masinatele, mis on juba sünkroonitud olekus. Saate genereerida nii ühe konkreetse VM-i kui ka kõigi masinate jaoks korraga.

Hystaxi pilvede migratsioon: pilvede üle sõitmine
DR-plaani loomisel kasutatavad parameetrid erinevad olenevalt infrastruktuurist, kuhu migreerite. VMware keskkonna jaoks on saadaval minimaalne parameetrite komplekt. Samuti ei toetata masinate IP-aadressi uuesti muutmist. Sellega seoses huvitavad meid järgmised punktid: VM-i kirjelduses parameeter "alamvõrk": "VMNetwork", kus seome VM-i klastris konkreetse võrguga. Aste – asjakohane mitme virtuaalse masina üleviimisel; see määrab nende käivitamise järjekorra. Maitse – kirjeldab VM-i konfiguratsiooni, antud juhul – 1CPU, 2GB RAM. Alamvõrkude jaotises määratleme, et "alamvõrk": "VMNetwork" on seotud VMware'i "VM-võrguga". 

DR-plaani loomisel ei saa kettaid erinevate andmesalvede vahel laiali ajada. Need asuvad samas andmesalves, mis selle kliendipilve jaoks määratleti ja kui teil on erineva klassi kettad, võib see masina käivitamisel raskusi tekitada ning peale VM-i käivitamist ja Hystaxist “eraldamist” vaja eraldi migratsioonikettaid vajalikesse andmesalvedesse. Siis ei jää meil muud teha, kui käivitada oma DR-plaan ja oodata, kuni meie autod tõusevad. P2V/V2V teisendusprotsess võtab samuti aega. Minu suurimal katsemasinal, 100GB kolme kettaga, kulus selleks maksimaalselt 10 minutit.

Hystaxi pilvede migratsioon: pilvede üle sõitmine
Pärast seda peaksite kontrollima töötavat VM-i, sellel olevaid teenuseid, andmete järjepidevust ja tegema muid kontrolle. 

Siis on meil kaks võimalust: 

  1. Kustuta – kustutage töötav DR-plaan. See toiming lihtsalt sulgeb töötava VM-i. Need koopiad ei kao kuhugi. 
  2. Eralda – rebi Acura küljest ära paljundatud auto, st. tegelikult viige migratsiooniprotsess lõpule. 

Lahenduse plussid: 

  • paigaldamise ja konfigureerimise lihtsus nii kliendi kui ka pakkuja poolt; 
  • migratsiooni seadistamise, DR-plaani loomise ja koopiate käivitamise lihtsus;
  • tugi ja arendajad reageerivad leitud probleemidele üsna kiiresti ja parandavad need platvormi või agendi värskenduste abil. 

Miinused 

  • Ebapiisav Vmware tugi.
  • Platvormil puuduvad üürnike kvoodid. 

Koostasin ka funktsioonitaotluse, mille esitasime müüjale:

  1. kasutamise jälgimine ja juurutamine pilveagentide Acura halduskonsoolist;
  2. üürnike kvootide olemasolu; 
  3. võimalus piirata iga üürniku samaaegsete replikatsioonide arvu ja kiirust; 
  4. VMware vCloud Directori tugi; 
  5. ressursside kogumite tugi (rakendatud testimise käigus);
  6. võimalus konfigureerida VMware agenti agendi enda kaudu, ilma Acura paneelil kliendi infrastruktuuri mandaate sisestamata;
  7.  VM-i käivitusprotsessi "visualiseerimine" DR-plaani käitamisel. 

Ainus, mis mulle suurt kriitikat tekitas, oli dokumentatsioon. Mulle "mustad kastid" väga ei meeldi ja eelistan, kui toote sees toimimise kohta on üksikasjalik dokumentatsioon. Ja kui AWS-i ja OpenStacki puhul on toodet isegi enam-vähem kirjeldatud, siis VMware jaoks on dokumentatsiooni väga vähe. 

Seal on installijuhend, mis kirjeldab ainult Acura paneeli juurutamist ja pole sõnagi sellest, et vaja on ka Cloud agenti. Toote spetsifikatsioonide täielik komplekt on olemas, mis on hea. Seal on dokumentatsioon, mis kirjeldab seadistamist algusest lõpuni, kasutades näitena AWS-i ja OpenStacki (kuigi see tundub mulle pigem ajaveebipostitusena), ja seal on väga väike teadmistebaas. 

Üldiselt pole see päris see dokumentatsioonivorming, millega ma olen harjunud, näiteks suuremate müüjate puhul, nii et ma ei tundnud end päris mugavalt. Samas ei leidnud ma sellest dokumentatsioonist kunagi vastuseid mõningate nüansside kohta, kuidas süsteem "sees" töötab - pidin tehnilise toega palju küsimusi selgitama ja see lükkas stendi kasutuselevõtu ja läbiviimise protsessi üsna edasi. testimine. 

Kokkuvõtteks võin öelda, et üldiselt meeldis mulle toode ja ettevõtte lähenemine ülesandele. Jah, on puudujääke, on tõesti kriitiline funktsionaalsuse puudus (seoses VMware'iga). On selge, et esiteks on ettevõte endiselt keskendunud avalikele pilvedele, eriti AWS-ile, ja mõne jaoks sellest piisab. Sellise lihtsa ja mugava toote omamine tänapäeval, mil paljud ettevõtted valivad mitme pilve strateegiat, on äärmiselt oluline. Arvestades konkurentidega võrreldes palju madalamat hinda, muudab see toote äärmiselt atraktiivseks.

Otsime meeskonda Juhtimissüsteemide insener. Võib-olla oled see sina?

Allikas: www.habr.com

Lisa kommentaar