Jedním z mladých hráčů na trhu řešení Disaster Recovery je společnost Hystax – ruský startup z roku 2016. Vzhledem k tomu, že téma obnovy po havárii je velmi populární a na trhu je extrémní konkurence, rozhodl se startup zaměřit na migraci mezi různými cloudovými infrastrukturami. Produkt, který umožňuje snadnou a rychlou migraci do cloudu, by byl velmi užitečný také pro klienty společnosti „Onlanta“ – uživatele. . Tak jsem se seznámil s Hystax a začal testovat jeho možnosti. A co z toho vzniklo, povím v tomto článku.
Hlavní předností Hystax je jeho široká funkčnost v oblasti podpory různých platforem virtualizace, hostitelských operačních systémů a cloudových služeb, což umožňuje přenášet vaše pracovní zátěže odkudkoli a kamkoli.
To umožňuje nejen vytvářet DR řešení pro zvýšení odolnosti služeb, ale také operativně a flexibilně migrovat zdroje mezi různými lokalitami a hyperscalery kvůli zvýšení úspor a výběru nejlepšího řešení pro konkrétní službu v daném okamžiku. Kromě platforem uvedených na titulním obrázku společnost také aktivně spolupracuje s ruskými cloudovými poskytovateli: Yandex.Cloud, KROK „Cloudové služby“, Mail.ru a mnoha dalšími. Také stojí za zmínku, že v roce 2020 se společnosti podařilo otevřít R&D centrum se sídlem ve Skolkovu.
Výběr jednoho řešení mnoha hráči na trhu naznačuje dobrou cenovou politiku a vysokou použitelnost produktu, což jsme se rozhodli ověřit v praxi.
Naším testovacím úkolem bude migrace z mé testovací platformy VMware a fyzických strojů na platformu poskytovatele, která je také pod správou VMware. Ano, existuje mnoho řešení, která mohou takovou migraci zrealizovat, ale Hystax považujeme za univerzální nástroj a testovat migraci ve všech možných kombinacích je zkrátka nereálný úkol. A navíc cloud Oncloud.ru je postaven právě na VMware, proto nás tato platforma jako cílová více zajímá. Dále popíšu základní princip fungování, který v zásadě nezávisí na platformě, a VMware může být z jakékoli strany nahrazena platformou jiného dodavatele.
V prvním kroku je nutné nasadit Hystax Acura, což je ovládací panel systému.
Nasazuje se z šablony. Z nějakého důvodu v našem případě nebyla zcela správná a místo doporučených 8CPU, 16Gb se nasazoval s polovičními prostředky. Proto je třeba je nezapomenout změnit, jinak se kontejnery infrastruktury uvnitř VM, na které je vše postaveno, prostě nespustí a portál nebude dostupný. V jsou podrobně popsány požadované prostředky a také porty pro všechny komponenty systému.
A s přiřazením IP adresy přes šablonu také vznikly potíže, takže jsme jej měnili z konzole. Pak lze přejít do webového rozhraní admin rozhraní a vyplnit počáteční nastavení konfigurace.
Endpoint – IP nebo FQDN našeho vCenter.
Login a Password – to je jasné.
Cílové ESXi hostname – jeden z hostitelů našeho clusteru, na který bude probíhat replikace.
Cílový datastore – jeden z datů našeho clusteru, na který bude probíhat replikace.
Hystax Acura Control Panel Public IP – adresa, na které bude dostupný ovládací panel.
Potřebuje se malé upřesnění ohledně hostitele a datastoru. Věc se má tak, že replikace Hystax funguje na úrovni hostitele a datastoru. Dále vám řeknu, jak pro tenant změnit hostitele a datastore, ale problém je jinde. Hystax nepodporuje práci s pooly zdrojů, tedy replikace vždy probíhá do kořene clusteru (během psaní tohoto materiálu vydali kluci z Hystax aktualizovanou verzi, kde rychle implementovali mou žádost o funkci týkající se podpory poolů zdrojů). Také není podporován vCloud Director, tedy pokud, jako v mém případě, tenant nemá administrátorská práva na celý cluster, ale pouze na konkrétní pool zdrojů, a my jsme dali přístup k Hystaxu, tak bude moci sám replikovat a spustit tyto VMs, ale nebude je moci vidět v infrastruktuře VMware, k níž má přístup, a tedy dále spravovat virtuální stroje. Je nezbytné, aby administrátor clusteru přesunul VM do požadovaného resource poolu nebo importoval do vCloud Director.
Proč na tyto věci tak poukazuji? Protože, jak chápu koncept produktu, zákazník by měl mít možnost provést jakoukoli migraci nebo DR pomocí panelu Acura. Ale podpora VMware zatím trochu zaostává ve srovnání s podporou OpenStack, kde jsou podobné mechanismy již realizovány.
Ale vraťme se k nasazení. Nejprve, po počátečním nastavení panelu, musíme vytvořit prvního nájemce v našem systému.
Všechna pole jsou zde srozumitelná, povím jen o poli Cloud. Již máme výchozí cloud, který jsme vytvořili při počáteční konfiguraci. Ale pokud chceme mít možnost umístit každého nájemce na vlastní datové úložiště a do vlastního zdrojového poolu, můžeme to realizovat vytvořením samostatných cloudů pro každého z našich zákazníků.
Ve formuláři pro přidání nového cloudu uvádíme stejné parametry, jaké jsme použili při počáteční konfiguraci (můžeme použít i stejný host), uvádíme potřebné datové úložiště pro konkrétního zákazníka, a nyní v dodatečných parametrech můžeme individuálně uvést potřebný zdrojový pool {„resource_pool“: „YOUR_POOL_NAME“}
Jak jste si mohli všimnout, ve formuláři pro vytvoření nájemce není nic o přidělování zdrojů nebo nějakých kvót - nic takového systém nemá. Není možné omezit nájemce na počet současných replik, počet strojů pro replikaci nebo podle jiných parametrů. Takže jsme vytvořili prvního nájemce. Nyní je tu něco nelogického, ale nezbytného - instalace Cloud-agenta. Je to nelogické, protože agent se stahuje na stránce konkrétního zákazníka.
Přitom se neprovazuje k vytvořenému tenantovi a všichni naši zákazníci budou pracovat skrze něj (nebo přes několik, pokud je nasadíme). Jeden agent podporuje 10 současných relací. Jedna relace se počítá jako jedno zařízení. Přitom nezáleží na tom, kolik má disků. V současné době v Acuře pod VMware neexistuje mechanismus pro škálování agentů. Je tu i další nepříjemný moment – nemáme možnost v panelu Acuře vidět „využití“ tohoto agenta, abychom zjistili, zda je potřeba nasadit další nebo zda je stávající instalace dostatečná. Výsledkem je, že stand vypadá takto:
Dalším krokem pro přístup k portálu našeho zákazníka je vytvoření účtu (a předtím ještě role, která bude aplikována na tohoto uživatele).
Nyní může náš zákazník používat portál samostatně. Vše, co musí udělat, je stáhnout agenty z portálu a nainstalovat je na své straně. Existují tři typy agentů: Linux, Windows a VMware.
První dva se instalují na fyzické nebo virtuální stroje na jakémkoli hypervizoru, který není VMware. Zde není potřeba nic dalšího konfigurovat, agent se stáhne a už ví, kam se má připojit, a doslova během minuty bude stroj viditelný v panelu Acuře. Situace s agentem pro VMware je o něco složitější. Problém je, že agent pro VMware se také stahuje z portálu již připraven a obsahuje potřebnou konfiguraci. Ale agent VMware kromě znalosti našeho portálu Acuře musí také znát virtualizační systém, na kterém bude nasazen.
Tyto údaje od nás systém požádá při prvním stažení agenta VMware. Problém je, že v naší době všeobecné lásky k bezpečnosti ne každý chce uvádět své administrátorské heslo na cizím portálu, což je zcela pochopitelné. Po nasazení již nelze agenta nikterak nakonfigurovat (lze pouze změnit jeho síťová nastavení). Předpokládám, že zde nastanou potíže s obzvlášť opatrnými zákazníky.
Takže po instalaci agentů se můžeme vrátit do panelu Acuře a vidět všechny naše stroje.
Jelikož se systémem pracuji už nějakou dobu, mám stroje v různých stádiích. Všechny se nachází ve skupině Default, ale je možné vytvořit jednotlivé skupiny a přesunout do nich stroje podle potřeby. To na nic neovlivní – jde pouze o logické uspořádání dat a jejich skupinování pro pohodlnější práci. První a nejdůležitější věc, kterou musíme po tomto udělat, je spustit proces migrace. To můžeme udělat buď manuálně, nebo nastavit plán, včetně hromadného zpracování pro všechny stroje najednou.
Připomínám, že Hystax se prezentoval jako produkt pro migraci. Proto není překvapující, že pro spuštění našich replikovaných strojů je třeba vytvořit DR plán. Plán může být sestaven pro stroje, které již jsou v režimu Synced. Můžeme generovat jak pro jednu konkrétní VM, tak pro všechny stroje najednou.
Sada parametrů při generaci DR plánu se bude lišit v závislosti na infrastruktuře, do které budete migrovat. Pro VMware prostředí je k dispozici minimální sada parametrů. Re-IP pro stroje také není podporováno. V tomto plánu nás zajímají následující aspekty: v popisu VM parametr „subnet“: „VMNetwork“, kde přidružujeme VM k konkrétní síti v klastru. Rank – je důležitý při migraci více VM, určuje pořadí jejich spuštění. Flavor – popisuje konfiguraci VM, v tomto případě – 1CPU, 2GB RAM. V sekci subnets definujeme, že „subnet“: „VMNetwork“ je asociován se sítí „VM Network“ VMware.
Při vytváření DR plánu není možné „rozdělit“ disky na různé datastory. Ty budou umístěny na stejném datastoru, který byl určen pro toto klientské cloudové úložiště, a pokud máte disky různého typu, může to způsobit některé potíže při spuštění stroje, a po spuštění a „odpojení“ VM od Hystax bude vyžadována samostatná migrace disků na potřebné datastory. Poté nám zbývá pouze spustit náš DR plán a čekat, až se naše stroje spustí. Proces konverze P2V/V2V také zabere čas. Na mém největším testovacím stroji s 100GB a třemi disky to zabralo maximálně 10 minut.
Poté je třeba zkontrolovat spuštěnou VM, služby na ní, konzistenci dat a provést další kontroly.
Dále máme dvě možnosti:
- Odstranit – vypnout spuštěný DR plán. Tato akce jednoduše vypne spuštěnou VM. Data repliky zůstanou zachována.
- Odpojit – oddělit replikovaný stroj od Acura, tj. fakticky dokončit proces migrace.
Výhody řešení:
- snadnost instalace a nastavení jak z pohledu klienta, tak z pohledu poskytovatele;
- snadnost nastavení migrace, vytváření DR plánu a spuštění replik;
- podpora a vývojáři rychle reagují na nalezené problémy a řeší je prostřednictvím aktualizací platformy nebo agentů.
Nevýhody
- Nedostatečná podpora pro VMware.
- Nedostatek jakéhokoli kvótování pro tenanty ze strany platformy.
Také jsem sestavil Feature Request, který jsme předali dodavateli:
- monitorování využití a nasazení z ovládacího panelu Acura pro Cloud agenty;
- existence kvót pro tenanty;
- možnost omezení počtu současných replikací a rychlosti pro každého tenant;
- podpora VMware vCloud Director;
- podpora zdrojových poolů (bylo realizováno během testování);
- možnost nastavení VMware agenta ze strany samotného agenta, bez zadávání přihlašovacích údajů z klientské infrastruktury v panelu Acura;
- vizualizace procesu spuštění VM při aktivaci DR plánu.
Jediné, co mi způsobilo velké výhrady, je dokumentace. Nemám příliš rád „černé skříňky“ a dávám přednost tomu, když existuje podrobná dokumentace o tom, jak produkt funguje uvnitř. A pokud je pro AWS a OpenStack produkt popsán více méně, pro VMware je dokumentace velmi nedostatečná.
Existuje instalační příručka, která popisuje pouze nasazení ovládacího panelu Acura, kde není ani slovo o tom, že potřebujete také Cloud agenta. Existuje kompletní soubor specifikací produktu, což je dobré. Existuje dokumentace, která popisuje nastavení „od A do Z“ na příkladu AWS a OpenStack (i když mi to více připomíná příspěvek na blogu), a je zde velmi malá Knowledge Base.
Celkově to není úplně formát dokumentace, na který jsem zvyklý, řekněme u větších dodavatelů, a proto jsem se necítil úplně pohodlně. Přitom jsem na některé nuance fungování systému „uvnitř“ nenašel odpovědi v této dokumentaci – musel jsem se na hodně otázek obracet na technickou podporu, což značně prodlužovalo proces nasazení standu a provádění testování.
Na závěr mohu říci, že celkově se mi produkt a přístup společnosti k realizaci úkolu líbily. Ano, existují nedostatky, je zde skutečně kritická nedostatečnost funkcionality (v kombinaci s VMware). Je patrné, že se společnost především zaměřuje na veřejná cloudová řešení, zejména AWS, a pro někoho to bude dostačující. Přítomnost takového jednoduchého a pohodlného produktu dnes, kdy mnoho společností volí multicloudovou strategii, je extrémně důležitá. Vzhledem k daleko nižší ceně ve srovnání s konkurencí to dělá produkt vysoce atraktivním.
Hledáme do našeho týmu . Možná jste to právě vy?
Zdroj: habr.com
