Digamos que si es necesario "mudarse", por ejemplo, de la plataforma VMware a otra plataforma, esta tarea no es frecuente en las actividades de los especialistas en TI. Por lo tanto, creamos herramientas para esto.
A día de hoy, nuestra solución consta de cuatro productos.
Mind Migrate es, en realidad, una migración única para servicios virtuales. Mind Guard es un producto lanzado muy recientemente, aún no lo presentamos oficialmente, pero hoy hablaremos de él. Se trata de garantizar la protección de estos servidores virtuales.
Mind Universe: creación y gestión automática de la infraestructura de la aplicación en cualquiera de las plataformas de nube o sistemas de virtualización compatibles.
Mind Swap es un módulo de software para implementar varios escenarios de migración de máquinas virtuales y sus recursos de disco a nivel de hipervisor sin interrumpir el funcionamiento del servidor virtual.
Mind
¿Qué hace Mind? Se establece la tarea de "transportar" un servidor virtual. Un servidor virtual es una máquina virtual y un sistema operativo junto con sus datos. El producto lleva en el mercado unos dos años. Al mismo tiempo, ha sido probado en "producción" por diferentes clientes, desde pequeños hasta grandes, y se han estudiado los escenarios en los que surge esta necesidad. En el producto Mind incluimos soporte para todos estos escenarios. Es decir, nuestra tarea principal es crear un producto muy simple, comprensible en términos de interfaz gráfica, en términos de documentación, en términos de la posibilidad de usarlo con una preparación mínima y garantizar la posibilidad de mover servidores virtuales desde cualquier lugar a cualquier lugar. Es decir, en este caso, en la pantalla con los iconos mostrados, realizamos la llegada, por ejemplo, de una máquina virtual desde el entorno VMware a BASIS.
La migración en sí es una migración en vivo. Es decir, ¿cuáles son las opciones para realizar tal operación sin utilizar ningún medio externo? Puede, por ejemplo, tomar y apagar la máquina virtual, exportarla, convertirla al tipo o formato necesario en la plataforma de destino e importarla allí. Puede hacer una copia de seguridad con los medios de los sistemas de copia de seguridad, guardar en algún lugar en el repositorio de copia de seguridad y restaurar desde allí a la nueva plataforma. Estos son, como yo los llamo, "parches", es decir, medios que en general funcionan, pero no están diseñados para tales eventos. Lo que, por ejemplo, se puede hacer con nuestra herramienta es organizar una cola.
Es decir, primero queremos transportar máquinas virtuales de un tipo o de un sistema de información. Después de que se hayan movido y cambiado, podemos iniciar otra etapa, por ejemplo, verificando algo manualmente. Luego ajustamos, por ejemplo, la capacidad de ejecutar scripts, porque la migración de datos requiere la máxima consistencia.
Es decir, queremos que nada se pierda durante la migración. Dado que nuestra herramienta funciona a nivel de bloque, no podemos saber qué hay en la memoria operativa del servidor o la base de datos.
Por lo tanto, a menudo, al migrar, es necesario, por ejemplo, ejecutar algún script, es decir, tomar y poner la base de datos en modo de código consistente, es decir, pedirle a través de algunos medios integrados que rastree los datos de la memoria al disco, después de eso hacemos la sincronización final y podemos incluir la base de datos ya en un nuevo lugar. Estas y muchas otras herramientas están incluidas en la funcionalidad de la plataforma. Mind Migrate puede manejar más de mil máquinas virtuales de tipos completamente diferentes, desde diferentes lugares a diferentes lugares.
Cómo está estructurado este producto. Trabajamos a nivel de sistema operativo. Asignamos una máquina virtual en la que se instala nuestro servidor de gestión Modul Control. La máquina virtual es muy exigente con los recursos, 4 VCPU, 16 GB de memoria. Sistema operativo Ubuntu o Astra. Además, dentro de las máquinas virtuales que planeamos transportar, necesitamos obtener acceso a ellas, a través de SMB, si es una máquina Windows, también necesitamos cuentas de administrador.
Con la ayuda de estas cuentas, Modul Control instala agentes en el sistema operativo. Al mismo tiempo, no interactuamos de ninguna manera con la infraestructura subyacente. Es decir, no nos importa qué plataforma sea, puede ser un servidor limpio, puede ser VMware, Hyper-V, en principio, cualquier cosa. A continuación, mostraré una lista de compatibilidad, lo hemos comprobado. Pero se garantiza una compatibilidad virtual del 100 por ciento con cualquier plataforma. En consecuencia, en la plataforma de destino, por ejemplo, en Astra, se crean máquinas virtuales en la misma configuración que las máquinas migradas, deben crearse manualmente. La configuración de los discos debe ser exactamente la misma que en la máquina virtual. Trabajamos solo con lo que ve el sistema operativo ya dentro de la máquina virtual. Guardamos exactamente la misma estructura de discos y la creamos en la plataforma de destino. En estas máquinas virtuales de destino se inicia el sistema operativo - "dummy". Especialmente, nuevamente, admitimos Ubuntu o Astra para la migración de máquinas Linux y para la migración de máquinas Windows OS "dummy". En consecuencia, también damos acceso al controlador allí. El controlador instala su agente allí. Instalamos el sistema operativo en las máquinas de destino para que el agente pueda funcionar allí. Creamos una tarea de migración: nos movemos de esta máquina virtual a esta máquina virtual y comenzamos el proceso de migración.
Es decir, los requisitos para el sitio, la fuente y el sitio receptor son solo la conectividad de red entre las máquinas virtuales y entre el controlador. No hay más condiciones. Esto permite realizar migraciones, probablemente, en cualquier escenario que se pueda imaginar.
¿Qué se deduce del hecho de que trabajamos a nivel de sistemas operativos? Esto es, por supuesto, la máxima compatibilidad. Inicialmente, había una opción para diseñar este software sin agentes, es decir, crear un producto que interactúe con la plataforma de virtualización, realizar las acciones necesarias a través de la API. Pero esto es bueno cuando se virtualizan una o dos plataformas, como era masivo en Rusia, hace dos o tres años. Pero en el mundo moderno, cuando el número de proveedores de virtualización en Rusia en este momento se cuenta por decenas, esto es imposible. Decidimos que trabajaríamos a nivel de sistema operativo.
El criterio principal para la posibilidad de migración es el sistema operativo compatible. La diapositiva muestra una lista de sistemas operativos. Estos son Ubuntu, CentOS, Debian y otros. Hay un error obsoleto en la diapositiva, no admitimos Windows 2008, solo a partir de la versión de Windows 2012. Las plataformas que se enumeran aquí son todas aquellas con las que somos compatibles, es decir, probamos directamente o tuvimos proyectos. Es decir, cada marca que se indica en esta lista está verificada, el escenario de migración pasó y, de hecho, lo más probable es que incluso estuviera en producción.
Se admiten todos los proveedores nacionales de virtualización. Tenemos una asociación tecnológica con varios proveedores rusos. El escenario de sustitución de importaciones va de la mano con la funcionalidad de nuestro producto.
Ventajas
El producto es completamente ruso, desarrollado por un equipo ruso de casi 90 personas. En esta etapa de desarrollo, es casi todo de ingeniería.
Todo se desarrolla prácticamente desde cero. No utilizamos soluciones de código abierto, este es completamente nuestro desarrollo, que consiste en que creamos nuestra propia tecnología para crear instantáneas para hacer una copia consistente de todos los datos en el disco. Tenemos una tecnología para transmitir estos datos y una tecnología de gestión.
El cliente, por defecto, no piensa mucho en cómo va a migrar. Esto se expresó principalmente en el hecho de que muchos proyectos de sustitución de importaciones en años anteriores tenían el carácter de pilotos o la creación de zonas de prueba. Es decir, se planeó crear un entorno de virtualización, implementarlo, probar servicios no críticos, evaluar la estabilidad del producto. En su mayor parte, son nuevos, se desarrollan dinámicamente. Y allí se movieron cargas, principalmente simples, aquellas que se pueden apagar y encender en un nuevo lugar en una semana. Ahora, cuando muchas empresas ya han decidido su camino, ya sea que permanezcan en VMware o en Hyper-V, o se muden a soluciones rusas, surge la tarea de escalar. Y las empresas se acercan al tema de cómo transportar aquellos sistemas de información que tienen un requisito estricto de tiempo de inactividad mínimo. Es decir, es necesario seleccionar una ventana para cambiar y evaluar cuántos datos se pueden perder al mismo tiempo.
Y aquí las empresas se enfrentan cada vez más al hecho de que los métodos de transferencia manual a través de copias de seguridad, a través de conversiones, etc., no son adecuados. Y, de hecho, probablemente, el escenario más popular para el uso de nuestro software es precisamente la migración de máquinas virtuales de servicios complejos.
Una solicitud típica se ve más o menos así: hay un sistema de información y es posible que se interrumpa durante no más de una hora. Hacer esto manualmente es prácticamente imposible. Es precisamente para esto que recurren a la ayuda de nuestras herramientas. La migración se realiza en línea. Esto significa que la máquina virtual que queremos mover continúa funcionando todo el tiempo con la sincronización. Es decir, elegimos alguna base de datos. Instalamos agentes en estas máquinas. Al mismo tiempo, necesitamos acceso completo. Se inicia la sincronización, que comienza a trasladarse a la plataforma de destino. Al mismo tiempo, el impacto en el rendimiento de las máquinas de origen es prácticamente nulo (2-4% de sobrecarga). Dado que durante el transporte podemos comprimir y cifrar los datos. Lo único que importan son dos cosas. Primero, el éxito de dicha migración depende de que transportemos datos a través de la red más rápido de lo que se acumulan. Y lo que también es importante es que, mientras estos datos se mueven, registramos todos sus cambios utilizando la tecnología Change Book Tracking. Debemos almacenar estos cambios en algún lugar del disco. Y, por regla general, para los sistemas de alta carga dentro de la "máquina virtual" de origen, es necesario conectar un disco adicional donde almacenaremos estos cambios durante la migración. Esto es lo único, probablemente, que requerirá intervención en el funcionamiento de la máquina virtual.
La migración se realiza en línea, se produce la primera sincronización y luego el sistema comienza a transferir los cambios y nos informa que está listo para la migración. Elegimos el tiempo de migración. Digamos que el jueves por la noche a una hora designada para el cambio. En este día, por la noche, se reúne un consejo: socios, jefe de proyecto, especialistas en TI, propietario del sistema de información.
Comienza el proceso de conmutación. Al mismo tiempo, detenemos los servicios de la máquina virtual, descargan sus datos en el disco. Realizamos la última pequeña sincronización. En la plataforma se enciende una nueva máquina virtual, en ella, si es necesario, se pueden cambiar los ajustes de red, todo esto se configura, en ella, si es necesario, se pueden añadir discos adicionales, en ella ya estarán instalados todos los controladores necesarios en la nueva plataforma.
Licencias
Existe una única licencia normal, Migrate Enterprise, que incluye todas las funciones necesarias que hablan sobre el cifrado del tráfico, la limitación del canal, la posibilidad de utilizar el registro CBT, un disco separado, etc. Las licencias se realizan por máquinas virtuales. Es decir, si desea transferir 400 máquinas virtuales, debe comprar 400 licencias. Existe una licencia separada Migrate Enterprise Desk para la transferencia de sistemas operativos de escritorio.
Si adquiere nuestro software a través del canal OEM, tenemos una serie de acuerdos especiales, ahora aparecerán nuevos acuerdos. Creo que dentro de un año la mayoría de los fabricantes de plataformas de virtualización podrán suministrar nuestra solución también dentro de sí mismos, allí habrá licencias que corresponderán a las licencias de la propia plataforma virtual. Es decir, si es por hosts, entonces a los hosts, si es por máquinas virtuales, entonces por máquinas virtuales.
Hay diferentes opciones de compra. La licencia también incluye un modo de soporte de garantía. Incluyen consultas sobre el rendimiento del sistema.
Si es necesario, puede utilizar el soporte técnico ampliado. Si el cliente decide que necesita migrar no manualmente, sino utilizar alguna herramienta para esto, entonces esto es para nosotros.
La migración a un nuevo sistema de virtualización es un proyecto complejo e integral en el que es necesario resolver muchas tareas diferentes. Si existe la posibilidad de tomar una pequeña parte de su presupuesto y cambiarlo por una solución lista para usar, es decir, quitarse el dolor de cabeza, generalmente aceptan no solo comprar el software, sino también el servicio. Tenemos servicios profesionales que brindamos por defecto, pero dentro del programa de socios hay socios que están listos para brindarlos también.
Los servicios son simples, esta es la implementación de un proyecto de migración, que ahora está siendo realizado por un grupo de 100 máquinas. Si la migración pasa por más de 100 máquinas, entonces, respectivamente, debe tomar un múltiplo de 100. Si es menos de 100, entonces debe tomar un paquete para 100 máquinas.
El cliente, por regla general, que ha decidido comprar software, en realidad ya quiere llegar hasta el final, es decir, para que todo se migre llave en mano. Y el soporte extendido no se compra con frecuencia, sino que generalmente se toma de inmediato un servicio profesional para que podamos compartir nuestra propia competencia.
MIND Guard
Tenemos una tecnología para crear instantáneas, tenemos una tecnología para crear una copia, es decir, enviamos estas instantáneas a una nueva plataforma. Y si este proceso se detiene y se cambia la máquina, será una migración. Una vez pensamos, ¿no detener este proceso, sino simplemente mantener una copia en un sitio remoto todo el tiempo? Aparece una herramienta de tolerancia a fallos. Y aún no lo hemos lanzado oficialmente, pero hemos lanzado la primera versión del producto MIND Guard, que hace tres cosas.
Primero, realiza la replicación asíncrona de datos de una máquina virtual a otra. Luego, соответственно, rastrea y administra este proceso. Y en caso de que ocurra alguna falla en la máquina de origen, por ejemplo, el centro de datos no está disponible, los servidores se quemaron, etc., realizamos la conmutación. Es decir, automatizamos el lanzamiento de una copia de emergencia. Esto se llama tolerancia a desastres.
¿Cómo funciona? Primero, desde el servidor primario al sitio de respaldo se realiza la copia asíncrona de datos. Es decir, primero la copia primaria y luego la instalación de cambios. Teóricamente, en condiciones ideales, es decir, cuando hay un canal de comunicación amplio, discos rápidos, servidores rápidos, se puede proporcionar hasta 5 segundos de RPO. La pérdida de datos en 5 segundos se considera aceptable para muchos clientes.
El nivel de consistencia es un dispositivo de almacenamiento en bloques dentro del sistema operativo invitado, es decir, los datos que están en el disco. Porque los datos que están en la memoria de la máquina virtual se perderán.
Segundo, la administración, hay un controlador que monitorea constantemente el estado del sitio. El controlador de respaldo, соответственно, se encuentra en el sitio de respaldo. A través del controlador se realiza el monitoreo de parámetros.
Si ocurre un accidente, entonces el controlador pasa al modo de posibilidad de conmutación. La conmutación no es automática. Соответственно, el operador que toma la decisión de que el sitio principal realmente ha muerto, puede realizar la conmutación manual. Inicia manualmente un plan de emergencia, que implica encender la máquina en el sitio, asignar direcciones IP, ejecutar scripts o a través de interfaces API.
Toda la funcionalidad de todos los productos que están disponibles a través de la interfaz gráfica, están disponibles a través de REST API, esto permite que este producto se ajuste a sistemas más complejos. Por ejemplo, en el panel de control del servicio de un proveedor de nube, que brinda servicios de tolerancia a desastres para sus clientes.
Failover
Este producto acaba de salir. Está en las primeras etapas, por lo que ahora podemos garantizar el trabajo solo con una serie de restricciones.
Tareas que realiza Guard. Les recuerdo que nuestra arquitectura es de plataforma. Instalamos agentes, no requerimos soporte de la plataforma subyacente. La red de almacenamiento de datos tampoco nos interesa.
Primero, la posibilidad de organizar la replicación entre diferentes fabricantes de sistemas de almacenamiento. La posibilidad de hacerlo entre diferentes tipos de plataformas. Un escenario interesante que se está trabajando actualmente en los primeros proyectos de producción son clientes que temen trasladar sus sistemas a nuevas plataformas y desean esperar a un estado más estable, a nuevos productos rusos. Se les propone trasladar el sistema de información y configurar la replicación en sentido inverso a la antigua plataforma fiable. De esta manera, se cumplen ciertos planes establecidos para los responsables de TI. Y, por otro lado, hay un seguro. En caso de que algo salga mal, por ejemplo, que un parche no se haya aplicado, que un administrador se haya equivocado, etc. Se puede volver a Hyper-V y continuar trabajando, mientras se repara el clúster, muchos lo hacen incluso dentro de un mismo centro de datos.
De nuevo, algunas aplicaciones, especialmente las críticas, donde no puede haber ninguna pérdida de datos, suelen tener medios de clustering. Para ellas, nuestras herramientas no son muy necesarias. Pero para los sistemas de información de aplicaciones que no tienen medios integrados, donde la pérdida de unos segundos o minutos de datos no es muy crítica, podemos proporcionar un sistema de resistencia a desastres para cualquier aplicación de este tipo.
Limitaciones
Primero. Actualmente, solo admitimos el sistema operativo Linux. Windows está en la cola. En las próximas versiones se implementará. Segundo. Podemos gestionar la situación de Failover, cuando la plataforma principal "se cae". Cambiamos a la reserva, pero actualmente no tenemos automatización del proceso de retorno a la plataforma principal o a una nueva. No decimos que no se pueda hacer. Se puede volver a aplicar Guard, crear un par manualmente y enviar la máquina en la nueva dirección. Pero actualmente no hay automatización del proceso, aunque está prevista. Y, de nuevo, está prevista la implementación de algo importante para este tipo de soluciones: las pruebas. Al igual que con las herramientas de copia de seguridad, las pruebas son importantes, porque prácticamente comprobamos la migración de inmediato. Sin embargo, actualmente las pruebas solo se pueden realizar manualmente.
En la diapositiva se muestra la misma lista de compatibilidad, pero aquí falta una columna con Windows. Se espera soporte, pero está previsto para el segundo trimestre de 2024. Esto se debe a que estamos creando nuestra propia tecnología para crear snapshots en Windows.