{"id":96767,"date":"2020-10-14T14:43:02","date_gmt":"2020-10-14T12:43:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/hystax-cloud-migration-skachem-po-oblakam"},"modified":"2020-10-14T14:43:02","modified_gmt":"2020-10-14T12:43:02","slug":"hystax-cloud-migration-skachem-po-oblakam","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/hystax-cloud-migration-skachem-po-oblakam","title":{"rendered":"Hystax Cloud Migration: saltando entre nubes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Uno de los j\u00f3venes jugadores en el mercado de soluciones de Recuperaci\u00f3n ante Desastres es la empresa Hystax, una startup rusa de 2016. Dado que el tema de la recuperaci\u00f3n ante desastres es muy popular y el mercado presenta una competencia extremadamente alta, la startup decidi\u00f3 concentrarse en la migraci\u00f3n entre diferentes infraestructuras en la nube. Un producto que permita organizar una migraci\u00f3n simple y r\u00e1pida a la nube ser\u00eda muy \u00fatil tambi\u00e9n para los clientes de la empresa \"Onlanta\" \u2014 usuarios. Oncloud.ru<\/a><\/noindex>. As\u00ed fue como conoc\u00ed a Hystax y comenc\u00e9 a probar sus capacidades. \u00bfQu\u00e9 resultado obtuvimos? Lo contar\u00e9 en este art\u00edculo.<\/p>\n

\"Hystax<\/a><\/noindex>
\nLa caracter\u00edstica principal de Hystax es su amplia funcionalidad en el soporte de diversas plataformas de virtualizaci\u00f3n, sistemas operativos invitados y servicios en la nube, lo que permite trasladar sus cargas de trabajo de donde sea y a donde sea.<\/p>\n

Esto permite crear no solo soluciones de DR para aumentar la resiliencia de los servicios, sino tambi\u00e9n migrar recursos de forma \u00e1gil y flexible entre diferentes plataformas y hiperescalares para lograr ahorros de costos y elegir la mejor soluci\u00f3n para un servicio espec\u00edfico en un momento dado. Adem\u00e1s de las plataformas mencionadas en la imagen de cabecera, la empresa tambi\u00e9n colabora activamente con proveedores de nube rusos: Yandex.Cloud, \u041a\u0420\u041e\u041a \u00ab\u041e\u0431\u043b\u0430\u0447\u043d\u044b\u0435 \u0441\u0435\u0440\u0432\u0438\u0441\u044b\u00bb, Mail.ru y muchos otros. Tambi\u00e9n cabe mencionar que en 2020 la empresa estableci\u00f3 un centro de I+D ubicado en Skolkovo.\u00a0<\/p>\n

La elecci\u00f3n de una soluci\u00f3n por una gran cantidad de actores en el mercado indica una buena pol\u00edtica de precios y una alta aplicabilidad del producto, algo que decidimos verificar en la pr\u00e1ctica.<\/p>\n

As\u00ed que nuestra tarea de prueba consistir\u00e1 en migrar desde mi plataforma de prueba VMware y m\u00e1quinas f\u00edsicas a la plataforma del proveedor tambi\u00e9n bajo gesti\u00f3n de VMware. S\u00ed, hay muchas soluciones que pueden realizar una migraci\u00f3n de este tipo, pero consideramos a Hystax como una herramienta universal, y probar la migraci\u00f3n en todas las combinaciones posibles ser\u00eda simplemente una tarea irreal. Adem\u00e1s, la nube Oncloud.ru est\u00e1 construida precisamente sobre VMware, por lo que esta plataforma como objetivo nos interesa en mayor medida. A continuaci\u00f3n, describir\u00e9 el principio b\u00e1sico de funcionamiento, que en general no depende de la plataforma, y VMware puede ser sustituido por una plataforma de otro proveedor desde cualquier lado.\u00a0<\/p>\n

En la primera etapa, es necesario desplegar Hystax Acura, que es el panel de control del sistema.<\/p>\n

\"Hystax<\/a><\/noindex>
\nSe despliega a partir de una plantilla. Por alguna raz\u00f3n, en nuestro caso no era del todo correcta y en lugar de los recursos recomendados de 8CPU, 16Gb, se despleg\u00f3 con recursos dos veces m\u00e1s 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\u00e1 y el portal ser\u00e1 inaccesible. En Requisitos de despliegue<\/a><\/noindex> se detallan los recursos requeridos, as\u00ed como los puertos para todos los componentes del sistema.\u00a0<\/p>\n

Y tambi\u00e9n hubo dificultades con la asignaci\u00f3n de la direcci\u00f3n IP a trav\u00e9s de la plantilla, as\u00ed que la cambiamos desde la consola. Despu\u00e9s de esto, se puede acceder a la interfaz web de administraci\u00f3n y completar el asistente de configuraci\u00f3n inicial.\u00a0<\/p>\n

\"Hystax<\/a><\/noindex>
\n\"Hystax<\/a><\/noindex>
\nEndpoint \u2013 IP o FQDN de nuestro vCenter.\u00a0
\nLogin y Password \u2013 esto es claro.\u00a0
\nTarget ESXi hostname \u2013 uno de los hosts de nuestro cl\u00faster, al cual se realizar\u00e1 la replicaci\u00f3n.\u00a0
\nTarget datastore \u2013 uno de los datastores de nuestro cl\u00faster, al cual se realizar\u00e1 la replicaci\u00f3n.
\nHystax Acura Control Panel Public IP \u2013 la direcci\u00f3n a la que se acceder\u00e1 al panel de control.<\/p>\n

Se requiere una peque\u00f1a aclaraci\u00f3n sobre el host y el datastore. La cuesti\u00f3n es que la replicaci\u00f3n de Hystax se realiza a nivel de host y datastore. M\u00e1s adelante explicar\u00e9 c\u00f3mo 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\u00f3n siempre se realizar\u00e1 en la ra\u00edz del cl\u00faster (mientras escrib\u00eda este material, el equipo de Hystax lanz\u00f3 una versi\u00f3n actualizada, donde implementaron r\u00e1pidamente mi solicitud de funci\u00f3n 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\u00faster, sino solo sobre un grupo de recursos espec\u00edfico, y le hemos otorgado acceso a Hystax, podr\u00e1 replicar e iniciar estas VMs de forma independiente, pero no podr\u00e1 verlas en la infraestructura de VMware a la que tiene acceso y, por lo tanto, administrar las m\u00e1quinas virtuales posteriormente. Es necesario que el administrador del cl\u00faster mueva la VM al grupo de recursos necesario o la importe en vCloud Director.<\/p>\n

\u00bfPor qu\u00e9 enfatizo tanto estos puntos? Porque, seg\u00fan entiendo el concepto del producto, el cliente debe poder realizar cualquier migraci\u00f3n o DR por s\u00ed mismo utilizando el panel de Acura. Pero hasta ahora, el soporte para VMware est\u00e1 un poco rezagado en comparaci\u00f3n con el soporte para OpenStack, donde esos mecanismos ya est\u00e1n implementados.\u00a0<\/p>\n

Pero volvamos a la implementaci\u00f3n. Lo primero que debemos hacer, despu\u00e9s de la configuraci\u00f3n inicial del panel, es crear el primer inquilino en nuestro sistema.<\/p>\n

\"Hystax<\/a><\/noindex>
\nTodos los campos aqu\u00ed son claros, solo hablar\u00e9 sobre el campo de Nube. Ya tenemos una nube \u00abpredeterminada\u00bb que creamos durante la configuraci\u00f3n inicial. Sin embargo, si queremos tener la capacidad de asignar cada inquilino a su propio almac\u00e9n de datos y a su propio grupo de recursos, podemos hacerlo creando nubes separadas para cada uno de nuestros clientes.<\/p>\n

\"Hystax<\/a><\/noindex>
\nEn el formulario para a\u00f1adir una nueva nube, indicamos los mismos par\u00e1metros que en la configuraci\u00f3n inicial (incluso podemos utilizar el mismo host), especificamos el almac\u00e9n de datos necesario para el cliente espec\u00edfico, y ahora en los par\u00e1metros adicionales ya podemos indicar individualmente el grupo de recursos necesario {\u00abresource_pool\u00bb: \u00abYOUR_POOL_NAME\u00bb}.\u00a0<\/p>\n

Como habr\u00e1n notado, en el formulario de creaci\u00f3n de un inquilino no hay nada sobre la asignaci\u00f3n de recursos o cuotas, nada de eso existe en el sistema. No se puede limitar un inquilino en la cantidad de r\u00e9plicas simult\u00e1neas, en el n\u00famero de m\u00e1quinas para replicaci\u00f3n o por otros par\u00e1metros. As\u00ed que, hemos creado el primer inquilino. Ahora hay algo que no es del todo l\u00f3gico, pero es obligatorio: la instalaci\u00f3n del agente de Nube. No es l\u00f3gico porque el agente se descarga en la p\u00e1gina de un cliente espec\u00edfico.<\/p>\n

\"Hystax<\/a><\/noindex>
\nNo est\u00e1 vinculado al inquilino creado, y a trav\u00e9s de \u00e9l trabajar\u00e1n todos nuestros clientes (o a trav\u00e9s de varios, si los desplegamos). Un agente admite 10 sesiones simult\u00e1neas. Se considera una sesi\u00f3n por cada m\u00e1quina. No importa cu\u00e1ntos 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\u00f3n\" de este agente, para determinar si necesitamos desplegar m\u00e1s o si la instalaci\u00f3n actual es suficiente. En resumen, el entorno se ve de la siguiente manera:<\/p>\n

\"Hystax<\/a><\/noindex>
\nEl siguiente paso para acceder al portal de nuestro cliente es crear una cuenta (y previamente tambi\u00e9n un rol que se aplicar\u00e1 a este usuario).<\/p>\n

\"Hystax<\/a><\/noindex>
\n\"Hystax<\/a><\/noindex>
\nAhora nuestro cliente puede usar el portal por s\u00ed 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.<\/p>\n

\"Hystax<\/a><\/noindex>
\nLos dos primeros se instalan en hardware f\u00edsico o en m\u00e1quinas virtuales en cualquier hipervisor que no sea VMware. No se requiere ninguna configuraci\u00f3n adicional; el agente se descarga y ya sabe a d\u00f3nde debe conectarse, y literalmente en un minuto la m\u00e1quina estar\u00e1 visible en el panel de Acura. La situaci\u00f3n con el agente de VMware es un poco m\u00e1s complicada. El problema es que el agente para VMware tambi\u00e9n se descarga del portal ya preparado y con la configuraci\u00f3n necesaria. Pero el agente de VMware, adem\u00e1s de conocer nuestro portal de Acura, tambi\u00e9n necesita conocer el sistema de virtualizaci\u00f3n en el que se desplegar\u00e1.<\/p>\n

\"Hystax<\/a><\/noindex>
\nDe hecho, estos son los datos que el sistema nos pedir\u00e1 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\u00e1n ingresar su contrase\u00f1a 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\u00ed preveo dificultades con clientes especialmente cautelosos.\u00a0<\/p>\n

As\u00ed que, despu\u00e9s de instalar los agentes, podemos volver al panel de Acura y ver todas nuestras m\u00e1quinas.<\/p>\n

\"Hystax<\/a><\/noindex>
\nDado que ya llevo trabajando con el sistema varios d\u00edas, tengo m\u00e1quinas en diversos estados. Todas est\u00e1n en el grupo Default, pero hay opci\u00f3n de crear grupos separados y trasladar las m\u00e1quinas a ellos seg\u00fan sea necesario. Esto no afecta en nada: es solo una representaci\u00f3n l\u00f3gica de los datos y su agrupaci\u00f3n para facilitar el trabajo. Lo primero y m\u00e1s importante que debemos hacer despu\u00e9s de esto es iniciar el proceso de migraci\u00f3n. Podemos hacerlo de forma manual forzada o programar una rutina, incluyendo para todas las m\u00e1quinas a la vez.<\/p>\n

\"Hystax<\/a><\/noindex>
\nRecuerdo que Hystax se posicion\u00f3 como un producto para migraciones. Por lo tanto, no es sorprendente que para lanzar nuestras m\u00e1quinas replicadas necesitemos crear un plan DR. Este plan se puede elaborar para las m\u00e1quinas que ya est\u00e1n en estado Sincronizado. Se puede generar tanto para una VM espec\u00edfica como para todas las m\u00e1quinas a la vez.<\/p>\n

\"Hystax<\/a><\/noindex>
\nEl conjunto de par\u00e1metros al generar el plan DR variar\u00e1 seg\u00fan la infraestructura a la que se va a migrar. Para el entorno de VMware, se ofrece un conjunto m\u00ednimo de par\u00e1metros. Adem\u00e1s, no se permite el Re-IP para las m\u00e1quinas. En este plan nos interesan los siguientes aspectos: en la descripci\u00f3n de la VM, el par\u00e1metro \"subnet\": \"VMNetwork\", donde vinculamos la VM a una red espec\u00edfica dentro del cl\u00faster. Rank es relevante al migrar varias VMs, determina el orden de activaci\u00f3n. Flavor describe la configuraci\u00f3n de la VM, en este caso: 1CPU, 2GB RAM. En la secci\u00f3n de subnets, definimos que \"subnet\": \"VMNetwork\" est\u00e1 asociado con la red \"VM Network\" de VMware.\u00a0<\/p>\n

Al crear un plan DR, no hay opci\u00f3n de \"dividir\" discos entre diferentes datastores. Estar\u00e1n en el mismo datastore que se determin\u00f3 para esta nube del cliente, y si tiene discos de diferentes clases, esto puede presentar algunas dificultades al iniciar la m\u00e1quina, y tras el inicio y el \"desenganche\" de la VM de Hystax, requerir\u00e1 una migraci\u00f3n separada de los discos a los datastores adecuados. Luego, solo nos queda iniciar nuestro plan DR y esperar a que se levanten nuestras m\u00e1quinas. El proceso de conversi\u00f3n P2V\/V2V tambi\u00e9n toma tiempo. En mi m\u00e1quina de prueba m\u00e1s grande, de 100GB con tres discos, esto tom\u00f3 un m\u00e1ximo de 10 minutos.<\/p>\n

\"Hystax<\/a><\/noindex>
\nDespu\u00e9s de esto, es necesario verificar la VM que se ha iniciado, los servicios en ella, la consistencia de los datos y realizar otras verificaciones.\u00a0<\/p>\n

A partir de aqu\u00ed, tenemos dos caminos:\u00a0<\/p>\n

    \n
  1. Eliminar \u2013 eliminar el plan DR en ejecuci\u00f3n. Esta acci\u00f3n simplemente apagar\u00e1 la VM en ejecuci\u00f3n. Los datos de la r\u00e9plica no se perder\u00e1n.\u00a0<\/li>\n
  2. Desvincular \u2013 desvincular la m\u00e1quina replicada de Acura, es decir, finalizar el proceso de migraci\u00f3n.\u00a0<\/li>\n<\/ol>\n

    \nVentajas de la soluci\u00f3n:<\/strong>\u00a0<\/p>\n