Një nga lojtarët e rinj në tregun e zgjidhjeve të Rimëkëmbjes së Fatkeqësive është Hystax, një startup rus në 2016. Meqenëse tema e rikuperimit nga fatkeqësitë është shumë e njohur dhe tregu është jashtëzakonisht konkurrues, startup-i vendosi të fokusohet në migrimin midis infrastrukturave të ndryshme cloud. Një produkt që ju lejon të organizoni një migrim të thjeshtë dhe të shpejtë në cloud do të ishte shumë i dobishëm për klientët - përdoruesit e Onlanta . Kështu u njoha me Hystax dhe fillova të testoja aftësitë e tij. Unë do t'ju tregoj se çfarë erdhi prej saj në këtë artikull.
Tipari kryesor i Hystax është funksionaliteti i tij i gjerë për të mbështetur platforma të ndryshme virtualizimi, sisteme operative të ftuar dhe shërbime cloud, gjë që bën të mundur transferimin e ngarkesave tuaja të punës nga kudo, kudo.
Kjo ju lejon të krijoni jo vetëm zgjidhje DR për të rritur tolerancën ndaj gabimeve të shërbimeve, por edhe për të migruar shpejt dhe në mënyrë fleksibël burimet midis faqeve të ndryshme dhe hipershkalluesve për të rritur kursimet e kostos dhe për të zgjedhur zgjidhjen më të mirë për një shërbim specifik në një moment të caktuar. Përveç platformave të listuara në foton e titullit, kompania gjithashtu bashkëpunon në mënyrë aktive me ofruesit rusë të cloud: Yandex.Cloud, CROC Cloud Services, Mail.ru dhe shumë të tjerë. Vlen gjithashtu të theksohet se në vitin 2020 kompania hapi një qendër R&D të vendosur në Skolkovo.
Zgjedhja e një zgjidhjeje nga një numër i madh lojtarësh në treg tregon një politikë të mirë çmimi dhe zbatueshmëri të lartë të produktit, të cilin ne vendosëm ta testojmë në praktikë.
Pra, detyra jonë e testimit do të konsistojë në migrimin nga faqja ime e provës VMware dhe makinat fizike në faqen e ofruesit që funksionon gjithashtu VMware. Po, ka shumë zgjidhje që mund të zbatojnë një migrim të tillë, por ne e konsiderojmë Hystax si një mjet universal dhe testimi i migrimit në të gjitha kombinimet e mundshme është thjesht një detyrë joreale. Po, dhe cloud Oncloud.ru është ndërtuar posaçërisht në VMware, kështu që kjo platformë, si një objektiv, na intereson në një masë më të madhe. Tjetra, unë do të përshkruaj parimin bazë të funksionimit, i cili në tërësi nuk varet nga platforma, dhe VMware mund të zëvendësohet nga çdo anë me një platformë nga një shitës tjetër.
Hapi i parë është vendosja e Hystax Acura, e cila është paneli i kontrollit të sistemit.
Ai zgjerohet nga shablloni. Për disa arsye, në rastin tonë nuk ishte plotësisht e saktë dhe në vend të 8CPU-së së rekomanduar, 16 Gb u vendos me gjysmën e burimeve. Prandaj, duhet të mbani mend t'i ndryshoni ato, përndryshe infrastruktura e kontejnerëve brenda VM, mbi të cilën është ndërtuar gjithçka, thjesht nuk do të fillojë dhe portali do të jetë i paarritshëm. NË burimet e kërkuara janë përshkruar në detaje, si dhe portat për të gjithë komponentët e sistemit.
Kishte gjithashtu vështirësi në vendosjen e adresës IP përmes një shablloni, kështu që ne e ndryshuam atë nga tastiera. Pas kësaj, mund të shkoni te ndërfaqja e uebit e administratorit dhe të përfundoni magjistarin fillestar të konfigurimit.
Pika përfundimtare - IP ose FQDN e vQendrës sonë.
Hyrja dhe fjalëkalimi - është e qartë këtu.
Emri i hostit të synuar ESXi është një nga hostet në grupin tonë që do të kopjohet.
Target datastore është një nga depozitat e të dhënave në grupin tonë në të cilin do të kryhet replikimi.
IP-ja publike e Panelit të Kontrollit Hystax Acura – adresa ku paneli i kontrollit do të jetë i disponueshëm.
Kërkohet një sqarim i vogël për hostin dhe ruajtjen e të dhënave. Fakti është se riprodhimi i Hystax funksionon në nivelet e hostit dhe të ruajtjes së të dhënave. Më pas do t'ju tregoj se si mund të ndryshoni hostin dhe dyqanin e të dhënave për një qiramarrës, por problemi është ndryshe. Hystax nuk e mbështet punën me grupe burimesh, d.m.th. kopja do të shkojë gjithmonë në rrënjën e grupit (në kohën e shkrimit të këtij materiali, djemtë nga Hystax lëshuan një version të përditësuar, ku zbatuan shpejt kërkesën time të veçorive në lidhje me mbështetjen për grupet e burimeve). Drejtori vCloud gjithashtu nuk mbështetet, d.m.th. nëse, si në rastin tim, qiramarrësi nuk ka të drejta administratori për të gjithë grupin, por vetëm për një grup të veçantë burimesh, dhe ne i kemi dhënë akses Hystax, atëherë ai do të jetë në gjendje të kopjojë dhe lëshojë në mënyrë të pavarur këto VM, por ai do nuk mund t'i shohë ato në infrastrukturën VMware, në të cilën ai ka akses dhe, në përputhje me rrethanat, menaxhon më tej makinat virtuale. Është e nevojshme që administratori i grupit të zhvendosë VM-në në grupin e dëshiruar të burimeve ose ta importojë atë në Drejtorin vCloud.
Pse fokusohem kaq shumë në këto momente? Sepse, për aq sa unë e kuptoj konceptin e produktit, klienti duhet të jetë në gjendje të zbatojë në mënyrë të pavarur çdo migrim ose DR duke përdorur panelin Acura. Por deri më tani, mbështetja e VMware është pak prapa nivelit të mbështetjes për OpenStack, ku mekanizma të ngjashëm tashmë janë zbatuar.
Por përsëri te vendosja. Para së gjithash, pas konfigurimit fillestar të panelit, ne duhet të krijojmë qiramarrësin e parë në sistemin tonë.
Të gjitha fushat këtu janë të qarta, unë do t'ju tregoj vetëm për fushën Cloud. Ne tashmë kemi një re "të parazgjedhur" që kemi krijuar gjatë konfigurimit fillestar. Por nëse duam të jemi në gjendje të vendosim çdo qiramarrës në dyqanin e tij të të dhënave dhe në grupin e tij të burimeve, ne mund ta zbatojmë këtë duke krijuar re të veçanta për secilin prej klientëve tanë.
Në formularin për shtimin e një reje të re, ne specifikojmë të njëjtat parametra si gjatë konfigurimit fillestar (madje mund të përdorim të njëjtin host), tregojmë dyqanin e të dhënave që kërkohet për një klient specifik dhe tani në parametra shtesë mund të specifikojmë individualisht burimin e kërkuar pishinë {"resource_pool" : "YOUR_POOL_NAME"}
Siç mund ta keni vënë re, në formën e krijimit të një qiramarrësi nuk ka asgjë në lidhje me shpërndarjen e burimeve ose ndonjë lloj kuote - nuk ka asgjë nga kjo në sistem. Ju nuk mund ta kufizoni qiramarrësin në numrin e kopjeve të njëkohshme, numrin e makinave për riprodhim ose me ndonjë parametër tjetër. Pra, ne kemi krijuar qiramarrësin e parë. Tani ekziston një gjë jo plotësisht logjike, por e detyrueshme - instalimi i një agjenti Cloud. Është e palogjikshme, pasi agjenti shkarkohet në faqen e një klienti specifik.
Në të njëjtën kohë, ai nuk është i lidhur me qiramarrësin e krijuar dhe të gjithë klientët tanë do të punojnë përmes tij (ose pas disa, nëse i vendosim). Një agjent mbështet 10 seanca të njëkohshme. Një seancë llogaritet si një makinë. Nuk ka rëndësi sa disqe ka. Deri më sot, nuk ka asnjë mekanizëm për shkallëzimin e agjentëve në vetë Acura për VMware. Ekziston edhe një moment i pakëndshëm - ne nuk jemi në gjendje të shikojmë "përdorimin" e këtij agjenti nga paneli Acura në mënyrë që të konkludojmë nëse duhet të vendosim më shumë ose instalimi aktual është i mjaftueshëm. Si rezultat, stenda duket si kjo:
Hapi tjetër për të hyrë në portalin tonë të klientit është krijimi i një llogarie (dhe së pari, një rol që do të zbatohet për këtë përdorues).
Tani klienti ynë mund ta përdorë portalin në mënyrë të pavarur. Gjithçka që ai duhet të bëjë është të shkarkojë agjentë nga portali dhe t'i instalojë ato në anën e tij. Ekzistojnë tre lloje agjentësh: Linux, Windows dhe VMware.
Dy të parat vendosen në fizikë ose në makina virtuale në çdo hipervizor jo-VMware. Këtu nuk kërkohet asnjë konfigurim shtesë, agjenti shkarkon dhe tashmë e di se ku të trokasë, dhe fjalë për fjalë në një minutë makina do të jetë e dukshme në panelin Acura. Me agjentin VMware, situata është pak më e ndërlikuar. Problemi është se Agent for VMware gjithashtu shkarkohet nga portali i përgatitur tashmë dhe ka konfigurimin e nevojshëm. Por agjenti VMware, përveçse të dijë për portalin tonë Acura, duhet të dijë edhe për sistemin e virtualizimit në të cilin do të vendoset.
Në fakt, sistemi do të na kërkojë të specifikojmë këto të dhëna kur të shkarkoni për herë të parë agjentin VMware. Problemi është se në epokën tonë të dashurisë universale për sigurinë, jo të gjithë do të duan të tregojnë fjalëkalimin e tyre të administratorit në portalin e dikujt tjetër, gjë që është mjaft e kuptueshme. Nga brenda, pas vendosjes, agjenti nuk mund të konfigurohet në asnjë mënyrë (mund të ndryshoni vetëm cilësimet e rrjetit të tij). Këtu parashikoj vështirësi me klientët veçanërisht të kujdesshëm.
Pra, pas instalimit të agjentëve, ne mund të kthehemi te paneli Acura dhe të shohim të gjitha makinat tona.
Meqenëse kam disa ditë që punoj me sistemin, kam makina në shtete të ndryshme. Unë i kam të gjitha në grupin e paracaktuar, por është e mundur të krijoni grupe të veçanta dhe të transferoni makina tek ata sipas nevojës. Kjo nuk ndikon asgjë - vetëm një paraqitje logjike e të dhënave dhe grupimi i tyre për punë më të përshtatshme. Gjëja e parë dhe më e rëndësishme që duhet të bëjmë pas kësaj është të fillojmë procesin e migrimit. Ne mund ta bëjmë këtë ose me dorë ose duke vendosur një orar, duke përfshirë në masë për të gjitha makinat menjëherë.
Më lejoni t'ju kujtoj se Hystax u pozicionua si një produkt për migrim. Prandaj, nuk është për t'u habitur që për të drejtuar makinat tona të përsëritura, duhet të krijojmë një plan DR. Mund të krijoni një plan për makinat që janë tashmë në gjendjen e sinkronizuar. Ju mund të gjeneroni të dyja për një VM specifike, dhe për të gjitha makinat menjëherë.
Seti i parametrave kur krijoni një plan DR do të ndryshojë në varësi të infrastrukturës në të cilën do të migroni. Një grup minimal opsionesh është i disponueshëm për një mjedis VMware. Ri-IP për makineritë gjithashtu nuk mbështetet. Në këtë drejtim, ne jemi të interesuar për pikat e mëposhtme: në përshkrimin e VM, parametri "nënrrjet": "VMNetwork", ku lidhim VM me një rrjet specifik në grup. Renditja - e rëndësishme kur migroni disa VM, përcakton rendin në të cilin ato lëshohen. Flavor përshkruan konfigurimin e VM, në këtë rast 1CPU, 2 GB RAM. Në seksionin e nënrrjetave, ne përcaktojmë se "nënrrjeta": "VMNetwork" është i lidhur me "Rrjetin VM" të VMware.
Kur krijoni një plan DR, nuk ka asnjë mënyrë për të "përhapur" disqet nëpër të dhëna të ndryshme. Ato do të vendosen në të njëjtin dyqan të dhënash që është përcaktuar për këtë re të klientit, dhe nëse keni disqe të klasave të ndryshme, kjo mund të shkaktojë disa vështirësi gjatë nisjes së makinës dhe pas nisjes dhe "ndarjes" së VM nga Hystax, ajo gjithashtu do të kërkojnë një disqe të veçantë migrimi në të dhënat e kërkuara. Atëherë ne vetëm duhet të zbatojmë planin tonë DR dhe të presim që makinat tona të ngrihen. Procesi i konvertimit P2V/V2V kërkon gjithashtu kohë. Në makinën time më të madhe të testimit 100 GB me tre disqe, kjo zgjati maksimumi 10 minuta.
Pas kësaj, duhet të kontrolloni VM-në që funksionon, shërbimet në të, qëndrueshmërinë e të dhënave dhe të kryeni kontrolle të tjera.
Atëherë kemi dy opsione:
- Fshi – fshi planin DR që po funksionon. Ky veprim thjesht do të mbyllë VM-në që po funksionon. Këto kopje nuk po shkojnë askund.
- Shkëputeni - grisni një makinë të përsëritur nga një Acura, d.m.th. në fakt të përfundojë procesin e migrimit.
Përparësitë e zgjidhjes:
- lehtësia e instalimit dhe konfigurimit si nga klienti ashtu edhe nga ofruesi;
- lehtësia e vendosjes së migrimit, krijimi i një plani DR dhe lëshimi i kopjeve;
- mbështetja dhe zhvilluesit përgjigjen mjaft shpejt ndaj problemeve të gjetura dhe i rregullojnë ato duke përdorur përditësimet e platformës ose agjentëve.
Cons
- Mbështetje e pamjaftueshme Vmware.
- Mungesa e kuotave për qiramarrësit nga platforma.
Unë gjithashtu përpilova një Kërkesë për Veçori, të cilën ia dërguam shitësit:
- monitorimi dhe vendosja e përdorimit nga Paneli i Menaxhimit Acura për agjentët e resë kompjuterike;
- disponueshmëria e kuotave për qiramarrësit;
- aftësia për të kufizuar numrin e përsëritjeve të njëkohshme dhe shpejtësinë për çdo qiramarrës;
- mbështetje për VMware vCloud Director;
- mbështetje për grupet e burimeve (u zbatua gjatë testimit);
- aftësia për të konfiguruar agjentin VMware nga ana e vetë agjentit, pa futur kredencialet nga infrastruktura e klientit në panelin Acura;
- "Vizualizimi" i procesit të fillimit të një VM kur fillon një plan DR.
E vetmja gjë që më shkaktoi ankesa të mëdha ishte dokumentacioni. Nuk më pëlqejnë shumë "kutitë e zeza" dhe preferoj kur ka dokumentacion të detajuar se si funksionon produkti brenda. Dhe nëse për AWS dhe OpenStack produkti përshkruhet edhe pak a shumë, atëherë për VMware ka shumë pak dokumentacion.
Ekziston një Udhëzues Instalimi që përshkruan vetëm vendosjen e panelit Acura dhe nuk ka asnjë fjalë për faktin që nevojitet edhe një agjent Cloud. Ekziston një grup i plotë i specifikimeve për produktin, gjë që është e mirë. Ekziston një dokumentacion që përshkruan konfigurimin "nga fillimi në fund" duke përdorur AWS dhe OpenStack si shembull (edhe pse mua më duket më shumë si një postim në blog), dhe ka një bazë njohurish shumë të vogël.
Në përgjithësi, ky nuk është plotësisht formati i dokumentacionit me të cilin jam mësuar, të themi, nga shitësit më të mëdhenj, kështu që nuk isha plotësisht rehat. Në të njëjtën kohë, nuk gjeta kurrë përgjigje për disa nga nuancat se si funksionon sistemi "brenda" në këtë dokumentacion - më duhej të sqaroja shumë pyetje me mbështetje teknike, dhe kjo vonoi mjaft procesin e vendosjes së stendës dhe kryerjes duke testuar.
Për ta përmbledhur, mund të them se në përgjithësi më pëlqeu produkti dhe qasja e kompanisë ndaj detyrës. Po, ka mangësi, ka një mungesë vërtet kritike të funksionalitetit (në lidhje me VMware). Është e qartë se, para së gjithash, kompania është ende e përqendruar në retë publike, në veçanti AWS, dhe për disa kjo do të jetë e mjaftueshme. Të kesh një produkt kaq të thjeshtë dhe të përshtatshëm sot, kur shumë kompani po zgjedhin një strategji multi-cloud, është jashtëzakonisht e rëndësishme. Duke marrë parasysh çmimin shumë më të ulët në krahasim me konkurrentët, kjo e bën produktin jashtëzakonisht tërheqës.
Ne jemi në kërkim të një ekipi . Ndoshta je ti?
Burimi: www.habr.com