Hystax Cloud Migration: Riding the Clouds

Jedným z mladých hráčov na trhu riešení Disaster Recovery je Hystax, ruský startup v roku 2016. Keďže téma obnovy po havárii je veľmi populárna a trh je mimoriadne konkurenčný, startup sa rozhodol zamerať na migráciu medzi rôznymi cloudovými infraštruktúrami. Produkt, ktorý vám umožní organizovať jednoduchú a rýchlu migráciu do cloudu, by bol veľmi užitočný pre zákazníkov Onlanty – používateľov oncloud.ru. Tak som spoznal Hystax a začal som testovať jeho vlastnosti. A čo z toho vzniklo, poviem v tomto článku.

Hystax Cloud Migration: Riding the Clouds
Hlavnou črtou Hystaxu je jeho široká funkcionalita na podporu rôznych virtualizačných platforiem, hosťujúcich OS a cloudových služieb, čo umožňuje presúvať vaše pracovné zaťaženie odkiaľkoľvek a kdekoľvek.

To vám umožňuje vytvárať nielen DR riešenia na zvýšenie odolnosti služieb voči chybám, ale aj rýchlu a flexibilnú migráciu zdrojov medzi rôznymi lokalitami a hyperscalermi pre zvýšenie úspor nákladov a výber najlepšieho riešenia pre konkrétnu službu v danom momente. Okrem platforiem uvedených na titulnom obrázku spoločnosť aktívne spolupracuje aj s ruskými poskytovateľmi cloudu: Yandex.Cloud, CROC Cloud Services, Mail.ru a mnohými ďalšími. Za zmienku tiež stojí, že v roku 2020 spoločnosť otvorila R&D centrum v Skolkove. 

Výber jedného riešenia veľkým počtom hráčov na trhu svedčí o dobrej cenovej politike a vysokej použiteľnosti produktu, ktorý sme sa rozhodli otestovať v praxi.

Takže naša testovacia úloha bude pozostávať z migrácie z mojej testovacej lokality VMware a fyzických počítačov na lokalitu poskytovateľa, ktorú tiež spravuje VMware. Áno, existuje veľa riešení, ktoré dokážu takúto migráciu vykonať, no Hystax považujeme za univerzálny nástroj a testovanie migrácie vo všetkých možných kombináciách je jednoducho nereálna úloha. A cloud Oncloud.ru je postavený špeciálne na VMware, takže táto platforma ako cieľ nás zaujíma vo väčšej miere. Ďalej popíšem základný princíp fungovania, ktorý je vo všeobecnosti nezávislý od platformy a VMware z ktorejkoľvek strany môže byť nahradený platformou od iného dodávateľa. 

Prvým krokom je nasadenie Hystax Acura, čo je ovládací panel systému.

Hystax Cloud Migration: Riding the Clouds
Rozbalí sa zo šablóny. Z nejakého dôvodu to v našom prípade nebolo úplne správne a namiesto odporúčaných 8CPU bolo nasadených 16Gb s polovičnými zdrojmi. Preto je potrebné pamätať na ich zmenu, inak infraštruktúra vo vnútri VM, na ktorej je všetko postavené, jednoducho nezačne s kontajnermi a portál bude nedostupný. IN Požiadavky na nasadenie potrebné zdroje sú podrobne popísané, ako aj porty pre všetky súčasti systému. 

A tiež boli problémy s nastavením IP adresy cez šablónu, takže sme ju zmenili z konzoly. Potom môžete prejsť do webového rozhrania správcu a dokončiť sprievodcu úvodnou konfiguráciou. 

Hystax Cloud Migration: Riding the Clouds
Hystax Cloud Migration: Riding the Clouds
Koncový bod – IP alebo FQDN nášho vCenter. 
Prihlasovacie meno a heslo - tu je to jasné. 
Cieľový názov hostiteľa ESXi je jedným z hostiteľov v našom klastri, na ktorý sa bude replikovať. 
Cieľový dátový sklad je jedným z dátových skladov nášho klastra, do ktorého bude vykonaná replikácia.
Hystax Acura Control Panel Public IP – adresa, na ktorej bude dostupný ovládací panel.

Vyžaduje sa malé objasnenie hostiteľa a úložiska údajov. Faktom je, že replikácia Hystax funguje na úrovni hostiteľa a úložiska údajov. Ďalej vám poviem, ako môžete zmeniť hostiteľa a úložisko údajov pre nájomníka, ale problém je iný. Hystax nepodporuje združovanie zdrojov, t.j. replika sa vždy stane s koreňovým adresárom klastra (v čase písania tohto materiálu chlapci z Hystaxu vydali aktualizovanú verziu, kde rýchlo implementovali moju požiadavku na funkcie týkajúce sa podpory zdrojových fondov). Tiež nie je podporovaný vCloud Director, tj. ak, ako v mojom prípade, nájomník nemá práva správcu na celý klaster, ale iba na konkrétny fond zdrojov a my sme mu poskytli prístup k Hystaxu, potom bude môcť nezávisle replikovať a prevádzkovať tieto VM, ale bude nebude ich môcť vidieť v infraštruktúre VMware, ku ktorej má prístup, a podľa toho ďalej spravovať virtuálne stroje. Správca klastra musí presunúť VM do správneho fondu prostriedkov alebo ho importovať do vCloud Director.

Prečo sa tak sústreďujem na tieto momenty? Pretože, pokiaľ rozumiem konceptu produktu, zákazník by mal byť schopný samostatne implementovať akúkoľvek migráciu alebo DR pomocou panelu Acura. Zatiaľ však podpora VMware mierne zaostáva za úrovňou podpory rovnakého OpenStacku, kde už boli takéto mechanizmy implementované. 

Ale späť k nasadeniu. V prvom rade, po úvodnom nastavení panelu, musíme vytvoriť prvého nájomníka v našom systéme.

Hystax Cloud Migration: Riding the Clouds
Všetky polia sú tu jasné, poviem vám len o poli Cloud. Už máme „predvolený“ cloud, ktorý sme vytvorili pri prvotnej konfigurácii. Ale ak chceme mať možnosť umiestniť každého nájomníka do jeho vlastného dátového úložiska a do jeho vlastného fondu zdrojov, môžeme to implementovať vytvorením samostatných cloudov pre každého z našich zákazníkov.

Hystax Cloud Migration: Riding the Clouds
Formou pridania nového cloudu zadáme rovnaké parametre ako pri prvotnej konfigurácii (dokonca môžeme použiť rovnaký hostiteľ), špecifikujeme dátové úložisko potrebné pre konkrétneho zákazníka a teraz v dodatočných parametroch už vieme individuálne špecifikovať požadovaný zdroj fondu {"resource_pool" :"YOUR_POOL_NAME"} 

Ako ste si mohli všimnúť, vo forme vytvorenia nájomcu nie je nič o prideľovaní zdrojov alebo o nejakej kvóte – nič z toho v systéme nie je. Nájomníka nemôžete obmedziť počtom simultánnych replík, počtom počítačov na replikáciu ani žiadnymi inými parametrami. Vytvorili sme teda prvého nájomcu. Teraz je tu nie úplne logická, ale povinná vec - inštalácia Cloud agenta. Je to nelogické, pretože agent je stiahnutý na stránke konkrétneho zákazníka.

Hystax Cloud Migration: Riding the Clouds
Zároveň nie je viazaný na vytvoreného nájomcu a budú cez neho fungovať všetci naši zákazníci (alebo po viacerých, ak ich nasadíme). Jeden agent podporuje 10 simultánnych relácií. Jedna relácia sa počíta ako jedno auto. Nezáleží na tom, koľko má diskov. K dnešnému dňu neexistuje žiadny mechanizmus na škálovanie agentov v samotnej Acure pre VMware. Je tu ešte jeden nepríjemný moment – ​​nevieme sa pozrieť na „vyťaženosť“ tohto agenta z panelu Acura, aby sme usúdili, či potrebujeme nasadiť viac alebo stačí aktuálna inštalácia. V dôsledku toho stojan vyzerá takto:

Hystax Cloud Migration: Riding the Clouds
Ďalším krokom pre prístup na náš zákaznícky portál je vytvorenie účtu (a najprv aj rola, ktorá bude priradená tomuto užívateľovi).

Hystax Cloud Migration: Riding the Clouds
Hystax Cloud Migration: Riding the Clouds
Teraz môže náš zákazník využívať portál samostatne. Stačí mu stiahnuť agentov z portálu a nainštalovať ich na svoju stranu. Existujú tri typy agentov: Linux, Windows a VMware.

Hystax Cloud Migration: Riding the Clouds
Prvé dva sú umiestnené na fyzike alebo na virtuálnych strojoch na akomkoľvek hypervízore mimo VMware. Tu nie je potrebná žiadna ďalšia konfigurácia, agent sa stiahne a už vie, kde má zaklopať, a doslova za minútu bude auto viditeľné na paneli Acura. S agentom VMware je situácia trochu komplikovanejšia. Problém je v tom, že Agent for VMware sa sťahuje z portálu už pripravený a má potrebnú konfiguráciu. Ale agent VMware okrem toho, že musí vedieť o našom portáli Acura, musí vedieť aj o virtualizačnom systéme, na ktorom bude nasadený.

Hystax Cloud Migration: Riding the Clouds
V skutočnosti nás systém pri prvom stiahnutí agenta VMware požiada o špecifikáciu týchto údajov. Problém je v tom, že v našej dobe univerzálnej lásky k bezpečnosti nie každý bude chcieť na cudzom portáli uviesť svoje heslo správcu, čo je celkom pochopiteľné. Zvnútra po nasadení nemožno agenta nijako nakonfigurovať (môžete zmeniť iba jeho sieťové nastavenia). Tu predpokladám ťažkosti s obzvlášť opatrnými zákazníkmi. 

Takže po nainštalovaní agentov sa môžeme vrátiť na panel Acura a pozrieť si všetky naše autá.

Hystax Cloud Migration: Riding the Clouds
Keďže so systémom pracujem už viac ako deň, mám stroje v rôznych stavoch. Všetky sú v skupine Default, ale je možné vytvárať samostatné skupiny a prenášať do nich stroje podľa potreby. To nemá vplyv na nič - iba na logické znázornenie údajov a ich zoskupenie pre pohodlnejšiu prácu. Prvá a najdôležitejšia vec, ktorú potom musíme urobiť, je spustiť proces migrácie. Môžeme to urobiť vynútene manuálne a nastaviť plán, a to aj hromadne pre všetky stroje naraz.

Hystax Cloud Migration: Riding the Clouds
Dovoľte mi pripomenúť, že Hystax bol umiestnený ako produkt pre migráciu. Preto nie je prekvapujúce, že na to, aby sme mohli prevádzkovať naše replikované stroje, musíme vytvoriť plán DR. Môžete vytvoriť plán pre počítače, ktoré sú už v synchronizovanom stave. Môžete generovať pre jeden konkrétny VM aj pre všetky počítače naraz.

Hystax Cloud Migration: Riding the Clouds
Sada parametrov pri generovaní plánu DR sa bude líšiť v závislosti od infraštruktúry, do ktorej budete migrovať. Pre prostredie VMware je k dispozícii minimálna sada možností. Re-IP pre stroje tiež nie je podporovaná. V tejto súvislosti nás zaujímajú nasledujúce body: v popise VM parameter „podsieť“: „VMNetwork“, kde viažeme VM na konkrétnu sieť v klastri. Poradie – relevantné pri migrácii viacerých VM, určuje poradie, v ktorom sú spustené. Flavour popisuje konfiguráciu VM, v tomto prípade 1CPU, 2GB RAM. V sekcii podsiete definujeme, že „podsieť“: „VMNetwork“ je priradená k „VM Network“ spoločnosti VMware. 

Pri vytváraní plánu DR neexistuje spôsob, ako „rozdeliť“ disky medzi rôzne dátové úložiská. Budú umiestnené na rovnakom dátovom úložisku, ktoré bolo definované pre tento klientsky cloud, a ak máte disky rôznych tried, môže to spôsobiť určité ťažkosti pri spúšťaní počítača a po spustení a „oddelení“ VM od Hystax sa vyžadujú samostatné migračné disky na požadované dátové úložiská. Potom už len musíme spustiť náš plán DR a počkať, kým sa naše autá zdvihnú. Proces konverzie P2V/V2V si tiež vyžaduje čas. Na mojom najväčšom 100 GB testovacom stroji s tromi jednotkami to trvalo maximálne 10 minút.

Hystax Cloud Migration: Riding the Clouds
Potom by ste mali skontrolovať spustený VM, služby na ňom, konzistenciu údajov a ďalšie kontroly. 

Potom máme dve možnosti: 

  1. Odstrániť – vymaže spustený plán DR. Táto akcia jednoducho vypne spustený VM. Tieto repliky nikam nevedú. 
  2. Detach – odtrhnúť replikované auto od Acura, t.j. skutočne dokončiť proces migrácie. 

Výhody riešenia: 

  • jednoduchosť inštalácie a konfigurácie na strane klienta aj na strane poskytovateľa; 
  • jednoduchosť nastavenia migrácie, vytvorenie plánu DR a spustenie replík;
  • podpora a vývojári pomerne rýchlo reagujú na zistené problémy a opravujú ich pomocou aktualizácií platformy alebo agentov. 

Zápory 

  • Nedostatočná podpora Vmware.
  • Absencia akejkoľvek kvóty pre nájomcov z platformy. 

Urobil som tiež požiadavku na funkciu, ktorú sme odovzdali predajcovi:

  1. monitorovanie používania a nasadenie z riadiacej konzoly Acura pre cloudových agentov;
  2. dostupnosť kvót pre nájomcov; 
  3. schopnosť obmedziť počet simultánnych replikácií a rýchlosť pre každého nájomcu; 
  4. podpora pre VMware vCloud Director; 
  5. podpora pre fondy zdrojov (bola implementovaná počas testovania);
  6. možnosť konfigurovať agenta VMware zo strany samotného agenta bez zadávania poverení z klientskej infraštruktúry na paneli Acura;
  7.  "Vizualizácia" procesu spustenia VM pri spustení plánu DR. 

Jediné, čo mi spôsobilo veľké sťažnosti, bola dokumentácia. Nemám veľmi rád „čierne skrinky“ a preferujem, keď je vo vnútri podrobná dokumentácia o tom, ako produkt funguje. A ak pre AWS a OpenStack je produkt popísaný ešte viac-menej, potom pre VMware je veľmi málo dokumentácie. 

Existuje Inštalačná príručka, ktorá popisuje iba nasadenie panelu Acura a kde nie je ani slovo o potrebe cloudového agenta. K produktu existuje celá sada špecifikácií, čo je dobré. Existuje dokumentácia, ktorá popisuje nastavenie „od a do“ pomocou AWS a OpenStack ako príklad (hoci mi to pripomína skôr blogový príspevok) a existuje veľmi malá báza znalostí. 

Vo všeobecnosti to nie je úplne formát dokumentácie, na ktorý som zvyknutý, povedzme, od väčších predajcov, takže mi to nebolo úplne príjemné. Zároveň som v tejto dokumentácii nenašiel odpovede na niektoré nuansy fungovania systému „vo vnútri“ - veľa otázok som si musel vyjasniť s technickou podporou, čo skôr naťahovalo proces rozmiestnenia stojana a testovanie. 

Ak to zhrniem, môžem povedať, že vo všeobecnosti sa mi produkt a prístup spoločnosti k realizácii úlohy páčili. Áno, existujú chyby, existuje skutočne kritický nedostatok funkčnosti (v spojení s VMware). Je vidieť, že v prvom rade sa spoločnosť stále zameriava na verejné cloudy, konkrétne AWS, a niekomu to bude stačiť. Mať dnes taký jednoduchý a pohodlný produkt, keď veľa spoločností volí multi-cloudovú stratégiu, je mimoriadne dôležité. Vzhľadom na oveľa nižšiu cenu v porovnaní s konkurenciou to robí produkt mimoriadne atraktívnym.

Hľadáme tím Vedúci inžinier monitorovacích systémov. Možno si to ty?

Zdroj: hab.com

Pridať komentár