Migración en vivo KVM sin almacenamiento compartido: replicación a nivel de bloques, consistencia y minimización del tiempo de inactividad

Migración en vivo de KVM sin almacenamiento compartido es un desafío recurrente en centros de datos heterogéneos, en ubicaciones Edge y durante cambios de hardware planificados, cuando no hay un SAN centralizado ni un backend de almacenamiento distribuido como Ceph disponible. La palabra clave principal Migración en vivo de KVM sin almacenamiento compartido aparece por eso al principio: en este artículo explico con enfoque práctico qué patrones técnicos existen para la replicación de bloques, cómo garantizar la consistencia del sistema de archivos y de las aplicaciones y cómo reducir el tiempo de inactividad a segundos. El público objetivo son administradores, System Engineers y operadores que planifican, prueban y gestionan migraciones.

Conceptos clave: Was bedeutet „ohne Shared-Storage“ und welche Optionen gibt es?

„Ohne Shared-Storage“ significa: el host origen y el host destino no comparten dispositivos de bloque persistentes a través de un backend de almacenamiento común. Shared-Storage designa sistemas centrales como SAN, NFS o backends distribuidos que proveen a ambos hosts el mismo LUN o dispositivo RBD. Si esto no existe, los bloques de disco deben sincronizarse activamente entre hosts.

Los patrones más comunes son:

• Replicación de bloques a nivel de bloque (DRBD o basada en NBD).
• Migración de almacenamiento soportada por libvirt/QEMU (copy-storage-all, block-copy, postcopy).
• Métodos orientados al sistema de archivos (instantáneas LVM + rsync para archivos de imagen de guest).

Cada patrón impone diferentes requisitos de operación, red, monitorización y estrategia de recuperación.

Migración en vivo de KVM sin almacenamiento compartido: variantes de arquitectura

DRBD: replicación a nivel de bloques

DRBD (Distributed Replicated Block Device) replica dispositivos de bloque entre hosts en el nivel anterior al sistema de archivos. Puede operar en modo síncrono (protocolo C, asegura cada operación de escritura), semi-síncrono (protocolo B) o asíncrono (protocolo A). Ventaja: para la VM el dispositivo sigue siendo visible como local y el cutover puede ser muy corto. Inconveniente: carga operativa por fencing (aislamiento automático de un host con comportamiento anómalo), prevención de split‑brain y comprobaciones de resync periódicas.

# Grundlegende DRBD-Schritte (Beispiel)
drbdadm create-md r0
drbdadm up r0
# Initiale Promotion und Datenübernahme (Achtung: überschreibt Daten auf Ziel!)
drbdadm -- --overwrite-data-of-peer primary r0
cat /proc/drbd

Importante para la operación: fencing (separación externa de un host defectuoso) y un sistema de monitorización para los resyncs son imprescindibles. Sin fencing, ante una partición de red puede producirse split‑brain —ambos extremos creen ser primario y los estados de escritura divergentes deben reunificarse manualmente.

DRBD-Config-Beispiel (minimal)

resource r0 {
  protocol C; # synchrone Replikation
  on hostA {
    device /dev/drbd0;
    disk /dev/sdb1;
    address 10.0.0.1:7789;
    meta-disk internal;
  }
  on hostB {
    device /dev/drbd0;
    disk /dev/sdb1;
    address 10.0.0.2:7789;
    meta-disk internal;
  }
}

Por qué se configura así: el protocolo C garantiza que una escritura se considere exitosa solo cuando se ha almacenado en ambos extremos —importante para requisitos Zero-RPO. Sin embargo, con latencias elevadas, C impacta la latencia percibida por la aplicación.

Migración de almacenamiento QEMU/libvirt (copy-storage-all, block-job, postcopy)

Libvirt puede copiar el almacenamiento de VMs en ejecución. El enfoque por defecto es Pre-copy: copia inicial del volumen, copias incrementales posteriores de los bloques modificados y corte final (cutover). Postcopy es un modo en el que la VM se inicia en el destino y los bloques faltantes se cargan por la red bajo demanda. Postcopy reduce la ventana de cutover, pero es más susceptible a la pérdida de paquetes o al fallo del host origen.

# Beispiel: virsh migrate mit copy-storage-all und optionalem postcopy
virsh migrate --live --verbose 
  --copy-storage-all 
  --persistent 
  --unsafe --postcopy 
  vmname qemu+ssh://targethost/system

# Job-Status überprüfen
virsh domjobinfo vmname

Consejo práctico: usar Postcopy solo en una red controlada y tras pruebas de carga. Pruebe escenarios de failover (p. ej. pérdida de un paquete o interrupción breve) antes de desplegarlo en producción.

LVM-Snapshot + rsync (Image-basiert)

Si los discos de la VM están almacenados como archivos (qcow2/raw) en el host, un snapshot de LVM es una forma pragmática de crear una imagen consistente. A continuación sincronice con rsync al host de destino. Las desventajas son mayores tiempos de inactividad durante la sincronización final y posibles incoherencias sin quiesce.

# Beispielablauf: Snapshot, rsync und Cleanup
lvcreate -L 10G -s -n vmname-snap /dev/vg/vmname
rsync -av --progress /var/lib/libvirt/images/vmname-snap.img target:/var/lib/libvirt/images/
# Nach erfolgreichem Test Snapshot löschen
lvremove /dev/vg/vmname-snap

Requisitos de consistencia: ¿quién debe hacer flush de qué y por qué?

Consistencia significa que la imagen de destino representa un estado que los sistemas de archivos y las aplicaciones pueden interpretar correctamente. Se distinguen consistencia a nivel de bloque (todos los bloques están en un estado coherente), consistencia del sistema de archivos (metadatos y journal correctos) y consistencia a nivel de aplicación (p. ej. transacciones completas de la base de datos).

Mecanismos esenciales para alcanzarla:

• QEMU Guest Agent: guest-fsfreeze para congelar temporalmente los sistemas de archivos dentro del huésped.
• Hooks específicos de la aplicación: WAL switch en PostgreSQL, comandos de flush en otros DBMS.
• Snapshots del sistema de archivos (LVM/XFS/Btrfs) para imágenes atómicas.

# guest-fsfreeze Beispiel mit virsh
virsh qemu-agent-command vmname '{"execute":"guest-fsfreeze-freeze"}'
# Applikation flush (Beispiel PostgreSQL)
psql -c "SELECT pg_switch_wal();"
# Nach Abschluss
virsh qemu-agent-command vmname '{"execute":"guest-fsfreeze-thaw"}'

Runbook de migración concreto (paso a paso)

Un runbook claro y conciso reduce errores en las fases de cutover. A continuación un procedimiento práctico para una migración Pre-copy con quiesce mediante Guest-Agent:

1. Preparación: comprobación de versiones de QEMU/libvirt, verificación de espacio, prueba de red (iperf), monitoring activo.
2. Iniciar la copia inicial del volumen (Pre-copy).
3. Permitir varias copias incrementales; supervisar hasta que la tasa de cambios (dirty rate) sea baja.
4. Quiesce del huésped: guest-fsfreeze + flush de la aplicación.
5. Última sincronización incremental y cutover (detener la VM en el origen y arrancarla en el destino, o conmutación en vivo a través de libvirt).
6. Comprobaciones post-cutover: chequeos del sistema de archivos, estado de la aplicación, comparar métricas del monitor.
7. Si todo está estable: eliminar snapshot/backup en el destino y marcar el destino como productivo.

# Beispiel: Cutover mit virsh (vereinfachte Darstellung)
# 1) Initiate migration
virsh migrate --live --copy-storage-all --persistent vmname qemu+ssh://targethost/system
# 2) Monitor progress
watch -n 2 virsh domjobinfo vmname
# 3) Nach Erfolg: prüfen
ssh targethost virsh list --all | grep vmname
# 4) Falls Abbruch: Abbruchbefehl
virsh migrate --abort vmname || echo "Abort attempted"

Documente las responsabilidades para cada paso (quién ejecuta guest-fsfreeze, quién inicia el DB-Flush, quién supervisa los logs).

Estrategia de rollback y recuperación

Un rollback debe ser posible de forma rápida y segura. Principios importantes:

• Conservar un punto de restauración (Snapshot o copia de seguridad) antes del cutover final.
• Definir timeouts: si el Cutover dura más de X minutos, abortar y revertir a la fuente.
• Cambio de rol en DRBD: órdenes claras y listas de verificación para promover y degradar roles.

# DRBD: Promoten (auf Ziel) / Demoten (auf Quelle)
# Ziel promoten
drbdadm primary r0
# Quelle demoten (falls noch Primary)
drbdadm secondary r0
# Resync anstoßen
drbdadm connect r0
drbdadm status r0

Si debe abortar una migración de libvirt, deje constancia de si el destino ya ha modificado partes del disco. Un patrón habitual es: detener la VM en el destino, conservar el snapshot en el destino, dejar la VM en la fuente en ejecución y realizar un análisis de causas.

Pruebas de postcopy con simulación de fallo de red

Antes de usar postcopy en producción, debe simular errores de red. Utilice tc (Traffic Control) para introducir latencia, pérdida de paquetes o interrupciones de conexión:

# Beispiel: 2% Paketverlust und 100ms Latenz auf der Ziel-schnittstelle
tc qdisc add dev eth1 root netem delay 100ms loss 2%
# entfernen
tc qdisc del dev eth1 root netem

Procedimiento de prueba: inicie una migración postcopy en la red de pruebas, inyecte fallos de red y observe si la VM en el destino se mantiene estable o si los bloques faltantes provocan errores. Registre los tiempos de respuesta y los pasos de recuperación.

Monitorización, métricas y alertas

Métricas prácticas que debería supervisar:

• Tasa de dirty (velocidad de cambio de los discos de la VM) — influye en el número de rondas de Pre-copy.
• Bytes incrementales por trabajo y bytes restantes (über virsh domjobinfo).
• Ancho de banda y latencia en la red de migración (iperf, SNMP).
• Estado de resync de DRBD y posibles backlogs.
• Estado del Guest-Agent, salud de procesos y servicios en el huésped (via monitoring agent).

Alarmas concretas: si Pre-copy tarda más de lo esperado, si dirty-rate > X MB/s durante Y minutos, si DRBD Resync cae o se detecta Split-Brain.

Ajuste de rendimiento: parámetros que realmente ayudan

Algunos enfoques prácticos de ajuste:

• Elección del protocolo DRBD: Protocol C para consistencia, A/B para menor latencia — elegir según el requisito de RPO.
• Opciones de I/O de QEMU: cache=none, io=native reducen los efectos de cache en el host durante la copia.
• En qcow2: comprobar si una conversión temporal a raw reduce el tiempo de copia — tenga en cuenta el requerimiento adicional de espacio.
• Red: VLAN de migración dedicado, QoS o conexión física separada para grandes volúmenes de datos.

Errores típicos y cómo evitarlos

• Falta del Guest Agent o versión obsoleta: pruebe guest-fsfreeze / thaw antes de la migración.
• Subestimar la tasa de cambios: mida dirty-rate con antelación y planifique varios ciclos de Pre-copy.

Lista de comprobación antes de la migración a producción

1. Copia de seguridad: disponer de un backup actualizado y su validación.
2. Comprobación de compatibilidad: modelos de CPU, versiones de QEMU/libvirt, formatos de imagen.
3. Comprobación de red: latencia, ancho de banda, QoS configurado.
4. Guest-Agent y hooks de la aplicación verificados.
5. Monitorización y alertas para las métricas de migración activas.
6. Runbook de rollback conocido y confirmado por los miembros del equipo.
7. Dry-run en staging realizado.

Conclusión: criterios de selección y madurez operativa

Elija DRBD si necesita tiempos de cutover cortos y está dispuesto a operar procesos operativos para fencing y manejo de split‑brain. Elija libvirt –copy-storage-all / block-copy para migraciones puntuales sin infraestructura de almacenamiento adicional, siempre que la red y las pruebas estén en orden. Los snapshots LVM junto con rsync son adecuados para escenarios con ventanas de mantenimiento previsibles y requisitos de downtime menos estrictos.

Lo decisivo es la madurez operativa: pruebe cada método en un entorno de staging con un perfil de E/S comparable, documente runbooks, automatice las comprobaciones previas y mantenga la posibilidad de intervención manual para las fases de cutover. Solo así reducirá el tiempo de inactividad de cargas críticas al mínimo y conservará el control sobre la consistencia y la recuperación.

Con pruebas sistemáticas, estrategias claras de verificación y de reversión, así como monitorización, puede operar migraciones KVM en vivo sin almacenamiento compartido de forma segura y fiable.

Migración en vivo KVM sin almacenamiento compartido: operación, seguridad y orquestación

Además de la técnica pura de la replicación a nivel de bloque, la operación, la seguridad y la orquestación determinan el éxito de las migraciones a producción. Los puntos siguientes complementan los patrones técnicos previos con reglas prácticas de operación, aspectos de integración y enfoques de automatización que han demostrado su eficacia en proyectos con software empresarial personalizado y servicios críticos.

Aspectos de seguridad y cumplimiento

El tráfico de replicación y migración transporta estados completos de VM. Proteja estos datos de forma rigurosa: cifrado en tránsito (IPsec, WireGuard o túnel TLS) y autenticación de los pares son obligatorios, especialmente en replicación asincrónica. En VMs cifradas (LUKS) aclare el transporte de claves: el host de destino debe disponer del material de claves o de un mecanismo de desbloqueo remoto antes del cutover. Un error típico es iniciar la migración y no detectar problemas con las claves hasta el arranque en el destino.

• Recomendación: red de migración dedicada con ACLs y VPN; activar el registro (logging) para generar audit trails.
• Con DRBD: no exponer los puertos de gestión a la red; aplicar control de acceso y autenticación para el monitoring.

Migración consistente de múltiples VMs o de clúster

Las aplicaciones distribuidas (p. ej., clústeres de bases de datos, caches distribuidos) requieren migraciones coordinadas. Procedimiento en breve:

1. El orquestador/runbook inicia hooks de quiesce programados en todas las VMs implicadas (flush de la aplicación, Guest-Agent).
2. Los incrementos de pre-copy se ejecutan hasta que la tasa de datos sucios (dirty‑rate) disminuya.
3. Quiesce final y cutover sincronizado de todos los nodos con timeouts definidos.

Sin coordinación corre el riesgo de split-brain a nivel de aplicación o de transacciones inconsistentes. Un token mutex simple (p. ej. en etcd) reduce el riesgo, ya que el Cutover solo debe realizarse cuando todos los nodos han confirmado.

Automatización: pequeño ejemplo de orquestación

Los hooks automatizados reducen errores por intervención manual. A continuación un task mínimo de Ansible que orquesta guest-fsfreeze y un flush de la BD (como patrón, adaptar a su entorno):

- name: Quiesce VM and switch WAL
  hosts: controlhost
  tasks:
    - name: Freeze guest filesystem
      command: virsh qemu-agent-command vmname '{"execute":"guest-fsfreeze-freeze"}'
    - name: Trigger DB WAL switch on guest
      command: ssh dbuser@guest "psql -c 'SELECT pg_switch_wal();'"
    - name: Thaw guest filesystem
      command: virsh qemu-agent-command vmname '{"execute":"guest-fsfreeze-thaw"}'

La automatización debe ser idempotente y disponer de rutas claras de gestión de errores: en caso de fallo, disparadores de rollback y notificación al equipo on-call.

Planificación de capacidad y cálculo de SLA

Planifique las migraciones con una fórmula sencilla: duración estimada ≈ (volumen inicial de datos / ancho de banda neto disponible) + (volumen estimado acumulado de cambios / ancho de banda) + tiempo de Cutover. Mida de antemano la Dirty‑Rate y utilice esos valores para ventanas realistas. Establezca umbrales de alerta: si la Pre-copy se prolonga más de lo esperado o la Dirty‑Rate se mantiene por encima del umbral, cancelar automáticamente o escalar.

Validación después de la migración

Tras el Cutover no solo compruebe que la VM esté en ejecución, sino valide las transacciones de la aplicación, las comprobaciones de integridad (checksums, DB-Health) y las métricas de latencia/rendimiento frente a las líneas base. Automatice los smoke-checks y compare la telemetría antes de desactivar definitivamente la fuente.

Estos complementos ayudan a trasladar las KVM-Live-Migrationen sin almacenamiento compartido al contexto operativo: seguridad, orquestación coordinada y SLAs medibles hacen que las migraciones sean previsibles y auditables.

Para este tema también son importantes Libvirt Copy-Storage-All. El artículo sitúa estos aspectos de forma comprensible y muestra en qué hay que fijarse en la práctica.