Ien fan 'e jonge spilers op' e merk foar Disaster Recovery-oplossingen is Hystax, in Russyske opstart út 2016. Sûnt it ûnderwerp fan rampherstel heul populêr is en de merk ekstreem konkurrearjend is, besleat de opstart te rjochtsjen op migraasje tusken ferskate wolkinfrastruktuer. In produkt wêrmei jo in ienfâldige en rappe migraasje nei de wolk kinne organisearje soe ek heul nuttich wêze foar Onlanta's kliïnten - brûkers . Dat is hoe't ik yn 'e kunde kaam mei Hystax en begon syn mooglikheden te testen. Ik sil jo fertelle wat der fan kaam is yn dit artikel.
It wichtichste skaaimerk fan Hystax is syn brede funksjonaliteit om ferskate virtualisaasjeplatfoarms, gastbestjoeringssystemen en wolktsjinsten te stypjen, wat it mooglik makket om jo workloads oeral en oeral oer te dragen.
Hjirmei kinne jo net allinich DR-oplossingen meitsje om de fouttolerânsje fan tsjinsten te fergrutsjen, mar ek om boarnen fluch en fleksibel te migrearjen tusken ferskate siden en hyperscalers om kostenbesparring te fergrutsjen en de bêste oplossing foar in spesifike tsjinst op in bepaald momint te selektearjen. Neist de platfoarms neamd yn 'e titelôfbylding, wurket it bedriuw ek aktyf gear mei Russyske wolkproviders: Yandex.Cloud, CROC Cloud Services, Mail.ru en in protte oaren. It is ek de muoite wurdich op te merken dat it bedriuw yn 2020 in R&D-sintrum iepene yn Skolkovo.
De kar fan ien oplossing troch in grut oantal spilers op 'e merk jout oan in goed priisbelied en hege tapasberens fan it produkt, dat wy besletten om te testen yn 'e praktyk.
Dat, ús testtaak sil bestean út migraasje fan myn VMware-testside en fysike masines nei de side fan 'e provider, ek beheard troch VMware. Ja, d'r binne in protte oplossingen dy't sa'n migraasje kinne útfiere, mar wy beskôgje Hystax as in universele ark, en it testen fan migraasje yn alle mooglike kombinaasjes is gewoan in unrealistyske taak. En de Oncloud.ru-wolk is spesifyk boud op VMware, dus dit platfoarm as doel ynteresseart ús yn gruttere mjitte. Folgjende, Ik sil beskriuwe de basis prinsipe fan operaasje, dat is oer it algemien ûnôfhinklik fan it platfoarm, en VMware fan eltse kant kin wurde ferfongen troch in platfoarm fan in oare ferkeaper.
De earste stap is om Hystax Acura yn te setten, dat is it kontrôlepaniel fan it systeem.
It unfolds út it sjabloan. Om ien of oare reden wie it yn ús gefal net folslein korrekt en ynstee fan 'e oanbefellende 8CPU waard 16Gb ynset mei de helte fan' e middels. Dêrom moatte jo ûnthâlde om se te feroarjen, oars sil de kontenerynfrastruktuer binnen de VM, wêrop alles is boud, gewoan net begjinne en it portaal sil net tagonklik wêze. YN De fereaske boarnen wurde yn detail beskreaun, lykas havens foar alle systeemkomponinten.
D'r wiene ek swierrichheden by it ynstellen fan it IP-adres fia in sjabloan, dus wy feroare it fan 'e konsole. Hjirnei kinne jo nei de admin-webynterface gean en de inisjele konfiguraasjewizard foltôgje.
Einpunt - IP of FQDN fan ús vCenter.
Oanmelde en wachtwurd - dit is dúdlik.
Target ESXi hostnamme is ien fan de hosts yn ús kluster dêr't replikaasje wurdt útfierd.
Target datastore is ien fan 'e datastores yn ús kluster wêryn replikaasje sil wurde útfierd.
Hystax Acura Control Panel Public IP - it adres wêr't it kontrôlepaniel beskikber sil wêze.
In bytsje ferdúdliking is nedich oangeande de host en datastore. It feit is dat Hystax-replikaasje wurket op it nivo fan host en datastore. Folgjende sil ik jo fertelle hoe't jo de host en datastore kinne feroarje foar in hierder, mar it probleem is oars. Hystax stipet gjin wurkjen mei boarne pools, d.w.s. de replika sil altyd gean nei de woartel fan it kluster (op it momint fan it skriuwen fan dit materiaal, de jongens fan Hystax útbrocht in aktualisearre ferzje, dêr't se fluch ymplementearre myn funksje fersyk oangeande stipe foar boarne pools). vCloud Director wurdt ek net stipe, d.w.s. as, lykas yn myn gefal, de hierder gjin administraasjerjochten hat foar it heule kluster, mar allinich foar in spesifike boarnepool, en wy joegen tagong ta Hystax, dan sil hy dizze VM's selsstannich kinne replikearje en lansearje, mar hy sil net by steat wêze om te sjen se yn 'e VMware ynfrastruktuer , dêr't hy hat tagong en, dêrtroch, fierder beheart firtuele masines. It is nedich foar de klusterbehearder om de VM te ferpleatsen nei de winske boarne pool of ymportearje yn vCloud Director.
Wêrom rjochtsje ik my safolle op dizze punten? Om't, foar safier't ik it konsept fan it produkt begryp, de klant moat wêze kinne om selsstannich elke migraasje of DR út te fieren mei it Acura-paniel. Mar oant no ta is VMware-stipe in bytsje efter it nivo fan stipe foar OpenStack, wêr't ferlykbere meganismen al binne ymplementearre.
Mar litte wy weromgean nei ynset. Earst fan alles, nei de earste opset fan it paniel, moatte wy de earste hierder yn ús systeem oanmeitsje.
Alle fjilden hjir binne dúdlik, ik sil jo allinich fertelle oer it Wolkfjild. Wy hawwe al in "standert" wolk dy't wy makke hawwe tidens de earste konfiguraasje. Mar as wy elke hierder op syn eigen datastore en yn har eigen boarnepool wolle kinne pleatse, kinne wy dit ymplementearje troch aparte wolken foar elk fan ús klanten te meitsjen.
Yn it formulier foar it tafoegjen fan in nije wolk spesifisearje wy deselde parameters as yn 'e earste konfiguraasje (wy kinne sels deselde host brûke), jouwe de datastore oan dy't nedich is foar in spesifike klant, en no kinne wy yn ekstra parameters de fereaske boarne yndividueel opjaan pool {"resource_pool" : "YOUR_POOL_NAME"}
Lykas jo miskien hawwe opfallen, is d'r yn 'e formulier foar oanmeitsjen fan hierders neat oer tawizing fan boarnen of kwota's - d'r is neat fan dit yn it systeem. It is ûnmooglik om in hierder te beheinen yn it oantal simultane replika's, it oantal masines foar replikaasje, of troch oare parameters. Dat, wy hawwe de earste hierder makke. No is d'r in net folslein logysk, mar ferplicht ding - it ynstallearjen fan in Cloud-agint. It is ûnlogysk, om't de agint wurdt ynladen op 'e side fan in spesifike klant.
Tagelyk is it net bûn oan 'e makke hierder, en al ús klanten sille der troch wurkje (of troch ferskate, as wy se ynsette). Ien agint stipet 10 simultane sesjes. Ien masine wurdt rekkene as ien sesje. It makket neat út hoefolle skiven it hat. Oant no ta is d'r gjin meganisme foar skaalfergrutting yn Acura sels ûnder VMware. D'r is noch ien onaangenaam momint - wy hawwe net de kâns om te sjen nei de "ferwidering" fan dizze agint út it Acura-paniel om te konkludearjen oft wy mear moatte ynsette of oft de hjoeddeistige ynstallaasje genôch is. As resultaat sjocht de stand der sa út:
De folgjende stap om tagong te krijen ta ús klantportaal is om in akkount te meitsjen (en earst in rol dy't sil jilde foar dizze brûker).
No kin ús klant it portaal selsstannich brûke. Alles wat hy hoecht te dwaan is de aginten fan it portaal te downloaden en it op syn kant te ynstallearjen. D'r binne trije soarten aginten: Linux, Windows en VMware.
De earste twa wurde ynstalleare op natuerkunde as op firtuele masines op elke hypervisor oars as VMware. D'r is net nedich om wat ekstra te konfigurearjen, de agint is ynladen en wit al wêr't te klopjen, en letterlik yn in minút sil de auto sichtber wêze yn it Acura-paniel. Mei de VMware-agint is de situaasje in bytsje komplisearre. It probleem is dat de agent foar VMware ek wurdt ynladen fan it portal dat al taret is en de nedige konfiguraasje befettet. Mar neist it witten fan ús Acura-portaal, moat in VMware-agint ek witte oer it virtualisaasjesysteem wêrop it sil wurde ynset.
Eigentlik sil it systeem ús freegje om dizze gegevens te leverjen as wy de VMware-agint foar it earst downloade. It probleem is dat yn ús tiidrek fan universele leafde foar feiligens, net elkenien har admin-wachtwurd oanjaan sil op it portaal fan in oar, wat frij begryplik is. Fan binnen, nei ynset, kin de agint net op ien of oare manier konfigureare wurde (jo kinne allinich syn netwurkynstellingen feroarje). Hjir foarsjoch ik swierrichheden mei benammen foarsichtige klanten.
Dat, nei it ynstallearjen fan de aginten, kinne wy weromgean nei it Acura-paniel en al ús auto's sjen.
Sûnt ik haw wurke mei it systeem foar ferskate dagen no, Ik haw auto's yn ferskillende steaten. Ik haw se allegearre yn 'e Standert groep, mar it is mooglik om te meitsjen aparte groepen en oerdrage auto nei harren as jo nedich hawwe. Dit hat gjin ynfloed op neat - allinich in logyske presintaasje fan gegevens en har groepearring foar handiger wurk. It earste en wichtichste ding dat wy nei dit moatte dwaan is it migraasjeproses te begjinnen. Wy kinne dit of mei de hân dwaan of troch in skema op te stellen, ynklusyf yn bulk foar alle masines tagelyk.
Lit my jo herinnerje dat Hystax waard gepositioneerd as in produkt foar migraasje. Dêrom is it net ferrassend dat wy in DR-plan moatte meitsje om ús replike masines út te fieren. It plan kin makke wurde foar masines dy't al yn 'e Syngronisearre steat binne. Jo kinne sawol foar ien spesifike VM en foar alle masines tagelyk generearje.
De set parameters by it generearjen fan in DR-plan sil ferskille ôfhinklik fan 'e ynfrastruktuer wêr't jo nei migrearje. In minimale set fan parameters is beskikber foar de VMware-omjouwing. Re-IP foar masines wurdt ek net stipe. Yn dit ferbân binne wy ynteressearre yn 'e folgjende punten: yn' e VM-beskriuwing, de parameter "subnet": "VMNetwork", wêr't wy de VM bine oan in spesifyk netwurk yn it kluster. Rang - relevant by it migrearjen fan ferskate VM's; it bepaalt de folchoarder wêryn't se wurde lansearre. Flavor - beskriuwt de VM-konfiguraasje, yn dit gefal - 1CPU, 2GB RAM. Yn de subnets seksje wy definiearje dat "subnet": "VMNetwork" is assosjearre mei de VMware "VM Network".
By it meitsjen fan in DR-plan is d'r gjin manier om skiven te "fersprieden" oer ferskate datastores. Se sille lizze op deselde datastore dy't definieare is foar dizze kliïntwolk, en as jo skiven hawwe fan ferskate klassen, kin dit wat swierrichheden feroarsaakje by it starten fan 'e masine, en nei it starten en "skieden" fan' e VM fan Hystax, sil it ek fereaskje in aparte migraasje skiven nei de fereaske datastores. Dan alles wat wy hoege te dwaan is ús DR-plan lansearje en wachtsje oant ús auto's opkomme. It P2V / V2V-konverzjeproses nimt ek tiid. Op myn grutste testmasine, 100GB mei trije skiven, duorre it maksimaal 10 minuten.
Hjirnei moatte jo de rinnende VM kontrolearje, de tsjinsten dêrop, de konsistinsje fan 'e gegevens, en oare kontrôles útfiere.
Dan hawwe wy twa manieren:
- Wiskje - wiskje it rinnende DR-plan. Dizze aksje sil de rinnende VM gewoan ôfslute. Dizze replika's geane nergens hinne.
- Detach - tear in replicated auto fuort fan in Acura, i.e. eins foltôgje it migraasjeproses.
Foardielen fan de oplossing:
- gemak fan ynstallaasje en konfiguraasje sawol fan 'e kliïnt as fan' e provider;
- gemak fan it opsetten fan migraasje, it meitsjen fan in DR-plan en it lansearjen fan replika's;
- stipe en ûntwikkelders reagearje frij fluch op problemen fûn en reparearje se mei platfoarm- of agentupdates.
Минусы
- Net genôch Vmware-stipe.
- It ûntbrekken fan kwotas foar hierders fan it platfoarm.
Ik haw ek in Feature Request gearstald, dat wy yntsjinne by de ferkeaper:
- tafersjoch en ynset fan gebrûk fan 'e Acura-behearkonsole foar Cloud-aginten;
- beskikberens fan kwotas foar hierders;
- de mooglikheid om it oantal simultane replikaasjes en snelheid foar elke hierder te beheinen;
- VMware vCloud Director-stipe;
- stipe foar boarne pools (implementearre tidens testen);
- de mooglikheid om de VMware-agint te konfigurearjen fan 'e agint sels, sûnder referinsjes yn te fieren fan' e kliïntynfrastruktuer yn it Acura-paniel;
- "visualisaasje" fan it VM-startproses by it útfieren fan it DR-plan.
It iennichste dat my grutte krityk joech wie de dokumintaasje. Ik hâld net echt fan "swarte doazen" en leaver as d'r detaillearre dokumintaasje is oer hoe't it produkt binnen wurket. En as foar AWS en OpenStack it produkt noch mear of minder wurdt beskreaun, dan is d'r foar VMware heul lyts dokumintaasje.
D'r is in ynstallaasjegids dy't allinich de ynset fan it Acura-paniel beskriuwt, en d'r is gjin wurd oer it feit dat in Cloud-agint ek nedich is. Der is in folsleine set fan produkt spesifikaasjes, dat is goed. D'r is dokumintaasje dy't de opset "fan begjin oant ein" beskriuwt mei AWS en OpenStack as foarbyld (hoewol't it foar my mear liket op in blogpost), en d'r is in heul lytse Knowledge Base.
Yn 't algemien is dit net hielendal it dokumintaasjeformaat dat ik wend bin, bygelyks fan gruttere leveransiers, dus ik wie net hielendal noflik. Tagelyk fûn ik noait antwurden oer guon fan 'e nuânses fan hoe't it systeem "binnen" wurket yn dizze dokumintaasje - in protte fragen moasten dúdlik wurde mei technyske stipe, en dit fertrage it proses fan it ynsetten fan de stand en it útfieren fan testen.
Om gearfetsje, kin ik sizze dat ik yn 't algemien it produkt en de oanpak fan it bedriuw oan' e taak leuk fûn. Ja, d'r binne tekoarten, d'r is in echt kritysk gebrek oan funksjonaliteit (yn ferbân mei VMware). It is dúdlik dat, yn it foarste plak, it bedriuw noch rjochte is op iepenbiere wolken, benammen AWS, en foar guon sil dit genôch wêze. It hawwen fan sa'n ienfâldich en handich produkt hjoed, as in protte bedriuwen kieze in multi-wolk strategy, is ekstreem wichtich. Sjoen de folle legere priis yn ferliking mei konkurrinten, makket dit it produkt ekstreem oantreklik.
Wy sykje in teamlid . Miskien binne jo it?
Boarne: www.habr.com