Problema

En entornos de virtualización con Proxmox, la pérdida de un nodo principal puede detener servicios críticos. La práctica recomendada es mantener al menos un nodo de respaldo que pueda asumir las cargas de los VMs y LXCs en caso de fallo del hardware, del SSD o de la placa madre. La dificultad radica en elegir un equipo que sea suficientemente potente para ejecutar los workloads más importantes, pero que al mismo tiempo sea económico y fácil de integrar. Mini‑PCs basados en procesadores móviles, como el i5‑13240H, aparecen frecuentemente en ofertas de bajo costo, lo que genera la duda de si su arquitectura “laptop” es adecuada para un nodo de backup en un clúster Proxmox HA.

Causa

Los principales factores que limitan la idoneidad de un hardware de bajo costo como nodo de respaldo son:

  1. Capacidad de CPU bajo carga sostenida – Los chips móviles están diseñados para picos cortos y pueden throttlear bajo uso continuo, reduciendo el rendimiento de VMs con alta demanda de CPU.
  2. Memoria limitada y tipo SODIMM – La configuración de fábrica suele ofrecer 8 GB DDR5 SODIMM, lo que puede ser insuficiente para alojar varios contenedores simultáneos, y la capacidad de expansión depende del número de ranuras disponibles.
  3. Almacenamiento y ancho de banda de I/O – Un único NVMe de 512 GB puede saturarse rápidamente con snapshots y backups, y la ausencia de RAID hardware obliga a depender de software RAID o backups externos.
  4. Conectividad de red – La mayoría de los mini‑PCs solo incluyen una NIC de 1 GbE; para HA se recomienda al menos 2 GbE o 2.5 GbE para evitar cuellos de botella en replicación y migración en vivo.
  5. Limitaciones de expansión – El procesador está soldado, lo que impide upgrades futuros de CPU; la placa madre suele ofrecer pocas ranuras PCIe, restringiendo la adición de tarjetas de red o almacenamiento adicional.

Solución

Una estrategia robusta para validar cualquier hardware como nodo de backup en Proxmox incluye los siguientes pasos:

1. Definir el perfil de carga del nodo de respaldo

  • Workloads críticos: identifica los VMs/LXCs que deben estar siempre disponibles (por ejemplo, controladores de red, bases de datos ligeras, servidores DNS).
  • Requerimientos de CPU: suma los vCPU asignados a esos workloads; el nodo de backup debe poder ejecutar al menos el 70 % de esa suma sin throttling.
  • Memoria: reserva al menos 2 GB por VM crítico y añade un margen del 20 % para el propio Proxmox y la replicación.

2. Evaluar el rendimiento sostenido del i5‑13240H

  • Ejecuta pruebas de estrés con stress-ng o sysbench durante 30 min para observar la frecuencia de turbo y el consumo de energía.
  • Verifica que la temperatura se mantenga bajo 80 °C; si supera este umbral, considera una solución de refrigeración externa.

3. Dimensionar la RAM

  • Si la placa permite hasta 64 GB DDR5, instala al menos 16 GB para cubrir la carga prevista y dejar espacio para snapshots.
  • Configura vm.swappiness=1 en /etc/sysctl.conf para minimizar el uso de swap bajo carga de VM.

4. Planificar almacenamiento redundante

  • Usa el NVMe de 512 GB como disco de arranque y para los VMs críticos.
  • Añade un disco SATA de 2 TB en modo RAID‑1 software (mdadm) para backups y snapshots.
  • Configura ZFS con compression=lz4 y recordsize=8K para reducir la escritura en el SSD.

5. Mejorar la conectividad de red

  • Instala una tarjeta PCIe x1 2.5 GbE (por ejemplo, Intel I210) si la placa tiene ranura disponible.
  • Configura bonding (mode=802.3ad) entre la NIC integrada y la tarjeta adicional para redundancia y mayor ancho de banda.

6. Configurar Proxmox HA

  • Añade el nodo al clúster y habilita el recurso pve-ha-manager.
  • Define grupos de recursos con prioridad baja para los VMs que pueden vivir en el nodo de respaldo.
  • Usa fence basado en IPMI o ssh para garantizar que el nodo fallido sea aislado correctamente.
# Crear grupo de recursos HA con prioridad 200 (baja)
pvecm addnode backup-node
ha-manager add group backup-group --priority 200
ha-manager add vm 101 backup-group
ha-manager add lxc 102 backup-group

7. Automatizar backups

  • Programa vzdump en el nodo de backup para crear snapshots diarios de los VMs críticos y enviarlos al disco RAID‑1.
  • Habilita la retención de 7 días y la compresión gzip para ahorrar espacio.
# Programar backup diario a las 02:00
echo "0 2 * * * root /usr/sbin/vzdump 101 --mode snapshot --compress gzip --storage local-raid1" >> /etc/crontab

Cuándo aplicar esta solución

  • Escenarios ideales: entornos de oficina o pymes con menos de 20 VMs, donde la carga de CPU es moderada y la disponibilidad de red es crítica pero no a nivel de datacenter.
  • Síntomas que indican necesidad: fallos intermitentes del nodo principal, pérdida de datos tras fallas de SSD, o migraciones en vivo que se quedan colgadas por ancho de banda insuficiente.
  • Casos donde no aplica: clusters con más de 30 VMs de alta demanda, bases de datos transaccionales intensivas, o requisitos de latencia ultra‑baja que demandan CPUs de servidor y NICs de 10 GbE.

Verificación

  1. Prueba de failover: apaga el nodo principal y verifica que los VMs críticos arranquen automáticamente en el nodo de backup.
  2. Monitoreo de recursos: usa htop y pveperf durante 24 h para confirmar que CPU y RAM permanecen por debajo del 80 % de uso.
  3. Integridad de backups: restaura una VM de prueba desde el backup y comprueba que el checksum de los discos coincida con el original.
  4. Latencia de red: ejecuta iperf3 entre los nodos; los resultados deben superar 1 Gbps para evitar cuellos de botella en replicación.

Notas adicionales

  • Refrigeración: los mini‑PCs no están diseñados para operar 24/7 bajo carga; una base de refrigeración con ventilador adicional prolonga la vida útil del CPU.
  • Firmware y BIOS: actualiza a la última versión disponible antes de instalar Proxmox; algunas BIOS limitan la frecuencia de la PCIe cuando se usa una tarjeta de red adicional.
  • Licenciamiento: Proxmox permite añadir nodos sin costo adicional, pero la suscripción de soporte puede ser útil para recibir actualizaciones de seguridad en hardware menos común.
  • Escalabilidad: si la carga crece, considera migrar a un servidor con CPU Xeon o AMD EPYC; el proceso de migración es transparente gracias a la arquitectura de clúster de Proxmox.