Hace unos 7 años, los primeros proyectos se trasladaron a nuestra nube de forma sencilla y sin pretensiones. Las imágenes de las máquinas virtuales se cargaron en un servidor FTP o se entregaron en discos duros. Luego, a través de un servidor de importación especial, las máquinas virtuales se cargaron en la nube.
Si no es un problema para el cliente apagar la máquina virtual durante uno o dos días (o no hay otras opciones), entonces puede hacerlo. Pero si el tiempo de inactividad debe ser de un máximo de una hora, entonces este método no funcionará. Hoy te contaré qué herramientas te ayudarán a migrar a la nube con un tiempo de inactividad mínimo y cómo funciona nuestro proceso de migración.
Migración con Veeam Backup and Replication
Todo el mundo conoce Veeam Backup and Replication como una herramienta para crear copias de seguridad y réplicas. Lo usamos para la migración entre nuestros sitios y para transportar clientes desde la virtualización privada a nuestra nube. Las máquinas virtuales del cliente se replican en nuestro vCenter, luego de lo cual el ingeniero las agrega a vCloud Director.
La replicación primaria ocurre en una máquina virtual encendida. A la hora acordada, la máquina del lado del cliente se apaga. La replicación se ejecuta nuevamente para transferir los cambios que se produjeron desde la primera replicación. Después de esto, la máquina virtual se inicia en nuestra nube.
Normalmente, desde que se apaga la máquina en la infraestructura del cliente hasta que se enciende en nuestra nube no pasa más de media hora, sino entre 15 y 20 minutos.
En este caso, la máquina virtual original permanece en el sitio del cliente. Si de repente algo sale mal, siempre puedes retroceder y encenderlo. Este método también es conveniente para el cliente porque no requiere que tenga Veeam.
Caso 1
El cliente tenía su propia infraestructura virtual basada en VMware: 40 VM con una capacidad de 30 TB. El equipo en el que se implementó el clúster ya estaba desactualizado y el cliente decidió no molestarse en comprar otros nuevos y se trasladó a la nube pública. El tiempo de inactividad requerido para los sistemas críticos no fue más de una hora. Se eligió Veeam Replication como herramienta. Otra ventaja fue que el proveedor de Internet del cliente estaba presente en nuestro centro de datos, lo que permitió organizar un buen canal. La migración duró aproximadamente un mes y el tiempo de inactividad durante el cambio fue de hasta 30 minutos por grupo de máquinas virtuales.
Migrar con Veeam Cloud Connect
Veeam Cloud Connect es una herramienta que le ayuda a configurar la replicación de máquinas virtuales y lanzar réplicas en la nube del proveedor de servicios. Después de actualizar a año, fue posible replicar máquinas virtuales directamente en vCloud Director. La única condición es que en el lado del cliente, Veeam Backup and Replication debe estar implementado al menos la versión 9. En resumen (versión detallada ), entonces todo el proceso se ve así.
En vCloud Director se crea una organización con los recursos y redes necesarios. En Veeam Cloud Connect, creamos una cuenta, el cliente se conecta a ella desde su Veeam B&R, selecciona un proveedor y una organización de DataLine y configura las tareas para la replicación. Además del hecho de que durante dicha migración el tiempo de inactividad será de entre 15 y 20 minutos, el cliente no depende de ninguna manera del soporte técnico del proveedor y gestiona todo el proceso de forma independiente: crea tareas de replicación, la replicación misma, apaga las máquinas y las inicia en el nuevo sitio.
Caso 2
La infraestructura del cliente desde donde se planeó la migración estaba ubicada en Bielorrusia. Fue necesario transportar 90 VM con un volumen total de 27 TB, a pesar de que el canal de Internet era de 100 Mbit/seg. Si realiza una copia de seguridad y la carga inmediatamente en nuestra nube, para algunas máquinas virtuales tardaría varios días. Durante este tiempo, habría crecido un gran delta en la VM, y esto podría tener un impacto negativo en el rendimiento de las máquinas o, peor aún, se habría agotado el espacio en el almacén de datos. Procedimos de la siguiente manera: primero, el cliente realizó una copia de seguridad completa local y transfirió una copia a nuestra nube a través de Veeam Cloud Connect. Luego hice y transferí el incremento a la nube. La máquina virtual original continuó ejecutándose. Después de apagar la VM, el cliente realizó otro incremento y también la transfirió a la nube. Por nuestra parte, implementamos una máquina virtual a partir de una copia de seguridad completa y luego le aplicamos dos incrementos. En última instancia, este esquema hizo posible minimizar el tiempo de inactividad a 2 horas al cambiar a nuestro sitio.
Migración con disponibilidad de VMware vCloud
En marzo de este año, VMware lanzó vCloud Availability 3.0, que permite migrar máquinas virtuales entre diferentes nubes (vCloud Director - vCloud Director) y desde puestos de virtualización de clientes privados a la nube (vCenter - vCloud Director). La principal comodidad es la integración con la interfaz de vCloud Director. Esto simplifica enormemente el proceso de gestión de replicación y minimiza el tiempo de inactividad durante las conmutaciones.
Usando esta herramienta, migramos uno de los clientes de nuestra nube de Moscú a nuestra nube en San Petersburgo. Fue necesario transportar 18 máquinas virtuales con una capacidad total de 14 TB. Se creó una organización para el cliente en la nube de San Petersburgo y se organizaron las redes necesarias. A continuación, desde la interfaz de vCloud Director, el cliente accedió a la configuración de disponibilidad de vCloud, creó trabajos de replicación y en el momento que más le convenía cambió al sitio de San Petersburgo. El tiempo de inactividad durante el cambio fue de 12 minutos.
Esquema de migración entre nubes DataLine en San Petersburgo y Moscú.
vCloud Availability tiene un mecanismo para migrar VM desde el sitio del cliente a nuestra nube. Para hacer esto, se implementa una aplicación especial de disponibilidad de vCloud en el vCenter del cliente. Después de una configuración simple, se conecta a la nube y configura las tareas de migración. El cliente también gestiona todo el proceso de forma independiente y el tiempo de migración se mantiene al mínimo.
Esquema de migración de máquinas virtuales desde una instalación privada a la nube.
VMware vCloud Availability tiene muchos otros casos de uso; pronto hablaremos de ellos en un artículo aparte.
Preparándose para la migración
Para elegir una herramienta y comenzar a migrar, debe decidir sobre los siguientes puntos:
¿Desde dónde migramos? Si está migrando desde una solución privada, tendrá total libertad para elegir herramientas. Si se aleja de su proveedor, entonces es más complicado. Lo más probable es que vincular las infraestructuras de dos proveedores y simplemente arrastrar y soltar una VM no funcione por razones de seguridad. A veces, el proveedor que el cliente está a punto de rechazar comienza a ser travieso y gana tiempo. Puede alejarse del proveedor a la antigua usanza: cargando máquinas virtuales en discos y FTP, o migrando a nivel de aplicación. El nombre de este último es condicional y se parece a esto.
Caso 3
Fue necesario migrar el sistema SAP del cliente desde un proveedor europeo: 34 VM con una capacidad de 54 TB. Al cliente se le asignaron recursos en nuestra nube. Se organizó la conectividad de red entre nosotros y la infraestructura del proveedor europeo. Los servidores de aplicaciones se volvieron a implementar y se renovaron las configuraciones necesarias. Se migraron grandes bases de datos mediante la carga de copias de seguridad a nuestra nube. A continuación, se configuró la replicación entre las bases de datos de nuestro sitio y el original. A la hora acordada, cambiamos a bases de datos en nuestra nube.
Volumen de datos y canal de Internet. Generalmente le pedimos al cliente que proporcione una carga por sistema con los parámetros de memoria, CPU y disco. Evaluamos si el canal es suficiente para enviar directamente réplicas o respaldos de máquinas virtuales.
Tiempo de inactividad aceptable. Para diferentes sistemas y, en consecuencia, máquinas virtuales, puede ser diferente según su importancia comercial. Por lo general, el cliente viene con requisitos ya preparados para el tiempo de inactividad durante la migración y, en base a esto, seleccionamos la herramienta y el plan de migración adecuados. Intentamos programar el cambio final por la noche o los fines de semana para que los usuarios finales del cliente no noten ni siquiera un pequeño tiempo de inactividad.
Según estos datos, puede seleccionar una herramienta y comenzar la migración. Esto es lo que sucede a continuación.
- Configuración de la conectividad de red. Organizamos la conectividad de red entre nuestra nube y la infraestructura del cliente. Las máquinas virtuales se copiarán a través de esta red. Si se utiliza Veeam Backup and Replication, entonces este es un canal dedicado, con menos frecuencia un canal VPN. Si Veeam Cloud Connect, entonces todo se realiza a través de Internet o del mismo canal dedicado.
Luego, la red se configura para la VM en la nube. Los coches suelen circular en grupos y durante más de un día. Una vez que las máquinas virtuales nos llegan y se ejecutan, deben comunicarse con las máquinas que aún permanecen en el sitio original.
- Calendario de migración. Cuando hay muchos coches, tiene sentido dividirlos en grupos y transportarlos en lotes. Junto con el cliente, acordamos un plan en el que especificamos cuándo y qué máquinas se trasladarán y cuándo se realizará la replicación final y el cambio al nuevo sitio.
- Migración de prueba. Migramos la máquina virtual de prueba y comprobamos si todo está configurado correctamente: conectividad de red entre sitios, disponibilidad de la máquina virtual para las máquinas en el sitio de origen, derechos de cuenta, etc. Esta prueba ayuda a evitar problemas en la etapa de migración de combate.
Eso es todo para mí. En los comentarios, haz preguntas y cuéntanos sobre tu experiencia migratoria.
Fuente: habr.com
