IBM COS vs Ceph: cuándo migrar, en qué dirección y por qué.
Tres caminos para hacer object storage a escala petabyte — y cómo llegamos a la recomendación correcta en cada caso. Con quince años de despliegues en producción y tres casos reales sobre la mesa.
En 2026, si llevas un despliegue de object storage de varios petabytes y te planteas qué hacer con él los próximos cinco años, tienes tres opciones realistas sobre la mesa: IBM Cloud Object Storage (el heredero de Cleversafe), Ceph upstream apoyado en un partner de soporte, o Ceph empaquetado comercialmente — típicamente IBM Storage Ceph.
Nuestra preferencia es el open source y lo decimos al principio para no hacer perder el tiempo a nadie. Pero también hemos recomendado IBM COS a clientes concretos sabiendo que era la respuesta correcta, y nos hemos opuesto a migraciones que nos habrían facturado bien pero que habrían complicado la vida del cliente sin ganancia real. En este artículo explicamos cuándo y por qué, con casos vividos.
El contexto de 2026, sin adornos
El mercado de object storage on-premise lleva tres años en reacomodo. IBM ha ido reposicionando COS varias veces desde que absorbió Cleversafe en 2015: primero como producto independiente, luego empujado hacia IBM Storage Ready Nodes, después integrado en el discurso de «cyber vault» dentro del portfolio de Storage Defender. Los clientes históricos de Cleversafe — muchos de ellos con despliegues legacy de más de diez años sobre hardware Cisco UCS que ya tocaron fin de vida — se preguntan cuál es el camino a cinco años.
Ceph, mientras tanto, ha hecho lo contrario. Ha consolidado. La release actual Tentacle (20.2.1, abril de 2026) cierra un ciclo de madurez que arrancó con Reef y Squid, y el proyecto tiene contribuciones activas de CERN, DigitalOcean, Bloomberg, OVH, Clyso, Red Hat/IBM y SUSE. Es difícil encontrar un proyecto open source de infraestructura con más actividad sostenida.
En el medio ha aparecido IBM Storage Ceph: Ceph upstream empaquetado y soportado comercialmente por IBM, heredero directo de Red Hat Ceph Storage. Técnicamente es el mismo Ceph. Comercialmente es una suscripción con SLA vendor tier-1. Existe porque hay clientes cuyos pliegos exigen soporte enterprise con nombre conocido, y Ceph upstream «a secas» no pasa ese corte aunque técnicamente sea idéntico.
Tres productos, tres modelos de negocio, tres perfiles de cliente distintos.
Los tres protagonistas, en sesenta segundos
Hover sobre cada tarjeta para más detalle · La opción correcta depende de la realidad operativa de cada cliente
Los tres funcionan. A nivel técnico, las diferencias que importan no están en el qué hacen sino en el cómo se operan y en el cuánto cuestan a cinco años. IBM Storage Ceph e IBM COS no compiten entre sí — sirven a perfiles distintos. Si te interesa la comparativa de Ceph frente a Storage Scale, GPFS o NFS, tenemos un artículo específico: IBM Storage Ceph vs Storage Scale, GPFS, GFS2, NFS y SMB.
Por qué preferimos open source
No es ideología. Es el resultado de ver, proyecto tras proyecto, que un cliente con buen equipo interno o con un partner competente detrás obtiene sobre Ceph upstream la misma estabilidad operativa que sobre cualquier alternativa comercial, con bastante más libertad y por menos dinero.
El lock-in de los productos propietarios no es solo de hardware, es también de roadmap. Si mañana IBM reposiciona COS otra vez — y ya ha pasado varias veces desde 2015 —, el cliente mira el cambio desde la barrera. Con Ceph, si tu distribuidor comercial cambia de estrategia o sube precios, te mueves a upstream o a otro distribuidor sin migrar datos. La portabilidad es real, no es marketing.
La comunidad es garantía de continuidad de una manera que un solo fabricante no puede serlo. Un producto propietario depende en última instancia de una hoja de cálculo en la sede del fabricante. Ceph tiene tantos contribuidores institucionales que si uno se va — cosa que ha pasado — el proyecto sigue. Para infraestructura que vas a tener quince o veinte años en producción, esto cuenta.
La versatilidad arquitectónica se paga sola. Object storage hoy, block mañana para virtualización, file puntual, NVMe-oF cuando aparezca la necesidad. Todo sobre el mismo hardware y el mismo equipo. COS solo hace object bien. Separar plataformas por protocolo duplica equipos, procedimientos y contratos de soporte. Y para los casos donde Ceph actúa como backend NFS, hemos documentado el proceso en este artículo: NFS de alta disponibilidad con Ceph Ganesha.
La transparencia operativa es otro tipo de seguridad. Cuando algo falla en Ceph, tienes el código. Cuando algo falla en COS, abres un caso y esperas. Para equipos técnicos serios, la primera vale más de lo que aparenta en una comparativa de features.
El open source no es gratis. Es distinto. Lo que te ahorras en licencias lo pagas en horas de equipo, propio o contratado. Si no tienes el equipo ni un partner que actúe como extensión de él, la cuenta puede darse la vuelta. Por eso la siguiente pregunta importa tanto como la filosofía: ¿quién opera esto en el día a día?
Cuándo IBM COS es la respuesta correcta
Si fuéramos talibanes del open source estaríamos vendiendo humo y ya hay suficiente en el mercado. COS es la elección correcta para un perfil de cliente bastante concreto.
Equipos operativos pequeños, sin skills profundos en SDS y sin presupuesto para contratarlos ni para externalizar de forma continua. La curva de aprendizaje de Ceph es real. Si la organización no puede asumirla, un producto empaquetado como COS reduce la superficie de problemas operativos.
Sectores regulados con requisitos de compliance muy específicos — WORM auditado, retención bajo SEC 17a-4, Compliance Enabled Vaults, NENR. El ecosistema IBM está muy maduro aquí y las auditorías van más rápido cuando todo el stack es del mismo fabricante.
Política corporativa de «una sola garganta que apretar» con preferencia explícita por vendor tier-1. Hay organizaciones — banca conservadora, administración pública, defensa — donde el CISO no acepta una arquitectura sin SLA contractual. Discutir con esa política desde fuera es perder el tiempo; lo correcto es ayudar al cliente a elegir el producto que mejor encaje.
Ecosistema IBM ya desplegado. Si el cliente ya tiene Spectrum Protect, Storage Defender, Fusion, Power o Z, consolidar object storage dentro del mismo paraguas vendor tiene lógica operativa y comercial.
Escala muy grande (petabytes altos o exabytes) con workload predecible y estable, donde la simplicidad operativa de un producto maduro compensa el coste de la licencia. Hemos visto clientes con más de un exabyte bajo soporte IBM para los que migrar supondría un proyecto de tres años y decenas de millones; en esos casos la respuesta es quedarse y optimizar.
La inercia, el miedo mal informado al open source, o dar por buena la partida anual de licencia sin cuestionarla. Eso sí lo cuestionamos siempre.
Cuándo Ceph upstream con buen partner es la respuesta
Este es el escenario donde creemos que está la mayoría del mercado, aunque no siempre lo sepa.
Perfiles donde Ceph upstream gana claro:
- Cliente con equipo técnico competente en Linux e infraestructura, o dispuesto a tener partner de soporte continuado.
- Escala media-grande, de cientos de TB a decenas de PB, donde la suscripción comercial empieza a dolerle al presupuesto.
- Necesidad o intención de unificar object, block y file en la misma plataforma.
- Refresh de hardware en curso sin ganas de atarse a una lista certificada de un único fabricante.
- Integración nativa con Kubernetes vía Rook, si hay plataforma cloud-native en el mapa.
- Preferencia, simplemente, por poder ver lo que hay debajo del capó.
Aquí toca enfrentar un mito que lleva años rondando: que Ceph es difícil. Lo es a medias. Ceph es complejo — como lo es cualquier sistema distribuido serio — pero no es caótico ni inestable. La diferencia entre un cluster Ceph que da guerra y uno que corre años sin incidentes no está en el software. Está en el diseño del despliegue, en el tuning de los placement groups y del balancer, en la elección de hardware coherente, en la monitorización, y en tener a alguien al otro lado del teléfono que sepa qué hacer cuando algo raro aparece en ceph health detail. Tenemos un artículo específico sobre el error más común de Ceph y cómo corregirlo.
El problema no es Ceph. El problema es desplegarlo sin expertise. Eso es un problema de cualquier infraestructura compleja, no un defecto del producto.
Un cluster Ceph bien operado funciona igual de bien con soporte upstream más partner competente que con una suscripción enterprise. La diferencia real es quién coge el teléfono a las tres de la mañana. Si te estás planteando Ceph frente a alternativas más ligeras de object storage, el artículo Ceph vs MinIO para 2026 cubre ese análisis en detalle.
IBM Storage Ceph: la opción intermedia
Aquí nos mojamos más, porque sobre este producto se escribe poco con claridad.
IBM Storage Ceph es, en lo técnico, Ceph. El mismo Ceph que te bajas de la web del proyecto. Empaquetado, probado, integrado con herramientas propias de IBM, soportado comercialmente con SLA, y certificado en varios entornos regulados. Eso es lo que pagas. Técnicamente no tienes nada que no puedas tener con upstream.
Cuándo tiene sentido pagarlo:
- Pliegos de contratación pública o privada que exigen vendor tier-1 con soporte contractual, sin margen de negociación.
- Organizaciones donde la política de compras obliga a soporte enterprise sí o sí, y no hay manera de homologar a un partner externo como sustituto.
- Clientes que ya tienen un ELA con IBM y añadir Storage Ceph al paquete sale razonable frente al precio de lista.
- Sectores con auditorías donde el nombre del fabricante en la factura acorta el proceso.
Cuándo no vale la pena: en prácticamente todos los demás casos. Si tu compliance no te obliga y tienes un partner decente, pagar suscripción por upstream es un sobrecoste evitable. A escala decenas de petabytes, la diferencia entre suscripción comercial y partner de soporte sobre upstream puede rondar cientos de miles de euros al año. A escala exabyte, pasa a millones. Ese dinero, para la mayoría de los clientes, vale más reinvertido en equipo, hardware o cualquier otra cosa.
Si tu realidad te empuja al primero o al segundo, ahí estaremos para ayudarte a operarlo bien. Pero la mayoría de clientes con los que trabajamos descubren, tras un assessment honesto, que el tercero les encaja mejor de lo que pensaban.
Tres casos reales
Anonimizados, porque los NDAs son los NDAs. La moraleja siempre es la misma: la pregunta correcta no es «cuál es mejor en abstracto» sino «cuál encaja con esta realidad concreta».
Lo que la mayoría de comparativas no cuenta
Cuatro cosas que en los whitepapers de vendor nunca aparecen y que hemos visto tropezar a muchos equipos técnicos.
Migrar a escala petabyte no es copiar datos
Es migrar configuración: lifecycle policies, retention, legal holds, ACLs, CORS, bucket policies, versioning, notificaciones de eventos, tagging, replicación. Se migra el contexto tanto como los bytes. Un proyecto de migración mal escopado se da cuenta de esto a mitad de camino y se le duplica el calendario.
El dialecto S3 no es uniforme
Entre AWS S3, Ceph RGW e IBM COS hay diferencias sutiles en headers, en comportamiento de LIST con muchos objetos, en casos borde de multipart upload, en la semántica de versioning. Las aplicaciones cliente a veces necesitan ajustes. Hay que probar, no asumir.
La protección de datos cambia de filosofía según el producto
El IDA de COS, el erasure coding de Ceph y la replicación triple tradicional no son intercambiables a nivel de garantías de durabilidad ni de perfil de fallos que toleran. Traducir un IDA 10/8/7 de COS a un perfil de erasure coding de Ceph requiere criterio, no es aritmética.
El día a día operativo es radicalmente distinto
En COS diagnosticas con storagectl list y el shell del Manager. En Ceph con ceph -s, ceph osd tree, ceph health detail, placement groups, OSDs, CRUSH maps. Reentrenar a un equipo cuesta entre seis y doce meses de transición efectiva. Hay que presupuestarlo, no puede ser una nota al pie del proyecto.
Cómo trabajamos en SIXE
El esquema lleva años funcionando. Primero un assessment: revisamos la arquitectura actual, los workloads reales, el perfil del equipo operativo, las restricciones regulatorias, el presupuesto a tres o cinco años y las opciones técnicas viables. El output es una recomendación motivada, con alternativas, y a veces es «quédate donde estás». Lo hemos dicho más de una vez.
Luego un diseño, si hay migración o cambio sustancial. Arquitectura objetivo, plan por fases, ventanas operativas, matriz de riesgos, runbooks. No hay dos migraciones iguales.
Después la ejecución. Migración en fases con dual-running cuando es posible, validación de datos, QA funcional con aplicaciones cliente, ajuste fino post-corte.
Y finalmente el handover con mentoring al equipo del cliente, más soporte técnico Ceph continuado si quieren que sigamos al otro lado del teléfono. Muchos clientes prefieren este modelo — SIXE como extensión de su equipo — frente a una suscripción comercial. Es exactamente lo que hace viable Ceph upstream en producción seria. Para los equipos que quieren construir capacidad interna, tenemos el curso de administración de Ceph y el curso práctico de IBM Storage Ceph.
Nuestro equipo diagnostica un DONT-START-DAEMON de un slicestor ClevOS con la misma soltura que un placement group inactive+incomplete de Ceph. No somos un partner «de IBM» ni «de Ceph». Somos un partner de object storage, y conocemos las tres opciones lo suficientemente bien como para recomendar la que toca en cada caso.
Una conversación técnica honesta, sin pitch comercial.
Cuéntanos tu despliegue actual — capacidad, workloads, equipo, restricciones regulatorias — y te decimos qué tiene sentido hacer. Si la respuesta es «quédate donde estás», también te lo decimos.
Blog!
Nuestra mision
SIXE garantiza que tus infraestructuras basadas en tecnologías IBM®, Red Hat®, Canonical® y SUSE® permanezcan estables, seguras y optimizadas durante todo el tiempo que las necesites.
En SIXE, nos comprometemos con la sostenibilidad. Por eso te ayudamos a diseñar, implementar y mantener soluciones tecnológicas duraderas y eficientes.
