Hystax Cloud Migration: plovimo po oblakih

Eden iz mladih igralcev na tržišču rešitev za obnovo po katastrofi je podjetje Hystax – ruski start-up iz leta 2016. Ker je tema obnovitve po katastrofi zelo priljubljena in na trgu izredno visoka konkurenca, se je start-up odločil osredotočiti na migracijo med različnimi oblačnimi infrastrukturalami. Izdelek, ki omogoča preprosto in hitro migracijo v oblak, bi bil zelo koristen tudi strankam podjetja „Onlanta“ – uporabnikom Oncloud.ru. Tako sem se spoznal s Hystax in začel preizkušati njegove možnosti. Kaj je iz tega nastalo, bom opisal v tem članku.

Glavna posebnost Hystax je njegova široka funkcionalnost pri podpori različnih platform virtualizacije, gostujočih operacijskih sistemov in oblačnih storitev, kar omogoča prenos vaših delovnih obremenitev od koderkoli kamorkoli.

To omogoča ustvarjanje ne le DR-rešitev za povečanje odpornosti storitev, temveč tudi hitro in fleksibilno migracijo virov med različnimi platformami in hiperskalniki, da se poveča ekonomičnost in izbere najboljša rešitev za določeno storitev v danem trenutku. Poleg platform, navedenih na naslovni sliki, podjetje aktivno sodeluje tudi z ruskimi oblačnimi ponudniki: Yandex.Cloud, KROK „Oblačne storitve“, Mail.ru in mnogimi drugimi. Prav tako je treba omeniti, da je podjetje v letu 2020 ustanovilo R&D center, ki se nahaja v Skolkovo. 

Izbira enega samega rešitve s strani velikega števila igralcev na trgu govori o dobri cenovni politiki in visoki uporabnosti izdelka, kar smo se odločili preveriti v praksi.

Tako bo naša testna naloga obsegala migracijo z moje testne platforme VMware in fizičnih naprav na platformo ponudnika, prav tako pod upravljanjem VMware. Da, obstaja mnogo rešitev, ki lahko realizirajo to migracijo, a mi obravnavamo Hystax kot univerzalno orodje, medtem ko bi bilo preizkušanje migracije v vseh možnih kombinacijah preprosto nerealna naloga. Pa tudi oblak Oncloud.ru je zgrajen prav na VMware, zato nas ta platforma kot ciljna bolj zanima. Nadalje bom opisal osnovno načelo delovanja, ki v osnovi ne odvisno od platforme, in VMware bi bilo mogoče zamenjati z drugo platformo drugega dobavitelja. 

V prvem koraku je potrebno razpostaviti Hystax Acura, ki predstavlja nadzorno ploščo sistema.

Postavi se iz predloge. Iz neznanega razloga v našem primeru ni bila povsem pravilna in namesto priporočenih 8CPU, 16Gb, se je razpostavila s prepolovljenimi viri. Zato jih je potrebno spremeniti, sicer infrastruktura znotraj VM, na kateri je vse zgrajeno, ne bo delovala in portal bo nedostopen. V Zahteve za postavitev so podrobno opisane potrebne vire ter vrata za vse komponente sistema. 

Pri nastavljanju IP-naslova preko predloge so se pojavile težave, zato smo ga spremenili iz konzole. Po tem se lahko preklopiš v spletni vmesnik za administracijo in izpolniš začetni čarovnik konfiguracije. 

Endpoint – IP ali FQDN našega vCenter. 
Prijava in geslo – to je jasno. 
Ciljni ESXi hostname – eden izmed hostov našega klasterja, na katerega bo potekala replikacija. 
Ciljni datastore – eden izmed datastore-ov našega klasterja, na katerega bo potekala replikacija.
Javni IP Hystax Acura Control Panel – naslov, preko katerega bo dostopna nadzorna plošča.

Potrebno je majhno pojasnilo glede gosta in datastore-a. Gre namreč za to, da replikacija Hystax deluje na ravni gosta in datastore-a. Kasneje bom opisal, kako lahko za najemnika spremenimo gosta in datastore, a težava je drugje. Hystax ne podpira dela z bazeni virov, tj. replikacija se vedno dogaja v koren klasterja (med pisanjem tega gradiva so fantje iz Hystax izdal posodobljeno različico, kjer so hitro vnesli moj predlog za podporo bazenom virov). Prav tako ne podpira vCloud Director, tj. če, kot v mojem primeru, najemnik nima administratorskih pravic za celoten klaster, ampak le za določen bazen virov, in smo mu omogočili dostop do Hystax, potem lahko samostojno replikate in zažene te VM, vendar jih ne bo mogel videti v VMware infrastrukturi, do katere ima dostop in posledično upravljati z virtualnimi stroji. Potrebno je, da administrator klasterja premakne VM v ustrezen bazen virov ali jo uvozi v vCloud Director.

Zakaj tako poudarjam te točke? Ker, kot razumem koncept izdelka, bi moral naročnik imeti možnost, da samostojno izvede katero koli migracijo ali DR s pomočjo nadzorne plošče Acura. A podpora za VMware trenutno nekoliko zaostaja za podporo OpenStack, kjer so takšni mehanizmi že implementirani. 

Vrnimo se k uvajanju. Prvi korak po začetni nastavitvi nadzorne plošče je ustvariti prvega najemnika v našem sistemu.

Vsa polja tukaj so jasna; omenil bom le polje Cloud. Že imamo 'privzeto' oblak, ki smo ga ustvarili pri prvotni konfiguraciji. Če pa želimo, da lahko vsak najemnik uporablja svoj lasten podatkovni prostor in lasten nabor virov, lahko to dosežemo z ustvarjanjem ločenih oblakov za vsakega od naših naročnikov.

V obrazcu za dodajanje novega oblaka navedemo iste parametre kot pri prvotni konfiguraciji (lahko uporabimo celo isti strežnik), določimo zahtevan podatkovni prostor za konkretnega naročnika, zdaj pa lahko v dodatnih parametrih posamezno navedemo potreben nabor virov {«resource_pool»: «YOUR_POOL_NAME»} 

Kot ste morda opazili, v obrazcu za ustvarjanje najemnika ni ničesar o dodelitvi virov ali kakršnih koli kvot – v sistemu ni ničesar tega. Ni mogoče omejiti števila hkratnih replik, števila strojev za replikacijo ali drugih parametrov. Torej, ustvarili smo prvega najemnika. Zdaj je tu nekoliko nelogična, a obvezna naloga – namestitev Cloud-agenta. Nelogična je, ker se agent prenese na strani konkretnega naročnika.

Pri tem se ne povezuje s ustvarjenim tenantom, preko njega pa bodo delali vsi naši naročniki (ali več njih, če jih namestimo). En agent podpira 10 hkratnih sej. Ena seja se šteje za en računalnik. Pri tem ni pomembno, koliko diskov ima. Do danes mehanizma za razširitev agentov v sami Acura pod VMware ni. Je pa še en neprijeten trenutek – nimamo možnosti iz nadzorne plošče Acura pregledati "izkoriščenost" tega agenta, da bi ugotovili, ali moramo razširiti še enega ali je trenutna namestitev dovolj. Tako stojalo izgleda tako:

Naslednji korak za dostop do portala našega naročnika je ustvariti uporabniški račun (pred tem pa še vlogo, ki bo dodeljena temu uporabniku).

Zdaj lahko naš naročnik samostojno uporablja portal. Vse, kar mora storiti, je, da prenese agente s portala in jih namesti na svoji strani. Obstajajo tri vrste agentov: Linux, Windows in VMware.

Prvi dve se namestita na fizične ali virtualne stroje na katerem koli hipervizorju, ki ni VMware. Tukaj ni potrebno dodatno ničesar konfigurirati, agent se prenese in že ve, kam mora sporočiti, in dobesedno v nekaj minutah bo računalnik viden na nadzorni plošči Acura. Situacija z agentom VMware je nekoliko bolj zapletena. Težava je v tem, da se agent za VMware prav tako prenaša s portala, že pripravljen in z zahtevano konfiguracijo. A agentu VMware, poleg znanja o našem portalu Acura, potrebuje tudi informacije o virtualizacijskem sistemu, na katerem bo nameščen.

Dejansko so ti podatki, ki jih bo sistem od nas zahteval, ob prvem prenosu agenta VMware. Težava pa je v tem, da v našem času splošne ljubezni do varnosti le redko kdo želi vnesti svojo administratorsko geslo na tujem portalu, kar je povsem razumljivo. Znotraj, po namestitvi, agenta ni mogoče še dodatno konfigurirati (lahko se le spremeni njegove omrežne nastavitve). Tukaj predvidevam težave s še posebej previdnimi naročniki. 

Torej, po namestitvi agentov se lahko vrnemo v nadzorno ploščo Acura in vidimo vse naše stroje.

Ker sem že nekaj dni v sistemu, imam stroje v različnih stanjih. Vsi so v skupini Default, a obstaja možnost ustvariti ločene skupine in vanje prenesti stroje, kot potrebujete. To ne vpliva na nič – le na logično predstavitev podatkov in njihovo skupino za lažje delo. Prvo in najpomembnejše, kar moramo storiti po tem, je zagnati proces migracije. To lahko storimo tako, da to prisilimo ročno, kot tudi tako, da nastavimo urnik, vključno z množično migracijo vseh strojev naenkrat.

Spominjam vas, da se je Hystax pozicioniral kot izdelek za migracijo. Zato ni nič presenetljivega, da za zagon naših repliciranih strojev potrebujemo ustvariti DR-naključek. Načrt lahko pripravimo za stroje, ki so že v stanju Synced. Generirati ga je mogoče za eno konkretno VM ali pa za vse stroje naenkrat.

Nabor parametrov pri generiranju DR-naključka se bo razlikoval glede na infrastrukturo, v katero boste migrirali. Za VMware okolje je na voljo minimalen nabor parametrov. Prav tako Re-IP za stroje ni podprt. V tem načrtu nas zanimajo naslednje točke: v opisu VM parameter „subnet“: „VMNetwork“, kjer povezujemo VM s konkretno mrežo v klasterju. Rank – je pomemben pri migraciji več VM, določa vrstni red njihovega zagona. Flavor – opisuje konfiguracijo VM, v tem primeru – 1CPU, 2GB RAM. V razdelku subnets določimo, da je „subnet“: „VMNetwork“ povezan s mrežo „VM Network“ VMware. 

Pri ustvarjanju DR-naključka ni možnosti, da bi „razdelili“ diske po različnih datastorih. Nahajali se bodo na istem datastoru, ki je bil določen za to odjemalsko oblačno okolje, in če imate diske različnih razredov, lahko to povzroči nekaj težav pri zagonu stroja, po zagonu in „odtrganju“ VM od Hystax pa bo potrebna še ločena migracija diskov na ustrezne datastore. Potem nam ostane le še zagnati naš DR-naključek in počakati, da se naši stroji dvignejo. Proces konverzije P2V/V2V prav tako traja čas. Na mojem največjem testnem stroju s 100GB in tremi diski je to trajalo največ 10 minut.

Po tem je potrebno preveriti zagnano VM, storitve na njej, doslednost podatkov in izvesti druge preglede. 

Nato imamo dve poti: 

1. Удалить – выключить запущенный DR-план. Это действие просто погасит запущенную виртуальную машину. Данные реплики сохранятся. 
2. Оторвать – разъединить реплицированную машину от Acura, то есть фактически завершить процесс миграции. 

Преимущества решения: 

• простота установки и настройки как со стороны клиента, так и со стороны провайдера; 
• интуитивно понятная настройка миграции, создание DR-плана и запуск реплик;
• поддержка и разработчики достаточно оперативно реагируют на обнаруженные проблемы и устраняют их с помощью обновлений платформы или агентов. 

Недостатки 

• Недостаточная поддержка VMware.
• Отсутствие квотирования для тенантов со стороны платформы. 

Также я подготовил запрос на функционал, который мы передали вендору:

1. мониторинг использования и развертывание из панели управления Acura для Cloud-агентов;
2. наличие квот для тенантов; 
3. возможность ограничения количества одновременных репликаций и скорости для каждого тенанта; 
4. поддержка VMware vCloud Director; 
5. поддержка ресурсных пулов (это было реализовано во время тестирования);
6. возможность настройки VMware-агента со стороны самого агента, без ввода учётных данных клиентской инфраструктуры в панели Acura;
7.  «визуализация» процесса запуска виртуальной машины при активации DR-плана. 

Единственное, что меня сильно смутило – это документация. Я не люблю «чёрные коробки» и предпочитаю, чтобы была подробная документация о внутреннем устройстве продукта. Если для AWS и OpenStack продукт описан более-менее, то для VMware документации крайне мало. 

Есть руководство по установке, которое описывает только развертывание панели Acura, без упоминания о необходимости наличия Cloud-агента. Предоставлен полный набор спецификаций по продукту, что хорошо. Существует документация, описывающая настройку «от начала до конца» на примере AWS и OpenStack (хотя она больше напоминает пост в блоге), а также довольно ограниченная база знаний. 

В целом, это не совсем тот формат документации, к которому я привык, скажем, у более крупных вендоров, поэтому мне было не совсем комфортно. При этом на некоторые нюансы работы системы «внутри» я так и не нашёл ответов в этой документации – очень много вопросов приходилось уточнять у технической поддержки, что значительно затягивало процесс развертывания стенда и проведения тестирования. 

Povzemimo, lahko rečem, da mi je na splošno izdelek in pristop podjetja k izvedbi naloge zelo všeč. Da, obstajajo pomanjkljivosti, resnično kritična pomanjkljivost funkcionalnosti (v povezavi z VMware). Očitno je, da se podjetje predvsem osredotoča na javne oblake, zlasti na AWS, in za nekatere bo to dovolj. Razpoložljivost takega preprostega in uporabniku prijaznega izdelka danes, ko se mnoge podjetja odločajo za multi-cloud strategijo, je izjemno pomembna. Ob upoštevanju občutno nižje cene v primerjavi s konkurenco, to naredi izdelek zelo privlačen.

V našem timu iščemo vodilnega inženirja sistemov za spremljanje. Morda ste to prav vi?

Izvor: habr.com