Fast EC llega apagado: el interruptor de Ceph Tentacle que solo gira una vez

Ceph Tentacle trae el trabajo de rendimiento en erasure coding que llevaba años en la lista de deseos. En el banco de pruebas de los propios desarrolladores, con un perfil 6+2 y un stripe_unit de 16K, las escrituras pequeñas «al menos doblan» el rendimiento frente a Squid. Dos cosas que no dice el titular: ese 16K es exactamente lo que un pool ya creado no puede tener, y Fast EC llega apagado. Se enciende pool por pool, con un comando, y el monitor se niega a apagarlo después.

Escribimos esto porque es la clase de detalle que se pierde entre la nota de la release y la ventana de mantenimiento. Proxmox VE 9.2, publicado en mayo, ya trae Ceph Tentacle 20.2.1 como versión estable por defecto —con Squid 19.2.3 todavía disponible como opción—. Mucha gente ya tiene Tentacle instalado. Y sigue leyendo los mismos números de rendimiento que antes.

Qué hace Fast EC, una frase por optimización

El pecado original del erasure coding es conocido: para tocar un byte había que mover la banda entera. Las cuatro optimizaciones que describe el equipo de Ceph atacan exactamente eso.

• Lecturas parciales. Se lee el mínimo necesario en vez de la banda completa. De ahí sale la mejora de dos a tres veces en lecturas pequeñas de bloque y fichero.
• Fin del relleno de objetos pequeños. Se deja de rellenar los objetos pequeños hasta la banda completa. Esta no es una mejora de velocidad, es de espacio: es la parte de «amplificación» del titular.
• Escrituras parciales. Antes de recalcular las paridades se leen solo los trozos modificados, no todos.
• Escrituras por delta de paridad (PDW). Ceph se trae una técnica clásica de controladora RAID: lee el dato viejo, lo combina con el nuevo mediante XOR y aplica el delta a la paridad. Con m=2, son tres lecturas y tres escrituras por trozo.

Los números, con el banco de pruebas delante

Conviene mirar dónde se han medido: un solo nodo, ocho OSD sobre NVMe, dos Intel Xeon Platinum 8276M a 2,20 GHz con 28 núcleos por zócalo. En carga mixta —70% lecturas y 30% escrituras de unos 16k, que es el patrón típico de aplicaciones transaccionales y de fichero—, «comparado con Squid, hay al menos el doble de rendimiento con FastEC». La comparación concreta es Squid con 4K frente a Tentacle con 16K, ambos 6+2.

Y la frase que sigue en el mismo artículo, que casi nadie cita porque estropea el titular: «la réplica de tres vías sigue siendo más rápida» —el pool 6+2 con Fast EC se queda en torno a la mitad de su rendimiento—. Fast EC no gana esa discusión, la estrecha. El propio equipo de Ceph lo remata con una frase honesta que vale por todo el artículo: con erasure coding «obtienes la mitad del rendimiento a menos de la mitad del coste». Eso es un intercambio, no una victoria.

Ese banco de pruebas tampoco es tu clúster. Fast EC recorta trabajo de CPU y de entrada/salida dentro del nodo; si tu cuello de botella está en una red de 10 GbE compartida con el tráfico de las máquinas virtuales, o en discos giratorios, la mejora será mucho más discreta, porque el problema nunca estuvo ahí. Un número de laboratorio con un solo nodo no es una promesa para tres nodos en producción: sirve para saber qué se ha arreglado, no cuánto vas a ganar tú. Si esto te suena a la conversación de siempre sobre erasure coding frente a réplica 3, es exactamente eso: mueve un término de la cuenta que hicimos en su día, sin dar la vuelta al resultado.

Un comando, un pool, una sola dirección

Fast EC se activa por pool con una bandera:

ceph osd pool set <pool> allow_ec_optimizations true

En Proxmox, un pool con erasure coding se crea en realidad como dos: uno replicado para los metadatos y otro para los datos, que es el que lleva el sufijo -data. La documentación de Proxmox usa ese sufijo en el ejemplo, y merece la pena fijarse: el nombre que ves en la interfaz no es el pool sobre el que hay que lanzar el comando.

La documentación de Ceph avisa sin adornos: «una vez la bandera se ha activado para un pool no se puede desactivar, porque cambia cómo se almacenan los datos nuevos». Proxmox lo traduce a lenguaje de operaciones y es todavía más claro: es un interruptor de una sola dirección, el monitor se niega a limpiar la bandera y revertirlo exige vaciar y recrear el pool.

Ahí está el criterio que nos importa: cualquier cosa que se deshace «vaciando y recreando el pool» no es una opción de configuración, es una migración. Se parece más a cambiar el tipo de una columna en una base de datos con veinte terabytes dentro que a marcar una casilla. Y las migraciones se planifican, se prueban antes en un pool pequeño y se hacen con la ventana abierta.

Las cuatro condiciones que comprueba el monitor

Proxmox las enumera como cuatro requisitos que el monitor de Ceph hace cumplir. Las cuatro se comprueban en dos minutos:

• Todo el clúster en Tentacle, y declarado. La bandera no se puede activar mientras no estén actualizados todos los monitores y OSD, y el clúster tiene que estar en require_osd_release tentacle o posterior. Ese último paso es manual y va después de actualizar los paquetes: es el que más se queda a medias. Se mira con ceph osd dump | grep require_osd_release.
• Que el pool sea de erasure coding. El nombre de un pool no dice nada de su tipo; ceph osd pool ls detail sí.
• Plugin y técnica compatibles. Las optimizaciones «solo están soportadas de momento con los plugins Jerasure e ISA-L usando la técnica reed_sol_van». Se comprueba con ceph osd erasure-code-profile get <perfil>.
• Que el stripe_unit del pool sea múltiplo de 4096 bytes. El valor por defecto ya lo cumple, así que esto solo afecta a pools creados con un stripe_unit a medida. Tentacle rechaza explícitamente los tamaños de trozo no alineados a 4k.

Hay una quinta que Proxmox no lista y la documentación de Ceph sí: el pool tiene que residir sobre OSD BlueStore, porque las sumas de verificación de BlueStore se usan durante el deep scrub. En un clúster montado en los últimos años esto se cumple sin pensarlo; en uno heredado con FileStore, es lo primero que hay que mirar.

La otra mitad de la mejora la decidiste hace años

La documentación de Ceph lleva años avisando de algo que casi nadie lee cuando crea su primer pool: «elegir el perfil correcto es importante porque el perfil no se puede modificar después de crear el pool». El k, el m, el plugin y la técnica quedan congelados el día de la creación. Y el stripe_unit, que se especifica al crear el perfil, tampoco se toca después.

Ahí es donde la mejora se parte en dos. El stripe_unit por defecto sigue siendo 4K en Tentacle, y el equipo de Ceph recomienda 16K para los pools nuevos que vayan a usar Fast EC —hasta 256K si la carga es mayoritariamente de lectura, a costa de desperdiciar capacidad con ficheros y objetos pequeños—. Sobre los pools que ya existen, la frase es literal: «no es posible cambiar el stripe_unit; Fast EC se puede activar igualmente en esos pools, pero la mejora de rendimiento será algo menor». Conviene atarlo con el titular: ese «al menos el doble» se midió contra un pool de 16K; sobre el 4K que tienes, la propia fuente promete «algo menos». Quien en su día eligió una técnica del plugin jerasure distinta de reed_sol_van —cauchy_good, liberation y compañía— no se lleva nada: para ese pool no hay interruptor, hay pool nuevo y mover los datos.

ISA-L toma el relevo de jerasure

El cambio silencioso de esta versión es que ISA-L pasa a ser el plugin por defecto de los pools con erasure coding. El perfil por defecto de Tentacle sale ya con plugin=isa, k=2, m=2 y technique=reed_sol_van; en Squid, esa misma página mostraba plugin=jerasure. El motivo lo explica la documentación sin diplomacia: la biblioteca jerasure «ya no se mantiene y no se ha actualizado para soportar instrucciones modernas de CPU» que aceleran la codificación y la decodificación.

Hay además un aviso con fecha, todavía no en la documentación de Tentacle sino en la rama de desarrollo (la consultamos el 7 de agosto de 2026): las técnicas distintas de reed_sol_van quedan marcadas como obsoletas y el soporte se retirará en la release Vampire. Si tienes un pool con una de esas técnicas, ya tienes un trabajo apuntado en la lista, y ese trabajo consiste en mover datos: cuanto más tarde, más datos habrá que mover.

Lo que le pasa al clúster cuando lo enciendes

La bandera se puede activar en pools que ya existen —eso es una buena noticia— y también se puede dejar puesta por defecto para los pools nuevos con la opción de configuración central osd_pool_default_flag_ec_optimizations. Lo que no es gratis es el momento de encenderla.

La documentación de Proxmox describe el efecto secundario con una precisión que se agradece: Fast EC marca los shards de datos del 1 al k-1 como no primarios, así que los grupos de colocación que tuvieran el primario en uno de esos shards vuelven a hacer peering; y ese re-peering cancela cualquier scrub en vuelo, con lo que esos PG habrá que volver a revisarlos después.

Traducido a lo que significa un martes cualquiera: hay un rato de movimiento en el clúster, la ventana de scrubs se descoloca y durante ese rato tu tolerancia a que se caiga un nodo es más fina de lo habitual. Es una ventana de mantenimiento, no una casilla. Se hace de un pool en un pool, con la monitorización delante, y se deja que el clúster vuelva a HEALTH_OK antes del siguiente.

Tres casos en los que esperaríamos

• Si tu pool EC es de objetos grandes. El propio equipo de Ceph acota el alcance: Fast EC está pensado sobre todo para cargas de bloque y fichero, y en objeto (S3) puede ayudar con objetos pequeños o lecturas de acceso aleatorio. Un repositorio de vídeo o de copias que escribe secuencialmente objetos de cientos de megabytes no es el caso de uso.
• Si todavía estás en Squid. Entonces esto no es tu siguiente trabajo: el siguiente es la actualización, y conviene mirarla con calendario. Squid figura en la tabla de releases de Ceph, consultada hoy, con fin de vida estimado el 31 de octubre de 2026; escribimos en su día sobre la fecha que constaba entonces, y que se haya movido es exactamente el motivo por el que estas fechas se llaman «estimadas» y no se planifican para el último día. Si además tu hipervisor sigue en Proxmox VE 8, ahí hay otro reloj corriendo por delante de este.
• Si nadie va a medir antes y después. Encender un interruptor irreversible sin una línea base es fe, no ingeniería. Media hora de fio con el patrón real de tu carga —no con el que sale bonito— vale más que cualquier gráfica de una nota de release, incluidas las que hemos citado aquí.

Decisiones de arquitectura sin acta

Operamos Proxmox VE con Ceph en producción desde hace años, y la lección que más veces se repite no tiene que ver con el hardware. Es esta: en un sistema de almacenamiento, los valores por defecto son decisiones de arquitectura de las que no queda acta. Nadie firmó que el stripe_unit fuera 4K. Nadie discutió en una reunión si el perfil debía ser 2+2. Salió así del asistente, funcionó, y ahí sigue años después decidiendo el rendimiento de las máquinas de alguien.

Fast EC es la primera vez en mucho tiempo que esos valores pasan factura de forma medible. Así que, antes de planificar la actualización, saca el perfil de cada pool con ceph osd erasure-code-profile get y anota en cuál de los tres grupos cae: el que puede encender el interruptor y ganar lo que promete la fuente, el que puede encenderlo y ganar «algo menos» porque arrastra 4K, y el que no puede encenderlo en absoluto. Los tres son respuestas válidas. Lo que no es válido es no saberlo y planificar la ventana igual.

Si quieres que lo miremos contigo —el perfil de cada pool, si el interruptor se puede encender, qué ganarías de verdad con tu carga y en qué orden—, eso es parte de lo que hacemos en almacenamiento distribuido con Ceph y en el soporte y la operación del día a día.

Fuentes (verificadas el 7 de agosto de 2026): las cuatro optimizaciones de Fast EC (lecturas parciales, fin del relleno de objetos pequeños, escrituras parciales y escrituras por delta de paridad, con tres lecturas y tres escrituras por trozo con m=2), las cifras («al menos el doble» de rendimiento en escrituras pequeñas, dos a tres veces en lecturas pequeñas, «al menos el doble» en carga mixta 70/30 a 16k comparando Squid a 4K con Tentacle a 16K), el banco de pruebas (un nodo, 8 OSD NVMe, 2 × Intel Xeon Platinum 8276M a 2,20 GHz, 28 núcleos por zócalo), las frases sobre el stripe_unit (4K por defecto, 16K recomendado para pools nuevos, imposible de cambiar en pools existentes) y las dos frases que matizan el titular —«la réplica de tres vías sigue siendo más rápida» y «con erasure coding obtienes la mitad del rendimiento a menos de la mitad del coste»— proceden del artículo Fast Erasure Coding for Tentacle del blog oficial de Ceph. Las condiciones de activación, la irreversibilidad de la bandera («una vez activada para un pool no se puede desactivar porque cambia cómo se almacenan los datos nuevos»), el requisito de tener todos los monitores y OSD en Tentacle, la restricción a los plugins Jerasure e ISA-L con la técnica reed_sol_van, el requisito de OSD BlueStore, la recomendación de 16K a 256K con su contrapartida y la opción osd_pool_default_flag_ec_optimizations están en la documentación de erasure code de Ceph Tentacle, de donde también sale la frase sobre la inmutabilidad del perfil y el perfil por defecto (k=2, m=2, plugin=isa, technique=reed_sol_van); que en Squid esa misma página mostraba plugin=jerasure se comprueba en su versión para Squid. Que ISA-L es el plugin por defecto está en la página del plugin ISA; que jerasure «ya no se mantiene y no se ha actualizado para soportar instrucciones modernas de CPU» y la lista de técnicas (reed_sol_van, reed_sol_r6_op, cauchy_orig, cauchy_good, liberation, blaum_roth, liber8tion), en la página del plugin jerasure. La nota de obsolescencia de las técnicas distintas de reed_sol_van y su retirada en la release Vampire aparece en la versión de desarrollo de esa misma página (docs.ceph.com/en/latest), no todavía en la de Tentacle, y así lo hemos escrito. Los requisitos operativos en Proxmox (los cuatro que el monitor hace cumplir, require_osd_release tentacle, el sufijo -data del pool, el stripe_unit múltiplo de 4096 que el valor por defecto ya cumple, el interruptor de una sola dirección y el re-peering que cancela los scrubs) están en el wiki de Proxmox, procedentes del parche de documentación enviado a la lista pve-devel el 16 de abril de 2026. Que Proxmox VE 9.2 trae Ceph Tentacle 20.2.1 por defecto con Squid 19.2.3 como opción, del anuncio de la versión. Las fechas de las releases (Tentacle 20.2.0 el 18 de noviembre de 2025, 20.2.1 el 6 de abril de 2026, 20.2.2 el 16 de junio de 2026 y 20.2.3 el 5 de agosto de 2026; fin de vida estimado de Squid el 31 de octubre de 2026) proceden de la tabla de releases de Ceph. No hemos medido Fast EC en nuestro propio clúster: todos los números de este artículo son de terceros y así se citan. Fotografía de la imagen social: parte trasera de un rack en el centro de datos del NERSC, Wikimedia Commons, dominio público (CC0).