Hiperconvergencia en el Barro: Proxmox, Ceph y la trampa de los SSD baratos

A finales de 2024 cometimos la imprudencia de montar un clúster hiperconvergente "de juguete" para producción. Queríamos huir de VMware y, de paso, ver si podíamos dormir tranquilos sin pagar el precio de una cabina SAN tradicional. Spoiler: dormimos poco al principio, pero ahora dormimos mejor.

El plan era sencillo: un clúster interno donde conviviesen los servicios del día a día —autenticación centralizada, gestión documental, seguimiento de tiempos, herramientas de colaboración— y que además sirviese como tercera copia de seguridad de los clústeres que ya teníamos desplegados en proveedores cloud. Un sitio local, controlado y barato donde tener los datos a buen recaudo.

El detonante fue VMware. No estábamos de acuerdo con la deriva de su licenciamiento. Cada cambio de política, cada nuevo modelo de suscripción, cada incertidumbre añadía fricción a algo que debería ser simple: un hipervisor estable, predecible y sin sorpresas. Proxmox fue la decisión obvia; ya llevábamos tiempo usándolo. La verdadera duda estaba en el almacenamiento. ¿Comprar otra cabina tradicional, asumir su coste, su ciclo de vida y su futura obsolescencia? Teníamos bastante reciente el dolor económico de haber comprado discos para una cabina que ya estaba descatalogada. Así que nos preguntamos: los sistemas de almacenamiento distribuido llevan años madurando, ¿podemos probar si realmente son una alternativa viable en entornos pequeños?

Ahí empezó el experimento. Tres objetivos claros: alojar servicios internos, servir como plataforma de experimentación con tecnologías que luego usaríamos en clientes, y actuar como tercera copia de seguridad. Esto condicionó completamente el diseño. No buscábamos el máximo rendimiento ni la máxima densidad. Buscábamos equilibrio, previsibilidad y, sobre todo, aprender. Y aprender casi siempre implica equivocarse.

GlusterFS: la primera opción muerta

Ceph no fue nuestra primera elección. De hecho, nos daba bastante respeto. Ceph siempre se asocia mentalmente a grandes despliegues: decenas o cientos de nodos, redes de 25, 40 o 100 Gbps, discos NVMe. Nuestro clúster iba a ser de tres nodos. Así que nuestra primera idea fue GlusterFS.

Sobre el papel, GlusterFS era perfecto: simple y barato. Nos gustaba su curva de aprendizaje más suave y el hecho de que mucha gente lo usase con éxito en clústeres pequeños. Pero al rascar un poco, nos llegó el olor a formol. El proyecto estaba en soporte vital, sin desarrollo real, sin roadmap claro, sin señales de evolución. Y en infraestructura, montar tu casa sobre cimientos que nadie mantiene no es una apuesta, es un suicidio a largo plazo.

Ceph era el monstruo complejo, sí, pero al menos era un monstruo vivo. Muy vivo. Demasiado vivo, incluso. Documentación inmensa, terminología propia —OSD, MON, MGR, CRUSH, placement rules, pools, PGs—, y una fama bien ganada de ser potente pero exigente. Tras descartar otras opciones y valorar pros y contras, decidimos darle una oportunidad. No porque fuese la opción perfecta, sino porque si íbamos a recomendar o descartar hiperconvergencia con Ceph para clientes, necesitábamos haberla sufrido primero en nuestras propias carnes.

El hardware: la lista de la compra y sus trampas

Optamos por hardware empresarial de gama de entrada. Tres nodos idénticos:

• Servidores: Lenovo ThinkSystem SR250 V2
• CPU: Intel Xeon E-2378 (8 cores / 16 hilos)
• RAM: 128 GB DDR4 ECC
• Almacenamiento: 8 bahías SAS/SATA por nodo
• Red: 2x SFP+ a 10 Gbps (Intel X710) + 2x 1 Gbps RJ45 + 1 puerto de gestión
• Boot: 2x Samsung 870 EVO 1 TB en RAID1 ZFS
• Datos (inicial): 4x Samsung 870 QVO 4 TB por nodo

En red, un Cisco CBS 250-24T-4X. Switch empresarial, pero gama de entrada. Y aquí viene la primera trampa: solo tiene 4 puertos SFP+ a 10 Gbps. Tres nodos, cuatro puertos de 10G. Haz las cuentas.

La idea feliz era compartir el enlace SFP+ para el tráfico de Ceph y el tráfico de las máquinas virtuales. En la práctica, eso es como meter dos ríos por la misma tubería. Ceph genera un tráfico interno brutal: replicación, rebalanceo, scrubbing, recuperación tras fallos. En cuanto el clúster empezó a trabajar en serio, quedó claro que ese enlace tenía que ser exclusivo para Ceph. Así que rebalanceamos: movimos el tráfico de las máquinas virtuales a las tomas RJ45 de 1 Gbps y mantuvimos los SFP+ en exclusiva para Ceph. Si hoy lo montásemos de nuevo, usaríamos un switch con al menos 6 u 8 puertos SFP+ y separaríamos físicamente la red de almacenamiento de la red de servicios. Ceph no perdona atajos en red.

Pero el error de la red fue menor comparado con lo que vino después.

El gran error: Samsung QVO y la trampa de los benchmarks

Cuando tocó elegir discos de datos, miramos muchas comparativas. Samsung 870 EVO contra Samsung 870 QVO. Los EVO eran mejores en todo. Pero los QVO costaban casi la mitad. Y según los benchmarks sintéticos (como este), el rendimiento parecía "suficiente". Para el presupuesto de un clúster interno, esa diferencia de precio multiplicada por doce discos era significativa.

Aquí es donde los benchmarks nos engañaron y pagamos la novatada.

El problema de los QVO no es que sean baratos, es que son mentirosos. Usan tecnología QLC (Quad Level Cell): cuatro bits por celda. Mayor densidad, menor coste por terabyte, pero también menor durabilidad y, lo que es crítico, peor rendimiento sostenido. Para compensar esta limitación, Samsung implementa una caché SLC interna —aproximadamente entre 42 y 78 GB dependiendo del espacio libre— que actúa como maquillaje. Mientras escribes dentro de esa caché, el disco te sonríe y te da 500 MB/s. Todo parece perfecto.

Pero en cuanto llenas esa caché —y Ceph la llena en segundos—, el maquillaje se cae y te encuentras con la realidad: una velocidad de escritura de 80 MB/s o menos. Menos que un disco mecánico de hace una década. En cargas cortas e intermitentes, nunca lo notas. En cargas sostenidas, el desastre aparece.

Y Ceph, precisamente, genera cargas sostenidas.

Cada escritura que hace una máquina virtual pasa por el Journal/WAL (Write Ahead Log) de Ceph antes de confirmarse. Ceph necesita escribir el dato en el WAL, confirmar que está persistido y solo entonces decirle a la VM "dato guardado". Si el disco subyacente está en modo QLC nativo porque la caché SLC se saturó, la latencia de escritura pasa de 1 ms a 100 ms o más. Para una base de datos, eso es la muerte clínica. Para cualquier VM que haga escrituras frecuentes, es una agonía lenta. El clúster no iba lento; el clúster se ahogaba.

Nos pasamos semanas buscando el problema. Revisamos la red, la CPU, la configuración de Ceph, los pools, los PGs, los parámetros de OSD. Todo parecía correcto. Hasta que empezamos a medir latencias a nivel de disco individual y dimos con la causa. Los discos. Los malditos discos baratos que habíamos elegido para ahorrar.

La solución de trinchera: no tirar nada

Un informático de trinchera no tira hardware, lo reasigna.

Nos quedaban dos bahías libres por servidor. Compramos dos Samsung 870 EVO de 4 TB para cada nodo —discos TLC, que mantienen velocidades de escritura constantes sin depender de trucos de caché— y creamos un pool nuevo en Ceph basado exclusivamente en los EVO. Los QVO pasaron a un pool dedicado a copias de seguridad.

¿Por qué funciona esta separación? Porque los backups tienen un perfil de escritura completamente distinto al de las VMs. Las copias de seguridad incrementales rara vez superan los 75 GB de una sola vez, lo que significa que la caché SLC de los QVO es suficiente para absorber la mayoría de las escrituras sin despeinarse. Y si algún backup completo satura la caché y tarda tres horas en lugar de una, no pasa absolutamente nada. Nadie está esperando a que un commit de base de datos se confirme en 200 ms.

Aquí es donde Ceph justificó cada maldita hora que pasamos aprendiéndolo. Creamos dos placement rules en el CRUSH map: rule-ssd-evo para forzar escrituras a los discos rápidos y rule-ssd-qvo para los discos lentos. Cambiamos la regla del pool de máquinas virtuales de la regla por defecto a rule-ssd-evo. Nada más. Sin reinicios. Sin ventanas de mantenimiento. Ceph empezó a mover los datos en segundo plano —los muebles— mientras la gente seguía viviendo dentro de la casa. Las máquinas virtuales encendidas, los usuarios trabajando, y según avanzaba la migración, las VMs empezaban a rendir más rápido. Podías verlo en tiempo real. Es en momentos así cuando entiendes por qué Ceph, pese a su complejidad, se ha ganado el respeto que tiene.

Qué corre aquí y qué NO

Tras más de un año de uso, tenemos bastante claro dónde encaja este clúster y dónde no.

Actualmente tenemos funcionando sin problemas: Authentik, Netbox, Plane, Solidtime, Nextcloud, Penpot, Jenkins, Netbird, Password Pusher, Snipe-IT y varias máquinas RDP para soporte remoto a clientes. También tenemos entornos de desarrollo internos, algún que otro servicio de pruebas y este mismo blog que estás leyendo. Todo esto va fluido, sin latencias perceptibles, sin cuellos de botella graves. Para servicios web, herramientas de colaboración y aplicaciones internas de uso moderado, la hiperconvergencia con Ceph sobre hardware de gama de entrada funciona. Punto.

Ahora bien, hay un "NO" categórico que quiero dejar claro.

Este clúster no sirve para bases de datos pesadas. Un ERP exigente como IFS, que corre sobre Oracle, necesita latencias bajísimas y un volumen de IOPS que está a órdenes de magnitud de lo que nuestro setup puede ofrecer. No es culpa de Ceph como tecnología. Es una cuestión de física: discos SSD SATA, red a 10 Gbps compartida y tres nodos simplemente no dan las cifras. Sería como intentar ganar Le Mans con un Dacia Sandero. El motor funciona, pero no es ESE motor. Con NVMe, más nodos y red de 25 o 100 Gbps podríamos empezar a plantearlo. Con este hardware, ni de lejos. Y es importante asumirlo sin complejos, porque la tentación de estirar un sistema más allá de sus límites es una de las formas más comunes de generar problemas crónicos en infraestructura.

Los incidentes: dos paradas en catorce meses

Desde diciembre de 2024 hasta febrero de 2026, el almacenamiento Ceph se ha detenido exactamente dos veces. Para un clúster de tres nodos con hardware de gama de entrada, creo que merece contexto y reconocimiento.

La primera parada fue el 28 de abril de 2025, durante el apagón generalizado. No disponemos de grupo electrógeno para el clúster interno. Los SAIs aguantaron lo que pudieron, pero cuando se acabaron las baterías, se apagó todo. Física pura. Nada que reprocharle a Ceph. Al restaurar el suministro, los nodos arrancaron y Ceph recuperó el estado sin incidencias. Limpio.

La segunda parada fue bastante más interesante y merece que la desgranemos, porque es el tipo de incidente del que se aprende de verdad.

Hace unas semanas tuvimos una incidencia con nuestro contador eléctrico que requería su sustitución. Nuestro protocolo ante cortes de más de cinco minutos es claro: apagar las máquinas virtuales del Servidor 3 —que aloja las VMs menos críticas— y apagar ese nodo para maximizar la duración de las baterías de los SAIs en los otros dos servidores y para las máquinas críticas. Lo hicimos según protocolo, paso a paso, sin prisas.

El problema fue que, sin que lo detectásemos, el Servidor 2 se había reiniciado silenciosamente durante la noche anterior. Y aquí entra un detalle técnico importante: en nuestra configuración específica, el target de systemd no arranca automáticamente los OSDs de Ceph tras un reinicio. Es una limitación técnica que tenemos resuelta con un script manual, start-ceph-osds.sh, precisamente para gestionar ese arranque. Pero como no sabíamos que el Servidor 2 se había reiniciado, nadie ejecutó el script. Los servicios de Ceph en ese nodo llevaban horas caídos sin que nos enterásemos.

Cuando apagamos el Servidor 3 siguiendo el protocolo, el clúster se quedó efectivamente con un solo nodo activo: el Servidor 1. Y en ese instante, Ceph hizo exactamente lo que tenía que hacer: congeló todas las operaciones de I/O.

¿Por qué? Porque nuestros pools están configurados con size=3 (tres réplicas) y min_size=2. Esto significa que Ceph exige que cada dato esté escrito en al menos dos ubicaciones distintas —en servidores diferentes— antes de confirmar una escritura. Es un mecanismo de protección contra la corrupción: si el clúster se fragmenta y dos partes creen ser la versión válida, podrían escribir versiones diferentes del mismo dato. El min_size=2 previene exactamente eso. Con un solo nodo activo, 1 < min_size(2), Ceph prioriza la Consistencia sobre la Disponibilidad. Prefiere pararse antes que arriesgar la integridad de los datos. Y tiene razón.

Tan pronto como los técnicos de la compañía eléctrica terminaron y el suministro se restableció, arrancamos los nodos. Empezamos por el Servidor 3, porque era el último nodo que sabíamos que tenía quórum válido antes de apagarse —no fue una decisión al azar, sino basada en el conocimiento del estado del clúster. Al arrancar, detectamos que Ceph estaba detenido en el Servidor 2, ejecutamos el script de arranque de OSDs y el clúster recuperó el quórum. Cero bits corruptos. Cero inconsistencias. El sistema funcionó exactamente como fue diseñado. Ceph hizo su trabajo; los que fallamos fuimos nosotros al no saber que el Servidor 2 estaba caído.

En casa de herrero, cuchillo de palo

Sí, sé perfectamente lo que estarás pensando. ¿Cómo es posible que no supieseis que el Servidor 2 se había reiniciado? ¿No tenéis monitorización?

Tenemos sistemas de monitorización desplegados en nuestros clientes. Prometheus, Grafana y alertas configuradas al detalle. Pero en nuestro propio clúster interno, el que considerábamos "de pruebas", no habíamos configurado las alertas. El clásico refrán español lo resume mejor que cualquier post-mortem: "En casa de herrero, cuchillo de palo". Sería hipócrita por mi parte no reconocerlo.

La ironía es que ese clúster "de pruebas" sostiene nuestro día a día. Nuestra autenticación, nuestra gestión de tareas, nuestras copias de seguridad. Llamarlo "de pruebas" era una excusa cómoda para no aplicarnos el mismo rigor que exigimos a los demás. La capa 8 del modelo OSI —la humana— nos jugó una mala pasada. Desde ese incidente, la monitorización del clúster interno dejó de ser un "pendiente" y empezó a ganar mucha prioridad. Lección aprendida por las malas, como las buenas lecciones.

Conocer tus límites y diseñar alrededor de ellos

Llevamos 14 meses con este Frankenstein. Tiene discos de consumo, red de 10G y un switch que se queda corto. No es perfecto. Nunca lo fue y nunca lo será. Cometimos errores de diseño con la red, errores de selección con los discos, errores de operación con la monitorización. Pero cada uno de esos errores nos enseñó algo que no habríamos aprendido leyendo documentación ni viendo vídeos de YouTube.

Sabemos que Ceph en tres nodos con SATA y 10 Gbps tiene un techo claro. Sabemos que los SSD baratos esconden trampas que los benchmarks sintéticos no revelan. Sabemos que un clúster sin monitorización es un clúster con una bomba de relojería. Y sabemos que, dentro de sus límites, la hiperconvergencia con Proxmox y Ceph funciona de forma sorprendentemente fiable para cargas de trabajo moderadas.

La robustez no es comprar la máquina más cara del catálogo de Dell. La robustez es saber qué hacer cuando la máquina barata que has comprado decide dejar de funcionar un martes a las tres de la mañana. Saber exactamente dónde se rompe tu sistema y cómo arreglarlo. Diseñar alrededor de las fronteras en lugar de fingir que no existen. Eso es lo que separa un entorno que aguanta de uno que solo parece que aguanta hasta que deja de hacerlo.

Y en eso, este clúster ya se ha pagado solo.

Nos leemos en el siguiente post. O si prefieres no estar pendiente de refrescar la web, suscríbete y te mando un aviso cuando salga el próximo. Sin spam, palabra.