Migración de IBM Cloud, VMware y VCF a servidores virtuales de VPC mediante RackWare RMM

Migrar las máquinas virtuales de IBM Cloud VMware VCF a servidores virtuales de VPC mediante RackWare RMM, conservando las direcciones IP a través de Direct Sync y un servidor puente.

Esta guía se centra en el uso del módulo de gestión de RackWare ( RMM ) para migrar máquinas virtuales automatizadas de IBM Cloud VCF a instancias de servidor virtual de una nube privada virtual (VPC) de IBM Cloud. Hay un tutorial asociado que explica el proceso paso a paso.

IBM Cloud VCF-Las licencias del sistema operativo de las máquinas virtuales automatizadas son responsabilidad del cliente y no las proporciona. IBM Cloud Al crear las instancias del servidor virtual de destino, ten en cuenta las opciones de aprovisionamiento de la opción « Trae tu propia licencia ».

La mayoría de las máquinas virtuales alojadas en IBM Cloud VCF-Automated están conectadas a segmentos de superposición de NSX que no tienen acceso nativo a las redes de IBM Cloud Classic. Para garantizar que las instancias de servidor virtual de destino tengan las mismas direcciones IP que las máquinas virtuales de origen, es necesario aislar el segmento de superposición de NSX y las subredes VPC de las instancias de servidor virtual de destino. Para ello, puedes utilizar las siguientes funciones de « RMM »:

  • Sincronización directa (Host Sync): los datos se transfieren directamente desde la máquina virtual de origen a la instancia del servidor virtual de destino sin almacenarse en el servidor RMM. La « RMM » coordina la operación.
  • Passthrough: la instancia del servidor virtual de destino no puede acceder directamente a la máquina virtual de origen, por lo que « RMM » utiliza Secure Shell (SSH) para conectarse a la instancia del servidor virtual de destino y, desde allí, iniciar un túnel SSH inverso hacia la máquina virtual de origen. Flujos de datos: Origen → RMM → Destino, actuando RMM como relé o proxy de red para la transferencia de datos.

El RackWare RMM con un servidor puente permite la migración entre redes aisladas a través de:

  1. Traducción de direcciones de red (NAT) de puente: permite que RMM pueda acceder a la fuente a través de NAT
  2. Túnel SSH inverso: permite que la instancia del servidor virtual de destino se conecte a la máquina virtual de origen a través del servidor RMM
  3. Autenticación mediante clave: la instancia del servidor virtual de destino utiliza la clave SSH de RMM para autenticarse en la máquina virtual de origen
  4. Sincronización de datos a través del túnel: la instancia del servidor virtual de destino obtiene los datos de la máquina virtual de origen a través del túnel SSH seguro
  5. Instalación del gestor de arranque: « RMM » hace que el dispositivo de destino sea arrancable con la configuración adecuada de GRUB

El proceso es elegante, ya que permite migrar de un lugar a otro manteniendo la seguridad y el aislamiento de la red.

En esta guía no se trata una alternativa a la Sincronización directa, denominada Sincronización por etapas (Etapa 1 + Etapa 2):

  • Etapa 1: Copiar los datos del origen al pool de almacenamiento ZFS de RMM, almacenándolos temporalmente.
  • Etapa 2: Copia de datos del almacenamiento de RMM al destino.

Se utiliza cuando no se desea Direct Sync o cuando se quiere desacoplar las operaciones de origen y destino.

Conservar el direccionamiento IP

La mayoría de las migraciones de máquinas virtuales a servidores virtuales de VPC requieren que se mantenga el direccionamiento IP en las cargas de trabajo migradas. En la mayoría de las máquinas virtuales esto es posible; sin embargo, las subredes de VPC tienen direcciones IP reservadas. Por ejemplo, los siguientes están reservados en 192.168.10.0/24:

  • dirección de red ibm: 192.168.10.0
  • ibm-default-gateway: 192.168.10.1
  • ibm-dns-address: 192.168.10.2
  • ibm-reserved-address: 192.168.10.3
  • dirección de difusión de IBM: 192.168.10.255

Por lo tanto, es posible que tenga que volver a IP unas cuantas máquinas virtuales por subred.

Sistemas soportados

Revise la documentación listada en las referencias para conocer los últimos sistemas operativos soportados, pero actualmente incluyen:

  • RHEL 5.2 a través de 5.11, 6.x, 7.x. 8.x, 9.x
  • Centos 5.2 a través de 5.11, 6.x, 7.x, 8.x
  • Oracle Linux 5.6 a través de 5.11, 6.x, 7.x, 8.x, 9.x
  • SLES 11 (incluida la versión de 32 bits)
  • SLES 12 (sin btrfs)
  • SLES 15 (sin btrfs)
  • Ubuntu 12 (incluida la versión de 32 bits), 14, 16, 18, 20, 22, 24
  • Debian 8, 9, 10, 11, 12
  • AlmaLinux 8, 9
  • Rocky Linux, 8 y 9
  • Windows 2008 R2, 2012, 2016, 2019, 2022

Componentes de arquitectura

Esta guía:

  • Utiliza direcciones IP de ejemplo para ayudar en la transferencia de conocimientos, sus direcciones IP serán diferentes.
  • Se centra en una migración a Linux, pero Microsoft Windows es similar.
IBM Cloud VMware-Automated    Bridge Server              IBM Cloud VPC
┌──────────────┐             ┌───────────────┐          ┌───────────────┐
│              │             │ens192:        │          │               │
│  Source VM   │             │192.168.10.254 │          │  RMM Server   │
│ 192.168.10.11├────────────►│               │◄─────────┤  10.68.70.11  │
│              │             │   ens224:     │          │               │
└──────────────┘             │   10.134.54.62│          └───────────────┘
                             │               │                  │
                             └───────────────┘                  │
                                                                │
                                                        ┌───────▼───────┐
                                                        │  Target VSI   │
                                                        │ 192.168.10.11 │
                                                        └───────────────┘

El diagrama anterior muestra una vista de conexión lógica de los componentes. El nombre de bridge server induce a error, ya que no utiliza puentes de capa 2, sino NAT de capa 3.

Fuente VM:

  • Localización: IBM Cloud VCF Instancia automatizada VMware
  • Ejemplo: VM ejecutando Ubuntu 22.04
  • IP real: 192.168.10.11 (segmento superpuesto NSX)
  • Accesible a través de: VM tiene acceso a Internet a través de SNAT, y acceso nativo a la red del cliente pero no acceso a la red IBM Cloud

Servidor Puente:

  • Finalidad: Proporcionar conectividad de red de capa 3 entre redes aisladas
  • Función: Utiliza SNAT para hacer accesible el segmento superpuesto NSX aislado a las redes IBM Cloud VPC
  • Interfaces:
    • ens192: 192.168.10.254- Red interior ( 192.168.10.0/24 )
    • ens224: 10.134.54.62- Red exterior ( 10.134.54.0/26 )

RMM Servidor:

  • Ubicación: IBM Cloud VPC
  • Finalidad: Orquestar las operaciones de migración/sincronización
  • IP: 10.68.70.11
  • Ejecuta: RackWare software, aloja la interfaz de usuario, coordina la transferencia de datos, actúa como proxy para las comunicaciones de red en modo passthrough

VSI de destino

  • Ubicación: IBM Cloud VPC
  • Ejemplo: Instancia de servidor virtual (VSI)
  • IP: 192.168.10.11
  • Finalidad: Destino de los datos migrados

IBM Cloud Private Subred estática:

  • Ubicación: « IBM Cloud » Classic
  • Ejemplo: Despliegue de una subred portátil /30 (4 IP)
  • IP: 10.194.177.82/30. IPs utilizables: 10.194.177.82- 10.194.177.85
  • Finalidad: Proporciona la dirección IP para NAT a la que se dirige la red clásica IBM Cloud: 10.134.54.62 (IP ens224 del servidor puente). IBM la infraestructura de red de la empresa sabe que el tráfico destinado a 10.194.177.82/30 debe enviarse a 10.134.54.62

Servidor Puente

El servidor puente utiliza iptables para proporcionar NAT:

  1. Cuando RMM se conecta a 10.194.177.82, el puente traduce el destino a 192.168.10.11 (la dirección IP de origen real VM ).

  2. Cuando la fuente VM responde, parece provenir de la IP NAT 10.194.177.82

    Cuando RMM intenta llegar a 10.194.177.82:

    1. RMM envía el paquete
      • SRC: 10.68.70.11
      • Horario de verano: 10.194.177.82
    2. VPC Enruta a Transit Gateway que enruta a la red Classic que sabe que:
      • " 10.194.177.82 está en la subred 10.194.177.82/30 "
      • "Enruta esta subred a 10.134.54.62 "
    3. Paso 3: Entrega del paquete al servidor puente
      • Llega a ens224 ( 10.134.54.62 )
      • DST: 10.194.177.82 (sin cambios)
    4. DNAT iptables de Bridge
      • iptables -t nat -A PREROUTING -i ens224 -d 10.194.177.82 -j DNAT --to-destination 192.168.10.11
    5. Paquete reenviado al origen VM
      • SRC: 10.68.70.11
      • DST: 192.168.10.11 (redirigido mediante DNAT)

Requisitos de la clave SSH

Para que el túnel funcione para la transferencia de datos, el destino debe autenticarse en el origen. La VSI de destino necesita la clave privada SSH que coincida con una clave pública del archivo authorized_keys de la VM de origen.

Lugares clave:

  • RMM: /root/.ssh/id_rsa Creado como parte del proceso manual posterior al despliegue de RMM
  • Destino Linux VSI: /root/.ssh/id_rsa Debe ser la misma clave que RMM 's y transferida a través de un proceso automatizado RMM
  • Fuente Linux VM: /home/rackware/.ssh/authorized_keys Creado como parte del proceso manual para la configuración de la fuente

Para servidores Windows, se utiliza la utilidad RackWare SSHD. RackWare SSHD para Windows es una implementación ligera de servidor SSH empaquetada como un instalador MSI específico para sistemas Windows que permite la conectividad RackWare RMM. El MSI, RWSSHDService_x64.msi, puede descargarse directamente del servidor RMM en: https://<RMM_IP>/windows/RWSSHDService_x64.msi

flujo de autenticación

  1. RMM → Fuente VM (a través del servidor puente)
    • Utiliza: RMM 's SSH key
    • Se autentica como: rackware user
    • Finalidad: Descubrimiento, montaje del sistema de archivos, limpieza
  2. RMM → VSI objetivo
    • Utiliza: RMM 's SSH key
    • Se autentica como: root user
    • Finalidad: Creación de túneles, montaje de sistemas de archivos, transferencia de datos
  3. VSI de destino → Fuente VM (a través de túnel)
    • Usos: Clave SSH copiada (igual que la de RMM )
    • Se autentica como: rackware user
    • Finalidad: Transferencia de datos

Core RackWare RMM Operaciones

A continuación se indican las principales operaciones de RackWare RMM para la migración.

Descubrir/Examinar

Finalidad: Recopilar información sobre la fuente VM Proceso:

  • El usuario proporciona la dirección IP o el nombre de host DNS de la fuente VM. En nuestro caso utilizaremos la dirección IP NAT.
  • RMM se conecta mediante SSH al servidor de origen VM
  • Realiza consultas estándar del sistema operativo para recopilar metadatos:
    • Núcleos de CPU, RAM, configuración de disco
    • Particiones y estructura de volúmenes
    • Versión del sistema operativo y paquetes instalados
    • Configuración de red
    • Información de la aplicación
  • Metadatos almacenados en la CMDB (base de datos de gestión de la configuración) de RMM
  • Se utiliza posteriormente para AutoProvisioning target VSIs, si es necesario

Requisito de claves: Las claves SSH deben estar correctamente configuradas entre RMM y el servidor de origen

Captura (método de almacenamiento y envío)

El enfoque Store-and-Forward no se utiliza en este caso de uso, ya que utilizamos el enfoque Direct Assign (Flex Sync/Host Sync).

Propósito: Crear una instantánea/clon de la imagen VM de origen en el RMM Proceso:

  • Toma instantáneas LVM ( Linux ) o instantáneas VSS (Windows) en el origen VM
  • El SO vuelca las IOs de la aplicación al disco por coherencia
  • El sistema operativo coloca el marcador en el sistema de archivos (no disruptivo)
  • RMM copia bits de imagen de la instantánea estática al almacenamiento RMM
  • Sólo se copian los datos utilizados (a nivel de archivo, no de bloque)
  • Imagen almacenada en RMM Ubicación de almacenamiento del servidor
  • Metadatos adicionales sobre la imagen almacenados en la CMDB

Características principales:

  • No interrumpe el servidor de origen (la producción sigue en marcha)
  • Replicación basada en ficheros (no en sectores/bloques)
  • Admite compresión y cifrado
  • Puede especificar listas de inclusión/exclusión para datos selectivos

Asignar

Propósito: Desplegar la imagen capturada en una VSI de destino Proceso:

  1. AutoProvision vSI de destino (o utilizar un servidor preaprovisionado)
    • RMM utiliza los metadatos de Discover para dimensionar adecuadamente el objetivo
    • Disposiciones VSI en VPC
  2. Conectarse al objetivo utiliza SSH
  3. Examinar el objetivo
    • Compruebe que la VSI de destino puede ejecutar la imagen de origen VM
    • Comprender el hardware subyacente
  4. Arranque en RackWare Microkernel
    • Despliegue del micronúcleo en la VSI de destino
    • Insertar en las opciones del cargador de arranque
    • Arranque del VSI de destino desde el micronúcleo
  5. Preparar disco VSI de destino
    • Reformatear disco
    • Recrear la estructura del Volumen Lógico (coincidencia exacta con el Origen)
    • Crear particiones utilizando el algoritmo de mejor ajuste
  6. Imagen de transferencia
    • Transferencia de bits de imagen desde el almacenamiento RMM a la VSI de destino
    • Inyectar los controladores de dispositivo necesarios para el nuevo hardware
    • Modificación opcional de la configuración de red para la VSI de destino
  7. Configurar y reiniciar
    • Configurar el gestor de arranque para el sistema operativo actual
    • Reiniciar en el SO replicado
  8. Verificación
    • Compruebe que la VSI de destino arranca correctamente
    • Verificar la correcta conexión en red
    • Verificar que los datos se replican correctamente
    • SSH en el servidor replicado utilizando las mismas credenciales que el origen

Asignación directa (también llamada Flex Sync o Host Sync)

Este es el enfoque que utilizamos en este caso.

Objetivo: Replicar directamente desde la fuente VM a la VSI de destino sin almacenamiento intermedio Proceso:

  1. Combina Captura + Asignación en una sola operación
  2. Realiza todas las funciones de Discover
  3. Proporciona el servidor de destino (o utiliza el existente)
  4. Prepara el servidor de destino
  5. Replica directamente de la fuente VM a la VSI de destino
  6. La conexión de red puede seguir enrutándose a través de RMM (no es necesaria una conexión directa de origen a destino)

Sync (Sincronización Delta)

Finalidad: Actualizar el destino sólo con los datos modificados del origen VM Proceso:

  1. Toma instantáneas en la fuente VM (LVM o VSS)
  2. Calcula delta (sólo archivos modificados)
  3. Transfiere al destino sólo los datos modificados
  4. Actualizaciones tampoco:
    • Imagen capturada en RMM storage, OR
    • Ejecutar el servidor de destino, O
    • Ambos (Imagen + Servidor de destino)

Opciones de sincronización

  • Sincronización Fase I
    • Origen → RMM Almacenamiento (imagen capturada)
    • Actualiza sólo la imagen almacenada
  • Fase II Sync
    • RMM Almacenamiento → Servidor de destino
    • Actualiza el objetivo en ejecución a partir de la imagen almacenada
  • RMM A través de
    • Origen → RMM → Objetivo
    • Los datos fluyen por RMM pero no persisten
    • No requiere almacenamiento en RMM
  • Sincronización directa
    • Origen → Destino (conexión directa)
  • Sincronización selectiva
    • Sincronizar sólo archivos/directorios específicos
    • Utiliza listas de inclusión/exclusión
  • Asignación de unidades/directorios
    • Asignar rutas de origen específicas a diferentes rutas de destino

Motores Sync:

  • RWSync (por defecto):
    • Agentless
    • Tolerancia a las interrupciones de la red
    • Maneja actualizaciones concurrentes masivas
    • Incluye la suma de comprobación final
    • Más lento que TNG
  • TNG (Avanzado):
    • Requiere la instalación del rastreador de archivos delta
    • Mucho más rápido y eficaz
    • Para grandes servidores, altas tasas de actualización, RPO agresivos
    • Debe estar en la lista blanca del antivirus
    • Más sensible a los cortes de red
    • No admite montajes remotos NFS /CIFS

El proceso de arranque del micronúcleo RackWare

Durante la operación de asignación, RMM arranca la VSI de destino en un micronúcleo RackWare y se reformatea el disco de arranque, asegurándose de que los sistemas de archivos, sus tipos y tamaños coincidan con los de la fuente VM. El RMM hace un intento de mejor ajuste basado en la disposición del disco de destino y las particiones para encajar en base a lo que la fuente tiene.

Despliegue del micronúcleo

Cuando RackWare prepara una VSI de destino para recibir la imagen replicada:

  • RMM despliega un micronúcleo RackWare en la VSI de destino
  • Este micronúcleo "se inserta en las opciones del cargador de arranque" del SO de la plataforma
  • El microkernel arranca desde el gestor de arranque (GRUB en Linux )

El micronúcleo puede considerarse como un LiveCD, y es un entorno de arranque mínimo que:

  • Aloja los controladores necesarios para el hardware de destino
  • Permite a RMM comunicarse con el servidor de destino
  • Permite reformatear el disco y crear particiones
  • Facilita la transferencia real de datos del origen al destino
  • Configura el sistema para el nuevo entorno de hardware

Durante la fase de Asignación, RackWare:

  1. Arranca la VSI de destino en el micronúcleo (a través de la entrada GRUB)
  2. Reformatea el disco en el micronúcleo
  3. Recrea la estructura de particiones coincidente con la fuente VM
  4. Crea Volúmenes Lógicos para crear la estructura LVM
  5. Transfiere los datos de origen VM a la VSI de destino
  6. Inyecta los controladores necesarios para el hardware de destino
  7. Configura GRUB para arrancar el sistema operativo actual
  8. Reinicia en el sistema operativo replicado

RackWare modifica la configuración de GRUB a:

  • Añadir una entrada temporal de arranque del micronúcleo durante el proceso de Asignación
  • Configure los parámetros de arranque correctos para el SO replicado
  • Establecer la opción de arranque por defecto para el sistema operativo replicado una vez completada la transferencia
  • Gestionar cualquier parámetro del kernel necesario para el nuevo hardware

Para los sistemas Windows:

  • Se utiliza el Gestor de arranque de Windows en lugar de GRUB
  • Se aplica el mismo concepto de micronúcleo
  • El micronúcleo se inserta en la configuración de arranque de Windows
  • Tras la replicación, la configuración de arranque apunta al SO Windows replicado

El entorno del micronúcleo permite a RackWare:

  • Inyectar controladores de almacenamiento adecuados
  • Inyectar controladores de red
  • Configurar los controladores de dispositivos para el nuevo hardware
  • Asegúrese de que el sistema operativo replicado puede arrancar en hardware diferente

El proceso de replicación para las sincronizaciones delta, posteriores, funciona de la misma manera que la sincronización inicial. La sincronización delta se realiza después de reiniciar el servidor de destino en el micronúcleo RackWare. Una vez completada la sincronización delta, la VSI de destino se iniciará de nuevo en el SO anfitrión,

Este enfoque de micronúcleo es un diferenciador clave para RackWare, ya que les permite manejar la complejidad de las migraciones entre plataformas, entre hipervisores y de físico a virtual al tener un control total sobre el entorno de destino durante la fase crítica de transferencia y configuración.

RackWare Passthrough con proceso de sincronización directa

El proceso es el siguiente:

  1. RMM Descubre la fuente VM
RMM → Bridge (10.194.177.82) → Source VM (192.168.10.11)
  • RMM se conecta mediante SSH a 10.194.177.82 (IP NAT)
  • Puente se traduce como 192.168.10.11
  • RMM recopila metadatos: Sistema operativo, sistemas de archivos, disposición del disco, etc.
  1. RMM Descubre el objetivo VSI
RMM → Target VSI (192.168.10.11)
  • RMM se conecta vía SSH a 192.168.10.11
  • Examina el hardware y las capacidades del objetivo
  1. RMM Creación de un túnel SSH inverso a la VSI de destino

La automatización RMM crea un túnel SSH inverso entre el VSI de destino y el VM de origen a través del servidor RMM:

Target VSI (192.168.10.11)
  │
  └─ localhost:23 ──[SSH Tunnel]──► RMM ──► Bridge ──► Source VM:22

  1. RMM inicia la conexión SSH con la VSI de destino

  2. Crea un puerto de escucha (23) EN el objetivo

  3. Cualquier conexión a localhost:23 en el objetivo se reenvía:

    • A través del túnel SSH de vuelta a RMM
    • RMM reenvía a 10.194.177.82:22 (origen vía puente)
    • Puente de DNAT a la fuente real

    Flujo visual:

    Target:       [App tries localhost:23]
                       ↓
               [SSH tunnel to RMM]
                       ↓
RMM: [Receives and forwards to 10.194.177.82:22]
                       ↓
 Bridge: [DNAT: 10.194.177.82 → 192.168.10.11]
                       ↓
Source:   [Receives connection on port 22]

  4. Montar sistemas de archivos

RMM monta sistemas de archivos tanto en el origen como en el destino utilizando comandos similares a los de los ejemplos siguientes:

En la fuente VM (vía puente):

# RMM executes on source
mount --bind / /mnt/rackware/tmp.xxxxx

On Target VSI (directo):

# RMM executes on target
mount /dev/vda2 /mnt/rackware/tmp.yyyyy
  1. Transferencia de datos

RMM ejecuta la transferencia de datos en la VSI de destino para extraer datos de la fuente VM:

  1. Instalación de GRUB

RMM instala y configura GRUB en el objetivo para el arranque UEFI:

  • Copia los archivos del gestor de arranque GRUB
  • Genera grub.cfg con los parámetros correctos del núcleo
  • Crea entradas de arranque UEFI
  • Configuración de nuevos controladores de hardware
  1. Desmontar sistemas de archivos
# On both source and target
umount /mnt/rackware/tmp.xxxxx

  1. Cerrar Túnel

  2. RMM cierra el túnel SSH hacia el objetivo

  3. El puerto 23 deja de escuchar en el objetivo

  4. Eliminar utilidades

# RMM removes temporary files from source and target
rm -rf /var/tmp/rackware/

Referencias