Einn af ungu leikmönnunum á Disaster Recovery lausnamarkaðnum er Hystax, rússneskt sprotafyrirtæki árið 2016. Þar sem efni hamfarabata er mjög vinsælt og markaðurinn er afar samkeppnishæfur ákvað gangsetningin að einbeita sér að flutningi milli mismunandi skýjainnviða. Vara sem gerir þér kleift að skipuleggja einfalda og fljótlega flutning í skýið væri mjög gagnleg fyrir viðskiptavini Onlanta - notendur . Þannig kynntist ég Hystax og fór að prófa eiginleika þess. Og hvað kom út úr því mun ég segja í þessari grein.
Helsti eiginleiki Hystax er víðtæk virkni þess til að styðja við ýmsa sýndarvæðingarvettvanga, gestastýrikerfi og skýjaþjónustu, sem gerir þér kleift að flytja vinnuálag þitt hvar sem er og hvar sem er.
Þetta gerir þér kleift að búa til ekki aðeins DR-lausnir til að bæta bilanaþol þjónustu, heldur einnig fljótt og sveigjanlegan flutning á tilföngum milli mismunandi vefsvæða og ofurskala til að auka kostnaðarsparnað og velja bestu lausnina fyrir tiltekna þjónustu í augnablikinu. Til viðbótar við pallana sem taldir eru upp á titilmyndinni, vinnur fyrirtækið einnig virkt samstarf við rússneska skýjafyrirtæki: Yandex.Cloud, CROC Cloud Services, Mail.ru og marga aðra. Það er líka athyglisvert að árið 2020 opnaði fyrirtækið R&D miðstöð staðsett í Skolkovo.
Val á einni lausn af miklum fjölda leikmanna á markaðnum gefur til kynna góða verðstefnu og mikla nothæfi vörunnar, sem við ákváðum að prófa í reynd.
Þannig að prófunarverkefnið okkar mun felast í því að flytja frá VMware prófunarsíðunni minni og líkamlegum vélum yfir á síðu þjónustuveitunnar sem keyrir einnig VMware. Já, það eru margar lausnir sem geta innleitt slíka flutning, en við lítum á Hystax sem alhliða tól og að prófa flutninginn í öllum mögulegum samsetningum er einfaldlega óraunhæft verkefni. Já, og Oncloud.ru skýið er byggt sérstaklega á VMware, þannig að þessi vettvangur, sem markmið, vekur áhuga okkar í meira mæli. Næst mun ég lýsa grunnreglunni um rekstur, sem í heild er ekki háð vettvangi, og VMware er hægt að skipta út frá hvaða hlið sem er fyrir vettvang frá öðrum söluaðila.
Fyrsta skrefið er að setja inn Hystax Acura, sem er stjórnborð kerfisins.
Það stækkar frá sniðmátinu. Af einhverjum ástæðum, í okkar tilviki, var það ekki alveg rétt og í stað ráðlagðs 8CPU var 16Gb notað með helmingi fjármagnsins. Þess vegna þarftu að muna að breyta þeim, annars munu innviðir inni í VM, sem allt er byggt á, einfaldlega ekki byrja með gámum og gáttin verður ekki tiltæk. IN nauðsynlegum tilföngum er lýst í smáatriðum, svo og höfnum fyrir alla kerfishluta.
Og það voru líka erfiðleikar við að stilla IP töluna í gegnum sniðmátið, svo við breyttum því frá stjórnborðinu. Eftir það geturðu farið í stjórnunarviðmótið og lokið við upphafsstillingarhjálpina.
Endapunktur - IP eða FQDN vCenter okkar.
Innskráning og lykilorð - það er skýrt hér.
Target ESXi hostname er einn af gestgjöfunum í klasanum okkar sem verður afritað til.
Target datastore er ein af gagnaverum í klasanum okkar sem verður afritað til.
Hystax Acura Control Panel Public IP - heimilisfangið þar sem stjórnborðið verður tiltækt.
Smá skýringar á hýsingaraðila og gagnageymslu er krafist. Staðreyndin er sú að afritun Hystax virkar á hýsil- og gagnageymslustigi. Næst mun ég segja þér hvernig þú getur breytt hýsingaraðilanum og gagnageymslunni fyrir leigjandann, en vandamálið er annað. Hystax styður ekki auðlindasamsetningu, þ.e. eftirmyndin mun alltaf gerast við rót þyrpingarinnar (þegar þetta efni var skrifað gáfu strákarnir frá Hystax út uppfærða útgáfu, þar sem þeir útfærðu fljótt eiginleikabeiðnina mína varðandi stuðning við auðlindahópa). Einnig er vCloud Director ekki stutt, þ.e. ef, eins og í mínu tilfelli, leigjandi hefur ekki stjórnunarréttindi á öllum klasanum, heldur aðeins tilteknum auðlindapotti, og við gáfum aðgang að Hystax, þá mun hann geta endurtekið og keyrt þessar VMs sjálfstætt, en hann mun ekki geta séð þær í VMware innviðum , sem hann hefur aðgang að og, í samræmi við það, frekar stjórnað sýndarvélum. Klasastjórnandinn þarf að færa VM í réttan auðlindahóp eða flytja hann inn í vCloud Director.
Af hverju einbeiti ég mér svona mikið að þessum augnablikum? Vegna þess að eins langt og ég skil hugmyndina um vöruna ætti viðskiptavinurinn að geta sjálfstætt innleitt hvaða flutning eða DR sem er með Acura spjaldið. En hingað til er stuðningur VMware aðeins á eftir stuðningi við sama OpenStack, þar sem slíkar aðferðir hafa þegar verið innleiddar.
En aftur að dreifingu. Fyrst af öllu, eftir fyrstu uppsetningu spjaldsins, þurfum við að búa til fyrsta leigjandann í kerfinu okkar.
Allir reitirnir hér eru skýrir, ég mun aðeins segja þér frá Cloud sviðinu. Við erum nú þegar með „sjálfgefið“ ský sem við bjuggum til við upphaflega uppsetningu. En ef við viljum geta sett hvern leigjanda í sína eigin gagnageymslu og í eigin auðlindapott, getum við innleitt þetta með því að búa til aðskilin ský fyrir hvern viðskiptavin okkar.
Í formi þess að bæta við nýju skýi, tilgreinum við sömu færibreytur og við upphaflegu uppsetninguna (við getum jafnvel notað sama hýsilinn), tilgreinum gagnageymsluna sem þarf fyrir tiltekinn viðskiptavin, og nú í viðbótarbreytunum getum við þegar tilgreint hver fyrir sig nauðsynleg tilföng laug {"resource_pool" :"YOUR_POOL_NAME"}
Eins og þú hefur kannski tekið eftir, í formi þess að búa til leigjanda, er ekkert um úthlutun auðlinda eða einhvers konar kvóta - það er ekkert af þessu í kerfinu. Þú getur ekki takmarkað leigjanda í fjölda samtímis eftirmynda, fjölda véla til afritunar eða með öðrum færibreytum. Þannig að við höfum búið til fyrsta leigjandann. Nú er það ekki alveg rökrétt, en lögboðinn hlutur - að setja upp Cloud umboðsmann. Það er órökrétt, vegna þess að umboðsmaðurinn er sóttur á síðu tiltekins viðskiptavinar.
Á sama tíma er það ekki bundið við stofnaðan leigjanda og allir viðskiptavinir okkar munu vinna í gegnum það (eða eftir nokkra, ef við sendum þá). Einn umboðsmaður styður 10 fundi samtímis. Ein lota telst einn bíll. Það skiptir ekki máli hversu marga diska það hefur. Hingað til er engin vélbúnaður fyrir mælikvarða í Acura sjálfu fyrir VMware. Það er eitt óþægilegt augnablik í viðbót - við getum ekki horft á "nýtingu" þessa umboðsmanns frá Acura spjaldinu til að komast að því hvort við þurfum að dreifa meira eða núverandi uppsetning er nóg. Fyrir vikið lítur standurinn svona út:
Næsta skref til að fá aðgang að gátt viðskiptavina okkar er að búa til reikning (og fyrst, einnig hlutverk sem verður notað fyrir þennan notanda).
Nú getur viðskiptavinur okkar notað gáttina sjálfstætt. Allt sem hann þarf að gera er að hlaða niður umboðsmönnum frá gáttinni og setja þá upp á hlið hans. Það eru þrjár gerðir umboðsmanna: Linux, Windows og VMware.
Fyrstu tveir eru settir á eðlisfræði eða á sýndarvélar á hvaða yfirvisara sem er ekki VMware. Það er engin viðbótarstilling nauðsynleg hér, umboðsmaðurinn halar niður og veit nú þegar hvar á að banka, og bókstaflega eftir eina mínútu verður bíllinn sýnilegur á Acura spjaldinu. Með VMware umboðsmanninum er staðan aðeins flóknari. Vandamálið er að Agent for VMware er einnig hlaðið niður af gáttinni sem þegar er undirbúin og með nauðsynlegar stillingar. En VMware umboðsmaðurinn þarf, auk þess að vita um Acura gáttina okkar, einnig að vita um sýndarvæðingarkerfið sem það verður sett á.
Reyndar mun kerfið biðja okkur um að tilgreina þessi gögn þegar þú hleður niður VMware umboðsmanni fyrst. Vandamálið er að á tímum okkar alhliða ástar á öryggi munu ekki allir vilja gefa til kynna stjórnanda lykilorð sitt á vefsíðu einhvers annars, sem er alveg skiljanlegt. Að innan, eftir dreifingu, er ekki hægt að stilla umboðsmanninn á nokkurn hátt (þú getur aðeins breytt netstillingum hans). Hér sé ég fyrir mér erfiðleika við sérstaklega varkára viðskiptavini.
Svo, eftir að hafa sett upp umboðsmennina, getum við farið aftur á Acura spjaldið og séð alla bílana okkar.
Þar sem ég hef verið að vinna með kerfið í meira en einn dag hef ég vélar í ýmsum ríkjum. Allar eru þær í Default hópnum, en það er hægt að búa til sérstaka hópa og flytja vélar á þá eftir þörfum. Þetta hefur ekki áhrif á neitt - aðeins rökrétt framsetning gagna og flokkun þeirra fyrir þægilegri vinnu. Það fyrsta og mikilvægasta sem við þurfum að gera eftir það er að hefja flutningsferlið. Við getum gert þetta bæði handvirkt með valdi og sett upp áætlun, þar á meðal í lausu fyrir allar vélar í einu.
Leyfðu mér að minna þig á að Hystax var staðsett sem vara fyrir fólksflutninga. Þess vegna kemur það ekki á óvart að til að keyra endurteknar vélar okkar þurfum við að búa til DR áætlun. Þú getur búið til áætlun fyrir vélar sem eru þegar í samstilltu ástandi. Þú getur búið til bæði fyrir eina tiltekna VM og fyrir allar vélar í einu.
Setja af breytum þegar búið er til DR áætlun mun vera mismunandi eftir innviðum sem þú munt flytja til. Lágmarks valkostur er í boði fyrir VMware umhverfi. Re-IP fyrir vélar er heldur ekki stutt. Í þessu sambandi höfum við áhuga á eftirfarandi atriðum: í lýsingu á VM, „undirnet“ færibreytan: „VMNetwork“, þar sem við bindum VM við ákveðið net í þyrpingunni. Staða – á við þegar fluttar eru nokkrar VM, ákvarðar í hvaða röð þær eru ræstar. Bragð lýsir VM uppsetningunni, í þessu tilfelli 1CPU, 2GB vinnsluminni. Í undirnetshlutanum skilgreinum við að „undirnet“: „VMNetwork“ er tengt „VM Network“ VMware.
Þegar búið er til DR áætlun er engin leið að „skipta“ diskum yfir mismunandi gagnaverslanir. Þeir verða staðsettir í sömu gagnageymslu sem var skilgreind fyrir þetta biðlaraský, og ef þú ert með diska af mismunandi flokkum, getur það valdið nokkrum erfiðleikum við að ræsa vélina, og eftir að hafa ræst og „aðskilið“ VM frá Hystax, mun það einnig krefjast sérstakrar flutningsdiska í nauðsynlegar gagnaverslanir. Þá verðum við bara að keyra DR áætlunina okkar og bíða eftir að bílarnir okkar hækki. P2V/V2V umbreytingarferlið tekur líka tíma. Á stærstu 100GB prófunarvélinni minni með þremur diskum tók þetta að hámarki 10 mínútur.
Eftir það ættir þú að athuga hlaupandi VM, þjónustu á honum, gagnasamkvæmni og aðrar athuganir.
Við höfum þá tvo valkosti:
- Eyða - eyða keyrandi DR áætlun. Þessi aðgerð mun einfaldlega leggja niður keyrandi VM. Þessar eftirlíkingar fara ekki neitt.
- Losaðu þig - rífðu endurgerða bílinn frá Acura, þ.e. klára í raun flutningsferlið.
Kostir lausnarinnar:
- auðveld uppsetning og stillingar bæði á viðskiptavinum og þjónustuveitanda;
- auðvelt að setja upp flutning, búa til DR áætlun og setja af stað eftirlíkingar;
- stuðningur og verktaki bregðast nokkuð fljótt við vandamálunum sem fundust og laga þau með uppfærslum á vettvangi eða umboðsmanni.
Gallar
- Ófullnægjandi Vmware stuðningur.
- Skortur á kvóta fyrir leigjendur frá pallinum.
Ég gerði líka eiginleikabeiðni, sem við afhentum seljanda:
- notkunarvöktun og uppsetning frá Acura Management Console fyrir Cloud Agents;
- framboð á kvóta fyrir leigjendur;
- getu til að takmarka fjölda samtímis endurtekningar og hraða fyrir hvern leigjanda;
- stuðningur við VMware vCloud Director;
- stuðningur við auðlindahópa (var innleiddur við prófun);
- getu til að stilla VMware umboðsmanninn frá hlið umboðsmannsins sjálfs, án þess að slá inn skilríki frá innviði viðskiptavinarins í Acura spjaldið;
- „Sjónsýn“ á því ferli að hefja VM þegar DR áætlun er hafin.
Það eina sem olli mér miklum kvörtunum var skjölin. Ég er ekki mjög hrifinn af "svörtum kassa" og vil frekar þegar það eru nákvæmar heimildir um hvernig varan virkar inni. Og ef vörunni er meira eða minna lýst fyrir AWS og OpenStack, þá er mjög lítið um skjöl fyrir VMware.
Það er til uppsetningarhandbók sem lýsir aðeins uppsetningu Acura spjaldsins og þar sem ekki er orð um þörfina fyrir Cloud umboðsmann. Það er fullt sett af forskriftum fyrir vöruna, sem er gott. Það eru til skjöl sem lýsa uppsetningunni „frá og til“ með því að nota AWS og OpenStack sem dæmi (þó það minni mig meira á bloggfærslu), og það er mjög lítill þekkingargrunnur.
Almennt séð er þetta ekki alveg skjalasniðið sem ég er vanur, td frá stærri söluaðilum, svo ég var ekki alveg sátt. Á sama tíma fann ég engin svör um sum blæbrigði aðgerða kerfisins „inni“ í þessum skjölum - ég þurfti að útskýra margar spurningar með tæknilega aðstoð, og þetta dró frekar út ferlið við að dreifa standinum og prófun.
Í stuttu máli get ég sagt að almennt líkaði mér við vöruna og nálgun fyrirtækisins við framkvæmd verkefnisins. Já, það eru gallar, það er mjög mikilvægur skortur á virkni (í tengslum við VMware). Það má sjá að í fyrsta lagi leggur fyrirtækið enn áherslu á almenningsský, sérstaklega AWS, og fyrir suma mun þetta duga. Að hafa svona einfalda og þægilega vöru í dag, þegar mörg fyrirtæki velja sér fjölskýjastefnu, er afar mikilvægt. Miðað við mun lægra verð miðað við keppinauta gerir þetta vöruna mjög aðlaðandi.
Við erum að leita að teymi . Kannski ert það þú?
Heimild: www.habr.com