¿Es un business-class NAS suficiente como shared storage para un pequeño cluster Proxmox de 2 nodos?

Problema

Muchas pymes y laboratorios de TI necesitan un entorno de virtualización de alta disponibilidad con un presupuesto limitado. Un escenario típico es un cluster Proxmox de dos nodos que ejecuta varios servicios críticos (AD, bases de datos, aplicaciones web) y que requiere un storage compartido para migraciones en vivo y failover rápido. La pregunta central es si un business‑class NAS puede reemplazar una arquitectura basada en discos locales con ZFS y replicación, manteniendo un RPO aceptable y sin introducir cuellos de botella. El problema se repite en cualquier despliegue donde:

• El número de nodos es bajo (2‑3).
• La carga de trabajo combina I/O moderado (bases de datos pequeñas, contenedores) y picos ocasionales.
• El presupuesto no permite una storage array de nivel “enterprise”.
• Se dispone de conectividad 10 GbE o al menos 1 GbE entre los nodos y el storage.

Causa

Los principales factores que hacen que la decisión sea compleja son:

1. Latencia y ancho de banda del enlace – Un NAS que sirve discos vía NFS o iSCSI depende de la calidad del enlace. En 1 GbE la latencia típica es 1‑2 ms; en 10 GbE baja a <0,2 ms. Si la red no está preparada, la performance de VM‑disk se degrada notablemente.

2. Modelo de fallos – Con ZFS local cada nodo tiene una copia física de los datos. Un NAS introduce un único punto de fallo (SPOF) a menos que se implemente redundancia a nivel de chassis (dual‑controller, discos hot‑spare, etc.).

3. Gestión de snapshots y clones – Proxmox usa LVM‑thin o ZFS para snapshots. En un NAS la capacidad de snapshots depende del protocolo (NFS permite snapshots en el propio NAS, iSCSI no). La ausencia de snapshots puede afectar a procesos de backup y pruebas.

4. Tipo de carga I/O – Bases de datos MySQL pequeñas pueden tolerar la latencia de red, pero transacciones intensas o workloads con alta concurrencia pueden sufrir. La mayoría de los ERP ligeros funcionan bien con almacenamiento basado en NAS siempre que el NAS tenga caché de escritura y discos de nivel empresarial.

5. Escalabilidad futura – Añadir nodos o capacidad de storage a un NAS es sencillo (expansión de discos, agregación de LUN). Con ZFS local cada nodo necesita hardware adicional y replicación configurada.

Solución

Una solución reutilizable combina los siguientes pasos:

1. Definir el nivel de servicio requerido

Si el RPO aceptable está por debajo de 5 min, un NAS con replicación interna (dual‑controller, espejo de discos) suele ser suficiente. Si se necesita cero pérdida, la arquitectura ZFS con replicación asíncrona puede ser más segura.

2. Seleccionar el protocolo de acceso

Para entornos donde los snapshots son críticos (p.ej. pruebas de actualizaciones), NFS suele ser la opción preferida. Cuando la prioridad es rendimiento bruto y se dispone de LVM‑thin en los nodos, iSCSI es viable.

3. Dimensionar el NAS

• CPU: 4‑8 cores (Intel Xeon D o AMD EPYC) – suficiente para caché de escritura y deduplicación ligera.
• RAM: 8 GB por TB de capacidad de datos (mínimo 64 GB para 8 TB) para caché de escritura (write‑back) y metadata.
• Discos: 2‑4 bay con SSD de caché (RAID‑1) + 4‑8 bay con HDD SAS 10K o 12K en RAID‑10. La combinación permite latencia de <0,5 ms para escrituras y buen throughput para lecturas secuenciales.
• Red: 2× 10 GbE (LACP) o 1× 10 GbE + 1× 1 GbE para gestión. Redundancia de enlace evita SPOF de red.
• Fuente de poder: fuentes redundantes, hot‑swap.

4. Configurar Proxmox para usar el NAS

1. Crear el pool de almacenamiento en la UI de Proxmox:
   • NFS → nfs://nas-ip/exports/vm-data
   • iSCSI → iscsi://nas-ip/iqn.2026-08.com:my-nas:pool1
2. Asignar el pool a los nodos y habilitar thin provisioning si se usa LVM‑thin.
3. Activar HA en los recursos críticos (VM de AD, MySQL) marcando la opción “HA” en la tabla de recursos.

5. Implementar redundancia del NAS

• Dual‑controller con failover automático.
• RAID‑10 o RAID‑6 en los discos de datos.
• Hot‑spare configurado para reemplazo rápido.
• Monitorización (SNMP, syslog) para detectar degradaciones antes de que afecten al cluster.

6. Plan de contingencia

• Mantener una copia de los discos críticos en un snapshot local (ZFS o LVM) en cada nodo, con retención de 24 h. En caso de caída del NAS, los nodos pueden iniciar VMs desde su snapshot local mientras se reemplaza el hardware.
• Documentar procedimiento de failover manual: desmontar NFS, reasignar LUNs iSCSI a otro storage (por ejemplo, un USB‑SSD externo) y arrancar VMs.

Cuándo aplicar esta solución

• Adecuado cuando:

  • El cluster tiene 2‑3 nodos y la carga I/O es moderada (≤ 200 IOPS promedio por VM).
  • Se dispone de al menos 10 GbE entre nodos y NAS.
  • El presupuesto permite un NAS con al menos dos controladores y caché SSD.
  • Se acepta un RPO de 5‑15 min para bases de datos pequeñas.

• No recomendado cuando:

  • Se esperan workloads intensivos en I/O (bases de datos grandes, análisis de logs en tiempo real) que superan 500 IOPS por VM.
  • La red está limitada a 1 GbE sin posibilidad de upgrade.
  • El entorno requiere cero pérdida de datos (p.ej. transacciones financieras críticas).

En esos casos, una arquitectura basada en ZFS con replicación asíncrona y discos locales de alta velocidad ofrece mayor control y menor dependencia de un único punto de fallo.

Código

# Montar export NFS en ambos nodos (añadir a /etc/fstab)
nas_ip=10.0.0.10
mount_point=/mnt/nas-vm
echo "${nas_ip}:/exports/vm-data ${mount_point} nfs4 defaults,_netdev 0 0" >> /etc/fstab
mount -a

# Crear LVM‑thin sobre un LUN iSCSI (ejemplo)
iscsiadm -m discovery -t sendtargets -p ${nas_ip}
iscsiadm -m node --login
pvcreate /dev/disk/by-path/ip-${nas_ip}:3260-iscsi-iqn.2026-08.com:my-nas:pool1-lun-0
vgcreate vg_nas /dev/disk/by-path/ip-${nas_ip}:3260-iscsi-iqn.2026-08.com:my-nas:pool1-lun-0
lvcreate -L 100G -T vg_nas/thinpool

Verificación

1. Latencia: fio --name=latency --filename=/mnt/nas-vm/testfile --size=1G --rw=randread --bs=4k --iodepth=32 --numjobs=4 --runtime=60 --group_reporting. Los valores de latencia deben estar <1 ms en 10 GbE.
2. Failover: desconectar uno de los enlaces de 10 GbE y comprobar que las VMs siguen operativas.
3. Snapshot: crear un snapshot en el NAS (si NFS) y verificar que Proxmox lo reconoce en la UI.
4. HA: detener el servicio pve-cluster en un nodo y observar que la VM marcada como HA migra automáticamente al otro nodo.

Notas adicionales

• Caché de escritura: habilitar write‑back en el NAS mejora significativamente el rendimiento de bases de datos, pero requiere una batería o capacitor de respaldo para evitar pérdida de datos en corte de energía.
• Alineación de bloques: al usar iSCSI, asegúrate de que el tamaño de bloque del LUN coincida con el de LVM‑thin (normalmente 4 KB) para evitar penalizaciones de I/O.
• Monitorización proactiva: integra el NAS en Prometheus o Zabbix con métricas de latencia, uso de caché y estado de los discos. Alertas tempranas evitan sorpresas durante un failover.
• Licenciamiento: algunos NAS empresariales requieren licencias para funciones de snapshot o replicación. Verifica que el coste de licencia no supere el presupuesto restante.