Jedním z mladých hráčů na trhu řešení Disaster Recovery je Hystax, ruský startup z roku 2016. Jelikož je téma obnovy po havárii velmi oblíbené a trh je extrémně konkurenční, rozhodl se startup zaměřit na migraci mezi různými cloudovými infrastrukturami. Produkt, který vám umožní organizovat jednoduchou a rychlou migraci do cloudu, by byl velmi užitečný i pro klienty Onlanty – uživatele . Tak jsem se seznámil s Hystaxem a začal testovat jeho schopnosti. Co z toho vzešlo, vám povím v tomto článku.
Hlavním rysem Hystaxu je jeho široká funkcionalita pro podporu různých virtualizačních platforem, hostovaný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 vám umožní vytvářet nejen DR řešení pro zvýšení odolnosti služeb, ale také rychle a flexibilně migrovat zdroje mezi různými lokalitami a hyperscalery pro zvýšení úspor nákladů a výběr nejlepšího řešení pro konkrétní službu v danou chvíli. Kromě platforem uvedených na titulním obrázku společnost aktivně spolupracuje také s ruskými poskytovateli cloudu: Yandex.Cloud, CROC Cloud Services, Mail.ru a mnoha dalšími. Za zmínku také stojí, že v roce 2020 společnost otevřela výzkumné a vývojové centrum ve Skolkově.
Volba jednoho řešení velkým množstvím hráčů na trhu svědčí o dobré cenové politice a vysoké použitelnosti produktu, který jsme se rozhodli vyzkoušet v praxi.
Náš testovací úkol se tedy bude skládat z migrace z mého testovacího webu VMware a fyzických počítačů na web poskytovatele, který rovněž spravuje VMware. Ano, existuje mnoho řešení, která takovou migraci dokážou provést, ale Hystax považujeme za univerzální nástroj a testování migrace ve všech možných kombinacích je prostě nereálný úkol. A cloud Oncloud.ru je postaven speciálně na VMware, takže tato platforma jako cíl nás zajímá ve větší míře. Dále popíšu základní princip fungování, který je obecně nezávislý na platformě a VMware z jakékoliv strany může být nahrazen platformou od jiného dodavatele.
Prvním krokem je nasazení Hystax Acura, což je ovládací panel systému.
Odvíjí se od šablony. Z nějakého důvodu to v našem případě nebylo úplně správné a místo doporučených 8CPU bylo nasazeno 16Gb s polovičními prostředky. Proto je potřeba pamatovat na jejich změnu, jinak se kontejnerová infrastruktura uvnitř VM, na které je vše postaveno, jednoduše nespustí a portál bude nepřístupný. V Požadované zdroje jsou podrobně popsány, stejně jako porty pro všechny součásti systému.
Problémy byly také s nastavením IP adresy pomocí šablony, takže jsme ji změnili z konzole. Poté můžete přejít do webového rozhraní správce a dokončit průvodce počáteční konfigurací.
Koncový bod – IP nebo FQDN našeho vCenter.
Login and Password – to je jasné.
Cílový název hostitele ESXi je jedním z hostitelů v našem clusteru, do kterého bude replikace provedena.
Cílové datové úložiště je jedním z datových úložišť v našem clusteru, do kterého bude provedena replikace.
Hystax Acura Control Panel Public IP – adresa, na které bude ovládací panel dostupný.
Je vyžadováno malé objasnění ohledně hostitele a úložiště dat. Faktem je, že replikace Hystax funguje na úrovni hostitele a datového úložiště. Dále vám řeknu, jak můžete změnit hostitele a datové úložiště pro tenanta, ale problém je jiný. Hystax nepodporuje práci s pooly zdrojů, tzn. replika vždy půjde do kořenového adresáře clusteru (v době psaní tohoto materiálu vydali kluci z Hystaxu aktualizovanou verzi, kde rychle implementovali můj požadavek na funkci týkající se podpory pro fondy zdrojů). Není podporován ani vCloud Director, tzn. pokud, jako v mém případě, tenant nemá práva správce k celému clusteru, ale pouze ke konkrétnímu fondu zdrojů, a my jsme mu poskytli přístup k Hystaxu, pak bude moci nezávisle replikovat a spouštět tyto virtuální počítače, ale bude neuvidí je v infrastruktuře VMware, ke které má přístup, a podle toho dále spravuje virtuální stroje. Je nutné, aby správce clusteru přesunul virtuální počítač do požadovaného fondu zdrojů nebo jej importoval do vCloud Director.
Proč se tolik zaměřuji na tyto body? Protože pokud rozumím konceptu produktu, zákazník by měl být schopen samostatně implementovat jakoukoli migraci nebo DR pomocí panelu Acura. Podpora VMware ale zatím mírně zaostává za úrovní podpory pro OpenStack, kde již podobné mechanismy byly implementovány.
Ale vraťme se k nasazení. Nejprve musíme po prvotním nastavení panelu vytvořit prvního tenanta v našem systému.
Všechna pole jsou jasná, řeknu vám pouze pole Cloud. Již máme „výchozí“ cloud, který jsme vytvořili během počáteční konfigurace. Ale pokud chceme mít možnost umístit každého tenanta na jeho vlastní datové úložiště a do jeho vlastního fondu zdrojů, můžeme to implementovat 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 zadáme stejné parametry jako při prvotní konfiguraci (můžeme použít i stejného hostitele), uvedeme datové úložiště potřebné pro konkrétního zákazníka a nyní v dalších parametrech můžeme individuálně specifikovat požadovaný zdroj fond {"resource_pool" : "YOUR_POOL_NAME"}
Jak jste si mohli všimnout, ve formuláři pro vytvoření tenanta není nic o alokaci zdrojů nebo jakýchkoli kvótách – nic z toho v systému není. Je nemožné omezit tenanta v počtu simultánních replik, počtu počítačů pro replikaci nebo jakýmikoli jinými parametry. Vytvořili jsme tedy prvního nájemce. Nyní je tu ne zcela logická, ale povinná věc - instalace Cloud agenta. Je to nelogické, protože agent je stažen na stránce konkrétního zákazníka.
Zároveň není vázán na vytvořeného tenanta a budou přes něj pracovat všichni naši zákazníci (nebo přes více, pokud je nasadíme). Jeden agent podporuje 10 simultánních relací. Jeden stroj se počítá jako jedna relace. Nezáleží na tom, kolik má disků. K dnešnímu dni neexistuje žádný mechanismus pro škálování agentů v samotné Acure pod VMware. Je tu ještě jeden nepříjemný moment - nemáme možnost podívat se na „likvidaci“ tohoto agenta z panelu Acura, abychom mohli usoudit, zda potřebujeme nasadit více nebo zda stačí aktuální instalace. V důsledku toho stojan vypadá takto:
Dalším krokem pro přístup k našemu zákaznickému portálu je vytvoření účtu (a nejprve role, která bude platit pro tohoto uživatele).
Nyní může náš zákazník používat portál samostatně. Stačí mu stáhnout agenty z portálu a nainstalovat si ho na svou stranu. Existují tři typy agentů: Linux, Windows a VMware.
První dva jsou nainstalovány na fyzice nebo na virtuálních strojích na jakémkoli jiném hypervizoru než VMware. Není potřeba nic dodatečně konfigurovat, agent se stáhne a už ví, kam zaklepat, a doslova za minutu bude auto vidět v panelu Acura. S agentem VMware je situace trochu složitější. Problém je v tom, že agent pro VMware je také stažen z portálu již připravený a obsahující potřebnou konfiguraci. Ale kromě znalosti našeho portálu Acura musí agent VMware také vědět o virtualizačním systému, na kterém bude nasazen.
Ve skutečnosti nás systém požádá o poskytnutí těchto dat při prvním stažení agenta VMware. Problém je v tom, že v našem věku univerzální lásky k bezpečnosti ne každý bude chtít uvádět své heslo správce na portálu někoho jiného, což je docela pochopitelné. Zevnitř po nasazení nelze agenta nijak konfigurovat (můžete pouze změnit jeho síťová nastavení). Zde předvídám potíže s obzvláště opatrnými zákazníky.
Takže po instalaci agentů se můžeme vrátit na panel Acura a prohlédnout si všechna naše auta.
Vzhledem k tomu, že se systémem pracuji již několik dní, mám auta v různých stavech. Všechny mám ve výchozí skupině, ale je možné vytvářet samostatné skupiny a přenášet do nich auta, jak potřebujete. Tím se nic neovlivní – pouze logická prezentace dat a jejich seskupení pro pohodlnější práci. První a nejdůležitější věc, kterou musíme poté udělat, je zahájit proces migrace. Můžeme to udělat buď ručně, nebo nastavením plánu, a to i hromadně pro všechny stroje najednou.
Dovolte mi připomenout, že Hystax byl umístěn jako produkt pro migraci. Proto není divu, že abychom mohli provozovat naše replikované stroje, musíme vytvořit plán DR. Plán lze vytvořit pro počítače, které jsou již ve stavu Synced. Můžete generovat jak pro jeden konkrétní VM, tak pro všechny stroje najednou.
Sada parametrů při generování plánu DR se bude lišit v závislosti na infrastruktuře, do které budete migrovat. Pro prostředí VMware je k dispozici minimální sada parametrů. Re-IP pro stroje také není podporováno. V tomto ohledu nás zajímají následující body: v popisu VM parametr „subnet“: „VMNetwork“, kde vážeme VM ke konkrétní síti v clusteru. Pořadí – relevantní při migraci několika virtuálních počítačů, určuje pořadí, ve kterém jsou spouštěny. Příchuť – popisuje konfiguraci VM, v tomto případě – 1CPU, 2GB RAM. V sekci podsítě definujeme, že "podsíť": "VMNetwork" je spojena s VMware "VM Network".
Při vytváření plánu DR neexistuje způsob, jak „rozložit“ disky mezi různá datová úložiště. Budou umístěny na stejném datovém úložišti, které bylo definováno pro tento klientský cloud, a pokud máte disky různých tříd, může to způsobit určité potíže při spouštění počítače a po spuštění a „oddělení“ virtuálního počítače od Hystax bude také vyžadovat samostatné migrační disky do požadovaných datových úložišť. Pak už jen zbývá spustit náš plán DR a čekat, až se naše auta zvednou. Proces konverze P2V/V2V také nějakou dobu trvá. Na mém největším testovacím stroji, 100GB se třemi disky, to trvalo maximálně 10 minut.
Poté byste měli zkontrolovat běžící virtuální počítač, služby na něm, konzistenci dat a provést další kontroly.
Pak máme dva způsoby:
- Smazat – smaže běžící plán DR. Tato akce jednoduše vypne běžící virtuální počítač. Tyto repliky nikam nevedou.
- Odpojit – odtrhnout replikované auto od Acury, tzn. skutečně dokončit proces migrace.
Plusy řešení:
- snadnost instalace a konfigurace ze strany klienta i poskytovatele;
- snadné nastavení migrace, vytvoření plánu DR a spouštění replik;
- podpora a vývojáři poměrně rychle reagují na nalezené problémy a opravují je pomocí aktualizací platformy nebo agentů.
Zápory
- Nedostatečná podpora Vmware.
- Absence jakýchkoli kvót pro nájemce z platformy.
Také jsem sestavil žádost o funkci, kterou jsme zaslali dodavateli:
- monitorování využití a nasazení z řídící konzoly Acura pro cloudové agenty;
- dostupnost kvót pro nájemce;
- schopnost omezit počet simultánních replikací a rychlost pro každého nájemce;
- podpora VMware vCloud Director;
- podpora pro fondy zdrojů (implementováno během testování);
- možnost konfigurovat agenta VMware ze samotného agenta bez zadávání přihlašovacích údajů z klientské infrastruktury na panelu Acura;
- „vizualizace“ procesu spouštění virtuálního počítače při spuštění plánu DR.
Jediná věc, která mi způsobila velkou kritiku, byla dokumentace. Nemám moc rád "černé skříňky" a preferuji, když je uvnitř podrobná dokumentace o tom, jak produkt funguje. A pokud pro AWS a OpenStack je produkt popsán ještě více či méně, pak pro VMware je dokumentace velmi málo.
Existuje Instalační příručka, která popisuje pouze nasazení panelu Acura a není tam ani slovo o tom, že je potřeba i Cloud agent. Existuje celá sada specifikací produktu, což je dobré. Existuje dokumentace, která popisuje nastavení „od začátku do konce“ pomocí AWS a OpenStack jako příklad (ačkoli mi to vypadá spíše jako příspěvek na blogu) a existuje velmi malá znalostní báze.
Obecně to není úplně formát dokumentace, na který jsem zvyklý řekněme od větších prodejců, takže mi to nebylo úplně příjemné. Zároveň jsem v této dokumentaci nikdy nenašel odpovědi na některé nuance toho, jak systém funguje „uvnitř“ - mnoho otázek bylo nutné objasnit s technickou podporou, což značně zdrželo proces rozmístění stojanu a vedení testování.
Abych to shrnul, mohu říci, že obecně se mi produkt a přístup společnosti k úkolu líbil. Ano, existují nedostatky, je zde opravdu kritický nedostatek funkčnosti (v souvislosti s VMware). Je jasné, že v první řadě se společnost stále zaměřuje na veřejné cloudy, konkrétně AWS, a někomu to bude stačit. Mít dnes tak jednoduchý a pohodlný produkt, kdy mnoho společností volí multicloudovou strategii, je nesmírně důležité. Vzhledem k mnohem nižší ceně ve srovnání s konkurencí to činí produkt mimořádně atraktivním.
Hledáme člena týmu . Možná jsi to ty?
Zdroj: www.habr.com