Proxmox VE se ha convertido en una de las alternativas más serias para empresas que quieren recuperar control sobre su infraestructura de virtualización. Su base open source, su integración con KVM y LXC, su capacidad de clustering, la alta disponibilidad, Ceph, ZFS y Proxmox Backup Server lo han situado en el radar de CIOs, CTOs y equipos de sistemas que buscan una plataforma potente sin depender de modelos de licenciamiento cerrados.
Pero Proxmox no debe entenderse solo como una forma de reducir costes frente a VMware. Esa lectura se queda corta. En producción, Proxmox es una plataforma de infraestructura crítica y exige el mismo rigor que cualquier entorno empresarial: red bien diseñada, almacenamiento adecuado, quorum, alta disponibilidad, backup, monitorización, pruebas de fallo y operación diaria.
En Stackscale lo vemos cada vez más en proyectos de cloud privado. Muchas empresas no quieren simplemente “migrar a Proxmox”. Quieren construir una plataforma estable, controlada y preparada para crecer. Para eso no basta con instalar Proxmox en varios servidores. Hay que diseñar la arquitectura que hay debajo.
Proxmox no empieza en el hipervisor, empieza en la arquitectura
Uno de los errores más habituales al plantear Proxmox es empezar por la interfaz de administración o por la creación de máquinas virtuales. Es comprensible: Proxmox VE tiene una experiencia de uso muy directa y permite levantar VMs y contenedores con rapidez. Pero en un entorno real, la estabilidad no depende solo del hipervisor.
Depende de cómo se han diseñado los nodos, de cómo se separan las redes, de qué almacenamiento se utiliza, de cómo se resuelve el quorum, de qué ocurre si un nodo cae, de dónde están las copias de seguridad y de cuánto margen existe para crecer sin rediseñar todo el entorno.
| Capa de diseño | Pregunta que debe resolverse antes de producción |
|---|---|
| Computación | ¿Cuántos nodos hacen falta y qué margen queda ante fallo? |
| Red | ¿Están separados gestión, migración, almacenamiento, backup y tráfico de cliente? |
| Almacenamiento | ¿Se usará almacenamiento local, Ceph, NFS/iSCSI, almacenamiento en red o síncrono? |
| Alta disponibilidad | ¿Qué VMs deben reiniciarse automáticamente y dónde? |
| Quorum | ¿El clúster puede tomar decisiones seguras ante fallos? |
| Backup | ¿Dónde están las copias, cómo se verifican y cuánto tarda una restauración? |
| Operación | ¿Hay monitorización, alertas, documentación y procedimientos de mantenimiento? |
Esta diferencia es la que separa un laboratorio funcional de una infraestructura empresarial. En un laboratorio basta con que las VMs arranquen. En producción hay que preguntarse qué ocurre cuando un host falla a las tres de la mañana, cuando el almacenamiento se acerca al límite, cuando una migración coincide con un pico de carga o cuando una restauración se convierte en la única vía de recuperación.
Nodos dedicados: la base del cloud privado con Proxmox
En un cloud privado basado en Proxmox, los nodos de computación son una pieza central. No son simples servidores donde “caben” máquinas virtuales. Son la base sobre la que se distribuyen CPU, memoria, conectividad, disponibilidad y mantenimiento.
Stackscale plantea este tipo de entornos sobre nodos dedicados, lo que permite a cada cliente disponer de recursos de computación exclusivos, sin vecinos ruidosos ni competencia directa por CPU o RAM con terceros. Esta separación es importante cuando la infraestructura soporta ERP, bases de datos, ecommerce, escritorios virtuales, plataformas SaaS, sistemas internos o aplicaciones de clientes.
La ventaja de Proxmox sobre nodos dedicados no está solo en el rendimiento. También está en la previsibilidad. El equipo técnico sabe qué hardware tiene, qué capacidad real existe, cuánto se puede sobreaprovisionar, qué margen queda ante fallo y cuándo conviene añadir nuevos nodos.
| Decisión sobre nodos | Impacto operativo |
|---|---|
| Número mínimo de nodos | Determina HA, quorum y tolerancia a fallos |
| CPU y memoria por nodo | Condiciona densidad de VMs y overcommit |
| Redundancia | Permite mantenimiento sin parada completa del entorno |
| Homogeneidad de hardware | Simplifica migraciones, balanceo y operación |
| Margen libre | Evita que un fallo deje al clúster sin capacidad suficiente |
| Pool de nodos de reserva | Reduce tiempos de recuperación ante fallo físico |
Un clúster con tres nodos puede ser suficiente para muchos entornos iniciales, pero no todos los clústeres de tres nodos son iguales. Si los tres están llenos al 90 %, la alta disponibilidad será teórica: al caer uno, los otros dos no tendrán capacidad real para absorber la carga. Por eso el sizing debe contemplar el fallo, no solo el día normal de operación.
La pregunta no debería ser “cuántas VMs caben”. La pregunta correcta es: “cuántas VMs pueden seguir funcionando si pierdo un nodo y necesito mantener servicio”.
La red decide buena parte del comportamiento del clúster
Proxmox puede mover máquinas virtuales entre nodos, gestionar alta disponibilidad y trabajar con distintos tipos de almacenamiento. Pero todas esas capacidades dependen de la red. Si la red está mal diseñada, el clúster lo acabará mostrando en forma de latencia, migraciones lentas, backups que afectan a producción o problemas de comunicación entre nodos.
En un entorno profesional conviene separar, al menos de forma lógica, varios tipos de tráfico: gestión, Corosync, migración, almacenamiento, backup y tráfico de cliente. En proyectos más exigentes, esa separación también debe llevarse al plano físico o a redes dedicadas con ancho de banda garantizado.
| Tipo de tráfico | Riesgo si se mezcla sin control |
|---|---|
| Gestión | Exposición innecesaria y dificultad para operar en incidencias |
| Corosync / clúster | Pérdida de estabilidad si hay latencia o paquetes perdidos |
| Migración | Degradación de VMs si compite con tráfico de producción |
| Almacenamiento | Latencia alta en discos virtuales y bases de datos |
| Backup | Impacto en horas críticas si no se limita o planifica |
| Cliente | Contención con tráfico interno del clúster |
Corosync merece una mención especial. Es la base de la comunicación del clúster y del quorum. No debería convivir alegremente con tráfico pesado ni depender de enlaces inestables. Una red saturada puede no tumbar las VMs de inmediato, pero puede hacer que la gestión del clúster sea menos fiable justo cuando se necesita tomar decisiones rápidas.
La migración en caliente también depende de esta capa. En Proxmox funciona muy bien cuando el diseño acompaña, pero una VM grande con mucha memoria y alta actividad de escritura puede tardar más de lo esperado si la red de migración no tiene capacidad suficiente. La conclusión es sencilla: la red no se diseña al final. Se diseña antes de crear la primera VM de producción.
Almacenamiento en red: mucho más que capacidad
El almacenamiento suele ser la parte que más condiciona un entorno Proxmox. Y también una de las más subestimadas. En producción no basta con mirar terabytes disponibles. Hay que mirar latencia, IOPS, ancho de banda, redundancia, snapshots, replicación, recuperación, crecimiento y mantenimiento.
Proxmox permite trabajar con múltiples opciones: almacenamiento local, ZFS, Ceph, NFS, iSCSI, Fibre Channel, cabinas externas o almacenamiento en red. Cada opción tiene sentido en determinados escenarios, pero ninguna es universal.
| Opción de almacenamiento | Ventaja principal | Precaución |
|---|---|---|
| Local SSD/NVMe | Muy buen rendimiento local | Menor flexibilidad para HA si no hay replicación |
| ZFS local | Snapshots, integridad y gestión avanzada | Requiere RAM, planificación y no llenar el pool |
| Ceph | Almacenamiento distribuido integrado | Necesita nodos, discos y red bien dimensionados |
| NFS/iSCSI | Integración sencilla con almacenamiento compartido | Depende de cabina/red y diseño de disponibilidad |
| Almacenamiento en red dedicado | Separa computación y datos | Requiere baja latencia y redundancia real |
| Almacenamiento síncrono | Muy bajo RPO y continuidad avanzada | Mayor exigencia de arquitectura y coste |
En Stackscale, Proxmox puede apoyarse en almacenamiento en red y almacenamiento síncrono diseñado para desacoplar computación y datos. Esta separación permite escalar nodos de computación y almacenamiento de forma más independiente, facilita ciertos escenarios de recuperación y reduce la dependencia del disco local de cada host.
Esto no significa que Ceph o ZFS no sean buenas opciones. Lo son, cuando encajan. Ceph puede ser muy potente en entornos con suficientes nodos, red rápida y operación especializada. ZFS es una tecnología excelente para integridad, snapshots y rendimiento local. Pero en entornos empresariales donde se busca una plataforma de cloud privado gestionable y predecible, el almacenamiento en red puede aportar una base sólida para operación, crecimiento y continuidad.
El punto importante es no convertir el almacenamiento en una decisión improvisada. Muchas incidencias de virtualización empiezan como problemas de storage: pools demasiado llenos, latencia creciente, snapshots olvidados, backups que saturan enlaces, cabinas sin margen o discos que no responden como se esperaba bajo carga.
HA en Proxmox: qué hace y qué no hace
La alta disponibilidad de Proxmox VE permite reiniciar automáticamente máquinas virtuales o contenedores en otro nodo cuando el nodo original falla. Es una función muy valiosa y una de las razones por las que Proxmox puede usarse en entornos empresariales. Pero conviene entender bien sus límites.
HA no significa que una VM no se vaya a interrumpir nunca. Si un nodo cae, la VM debe arrancar en otro nodo. Eso implica un tiempo de recuperación. Para muchas cargas es aceptable. Para otras, no. Una base de datos crítica, una aplicación transaccional o un sistema con usuarios conectados puede necesitar además replicación a nivel de aplicación, balanceadores, clústeres internos o mecanismos propios de tolerancia a fallos.
| Concepto | Qué protege | Qué no sustituye |
|---|---|---|
| Proxmox HA | Fallo de nodo y reinicio automático de VMs | Alta disponibilidad de la aplicación |
| Live migration | Movimiento planificado de VMs entre nodos | Recuperación ante caída brusca del host |
| Backup | Recuperación de datos y sistemas | Continuidad inmediata |
| Replicación de aplicación | Continuidad del servicio a nivel software | Backup histórico |
| DR | Recuperación ante caída de ubicación o desastre | Operación normal del clúster local |
La confusión entre HA, backup y disaster recovery es frecuente. HA ayuda a recuperar servicio ante la caída de un nodo. Backup permite recuperar datos o sistemas en un punto anterior. DR permite responder ante una caída mayor, como la pérdida de un CPD, un error grave de plataforma o un incidente de seguridad. Son capas distintas y deben convivir.
Quorum: el pequeño detalle que decide el clúster
En Proxmox, como en otros sistemas de clúster, el quorum es lo que permite tomar decisiones evitando situaciones peligrosas como split-brain. Si el clúster no tiene quorum, puede bloquear determinadas operaciones para proteger la consistencia.
Por eso los clústeres de dos nodos deben tratarse con especial cuidado. Pueden tener sentido en escenarios concretos, pero normalmente requieren un qdevice o un diseño muy bien probado. En entornos de producción, el enfoque más habitual y recomendable es partir de al menos tres nodos para disponer de un quorum más fiable.
| Diseño de clúster | Lectura práctica |
|---|---|
| 1 nodo | No hay alta disponibilidad real |
| 2 nodos sin qdevice | Riesgo elevado de pérdida de quorum |
| 2 nodos con qdevice | Puede funcionar en escenarios controlados |
| 3 nodos | Base habitual para HA fiable |
| 4+ nodos | Mejor capacidad de crecimiento y mantenimiento |
El quorum no se debe descubrir durante una incidencia. Hay que probarlo antes. Simular caída de nodo, pérdida de red, reinicio controlado y mantenimiento ayuda a saber cómo se comporta el clúster y evita sorpresas en producción.
Snapshots, backups y Proxmox Backup Server
Los snapshots son útiles, pero no son backups. Esta frase se repite mucho porque sigue siendo uno de los errores más comunes en virtualización. Un snapshot sirve para conservar el estado de una VM durante una ventana corta: una actualización, un cambio de configuración, una prueba controlada o un despliegue. Si se mantiene demasiado tiempo, puede crecer, consumir almacenamiento y complicar el rendimiento.
El backup debe diseñarse de otra manera. En entornos Proxmox, Proxmox Backup Server aporta copias incrementales, deduplicación, verificación, cifrado y una integración muy natural con Proxmox VE. En Stackscale, PBS puede combinarse con almacenamiento Archive vía NFS o acceso compatible S3, además de capas de almacenamiento en red más rápidas cuando se necesita reducir tiempos de restauración.
| Elemento | Uso correcto |
|---|---|
| Snapshot | Cambio temporal y ventana corta |
| Backup local | Recuperación rápida, pero no suficiente como única copia |
| Proxmox Backup Server | Copias incrementales, deduplicadas y verificables |
| Archive storage | Retención y copia separada para largo plazo |
| Copia en otro CPD | Protección frente a fallo mayor de ubicación |
| Prueba de restauración | Validación real de que el backup sirve |
Una política de backup profesional debe responder a preguntas concretas: cada cuánto se copia, cuánto se retiene, dónde está la copia, quién puede borrarla, cómo se verifica, cuánto tarda una restauración y qué sistemas se recuperan primero.
Un backup que no se ha restaurado nunca no es una garantía. Es una hipótesis.
Sizing y overcommit: eficiencia sin poner en riesgo el clúster
Proxmox permite aprovechar bien CPU y memoria, pero el overcommit no es una barra libre. Asignar demasiadas vCPU o demasiada RAM sin medir uso real acaba generando contención. El problema no siempre aparece al principio. Aparece cuando varias VMs consumen recursos al mismo tiempo, cuando se ejecutan backups, cuando una base de datos crece o cuando un nodo falla y el resto debe absorber su carga.
| Recurso | Riesgo de mal sizing | Buena práctica |
|---|---|---|
| vCPU | Contención y latencia de CPU | Medir uso real y evitar asignaciones excesivas |
| RAM | Swapping o falta de margen ante fallo | Reservar capacidad para picos y HA |
| Disco | Latencia e I/O wait | Medir IOPS, no solo capacidad |
| Red | Cuellos de botella en migración, backup y storage | Separar tráfico y dimensionar enlaces |
| Backup | Impacto en producción | Ventanas, límites y monitorización |
| HA | Falta de capacidad al caer un nodo | Diseñar con margen N+1 o equivalente |
En cloud privado, el sizing debe revisarse de forma continua. Las cargas cambian. Una VM que hoy consume poco puede convertirse mañana en crítica. Un entorno que empezó con diez VMs puede crecer hasta cien. La ventaja de una infraestructura bien diseñada es que permite añadir nodos, ampliar almacenamiento y ajustar recursos sin tener que rehacer toda la plataforma.
Monitorización y operación: la diferencia entre instalar y gestionar
Una plataforma Proxmox bien diseñada necesita operación. Monitorización de nodos, almacenamiento, red, backups, latencia, capacidad, errores SMART, uso de CPU, memoria, I/O wait, estado de HA y tareas programadas. También necesita alertas útiles, no ruido. Si todo alerta, nada alerta.
La operación también incluye procedimientos: cómo se actualiza un nodo, cómo se evacuan VMs antes de mantenimiento, cómo se prueba HA, cómo se revisan backups, cómo se documentan cambios, cómo se gestionan accesos y cómo se responde ante una degradación de almacenamiento.
Proxmox tiene una ventaja importante: es transparente. Permite ver muchas capas del sistema, trabajar con herramientas Linux conocidas y automatizar mediante API y CLI. Pero esa transparencia exige conocimiento. No elimina la necesidad de administración. La hace más visible.
Proxmox como base de cloud privado en Stackscale
Para muchas empresas, el valor de Proxmox no está solo en el ahorro de licencias. Está en la posibilidad de construir un cloud privado abierto, flexible y controlado. En Stackscale, esa arquitectura puede apoyarse en nodos dedicados, redes privadas, almacenamiento en red, almacenamiento síncrono, backup, monitorización, soporte y opciones multi-CPD.
Este enfoque permite separar responsabilidades. Stackscale aporta la base física, conectividad, CPD, hardware, red, almacenamiento y soporte de infraestructura. El cliente puede centrarse en sus sistemas, aplicaciones, seguridad, datos y evolución de la plataforma.
| Necesidad empresarial | Enfoque con Proxmox sobre Stackscale |
|---|---|
| Control de infraestructura | Nodos dedicados y entorno de uso exclusivo |
| Reducción de dependencia propietaria | Plataforma Proxmox VE open source |
| Continuidad | HA, almacenamiento en red, backup y opciones multi-CPD |
| Crecimiento | Ampliación de nodos y almacenamiento según demanda |
| Migración desde VMware | Diseño de entorno destino, piloto y transición por fases |
| Recuperación | Proxmox Backup Server, Archive y pruebas de restauración |
| Operación | Monitorización, soporte y procedimientos técnicos |
La idea no es presentar Proxmox como una solución mágica. No lo es. Proxmox funciona muy bien cuando se diseña con rigor. También puede generar problemas si se despliega como una instalación rápida sin arquitectura. Lo mismo ocurre con cualquier plataforma de virtualización en producción.
La diferencia está en asumirlo desde el principio: Proxmox no es virtualización barata. Es infraestructura crítica cuando soporta cargas críticas.
Resumen técnico para administradores
| Área | Recomendación rápida |
|---|---|
| Clúster | Diseñar con al menos tres nodos cuando se busque HA fiable |
| Quorum | Probar pérdida de nodo y comportamiento del clúster antes de producción |
| Red | Separar gestión, migración, almacenamiento, backup y cliente |
| Storage | Elegir según carga: red, Ceph, ZFS, síncrono o combinación |
| HA | Usarla para reinicio automático, no como sustituto de HA de aplicación |
| Backup | Usar PBS, retención, verificación y restauraciones probadas |
| Capacidad | Alertar antes del límite, no cuando el pool ya está lleno |
| Sizing | Medir consumo real y reservar margen ante fallo |
| Operación | Documentar cambios, actualizar por fases y monitorizar todo |
Preguntas frecuentes
¿Proxmox es una alternativa real a VMware para cloud privado?
Sí, siempre que se diseñe como plataforma de producción. Proxmox VE puede ser una base sólida para cloud privado si se combina con clustering, almacenamiento adecuado, red bien segmentada, alta disponibilidad, backup y operación profesional.
¿Hace falta almacenamiento compartido para usar Proxmox HA?
Para muchos escenarios de HA es necesario que las VMs puedan arrancar en otros nodos con acceso a sus discos, ya sea mediante almacenamiento compartido, almacenamiento distribuido o replicación bien diseñada. La arquitectura exacta depende del caso de uso.
¿Ceph es obligatorio en Proxmox?
No. Ceph es una opción potente, especialmente para almacenamiento distribuido, pero no es obligatoria. Proxmox también puede trabajar con almacenamiento local, ZFS, NFS, iSCSI, Fibre Channel, almacenamiento en red o cabinas externas.
¿Los snapshots de Proxmox sirven como backup?
No. Los snapshots son útiles para ventanas cortas de mantenimiento, pero no sustituyen una estrategia de backup. Para copias reales conviene usar Proxmox Backup Server u otra solución de backup, con retención, verificación y pruebas de restauración.
¿Qué aporta Stackscale en un proyecto Proxmox?
Stackscale aporta infraestructura de cloud privado con nodos dedicados, conectividad, almacenamiento en red, opciones de almacenamiento síncrono, backup, monitorización y soporte especializado para diseñar y operar entornos Proxmox de producción.
