Uno de los jugadores más jóvenes en el mercado de soluciones de recuperación ante desastres es la empresa Hystax, una startup rusa de 2016. Dado que el tema de la recuperación ante desastres es muy popular y hay una alta competencia en el mercado, la startup decidió enfocarse en la migración entre diferentes infraestructuras en la nube. Un producto que permite organizar una migración simple y rápida a la nube sería muy útil también para los clientes de la empresa «Онланта» — usuarios . Así fue como conocí a Hystax y comencé a probar sus capacidades. ¿Qué resultado obtuvimos? Lo contaré en este artículo.
La característica principal de Hystax es su amplia funcionalidad en el soporte de diversas plataformas de virtualización, sistemas operativos invitados y servicios en la nube, lo que permite trasladar sus cargas de trabajo de donde sea y a donde sea.
Esto permite crear no solo soluciones de DR para aumentar la resiliencia de los servicios, sino también migrar recursos de forma ágil y flexible entre diferentes plataformas y hiperescalares para lograr ahorros de costos y elegir la mejor solución para un servicio específico en un momento dado. Además de las plataformas mencionadas en la imagen de cabecera, la empresa también colabora activamente con proveedores de nube rusos: Yandex.Cloud, КРОК «Облачные сервисы», Mail.ru y muchos otros. También cabe mencionar que en 2020 la empresa estableció un centro de I+D ubicado en Skolkovo.
La elección de una solución por una gran cantidad de actores en el mercado indica una buena política de precios y una alta aplicabilidad del producto, algo que decidimos verificar en la práctica.
Así que nuestra tarea de prueba consistirá en migrar desde mi plataforma de prueba VMware y máquinas físicas a la plataforma del proveedor también bajo gestión de VMware. Sí, hay muchas soluciones que pueden realizar una migración de este tipo, pero consideramos a Hystax como una herramienta universal, y probar la migración en todas las combinaciones posibles sería simplemente una tarea irreal. Además, la nube Oncloud.ru está construida precisamente 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 en general no depende de la plataforma, y VMware puede ser sustituido por una plataforma de otro proveedor desde cualquier lado.
En la primera etapa, es necesario desplegar Hystax Acura, que es el panel de control del sistema.
Se despliega a partir de una plantilla. Por alguna razón, en nuestro caso no era del todo correcta y en lugar de los recursos recomendados de 8CPU, 16Gb, se desplegó con recursos dos veces más bajos. Por lo tanto, es importante actualizar estos valores, de lo contrario la infraestructura dentro de la VM, en la que se basa todo, simplemente no se iniciará y el portal será inaccesible. En se detallan los recursos requeridos, así como los puertos para todos los componentes del sistema.
Y también hubo dificultades con la asignación de la dirección IP a través de la plantilla, así que la cambiamos desde la consola. Después de esto, se puede acceder a la interfaz web de administración y completar el asistente de configuración inicial.
Endpoint – IP o FQDN de nuestro vCenter.
Login y Password – esto es claro.
Target ESXi hostname – uno de los hosts de nuestro clúster, al cual se realizará la replicación.
Target datastore – uno de los datastores de nuestro clúster, al cual se realizará la replicación.
Hystax Acura Control Panel Public IP – la dirección a la que se accederá al panel de control.
Se requiere una pequeña aclaración sobre el host y el datastore. La cuestión es que la replicación de Hystax se realiza a nivel de host y datastore. Más adelante explicaré cómo se puede cambiar el host y el datastore para el inquilino, pero el problema es otro. Hystax no admite el trabajo con grupos de recursos, es decir, la replicación siempre se realizará en la raíz del clúster (mientras escribía este material, el equipo de Hystax lanzó una versión actualizada, donde implementaron rápidamente mi solicitud de función sobre el soporte de grupos de recursos). Tampoco se soporta vCloud Director, es decir, si, como en mi caso, el inquilino no tiene derechos administrativos sobre todo el clúster, sino solo sobre un grupo de recursos específico, y le hemos otorgado acceso a Hystax, podrá replicar e iniciar estas VMs de forma independiente, pero no podrá verlas en la infraestructura de VMware a la que tiene acceso y, por lo tanto, administrar las máquinas virtuales posteriormente. Es necesario que el administrador del clúster mueva la VM al grupo de recursos necesario o la importe en vCloud Director.
¿Por qué enfatizo tanto estos puntos? Porque, según entiendo el concepto del producto, el cliente debe poder realizar cualquier migración o DR por sí mismo utilizando el panel de Acura. Pero hasta ahora, el soporte para VMware está un poco rezagado en comparación con el soporte para OpenStack, donde esos mecanismos ya están implementados.
Pero volvamos a la implementación. Lo primero que debemos hacer, después de la configuración inicial del panel, es crear el primer inquilino en nuestro sistema.
Todos los campos aquí son claros, solo hablaré sobre el campo de Nube. Ya tenemos una nube «predeterminada» que creamos durante la configuración inicial. Sin embargo, si queremos tener la capacidad de asignar cada inquilino a su propio almacén de datos y a su propio grupo de recursos, podemos hacerlo creando nubes separadas para cada uno de nuestros clientes.
En el formulario para añadir una nueva nube, indicamos los mismos parámetros que en la configuración inicial (incluso podemos utilizar el mismo host), especificamos el almacén de datos necesario para el cliente específico, y ahora en los parámetros adicionales ya podemos indicar individualmente el grupo de recursos necesario {«resource_pool»: «YOUR_POOL_NAME»}.
Como habrán notado, en el formulario de creación de un inquilino no hay nada sobre la asignación de recursos o cuotas, nada de eso existe en el sistema. No se puede limitar un inquilino en la cantidad de réplicas simultáneas, en el número de máquinas para replicación o por otros parámetros. Así que, hemos creado el primer inquilino. Ahora hay algo que no es del todo lógico, pero es obligatorio: la instalación del agente de Nube. No es lógico porque el agente se descarga en la página de un cliente específico.
No está vinculado al inquilino creado, y a través de él trabajarán todos nuestros clientes (o a través de varios, si los desplegamos). Un agente admite 10 sesiones simultáneas. Se considera una sesión por cada máquina. No importa cuántos discos tenga. En la actualidad, no hay un mecanismo para escalar agentes en Acura para VMware. Hay otro punto desagradable: no tenemos la posibilidad desde el panel de Acura de ver la "utilización" de este agente, para determinar si necesitamos desplegar más o si la instalación actual es suficiente. En resumen, el entorno se ve de la siguiente manera:
El siguiente paso para acceder al portal de nuestro cliente es crear una cuenta (y previamente también un rol que se aplicará a este usuario).
Ahora nuestro cliente puede usar el portal por sí mismo. Todo lo que necesita hacer es descargar los agentes del portal e instalarlo en su lado. Hay tres tipos de agentes: Linux, Windows y VMware.
Los dos primeros se instalan en hardware físico o en máquinas virtuales en cualquier hipervisor que no sea VMware. No se requiere ninguna configuración adicional; el agente se descarga y ya sabe a dónde debe conectarse, y literalmente en un minuto la máquina estará visible en el panel de Acura. La situación con el agente de VMware es un poco más complicada. El problema es que el agente para VMware también se descarga del portal ya preparado y con la configuración necesaria. Pero el agente de VMware, además de conocer nuestro portal de Acura, también necesita conocer el sistema de virtualización en el que se desplegará.
De hecho, estos son los datos que el sistema nos pedirá indicar al descargar por primera vez el agente de VMware. El problema es que en nuestra era de amor por la seguridad, no todos querrán ingresar su contraseña de administrador en un portal ajeno, lo cual es comprensible. Una vez desplegado, el agente no puede ser configurado de ninguna otra manera (solo se pueden cambiar sus configuraciones de red). Aquí preveo dificultades con clientes especialmente cautelosos.
Así que, después de instalar los agentes, podemos volver al panel de Acura y ver todas nuestras máquinas.
Dado que ya llevo trabajando con el sistema varios días, tengo máquinas en diversos estados. Todas están en el grupo Default, pero hay opción de crear grupos separados y trasladar las máquinas a ellos según sea necesario. Esto no afecta en nada: es solo una representación lógica de los datos y su agrupación para facilitar el trabajo. Lo primero y más importante que debemos hacer después de esto es iniciar el proceso de migración. Podemos hacerlo de forma manual forzada o programar una rutina, incluyendo para todas las máquinas a la vez.
Recuerdo que Hystax se posicionó como un producto para migraciones. Por lo tanto, no es sorprendente que para lanzar nuestras máquinas replicadas necesitemos crear un plan DR. Este plan se puede elaborar para las máquinas que ya están en estado Sincronizado. Se puede generar tanto para una VM específica como para todas las máquinas a la vez.
El conjunto de parámetros al generar el plan DR variará según la infraestructura a la que se va a migrar. Para el entorno de VMware, se ofrece un conjunto mínimo de parámetros. Además, no se permite el Re-IP para las máquinas. En este plan nos interesan los siguientes aspectos: en la descripción de la VM, el parámetro "subnet": "VMNetwork", donde vinculamos la VM a una red específica dentro del clúster. Rank es relevante al migrar varias VMs, determina el orden de activación. Flavor describe la configuración de la VM, en este caso: 1CPU, 2GB RAM. En la sección de subnets, definimos que "subnet": "VMNetwork" está asociado con la red "VM Network" de VMware.
Al crear un plan DR, no hay opción de "dividir" discos entre diferentes datastores. Estarán en el mismo datastore que se determinó para esta nube del cliente, y si tiene discos de diferentes clases, esto puede presentar algunas dificultades al iniciar la máquina, y tras el inicio y el "desenganche" de la VM de Hystax, requerirá una migración separada de los discos a los datastores adecuados. Luego, solo nos queda iniciar nuestro plan DR y esperar a que se levanten nuestras máquinas. El proceso de conversión P2V/V2V también toma tiempo. En mi máquina de prueba más grande, de 100GB con tres discos, esto tomó un máximo de 10 minutos.
Después de esto, es necesario verificar la VM que se ha iniciado, los servicios en ella, la consistencia de los datos y realizar otras verificaciones.
A partir de aquí, tenemos dos caminos:
- Eliminar – eliminar el plan DR en ejecución. Esta acción simplemente apagará la VM en ejecución. Los datos de la réplica no se perderán.
- Desvincular – desvincular la máquina replicada de Acura, es decir, finalizar el proceso de migración.
Ventajas de la solución:
- facilidad de instalación y configuración tanto del lado del cliente como del proveedor;
- simplicidad en la configuración de la migración, creación del plan DR y lanzamientos de réplicas;
- el soporte y los desarrolladores responden de manera bastante rápida a los problemas encontrados y los resuelven mediante actualizaciones de la plataforma o agentes.
Desventajas
- Soporte insuficiente para Vmware.
- Falta de cualquier tipo de cuotificación para los inquilinos por parte de la plataforma.
También redacté una Solicitud de Funcionalidad que enviamos al proveedor:
- monitoreo del uso y despliegue desde la consola de gestión de Acura para los agentes de Cloud;
- existencia de cuotas para los inquilinos;
- posibilidad de limitar la cantidad de replicaciones simultáneas y la velocidad para cada inquilino;
- soporte para VMware vCloud Director;
- soporte para pools de recursos (se implementó durante la fase de pruebas);
- posibilidad de configurar el agente VMware desde el propio agente, sin introducir las credenciales de la infraestructura del cliente en el panel de Acura;
- «visualización» del proceso de lanzamiento de la VM al iniciar el plan DR.
Lo único que me causó grandes quejas fue la documentación. No me gustan mucho las «cajas negras» y prefiero que haya documentación detallada sobre cómo funciona el producto por dentro. Y si para AWS y OpenStack el producto está más o menos descrito, para VMware la documentación es extremadamente escasa.
Hay una Guía de Instalación que describe solo el despliegue del panel de Acura, y no menciona que también se necesita el agente de Cloud. Hay un conjunto completo de especificaciones del producto, lo cual es positivo. Hay documentación que describe la configuración «de principio a fin» usando AWS y OpenStack (aunque me recuerda más a un post de blog), y hay una base de conocimiento muy limitada.
En general, este no es el formato de documentación al que estoy acostumbrado, digamos, con proveedores más grandes, por lo que no me sentí del todo cómodo. Al mismo tiempo, no encontré respuestas sobre algunas particularidades del funcionamiento interno del sistema en esta documentación; tuve que aclarar muchas preguntas con el soporte técnico, lo que retrasó bastante el proceso de despliegue del entorno y las pruebas.
En resumen, puedo decir que en general me gustaron el producto y el enfoque de la empresa para abordar la tarea. Sí, hay áreas de mejora, hay una deficiencia realmente crítica en la funcionalidad (en combinación con VMware). Se nota que, ante todo, la empresa está enfocada en las nubes públicas, en particular AWS, y para algunos esto será suficiente. La existencia de un producto tan simple y conveniente hoy en día, cuando muchas empresas eligen una estrategia de múltiples nubes, es extremadamente importante. Dado el precio mucho más bajo en comparación con los competidores, esto hace que el producto sea muy atractivo.
Estamos buscando para nuestro equipo . ¿Podrías ser tú?
Fuente: habr.com
