Problema

Muchas organizaciones intentan sustituir hipervisores tradicionales por Proxmox VE para aprovechar hardware reutilizado y reducir costes. El salto a producción suele tropezar con tres grupos de síntomas recurrentes:

  1. Almacenamiento mixto – se combina Ceph, ZFS y arrays externos (iSCSI/NFS/FC) sin una estrategia clara, lo que genera cuellos de botella y pérdida de rendimiento.
  2. Corosync inestable – enlaces dedicados con latencia variable, configuraciones de dos nodos sin quorum y dispositivos Q que provocan split‑brain.
  3. Migración de VMs – importaciones desde ESXi, controladores VirtIO para Windows y snapshots QCOW2 que no se comportan como se espera.

En entornos donde la disponibilidad es crítica, cualquiera de estos puntos puede desencadenar caídas inesperadas, pérdida de datos o migraciones fallidas que obligan a volver al hipervisor anterior.

Causa

Almacenamiento heterogéneo

  • Ceph sin planificación de red: Ceph depende de una red de baja latencia y alta capacidad. Cuando se mezcla con tráfico de gestión o backup, la congestión degrada tanto el backend de bloques como el de objetos.
  • ZFS sobre discos SSD sin alineación: ZFS aprovecha la caché L2ARC y la deduplicación, pero si los discos no están alineados o el pool se crea con tamaños dispares, el rendimiento se vuelve impredecible.
  • Arrays externos sin tuning: iSCSI/NFS/FC pueden quedar bajo‑utilizados o, por el contrario, saturar el enlace si el MTU no coincide o si el multipathing no está habilitado.

Corosync sensible a latencia

  • Enlaces de gestión compartidos: usar la misma NIC para tráfico de VM y para el anillo de corosync introduce jitter que rompe el algoritmo de consenso.
  • Dos nodos sin quorum: un cluster de dos sin un QDevice carece de mayoría, por lo que cualquier caída de nodo genera split‑brain.
  • Configuración de latencia: valores por defecto (ping‑interval 1000 ms, max‑miss‑count 5) son demasiado laxos para entornos con enlaces de < 1 ms.

Migración desde VMware

  • Import wizard incompleto: el asistente de importación de ESXi no traduce todas las configuraciones de red y discos, dejando VMs sin drivers VirtIO o con discos en modo “thick”.
  • Snapshots QCOW2: al copiar una VM con snapshots, Proxmox crea una cadena de capas que puede colapsar el espacio de almacenamiento si no se compacta.
  • Drivers Windows: la falta del paquete de drivers VirtIO para Windows obliga a arrancar en modo IDE, lo que impacta el rendimiento y la estabilidad.

Solución

1. Arquitectura de almacenamiento coherente

  1. Define un dominio de red exclusivo para Ceph (por ejemplo, VLAN 30). Asegúrate de que todos los OSD y monitores usen MTU 9000 y QoS para priorizar tráfico de replicación.
  2. Crea pools ZFS alineados: usa zpool create -o ashift=12 para discos de 4 KB y agrupa discos de capacidad similar. Habilita compression=lz4 y desactiva deduplicación a menos que sea estrictamente necesario.
  3. Integra arrays externos mediante multipathing: en /etc/multipath.conf define defaults { user_friendly_names yes } y habilita features "1 queue_if_no_path" para evitar I/O stalls.
  4. Unifica la capa de presentación: exporta los volúmenes Ceph y ZFS como LVM‑thin o RBD y usa NFS solo como gateway de backup, nunca como datastore primario.

2. Corosync robusto

  1. Separa físicamente los enlaces: dedica al menos una NIC de 10 GbE exclusivamente al anillo de corosync. Conecta los nodos mediante un switch de capa 2 sin STP.
  2. Implementa un QDevice: en clusters de dos nodos, añade un tercer nodo ligero (puede ser un VM) como QDevice. Configura con pcs qdevice add model net y apunta al endpoint.
  3. Ajusta los timers: en /etc/corosync/corosync.conf establece: 
    totem {
    version: 2
    token: 2000
    token_retransmits_before_loss_const: 10
    join: 60
    consensus: 6000
    max_messages: 20
    interface {
        ringnumber: 0
        bindnetaddr: 10.0.30.0
        mcastaddr: 239.192.0.1
        mcastport: 5405
    }
}
    Estos valores reducen la ventana de split‑brain y mejoran la detección de fallos.

3. Migración fiable de VMs

  1. Exporta VMs como OVF desde ESXi, no como VMDK bruto. El OVF conserva la topología de red y los discos en formato “thin”.
  2. Importa con qm importovf en Proxmox, especificando el storage destino (qm importovf vm100.ovf local-lvm).
  3. Instala drivers VirtIO antes del arranque: monta la ISO de VirtIO (virtio-win.iso) como CD‑ROM y ejecuta el instalador de drivers de red y disco dentro de la VM.
  4. Compacta cadenas QCOW2 después de la importación: qemu-img convert -O qcow2 -c vm100-disk-0.qcow2 vm100-disk-0-compacted.qcow2 && mv vm100-disk-0-compacted.qcow2 vm100-disk-0.qcow2.
  5. Valida la configuración de backup: crea un job de backup Vzdump con mode snapshot y verifica que la VM se pueda restaurar en un nodo diferente.

Cuándo aplicar esta solución

  • Entornos con alta disponibilidad: cualquier cluster que requiera uptime > 99.9 % necesita la separación de enlaces y QDevice.
  • Infraestructura mixta: si ya existen arrays iSCSI/NFS, la estrategia de multipathing y VLAN dedicada evita la sobrecarga de Ceph.
  • Migraciones masivas: cuando se trasladan decenas de VMs desde VMware, el flujo OVF + drivers VirtIO reduce errores de arranque y pérdida de rendimiento.
  • No aplicar: en laboratorios de pruebas donde la latencia y la disponibilidad no son críticas, la configuración completa de QDevice y VLAN puede ser excesiva.

Código

# Configuración básica de multipath
cat > /etc/multipath.conf <<EOF
defaults {
    user_friendly_names yes
}
blacklist {
    devnode "^sd[a-z]"
}
EOF
systemctl restart multipathd

# Ajuste de Corosync (ejemplo simplificado)
cat > /etc/corosync/corosync.conf <<EOF
totem {
    version: 2
    token: 2000
    token_retransmits_before_loss_const: 10
    join: 60
    consensus: 6000
    max_messages: 20
    interface {
        ringnumber: 0
        bindnetaddr: 10.0.30.0
        mcastaddr: 239.192.0.1
        mcastport: 5405
    }
}
nodelist {
    node {
        ring0_addr: node1
        nodeid: 1
    }
    node {
        ring0_addr: node2
        nodeid: 2
    }
}
quorum {
    provider: corosync_votequorum
}
EOF
systemctl restart corosync

# Importar VM desde OVF
qm importovf vm101.ovf local-lvm

Verificación

  1. Almacenamiento: ejecuta zpool status y ceph -s. Ambos deben mostrar HEALTH OK y sin OSD down.
  2. Corosync: corosync-cfgtool -s debe listar los nodos y el QDevice. pvecm status debe indicar quorum 2/3.
  3. Migración: arranca la VM importada, verifica que los dispositivos de red aparecen como virtio y que dmesg no muestra errores de driver. Realiza un backup con vzdump y restaura en el nodo secundario.
  4. Rendimiento: usa fio o dd contra el storage para confirmar que los IOPS y latencias están dentro de los umbrales esperados (por ejemplo, < 5 ms para reads en SSD).

Notas adicionales

  • Monitoreo: integra prometheus-node-exporter y pve-exporter para alertas tempranas de latencia de corosync y degradación de OSD.
  • Actualizaciones: siempre prueba los upgrades de Proxmox en un nodo de prueba antes de aplicar al cluster productivo; los cambios en la versión de Ceph pueden requerir migración de crush map.
  • Backup externo: aunque Proxmox ofrece snapshots, mantén copias fuera del cluster (por ejemplo, a un bucket S3 compatible) para cubrir escenarios de pérdida total del datacenter.
  • Documentación interna: registra la topología de red, los IDs de QDevice y los pools de storage en un wiki interno; facilita la resolución de incidentes y la incorporación de nuevo personal.