Hace aproximadamente 7 a帽os, los primeros proyectos se trasladaron a nuestra nube de manera simple y sin pretensiones. Las im谩genes de las m谩quinas virtuales se cargaron en un servidor FTP, o se llevaron a los 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 un d铆a o dos (o no otras opciones), entonces es posible. Pero si el tiempo de inactividad es de un m谩ximo de una hora, entonces este m茅todo no funcionar谩. Hoy les dir茅 qu茅 herramientas lo ayudar谩n a migrar a la nube con un tiempo de inactividad m铆nimo y c贸mo funciona el proceso de migraci贸n con nosotros.
Migraci贸n con Veeam Backup and Replication
Todos conocen 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 con virtualizaci贸n privada a nuestra nube. Las m谩quinas virtuales del cliente se replican en nuestro vCenter, despu茅s de lo cual el ingeniero las agrega a vCloud Director.
La replicaci贸n primaria se realiza en una m谩quina virtual habilitada. A la hora acordada, la m谩quina en el lado del cliente se apaga. La replicaci贸n comienza nuevamente para transferir los cambios que ocurrieron desde la primera replicaci贸n. Despu茅s de eso, la m谩quina virtual comienza ya en nuestra nube.
Por lo general, desde el momento en que la m谩quina se apaga en la infraestructura del cliente y hasta el momento en que se enciende, no pasa m谩s de media hora, sino m谩s bien 15-20 minutos, en nuestra nube.
Al mismo tiempo, la m谩quina virtual original permanece en el sitio del cliente. Si de repente algo sale mal, siempre puede retroceder y encenderlo. Para el cliente, este m茅todo tambi茅n es conveniente porque no requiere Veeam de 茅l.
Caso 1
El cliente ten铆a su propia infraestructura virtual basada en VMware: 40 m谩quinas virtuales con una capacidad de 30 Tb. El equipo en el que se implement贸 el cl煤ster ya est谩 desactualizado, y el cliente decidi贸 no involucrarse en la compra de uno nuevo y pasar a una nube p煤blica. El requisito de tiempo de inactividad de los sistemas cr铆ticos no era m谩s de una hora. Veeam Replication fue elegido como herramienta. La ventaja tambi茅n fue que el proveedor de Internet del cliente estaba presente en nuestro centro de datos, lo que nos permiti贸 organizar un buen canal. La migraci贸n tom贸 aproximadamente un mes, mientras que el cambio fue simple, tom贸 hasta 30 minutos para un grupo de m谩quinas virtuales.Migre con Veeam Cloud Connect
Veeam Cloud Connect es una herramienta que lo ayuda a configurar la replicaci贸n de m谩quinas virtuales y ejecutar r茅plicas en la nube del proveedor de servicios. Despu茅s de la actualizaci贸n en
2019 , se hizo posible replicar m谩quinas virtuales directamente en vCloud Director. La 煤nica condici贸n es que en el lado del cliente, su Veeam Backup and Replication debe implementarse al menos en la versi贸n 9. En resumen (una versi贸n detallada est谩
aqu铆 ), todo el proceso es el siguiente.
VCloud Director crea una organizaci贸n con los recursos y redes necesarios. En Veeam Cloud Connect, creamos una cuenta, el cliente se conecta a ella desde nuestro Veeam B&R, selecciona el proveedor y la organizaci贸n de DataLine, y configura tareas para la replicaci贸n. Adem谩s del hecho de que durante dicha migraci贸n, el tiempo de inactividad ser谩 de 15 a 20 minutos, el cliente no depende del soporte t茅cnico del proveedor y gestiona todo el proceso de forma independiente: crea tareas de replicaci贸n, replicaci贸n en s铆, apaga las m谩quinas y comienza su inicio en un nuevo sitio.
Caso 2
La infraestructura del cliente desde donde se planific贸 la migraci贸n estaba ubicada en Bielorrusia. Era necesario transportar 90 m谩quinas virtuales con un volumen total de 27 TB, a pesar de que el canal de Internet era de 100 Mbps. Si realiza una copia de seguridad e inmediatamente la carga en nuestra nube, entonces, para algunas m谩quinas virtuales, esto tomar铆a varios d铆as. Durante este tiempo, un gran delta crecer铆a en la VM, y esto ya podr铆a afectar negativamente el rendimiento de las m谩quinas o, peor a煤n, el lugar en el almac茅n de datos se agot贸. Actuaron de la siguiente manera: primero, el cliente realiz贸 una copia de seguridad completa local y nos transfiri贸 una copia de la misma en la nube a trav茅s de Veeam Cloud Connect. Luego hizo y arroj贸 el incremento a la nube. La m谩quina virtual original continu贸 funcionando. Despu茅s de apagar la VM, el cliente realiz贸 otro incremento y tambi茅n lo transfiri贸 a la nube. De nuestro lado, implementamos una m谩quina virtual desde una copia de seguridad completa, y luego lanzamos dos incrementos sobre ella. Tal esquema nos permiti贸 minimizar el tiempo de inactividad a 2 horas al cambiar a nuestro sitio.Migraci贸n con VMware vCloud Availability
En marzo de este a帽o, VMware lanz贸 vCloud Availability 3.0, que permite que las m谩quinas virtuales migren entre diferentes nubes (vCloud Director - vCloud Director) y desde soportes de virtualizaci贸n de clientes privados a la nube (vCenter - vCloud Director). La conveniencia principal es la integraci贸n con la interfaz de vCloud Director. Esto simplifica enormemente la gesti贸n de la replicaci贸n y minimiza el tiempo de inactividad al cambiar.
Con esta herramienta, migramos a uno de los clientes de nuestra nube de Mosc煤 a nuestra nube en San Petersburgo. Era necesario transportar 18 m谩quinas virtuales con una capacidad total de 14 TB. Para el cliente, se cre贸 una organizaci贸n en la nube de San Petersburgo y se organizaron las redes necesarias. Luego, desde la interfaz de vCloud Director, el cliente cambi贸 a la configuraci贸n de Disponibilidad de vCloud, cre贸 tareas de replicaci贸n y cambi贸 al sitio de San Petersburgo en un momento conveniente. El tiempo de inactividad al cambiar fue de 12 minutos.
El esquema de migraci贸n entre las nubes DataLine en San Petersburgo y Mosc煤.VCloud Availability tiene un mecanismo para migrar m谩quinas virtuales de un sitio cliente a nuestra nube. Para hacer esto, se implementa una aplicaci贸n especial de vCloud Availability en el cliente vCenter. Despu茅s de una configuraci贸n simple, est谩 conectado a la nube y se configuran las tareas de migraci贸n. El cliente tambi茅n gestiona de forma independiente todo el proceso, y el tiempo de migraci贸n se minimiza.
Un diagrama de la 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 otro art铆culo.
Prepar谩ndose para la migraci贸n
Para seleccionar una herramienta y continuar con la migraci贸n, debe decidir sobre los siguientes puntos:
驴De d贸nde estamos migrando? Si est谩 migrando desde una soluci贸n privada, tiene total libertad para elegir herramientas. Si se muda del proveedor, entonces es m谩s dif铆cil. Lo m谩s probable es que la conexi贸n de la infraestructura de los dos proveedores y simplemente arrastrar la VM falle por razones de seguridad. A veces, el proveedor, que el cliente va a rechazar, comienza a ser completamente da帽ino y lleva tiempo. Puede dejar el proveedor a la antigua usanza: cargando la VM en discos y FTP o migrando a nivel de aplicaci贸n. El nombre de este 煤ltimo es arbitrario, y se parece a esto.
Caso 3
Era necesario migrar el sistema SAP del cliente desde un proveedor europeo: 34 m谩quinas virtuales con un volumen de 54 Tb. Se asignaron recursos al cliente en nuestra nube. Entre nosotros y la infraestructura del proveedor europeo se organiz贸 la conectividad de red. Los servidores de aplicaciones se volvieron a implementar, con la acumulaci贸n de las configuraciones necesarias. Grandes bases de datos migraron mediante la carga de copias de seguridad en nuestra nube. Luego, se configur贸 la replicaci贸n entre las bases de datos en nuestro sitio y el sitio fuente. A la hora acordada, cambiamos a las bases de datos en nuestra nube.La cantidad de datos y el canal de Internet. Por lo general, le pedimos al cliente que proporcione la descarga en los sistemas con par谩metros de memoria, CPU, discos. Estimamos si el canal es suficiente para enviar directamente r茅plicas o copias de seguridad de m谩quinas virtuales.
V谩lido simple. Para diferentes sistemas y, en consecuencia, m谩quinas virtuales, puede ser diferente dependiendo de su criticidad para el negocio. Por lo general, un cliente viene con requisitos listos para el tiempo de inactividad durante la migraci贸n, y en base a esto elegimos la herramienta y el plan de migraci贸n correctos. Intentamos planificar el cambio final a noche o fin de semana, de modo que incluso un ligero tiempo de inactividad no sea perceptible para los usuarios finales del cliente.
Seg煤n estos datos, puede elegir una herramienta y continuar con la migraci贸n en s铆. Esto es lo que pasa despu茅s.
- Configuraci贸n de 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 usa Veeam Backup and Replication, este es un canal dedicado, menos com煤nmente un canal VPN. Si Veeam Cloud Connect, entonces todo pasa por Internet o el mismo canal dedicado.
Luego, la red se configura para la VM en la nube. Los autom贸viles generalmente se mueven en grupos y m谩s de un d铆a. Despu茅s de que las m谩quinas virtuales nos fueron transferidas y lanzadas, deber铆an interactuar con las m谩quinas que a煤n permanecen en el sitio de inicio. - Calendario de migraciones. Cuando hay muchos autom贸viles, es razonable dividirlos en grupos y transportarlos en lotes. Junto con el cliente, acordamos un plan en el que prescribimos cu谩ndo y qu茅 m谩quinas se mueven y cu谩ndo se realizar谩 la replicaci贸n final y el cambio a un nuevo sitio.
- Prueba de migraci贸n. Migramos la m谩quina virtual de prueba y verificamos si todo est谩 configurado correctamente: conectividad de red entre sitios, la disponibilidad de la m谩quina virtual para m谩quinas en el sitio de origen, derechos de cuenta y m谩s. Tal prueba ayuda a evitar problemas durante la etapa de migraci贸n de combate.
Eso es todo para m铆. Haga preguntas en los comentarios y hable sobre su experiencia de migraci贸n.