Ceph en 2.5GbE funciona, pero el problema es el resto

El hardware parecía casi ideal para montar un clúster compacto de Proxmox: dos equipos Lenovo M920q, un M720q, 32 GB de RAM en cada uno, un SSD SATA pequeño para el arranque y una unidad NVMe de 1 TB para almacenamiento. Una torre Dell bastante más potente seguía ejecutando cada VM y LXC. El objetivo del nuevo clúster era sobrevivir a la caída de un nodo sin que la recuperación arruinara un fin de semana entero.

La cuestión del almacenamiento fue donde este montaje tan limpio empezó a complicarse. Ceph parecía la respuesta obvia, con almacenamiento distribuido compartido, redundancia automática y un mejor aprovechamiento de múltiples nodos. El inconveniente era todo lo que traía consigo: renovar la red, más escrituras de datos, menos capacidad útil, un posible desgaste acelerado en SSD de consumo, temperaturas altas, tarjetas de red adicionales, quizá un switch dedicado e incluso plantearse 10GbE. En ese punto ya no estás configurando virtualización, sino diseñando infraestructura desde cero.

La discusión sobre 2.5GbE casi parece una distracción

La duda más ruidosa era si Ceph podía funcionar sobre 2.5GbE. Quienes mantienen entornos pequeños con Ceph respondieron que sí.

Un usuario explicó que ejecutaba Ceph sobre 2.5GbE sin ningún contratiempo. Otro describió un clúster de mini PC con enlaces agregados de 2.5GbE que alcanzaba picos cercanos a 750 MB/s en escritura y casi 900 MB/s en lectura en ese entorno concreto. Otra persona comentó que un despliegue doméstico de Ceph le había resultado aceptable incluso sobre 1GbE. Ninguna de estas anécdotas demuestra que 2.5GbE sea la opción ideal, pero sí confirman que Ceph puede funcionar por debajo de 10GbE.

El punto más útil del debate giró en torno a qué ocurre cuando el clúster tiene mucha carga, reconstruye datos o se recupera de un fallo. Ceph mueve constantemente datos replicados entre los nodos, por lo que la red de almacenamiento soporta mucho más tráfico que la carga habitual de una VM. Un enlace que responde bien durante el uso ligero de un homelab se vuelve lento en cuanto falla un disco y arranca la reconstrucción.

Por eso varios participantes insistieron en dar el salto a 10GbE. Uno sugirió instalar tarjetas Mellanox de dos puertos en anillo directo entre los tres nodos Lenovo. Otro ya utilizaba adaptadores Intel X520 o X550 en equipos de formato Tiny similares. La ventaja era puramente práctica: el hardware 10GbE de segunda mano evita que la red sea el primer cuello de botella y acelera notablemente las migraciones.

Las recomendaciones oficiales de Proxmox son más prudentes que las experiencias del homelab. Proxmox aconseja dedicar al menos 10 Gbps al tráfico de Ceph y advierte de que el tráfico de recuperación puede perjudicar la comunicación del clúster sensible a la latencia si todo comparte la misma red. Para almacenamiento basado en NVMe, recuerda que un único dispositivo rápido ya puede saturar lo que 10GbE transporta con soltura. Por tanto, 2.5GbE es viable, pero dista de ser la decisión de diseño más crítica en este caso.

Ceph consume el almacenamiento que creías desperdiciar con ZFS

La duda inicial sobre la replicación en ZFS venía de la capacidad. Replicar el almacenamiento de VMs y LXC entre nodos parecía costoso porque las copias ocupan espacio. Parte del atractivo de Ceph era que parecía una forma más inteligente de agrupar las tres unidades NVMe de 1 TB.

Varios participantes recordaron que la replicación en Ceph también genera copias idénticas. Una configuración habitual de tres réplicas almacena los datos tres veces, por lo que un clúster pequeño termina ofreciendo en torno a un tercio de la capacidad bruta para datos únicos. Un usuario lo resumió con franqueza: Ceph no iba a crear espacio útil por arte de magia. Otro comparó ambas opciones y llegó a la misma conclusión: tanto la replicación con ZFS como Ceph sacrifican capacidad a cambio de copias, solo que con arquitecturas distintas por debajo.

Eso cambia por completo el análisis. Con la replicación de ZFS no necesitas replicar cada invitado en todos los nodos. Varios administradores señalaron que solo las VMs y contenedores críticos necesitan ese nivel de protección, mientras que las cargas secundarias pueden respaldarse en copias de seguridad o recuperación manual. De este modo, un homelab pequeño puede concentrar sus gigabytes donde realmente importa.

Ceph resulta atractivo por otros motivos. El almacenamiento está distribuido y disponible en todo el clúster, lo que encaja mucho mejor con una verdadera infraestructura hiperconvergente. El fallo de un disco no deja necesariamente fuera de servicio a todo el nodo de cómputo, y la capa de almacenamiento puede reconstruir la redundancia en los dispositivos restantes, lo cual es una gran ventaja.

Sin embargo, tres equipos pequeños con un único NVMe principal cada uno rozan la configuración mínima viable para Ceph, y varios participantes con experiencia vieron ahí el punto débil. Uno definió tres nodos como algo técnicamente funcional pero con un margen de tolerancia a fallos muy estrecho. Otro consideró que Ceph en tres nodos tenía sentido para aprender, pero resultaba excesivo si el único propósito era mantener activos los servicios del hogar.

Si montas el laboratorio para aprender Ceph, lidiar con esas complicaciones forma parte del aprendizaje. Si lo construyes para mantener en línea el DNS, Home Assistant, el almacenamiento o los servicios familiares, el criterio de éxito es muy distinto.

El desgaste de los SSD preocupa más que la velocidad de red

El hilo se volvió más interesante cuando pasó del ancho de banda de Ethernet a la durabilidad de los SSD. Los nodos propuestos utilizaban unidades NVMe de gama de consumo. Varios usuarios advirtieron de inmediato que Ceph puede castigar con dureza la memoria flash de consumo debido a la gran cantidad de escrituras del almacenamiento distribuido. Un participante relató que utilizó SSD de consumo en un entorno pequeño con Ceph y se agotaron en unos seis meses, tras lo cual tuvo que cambiarlos por unidades Intel para centro de datos. Se trata de la experiencia de un usuario y no predice la vida útil exacta de cada disco, pero un testimonio así obliga a replantearse un homelab económico.

Otro usuario con un clúster Lenovo casi idéntico explicó que esa limitación concreta fue el motivo por el que dejó de usar esas máquinas. Su nueva plataforma permitía alojar una unidad de arranque más dos discos dedicados a Ceph. Otros recomendaron modelos de SSD empresariales, lo que abrió otro problema de tamaño: algunos NVMe empresariales asequibles usan formatos más largos que no caben fácilmente dentro de estos equipos Tiny.

A partir de ahí, el plan inicial sobre 2.5GbE empezó a crecer sin freno. Con un elevador PCIe se puede instalar una tarjeta 10GbE. La ranura WiFi a veces permite colocar otro dispositivo NVMe mediante un adaptador, y algunos usuarios trasladaron ahí la unidad de arranque de Proxmox para liberar espacio SATA o NVMe. Otros desmontaron las carcasas de los SSD, añadieron pequeños ventiladores, imprimieron deflectores a medida en 3D o utilizaron adaptadores de corriente SATA para controlar la temperatura de tarjetas de red calientes. Todo eso funciona, aunque convierte un clúster limpio de tres nodos en un proyecto de ingeniería en miniatura.

El calor surgió una y otra vez en los comentarios. Los chasis son pequeños, el rack es denso y las tarjetas 10GbE generan bastante temperatura. Un usuario con un montaje similar basado en M920 añadió un ventilador de 40 mm dedicado para la tarjeta de red. Otro afirmó que la limitación térmica por temperatura fue un verdadero problema en su caso. El rack original ya contaba con la parte trasera abierta y un ventilador de 120 mm.

Llegados a este punto, la cuestión es cuántos compromisos adicionales estás dispuesto a asumir antes de que esto deje de ser la solución de alta disponibilidad sencilla que buscabas. Saber si Ceph puede funcionar sobre 2.5GbE pasa a un segundo plano.

La replicación con ZFS y PBS siguen imponiéndose por practicidad

Los argumentos más firmes contra Ceph vinieron de quienes preguntaron qué problema se pretendía resolver realmente, y ninguno de ellos sugirió que Ceph fuera una mala herramienta.

La prioridad declarada era recuperar VMs y LXC tras la caída de un nodo, y varios consideraron que la replicación con ZFS cubría esa necesidad. La replicación de almacenamiento en Proxmox transfiere los volúmenes de los invitados a otro nodo de forma incremental, y la HA puede combinarse con la replicación, aunque se pueden perder los datos escritos entre la última sincronización y el fallo. Ese compromiso existe, pero resulta mucho más fácil de gestionar que un almacenamiento distribuido entre tres equipos diminutos.

Un participante comentó que un montaje similar con tres mini PC, ZFS local y replicación funcionaba a la perfección. Otro recomendó empezar con ZFS porque solo las cargas esenciales necesitan replicarse, lo que permite aprovechar discos de 1 TB de forma mucho más razonable en vez de tratar cada byte como crítico.

Otro usuario había confiado en la alta disponibilidad basada en ZFS, probado apagados de nodos sin problemas y, tiempo después, vio desaparecer el disco de una VM tras un evento de HA. Una copia de seguridad le salvó la situación. Es un caso aislado y no define un patrón de fallo en ZFS, pero recuerda con claridad que la replicación nunca sustituye a un backup.

Ahí es donde Proxmox Backup Server volvió al centro del debate. El administrador ya ejecutaba PBS como VM, con las copias guardadas en un UNAS Pro, y planeaba migrar PBS a un equipo bare metal. Varios participantes consideraron que eso bastaba para un entorno doméstico: distribuir las cargas entre los nodos de cómputo, conservar buenos backups, asumir que un nodo averiado puede implicar restaurar datos y evitar un gasto desmedido de tiempo y dinero para eludir unas pocas horas de inactividad.

Es un enfoque menos llamativo que Ceph, pero cuando el tiempo de inactividad cuesta molestias y no facturación, suele ser también el diseño más sensato.

Si te interesa planificar tu entorno, en el Mr.PlanB Proxmox hub analizamos decisiones de clústeres, almacenamiento y migraciones desde esta misma perspectiva práctica.

La mejor arquitectura para homelab depende de lo que quieras aprender

La mayor parte del desacuerdo radicaba en qué objetivo debe optimizar un homelab.

Un grupo buscaba almacenamiento distribuido real y alta disponibilidad. Para ellos, tarjetas 10GbE, cableado directo, ventilación extra, SSD empresariales y más unidades formaban parte de construir las cosas como corresponde, y Ceph era la razón de ser del proyecto.

Un segundo grupo se preocupaba más por mantener los servicios funcionando que por la infraestructura en sí. Su solución consistía en replicación ZFS para ciertos invitados, PBS para la recuperación y mucho menos hardware. Si un nodo cae, restauras lo que importa, ya que unas horas de parada cuestan menos que rediseñar cada mini PC en torno a Ceph.

Luego estaba la postura intermedia: utilizar Ceph sobre 2.5GbE ahora, ver cómo responde el entorno y actualizar cuando los límites aparezcan en la práctica. Varios usuarios demostraron que los despliegues pequeños de Ceph pueden funcionar así, siempre que aceptes el cuello de botella, el tiempo de reconstrucción, el desgaste del SSD y los límites térmicos como parte del experimento.

Mi lectura de todo este debate es que 2.5GbE no hace que el diseño sea arriesgado por sí solo. El riesgo surge de querer almacenamiento distribuido, alta disponibilidad, máxima capacidad útil, bajo coste, hardware de consumo y mínima complejidad en las mismas tres máquinas diminutas, algo que difícilmente se consigue a la vez.

En un laboratorio de pruebas, lidiar con esos compromisos puede ser divertido. Para una infraestructura que debe funcionar a diario sin exigir atención constante, la opción aburrida casi siempre responde mejor.