Unul dintre tinerii jucători de pe piața soluțiilor de recuperare în caz de dezastru este Hystax, un startup rus în 2016. Întrucât subiectul recuperării în caz de dezastru este foarte popular și piața este extrem de competitivă, startup-ul a decis să se concentreze pe migrarea între diferite infrastructuri cloud. Un produs care vă permite să organizați o migrare simplă și rapidă în cloud ar fi foarte util pentru clienții Onlanta - utilizatori . Așa am ajuns să cunosc Hystax și am început să-i testez caracteristicile. Și ce a rezultat, voi spune în acest articol.
Principala caracteristică a Hystax este funcționalitatea sa largă de a susține diverse platforme de virtualizare, sisteme de operare invitate și servicii cloud, ceea ce face posibilă mutarea sarcinilor de lucru de oriunde și oriunde.
Acest lucru vă permite să creați nu numai soluții DR pentru a îmbunătăți toleranța la erori a serviciilor, ci și să migrați rapid și flexibil resursele între diferite site-uri și hyperscalere pentru a crește economiile de costuri și pentru a selecta cea mai bună soluție pentru un anumit serviciu în acest moment. Pe lângă platformele enumerate în imaginea de titlu, compania cooperează activ și cu furnizorii ruși de cloud: Yandex.Cloud, CROC Cloud Services, Mail.ru și mulți alții. De asemenea, este de remarcat faptul că în 2020 compania a deschis un centru de cercetare și dezvoltare situat în Skolkovo.
Alegerea unei singure soluții de către un număr mare de jucători de pe piață indică o bună politică de prețuri și o aplicabilitate ridicată a produsului, pe care am decis să-l testăm în practică.
Deci, sarcina noastră de testare va consta în migrarea de pe site-ul meu de testare VMware și mașinile fizice pe site-ul furnizorului care rulează și VMware. Da, există multe soluții care pot implementa o astfel de migrare, dar considerăm Hystax ca un instrument universal, iar testarea migrării în toate combinațiile posibile este pur și simplu o sarcină nerealistă. Da, iar cloud-ul Oncloud.ru este construit special pe VMware, așa că această platformă, ca țintă, ne interesează într-o măsură mai mare. În continuare, voi descrie principiul de bază de funcționare, care în ansamblu nu depinde de platformă, iar VMware poate fi înlocuit din orice parte cu o platformă de la alt furnizor.
Primul pas este instalarea Hystax Acura, care este panoul de control al sistemului.
Se extinde din șablon. Din anumite motive, în cazul nostru, nu a fost în întregime corect și în loc de 8CPU recomandat, 16Gb au fost implementați cu jumătate din resurse. Prin urmare, trebuie să vă amintiți să le schimbați, altfel infrastructura din interiorul VM, pe care este construit totul, pur și simplu nu va începe cu containere, iar portalul va fi indisponibil. ÎN resursele necesare sunt descrise în detaliu, precum și porturile pentru toate componentele sistemului.
Și au existat și dificultăți în setarea adresei IP prin șablon, așa că am schimbat-o din consolă. După aceea, puteți accesa interfața web de administrare și puteți finaliza vrăjitorul de configurare inițială.
Punct final - IP sau FQDN al vCenter-ului nostru.
Autentificare și parolă - este clar aici.
Numele de gazdă ESXi țintă este una dintre gazdele din clusterul nostru la care va fi replicat.
Depozitul de date țintă este unul dintre depozitele de date ale clusterului nostru la care va fi efectuată replicarea.
Hystax Acura Control Panel Public IP - adresa la care va fi disponibil panoul de control.
Este necesară o mică clarificare cu privire la gazdă și depozitul de date. Faptul este că replicarea Hystax funcționează la nivel de gazdă și de depozit de date. În continuare, vă voi spune cum puteți schimba gazda și depozitul de date pentru chiriaș, dar problema este alta. Hystax nu acceptă punerea în comun a resurselor, de exemplu. replica se va întâmpla întotdeauna la rădăcina clusterului (la momentul scrierii acestui material, băieții de la Hystax au lansat o versiune actualizată, în care au implementat rapid solicitarea mea de caracteristică privind suportul pentru pool-urile de resurse). De asemenea, vCloud Director nu este acceptat, de exemplu. dacă, la fel ca în cazul meu, chiriașul nu are drepturi de admin asupra întregului cluster, ci doar asupra unui anumit pool de resurse și am dat acces la Hystax, atunci va putea replica și rula independent aceste VM-uri, dar el nu le va putea vedea în infrastructura VMware, la care are acces și, în consecință, să gestioneze în continuare mașinile virtuale. Administratorul clusterului trebuie să mute VM-ul în pool-ul de resurse corect sau să îl importe în vCloud Director.
De ce mă concentrez atât de mult pe aceste momente? Pentru că, din câte înțeleg conceptul de produs, clientul ar trebui să poată implementa în mod independent orice migrare sau DR folosind panoul Acura. Dar, până acum, suportul VMware este ușor în urmă față de nivelul de suport pentru același OpenStack, unde astfel de mecanisme au fost deja implementate.
Dar să revenim la desfășurare. În primul rând, după configurarea inițială a panoului, trebuie să creăm primul chiriaș în sistemul nostru.
Toate câmpurile de aici sunt clare, vă voi spune doar despre câmpul Cloud. Avem deja un nor „implicit” pe care l-am creat în timpul configurării inițiale. Dar dacă dorim să putem pune fiecare chiriaș în propriul său depozit de date și în propriul pool de resurse, putem implementa acest lucru prin crearea de cloud-uri separate pentru fiecare dintre clienții noștri.
Sub forma adăugării unui nou cloud, specificăm aceiași parametri ca în timpul configurării inițiale (putem folosi chiar aceeași gazdă), specificăm depozitul de date necesar pentru un anumit client, iar acum în parametrii suplimentari putem specifica deja individual resursa pool necesară {"resource_pool" :"YOUR_POOL_NAME"}
După cum probabil ați observat, sub forma creării unui chiriaș nu există nimic despre alocarea de resurse sau un fel de cote - nu există nimic din acest lucru în sistem. Nu puteți limita locatarul în numărul de replici simultane, numărul de mașini pentru replicare sau prin orice alți parametri. Așadar, am creat primul chiriaș. Acum există un lucru nu în întregime logic, dar obligatoriu - instalarea unui agent Cloud. Este ilogic, deoarece agentul este descărcat pe pagina unui anumit client.
În același timp, nu este legat de chiriașul creat și toți clienții noștri vor lucra prin el (sau după mai multe, dacă îi vom implementa). Un agent acceptă 10 sesiuni simultane. O sesiune contează ca o mașină. Nu contează câte discuri are. Până în prezent, nu există un mecanism de scalare a agenților în Acura în sine pentru VMware. Mai este un moment neplăcut - nu putem să ne uităm la „utilizarea” acestui agent din panoul Acura pentru a concluziona dacă trebuie să desfășurăm mai mult sau instalația actuală este suficientă. Ca urmare, standul arată astfel:
Următorul pas pentru a accesa portalul clienților noștri este crearea unui cont (și mai întâi, de asemenea, un rol care va fi aplicat acestui utilizator).
Acum clientul nostru poate folosi portalul independent. Tot ce trebuie să facă este să descarce agenți de pe portal și să-i instaleze de partea lui. Există trei tipuri de agenți: Linux, Windows și VMware.
Primele două sunt puse pe fizică sau pe mașini virtuale pe orice hypervisor non-VMware. Nu este necesară nicio configurație suplimentară aici, agentul descarcă și știe deja unde să bată, iar literalmente într-un minut mașina va fi vizibilă în panoul Acura. Cu agentul VMware, situația este puțin mai complicată. Problema este că Agentul pentru VMware este descărcat și de pe portalul deja pregătit și având configurația necesară. Dar agentul VMware, pe lângă faptul că știe despre portalul nostru Acura, trebuie să știe și despre sistemul de virtualizare pe care va fi implementat.
De fapt, sistemul ne va cere să specificăm aceste date atunci când descarcăm agentul VMware pentru prima dată. Problema este că, în epoca noastră de dragoste universală pentru securitate, nu toată lumea va dori să-și indice parola de administrator pe portalul altcuiva, ceea ce este destul de înțeles. Din interior, după implementare, agentul nu poate fi configurat în niciun fel (puteți modifica doar setările de rețea). Aici prevăd dificultăți cu clienții deosebit de precauți.
Deci, după instalarea agenților, ne putem întoarce la panoul Acura și vedem toate mașinile noastre.
Deoarece lucrez cu sistemul de mai bine de o zi, am mașini în diverse stări. Toate sunt în grupul implicit, dar este posibil să creați grupuri separate și să transferați mașini către ele, după cum aveți nevoie. Acest lucru nu afectează nimic - doar reprezentarea logică a datelor și gruparea lor pentru o muncă mai convenabilă. Primul și cel mai important lucru pe care trebuie să-l facem după aceea este să începem procesul de migrare. Putem face acest lucru atât manual forțat, cât și configura un program, inclusiv în vrac pentru toate mașinile simultan.
Permiteți-mi să vă reamintesc că Hystax a fost poziționat ca produs pentru migrare. Prin urmare, nu este surprinzător că, pentru a rula mașinile noastre replicate, trebuie să creăm un plan DR. Puteți crea un plan pentru mașinile care sunt deja în starea Sincronizată. Puteți genera atât pentru o anumită VM, cât și pentru toate mașinile simultan.
Setul de parametri la generarea unui plan DR va diferi în funcție de infrastructura către care veți migra. Un set minim de opțiuni este disponibil pentru un mediu VMware. Re-IP pentru mașini nu este, de asemenea, acceptat. În acest sens, ne interesează următoarele puncte: în descrierea VM-ului, parametrul „subrețea”: „VMNetwork”, unde legăm VM-ul la o anumită rețea din cluster. Rank - relevant la migrarea mai multor VM, determină ordinea în care sunt lansate. Flavour descrie configurația VM, în acest caz 1CPU, 2GB RAM. În secțiunea subrețele, definim acea „subrețea”: „VMNetwork” este asociată cu „VM Network” a VMware.
Când creați un plan DR, nu există nicio modalitate de a „împărți” discurile în diferite depozite de date. Acestea vor fi localizate pe același depozit de date 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ă pornirea și „separarea” VM de Hystax, va fi, de asemenea, necesită un disc de migrare separat la depozitele de date necesare. Apoi trebuie doar să rulăm planul nostru DR și să așteptăm ca mașinile noastre să se ridice. Procesul de conversie P2V/V2V necesită, de asemenea, timp. Pe cea mai mare mașină de testare de 100 GB cu trei discuri, acest lucru a durat maximum 10 minute.
După aceea, ar trebui să verificați VM-ul care rulează, serviciile pe acesta, consistența datelor și alte verificări.
Avem apoi două opțiuni:
- Ștergere - ștergeți un plan DR în derulare. Această acțiune va închide pur și simplu VM-ul care rulează. Aceste replici nu merg nicăieri.
- Detașați - rupeți mașina replicată de la Acura, i.e. finaliza efectiv procesul de migrare.
Avantajele soluției:
- ușurință de instalare și configurare atât pe partea clientului, cât și pe partea furnizorului;
- ușurința de a configura migrarea, crearea unui plan DR și lansarea de replici;
- asistența și dezvoltatorii răspund destul de repede la problemele găsite și le rezolvă cu actualizări de platformă sau de agent.
Contra
- Suport insuficient pentru Vmware.
- Absența oricărei cote pentru chiriași de pe platformă.
De asemenea, am făcut o cerere de caracteristici, pe care am predat-o vânzătorului:
- monitorizarea utilizării și implementarea din Consola de management Acura pentru agenții cloud;
- disponibilitatea cotelor pentru chiriași;
- capacitatea de a limita numărul de replicări simultane și viteza pentru fiecare chiriaș;
- suport pentru VMware vCloud Director;
- suport pentru pool-uri de resurse (a fost implementat în timpul testării);
- capacitatea de a configura agentul VMware din partea agentului însuși, fără a introduce acreditările din infrastructura clientului în panoul Acura;
- „Vizualizarea” procesului de pornire a unui VM la pornirea unui plan DR.
Singurul lucru care mi-a provocat mari plângeri a fost documentația. Nu prea îmi plac „cutiile negre” și prefer când există o documentație detaliată despre cum funcționează produsul în interior. Și dacă pentru AWS și OpenStack produsul este descris și mai mult sau mai puțin, atunci pentru VMware există foarte puțină documentație.
Există un Ghid de instalare care descrie doar desfășurarea panoului Acura și unde nu există niciun cuvânt despre necesitatea unui agent Cloud. Există un set complet de specificații pentru produs, ceea ce este bun. Există documentație care descrie configurarea „de la și către” folosind AWS și OpenStack ca exemplu (deși îmi amintește mai mult de o postare pe blog) și există o bază de cunoștințe foarte mică.
În general, acesta nu este formatul de documentație cu care sunt obișnuit, să zicem, de la furnizori mai mari, așa că nu m-am simțit pe deplin confortabil. În același timp, nu am găsit răspunsuri cu privire la unele dintre nuanțe ale funcționării sistemului „în interior” în această documentație - a trebuit să clarific o mulțime de întrebări cu suport tehnic, iar acest lucru a trage mai degrabă procesul de desfășurare a standului și testarea.
Rezumând, pot spune că în general mi-a plăcut produsul și abordarea companiei în implementarea sarcinii. Da, există defecte, există o lipsă foarte critică de funcționalitate (împreună cu VMware). Se poate observa că, în primul rând, compania se concentrează în continuare pe cloud-urile publice, în special pe AWS, iar pentru unii acest lucru va fi suficient. A avea un 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 față de concurenți, acest lucru face ca produsul să fie extrem de atractiv.
Căutăm o echipă . Poate tu esti?
Sursa: www.habr.com