Planificación de las oleadas de migración de servidores virtuales en IBM Cloud VPC

Planifica las fases de migració IBM Cloud VPC, analizando las dependencias de las máquinas virtuales ( VM ), estimando la velocidad y programando las ventanas de transición para las pilas de aplicaciones.

Planificación de la dependencia

Antes de iniciar las olas de migración, debe asignar las siguientes dependencias de la aplicación:

Por niveles:

  • Nivel web → Nivel aplicación
  • Nivel de aplicación → Nivel de base de datos
  • Nivel de base de datos → Almacenamiento y servicios compartidos

Aplicación cruzada:

  • Autenticación
  • Supervisión
  • Copia de seguridad
  • Agregación de registros
  • DNS y NTP

Herramientas para el descubrimiento:

  • VMware vRealize Network Insight ( ) vRNI
  • Herramientas de mapeo de dependencias de aplicaciones
  • Análisis del flujo de la red
  • Documentación manual de los propietarios de las aplicaciones

Para cada servidor virtual, registre la siguiente información en su plan de migración:

  • Dependencias de entrada
  • Dependencias salientes
  • Recursos compartidos

Diseño de la onda de migración de prueba

Su primera oleada de migración es la oleada de prueba (piloto). Para llevar a cabo una oleada de pruebas con éxito, debe atenerse a la siguiente información:

Representación adecuada de sus servidores virtuales:

  • Servidor virtual « Linux » de un solo disco
  • Servidor virtual « Linux » con varios discos
  • Servidor virtual Windows monodisco
  • Servidor virtual Windows multidisco
  • Aplicación con dependencias (aplicación de 3 niveles)

Utilice opciones de "riesgo mínimo":

  • Implemente la migración en un entorno que no sea de producción. O bien, utilizar un entorno de producción que tenga grandes ventanas de mantenimiento.
  • Conozca el procedimiento de reversión de sus aplicaciones.

Realice una migración completa:

  • Prueba completa de principio a fin de los métodos elegidos
  • Calendario de migración de notas frente a calendario estimado
  • Descubrimiento de problemas no detectados en las pruebas

Criterios de éxito de la migración:

  • Todos los servidores virtuales se inician correctamente
  • Las aplicaciones funcionan correctamente
  • Conectividad de red verificada
  • Los resultados cumplen o superan los valores de referencia
  • Sin pérdida ni corrupción de datos
  • La documentación de la migración es completa y precisa

Directrices sobre la estructura de las olas

Agrupación basada en subredes:

Recuerde que no puede extender una subred entre VMware y VPC. Lo que significa que tienes que realizar las siguientes acciones:

  • Agrupar servidores virtuales por subred
  • Migre subredes enteras en una sola oleada o sepa que necesita volver a IP algunos servidores virtuales
  • Planifique con antelación la asignación de subredes a VPC

Agrupación de pilas de aplicaciones para aplicaciones multinivel:

  • Si es posible, migre toda la pila de una sola vez.
  • Si la migración es demasiado grande, migre primero la base de datos, luego las aplicaciones y así sucesivamente.
  • Mantén la conectividad entre los niveles migrados y los no migrados mediante IBM Cloud Transit Gateway.

Agrupación de pilas de aplicaciones para una secuenciación consciente de las dependencias:

  • Migre primero los servicios de infraestructura (DNS, supervisión, copia de seguridad).
  • Migrar los servicios compartidos antes que las aplicaciones que necesitan.
  • Considera los efectos de cada ola y el impacto si falla.

Capacidad de migración paralela:

El método 3 Transferencia en red en directo(Recomendado para Escala) destaca aquí:

  • Aprovisionar varias instancias de servidores virtuales de trabajadores
  • Migración simultánea de varios servidores virtuales
  • Limitado por el ancho de banda de la red y los recursos del servidor virtual del trabajador
  • Típico: 4-8 migraciones simultáneas por instancia de servidor virtual de trabajador

Estructura de ejemplo de onda de prueba

El siguiente ejemplo muestra una migración de 50 servidores virtuales.

Ola 0 (prueba): 5 servidores virtuales

  • 1x Disco único Linux (prueba del método 1)
  • 1x Multidisco Linux (prueba del método 2)
  • 1x Windows monodisco (Método 1 con sysprep)
  • 1x Windows multidisco (Método 2 con virt-v2v )
  • 1x aplicación de prueba de 3 niveles (métodos 2 y 3, pila completa)

Ola 1 (infraestructura): 8 servidores virtuales

  • Servidores DNS
  • Supervisión de servidores
  • Jump hosts o servidores bastión
  • Servidores de archivos compartidos que han migrado al almacenamiento de archivos VPC

Ola 2 (aplicación A): 12 servidores virtuales

  • Nivel de base de datos (3 servidores virtuales)
  • Nivel de aplicación (6 servidores virtuales)
  • Nivel web (3 servidores virtuales)
  • Subred 10.50.10.0/24 → Subred VPC 10.240.10.0/24

Ola 3 (Aplicación B): 10 servidores virtuales

  • Nivel combinado de base de datos y aplicación (4 servidores virtuales)
  • Nivel web (6 servidores virtuales)
  • Subred 10.50.20.0/24 → Subred VPC 10.240.20.0/24

Ola 4 (Aplicación C): 15 servidores virtuales

  • Aplicación multinivel de gran tamaño
  • Subred 10.50.30.0/24 → Subred VPC 10.240.30.0/24

Diseño de la ventana de transición

Cada ola necesita una ventana de corte bien definida.

Calendario previo a la transición (de 7 días al día de la migración):

  • Finalizar el plan de oleadas y el libro de ejecución
  • Confirme la conectividad Transit Gateway
  • Aprovisionamiento de instancias de servidores virtuales de trabajadores y volúmenes de destino
  • Comunicar el periodo de transición a las partes interesadas
  • Reducir los TTL de DNS para los servicios que están migrando
  • Notificar a los usuarios la ventana de mantenimiento

Ejecución de la transición ( T-0 )

La siguiente información describe las fases de transición.

Fase 1: Suspender y migrar (Horas 0-4)

  1. Drenar conexiones - eliminar de los balanceadores de carga y esperar a que se cierren las sesiones.
  2. Detener correctamente las aplicaciones
  3. Apague los servidores virtuales o inicie desde una ISO activa para el método 3
  4. Iniciar transferencia de disco
  5. Supervisar el progreso de la transferencia

Fase 2: Transformación y provisión (Horas 4-6)

  1. Ejecute virt-v2v, si es necesario, para inyectar controladores
  2. Verificación de transferencias de disco (fdisk, sumas de comprobación)
  3. Vaciar búferes y separar volúmenes del trabajador
  4. Crear las instancias de servidor virtual a partir de los volúmenes migrados
  5. Inicia las instancias del servidor virtual

Fase 3: Validación y transición (Horas 6-8)

  1. Iniciar instancias de servidores virtuales y acceder a través de la consola VNC si es necesario
  2. Verifique la configuración de la red y ajústela si es necesario
  3. Iniciar aplicaciones
  4. Pruebas funcionales (la aplicación funciona, los datos son accesibles)
  5. Añadir a balanceadores de carga y actualizar DNS
  6. Supervisión del rendimiento de la aplicación

Fase 4: Estabilizar (Horas 8-12)

  1. Supervisar los problemas
  2. Verificar la conectividad externa
  3. Comprueba si hay errores en los registros de la aplicación
  4. Comparar los resultados con los de referencia

Puntos de decisión para el desmantelamiento de la migración:

  • Después de la fase 1: Retroceso sencillo (reiniciar los servidores virtuales de VMware )
  • Después de la Fase 2: Dificultad media (descartar instancias de servidor virtual, reiniciar servidores virtuales de VMware, restaurar DNS)
  • Después de la Fase 3: Difícil (podría haber nuevos datos en VPC, requiere sincronización de datos de vuelta a VMware )

Recomendación de diseño: Definir puntos de control explícitos. Ejemplos:

  • Después de la fase 2, si más del 20% de las instancias de servidor virtual no se inician, aplique una reversión.
  • Después de la fase 3, si fallan las pruebas funcionales de la aplicación, aplique una reversión.
  • Después de la fase 4, si el rendimiento es inferior en más de un 30% a la línea de base, investigue pero no aplique una reversión.

Estimación de la velocidad de migración

Calcule el tiempo de migración por servidor virtual para planificar tamaños de ola y ventanas realistas. El siguiente calendario es factible, pero debe consultarlo en PoC antes de la migración propiamente dicha.

Componentes temporales:

Estimaciones del tiempo de exportación utilizando los métodos 1-2:

  • servidor virtual de 100 GB: 20-30 minutos
  • servidor virtual de 500 GB: 2-3 horas
  • Depende del rendimiento del almacenamiento VMware

Tiempo estimado de traslado:

  • Red: 100 GB = 20-25 minutos
  • Red: 500 GB = 90-120 minutos
  • Método 3 con compresión: a menudo 2 o 3 veces más rápido gracias a la compresión

Estimaciones del tiempo de transformación con virt-v2v:

  • Linux: 5-10 minutos
  • Ventanas: 10-20 minutos
  • Depende del rendimiento de la instancia del servidor virtual del trabajador

Estimación del tiempo de aprovisionamiento:

  • Creación de instancia de servidor virtual: 5 minutos
  • Arranque y configuración de la red: 5-10 minutos

Ejemplos de estimaciones de tiempo:

Pequeño servidor virtual Linux (1 disco, 100 GB, Método 3):

  • No exportar: 0 minutos
  • Traslado con compresión: 25 minutos
  • Transformación: 5 minutos
  • Aprovisionamiento: 10 minutos
  • Total: 40 minutos

Estimaciones de tiempo de servidores virtuales Windows grandes utilizando el método 2 con 4 discos, 1 TB en total:

  • Exportación: 3 horas
  • Traslado: 2 horas
  • Transformación ( virt-v2v ): 20 minutos
  • Aprovisionamiento: 10 minutos
  • Total: 5.5 horas

Eficacia de la migración paralela utilizando ambos métodos 3, 4 estimación del tiempo:

  • 4x servidores virtuales de 100 GB que se migran en paralelo
  • 30 minutos cada uno
  • Tiempo total de onda: 35 minutos, que incluyen los tiempos de arranque y parada

En comparación con la migración de 4x servidores virtuales de 100 GB que se migran en serie:

La duración total de la ola es de 120 minutos

El paralelismo supone una mejora de 3 a 4 veces en este caso.