Medidas de mitigación de riesgos y estrategias de reversión para la migración a IBM Cloud VPC

Mitigar los riesgos de la migración de « IBM Cloud VPC » —fallos de red, corrupción de datos, problemas de rendimiento— e implementar procedimientos de reversión.

Riesgos comunes de la migración

La siguiente información cubre las dificultades más comunes que puedes encontrar después de una migración.

Riesgo: fallo de conectividad de la red

Síntoma: Tras la migración, el servidor virtual no puede comunicarse con otros sistemas.

Detección: Fallan las pruebas de conectividad posteriores a la migración.

Arreglo:

  • Acceder a través de la consola de Virtual Network Computing (VNC) para solucionar problemas
  • Comprueba la configuración de la interfaz de red virtual (VNI) (dirección IP, grupos de seguridad)
  • Compruebe las tablas de enrutamiento en VPC y Transit Gateway
  • Revise las reglas de los grupos de seguridad (utilice los registros de flujo de la VPC para ver los paquetes descartados)

Reiniciar: Reinicie los servidores virtuales de VMware y actualice los DNS y los equilibradores de carga para que vuelvan a apuntar a VMware.

Prevención:

  • Pruebe a fondo la conectividad de Transit Gateway antes de la migración
  • Compruebe que las reglas del grupo de seguridad permiten el tráfico necesario
  • Pruebe la resolución DNS en la VPC de destino

Riesgo: la aplicación no se inicia

Síntoma: el servicio de la aplicación no se inicia después de la migración, o se inicia pero no funciona.

Detección: El servicio no se inicia, o se inicia pero no supera las comprobaciones de estado.

Solución:

  • Comprueba si hay errores en los registros de la aplicación
  • Verificar los archivos de configuración
  • Comprobar variables de entorno
  • Verificar la conectividad de la base de datos
  • Compruebe si hay problemas de licencias

Reiniciar: Detener la aplicación en VPC, reiniciar en un entorno VMware.

Prevención:

  • Verifique que todas las dependencias están migradas o accesibles a través de Transit Gateway.
  • Pruebe los procedimientos de inicio de aplicaciones que están en la onda piloto.
  • Documente la configuración específica de la aplicación que pueda necesitar ajustar.

Riesgo: corrupción de datos

Síntoma: datos dañados, errores en el sistema de archivos o incoherencias en los datos de la aplicación.

Detección: Errores de comprobación del sistema de archivos, la aplicación informa de errores de datos, la base de datos no se inicia

Solución:

  • Intentar reparar el sistema de archivos
  • Si la reparación falla, vuelva a intentar la migración desde el servidor virtual de origen
  • Compruebe que el servidor virtual de origen se ha apagado correctamente

Deshacer: Descarte el servidor virtual VPC dañado, reinicie el servidor virtual de origen e investigue la causa raíz antes de volver a intentar la migración.

Prevención:

  • Apagar limpiamente los servidores virtuales antes de la migración
  • Verificar las transferencias con sumas de comprobación, siempre que sea posible
  • Utilice blockdev --flushbufs antes de separar volúmenes

Riesgo: degradación del rendimiento

Síntoma: La aplicación funciona peor en VPC que en VMware.

Detección: Aumento de los tiempos de respuesta y disminución del rendimiento

Solución:

  • Compruebe las métricas de CPU, memoria, E/S de disco y ancho de banda de red
  • Compruebe que el perfil de almacenamiento dispone de IOPS suficientes
  • Compruebe que el perfil de instancia dispone del ancho de banda de red adecuado
  • Compruebe si hay problemas de configuración de la aplicación
  • Considere la posibilidad de actualizar los perfiles de instancia o almacenamiento

Retroceso: Si es crítico, retroceda a VMware mientras investiga el rendimiento.

Prevención:

  • Rendimiento de referencia en VMware antes de la migración
  • Seleccionar los perfiles de instancia y almacenamiento adecuados basados en líneas de base
  • Activar la asignación de ancho de banda de almacenamiento agrupado

Diseño de la estrategia de desmantelamiento

Utilice los siguientes criterios para determinar si necesita revertir.

  • Más del 20% de los servidores virtuales de una oleada no arrancan
  • Las aplicaciones críticas no superan las pruebas funcionales
  • Se encuentran datos corruptos en los servidores virtuales migrados
  • Degradación del rendimiento superior al 50% con respecto a la línea de base sin solución rápida
  • Los errores de configuración de los grupos de seguridad dejan al descubierto servicios sensibles

Autoridad de decisión de retroceso:

  • Definir quién puede tomar la decisión de anulación
  • Definir la vía de escalada en caso de desacuerdo entre los responsables de la toma de decisiones
  • Decisión sobre la reducción del plazo

Procedimientos de reversión

En la siguiente sección se explican las fases del procedimiento de reversión.

Utilización del procedimiento de reversión de la fase 1

Antes de crear los servidores virtuales durante la migración, siga estos pasos para utilizar el procedimiento de reversión de la Fase 1. Este proceso dura unos 30 minutos.

  1. Detener la migración.
  2. Descartar servidores y volúmenes virtuales de trabajadores.
  3. Reinicia los servidores virtuales de VMware.
  4. Actualizar las comunicaciones de estado.

Utilización del procedimiento de reversión de la fase 2

Después de los servidores virtuales creados durante la migración, pero antes de la transferencia de DNS, siga estos pasos para utilizar el procedimiento de reversión de la Fase 2. Este proceso dura aproximadamente una hora.

  1. Detener y eliminar los servidores virtuales migrados.
  2. Reinicia los servidores virtuales de VMware.
  3. Compruebe que los servidores virtuales de VMware funcionan.
  4. Actualizar las comunicaciones de estado.

Uso del procedimiento de reversión de la Fase 3

Tras el corte de DNS durante la migración, los datos podrían cambiar. Siga los siguientes pasos para utilizar el procedimiento de reversión de Fase 3. Dependiendo del tamaño de los datos, este proceso dura entre 2 y 4 horas.

  1. Detenga los servidores virtuales, pero no los elimine.
  2. Actualice los DNS y los equilibradores de carga para que apunten a VMware.
  3. Reinicia los servidores virtuales de VMware.
  4. Decisión sobre los datos:
    • Si no se ha modificado ningún dato, proceda con la reversión.
    • Si los datos han cambiado en VPC, debe sincronizarlos con VMware antes de poder revertirlos.
  5. Sincroniza los datos, si es necesario.
  6. Compruebe que los servidores virtuales de VMware funcionan.
  7. Tras el periodo de verificación, elimine los servidores virtuales de la VPC

Conservación del servidor virtual de origen

Para asegurarse de que se conservan los servidores virtuales de origen, utilice la siguiente información.

  • No elimine los servidores virtuales de VMware inmediatamente después de la migración.
  • El periodo de retención es de 7 a 30 días, en función de su tolerancia al riesgo.
  • Crear instantáneas VMware.
  • Documente las ubicaciones de las instantáneas y sus políticas de conservación.