Vienas iš jaunų nelaimių atkūrimo sprendimų rinkos žaidėjų yra Hystax, Rusijos startuolis nuo 2016 m. Kadangi atkūrimo po nelaimių tema yra labai populiari, o rinka itin konkurencinga, startuolis nusprendė sutelkti dėmesį į migraciją tarp skirtingų debesų infrastruktūrų. Produktas, leidžiantis suorganizuoti paprastą ir greitą migraciją į debesį, taip pat būtų labai naudingas Onlantos klientams – vartotojams . Taip susipažinau su Hystax ir pradėjau testuoti jo galimybes. Aš jums pasakysiu, kas iš to išėjo šiame straipsnyje.
Pagrindinis Hystax bruožas yra platus funkcionalumas palaikyti įvairias virtualizacijos platformas, svečių operacines sistemas ir debesų paslaugas, leidžiančias perkelti savo darbo krūvius iš bet kur ir bet kur.
Tai leidžia sukurti ne tik DR sprendimus, didinančius paslaugų atsparumą gedimams, bet ir greitai bei lanksčiai migruoti išteklius tarp skirtingų svetainių ir hiperskalerių, kad būtų galima sutaupyti daugiau išlaidų ir pasirinkti tinkamiausią sprendimą konkrečiai paslaugai konkrečiu momentu. Be platformų, išvardytų tituliniame paveikslėlyje, įmonė taip pat aktyviai bendradarbiauja su Rusijos debesų tiekėjais: Yandex.Cloud, CROC Cloud Services, Mail.ru ir daugeliu kitų. Taip pat verta paminėti, kad 2020 metais įmonė atidarė MTEP centrą, esantį Skolkovo mieste.
Vieno sprendimo pasirinkimas daugelio rinkos dalyvių rodo gerą kainų politiką ir aukštą produkto pritaikomumą, kurį nusprendėme išbandyti praktiškai.
Taigi mūsų bandymo užduotį sudarys perkėlimas iš mano VMware testavimo vietos ir fizinių įrenginių į teikėjo svetainę, kurią taip pat valdo VMware. Taip, yra daug sprendimų, galinčių atlikti tokią migraciją, tačiau Hystax laikome universalia priemone, o migracijos testavimas visomis įmanomomis kombinacijomis yra tiesiog nereali užduotis. O Oncloud.ru debesis yra sukurtas specialiai VMware, todėl ši platforma kaip taikinys mus domina labiau. Toliau aprašysiu pagrindinį veikimo principą, kuris paprastai nepriklauso nuo platformos, o VMware iš bet kurios pusės gali būti pakeista kito gamintojo platforma.
Pirmasis žingsnis yra įdiegti Hystax Acura, kuri yra sistemos valdymo skydelis.
Jis išsiskleidžia iš šablono. Kažkodėl mūsų atveju tai buvo ne visai teisinga ir vietoj rekomenduojamo 8 procesoriaus, su puse resursų buvo dislokuota 16Gb. Todėl reikia nepamiršti juos pakeisti, antraip VM viduje esanti konteinerinė infrastruktūra, ant kurios viskas pastatyta, tiesiog nepasileis ir portalas bus nepasiekiamas. IN Išsamiai aprašyti reikalingi ištekliai, taip pat visų sistemos komponentų prievadai.
Taip pat kilo sunkumų nustatant IP adresą per šabloną, todėl pakeitėme jį iš konsolės. Po to galite pereiti į administratoriaus žiniatinklio sąsają ir užbaigti pradinį konfigūracijos vedlį.
Galutinis taškas – mūsų „vCenter“ IP arba FQDN.
Prisijungimas ir slaptažodis – aišku.
Tikslinis ESXi pagrindinio kompiuterio pavadinimas yra vienas iš mūsų klasterio pagrindinių kompiuterių, į kuriuos bus atlikta replikacija.
Tikslinė duomenų saugykla yra viena iš mūsų klasterio duomenų saugyklų, į kurią bus atlikta replikacija.
Hystax Acura Control Panel Public IP – adresas, kuriame bus pasiekiamas valdymo pultas.
Reikia šiek tiek paaiškinimo dėl pagrindinio kompiuterio ir duomenų saugyklos. Faktas yra tas, kad Hystax replikacija veikia pagrindinio kompiuterio ir duomenų saugyklos lygiu. Toliau papasakosiu, kaip galite pakeisti nuomininko pagrindinį kompiuterį ir duomenų saugyklą, tačiau problema yra kitokia. Hystax nepalaiko darbo su išteklių telkiniais, t.y. replika visada pateks į klasterio šaknį (rašant šią medžiagą, Hystax vaikinai išleido atnaujintą versiją, kurioje greitai įgyvendino mano funkcijos užklausą dėl išteklių telkinių palaikymo). „vCloud Director“ taip pat nepalaikomas, t.y. jei, kaip mano atveju, nuomininkas neturi administratoriaus teisių į visą klasterį, o tik į konkretų išteklių telkinį, ir mes suteikėme prieigą prie Hystax, tada jis galės savarankiškai dauginti ir paleisti šias VM, bet jis tai padarys. negalės jų matyti VMware infrastruktūroje, prie kurios jis turi prieigą ir atitinkamai toliau valdo virtualias mašinas. Klasterio administratorius turi perkelti VM į norimą išteklių telkinį arba importuoti į „vCloud Director“.
Kodėl aš tiek daug dėmesio skiriu šiems dalykams? Kadangi, kiek suprantu produkto koncepciją, klientas turėtų turėti galimybę savarankiškai įgyvendinti bet kokią migraciją ar DR naudodamas Acura skydelį. Tačiau kol kas „VMware“ palaikymas šiek tiek atsilieka nuo „OpenStack“ palaikymo lygio, kur panašūs mechanizmai jau buvo įdiegti.
Bet grįžkime prie diegimo. Visų pirma, atlikę pradinę skydo sąranką, turime sukurti pirmąjį mūsų sistemos nuomininką.
Visi laukai čia aiškūs, aš jums papasakosiu tik apie debesų lauką. Jau turime „numatytąjį“ debesį, kurį sukūrėme pradinės konfigūracijos metu. Bet jei norime, kad kiekvienas nuomininkas būtų įtrauktas į savo duomenų saugyklą ir savo išteklių telkinį, galime tai įgyvendinti sukurdami atskirus debesis kiekvienam savo klientui.
Naujo debesies pridėjimo formoje nurodome tuos pačius parametrus kaip ir pradinės konfigūracijos metu (galime naudoti net tą patį pagrindinį kompiuterį), nurodome konkrečiam klientui reikalingą duomenų saugyklą, o dabar papildomuose parametruose galime individualiai nurodyti reikiamą resursą baseinas {"resource_pool" : "YOUR_POOL_NAME"}
Kaip tikriausiai pastebėjote, nuomininko kūrimo formoje nėra nieko apie išteklių paskirstymą ar kvotas – sistemoje to nėra. Neįmanoma apriboti nuomininko vienalaikių kopijų skaičiumi, replikuojamų mašinų skaičiumi ar kitais parametrais. Taigi, sukūrėme pirmąjį nuomininką. Dabar yra ne visai logiškas, bet privalomas dalykas – Cloud agento įdiegimas. Tai nelogiška, nes agentas atsisiunčiamas konkretaus kliento puslapyje.
Tuo pačiu metu jis nėra susietas su sukurtu nuomininku, o visi mūsų klientai dirbs per jį (arba per kelis, jei juos įdiegsime). Vienas agentas palaiko 10 seansų vienu metu. Viena mašina skaičiuojama kaip viena sesija. Nesvarbu, kiek diskų jis turi. Iki šiol pačioje „Acura“ programoje „VMware“ nėra agentų mastelio keitimo mechanizmo. Yra dar vienas nemalonus momentas - neturime galimybės pažvelgti į šio agento „išmetimą“ iš „Acura“ skydelio, kad padarytume išvadą, ar reikia įdiegti daugiau, ar užtenka esamo įrenginio. Dėl to stovas atrodo taip:
Kitas žingsnis norint pasiekti mūsų klientų portalą – susikurti paskyrą (ir pirmiausia – vaidmenį, kuris bus taikomas šiam vartotojui).
Dabar mūsų klientas portalu gali naudotis savarankiškai. Jam tereikia atsisiųsti agentus iš portalo ir įdiegti jį savo pusėje. Yra trijų tipų agentai: Linux, Windows ir VMware.
Pirmieji du yra įdiegti fizikos sistemose arba virtualiose mašinose bet kuriame hipervizoriuje, išskyrus VMware. Nereikia nieko papildomai konfigūruoti, agentas atsisiunčiamas ir jau žino, kur belstis, o tiesiog po minutės automobilis bus matomas Acura skydelyje. Su VMware agentu situacija yra šiek tiek sudėtingesnė. Problema ta, kad VMware agentas taip pat atsisiunčiamas iš jau paruošto portalo, kuriame yra reikiama konfigūracija. Tačiau VMware agentas turi žinoti ne tik apie mūsų Acura portalą, bet ir apie virtualizacijos sistemą, kurioje jis bus įdiegtas.
Tiesą sakant, sistema paprašys mūsų pateikti šiuos duomenis, kai pirmą kartą atsisiųsime VMware agentą. Problema ta, kad mūsų visuotinės meilės saugumui amžiuje ne visi norės kažkieno portale nurodyti savo administratoriaus slaptažodį, o tai visiškai suprantama. Iš vidaus, po įdiegimo, agento jokiu būdu negalima konfigūruoti (galite pakeisti tik jo tinklo nustatymus). Čia numatau sunkumų su ypač atsargiais klientais.
Taigi, sumontavę agentus, galime grįžti į Acura skydelį ir apžiūrėti visus savo automobilius.
Kadangi jau keletą dienų dirbu su sistema, turiu įvairių valstybių automobilių. Visus turiu grupėje Default, bet galima pagal poreikį susikurti atskiras grupes ir perkelti į jas automobilius. Tai nieko neįtakoja – tik logiškas duomenų pateikimas ir jų grupavimas patogesniam darbui. Pirmas ir svarbiausias dalykas, kurį turime padaryti po to, yra pradėti perkėlimo procesą. Tai galime padaryti rankiniu būdu arba sudarydami tvarkaraštį, įskaitant masinį visų mašinų iš karto.
Leiskite jums priminti, kad Hystax buvo pastatytas kaip migracijos produktas. Todėl nenuostabu, kad norėdami paleisti savo pakartotas mašinas turime sukurti DR planą. Planą galima sudaryti mašinoms, kurios jau yra sinchronizuotos būsenos. Galite generuoti ir vienai konkrečiai VM, ir visoms mašinoms vienu metu.
Parametrų rinkinys generuojant DR planą skirsis priklausomai nuo infrastruktūros, į kurią persikelsite. VMware aplinkai galimas minimalus parametrų rinkinys. Re-IP mašinoms taip pat nepalaikomas. Šiuo atžvilgiu mus domina šie punktai: VM aprašyme „potinklio“ parametras: „VMNetwork“, kur VM susiejame su konkrečiu tinklu klasteryje. Reitingas – svarbus perkeliant kelias VM; jis nustato jų paleidimo tvarką. Skonis – apibūdina VM konfigūraciją, šiuo atveju – 1CPU, 2GB RAM. Potinklio skiltyje apibrėžiame, kad "potinklis": "VMNetwork" yra susietas su VMware "VM Network".
Kuriant DR planą, nėra būdo „išskirstyti“ diskus įvairiose duomenų saugyklose. Jie bus toje pačioje duomenų saugykloje, kuri buvo apibrėžta šiam kliento debesiui, o jei turite skirtingų klasių diskus, tai gali sukelti tam tikrų sunkumų paleidžiant mašiną, o paleidus ir „atskyrus“ VM nuo Hystax taip pat reikia atskirų perkėlimo diskų į reikiamas duomenų saugyklas. Tada mums belieka pradėti savo DR planą ir laukti, kol mūsų automobiliai pakils. P2V/V2V konvertavimo procesas taip pat užtrunka. Mano didžiausiame bandomajame aparate, 100 GB su trimis diskais, tai užtruko daugiausia 10 minučių.
Po to turėtumėte patikrinti veikiančią VM, joje esančias paslaugas, duomenų nuoseklumą ir atlikti kitus patikrinimus.
Tada turime du būdus:
- Ištrinti – ištrinkite veikiantį DR planą. Šis veiksmas tiesiog išjungs veikiančią VM. Šios kopijos niekur nedings.
- Atskirti – atplėšti nuo Acura replikuotą automobilį, t.y. iš tikrųjų užbaigia perkėlimo procesą.
Sprendimo privalumai:
- paprastas diegimas ir konfigūravimas tiek iš kliento, tiek iš tiekėjo;
- paprastas perkėlimo nustatymas, DR plano kūrimas ir kopijų paleidimas;
- palaikymas ir kūrėjai gana greitai reaguoja į rastas problemas ir ištaiso jas naudodami platformos ar agento naujinimus.
Trūkumai
- Nepakankamas Vmware palaikymas.
- Nėra jokių nuomininkų kvotų platformoje.
Taip pat sudariau funkcijos užklausą, kurią pateikėme pardavėjui:
- naudojimo stebėjimas ir diegimas iš Acura valdymo pulto debesies agentams;
- nuomininkų kvotų prieinamumas;
- galimybė apriboti kiekvieno nuomininko vienu metu atliekamų replikacijų skaičių ir greitį;
- VMware vCloud Director palaikymas;
- išteklių telkinių palaikymas (įdiegtas testavimo metu);
- galimybė konfigūruoti VMware agentą iš paties agento, neįvedant kredencialų iš kliento infrastruktūros Acura skydelyje;
- VM paleidimo proceso „vizualizavimas“, kai vykdomas DR planas.
Vienintelis dalykas, kuris man sukėlė didelę kritiką, buvo dokumentacija. Nelabai mėgstu „juodąsias dėžutes“ ir man labiau patinka, kai yra išsami dokumentacija apie tai, kaip produktas veikia viduje. Ir jei AWS ir OpenStack produktas aprašytas dar daugiau ar mažiau, tai VMware dokumentacijos yra labai mažai.
Yra diegimo vadovas, kuriame aprašomas tik „Acura“ skydelio diegimas, ir nėra nė žodžio apie tai, kad reikalingas ir „Cloud“ agentas. Yra visas produkto specifikacijų rinkinys, o tai yra gerai. Yra dokumentų, kuriuose aprašoma sąranka „nuo pradžios iki pabaigos“, kaip pavyzdį naudojant AWS ir „OpenStack“ (nors man tai labiau atrodo kaip tinklaraščio įrašas), ir yra labai maža žinių bazė.
Apskritai, tai ne visai tas dokumentacijos formatas, prie kurio esu įpratęs, tarkime, iš didesnių pardavėjų, todėl man nebuvo visiškai patogu. Tuo pačiu metu šioje dokumentacijoje taip ir neradau atsakymų apie kai kuriuos sistemos veikimo „viduje“ niuansus – daug klausimų teko išsiaiškinti su technine pagalba, o tai gerokai atitolino stendo išdėstymo ir vykdymo procesą. testavimas.
Apibendrinant galiu pasakyti, kad apskritai man patiko produktas ir įmonės požiūris į užduotį. Taip, yra trūkumų, yra tikrai kritiškas funkcionalumo trūkumas (susijus su VMware). Akivaizdu, kad, visų pirma, įmonė vis dar orientuojasi į viešuosius debesis, ypač AWS, ir kai kuriems to pakaks. Turėti tokį paprastą ir patogų produktą šiandien, kai daugelis įmonių renkasi kelių debesų strategiją, yra be galo svarbu. Atsižvelgiant į daug mažesnę kainą, palyginti su konkurentais, tai daro produktą itin patraukliu.
Ieškome komandos nario . Gal tai tu?
Šaltinis: www.habr.com