Problema

Los proveedores de servicios gestionados (MSP) suelen comenzar con hosts Hyper‑V o VMware en modo standalone porque la puesta en marcha es rápida y la licencia de dos máquinas virtuales cubre a la mayoría de clientes. Cuando un cliente exige redundancia real, la arquitectura pasa a tres nodos + almacenamiento compartido. En la práctica, muchos MSP se encuentran evaluando Proxmox como alternativa a VMware, pero la gran incógnita es: ¿qué modelo de storage elegir (Ceph, NFS, iSCSI, SAN) y qué tan estable resulta un cluster de Proxmox en producción? La pregunta se repite en varios foros y la falta de una guía concreta lleva a pruebas improvisadas que terminan en tiempo perdido y caídas inesperadas.

Causa

Los fallos de estabilidad en un cluster de Proxmox suelen rastrearse a tres áreas:

  1. Elección de storage inadecuada

    • Ceph requiere una red de baja latencia y suficiente ancho de banda; sin ella, los OSD se saturan y los VM experimentan I/O intermitente.
    • SAN basada en iSCSI/NFS funciona bien con pocos nodos, pero la falta de multipathing o de un LUN bien dimensionado provoca cuellos de botella cuando varios nodos acceden simultáneamente.

  2. Configuración de quorum y quorum‑watchdog

    • Un quorum mal configurado deja al cluster “split‑brain”. En entornos con tres nodos, la pérdida de un nodo sin quorum bloquea la migración en vivo y los recursos críticos pueden quedar inactivos.

  3. Red de gestión y datos mezclada

    • Cuando la misma VLAN lleva tráfico de gestión, replicación Ceph y tráfico de VM, cualquier congestión afecta a los servicios de alta disponibilidad. La separación física o al menos lógica (VLANs distintas) es esencial.

Solución

Una arquitectura reutilizable combina los siguientes principios:

1. Definir el modelo de storage según la carga

Escenario Recomendación Por qué
Alta densidad de VM, I/O intensivo Ceph (3‑5 OSD por nodo, red 10 GbE o superior) Distribución automática, tolerancia a fallos de disco y nodo.
Entorno con 3‑5 nodos, carga moderada SAN iSCSI con multipathing (LIO o hardware) Menor complejidad, latencia predecible.
Laboratorio o pruebas NFS exportado desde un nodo dedicado Simplicidad, sin requisitos de hardware adicional.

2. Configurar la red de forma segmentada

  • VLAN 10 – Gestión del cluster (pve‑cluster, corosync).
  • VLAN 20 – Tráfico de Ceph (public & cluster network).
  • VLAN 30 – Tráfico de VM (bridge vmbr0).

Usar switches con QoS para priorizar la VLAN 20 cuando se elige Ceph.

3. Establecer quorum robusto

  1. En corosync.conf habilitar quorum con provider: corosync_votequorum.
  2. Añadir un quorum‑watchdog (por ejemplo, watchdog de hardware o qdevice externo) para evitar split‑brain si el nodo perdedor no puede comunicarse.

4. Automatizar la creación del cluster

Los pasos pueden ejecutarse con pvecm y pveceph. Un script típico incluye:

# Crear el cluster y añadir nodos
pvecm create proxmox-cluster
pvecm addnode nodo2
pvecm addnode nodo3

# Instalar Ceph (si se elige)
apt-get install ceph ceph-mgr ceph-mon ceph-osd -y
pveceph init --network 10.0.20.0/24
pveceph createmon
pveceph createosd /dev/sdb
pveceph createosd /dev/sdc
# Repetir en cada nodo

5. Configurar HA para recursos críticos

  • Definir grupos de HA en la GUI o con ha-manager.
  • Asignar prioridad de migración (max_restart) y tiempo de espera (max_delay) acorde al SLA del cliente.

6. Monitoreo continuo

  • Prometheus + node_exporter para métricas de CPU, red y latencia Ceph.
  • Grafana con dashboards de Ceph health y VM uptime.
  • Alertas en Slack o correo cuando el estado del cluster pasa a warning o error.

Cuándo aplicar esta solución

  • Síntomas típicos: VM se reinician sin causa aparente, migraciones en vivo fallan, o el UI muestra “cluster down”.
  • Entorno: Tres o más nodos, clientes que exigen al menos 99.9 % de disponibilidad, y una necesidad de escalar storage sin depender de hardware propietario.
  • No aplicar: Cuando la carga es extremadamente baja (menos de 5 VM) y el presupuesto no permite una red dedicada; en esos casos un NFS simple puede ser suficiente.

Código

# Paso 1: crear el cluster
pvecm create proxmox-cluster

# Paso 2: añadir nodos (ejemplo nodo2, nodo3)
pvecm addnode nodo2
pvecm addnode nodo3

# Paso 3: habilitar quorum‑watchdog (ejemplo watchdog de hardware)
systemctl enable watchdog
systemctl start watchdog

# Paso 4: instalar Ceph (solo si se elige Ceph)
apt-get update && apt-get install -y ceph ceph-mgr ceph-mon ceph-osd
pveceph init --network 10.0.20.0/24
pveceph createmon
pveceph createosd /dev/sdb
pveceph createosd /dev/sdc

Verificación

  1. Estado del cluster

    pvecm status

    Debe mostrar Quorum: 3 y todos los nodos Online.

  2. Salud de Ceph (si se usa)

    ceph -s

    Salida sin HEALTH_WARN ni HEALTH_ERR.

  3. Prueba de HA

    • Marcar una VM como HA y forzar la caída del nodo con systemctl stop pve-cluster.
    • Verificar que la VM se migra automáticamente al nodo restante.

  4. Latencia de red

    ping -c 5 10.0.20.1   # nodo de Ceph

    RTT < 1 ms es deseable.

Notas adicionales

  • Planificación de discos: Ceph necesita al menos 3 OSD por nodo para tolerar la pérdida de un disco sin degradar el PG.
  • Backup: Proxmox Backup Server (PBS) se integra sin fricción y permite snapshots de VM en Ceph o en LVM.
  • Actualizaciones: Siempre aplicar el mismo nivel de versión a los tres nodos; una versión desincronizada rompe el quorum.
  • Licenciamiento: La versión gratuita de Proxmox ya incluye HA, pero la suscripción brinda acceso a repositorios de paquetes estables, lo que reduce riesgos en producción.
  • Documentación interna: Mantener un playbook con los comandos de pveam y pveceph acelera la recuperación ante fallos inesperados.

Con estos pasos, un MSP puede ofrecer a sus clientes una solución de virtualización basada en Proxmox que combina flexibilidad de storage (Ceph o SAN) y alta disponibilidad sin la complejidad de VMware. La clave está en alinear la arquitectura de red, el modelo de storage y la configuración de quorum desde el inicio.