Un dels joves jugadors del mercat de solucions de recuperació de desastres és Hystax, una startup russa del 2016. Com que el tema de la recuperació de desastres és molt popular i el mercat és extremadament competitiu, la startup va decidir centrar-se en la migració entre diferents infraestructures de núvol. Un producte que permeti organitzar una migració senzilla i ràpida al núvol també seria molt útil per als clients d'Onlanta - usuaris. . Així va ser com em vaig familiaritzar amb Hystax i vaig començar a provar les seves capacitats. Us explicaré què en va sortir en aquest article.
La característica principal d'Hystax és la seva àmplia funcionalitat per donar suport a diverses plataformes de virtualització, sistemes operatius convidats i serveis al núvol, que permet transferir les vostres càrregues de treball des de qualsevol lloc i des de qualsevol lloc.
Això us permet crear no només solucions de DR per augmentar la tolerància a errors dels serveis, sinó també migrar recursos de manera ràpida i flexible entre diferents llocs i hiperescaladors per augmentar l'estalvi de costos i seleccionar la millor solució per a un servei específic en un moment determinat. A més de les plataformes enumerades a la imatge del títol, l'empresa també coopera activament amb proveïdors de núvol russos: Yandex.Cloud, CROC Cloud Services, Mail.ru i molts altres. També val la pena assenyalar que l'any 2020 l'empresa va obrir un centre d'R+D situat a Skolkovo.
L'elecció d'una solució per part d'un gran nombre d'actors al mercat indica una bona política de preus i una alta aplicabilitat del producte, que vam decidir provar a la pràctica.
Per tant, la nostra tasca de prova consistirà en la migració del meu lloc de prova de VMware i les màquines físiques al lloc del proveïdor, també gestionat per VMware. Sí, hi ha moltes solucions que poden realitzar aquesta migració, però considerem Hystax com una eina universal i provar la migració en totes les combinacions possibles és simplement una tasca poc realista. I el núvol Oncloud.ru està construït específicament sobre VMware, de manera que aquesta plataforma com a objectiu ens interessa en major mesura. A continuació, descriuré el principi bàsic de funcionament, que generalment és independent de la plataforma, i VMware des de qualsevol costat es pot substituir per una plataforma d'un altre proveïdor.
El primer pas és desplegar Hystax Acura, que és el tauler de control del sistema.
Es desplega a partir de la plantilla. Per alguna raó, en el nostre cas no era del tot correcte i en comptes de la 8CPU recomanada, es van desplegar 16 Gb amb la meitat dels recursos. Per tant, cal recordar canviar-los, en cas contrari, la infraestructura de contenidors dins de la VM, sobre la qual està tot construït, simplement no s'iniciarà i el portal serà inaccessible. EN Els recursos necessaris es descriuen amb detall, així com els ports per a tots els components del sistema.
També hi va haver dificultats per configurar l'adreça IP mitjançant una plantilla, així que la vam canviar des de la consola. Després d'això, podeu anar a la interfície web d'administració i completar l'assistent de configuració inicial.
Punt final: IP o FQDN del nostre vCenter.
Inici de sessió i contrasenya: això està clar.
El nom d'amfitrió ESXi de destinació és un dels amfitrions del nostre clúster al qual es realitzarà la replicació.
El magatzem de dades de destinació és un dels magatzems de dades del nostre clúster al qual es realitzarà la replicació.
Hystax Acura Control Panel Public IP: l'adreça on el tauler de control estarà disponible.
Cal una mica d'aclariment sobre l'amfitrió i el magatzem de dades. El fet és que la replicació d'Hystax funciona a nivell d'amfitrió i magatzem de dades. A continuació, us explicaré com podeu canviar l'amfitrió i el magatzem de dades d'un inquilí, però el problema és diferent. Hystax no admet treballar amb agrupacions de recursos, és a dir. la rèplica sempre anirà a l'arrel del clúster (en el moment d'escriure aquest material, els nois d'Hystax van publicar una versió actualitzada, on van implementar ràpidament la meva sol·licitud de funcions pel que fa al suport per a grups de recursos). vCloud Director tampoc és compatible, és a dir. si, com en el meu cas, l'arrendatari no té drets d'administració de tot el clúster, sinó només d'un grup de recursos específic, i li donem accés a Hystax, llavors podrà replicar i llançar aquestes màquines virtuals de manera independent, però ho farà. no podrà veure'ls a la infraestructura de VMware, a la qual té accés i, en conseqüència, gestiona més les màquines virtuals. És necessari que l'administrador del clúster mogui la màquina virtual a l'agrupació de recursos desitjada o l'importi a vCloud Director.
Per què em concentro tant en aquests punts? Perquè, pel que entenc el concepte del producte, el client hauria de poder implementar de manera independent qualsevol migració o DR mitjançant el panell Acura. Però fins ara, el suport de VMware està lleugerament per darrere del nivell de suport per a OpenStack, on ja s'han implementat mecanismes similars.
Però tornem al desplegament. En primer lloc, després de la configuració inicial del panell, hem de crear el primer inquilí del nostre sistema.
Tots els camps aquí són clars, només us parlaré del camp Núvol. Ja tenim un núvol "per defecte" que vam crear durant la configuració inicial. Però si volem poder posar cada inquilí al seu propi magatzem de dades i al seu propi grup de recursos, ho podem implementar creant núvols separats per a cadascun dels nostres clients.
En el formulari per afegir un nou núvol, especifiquem els mateixos paràmetres que durant la configuració inicial (fins i tot podem utilitzar el mateix host), indiquem el magatzem de dades necessari per a un client concret i ara en paràmetres addicionals podem especificar individualment el recurs requerit pool {"resource_pool": "YOUR_POOL_NAME"}
Com haureu notat, en el formulari de creació de llogaters no hi ha res sobre l'assignació de recursos ni les quotes; no hi ha res d'això al sistema. És impossible limitar un inquilí en el nombre de rèpliques simultànies, el nombre de màquines per a la rèplica o per qualsevol altre paràmetre. Així doncs, hem creat el primer inquilí. Ara hi ha una cosa no del tot lògica, però obligatòria: instal·lar un agent de núvol. No és lògic, ja que l'agent es descarrega a la pàgina d'un client concret.
Al mateix temps, no està vinculat a l'arrendatari creat, i tots els nostres clients hi treballaran (o a través de diversos, si els despleguem). Un agent admet 10 sessions simultànies. Una màquina es compta com una sessió. No importa quants discs tingui. Fins ara, no hi ha cap mecanisme per escalar els agents a la mateixa Acura sota VMware. Hi ha un moment més desagradable: no tenim l'oportunitat de mirar l'"eliminació" d'aquest agent des del panell d'Acura per concloure si hem de desplegar més o si la instal·lació actual és suficient. Com a resultat, l'estand té aquest aspecte:
El següent pas per accedir al nostre portal de clients és crear un compte (i primer, un rol que s'aplicarà a aquest usuari).
Ara el nostre client pot utilitzar el portal de manera independent. Tot el que ha de fer és descarregar els agents del portal i instal·lar-lo al seu costat. Hi ha tres tipus d'agents: Linux, Windows i VMware.
Els dos primers s'instal·len a la física o a les màquines virtuals en qualsevol hipervisor que no sigui VMware. No cal configurar res addicional, l'agent està descarregat i ja sap on trucar, i literalment en un minut el cotxe serà visible al panell d'Acura. Amb l'agent VMware la situació és una mica més complicada. El problema és que l'agent per a VMware també es descarrega des del portal ja preparat i que conté la configuració necessària. Però, a més de conèixer el nostre portal Acura, un agent de VMware també ha de conèixer el sistema de virtualització en què es desplegarà.
De fet, el sistema ens demanarà que proporcionem aquestes dades quan baixem per primera vegada l'agent de VMware. El problema és que en la nostra era d'amor universal per la seguretat, no tothom voldrà indicar la seva contrasenya d'administrador al portal d'una altra persona, cosa que és força comprensible. Des de l'interior, després del desplegament, l'agent no es pot configurar de cap manera (només podeu canviar la seva configuració de xarxa). Aquí veig dificultats amb clients especialment prudents.
Així, després d'instal·lar els agents, podem tornar al panell d'Acura i veure tots els nostres cotxes.
Com que fa diversos dies que treballo amb el sistema, tinc cotxes en diferents estats. Els tinc tots al grup Predeterminat, però és possible crear grups separats i transferir-hi cotxes segons calgui. Això no afecta res, només una presentació lògica de les dades i la seva agrupació per a un treball més còmode. El primer i més important que hem de fer després d'això és iniciar el procés de migració. Ho podem fer manualment o configurant un calendari, inclòs a granel per a totes les màquines alhora.
Us recordo que Hystax es va posicionar com un producte per a la migració. Per tant, no és d'estranyar que per executar les nostres màquines replicades necessitem crear un pla de DR. El pla es pot fer per a màquines que ja es troben en l'estat sincronitzat. Podeu generar tant per a una màquina virtual específica com per a totes les màquines alhora.
El conjunt de paràmetres a l'hora de generar un pla de DR variarà en funció de la infraestructura a la qual migrareu. Hi ha disponible un conjunt mínim de paràmetres per a l'entorn VMware. Re-IP per a màquines tampoc és compatible. En aquest sentit, ens interessen els següents punts: a la descripció de la VM, el paràmetre “subxarxa”: “VMNetwork”, on enllacem la VM a una xarxa específica del clúster. Classificació: rellevant quan es migren diverses màquines virtuals; determina l'ordre en què s'inicien. Flavor: descriu la configuració de la màquina virtual, en aquest cas: 1 CPU, 2 GB de RAM. A la secció de subxarxes definim aquesta "subxarxa": "VMNetwork" s'associa a la "Xarxa VM" de VMware.
Quan es crea un pla de DR, no hi ha manera de "difondre" els discos entre diferents magatzems de dades. Estaran ubicats al mateix magatzem de dades que es va definir per a aquest núvol de client, i si teniu discs de diferents classes, això pot provocar algunes dificultats a l'hora d'iniciar la màquina, i després d'iniciar i “separar” la VM d'Hystax, també ho farà. requereixen discs de migració separats als magatzems de dades requerits. Aleshores, tot el que hem de fer és llançar el nostre pla DR i esperar que els nostres cotxes pugin. El procés de conversió P2V/V2V també requereix temps. A la meva màquina de prova més gran, 100 GB amb tres discs, va trigar un màxim de 10 minuts.
Després d'això, hauríeu de comprovar la màquina virtual en execució, els serveis que hi ha, la coherència de les dades i fer altres comprovacions.
Aleshores tenim dues maneres:
- Suprimeix: suprimiu el pla DR en execució. Aquesta acció simplement tancarà la màquina virtual en execució. Aquestes rèpliques no van enlloc.
- Separar: arrenca un cotxe replicat d'un Acura, és a dir. completar realment el procés de migració.
Avantatges de la solució:
- facilitat d'instal·lació i configuració tant des del client com del proveïdor;
- facilitat per configurar la migració, crear un pla de DR i llançar rèpliques;
- El suport i els desenvolupadors responen amb força rapidesa als problemes trobats i els solucionen mitjançant actualitzacions de la plataforma o de l'agent.
Contres
- Suport insuficient de Vmware.
- Absència de quotes per als llogaters de la plataforma.
També vaig compilar una sol·licitud de funcions, que vam enviar al venedor:
- supervisió i desplegament de l'ús des de la consola de gestió d'Acura per als agents del núvol;
- disponibilitat de quotes per als llogaters;
- la capacitat de limitar el nombre de rèpliques simultànies i la velocitat per a cada inquilí;
- Suport de VMware vCloud Director;
- suport per a grups de recursos (implementat durant les proves);
- la possibilitat de configurar l'agent VMware des del mateix agent, sense introduir credencials de la infraestructura del client al panell d'Acura;
- "visualització" del procés d'inici de la màquina virtual quan s'executa el pla de DR.
L'únic que em va causar grans crítiques va ser la documentació. No m'agraden gaire les "caixes negres" i prefereixo quan hi hagi documentació detallada sobre com funciona el producte a l'interior. I si per a AWS i OpenStack el producte es descriu encara més o menys, per a VMware hi ha molt poca documentació.
Hi ha una guia d'instal·lació que només descriu el desplegament del panell Acura, i no hi ha ni una paraula sobre el fet que també es necessita un agent de núvol. Hi ha un conjunt complet d'especificacions del producte, que és bo. Hi ha documentació que descriu la configuració "de principi a fi" utilitzant AWS i OpenStack com a exemple (tot i que em sembla més a una publicació de bloc) i hi ha una base de coneixement molt petita.
En general, aquest no és el format de documentació al qual estic acostumat, per exemple, dels venedors més grans, així que no em vaig sentir del tot còmode. Al mateix temps, mai no he trobat respostes sobre alguns dels matisos de com funciona el sistema "per dins" en aquesta documentació; s'havien d'aclarir moltes preguntes amb el suport tècnic, i això va retardar bastant el procés de desplegament de l'estand i realització. provant.
En resum, puc dir que en general m'ha agradat el producte i l'enfocament de l'empresa a la tasca. Sí, hi ha deficiències, hi ha una manca de funcionalitat realment crítica (en relació amb VMware). És evident que, en primer lloc, l'empresa segueix centrada en els núvols públics, en particular en AWS, i per a alguns n'hi haurà prou. Tenir un producte tan senzill i còmode avui, quan moltes empreses trien una estratègia multinúvol, és extremadament important. Tenint en compte el preu molt més baix en comparació amb els competidors, això fa que el producte sigui extremadament atractiu.
Busquem un membre de l'equip . Potser ets tu?
Font: www.habr.com