Jedným z mladých hráčov na trhu riešení Disaster Recovery je spoločnosť Hystax – ruský startup z roku 2016. Keďže je téma obnovenia po havárii veľmi populárna a na trhu je mimoriadne vysoká konkurencia, startup sa rozhodol zamerať na migráciu medzi rôznymi cloudovými inštruktúrami. Produkt, ktorý umožňuje jednoduchú a rýchlu migráciu do cloudu, by bol veľmi užitočný aj pre klientov spoločnosti «Onlanta» — používateľov. . Takto som sa zoznámil s Hystax a začal testovať jeho možnosti. A čo z toho vzniklo, poviem v tomto článku.
Hlavnou prednosťou Hystaxu je jeho široká funkčnosť pri podpore rôznych virtualizačných platforiem, hosťovacích OS a cloudových služieb, čo umožňuje prenášať vaše pracovné zaťaženia odkiaľkoľvek a kamkoľvek.
To umožňuje vytvárať nielen DR-riešenia na zvýšenie odolnosti služieb, ale aj operatívne, flexibilne migrovať zdroje medzi rôznymi lokalitami a hyperscaleri pre zvýšenie úspor nákladov a voľbu najlepšieho riešenia pre konkrétnu službu v danom momente. Okrem platforiem uvedených na úvodnom obrázku, spoločnosť tiež aktívne spolupracuje s ruskými cloudovými poskytovateľmi: Yandex.Cloud, KROK „Cloudové služby“, Mail.ru a mnohými ďalšími. Tiež stojí za zmienku, že v roku 2020 spoločnosť získala R&D centrum, ktoré sa nachádza v Skolkove.
Výber jedného riešenia mnohými hráčmi na trhu hovorí o dobrej cenovej politike a vysokej aplikovateľnosti produktu, čo sme sa rozhodli overiť v praxi.
Takže náš testovací úloha bude pozostávať z migrácie z mojej testovacej plochy VMware a fyzických strojov na plochu poskytovateľa, ktorá je taktiež pod správou VMware. Áno, existuje množstvo riešení, ktoré môžu uskutočniť podobnú migráciu, ale my považujeme Hystax za univerzálny prostriedok, pričom testovať migráciu vo všetkých možných kombináciách je jednoducho nerealizovateľná úloha. A aj cloud Oncloud.ru je postavený práve na VMware, preto nás táto platforma ako cieľ zaujíma viac. Ďalej popíšem základný princíp fungovania, ktorý v podstate nezávisí od platformy, a VMware môže byť z každej strany nahradená platformou iného dodávateľa.
V prvej fáze je potrebné nasadiť Hystax Acura, ktorá slúži ako ovládací panel systému.
Nasadzuje sa z šablóny. Z nejakého dôvodu bola v našom prípade nesprávna a namiesto odporúčaných 8CPU, 16Gb sa nasadil s dvojnásobne menšími zdrojmi. Preto je potrebné nezabudnúť ich zmeniť, inak sa infraštruktúra postavená vo vnútri VM s kontajnerami jednoducho nespustí a portál nebude dostupný. V sú podrobne popísané požadované zdroje, ako aj porty pre všetky komponenty systému.
S priradením IP adresy cez šablónu sa tiež vyskytli ťažkosti, takže sme ju menili z konzoly. Potom je možné prejsť na webové rozhranie administrátorského panela a vyplniť počiatočný konfigurátor.
Endpoint – IP alebo FQDN nášho vCenter.
Login a Password – to je jasné.
Target ESXi hostname – jeden z hostiteľov nášho klastera, na ktorý sa bude vykonávať replikácia.
Target datastore – jeden z dátových úložísk nášho klastera, na ktorý sa bude vykonávať replikácia.
Hystax Acura Control Panel Public IP – adresa, na ktorej bude dostupný ovládací panel.
Potrebné malé objasnenie ohľadom hostiteľa a dátového úložiska. V skutočnosti replikácia Hystax funguje na úrovni hostiteľa a dátového úložiska. Ďalej vysvetlím, ako môže tenant zmeniť hostiteľa a dátové úložisko, ale problém je iný. Hystax nepodporuje prácu so zdrojovými poolmi, tzn. replikácia sa vždy uskutoční do koreňa klastru (počas písania tohto materiálu chlapci z Hystax vydali aktualizovanú verziu, kde rýchlo implementovali moju požiadavku na podporu zdrojových poolov). Taktiež nie je podporovaný vCloud Director, tzn. ak, ako v mojom prípade, tenant nemá administrátorské práva na celý klaster, ale len na konkrétny zdrojový pool, a poskytli sme prístup k Hystax, potom môže sám replikovať a spustiť tieto VMs, ale nebude mať prístup k ich zobrazeniu v infraštruktúre VMware, ku ktorej má prístup a, samozrejme, ďalej spravovať virtuálne stroje. Je potrebné, aby administrátor klastera presunul VM do požadovaného zdrojového poolu alebo ich importoval do vCloud Director.
Prečo kladiem taký dôraz na tieto body? Pretože, ak som správne pochopil koncept produktu, zákazník by mal mať možnosť realizovať akúkoľvek migráciu alebo DR pomocou panela Acura. Ale zatiaľ podporované VMware zaostáva vo svojom stupni podpory za OpenStack, kde sú takéto mechanizmy už implementované.
Ale vráťme sa k nasadeniu. Najprv, po počiatočnom nastavení panela, musíme vytvoriť prvého tenant v našom systéme.
Všetky polia sú jasné, poviem len o poli Cloud. Už máme 'predvolenú' cloud, ktorú sme vytvorili pri počiatočnej konfigurácii. Ale ak chceme mať možnosť umiestniť každého tenanta na vlastný dátový sklad a do vlastného zdrojového poolu, môžeme to realizovať vytvorením samostatných cloudov pre každého z našich zákazníkov.
Vo formulári pridania nového cloudu uvádzame tie isté parametre, ktoré sme použili pri počiatočnej konfigurácii (môžeme použiť aj ten istý host), uvádzame potrebný dátový sklad pre konkrétneho zákazníka, a teraz v dodatočných parametroch môžeme už individuálne uviesť potrebný zdrojový pool {«resource_pool»: «YOUR_POOL_NAME»}
Ako ste si mohli všimnúť, vo formulári na vytvorenie tenanta nie je nič o prideľovaní zdrojov alebo akýchkoľvek kvót – nič také v systéme neexistuje. Nie je možné obmedziť tenanta v počte súčasných replik, v počte strojov pre replikáciu alebo podľa akýchkoľvek iných parametrov. Takže sme vytvorili prvého tenanta. Teraz je tu nie úplne logická, ale povinná vec – inštalácia Cloud-agenta. Nie je logická, pretože agent sa sťahuje na stránke konkrétneho zákazníka.
Nepoťažuje sa však na vytvorený tenanta a všetci naši zákazníci budú prostredníctvom neho fungovať (alebo prostredníctvom viacerých, ak ich nasadíme). Jeden agent podporuje 10 súčasných relácií. Jedna relácia sa považuje za jeden stroj. Nezáleží pritom na tom, aké má množstvo diskov. V súčasnosti neexistuje mechanizmus na škálovanie agentov v samotnej Acura pod VMware. Je tu aj jeden nepríjemný moment – nemáme možnosť z panela Acura sledovať „vyťaženosť“ tohto agenta, aby sme zistili, či potrebujeme nasadiť ďalší, alebo či je aktuálna inštalácia dostatočná. Výsledkom je, že stanovište vyzerá nasledovne:
Nasledujúcim krokom pre prístup k portálu nášho zákazníka je vytvorenie účtu (a predtým ešte aj role, ktorá sa bude aplikovať na tohto používateľa).
Teraz môže náš zákazník používať portál samostatne. Všetko, čo musí urobiť, je stiahnuť si agenty z portálu a nainštalovať ich na svojom konci. Existujú tri typy agentov: Linux, Windows a VMware.
Prvé dve sa inštalujú na fyzické zariadenia alebo na virtuálne stroje na akomkoľvek hypervízore odlišnom od VMware. Tu nie je potrebné nič dodatočne konfigurovať, agent sa stiahne a už vie, kam sa má pripojiť, a doslova za minútu bude stroj viditeľný v paneli Acura. S agentom VMware je situácia o niečo zložitejšia. Problém je v tom, že agent pre VMware sa tiež sťahuje z portálu už pripravený a s potrebnou konfiguráciou. Ale agent VMware okrem znalosťou o našom portáli Acura potrebuje vedieť aj o virtualizačnom systéme, na ktorom bude nasadený.
Tieto údaje od nás systém vlastne požaduje počas prvého sťahovania agenta VMware. Problém je v tom, že v našej dobe všeobecnej lásky k bezpečnosti nie všetci budú chcieť uvádzať svoje administrátorské heslo na cudzom portáli, čo je celkom pochopiteľné. Zvnútra, po nasadení, už nie je možné agenta nijako konfigurovať (možno len zmeniť jeho sieťové nastavenia). Tu predpokladám ťažkosti so zvlášť opatrnými zákazníkmi.
Takže po inštalácii agentov sa môžeme vrátiť do panela Acura a vidieť všetky naše stroje.
Keďže už nejaký čas pracujem so systémom, mám stroje v rôznych stavoch. Všetky sú v skupine Default, no je možné vytvoriť samostatné skupiny a presunúť do nich stroje podľa potreby. To na nič dosť neovplyvňuje – ide iba o logické zobrazenie údajov a ich skupinovanie pre pohodlnejšiu prácu. Prvé a najdôležitejšie, čo musíme urobiť po tomto, je spustiť proces migrácie. Môžeme to urobiť buď manuálne na zoradenie, alebo nastaviť plán, vrátane hromadného procesu pre všetky stroje naraz.
Pripomínam, že Hystax je pozicionovaný ako produkt na migráciu. Preto nie je prekvapením, že na spustenie našich replikovaných strojov musíme vytvoriť plán DR. Plán možno zostaviť pre stroje, ktoré sú už v stave Synced. Môžeme ho generovať pre jednu konkrétnu VM alebo pre všetky stroje naraz.
Súbor parametrov pri generovaní DR-plánu sa bude líšiť v závislosti od infraštruktúry, do ktorej sa budete migrovať. Pre VMware prostredie je k dispozícii minimálny súbor parametrov. Taktiež sa nepodporuje Re-IP pre stroje. V tomto pláne nás zaujímajú nasledujúce body: v popise VM parameter „subnet”: „VMNetwork”, kde pripájame VM k konkrétnej sieti v klastri. Rank - je relevantný pri migrácii viacerých VM, určuje poradie ich spustenia. Flavor - popisuje konfiguráciu VM, v tomto prípade – 1CPU, 2GB RAM. V sekcii subnets definujeme, že „subnet”: „VMNetwork” je asociovaný so sieťou „VM Network” VMware.
Pri vytváraní DR-plánu nie je možné „rozdistribuovať” disky po rôznych datastoroch. Budú sa nachádzať na tom istom datastore, ktorý bol určený pre tento klientský cloud a ak máte disky rôzneho typu, môže to spôsobiť ťažkosti pri spustení stroja, a po spustení a „odpojení” VM od Hystax bude vyžadovať aj samostatnú migráciu diskov na požadované datastory. Potom nám zostáva len spustiť náš DR-plán a čakať, až sa naše stroje naštartujú. Proces konverzie P2V/V2V tiež trvá určitý čas. Na mojej najväčšej testovacej mašine s 100GB a tromi diskami to trvalo maximálne 10 minút.
Po tomto je potrebné skontrolovať spustenú VM, služby na nej, konzistenciu údajov a vykonať ďalšie kontroly.
Potom máme dve možnosti:
- Vymazať – odstrániť spustený DR plán. Táto činnosť jednoducho zastaví spustenú VM. Údaje repliky sa nikam nestratia.
- Odpojiť – odtrhnúť replikovanú jednotku od Acura, t.j. vlastne ukončiť proces migrácie.
Výhody tohto riešenia:
- jednoduchosť inštalácie a nastavenia z pohľadu klienta aj poskytovateľa;
- jednoduchosť nastavenia migrácie, vytvárania DR plánu a spúšťania replik;
- podpora a vývojári reagujú dosť rýchlo na zistené problémy a odstraňujú ich pomocou aktualizácií platformy alebo agentov.
Nevýhody
- Nedostatočná podpora pre Vmware.
- Nedostatok akéhokoľvek pridelovania pre tenantov zo strany platformy.
Taktiež som zostavil požiadavku na funkciu, ktorú sme odovzdali dodávateľovi:
- monitorovanie využívania a nasadzovania z ovládacieho panela Acura pre Cloud agentov;
- existencia kvót pre tenantov;
- možnosť obmedziť počet súčasných replikácií a rýchlosť pre každého tenanta;
- podpora VMware vCloud Director;
- podpora zdrojových poolov (bola implementovaná počas testovania);
- možnosť nastaviť VMware agenta priamo z agenta bez zadávania prihlasovacích údajov klientskiej infraštruktúry v ovládacom paneli Acura;
- „vizualizácia“ procesu spúšťania VM pri spustení DR plánu.
Jediné, čo mi spôsobilo veľké sťažnosti – je dokumentácia. Nemám veľmi rád „čierne skrinky“ a preferujem, keď je podrobná dokumentácia o tom, ako produkt pracuje vo vnútri. A ak je pre AWS a OpenStack produkt opísaný viac-menej, pre VMware je dokumentácie extrémne málo.
Existuje Inštalačný sprievodca, ktorý popisuje iba nasadenie ovládacieho panela Acura, a kde nie je ani slovo o tom, že je potrebný aj Cloud-agent. Existuje kompletná sada špecifikácií produktu, čo je dobré. Existuje dokumentácia, ktorá opisuje nastavenie „od a do“ na príklade AWS a OpenStack (aj keď mi to viac pripomína blogový príspevok), a existuje veľmi malá Znalostná báza.
Celkovo to nie je celkom ten formát dokumentácie, na ktorý som zvyknutý, povedzme, od väčších dodávateľov, takže som sa necítil úplne komfortne. Zároveň som prišiel o mnoho otázok ohľadom niektorých nuáns fungovania systému „vo vnútri“, ktoré som v tejto dokumentácii nenašiel – na veľmi veľa otázok som musel zisťovať odpovede od technickej podpory, a to značne predlžovalo proces nasadenia stánku a testovania.
Na záver môžem povedať, že celkovo sa mi produkt a prístup spoločnosti k riešeniu úlohy páčili. Áno, sú tu nedostatky, skutočne kritická nedostatočnosť funkčnosti (v spojení s VMware). Je zrejmé, že sa spoločnosť predovšetkým orientuje na verejné cloudové služby, najmä AWS, čo môže byť pre niekoho dostatočné. Prítomnosť takéhoto jednoduchého a pohodlného produktu dnes, keď mnohé firmy volia multicloudovú stratégiu, je mimoriadne dôležitá. Vzhľadom na oveľa nižšiu cenu v porovnaní s konkurenciou to robí produkt veľmi atraktívnym.
Hľadáme do nášho tímu . Môže to byť práve vy?
Zdroj: habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Lithuanian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish