Un dos novos actores do mercado de solucións de recuperación ante desastres é Hystax, unha startup rusa en 2016. Dado que o tema da recuperación ante desastres é moi popular e o mercado é extremadamente competitivo, a startup decidiu centrarse na migración entre diferentes infraestruturas na nube. Un produto que permita organizar unha migración sinxela e rápida á nube sería moi útil para os clientes de Onlanta - usuarios. . Foi así como coñecín Hystax e comecei a probar as súas características. E o que saíu, contarei neste artigo.
A principal característica de Hystax é a súa ampla funcionalidade para admitir varias plataformas de virtualización, sistemas operativos convidados e servizos na nube, o que fai posible mover as súas cargas de traballo desde calquera lugar e desde calquera lugar.
Isto permítelle crear non só solucións de DR para mellorar a tolerancia a fallos dos servizos, senón tamén migrar de xeito rápido e flexible os recursos entre diferentes sitios e hiperescaladores para aumentar o aforro de custos e seleccionar a mellor solución para un determinado servizo no momento. Ademais das plataformas que aparecen na imaxe do título, a compañía tamén coopera activamente con provedores de nube rusos: Yandex.Cloud, CROC Cloud Services, Mail.ru e moitos outros. Tamén cabe destacar que en 2020 a empresa abriu un centro de I+D situado en Skolkovo.
A elección dunha solución por parte dun gran número de xogadores no mercado indica unha boa política de prezos e unha alta aplicabilidade do produto, que decidimos probar na práctica.
Entón, a nosa tarefa de proba consistirá na migración do meu sitio de proba de VMware e das máquinas físicas ao sitio do provedor que tamén executa VMware. Si, hai moitas solucións que poden implementar tal migración, pero consideramos que Hystax é unha ferramenta universal e probar a migración en todas as combinacións posibles é simplemente unha tarefa pouco realista. Si, e a nube Oncloud.ru está construída especificamente en VMware, polo que esta plataforma, como obxectivo, interésanos en maior medida. A continuación, describirei o principio básico de funcionamento, que no seu conxunto non depende da plataforma, e VMware pódese substituír desde calquera lado por unha plataforma doutro provedor.
O primeiro paso é implantar Hystax Acura, que é o panel de control do sistema.
Expándese a partir do modelo. Por algún motivo, no noso caso, non era totalmente correcto e, en lugar da 8CPU recomendada, implantáronse 16 Gb coa metade dos recursos. Polo tanto, cómpre lembrar de cambialos, se non, a infraestrutura dentro da máquina virtual, na que está construído todo, simplemente non comezará con contedores e o portal non estará dispoñible. EN descríbense en detalle os recursos necesarios, así como os portos para todos os compoñentes do sistema.
E tamén houbo dificultades para configurar o enderezo IP a través do modelo, polo que o cambiamos desde a consola. Despois diso, pode ir á interface web de administración e completar o asistente de configuración inicial.
Punto final: IP ou FQDN do noso vCenter.
Inicio de sesión e contrasinal: aquí está claro.
O nome de host ESXi de destino é un dos hosts do noso clúster no que se replicará.
O almacén de datos de destino é un dos almacéns de datos do noso clúster no que se replicará.
IP pública do panel de control Hystax Acura: o enderezo onde estará dispoñible o panel de control.
Requírese unha pequena aclaración sobre o host e o almacén de datos. O feito é que a replicación de Hystax funciona a nivel de host e almacén de datos. A continuación, vouche dicir como podes cambiar o host e o almacén de datos para o inquilino, pero o problema é diferente. Hystax non admite a agrupación de recursos, é dicir. a réplica sempre ocorrerá na raíz do clúster (no momento de escribir este material, os mozos de Hystax lanzaron unha versión actualizada, onde implementaron rapidamente a miña solicitude de funcións relativas ao soporte para grupos de recursos). Tamén vCloud Director non é compatible, é dicir. se, como no meu caso, o inquilino non ten dereitos de administrador para todo o clúster, senón só para un grupo de recursos específico e demos acceso a Hystax, entón poderá replicar e executar estas máquinas virtuales de forma independente, pero non poder velos na infraestrutura de VMware, á que ten acceso e, en consecuencia, xestionar aínda máis as máquinas virtuais. O administrador do clúster debe mover a máquina virtual ao grupo de recursos correcto ou importala a vCloud Director.
Por que me concentro tanto nestes momentos? Porque, ata onde entendo o concepto do produto, o cliente debería poder implementar de forma independente calquera migración ou DR usando o panel Acura. Pero ata agora, o soporte de VMware está lixeiramente por detrás do nivel de soporte para o mesmo OpenStack, onde xa se implementaron estes mecanismos.
Pero volvemos ao despregamento. En primeiro lugar, despois da configuración inicial do panel, necesitamos crear o primeiro inquilino no noso sistema.
Todos os campos aquí están claros, só falarei do campo Cloud. Xa temos unha nube "por defecto" que creamos durante a configuración inicial. Pero se queremos poder poñer a cada inquilino no seu propio almacén de datos e no seu propio grupo de recursos, podemos implementar isto creando nubes separadas para cada un dos nosos clientes.
En forma de engadir unha nova nube, especificamos os mesmos parámetros que durante a configuración inicial (incluso podemos usar o mesmo host), especificamos o almacén de datos necesario para un cliente en particular, e agora nos parámetros adicionais xa podemos especificar individualmente o recurso de grupo necesario {"resource_pool" :"YOUR_POOL_NAME"}
Como xa notarás, na forma de crear un inquilino non hai nada sobre a asignación de recursos ou algún tipo de cotas; non hai nada diso no sistema. Non pode limitar o inquilino no número de réplicas simultáneas, o número de máquinas para a replicación ou por calquera outro parámetro. Entón, creamos o primeiro inquilino. Agora hai unha cousa non totalmente lóxica, pero obrigatoria: instalar un axente na nube. Non é lóxico, porque o axente se descarga na páxina dun cliente específico.
Ao mesmo tempo, non está vinculado ao inquilino creado, e todos os nosos clientes traballarán a través del (ou despois de varios, se os implantamos). Un axente admite 10 sesións simultáneas. Unha sesión conta como un coche. Non importa cantos discos teña. Ata a data, non hai ningún mecanismo para escalar axentes en Acura para VMware. Hai un momento máis desagradable: non podemos ver a "utilización" deste axente desde o panel de Acura para concluír se necesitamos implantar máis ou a instalación actual é suficiente. Como resultado, o stand ten o seguinte aspecto:
O seguinte paso para acceder ao portal do noso cliente é crear unha conta (e primeiro, tamén un rol que se aplicará a este usuario).
Agora o noso cliente pode usar o portal de forma independente. Só ten que descargar axentes do portal e instalalos do seu lado. Hai tres tipos de axentes: Linux, Windows e VMware.
Os dous primeiros colócanse en física ou en máquinas virtuais en calquera hipervisor que non sexa VMware. Non se require ningunha configuración adicional aquí, o axente descarga e xa sabe onde chamar, e literalmente nun minuto o coche estará visible no panel de Acura. Co axente de VMware, a situación é un pouco máis complicada. O problema é que o axente para VMware tamén se descarga dende o portal xa preparado e tendo a configuración necesaria. Pero o axente de VMware, ademais de coñecer o noso portal de Acura, tamén precisa saber sobre o sistema de virtualización no que se implantará.
En realidade, o sistema pediranos que especifiquemos estes datos cando descargues por primeira vez o axente de VMware. O problema é que na nosa era de amor universal pola seguridade, non todo o mundo quererá indicar o seu contrasinal de administrador no portal doutra persoa, o que é bastante comprensible. Desde o interior, despois da implantación, o axente non se pode configurar de ningún xeito (só pode cambiar a súa configuración de rede). Aquí prevén dificultades con clientes especialmente cautos.
Entón, despois de instalar os axentes, podemos volver ao panel de Acura e ver todos os nosos coches.
Xa que levo máis dun día traballando co sistema, teño máquinas en varios estados. Todos eles están no grupo Predeterminado, pero é posible crear grupos separados e transferir máquinas a eles, segundo o precise. Isto non afecta a nada: só a representación lóxica dos datos e a súa agrupación para un traballo máis cómodo. O primeiro e máis importante que debemos facer despois é comezar o proceso de migración. Podemos facelo manualmente e configurar unha programación, incluída a granel para todas as máquinas á vez.
Permíteme recordarche que Hystax se posicionou como un produto para a migración. Polo tanto, non é de estrañar que para executar as nosas máquinas replicadas, necesitemos crear un plan de DR. Podes crear un plan para máquinas que xa están no estado Sincronizado. Pode xerar tanto para unha máquina virtual específica como para todas as máquinas á vez.
O conxunto de parámetros ao xerar un plan de DR diferirá segundo a infraestrutura á que vaias migrar. Un conxunto mínimo de opcións está dispoñible para un ambiente VMware. Re-IP para máquinas tampouco é compatible. Neste sentido, interésanos os seguintes puntos: na descrición da máquina virtual, o parámetro "subrede": "VMNetwork", onde vinculamos a máquina virtual a unha rede específica do clúster. Rank: relevante cando se migran varias máquinas virtuales, determina a orde na que se inician. Sabor - describe a configuración da máquina virtual, neste caso - 1CPU, 2 GB de RAM. Na sección de subredes, definimos esa "subrede": "VMNetwork" está asociada á "Rede VM" de VMware.
Ao crear un plan de DR, non hai forma de "dividir" os discos en diferentes almacéns de datos. Localizaranse no mesmo almacén de datos que se definiu para esta nube de clientes, e se tes discos de diferentes clases, isto pode causar algunhas dificultades ao iniciar a máquina, e despois de iniciar e "separar" a máquina virtual de Hystax, tamén requiren discos de migración separados aos almacéns de datos necesarios. Entón só temos que executar o noso plan DR e esperar a que suban os nosos coches. O proceso de conversión P2V/V2V tamén leva tempo. Na miña máquina de proba máis grande de 100 GB con tres discos, isto levou un máximo de 10 minutos.
Despois diso, debes comprobar a máquina virtual en execución, os servizos nela, a coherencia dos datos e outras comprobacións.
Despois temos dúas opcións:
- Eliminar: elimina un plan de DR en execución. Esta acción simplemente pechará a máquina virtual en execución. Estas réplicas non van a ningún lado.
- Separar - arrincar o coche replicado de Acura, é dicir. completar realmente o proceso de migración.
Vantaxes da solución:
- facilidade de instalación e configuración tanto no lado do cliente como no do provedor;
- facilidade para configurar a migración, crear un plan de DR e lanzar réplicas;
- o soporte e os desenvolvedores responden con bastante rapidez aos problemas atopados e solucionalos con actualizacións de plataforma ou axentes.
Contra
- Soporte insuficiente de Vmware.
- A ausencia de calquera cota para os inquilinos da plataforma.
Tamén fixen unha solicitude de funcións, que entregamos ao vendedor:
- seguimento do uso e despregamento desde a Consola de xestión de Acura para axentes da nube;
- dispoñibilidade de cotas para os inquilinos;
- a capacidade de limitar o número de réplicas simultáneas e a velocidade para cada inquilino;
- soporte para VMware vCloud Director;
- soporte para grupos de recursos (implementado durante a proba);
- a posibilidade de configurar o axente de VMware desde o lado do propio axente, sen introducir as credenciais da infraestrutura do cliente no panel Acura;
- "Visualización" do proceso de inicio dunha máquina virtual ao iniciar un plan de DR.
O único que me causou grandes queixas foi a documentación. Non me gustan moito as "caixas negras" e prefiro cando hai documentación detallada sobre como funciona o produto dentro. E se para AWS e OpenStack o produto se describe aínda máis ou menos, entón para VMware hai moi pouca documentación.
Hai unha Guía de instalación que describe só a implantación do panel Acura, e onde non hai unha palabra sobre a necesidade dun axente Cloud. Hai un conxunto completo de especificacións para o produto, o que é bo. Hai documentación que describe a configuración "desde e ata" usando AWS e OpenStack como exemplo (aínda que me recorda máis a unha publicación de blog) e hai unha base de coñecemento moi pequena.
En xeral, este non é o formato de documentación ao que estou afeito, digamos, dos grandes provedores, polo que non me sentín totalmente cómodo. Ao mesmo tempo, non atopei respostas sobre algúns dos matices do funcionamento do sistema "dentro" nesta documentación: tiven que aclarar moitas preguntas con soporte técnico, e isto arrastrou o proceso de implantación do stand e probando.
En resumo, podo dicir que en xeral gustoume o produto e o enfoque da empresa na implementación da tarefa. Si, hai fallos, hai unha falta de funcionalidade realmente crítica (en conxunto con VMware). Pódese ver que, en primeiro lugar, a compañía aínda se centra nas nubes públicas, en particular en AWS, e para algúns isto será suficiente. Ter un produto tan sinxelo e cómodo hoxe en día, cando moitas empresas elixen unha estratexia multi-nube, é extremadamente importante. Dado o prezo moito máis baixo en comparación cos competidores, isto fai que o produto sexa moi atractivo.
Buscamos equipo . Quizais sexas ti?
Fonte: www.habr.com