Mr.PlanB Logo
    Volver al blog
    Almacenamiento
    Ceph
    NVMe

    Escalar un clúster Ceph de 40GB/s de cinco a seis nodos

    21 de mayo de 2026
    9 min de lectura

    Los ingenieros de almacenamiento se emocionan con cosas que nadie fuera de la sala nota, como una latencia que baja o un panel que se pone en verde en todos los nodos. Pasas semanas planificando, afinando y ajustando cargas de trabajo, viendo cómo las gráficas suben hacia un rendimiento que siempre se queda un poco fuera de alcance, y un día los números llegan más altos de lo que esperabas.

    I Built a 200K IOPS Monster—Then Proxmox Turned It Into a 6K Joke

    Un clúster de almacenamiento de cinco nodos ya iba a una velocidad absurda: unos 40 GB/s de lectura media, picos de escritura que rozaban los 11 GB/s y más de 2 millones de IOPS con más de 30 clientes empujando directamente contra él. Funcionaba sobre sistemas AMD EPYC con red de 200 Gb y Ceph sobre RBD, probado con I/O directa. Eran números reales de hardware real castigado hasta que empezaron a verse sus límites, no cifras de una diapositiva de un fabricante.

    La siguiente pregunta era qué pasa cuando añades más. No había nada roto ni faltaba capacidad. La gente que construye sistemas así simplemente quiere saber dónde está el techo.

    Perseguir límites forma parte del trabajo

    El hardware se ha ido haciendo más rápido con los años, la red ha dado un salto y NVMe ha movido tanto las expectativas que las arquitecturas de almacenamiento más antiguas empezaron a parecer prehistóricas. Pero la velocidad por sí sola ya no decide gran cosa. Los sistemas de almacenamiento modernos se juzgan por cómo escalan. Un clúster que rinde de maravilla con cinco nodos significa poco si añadir un sexto desata tormentas de rebalanceo, tiempo de inactividad, picos de latencia o cuellos de botella inesperados, y quien haya vivido una mala ampliación de almacenamiento la recuerda.

    Esa historia vuelve escéptica a la gente. Un bando trata cualquier promesa de escalado con desconfianza hasta que aguanta bajo presión, porque a los fabricantes les encantan las gráficas y los relatos de ampliaciones sin problemas, mientras que la realidad a veces trae incidentes de madrugada y resolución de problemas de urgencia. Otro bando considera el escalado un problema resuelto cuando la arquitectura está bien diseñada, porque el almacenamiento distribuido existe precisamente para que puedas añadir recursos, redistribuir cargas de trabajo y seguir adelante.

    Quienes han montado suficientes clústeres se quedan en algún punto intermedio. Saben que el éxito depende menos de la tecnología en sí que de detalles de implementación de los que nadie habla hasta que algo se rompe: las decisiones de red, los dominios de fallo, los patrones de carga, los placement groups, la estrategia de rebalanceo y la homogeneidad del hardware. Esos detalles deciden si escalar resulta fácil o catastrófico, y por eso esta prueba era interesante. El clúster se amplió y después se exprimió a fondo.

    El gusto de ver un sistema aguantar el maltrato

    Estresar la infraestructura a propósito tiene algo extrañamente satisfactorio. Le lanzas clientes, fuerzas el rendimiento, machacas las escrituras y vigilas las gráficas de latencia en busca de la primera señal de alarma.

    Este clúster ya era muy capaz antes de la ampliación. Cuarenta gigabytes por segundo de lectura media está muy por encima de la infraestructura de una empresa pequeña, y dos millones de IOPS cambian por completo las expectativas. A esos niveles los errores salen enseguida a la superficie, ya sean malas elecciones de hardware, malas decisiones de balanceo o atajos de diseño.

    En lugar de eso, al parecer la ampliación fue tan fluida que casi resultaba sospechosa. Se unió un sexto nodo NVMe, Ceph redistribuyó y rebalanceó los datos, y el sistema siguió funcionando sin tiempo de inactividad y con muy poco drama. Para gente acostumbrada a esperar dolor cada vez que crece la infraestructura, eso resulta raro.

    Un comentarista anónimo reaccionó más con humor que con admiración, bromeando con que los discos giratorios tradicionales estarían "llorando" intentando seguir el ritmo de números así. La broma funciona porque las expectativas de verdad han cambiado. Objetivos de rendimiento de almacenamiento que hace unos años sonaban imposibles hoy parecen normales en algunos entornos, y el hardware ha avanzado más deprisa de lo que mucha gente esperaba.

    Por qué ampliar el almacenamiento suele doler más de lo que nadie admite

    A la gente le encanta hablar de cifras de rendimiento y habla mucho menos del dolor operativo. Escalar el almacenamiento no tiene glamour. Los clústeres se rebalancean, el tráfico de red se dispara, las operaciones de recuperación compiten con las cargas de producción, el rendimiento cambia durante un tiempo y los administradores miran sus paneles más a menudo de lo normal. A veces una ampliación crea problemas que solo aparecen semanas después.

    Por eso importan las historias de escalado sin sobresaltos. Cuando crecer deja de doler, los equipos planifican con más ambición, sus arquitecturas evolucionan de otra manera y la ampliación deja de ser un acontecimiento peligroso que exige elaborados rituales de preparación.

    El escepticismo sigue siendo sano. Algunos ingenieros sostienen que los benchmarks solo importan cuando la carga de trabajo se parece a la realidad, porque los entornos de prueba sintéticos pueden esconder sorpresas feas y los grandes sistemas transaccionales se comportan de forma distinta a las pruebas con I/O directa. Otros responden que forzar los límites a propósito deja ver las debilidades antes de que las encuentre producción. Las dos posturas tienen su parte de razón, y los mejores equipos de infraestructura sopesan juntos los resultados de los benchmarks y el historial operativo antes de fiarse de un sistema.

    La gran promesa de Ceph nunca fue la velocidad bruta

    El rendimiento se lleva los titulares, pero lo que mantiene vivo el almacenamiento distribuido es la escalabilidad. El detalle interesante de este caso era menos el rendimiento que la forma en que, al parecer, se hizo la ampliación: unas cuantas acciones en el panel, un rebalanceo y el sistema siguió funcionando sin tiempo de inactividad.

    Esa sencillez importa porque la complejidad se acumula. Los clústeres crecen, el número de clientes sube y las necesidades de almacenamiento se multiplican, y las organizaciones rara vez reducen su infraestructura. Una tecnología que parece manejable a pequeña escala a veces se hunde operativamente a una escala mayor. Los sistemas distribuidos prometen una salida de esa trampa, aunque no prometan la perfección: puedes crecer sin reconstruirlo todo desde cero, sin una migración a lo bruto, sin un rediseño de meses porque el crecimiento rompió una suposición y sin una ventana de parada que explicar.

    Cuando el escalado sale bien, casi no se ve. La gente de fuera de operaciones técnicas rara vez lo nota, mientras que todo el equipo de infraestructura sí.

    La carrera armamentística de la infraestructura no afloja

    Las expectativas de rendimiento han cambiado de forma radical. Hace cinco años, muchos entornos medían el éxito del almacenamiento de otra manera. Hoy los sistemas de IA necesitan un rendimiento enorme, la densidad de virtualización no deja de subir, los pipelines de analítica mueven cantidades asombrosas de datos y las pilas de software modernas dan por hecho que el almacenamiento no será el cuello de botella.

    Esa suposición presiona a quienes construyen la infraestructura. Se espera de ellos que entreguen a la vez ancho de banda, IOPS, consistencia, tolerancia a fallos, velocidad de recuperación y margen para crecer, y no hay línea de meta. Llegas a 40 GB/s de lectura media y alguien pregunta por 50. Alcanzas dos millones de IOPS y la gente se pregunta enseguida qué viene después.

    Esa mentalidad impulsa la innovación, y también desgasta a la gente. A los equipos de infraestructura se les pide que aprieten más sin dejar de ser fiables, que escalen más sin dejar de ser manejables y que vayan más rápido sin provocar caídas. Historias como esta calan porque muestran que la preparación da frutos. Una buena arquitectura absorbe el crecimiento, y una mala pelea contra él.

    El rendimiento no significa nada sin confianza

    La confianza es difícil de medir. Los paneles no la muestran y los benchmarks solo la captan en parte. Se ve cuando los equipos dejan de temer las ampliaciones, cuando escalar deja de parecer arriesgado y cuando los sistemas se comportan de forma predecible bajo presión.

    El mundo del almacenamiento ya tiene historias de sobra sobre crecimientos dolorosos: ampliaciones que salieron mal, incompatibilidades de hardware que nadie previó, cuellos de botella inesperados, pesadillas de migración, largas ventanas de rebalanceo y muchas horas de sueño perdidas. Esas historias de terror se propagan rápido porque casi todo el mundo acaba coleccionando alguna, así que las experiencias más fluidas destacan. Un escalado que sale bien cambia cómo aborda un equipo la siguiente decisión. Crecer parece menos peligroso, experimentar resulta más fácil y las ambiciones aumentan, y eso importa más que cualquier captura de un benchmark.

    La buena infraestructura se funde con el fondo, y la gente solo se fija en ella cuando algo falla. El mejor cumplido que puede recibir un sistema de almacenamiento puede sonar aburrido: "Simplemente siguió funcionando".

    La verdadera prueba todavía no ha llegado

    Añadir el sexto nodo respondió una pregunta y abrió otra: ¿cuánto rendimiento queda por sacar? La gente de infraestructura rara vez se detiene después de una ampliación. Vuelve a hacer benchmarks, reajusta, mide y aprieta más, porque alcanzar un límite suele dejar ver el siguiente.

    Ahora que el clúster ha superado el crecimiento, las preguntas abiertas son si el rendimiento subió de forma apreciable, si mejoraron los patrones de escritura, si se mantuvo la eficiencia del escalado, dónde queda la latencia y si el número de clientes puede subir todavía más. Siempre hay otra gráfica que vigilar y otro techo que encontrar. Los sistemas mejoran, las expectativas suben y el hardware evoluciona, así que los límites se siguen moviendo.

    En algún lugar, en una sala llena de paneles, alguien ve cómo los números superan los de ayer y sonríe, porque descubrir que un sistema rápido puede ir más rápido es de las mejores sensaciones de este oficio.