Unul dintre jucătorii tineri de pe piața soluțiilor de recuperare în caz de dezastru este compania Hystax – o start-up rusă din 2016. Deoarece tema recuperării în caz de dezastru este foarte populară și piața este extrem de competitivă, start-up-ul a decis să se concentreze pe migrarea între diferite infrastructuri cloud. Un produs care permite organizarea unei migrații simple și rapide în cloud ar fi foarte util și pentru clienții companiei «Onlanta» — utilizatorii. . Așa am ajuns să cunosc Hystax și am început să-i testez capabilitățile. Ce a ieșit din asta, voi povesti în acest articol.
Principala caracteristică a Hystax este funcționalitatea sa extinsă în suportul diferitelor platforme de virtualizare, sisteme de operare gazdă și servicii cloud, ceea ce permite mutarea sarcinilor de lucru de oriunde și către oriunde.
Aceasta permite crearea nu doar de soluții DR pentru creșterea disponibilității serviciilor, ci și migrarea rapidă și flexibilă a resurselor între diferite locații și hyperscaleri pentru maximizarea economiilor și alegerea celei mai bune soluții pentru un serviciu specific în acel moment. Pe lângă platformele enumerate în imaginea de titlu, compania colaborează activ și cu furnizorii ruși de cloud: Yandex.Cloud, KROK «Servicii Cloud», Mail.ru și mulți alții. De asemenea, merită menționat că în 2020 compania a deschis un centru R&D situat în Skolkovo.
Alegerea unei singure soluții de către un număr mare de jucători pe piață vorbește despre o politică de prețuri bună și o aplicabilitate ridicată a produsului, ceea ce am decis să verificăm în practică.
Deci, sarcina noastră de testare va consta în migrarea de pe platforma mea de testare VMware și mașini fizice pe platforma furnizorului, de asemenea sub gestionarea VMware. Da, există multe soluții care pot efectua o astfel de migrare, dar noi considerăm Hystax ca un instrument universal, iar testarea migrației în toate combinațiile posibile este pur și simplu o sarcină nerealistă. De asemenea, cloud-ul Oncloud.ru este construit pe VMware, așa că această platformă ne interesează mai mult ca țintă. În continuare, voi descrie principiul de funcționare principal, care, în general, nu depinde de platformă, și VMware poate fi înlocuită cu ușurință cu platforma unui alt furnizor.
În prima etapă, trebuie să desfășurăm Hystax Acura, care este panoul de control al sistemului.
Aceasta se desfășoară dintr-un șablon. Din anumite motive, în cazul nostru, acesta nu a fost complet corect și, în loc de cele recomandate 8CPU, 16Gb, s-a desfășurat cu resurse de două ori mai mici. Prin urmare, trebuie să nu uităm să le schimbăm, altfel containerele infrastructurii din interiorul VM-ului, pe care se bazează totul, pur și simplu nu se vor lansa și portalul va fi inaccesibil. În sunt detaliate resursele necesare, precum și porturile pentru toate componentele sistemului.
Și cu atribuirea adresei IP prin șablon au apărut și dificultăți, așa că am schimbat-o din consolă. După aceasta, putem să accesăm interfața web a adminului și să completăm asistentul inițial de configurare.
Endpoint – IP sau FQDN-ul vCenter-ului nostru.
Login și Password – aici este clar.
Hostname ESXi țintă – unul dintre gazdele din clusterul nostru, pe care se va face replicarea.
Datastore țintă – unul dintre datastore-urile din clusterul nostru, pe care se va face replicarea.
IP Public Hystax Acura Control Panel – adresa prin care va fi accesibil panoul de control.
Este necesară o mică clarificare privind gazda și datastore-ul. Problema este că replicarea Hystax funcționează la nivel de gazdă și datastore. Voi explica în continuare cum poate să schimbe gazda și datastore-ul pentru tenant, dar problema este alta. Hystax nu suportă funcționarea cu grupuri de resurse, adică replicarea va avea loc întotdeauna în rădăcina clusterului (în timpul redactării acestui material, echipa Hystax a lansat o versiune actualizată, unde au implementat rapid cererea mea de funcționalitate privind suportul pentru grupurile de resurse). De asemenea, vCloud Director nu este suportat, adică, dacă, așa cum este cazul meu, tenantul nu are drepturi administrative asupra întregului cluster, ci doar asupra unui grup specific de resurse și i-am acordat acces la Hystax, va putea să replicate și să lanseze aceste VM-uri, dar nu le va putea vedea în infrastructura VMware la care are acces și, prin urmare, nu va putea să gestioneze în continuare mașinile virtuale. Este necesar ca administratorul clusterului să mute VM-ul în grupul de resurse dorit sau să-l importe în vCloud Director.
De ce îmi accentuez atât de mult atenția asupra acestor aspecte? Pentru că, din câte îmi dau seama, conceptul de produs preconizează că clientul ar trebui să aibă posibilitatea de a efectua orice migrare sau DR prin intermediul panoului Acura. Dar până acum, suportul pentru VMware este puțin în urma suportului pentru OpenStack, unde astfel de mecanisme sunt deja implementate.
Dar să ne întoarcem la desfășurarea proiectului. Primul lucru pe care trebuie să-l facem, după configurația inițială a panoului, este să creăm primul tenant în sistemul nostru.
Toate câmpurile sunt clare aici, dar voi vorbi doar despre câmpul Cloud. Avem deja un «cloud» implicit, pe care l-am creat în timpul inițializării. Dar dacă dorim să avem posibilitatea de a plasa fiecare tenant pe propriul său datastor și în propriul pool de resurse, putem realiza acest lucru prin crearea de cloud-uri separate pentru fiecare dintre clienții noștri.
În formularul de adăugare a unui nou cloud, specificăm aceleași parametrii ca și în configurarea inițială (putem folosi chiar același host), indicăm datastorul necesar pentru clientul specific, iar acum, în parametrii suplimentari, putem specifica individual pool-ul de resurse necesar {«resource_pool»: «YOUR_POOL_NAME»}.
După cum ați observat, în formularul de creare a tenantului nu există nimic despre alocarea resurselor sau despre anumite cote – nimic din toate acestea nu există în sistem. Nu putem restricționa tenantul în ceea ce privește numărul de replici simultane, numărul de mașini pentru replicare sau alte parametrii. Astfel, am creat primul tenant. Acum există ceva nu tocmai logic, dar obligatoriu – instalarea agentului Cloud. Este ilogică, deoarece agentul este descărcat de pe pagina clientului specific.
În același timp, nu se leagă de tenantul creat, iar prin el vor opera toți clienții noștri (sau prin câțiva, dacă îi desfășurăm). Un agent suportă 10 sesiuni simultane. O sesiune este considerată o mașină. Nu contează câte discuri are aceasta. În prezent, nu există un mecanism pentru scalarea agenților în Acura sub VMware. Există și un alt aspect neplăcut – nu avem posibilitatea din panoul Acura să vedem „utilizarea” acestui agent pentru a concluziona dacă trebuie să desfășurăm unul suplimentar sau dacă instalația curentă este suficientă. În final, standul arată astfel:
Următorul pas pentru a accesa portalul clientului nostru este să creăm un cont (dar mai întâi încă și un rol care va fi aplicat acestui utilizator).
Acum clientul nostru poate utiliza portalul în mod autonom. Tot ce trebuie să facă este să descarce agenții de pe portal și să îi instaleze de cealaltă parte. Există trei tipuri de agenți: Linux, Windows și VMware.
Primele două se instalează pe hardware sau pe mașini virtuale pe orice hypervisor, în afară de VMware. Aici nu este necesar să configurăm nimic suplimentar, agentul se descarcă și știe deja unde trebuie să sune, și în mai puțin de un minut, mașina va fi vizibilă în panoul Acura. Situația cu agentul VMware este puțin mai complicată. Problema este că agentul pentru VMware se descarcă de pe portal deja pregătit și având în sine configurația necesară. Dar agentului VMware, pe lângă a cunoaște despre portalul nostru Acura, îi este necesar să știe și despre sistemul de virtualizare pe care va fi desfășurat.
Aceste date sunt cele pe care sistemul ne va cere să le introducem la prima descărcare a agentului VMware. Problema este că, în epoca noastră de iubire universală pentru securitate, nu toată lumea va dori să introducă parola de administrator pe un portal străin, ceea ce este perfect de înțeles. După desfășurare, agentul nu poate fi configurat în niciun mod (poate fi schimbată doar configurația sa de rețea). Aici prevăd dificultăți cu clienții foarte precauți.
Așadar, după instalarea agenților, ne putem întoarce în panoul Acura și vedem toate mașinile noastre.
Deoarece lucrez cu sistemul de mai multe zile, am mașini în diverse stări. Toate acestea se află în grupul Default, dar există posibilitatea de a crea grupuri separate și de a muta mașinile în acestea, așa cum este necesar. Acest lucru nu influențează nimic – este doar o prezentare logică a datelor și gruparea lor pentru o muncă mai convenabilă. Prima și cea mai importantă acțiune pe care trebuie să o facem după aceasta este să demarăm procesul de migrație. Putem face aceasta fie manual, forțat, fie putem configura un program, inclusiv în masă pentru toate mașinile deodată.
Amintesc că Hystax s-a poziționat ca un produs pentru migrarea datelor. Prin urmare, nu este nimic surprinzător în faptul că, pentru a porni mașinile noastre replicate, trebuie să creăm un plan DR. Planul poate fi realizat pentru mașinile care sunt deja în starea Synced. Este posibil să generăm fie pentru o VM anume, fie pentru toate mașinile deodată.
Setul de parametri la generarea planului DR va varia în funcție de infrastructura în care veți migra. Pentru medii VMware este disponibil un set minim de parametri. De asemenea, Re-IP nu este suportat pentru mașini. În acest plan, ne interesează următoarele aspecte: în descrierea VM, parametrul „subnet”: „VMNetwork”, unde asociem VM cu o rețea specifică din cluster. Rank – este relevant atunci când migrați mai multe VM, determinând ordinea de pornire a acestora. Flavor – descrie configurația VM, în acest caz – 1CPU, 2GB RAM. În secțiunea subnets, definim că „subnet”: „VMNetwork” este asociat cu rețeaua „VM Network” VMware.
La crearea planului DR, nu există posibilitatea de a „distribui” discul între diferite datastoruri. Acestea vor rămâne pe același datastore care a fost definit pentru acest cloud client, iar dacă aveți discuri de clase diferite, acest lucru poate cauza unele dificultăți la pornirea mașinii, iar după lansare și „deconectarea” VM-ului de Hystax, va necesita și o migrație separată a discurilor către datastorurile dorite. Tot ce ne mai rămâne este să demarăm planul nostru DR și să așteptăm să se pornească mașinile noastre. Procesul de conversie P2V/V2V durează, de asemenea, timp. La cea mai mare mașină de test a mea de 100Gb cu trei discuri, acest lucru a durat maximum 10 minute.
După aceasta, trebuie să verificăm VM-ul pornit, serviciile sale, consistența datelor și să efectuați alte verificări.
Mai departe, avem două opțiuni:
- Șterge – anulează planul DR activ. Această acțiune va opri pur și simplu VM-ul activat. Datele replicii nu vor fi pierdute.
- Dezattach – decuplează mașina replicată de Acura, adică finalizează efectiv procesul de migrare.
Avantajele soluției:
- ușurința de instalare și configurare atât din partea clientului, cât și din partea furnizorului;
- ușurința de configurare a migrației, crearea unui plan DR și lansarea replicilor;
- asistența și dezvoltatorii reacționează rapid la problemele întâmpinate și le rezolvă prin actualizări ale platformei sau agenților.
Dezavantaje
- Asistență insuficientă pentru VMware.
- Lipsa oricăror cotele pentru chiriași din partea platformei.
De asemenea, am redactat o cerere de funcționalitate pe care am transmis-o furnizorului:
- monitorizarea utilizării și implementarea din consola de control Acura pentru agenții Cloud;
- existenta cotelor pentru chiriași;
- posibilitatea de a limita numărul de replicări simultane și viteza pentru fiecare chiriaș;
- susținerea VMware vCloud Director;
- susținerea grupurilor de resurse (a fost implementată în timpul testării);
- posibilitatea de a configura agentul VMware din partea agentului în sine, fără a introduce acreditivele infrastructurii clientului în panoul Acura;
- „vizualizarea” procesului de pornire a VM-ului în momentul activării planului DR.
Singurul lucru care mi-a ridicat multe obiecții a fost documentația. Nu îmi plac prea mult „cutiile negre” și prefer să existe o documentație detaliată despre cum funcționează produsul la interior. Iar dacă pentru AWS și OpenStack produsul este descris relativ bine, pentru VMware documentația este extrem de puțină.
Există un Ghid de Instalare care descrie doar implementarea panoului Acura, în care nu se menționează niciun cuvânt despre faptul că este necesar și un agent Cloud. Există un set complet de specificații pentru produs, ceea ce este bine. Există documentația care descrie configurarea „de la A la Z” folosind exemple din AWS și OpenStack (deși îmi amintește mai mult de un articol de blog), și există o baze de cunoștințe foarte mică.
În general, acesta nu este formatul de documentație la care sunt obișnuit, să spunem, de la furnizorii mai mari, așa că nu mi-a fost prea confortabil. În același timp, răspunsurile la unele nuanțe ale funcționării sistemului „în interior” nu le-am găsit în această documentație - a trebuit să clarific foarte multe întrebări cu suportul tehnic, ceea ce a întârziat semnificativ procesul de implementare a standului și testare.
În concluzie, pot spune că, în general, produsul și abordarea companiei pentru realizarea sarcinii mi-au plăcut. Da, există lipsuri, iar funcționalitatea este într-adevăr insuficientă (în combinație cu VMware). Se vede că, în primul rând, compania se concentrează pe cloud-urile publice, în special AWS, și pentru unii acest lucru va fi suficient. Existența unui produs atât de simplu și convenabil astăzi, când multe companii aleg o strategie multi-cloud, este extrem de importantă. Având în vedere prețul mult mai mic comparativ cu concurenții, acesta face produsul extrem de atractiv.
Căutăm în echipa noastră . Poate că exact tu ești persoana căutată?
Sursa: habr.com
