Uno de los actores jóvenes en el mercado de soluciones de recuperación ante desastres es Hystax, una startup rusa de 2016. Dado que el tema de la recuperación ante desastres es muy popular y el mercado es extremadamente competitivo, la startup decidió centrarse en la migración entre diferentes infraestructuras de nube. Un producto que permita organizar una migración sencilla y rápida a la nube también sería de gran utilidad para los clientes - usuarios de Onlanta. . Así fue como conocí Hystax y comencé a probar sus capacidades. Te contaré lo que resultó de esto en este artículo.
La característica principal de Hystax es su amplia funcionalidad para admitir varias plataformas de virtualización, sistemas operativos invitados y servicios en la nube, lo que hace posible transferir sus cargas de trabajo desde cualquier lugar y lugar.
Esto le permite crear no solo soluciones de DR para aumentar la tolerancia a fallas de los servicios, sino también migrar recursos de manera rápida y flexible entre diferentes sitios e hiperescaladores para aumentar el ahorro de costos y seleccionar la mejor solución para un servicio específico en un momento dado. Además de las plataformas que aparecen en la imagen del título, la empresa también coopera activamente con proveedores de nube rusos: Yandex.Cloud, CROC Cloud Services, Mail.ru y muchos otros. También cabe destacar que en 2020 la empresa inauguró un centro de I+D situado en Skolkovo.
La elección de una solución por parte de un gran número de actores del mercado indica una buena política de precios y una alta aplicabilidad del producto, que decidimos probar en la práctica.
Entonces, nuestra tarea de prueba consistirá en migrar desde mi sitio de prueba de VMware y mis máquinas físicas al sitio del proveedor, también administrado por VMware. Sí, existen muchas soluciones que pueden realizar dicha migración, pero consideramos a Hystax como una herramienta universal y probar la migración en todas las combinaciones posibles es simplemente una tarea poco realista. Y la nube Oncloud.ru está construida específicamente sobre VMware, por lo que esta plataforma como objetivo nos interesa en mayor medida. A continuación, describiré el principio básico de funcionamiento, que generalmente es independiente de la plataforma, y VMware de cualquier lado puede ser reemplazado por una plataforma de otro proveedor.
El primer paso es implementar Hystax Acura, que es el panel de control del sistema.
Se desarrolla a partir de la plantilla. Por alguna razón, en nuestro caso no fue del todo correcto y en lugar de los 8CPU recomendados se desplegaron 16Gb con la mitad de recursos. Por lo tanto, debe recordar cambiarlos; de lo contrario, la infraestructura del contenedor dentro de la VM, en la que está construido todo, simplemente no se iniciará y el portal será inaccesible. EN Los recursos necesarios se describen en detalle, así como los puertos para todos los componentes del sistema.
También hubo dificultades para configurar la dirección IP a través de una plantilla, por lo que la cambiamos desde la consola. Después de esto, puede ir a la interfaz web de administración y completar el asistente de configuración inicial.
Endpoint – IP o FQDN de nuestro vCenter.
Nombre de usuario y contraseña: esto está claro.
El nombre de host ESXi de destino es uno de los hosts de nuestro clúster en el que se realizará la replicación.
El almacén de datos de destino es uno de los almacenes de datos de nuestro clúster en el que se realizará la replicación.
IP pública del panel de control de Hystax Acura: la dirección donde estará disponible el panel de control.
Se requiere una pequeña aclaración sobre el host y el almacén de datos. El hecho es que la replicación de Hystax funciona a nivel de host y almacén de datos. A continuación te diré cómo puedes cambiar el host y el almacén de datos de un inquilino, pero el problema es diferente. Hystax no admite trabajar con grupos de recursos, es decir. la réplica siempre irá a la raíz del clúster (al momento de escribir este material, los chicos de Hystax lanzaron una versión actualizada, donde implementaron rápidamente mi solicitud de función con respecto al soporte para grupos de recursos). vCloud Director tampoco es compatible, es decir. Si, como en mi caso, el inquilino no tiene derechos de administrador para todo el clúster, sino solo para un grupo de recursos específico, y le dimos acceso a Hystax, entonces podrá replicar e iniciar estas máquinas virtuales de forma independiente, pero lo hará. no podrá verlos en la infraestructura de VMware, a la que tiene acceso y, en consecuencia, administra aún más las máquinas virtuales. Es necesario que el administrador del clúster mueva la máquina virtual al grupo de recursos deseado o la importe a vCloud Director.
¿Por qué me concentro tanto en estos puntos? Porque, hasta donde yo entiendo el concepto del producto, el cliente debería poder implementar de forma independiente cualquier migración o DR utilizando el panel de Acura. Pero hasta ahora, el soporte de VMware está ligeramente por detrás del nivel de soporte de OpenStack, donde ya se han implementado mecanismos similares.
Pero volvamos al despliegue. En primer lugar, después de la configuración inicial del panel, debemos crear el primer inquilino en nuestro sistema.
Todos los campos aquí están claros, solo te hablaré del campo Nube. Ya tenemos una nube "predeterminada" que creamos durante la configuración inicial. Pero si queremos poder colocar a cada inquilino en su propio almacén de datos y en su propio grupo de recursos, podemos implementarlo creando nubes separadas para cada uno de nuestros clientes.
En el formulario para agregar una nueva nube, especificamos los mismos parámetros que durante la configuración inicial (incluso podemos usar el mismo host), indicamos el almacén de datos requerido para un cliente específico y ahora en parámetros adicionales podemos especificar individualmente el recurso requerido. grupo {"resource_pool": "YOUR_POOL_NAME"}
Como habrás notado, en el formulario de creación de inquilinos no hay nada sobre la asignación de recursos ni sobre cuotas; no hay nada de esto en el sistema. Es imposible limitar a un inquilino en la cantidad de réplicas simultáneas, la cantidad de máquinas para replicación o mediante cualquier otro parámetro. Entonces, hemos creado el primer inquilino. Ahora hay algo que no es del todo lógico, pero sí obligatorio: instalar un agente en la nube. Es ilógico, ya que el agente se descarga en la página de un cliente específico.
Al mismo tiempo, no está vinculado al inquilino creado y todos nuestros clientes trabajarán a través de él (o de varios, si los implementamos). Un agente admite 10 sesiones simultáneas. Una máquina se cuenta como una sesión. No importa cuántos discos tenga. Hasta la fecha, no existe ningún mecanismo para escalar agentes en Acura bajo VMware. Hay un momento desagradable más: no tenemos la oportunidad de observar la "eliminación" de este agente del panel de Acura para concluir si necesitamos implementar más o si la instalación actual es suficiente. Como resultado, el stand se ve así:
El siguiente paso para acceder a nuestro portal de clientes es crear una cuenta (y primero, un rol que se aplicará a este usuario).
Ahora nuestro cliente puede utilizar el portal de forma independiente. Todo lo que necesita hacer es descargar los agentes del portal e instalarlos en su lado. Hay tres tipos de agentes: Linux, Windows y VMware.
Los dos primeros se instalan en máquinas físicas o virtuales en cualquier hipervisor que no sea VMware. No es necesario configurar nada adicional, el agente está descargado y ya sabe dónde tocar, y literalmente en un minuto el automóvil será visible en el panel de Acura. Con el agente de VMware la situación es un poco más complicada. El problema es que el agente para VMware también se descarga desde el portal ya preparado y que contiene la configuración necesaria. Pero además de conocer nuestro portal Acura, un agente de VMware también necesita conocer el sistema de virtualización en el que se implementará.
De hecho, el sistema nos pedirá que proporcionemos estos datos cuando descarguemos por primera vez el agente de VMware. El problema es que en nuestra era de amor universal por la seguridad, no todos querrán indicar su contraseña de administrador en el portal de otra persona, lo cual es bastante comprensible. Desde adentro, después de la implementación, el agente no se puede configurar de ninguna manera (solo puede cambiar su configuración de red). Aquí preveo dificultades con clientes especialmente cautelosos.
Entonces, después de instalar los agentes, podemos volver al panel de Acura y ver todos nuestros autos.
Como llevo varios días trabajando con el sistema, tengo autos en diferentes estados. Los tengo todos en el grupo Predeterminado, pero es posible crear grupos separados y transferirles autos según sea necesario. Esto no afecta nada, solo la presentación lógica de los datos y su agrupación para un trabajo más conveniente. Lo primero y más importante que debemos hacer después de esto es iniciar el proceso de migración. Podemos hacer esto manualmente o configurando un cronograma, incluso de forma masiva para todas las máquinas a la vez.
Permítanme recordarles que Hystax se posicionó como un producto para la migración. Por lo tanto, no es de extrañar que para ejecutar nuestras máquinas replicadas necesitemos crear un plan de recuperación ante desastres. El plan se puede realizar para máquinas que ya están en el estado Sincronizado. Puede generar tanto para una VM específica como para todas las máquinas a la vez.
El conjunto de parámetros al generar un plan de DR diferirá dependiendo de la infraestructura a la que migrarás. Hay disponible un conjunto mínimo de parámetros para el entorno VMware. Tampoco se admite Re-IP para máquinas. En este sentido, nos interesan los siguientes puntos: en la descripción de la VM, el parámetro “subred”: “VMNetwork”, donde vinculamos la VM a una red específica en el cluster. Rango: relevante al migrar varias máquinas virtuales; determina el orden en el que se lanzan. Sabor: describe la configuración de la VM, en este caso: 1 CPU, 2 GB de RAM. En el apartado de subredes definimos que "subred": "VMNetwork" está asociada a la "VM Network" de VMware.
Al crear un plan de recuperación ante desastres, no hay forma de "distribuir" los discos entre diferentes almacenes de datos. Estarán ubicados en el mismo almacén de datos que se definió para esta nube cliente, y si tiene discos de diferentes clases, esto puede causar algunas dificultades al iniciar la máquina, y después de iniciar y “separar” la VM de Hystax, también requieren discos de migración separados a los almacenes de datos requeridos. Entonces todo lo que tenemos que hacer es lanzar nuestro plan DR y esperar a que nuestros autos suban. El proceso de conversión P2V/V2V también lleva tiempo. En mi máquina de prueba más grande, de 100 GB con tres discos, tardó un máximo de 10 minutos.
Después de esto, debe verificar la máquina virtual en ejecución, los servicios que contiene, la coherencia de los datos y realizar otras comprobaciones.
Entonces tenemos dos maneras:
- Eliminar: elimina el plan de recuperación ante desastres en ejecución. Esta acción simplemente apagará la VM en ejecución. Estas réplicas no van a ninguna parte.
- Separar: arrancar un automóvil replicado de un Acura, es decir, realmente completar el proceso de migración.
Ventajas de la solución:
- facilidad de instalación y configuración tanto por parte del cliente como del proveedor;
- facilidad para configurar la migración, crear un plan de recuperación ante desastres y lanzar réplicas;
- El soporte y los desarrolladores responden con bastante rapidez a los problemas encontrados y los solucionan mediante actualizaciones de la plataforma o del agente.
Contras
- Soporte insuficiente de Vmware.
- Ausencia de cuotas de inquilinos de la plataforma.
También compilé una Solicitud de función, que enviamos al proveedor:
- monitoreo e implementación de uso desde la consola de administración de Acura para agentes en la nube;
- disponibilidad de cuotas para inquilinos;
- la capacidad de limitar la cantidad de replicaciones simultáneas y la velocidad para cada inquilino;
- Compatibilidad con VMware vCloud Director;
- soporte para grupos de recursos (implementado durante las pruebas);
- la capacidad de configurar el agente VMware desde el propio agente, sin ingresar credenciales de la infraestructura del cliente en el panel de Acura;
- “visualización” del proceso de inicio de la VM al ejecutar el plan de DR.
Lo único que me generó grandes críticas fue la documentación. Realmente no me gustan las "cajas negras" y prefiero cuando hay documentación detallada sobre cómo funciona el producto en su interior. Y si para AWS y OpenStack el producto se describe aún más o menos, entonces para VMware hay muy poca documentación.
Hay una Guía de instalación que solo describe la implementación del panel de Acura y no dice una palabra sobre el hecho de que también se necesita un agente en la nube. Hay un conjunto completo de especificaciones del producto, lo cual es bueno. Hay documentación que describe la configuración "de principio a fin" usando AWS y OpenStack como ejemplo (aunque a mí me parece más una publicación de blog), y hay una base de conocimientos muy pequeña.
En general, este no es el formato de documentación al que estoy acostumbrado, por ejemplo, de proveedores más grandes, por lo que no me sentí del todo cómodo. Al mismo tiempo, nunca encontré respuestas sobre algunos de los matices de cómo funciona el sistema "interno" en esta documentación; tuve que aclarar muchas preguntas con el soporte técnico, y esto retrasó bastante el proceso de despliegue del stand y realización. pruebas.
En resumen, puedo decir que en general me gustó el producto y el enfoque de la empresa ante la tarea. Sí, hay deficiencias, hay una falta de funcionalidad realmente crítica (en relación con VMware). Está claro que, en primer lugar, la empresa todavía se centra en las nubes públicas, en particular AWS, y para algunos esto será suficiente. Tener un producto tan simple y conveniente hoy en día, cuando muchas empresas eligen una estrategia de múltiples nubes, es extremadamente importante. Teniendo en cuenta el precio mucho más bajo en comparación con la competencia, esto hace que el producto sea extremadamente atractivo.
Buscamos un miembro del equipo. . ¿Tal vez eres tú?
Fuente: habr.com