Hace unos 7 años, los primeros proyectos se trasladaban a nuestra nube de manera sencilla y sin complicaciones. Las imágenes de las máquinas virtuales se cargaban en un servidor FTP o se traían en discos duros. Luego, a través de un servidor de importación especial, se subían las máquinas virtuales a la nube.
Si para el cliente no es un problema apagar la virtualización durante uno o dos días (o no hay otras opciones), se puede hacer de esa manera. Pero si el tiempo de inactividad debe ser como máximo de una hora, este método no sería adecuado. Hoy hablaré sobre las herramientas que pueden ayudar a migrar a la nube con el mínimo tiempo de inactividad y sobre cómo funciona el proceso de migración con nosotros.
Migración utilizando Veeam Backup and Replication
Veeam Backup and Replication es conocido por ser una herramienta para la creación de copias de seguridad y réplicas. Lo usamos para migrar entre nuestras plataformas y para transferir clientes de virtualización privada a nuestra nube. Las máquinas virtuales del cliente se replican en nuestro vCenter, luego un ingeniero las agrega al vCloud Director.
La replicación inicial se lleva a cabo con la máquina virtual encendida. En un momento acordado, se apaga la máquina del lado del cliente. La replicación se reinicia para trasladar los cambios que ocurrieron desde la primera replicación. Después de eso, la máquina virtual se inicia en nuestra nube.
Generalmente, desde el momento en que la máquina se apaga en la infraestructura del cliente hasta que se enciende en nuestra nube, pasa un tiempo no mayor de media hora, y más bien de 15 a 20 minutos.
A su vez, en la instalación del cliente queda la máquina virtual original. Si algo sale mal, siempre se puede volver a encenderla. Para el cliente, este método también es conveniente ya que no requiere la presencia de Veeam.
Caso 1
El cliente tenía su propia infraestructura virtual basada en VMware: 40 máquinas virtuales con un volumen de 30 TB. El equipo en el que se había desplegado el clúster ya estaba desactualizado, y el cliente decidió no preocuparse por la compra de nuevo hardware y mudarse a la nube pública. El requisito para el tiempo de inactividad de sistemas críticos era de no más de una hora. Como herramienta, se eligió Veeam Replication. También fue una ventaja que el proveedor de Internet del cliente estaba presente en nuestro centro de datos, lo que permitió organizar un buen canal. La migración tomó alrededor de un mes, y el tiempo de inactividad durante el cambio fue de hasta 30 minutos para un grupo de máquinas virtuales.
Migración a través de Veeam Cloud Connect
Veeam Cloud Connect es una herramienta que ayuda a configurar la replicación de máquinas virtuales y a ejecutar réplicas en la nube del proveedor de servicios. Tras la actualización en el año, se agregó la capacidad de replicar máquinas virtuales directamente en vCloud Director. La única condición es que el cliente debe tener desplegado su propio Veeam Backup and Replication en versión 9 o superior. En resumen (la versión detallada ), el proceso se ve de la siguiente manera.
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 el proveedor DataLine y la organización, configura las tareas para la replicación. Además, durante esta migración, el tiempo de inactividad será de 15 a 20 minutos, y el cliente no depende del soporte técnico del proveedor, gestionando todo el proceso de manera autónoma: configura las tareas de replicación, la replicación en sí misma, apaga las máquinas y las reinicia en el nuevo sitio.
Caso 2
La infraestructura del cliente, desde donde se planeaba la migración, estaba ubicada en Bielorrusia. Era necesario trasladar 90 VM con un volumen total de 27 TB, teniendo en cuenta que el canal de Internet era de 100 Mbit/s. Si se hiciera una copia de seguridad y se subiera inmediatamente a nuestra nube, para algunas VM esto tomaría varios días. Durante este tiempo, la VM generaría una gran delta, lo que podría afectar negativamente el rendimiento de las máquinas o, lo que es peor, podría agotarse el espacio en el datastorage. El proceso fue el siguiente: primero, el cliente realizó una copia de seguridad completa localmente y trasladó una copia a nuestra nube a través de Veeam Cloud Connect. Luego, realizó y trasladó un incremento a la nube. La máquina virtual original continuó funcionando. Después de apagar la VM, el cliente hizo otro incremento y también lo trasladó a la nube. De nuestra parte, desplegamos la máquina virtual desde la copia de seguridad completa y luego aplicamos los dos incrementos. Este esquema permitió reducir el tiempo de inactividad a 2 horas al cambiar a nuestra plataforma.
Migración mediante VMware vCloud Availability
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 los entornos de virtualización privados del cliente a la nube (vCenter – vCloud Director). La principal facilidad es la integración con la interfaz de vCloud Director. Esto simplifica significativamente el proceso de gestión de replicación y minimiza el tiempo de inactividad durante la conmutación.
Con esta herramienta, migramos a uno de nuestros clientes desde nuestra nube de Moscú a nuestra nube en San Petersburgo. Era necesario trasladar 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. Luego, desde la interfaz de vCloud Director, el cliente accedió a la configuración de vCloud Availability, creó tareas de replicación y se conmutó a la plataforma de San Petersburgo en un momento conveniente para él. El tiempo de inactividad durante la conmutación fue de 12 minutos.
Diagrama de migración entre las nubes de DataLine en San Petersburgo y Moscú.
En vCloud Availability hay un mecanismo para migrar VMs desde la plataforma del cliente a nuestra nube. Para esto, se despliega un appliance especial de vCloud Availability en el vCenter del cliente. Después de una configuración sencilla, se conecta a la nube y se configuran las tareas de migración. El cliente también gestiona todo el proceso de forma independiente, y el tiempo de migración se minimiza.
Diagrama de migración de máquinas virtuales desde una instalación privada a la nube.
VMware vCloud Availability tiene muchos otros escenarios de uso, pronto hablaremos de ellos en un artículo separado.
Preparación para la migración
Para elegir la herramienta y comenzar la migración, es necesario aclarar los siguientes puntos:
De dónde migramos. Si está migrando desde una solución privada, tiene total libertad en la elección de herramientas. Si se está mudando de un proveedor, la situación es más compleja. Lo más probable es que no se pueda vincular las infraestructuras de dos proveedores y simplemente arrastrar la VM debido a consideraciones de seguridad. A veces, el proveedor del que el cliente desea desvincularse comienza a poner obstáculos y retrasa el proceso. La migración desde un proveedor se puede hacer de la manera antigua: exportando la VM a discos y utilizando FTP o migrando a nivel de la aplicación. El nombre de este último es condicional y funciona aproximadamente así.
Caso 3
Era necesario migrar el sistema SAP del cliente de un proveedor europeo: 34 VM con un volumen de 54 TB. Se asignaron recursos en nuestra nube al cliente. Se estableció conectividad de red entre nosotros y la infraestructura del proveedor europeo. Los servidores de aplicaciones se desplegaron nuevamente, aplicando las configuraciones necesarias. Las grandes bases de datos se migraron mediante la carga de respaldos en nuestra nube. Luego, se configuró la replicación entre las bases de datos en nuestra y la plataforma original. En el momento acordado, cambiamos a las bases de datos en nuestra nube.
Volumen de datos y ancho de banda de Internet. Normalmente pedimos al cliente que proporcione una exportación de los sistemas con los parámetros de memoria, CPU y discos. Evaluamos si el canal es suficiente para enviar directamente las réplicas o los respaldos de las máquinas virtuales.
Downtime aceptable. Para diferentes sistemas y, por lo tanto, máquinas virtuales, puede variar dependiendo de su criticidad para el negocio. Generalmente, el cliente llega con requisitos predefinidos sobre el tiempo de inactividad durante la migración, y con base en esto elegimos la herramienta adecuada y el plan de migración. Intentamos programar el cambio final durante la noche o los fines de semana, para que incluso un pequeño período de inactividad no sea perceptible para los usuarios finales del cliente.
A partir de estos datos, se puede elegir la herramienta y proceder con 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. A través de esta red se copiarán las máquinas virtuales. Si se utiliza Veeam Backup and Replication, será un canal dedicado, y menos frecuentemente, un canal VPN. Si se utiliza Veeam Cloud Connect, todo va a través de Internet o el mismo canal dedicado.
Luego, se configura la red para las VM en la nube. Las máquinas normalmente se trasladan en grupos y no en un solo día. Después de que las VM se transfieran a nosotros y se inicien, deben interactuar con las máquinas que aún permanecen en la plataforma original.
- Calendario de migración. Cuando hay muchas máquinas, es razonable dividirlas en grupos y transportarlas por lotes. Junto con el cliente, acordamos un plan en el que detallamos cuándo y qué máquinas se trasladan y cuándo se realizará la replicación final y el cambio a la nueva plataforma.
- Migración de prueba. Migramos la máquina virtual de prueba y verificamos que todo esté configurado correctamente: conectividad de red entre las plataformas, accesibilidad de la máquina virtual desde las máquinas en la plataforma original, derechos de la cuenta y demás. Esta prueba ayuda a evitar contratiempos en la fase de migración en producción.
Eso es todo de mi parte. En los comentarios, no duden en hacer preguntas y compartir su experiencia de migración.
Fuente: habr.com
