Proxmox cluster de 3 nodos: cuándo conviene, qué hardware necesitas y cómo diseñar HA
Una de las preguntas más frecuentes cuando una empresa comienza a evaluar Proxmox VE es:
¿Necesito uno, dos o tres servidores?
La respuesta depende del objetivo.
Un servidor Proxmox independiente puede ser perfectamente válido para determinados ambientes.
Dos nodos pueden utilizarse en algunas arquitecturas específicas.
Pero cuando hablamos de una plataforma empresarial donde queremos cluster, quorum fiable y alta disponibilidad, tres nodos suelen convertirse en un punto de partida especialmente interesante.
Sin embargo, comprar tres servidores y agregarlos a un cluster no significa automáticamente que tengamos una plataforma altamente disponible.
También debemos diseñar:
- CPU
- Memoria RAM
- Storage
- Networking
- Corosync
- Quorum
- Switching
- Backup
- Energía
- Capacidad ante falla
En esta guía de la Biblioteca Virtual Sistro 2.0 explicamos cómo analizar una arquitectura Proxmox de tres nodos antes de comprar hardware.
Conoce nuestras soluciones de Virtualización Empresarial
¿Qué es un cluster Proxmox?
Un cluster Proxmox permite agrupar varios servidores físicos para administrarlos como una infraestructura conjunta.
Proxmox VE utiliza Corosync para la comunicación del cluster y su sistema de archivos distribuido pmxcfs mantiene información de configuración disponible entre los nodos.
Esto permite disponer de funciones como:
- Administración centralizada
- Migración de máquinas virtuales
- Configuración compartida del cluster
- Servicios de alta disponibilidad
- Administración conjunta de recursos
Un cluster no significa necesariamente que HA esté habilitado.
Cluster y High Availability son conceptos relacionados, pero no son exactamente lo mismo.
¿Por qué se habla tanto de tres nodos?
La razón principal es el quorum.
En un sistema distribuido debemos evitar que diferentes partes del cluster crean simultáneamente que tienen autoridad para operar.
Ese problema puede provocar condiciones peligrosas conocidas generalmente como split brain.
Para ayudar a evitarlo, Corosync utiliza un sistema de votación.
En un cluster de tres nodos podemos tener:
Nodo 1 = 1 voto
Nodo 2 = 1 voto
Nodo 3 = 1 voto
Con dos nodos disponibles todavía existe mayoría.
Por eso tres nodos proporcionan una arquitectura mucho más natural para obtener quorum fiable en HA.
¿Qué ocurre si falla un nodo?
Supongamos:
PVE01 + PVE02 + PVE03
Si PVE01 presenta una falla, PVE02 y PVE03 continúan disponibles y mantienen mayoría de votos.
Si existen máquinas virtuales protegidas por HA y la arquitectura está correctamente diseñada, Proxmox HA Manager puede intentar recuperar esas cargas en otro nodo disponible.
Pero aquí aparece una condición fundamental:
El nodo restante debe tener capacidad para ejecutar esas máquinas virtuales.
El error de dimensionar los tres nodos al 100%
Supongamos tres servidores, cada uno con 256 GB de RAM.
Tenemos en total:
768 GB de RAM física.
Podría parecer que podemos utilizar prácticamente los 768 GB.
Pero si queremos sobrevivir a la falla de un nodo, debemos preguntarnos:
¿Dónde correrán las máquinas virtuales de ese servidor cuando falle?
Si los otros dos nodos ya se encuentran saturados, tener HA configurado no resolverá el problema.
Diseña para N+1
Una filosofía muy útil consiste en diseñar capacidad N+1.
Esto significa que la plataforma debería mantener capacidad suficiente para operar las cargas importantes aun cuando uno de los nodos no esté disponible.
En un cluster de tres nodos debemos analizar:
- CPU utilizada
- RAM utilizada
- Reserva necesaria
- Máquinas críticas
- Prioridades de HA
- Crecimiento esperado
No siempre tenemos que garantizar capacidad para absolutamente todas las VMs.
Podemos establecer prioridades.
Clasifica las máquinas por criticidad
Por ejemplo:
Grupo A — Críticas
- ERP
- Active Directory
- DNS
- Base de datos
- Aplicaciones productivas
Grupo B — Importantes
- File servers
- Aplicaciones departamentales
- Herramientas internas
Grupo C — No críticas
- Laboratorios
- Desarrollo
- Servidores temporales
- Ambientes de prueba
Ante una falla podemos garantizar primero los recursos necesarios para el Grupo A.
¿Qué hardware necesita un nodo Proxmox?
No existe una configuración universal.
El hardware debe seleccionarse después de revisar las cargas actuales y futuras.
Debemos dimensionar:
- Procesadores
- Número de cores
- Memoria RAM
- Interfaces de red
- Discos
- Controladoras
- HBAs
- Fuentes redundantes
- Capacidad de expansión
Por eso en Sistro comenzamos este tipo de proyectos con un assessment y capacity planning.
Consulta nuestro servicio de Instalación y Configuración Proxmox VE Empresarial
CPU: no dimensionemos solamente por vCPU
Una VM con ocho vCPU asignadas no significa necesariamente que consuma ocho cores permanentemente.
Antes de comprar servidores debemos revisar utilización real.
Conviene analizar:
- CPU promedio
- Picos
- CPU Ready o métricas equivalentes del ambiente origen
- Ratio de consolidación
- Cargas sensibles a latencia
- Crecimiento
Una infraestructura sobredimensionada puede aumentar innecesariamente el CAPEX.
Una plataforma demasiado ajustada puede comprometer HA.
RAM: probablemente uno de los recursos más importantes
En muchos ambientes de virtualización la memoria termina siendo el recurso que limita la consolidación.
Debemos considerar:
- RAM asignada actualmente
- RAM realmente utilizada
- Overcommit
- Reserva del host
- Crecimiento
- Capacidad N+1
También debemos recordar que determinadas tecnologías de almacenamiento pueden utilizar memoria adicional.
Networking: un cluster Proxmox no debería depender de una sola NIC
Otro error habitual consiste en comprar excelentes servidores y conectarlos mediante una infraestructura de red insuficiente.
Podemos necesitar redes para:
- Administración
- Máquinas virtuales
- Corosync
- Storage
- Live Migration
- Backup
- Ceph
Dependiendo del tamaño del proyecto, estas redes pueden utilizar interfaces físicas independientes, bonding, VLAN o una combinación de ambas.
Corosync necesita una red estable
Corosync es fundamental para el funcionamiento del cluster.
No necesita necesariamente cantidades enormes de ancho de banda, pero sí necesita una comunicación estable y de baja latencia.
No deberíamos diseñar Corosync sobre una red congestionada o poco confiable.
Para infraestructura empresarial debemos considerar:
- Red estable
- Baja latencia
- Redundancia
- Switches adecuados
- Interfaces correctamente configuradas
- MTU consistente
¿Necesito switches redundantes?
Si buscamos una infraestructura realmente altamente disponible, debemos revisar también el switching.
Podemos tener tres nodos Proxmox perfectamente configurados.
Pero si todos dependen de:
un solo switch
ese switch se convierte en un punto único de falla.
Una arquitectura más resistente puede utilizar:
Switch A + Switch B
con enlaces redundantes desde los nodos cuando el diseño lo permita.
¿Qué velocidad de red necesito?
Depende del workload.
No existe una regla de que todo cluster Proxmox necesite exactamente la misma velocidad.
Debemos revisar:
- Tráfico de las VMs
- Live Migration
- Storage
- Backup
- Ceph
- Número de nodos
- Crecimiento
Una pequeña infraestructura puede tener requisitos muy diferentes de un cluster hiperconvergente con Ceph.
El almacenamiento cambia completamente la arquitectura
Después de CPU, memoria y red debemos responder:
¿Dónde van a vivir los discos de las máquinas virtuales?
Proxmox puede trabajar con diferentes tecnologías.
Entre ellas:
- ZFS
- LVM-Thin
- NFS
- iSCSI
- SAN
- NAS
- Fibre Channel
- Ceph
- Almacenamiento local
- Storage compartido
Conoce las arquitecturas de almacenamiento que integramos en Sistro
Opción 1: cluster Proxmox con SAN existente
Una empresa que ya tiene almacenamiento empresarial no necesariamente debe reemplazarlo al migrar a Proxmox.
Podemos evaluar tecnologías como:
- iSCSI
- Fibre Channel
- NFS
- Multipath
La decisión depende del fabricante, modelo, conectividad y requerimientos del proyecto.
Reutilizar una SAN existente puede reducir la inversión de una migración cuando técnicamente es viable.
Opción 2: Proxmox + Ceph
Otra alternativa es construir una infraestructura hiperconvergente utilizando Ceph.
En este modelo los propios nodos proporcionan cómputo y almacenamiento distribuido.
Esto puede ser muy atractivo.
Pero Ceph debe diseñarse correctamente.
Debemos estudiar:
- Número de nodos
- Número de discos
- Tipo de discos
- Red
- IOPS
- Latencia
- Replicación
- Capacidad útil
- Crecimiento
Instalar Ceph porque aparece como opción en Proxmox no equivale a diseñar correctamente Ceph.
¿Tres nodos son suficientes para Ceph?
Tres nodos pueden utilizarse como punto de partida para determinados clusters Ceph, pero el hecho de que técnicamente sea posible no significa que sea la arquitectura ideal para cualquier carga.
Debemos revisar la cantidad y tipo de discos, red, capacidad requerida, rendimiento y comportamiento cuando uno de los nodos falla.
Para cargas de mayor tamaño puede resultar conveniente utilizar más nodos.
Opción 3: almacenamiento local
También puede haber proyectos donde cada host utiliza almacenamiento local.
Esta arquitectura puede ser válida dependiendo de los objetivos.
Pero debemos conocer las implicaciones para:
- HA
- Migración
- Replicación
- Recuperación
No debemos asumir que un cluster obliga siempre a utilizar Ceph.
Cluster no significa HA automático
Podemos agregar tres nodos al mismo cluster únicamente para:
- Administrarlos centralmente
- Mover determinadas VMs
- Compartir configuraciones
Para disponer de High Availability debemos además definir y proteger las cargas correspondientes.
El HA Manager de Proxmox puede supervisar VMs y contenedores configurados como recursos HA y reaccionar ante determinadas fallas de nodos.
¿Qué ocurre cuando un host falla?
Es importante entender algo:
HA no convierte mágicamente una VM que estaba ejecutándose en otro host sin ninguna interrupción.
Ante una falla física abrupta, la máquina virtual protegida normalmente necesita recuperarse en otro nodo disponible.
Esto es diferente de Live Migration.
HA vs Live Migration
Live Migration
El servidor origen todavía está funcionando.
Movemos una VM hacia otro nodo durante mantenimiento o balanceo.
High Availability
El nodo puede haber fallado inesperadamente.
El cluster intenta recuperar la carga protegida en otro host.
Son problemas diferentes.
¿Entonces HA tiene downtime?
Ante una falla abrupta puede existir un periodo de indisponibilidad mientras el cluster detecta el problema y la carga vuelve a arrancar en otro nodo.
Por eso no debemos vender HA como:
“cero downtime ante cualquier falla”.
Debemos hablar de:
reducción del tiempo de recuperación y automatización de la recuperación.
¿Qué pasa con las aplicaciones que realmente no pueden detenerse?
Si una aplicación requiere niveles de disponibilidad superiores, también debemos diseñarla a nivel aplicativo.
Por ejemplo:
- Cluster de base de datos
- Balanceadores
- Replicación
- Servicios activos en múltiples VMs
- Arquitecturas distribuidas
La virtualización es solamente una capa de la disponibilidad.
Un cluster de 3 nodos tampoco reemplaza el backup
Este error es especialmente peligroso.
HA protege contra determinadas fallas de infraestructura.
No necesariamente protege contra:
- Borrado accidental
- Ransomware
- Corrupción
- Error de aplicación
- Error humano
- Eliminación de una VM
Seguimos necesitando backup.
Proxmox Backup Server
Dentro del ecosistema Proxmox podemos integrar Proxmox Backup Server para proteger máquinas virtuales y contenedores.
Pero recomendamos analizar la arquitectura de backup de manera independiente.
Por ejemplo:
- RPO
- RTO
- Retención
- Repositorio
- Copias externas
- Inmutabilidad cuando aplique
- Pruebas de restauración
¿Puedo utilizar Veeam?
Si la empresa ya utiliza Veeam, debemos evaluar la compatibilidad de las versiones actuales y el diseño de respaldo antes de sustituir la plataforma existente.
Una migración hacia Proxmox no necesariamente implica cambiar simultáneamente todas las demás tecnologías.
Arquitectura básica de tres nodos
Podemos visualizarla así:
Switching redundante
↓
PVE01 + PVE02 + PVE03
↓
Storage compartido o distribuido
↓
Proxmox Backup Server / plataforma de backup
Con redes separadas o correctamente segmentadas para:
- Management
- VMs
- Corosync
- Storage
- Migration
- Backup
Escenario 1: pequeña empresa
Supongamos:
- 5 VMs
- Una aplicación administrativa
- Active Directory
- Servidor de archivos
- Horario de oficina
- Presupuesto limitado
Quizá un cluster de tres nodos no sea todavía la inversión prioritaria.
Podría tener más sentido comenzar con:
- Un buen servidor
- Storage adecuado
- Backup
- Equipo de reemplazo
La arquitectura debe corresponder con la criticidad.
Escenario 2: PyME con aplicaciones críticas
Supongamos:
- 25 máquinas virtuales
- ERP
- Base de datos
- Active Directory
- Aplicaciones productivas
- Operación extendida
Aquí un cluster de tres nodos puede comenzar a tener mucho sentido.
Podemos diseñarlo para sobrevivir a la pérdida de un host y recuperar automáticamente las cargas prioritarias.
Escenario 3: empresa migrando desde VMware
Este es un escenario cada vez más común.
La empresa ya tiene:
- Tres hosts VMware
- Storage compartido
- VLAN
- Backup
- 50 o más VMs
No sería correcto simplemente instalar Proxmox en tres servidores nuevos.
Primero debemos realizar:
Assessment → Capacity Planning → Diseño → PoC → Piloto → Migración.
Consulta nuestro checklist para migrar VMware a Proxmox
Consulta el servicio de Migración a Proxmox VE de Sistro
Escenario 4: infraestructura hiperconvergente
Una empresa que no dispone de SAN puede evaluar:
3 o más nodos Proxmox + Ceph
Pero antes debe validarse especialmente:
- Discos
- Red
- Latencia
- Capacidad
- IOPS
- Comportamiento ante falla
- Crecimiento
¿Puedo hacer un cluster de dos nodos?
Sí, existen arquitecturas de dos nodos.
Pero para resolver correctamente quorum suele ser necesario incorporar un tercer voto mediante un dispositivo externo conocido como QDevice u otro diseño técnicamente justificado.
Esto puede tener sentido en determinados ambientes.
Sin embargo, no deberíamos implementar dos nodos simplemente intentando ahorrar un servidor sin analizar las implicaciones.
¿Qué es un QDevice?
Un QDevice puede proporcionar un voto adicional al sistema de quorum sin convertirse en un nodo de cómputo completo.
Puede resultar útil en determinadas arquitecturas con un número par de nodos, especialmente pequeños clusters.
Pero debe alojarse en una infraestructura independiente y diseñarse correctamente.
¿Tres nodos siempre son mejores que dos?
No en términos absolutos.
La arquitectura correcta depende de:
- Disponibilidad requerida
- Presupuesto
- Número de VMs
- Capacidad
- Storage
- Ubicaciones físicas
- RPO
- RTO
Pero para un cluster empresarial de HA, tres nodos representan un punto de partida muy sólido.
¿Los tres servidores deben ser idénticos?
No existe una obligación absoluta de que todo el hardware sea idéntico para pertenecer al mismo cluster.
Sin embargo, utilizar nodos homogéneos puede simplificar considerablemente:
- Live Migration
- Compatibilidad de CPU
- Capacity Planning
- Operación
- Spare parts
- Mantenimiento
Para nuevas implementaciones empresariales normalmente preferimos una plataforma razonablemente homogénea.
Errores frecuentes al diseñar un cluster Proxmox
1. Comprar servidores antes de hacer capacity planning
El hardware debe salir del workload.
2. Utilizar toda la RAM disponible
Después no queda capacidad para absorber la falla de un nodo.
3. Pensar que cluster significa HA
Son conceptos diferentes.
4. Utilizar una sola red para todo
Management, VMs, storage, Corosync y backup pueden competir entre sí.
5. Dejar un único switch
Se convierte en un punto único de falla.
6. Instalar Ceph sin dimensionarlo
Ceph necesita diseño de discos, red y capacidad.
7. Pensar que HA elimina la necesidad de backup
No lo hace.
8. No reservar capacidad N+1
Las VMs no tendrán dónde recuperarse ante una falla.
9. No probar una falla real
Un cluster HA debe probarse antes de considerarlo terminado.
10. Prometer cero downtime
HA y Live Migration resuelven escenarios diferentes.
Checklist antes de cotizar un cluster Proxmox
Antes de comprar hardware deberíamos conocer:
- Número de máquinas virtuales
- vCPU
- RAM asignada
- RAM utilizada
- Capacidad de almacenamiento
- IOPS
- Latencia
- Crecimiento
- Aplicaciones críticas
- RPO
- RTO
- VLAN
- Interfaces de red
- Switches
- Storage actual
- SAN o NAS existente
- Backup actual
- Necesidad de HA
- Ventanas de mantenimiento
- Presupuesto
Las preguntas que Sistro debería hacer antes de recomendar tres nodos
- ¿Cuántas VMs tienes?
- ¿Cuáles son realmente críticas?
- ¿Cuánta CPU utilizan?
- ¿Cuánta memoria consumen?
- ¿Qué almacenamiento utilizas?
- ¿Cuántos IOPS necesitas?
- ¿Qué ocurre si un servidor falla?
- ¿Cuánto tiempo puede estar detenida una aplicación?
- ¿Necesitas Live Migration?
- ¿Necesitas HA?
- ¿Ya tienes SAN?
- ¿Estás evaluando Ceph?
- ¿Qué sistema de backup utilizas?
- ¿Cuánto esperas crecer durante los próximos tres o cinco años?
Después podemos seleccionar el hardware.
¿Qué debe incluir un proyecto de Proxmox empresarial?
En Sistro planteamos el proyecto por capas:
Assessment
Inventario y análisis del ambiente actual.
Capacity Planning
CPU, RAM, storage, IOPS, networking y crecimiento.
Arquitectura
Nodos, cluster, quorum, redes, almacenamiento, backup y seguridad.
Implementación
Instalación de Proxmox y configuración de la plataforma.
Pruebas
Live Migration, HA, backup y recuperación.
Operación
Monitoreo, soporte, actualizaciones y capacity planning continuo.
Soluciones Proxmox en Sistro
Virtualización Empresarial
https://sistro.net/virtualizacion
Proxmox VE
https://sistro.net/proxmox
Instalación y Configuración Proxmox VE
https://sistro.net/proxmox/instalacion-proxmox-ve
Migración a Proxmox VE
https://sistro.net/proxmox/migracion-proxmox-ve
Recomendación final
Un cluster Proxmox de tres nodos puede ser una excelente arquitectura para empresas que necesitan virtualización, mantenimiento flexible y alta disponibilidad.
Pero el número tres por sí solo no resuelve nada.
La plataforma debe diseñarse como un sistema completo:
Compute + RAM + Networking + Corosync + Quorum + Storage + HA + Backup + Capacidad N+1.
Una arquitectura bien diseñada debe poder responder una pregunta sencilla:
¿Qué ocurre cuando desconectamos físicamente uno de los servidores?
Si las cargas críticas no tienen dónde ejecutarse, el cluster puede existir técnicamente, pero la alta disponibilidad no está realmente resuelta.
¿Estás diseñando un cluster Proxmox?
En Sistro Networks podemos realizar un assessment de tu plataforma actual y dimensionar CPU, RAM, storage, networking, backup y capacidad ante falla antes de comprar los servidores.
Diseñamos la arquitectura para que el hardware responda a las cargas reales y al crecimiento de la empresa.
Consulta nuestro servicio de Instalación Proxmox VE Empresarial
Preguntas frecuentes
¿Cuántos nodos necesita un cluster Proxmox?
Proxmox permite crear clusters con diferentes cantidades de nodos. Para alta disponibilidad con quorum fiable, tres nodos constituyen un punto de partida común y recomendado.
¿Proxmox necesita tres nodos obligatoriamente?
No. Puede utilizarse un nodo independiente o diseñarse un cluster de dos nodos con mecanismos adicionales de quorum. La arquitectura depende de los objetivos.
¿Qué ocurre si falla un nodo de un cluster de tres?
Los otros dos mantienen mayoría de votos. Si existen cargas configuradas para HA y hay recursos y almacenamiento disponibles, pueden recuperarse en los nodos restantes.
¿Un cluster Proxmox necesita Ceph?
No. Proxmox puede trabajar con SAN, NAS, NFS, iSCSI, ZFS, almacenamiento local y otras tecnologías. Ceph es una alternativa para determinados diseños distribuidos.
¿Tres nodos Proxmox garantizan alta disponibilidad?
No por sí solos. También deben diseñarse quorum, networking, storage, capacidad disponible, switching, energía y HA.
¿Necesito reservar capacidad en los hosts?
Si quieres que las cargas puedan recuperarse cuando falla un nodo, los hosts restantes deben disponer de CPU y memoria suficientes.
¿Proxmox HA es lo mismo que Live Migration?
No. Live Migration mueve una carga mientras el nodo origen sigue disponible. HA busca recuperar cargas protegidas después de determinadas fallas.
¿HA reemplaza el backup?
No. La alta disponibilidad y el respaldo solucionan riesgos diferentes y deben utilizarse de manera complementaria.
Deja un Comentario