Isa sa mga batang manlalaro sa Disaster Recovery solutions market ay ang Hystax, isang Russian startup noong 2016. Dahil ang paksa ng pagbawi ng kalamidad ay napakapopular at ang merkado ay lubhang mapagkumpitensya, nagpasya ang startup na tumuon sa paglipat sa pagitan ng iba't ibang mga imprastraktura ng ulap. Ang isang produkto na nagbibigay-daan sa iyong ayusin ang isang simple at mabilis na paglipat sa cloud ay magiging lubhang kapaki-pakinabang para sa mga customer ng Onlanta - mga user . Iyon ay kung paano ko nakilala ang Hystax at nagsimulang subukan ang mga kakayahan nito. Sasabihin ko sa iyo kung ano ang nangyari sa artikulong ito.
Ang pangunahing tampok ng Hystax ay ang malawak na functionality nito upang suportahan ang iba't ibang virtualization platform, guest OS at cloud services, na ginagawang posible na ilipat ang iyong mga workload mula sa kahit saan at kahit saan.
Binibigyang-daan ka nitong lumikha hindi lamang ng mga solusyon sa DR upang mapabuti ang pagpapahintulot sa kasalanan ng mga serbisyo, kundi pati na rin ang mabilis, flexible na paglipat ng mga mapagkukunan sa pagitan ng iba't ibang mga site at hyperscaler upang mapataas ang pagtitipid sa gastos at piliin ang pinakamahusay na solusyon para sa isang partikular na serbisyo sa ngayon. Bilang karagdagan sa mga platform na nakalista sa larawan ng pamagat, ang kumpanya ay aktibong nakikipagtulungan sa mga tagapagbigay ng cloud ng Russia: Yandex.Cloud, CROC Cloud Services, Mail.ru at marami pang iba. Kapansin-pansin din na noong 2020 binuksan ng kumpanya ang isang R&D center na matatagpuan sa Skolkovo.
Ang pagpili ng isang solusyon ng isang malaking bilang ng mga manlalaro sa merkado ay nagpapahiwatig ng isang mahusay na patakaran sa pagpepresyo at mataas na kakayahang magamit ng produkto, na napagpasyahan naming subukan sa pagsasanay.
Kaya, ang aming pagsubok na gawain ay binubuo ng paglipat mula sa aking VMware test site at mga pisikal na makina patungo sa site ng provider na nagpapatakbo din ng VMware. Oo, maraming solusyon na maaaring magpatupad ng gayong paglipat, ngunit itinuturing namin ang Hystax bilang isang unibersal na tool, at ang pagsubok sa paglipat sa lahat ng posibleng kumbinasyon ay isang hindi makatotohanang gawain. Oo, at ang Oncloud.ru cloud ay partikular na binuo sa VMware, kaya ang platform na ito, bilang isang target, ay mas interesado sa amin. Susunod, ilalarawan ko ang pangunahing prinsipyo ng operasyon, na sa kabuuan ay hindi nakasalalay sa platform, at ang VMware ay maaaring mapalitan mula sa anumang panig ng isang platform mula sa isa pang vendor.
Ang unang hakbang ay ang pag-deploy ng Hystax Acura, na siyang control panel ng system.
Lumalawak ito mula sa template. Para sa ilang kadahilanan, sa aming kaso, hindi ito ganap na tama at sa halip na ang inirerekomendang 8CPU, 16Gb ang na-deploy na may kalahati ng mga mapagkukunan. Samakatuwid, kailangan mong tandaan na baguhin ang mga ito, kung hindi, ang imprastraktura sa loob ng VM, kung saan itinayo ang lahat, ay hindi magsisimula sa mga lalagyan at ang portal ay hindi magagamit. SA Ang mga kinakailangang mapagkukunan ay inilarawan nang detalyado, pati na rin ang mga port para sa lahat ng mga bahagi ng system.
At nagkaroon din ng mga kahirapan sa pagtatakda ng IP address sa pamamagitan ng template, kaya binago namin ito mula sa console. Pagkatapos nito, maaari kang pumunta sa web interface ng admin at kumpletuhin ang paunang configuration wizard.
Endpoint - IP o FQDN ng aming vCenter.
Login at Password - malinaw dito.
Ang target na ESXi hostname ay isa sa mga host sa aming cluster na gagayahin.
Ang target na datastore ay isa sa mga datastore sa aming cluster na gagawan ng kopya.
Hystax Acura Control Panel Public IP - ang address kung saan magiging available ang control panel.
Ang isang maliit na paglilinaw sa host at datastore ay kinakailangan. Ang katotohanan ay gumagana ang pagtitiklop ng Hystax sa mga antas ng host at datastore. Susunod, sasabihin ko sa iyo kung paano mo mapapalitan ang host at datastore para sa nangungupahan, ngunit iba ang problema. Hindi sinusuportahan ng Hystax ang resource pooling, i.e. ang replica ay palaging mangyayari sa ugat ng kumpol (sa oras ng pagsulat ng materyal na ito, ang mga lalaki mula sa Hystax ay naglabas ng isang na-update na bersyon, kung saan mabilis nilang ipinatupad ang aking kahilingan sa tampok tungkol sa suporta para sa mga mapagkukunang pool). Gayundin ang vCloud Director ay hindi suportado, ibig sabihin. kung, tulad ng sa aking kaso, ang nangungupahan ay walang mga karapatan ng admin sa buong cluster, ngunit sa isang partikular na mapagkukunang pool lamang, at nagbigay kami ng access sa Hystax, pagkatapos ay magagawa niyang independiyenteng kopyahin at patakbuhin ang mga VM na ito, ngunit gagawin niya hindi makita ang mga ito sa imprastraktura ng VMware , kung saan mayroon siyang access at, nang naaayon, higit pang pamahalaan ang mga virtual machine. Kailangang ilipat ng administrator ng cluster ang VM sa tamang resource pool o i-import ito sa vCloud Director.
Bakit masyado akong nakatutok sa mga sandaling ito? Dahil, sa pagkakaintindi ko sa konsepto ng produkto, ang customer ay dapat na nakapag-iisa na magpatupad ng anumang paglipat o DR gamit ang Acura panel. Ngunit sa ngayon, ang suporta ng VMware ay bahagyang nasa likod ng antas ng suporta para sa parehong OpenStack, kung saan ang mga naturang mekanismo ay naipatupad na.
Ngunit bumalik sa deployment. Una sa lahat, pagkatapos ng paunang pag-setup ng panel, kailangan naming gawin ang unang nangungupahan sa aming system.
Ang lahat ng mga patlang dito ay malinaw, sasabihin ko lamang sa iyo ang tungkol sa patlang ng Cloud. Mayroon na kaming "default" na ulap na ginawa namin sa paunang pagsasaayos. Ngunit kung gusto naming mailagay ang bawat nangungupahan sa sarili nitong datastore at sa sarili nitong resource pool, maaari naming ipatupad ito sa pamamagitan ng paglikha ng hiwalay na mga ulap para sa bawat isa sa aming mga customer.
Sa anyo ng pagdaragdag ng isang bagong ulap, tinukoy namin ang parehong mga parameter tulad ng sa panahon ng paunang pagsasaayos (maaari pa naming gamitin ang parehong host), tukuyin ang datastore na kinakailangan para sa isang partikular na customer, at ngayon sa mga karagdagang parameter maaari na naming isa-isa na tukuyin ang kinakailangang mapagkukunan ng pool {"resource_pool" :"YOUR_POOL_NAME"}
Tulad ng maaaring napansin mo, sa anyo ng paglikha ng isang nangungupahan ay walang tungkol sa paglalaan ng mga mapagkukunan o ilang uri ng mga quota - wala nito sa system. Hindi mo maaaring limitahan ang nangungupahan sa bilang ng sabay-sabay na mga replika, ang bilang ng mga makina para sa pagtitiklop, o ng anumang iba pang mga parameter. Kaya, nilikha namin ang unang nangungupahan. Ngayon mayroong isang hindi ganap na lohikal, ngunit ipinag-uutos na bagay - pag-install ng isang ahente ng Cloud. Ito ay hindi makatwiran, dahil ang ahente ay nai-download sa pahina ng isang partikular na customer.
Kasabay nito, hindi ito nakatali sa nilikhang nangungupahan, at lahat ng aming mga customer ay gagana sa pamamagitan nito (o pagkatapos ng ilang, kung i-deploy namin sila). Sinusuportahan ng isang ahente ang 10 sabay-sabay na session. Ang isang session ay binibilang bilang isang kotse. Hindi mahalaga kung gaano karaming mga disk ang mayroon ito. Sa ngayon, walang mekanismo para sa pag-scale ng mga ahente sa Acura mismo para sa VMware. May isa pang hindi kasiya-siyang sandali - hindi namin matingnan ang "paggamit" ng ahente na ito mula sa panel ng Acura upang mapag-isipan kung kailangan naming mag-deploy ng higit pa o sapat na ang kasalukuyang pag-install. Bilang resulta, ganito ang hitsura ng stand:
Ang susunod na hakbang upang ma-access ang portal ng aming customer ay lumikha ng isang account (at una, isang tungkulin din na ilalapat sa user na ito).
Ngayon ay magagamit na ng aming customer ang portal nang nakapag-iisa. Ang kailangan lang niyang gawin ay mag-download ng mga ahente mula sa portal at i-install ang mga ito sa kanyang tabi. May tatlong uri ng mga ahente: Linux, Windows, at VMware.
Ang unang dalawa ay inilalagay sa physics o sa mga virtual machine sa anumang non-VMware hypervisor. Walang kinakailangang karagdagang pagsasaayos dito, nagda-download ang ahente at alam na kung saan kakatok, at literal sa isang minuto ay makikita ang kotse sa panel ng Acura. Sa ahente ng VMware, ang sitwasyon ay medyo mas kumplikado. Ang problema ay ang Agent para sa VMware ay nai-download din mula sa portal na handa na at pagkakaroon ng kinakailangang pagsasaayos. Ngunit ang ahente ng VMware, bilang karagdagan sa pag-alam tungkol sa aming portal ng Acura, ay kailangan ding malaman ang tungkol sa sistema ng virtualization kung saan ito idi-deploy.
Sa totoo lang, hihilingin sa amin ng system na tukuyin ang data na ito kapag una mong na-download ang ahente ng VMware. Ang problema ay na sa ating panahon ng unibersal na pag-ibig para sa seguridad, hindi lahat ay nais na ipahiwatig ang kanilang admin password sa portal ng ibang tao, na medyo naiintindihan. Mula sa loob, pagkatapos ng pag-deploy, ang ahente ay hindi maaaring i-configure sa anumang paraan (maaari mo lamang baguhin ang mga setting ng network nito). Dito ko nahuhulaan ang mga paghihirap sa lalo na maingat na mga customer.
Kaya, pagkatapos i-install ang mga ahente, maaari tayong bumalik sa panel ng Acura at makita ang lahat ng ating mga sasakyan.
Dahil nagtatrabaho ako sa system nang higit sa isang araw, mayroon akong mga makina sa iba't ibang estado. Ang lahat ng mga ito ay nasa Default na grupo, ngunit posible na lumikha ng hiwalay na mga grupo at ilipat ang mga makina sa kanila, ayon sa kailangan mo. Hindi ito nakakaapekto sa anuman - tanging ang lohikal na representasyon ng data at ang kanilang pagpapangkat para sa mas maginhawang gawain. Ang una at pinakamahalagang bagay na kailangan nating gawin pagkatapos nito ay simulan ang proseso ng paglipat. Magagawa natin ito nang sapilitang manu-mano, at mag-set up ng iskedyul, kasama ang maramihan para sa lahat ng makina nang sabay-sabay.
Ipaalala ko sa iyo na ang Hystax ay nakaposisyon bilang isang produkto para sa paglipat. Samakatuwid, hindi nakakagulat na upang patakbuhin ang aming mga replicated machine, kailangan naming lumikha ng isang DR plan. Maaari kang lumikha ng isang plano para sa mga makina na nasa naka-sync na estado. Maaari kang bumuo ng pareho para sa isang partikular na VM, at para sa lahat ng machine nang sabay-sabay.
Ang hanay ng mga parameter kapag bumubuo ng DR plan ay mag-iiba depende sa imprastraktura kung saan ka lilipat. Ang isang minimal na hanay ng mga pagpipilian ay magagamit para sa isang kapaligiran ng VMware. Hindi rin sinusuportahan ang re-IP para sa mga machine. Kaugnay nito, interesado kami sa mga sumusunod na punto: sa paglalarawan ng VM, ang parameter na "subnet": "VMNetwork", kung saan ibinebinhi namin ang VM sa isang partikular na network sa cluster. Rank - may kaugnayan kapag naglilipat ng ilang VM, tinutukoy ang pagkakasunud-sunod kung saan inilunsad ang mga ito. Inilalarawan ng Flavor ang configuration ng VM, sa kasong ito ay 1CPU, 2GB RAM. Sa seksyong subnets, tinukoy namin na ang "subnet": "VMNetwork" ay nauugnay sa "VM Network" ng VMware.
Kapag gumagawa ng DR plan, walang paraan para "hatiin" ang mga disk sa iba't ibang datastore. Matatagpuan ang mga ito sa parehong datastore na tinukoy para sa cloud ng kliyente na ito, at kung mayroon kang mga disk ng iba't ibang klase, maaaring magdulot ito ng ilang mga paghihirap kapag sinisimulan ang makina, at pagkatapos simulan at "paghiwalayin" ang VM mula sa Hystax, ito rin ay nangangailangan ng hiwalay na migration disk sa mga kinakailangang datastore. Pagkatapos ay kailangan lang naming patakbuhin ang aming plano sa DR at maghintay para sa aming mga sasakyan na tumaas. Ang proseso ng conversion ng P2V/V2V ay tumatagal din ng oras. Sa aking pinakamalaking 100GB na test machine na may tatlong disk, tumagal ito ng maximum na 10 minuto.
Pagkatapos nito, dapat mong suriin ang tumatakbong VM, mga serbisyo dito, pagkakapare-pareho ng data at iba pang mga pagsusuri.
Mayroon kaming dalawang pagpipilian:
- Tanggalin - tanggalin ang tumatakbong DR plan. Ang pagkilos na ito ay magsasara lamang ng tumatakbong VM. Ang mga replika na ito ay hindi mapupunta kahit saan.
- Tanggalin - tanggalin ang kinopya na kotse mula sa Acura, i.e. talagang kumpletuhin ang proseso ng paglipat.
Mga kalamangan ng solusyon:
- kadalian ng pag-install at pagsasaayos kapwa sa panig ng kliyente at sa panig ng provider;
- kadalian ng pag-set up ng migration, paggawa ng DR plan at paglulunsad ng mga replika;
- ang suporta at mga developer ay mabilis na tumugon sa mga problemang natagpuan at ayusin ang mga ito gamit ang mga update sa platform o ahente.
Cons
- Hindi sapat na suporta sa Vmware.
- Ang kawalan ng anumang quota para sa mga nangungupahan mula sa platform.
Gumawa din ako ng Feature Request, na ipinasa namin sa vendor:
- pagsubaybay sa paggamit at pag-deploy mula sa Acura Management Console para sa Cloud Agents;
- pagkakaroon ng mga quota para sa mga nangungupahan;
- ang kakayahang limitahan ang bilang ng sabay-sabay na pagtitiklop at bilis para sa bawat nangungupahan;
- suporta para sa VMware vCloud Director;
- suporta para sa mga mapagkukunang pool (ipinatupad sa panahon ng pagsubok);
- ang kakayahang i-configure ang ahente ng VMware mula sa gilid ng mismong ahente, nang hindi naglalagay ng mga kredensyal mula sa imprastraktura ng kliyente sa panel ng Acura;
- "Visualization" ng proseso ng pagsisimula ng VM kapag nagsisimula ng DR plan.
Ang tanging bagay na nagdulot sa akin ng malalaking reklamo ay ang dokumentasyon. Hindi ko talaga gusto ang "mga itim na kahon" at mas gusto ko kapag may detalyadong dokumentasyon kung paano gumagana ang produkto sa loob. At kung para sa AWS at OpenStack ang produkto ay inilarawan nang higit pa o mas kaunti, kung gayon para sa VMware mayroong napakakaunting dokumentasyon.
Mayroong Gabay sa Pag-install na naglalarawan lamang sa pag-deploy ng panel ng Acura, at walang salita tungkol sa katotohanang kailangan din ng ahente ng Cloud. Mayroong isang buong hanay ng mga pagtutukoy ng produkto, na mabuti. Mayroong dokumentasyon na naglalarawan sa pag-setup "mula sa simula hanggang sa katapusan" gamit ang AWS at OpenStack bilang isang halimbawa (bagaman ito ay mas mukhang isang post sa blog sa akin), at mayroong isang napakaliit na Knowledge Base.
Sa pangkalahatan, hindi ito ang format ng dokumentasyon na nakasanayan ko, sabihin, mula sa mas malalaking vendor, kaya hindi ako lubos na komportable. Kasabay nito, hindi ako nakahanap ng mga sagot tungkol sa ilan sa mga nuances ng kung paano gumagana ang system "sa loob" sa dokumentasyong ito - Kailangan kong linawin ang maraming mga tanong na may teknikal na suporta, at medyo naantala nito ang proseso ng pag-deploy ng stand at pagsasagawa pagsubok.
Upang buod, maaari kong sabihin na sa pangkalahatan ay nagustuhan ko ang produkto at ang diskarte ng kumpanya sa gawain. Oo, may mga pagkukulang, mayroong talagang kritikal na kakulangan ng pag-andar (kaugnay ng VMware). Malinaw na, una sa lahat, ang kumpanya ay nakatuon pa rin sa mga pampublikong ulap, sa partikular na AWS, at para sa ilan ay magiging sapat na ito. Ang pagkakaroon ng simple at maginhawang produkto ngayon, kapag maraming kumpanya ang pumipili ng multi-cloud na diskarte, ay napakahalaga. Isinasaalang-alang ang mas mababang presyo kumpara sa mga kakumpitensya, ginagawa nitong lubos na kaakit-akit ang produkto.
Naghahanap kami ng isang miyembro ng koponan . Baka ikaw yun?
Pinagmulan: www.habr.com