Proxmox era para homelabs hasta que alguien reportó 10,000 VMs

Proxmox VE se utiliza en cargas de trabajo de producción mucho más allá de pequeños homelabs, según operadores que reportan clústeres desde más de 100 hasta más de 10,000 máquinas virtuales. Son cifras comunicadas por ellos mismos, no totales de despliegues auditados; la prueba operativa real es si el almacenamiento, las copias de seguridad y el soporte sobreviven a los fallos.

Los relatos abarcaron clústeres repartidos en varias sedes, el diseño de Ceph, el monitoreo del hardware y la elección de herramientas de backup. Los números muestran casos de uso reales, mientras que las diferencias entre esos entornos explican por qué el recuento de VMs por sí solo resulta una prueba insuficiente de fiabilidad.

¿Qué tamaño tienen los despliegues de producción reportados en Proxmox?

Los operadores describieron instalaciones que van desde un clúster de cinco nodos con más de 100 VMs hasta un parque reportado que superaba las 10,000 VMs, sin verificación independiente.

Un operador reportó cerca de 1,000 VMs en producción distribuidas en seis ubicaciones. Al pedirle detalles, describió nueve clústeres con 41 servidores host, más tres hosts independientes utilizados principalmente para Proxmox Backup Server y unas pocas VMs adicionales. Su clúster individual más grande contaba con ocho nodos, y explicó que Proxmox Datacenter Manager le ofrecía una vista de gestión común. Esa distinción importa. Mil VMs distribuidas en clústeres independientes plantean un problema de ingeniería muy distinto a forzar mil cargas de trabajo dentro de un único dominio de fallo gigantesco. El usuario describía un conjunto de infraestructura coordinado, no un único punto de fallo masivo.

Luego llegó la afirmación más llamativa: otro participante indicó que su entorno abarca tres regiones, cada una con tres clústeres de 30 a 40 servidores, albergando más de 10,000 VMs en total. Describió almacenamiento NVMe, configuraciones de memoria generosas y múltiples conexiones de red de 25 Gb. Es un despliegue notable comunicado por el usuario, no una comparativa de rendimiento auditada ni una recomendación para copiar esa arquitectura. Otros casos resultaban más fáciles de imaginar: un operador del sector educativo europeo describió 400 VMs en doce servidores Dell PowerEdge, almacenamiento Pure Storage sobre iSCSI, redes Cisco y copias con Veeam. Otro participante mencionó unas 800 VMs repartidas en dos centros de datos. Queda claro que la típica imagen de un PC viejo en un homelab deja fuera a una parte importante de los usuarios.

Los relatos más pequeños pueden resultar aún más útiles. Una empresa describió el paso de un entorno VMware Essentials de tres hosts a un clúster de Proxmox de cinco nodos manteniendo sus servidores, almacenamiento y software de backup. Las pruebas de failover para un despliegue planeado de ERP salieron bien, aunque el equipo todavía buscaba mayor redundancia en la red y los firewalls. Otro operador explicó que llevaba unos diez años ejecutando cientos de VMs con Windows y Linux. El administrador de una universidad detalló sistemas que cubren nóminas, ERP, OpenShift, bases de datos, autenticación, servicios de red y gestión de contenidos. Esos sistemas tienen que funcionar cuando la gente llega el lunes por la mañana.

¿Por qué Ceph resulta arriesgado en clústeres pequeños de Proxmox?

La disponibilidad de Ceph depende de los dominios de fallo, la política de réplicas y la capacidad restante tras la caída de un nodo.

El clúster original de cinco nodos utilizaba Ceph, lo que expuso de inmediato una división de opiniones en el debate. Un operador describió un despliegue de Ceph de 25 nodos, elogiando lo sencillo que resultaba gestionarlo desde la interfaz de Proxmox. Otro afirmó haber operado un clúster hiperconvergente de diez nodos con unas 230 VMs internas y de clientes durante casi cinco años, con redes de 100 Gb entre nodos. Otro participante había migrado de iSCSI a Ceph tras años en Proxmox y no se arrepentía. Contaba con el número de nodos y la red necesarios para tratar el almacenamiento distribuido como una decisión arquitectónica planificada.

Antes de extrapolar conclusiones a partir de un recuento alto de VMs, revisa los compromisos de disponibilidad en clústeres de Ceph, que se centran en lo que sucede tras perder un nodo.

No todos compartían esa tranquilidad a menor escala. El administrador de un proveedor de servicios explicó que sus clústeres Ceph hiperconvergentes de tres nodos funcionaban bien para servicios de gestión, pero resultaban incómodamente vulnerables cuando caía un nodo. Para cargas críticas de clientes, personalmente no elegiría menos de cinco nodos. Se trata de una postura ante el riesgo, no de una regla universal. Con todo, cumplir con el tamaño mínimo de clúster no garantiza de forma automática que el sistema cuente con suficiente capacidad libre, tolerancia a fallos o velocidad de reconstrucción para su carga de trabajo. Otra persona propuso añadir un QDevice a una configuración de dos nodos, lo que dio pie a una aclaración oportuna. Un QDevice ayuda al quórum de Corosync; no crea un nodo extra de almacenamiento en Ceph ni soluciona los riesgos de ubicación de datos de Ceph.

Varios administradores evitaban Ceph por completo. Uno reportó un entorno de tres nodos con cerca de 100 cargas de trabajo utilizando volúmenes ZFS, replicación y HA. Otro utilizaba LINSTOR para dos clústeres pequeños de tres nodos. Otros comentaron configuraciones con cabinas locales ZFS, almacenamiento externo por Fibre Channel, iSCSI y NVMe over TCP. Un operador especialmente detallista describió SSDs empresariales, redes de almacenamiento rápidas y replicación ZFS programada entre dominios de disponibilidad. Su preferencia por la replicación asíncrona respondía a un equilibrio consciente: menor latencia de escritura a cambio de un punto de recuperación que podía retrasarse varios minutos respecto a la última transacción confirmada. En producción, lo que importa es qué falla, qué sobrevive y qué pérdida de datos puede permitirse la aplicación.

Surgió además una pregunta cotidiana entre tanto hardware de red: ¿qué tan difícil es sustituir un disco que ha fallado en Ceph? Alguien respondió que basta con retirar el OSD dañado, sustituir la unidad, asignar el reemplazo y dejar que Ceph se recupere. Es un buen resumen, pero esa descripción tan tranquila pasa por alto el momento de tensión. El rebalanceo consume capacidad y ancho de banda, y el clúster necesita suficientes réplicas sanas y espacio libre para recuperarse sin peligro. A pequeña escala, ese margen se reduce más rápido de lo esperado. Un procedimiento de recuperación que parece simple con todos los nodos sanos resulta muy distinto mientras las aplicaciones ya sufren degradación.

¿Puede Proxmox Backup Server cubrir la recuperación en producción?

Proxmox Backup Server es una opción para recuperarse, pero estar preparado para producción exige restauraciones probadas y copias independientes.

Algunos de los defensores más firmes de Proxmox en producción no utilizaban las mismas herramientas de backup. Un operador describió hardware empresarial, monitoreo, escaneo de seguridad y una topología de backup 3-2-1 basada en Proxmox Backup Server. Otro gestionaba un clúster modesto en una planta de fabricación con unas pocas VMs críticas y recurría a PBS con una copia externa. Para estos administradores, el backup no era un accesorio opcional. Formaba parte de la razón por la que se sentían cómodos alojando cargas reales en la plataforma. La documentación oficial de Proxmox Backup Server describe la sincronización remota y las copias múltiples, mientras que su guía de verificación explica cómo comprobar la integridad de los datos de backup. Ninguna de esas funciones elimina la necesidad de ensayar una restauración real.

En cuanto a la capa de recuperación, compara tus planes con una estrategia práctica de backup en Proxmox basada en pruebas periódicas de restauración.

El debate subió de tono cuando alguien preguntó por qué una instalación grande de Proxmox utilizaba Veeam en lugar de PBS. Una respuesta fue puramente pragmática: la organización ya tenía contratado Veeam bajo un acuerdo de larga duración. Otras respuestas fueron más directas. Un participante prefería Veeam para sistemas de clientes que no toleraban periodos prolongados de inactividad, argumentando que las pruebas automatizadas y los esquemas de reserva en caliente encajaban mejor con ciertos requisitos de recuperación que una restauración convencional de PBS. Otro opinaba que PBS era eficaz pero estaba menos pulido para sus necesidades, sobre todo en flujos de trabajo con cintas. Son opiniones y descripciones de entornos concretos, no una prueba de que un producto sea categóricamente más seguro. La cobertura de funciones, la versión, las licencias y la arquitectura de recuperación deben evaluarse frente a cada carga de trabajo real.

Otro participante aportó un toque irónico: tras años usando Veeam, ahora buscaba un sustituto debido a los costes y a funciones que ya no necesitaba. Esa frustración refleja el motivo por el que tantas organizaciones evalúan Proxmox. Salir de una plataforma de virtualización cara puede dejar de todos modos una factura compleja en las copias de seguridad, mientras que optar por una herramienta más económica puede exigir más trabajo de ingeniería por parte del equipo. La recuperación se mide por el tiempo de reinicio, la pérdida de datos y si alguien ensayó el procedimiento antes del desastre.

¿Cuándo está listo Proxmox para cargas de trabajo empresariales?

Proxmox está preparado para una carga de trabajo determinada solo cuando el operador puede documentar la capacidad, el monitoreo, las actualizaciones con soporte y un plan de recuperación creíble.

Quizá la respuesta más reveladora vino de un administrador que utilizaba servidores HPE, SSDs empresariales, redes rápidas con Arista, firewalls Fortigate, infraestructura de backup y revisiones rutinarias de seguridad. Su entorno de Proxmox era estable, argumentaba, porque trataban la plataforma como infraestructura empresarial. Parece obvio hasta que surge la tentación de interpretar una factura de software más baja como un permiso para recortar gastos en todo lo demás. El hardware adecuado, las redes segmentadas, el monitoreo, los cambios controlados y los planes de recuperación probados siguen siendo indispensables. Un hipervisor no elimina esas obligaciones. Al contrario, un equipo que deja atrás un ecosistema conocido tiene que demostrar que sabe cumplir con ellas bajo presión.

El debate incluyó también una postura menos arriesgada: mantener la maquinaria más sensible en el sistema en el que ya se confía para ejecutarla. Un participante describió clientes con esquemas híbridos que mantenían la telemetría de tanques de fermentación y el control de maquinaria en Hyper-V mientras trasladaban la contabilidad, las bases de datos y los servicios de correo a Proxmox. No es una migración espectacular ni llenará diapositivas llamativas. Sigue siendo una estrategia de producción legítima. La organización adquiere experiencia práctica con la nueva plataforma y amplía su uso solo cuando los modos de fallo, el proceso de backup y las responsabilidades operativas quedan claros. Para algunos equipos, ganar confianza poco a poco vale más que un diagrama arquitectónico impecable.

Los ejemplos compartidos, desde unas pocas decenas de sistemas empresariales hasta la cifra que superaba las 10,000 VMs, demuestran algo más preciso y útil que una victoria de Proxmox sobre el resto de alternativas. Ya hay operadores utilizándolo para tareas críticas. Sus casos de éxito merecen atención, pero también las advertencias sobre clústeres Ceph pequeños, lagunas en la replicación, automatización de recuperación incompleta y actualizaciones en hosts con personalizaciones avanzadas. Ningún hilo en un foro puede certificar una plataforma para los requisitos de tiempo de actividad de una empresa concreta. Lo que sí puede hacer es sustituir una pregunta perezosa ("¿Proxmox sirve solo para homelabs?") por otra más exigente: ¿quién se responsabiliza de que el entorno de producción sobreviva el día en que nada sale según lo previsto?

Para el operador que abrió el debate, un clúster de cinco nodos y más de 100 VMs ya representaba un punto de partida importante. Las respuestas ofrecieron tranquilidad, pero también un estándar más riguroso. La cifra más alta de la sala no era la medida de la madurez. Lo que marcaba la diferencia era el plan ante la pérdida de un nodo, un pool de almacenamiento o una sede completa.

Aprobaría Proxmox para producción cuando el equipo pueda demostrar que sabe recuperarse de fallos monitorizados y ejecutar procesos de mantenimiento con soporte, sin importar si el parque tiene 20 o 10,000 VMs. Si esas capacidades no existen, empieza con algo más pequeño y valida cada paso antes de añadir más cargas de trabajo.