El soporte de 12.10 se ha acabado. Pero mientras no mirabas, Informix ha cambiado bastante: contenedores standalone para Kubernetes, un motor nuevo por dentro, backup nativo a S3 y una certificación que cambia de versión.
6 min lectura●Bases de datos · Cloud-native
En marzo, Anup Nair — Principal Technical Product Manager de Informix — publicó en IBM TechXchange el anuncio del Informix Standalone Container. Imágenes enterprise-grade para Kubernetes y OpenShift, con soporte oficial, sin depender de Cloud Pak for Data. El post acumula 13 visualizaciones y cero comentarios. Casi nadie se ha enterado.
Y sin embargo, es probablemente el cambio más significativo en la forma de desplegar Informix desde que IBM lo compró. Junto con el fin del soporte de 12.10, las novedades de Informix 15 y la transición de la certificación a v15, el panorama ha cambiado bastante. Aquí lo resumimos.
La noticia
Contenedores standalone: qué ha cambiado
Hasta hace poco, si querías Informix en contenedores con soporte enterprise en producción, el único camino era Cloud Pak for Data (CP4D). Las imágenes de Docker Hub — que se han movido al IBM Container Registry (ICR) — eran Developer Edition: válidas para desarrollo, sin soporte para producción.
En la práctica esto significa integrar Informix en pipelines CI/CD, levantar instancias para tests automatizados, desplegar con Helm Charts en hybrid-cloud y tener entornos dev idénticos a producción. Daniel Weber, Informix Container Dev Lead, hizo demo del proceso en la IIUG Tech Talk de abril.
Es el tipo de anuncio que no sale en titulares pero cambia cómo se opera un producto en el día a día.
El corte
Informix 12.10 ha perdido el soporte
El 30 de abril, IBM ha completado la transición de Informix 12.10 a Extended Support. Tres consecuencias directas:
Sin parches de seguridad. Cualquier vulnerabilidad descubierta queda sin resolver.
Sin correcciones de bugs. El fixpack actual es el último.
Soporte técnico solo de pago bajo Extended Support, hasta 2030.
12.10 se lanzó en 2013. Trece años es un ciclo razonable. Pero muchos entornos siguen corriendo esta versión porque «funciona» y nunca hubo presión suficiente para migrar. Ahora la presión existe — y coincide con que hay un camino de modernización real: contenedores, cifrado nativo, backup a S3.
La decisión
14.10 o 15: cuál elegir para migrar
Informix 15 (noviembre 2024) es la primera release major en más de un lustro, con cambios profundos en las estructuras internas del motor: límites ampliados drásticamente (una partición puede tener 140 billones de páginas), cifrado nativo por dbspace, Wire Listener mejorado (MongoDB 3.2–4.2), backup a S3/Azure/IBM COS con ON-Bar, Helm Charts oficiales y Java 11 obligatorio.
Informix 14.10xC13 (enero 2026) es la última release de la rama 14.10: mejoras en archecker para SmartLOBs, Direct I/O para bloques 2K/4K, y las correcciones acumuladas. Madura, probada, conservadora.
Estable · Probado
Informix 14.10xC13
Enero 2026 · Release madura
RiesgoBajo
UpgradeIn-place desde 12.10
DriversAlta compatibilidad
Cifrado dbspaceNo
Backup S3No nativo
ContainersStandalone ✓
Nuevo motor
Informix 15.0.1
Nov 2024 · Release actual
RiesgoMedio
UpgradeIn-place desde 12.10
DriversRequiere validación
Cifrado dbspaceSí — nativo
Backup S3ON-Bar nativo
ContainersStandalone + Helm ✓
Nuestra recomendación: si el entorno es estable y no necesitas las funcionalidades de 15, la ruta 12.10 → 14.10 es la más segura. Te da tiempo a que Informix 15 acumule fixpacks. Si el proyecto es nuevo o necesitas cifrado at-rest, backup a cloud o Kubernetes nativo, ve directo a 15.
Lo que no recomendamos
Quedarse en 12.10 bajo Extended Support «hasta que no haya más remedio». El Extended Support tiene fecha de fin y cuanto más esperes, menos flexibilidad tendrás. Migrar con prisas es caro. Migrar planificadamente es un proyecto controlable.
El equipo
Por qué formar al equipo importa tanto como migrar
Lo vemos proyecto tras proyecto. Un equipo actualiza Informix y sigue operando con los mismos procedimientos de hace ocho años. El servidor está en versión nueva; el conocimiento sigue en la antigua.
14.10 introdujo AUTO_TUNE que convierte en innecesarios muchos ajustes manuales. 15 cambia la filosofía de cifrado, backup y despliegue. Y con los contenedores standalone hay un modelo operativo nuevo que requiere competencias de Kubernetes que un DBA clásico no necesariamente tiene. La documentación oficial está en la guía de despliegue containerizado de Informix 15, pero la documentación no sustituye a la formación práctica.
En SIXE llevamos más de 15 años impartiendo formación oficial de IBM. Hemos actualizado todo el temario de Informix a v15 con laboratorios nuevos y documentación propia.
Informix 15 & 14.10 System Administration (SIFMX819G) — 3 días / 24 horas. Desde la arquitectura del servidor hasta troubleshooting en producción, con módulo de migración 12.10→14.10/15 y despliegue en contenedores. Impartido por DBAs en activo sobre una instancia Informix 15 en vivo.
El catálogo completo de Informix incluye administración de sistemas, administración de bases de datos y cursos personalizados para migración. En español, inglés y francés — online, presencial, abierto o in-company.
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.
Abril 2026●11 min lectura●Infraestructura · Open Source
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
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.
Las opciones
Los tres protagonistas, en sesenta segundos
IBM COS
IDA patentado (SecureSlice), arquitectura cerrada de tres capas, hardware certificado. Fuerte en compliance regulatorio avanzado.
Propietario
IBM Cloud Object Storage
Heredero Cleversafe · ClevOS
LicenciaPropietaria IBM
HardwareLista cerrada cert.
ProtocolosObject S3 / Swift
Coste 5 añosAlto
Lock-inAlto
Op. complejidadBaja
IBM Storage Ceph
Ceph upstream con suscripción IBM. Mismo código, SLA contractual tier-1. Para quienes necesitan vendor enterprise en el pliego.
Ceph + IBM
IBM Storage Ceph
Red Hat Ceph heredero · ppc64le
LicenciaSuscripción IBM
HardwareCualquier x86/ARM
ProtocolosS3 · RBD · CephFS · NVMe-oF
Coste 5 añosMedio-alto
Lock-inMedio
Op. complejidadMedia
Ceph upstream + partner
Máximo control, coste más bajo, sin lock-in. Requiere madurez técnica propia o un partner que actúe como extensión del equipo.
Open Source
Ceph upstream
Tentacle 20.2.1 · Apache 2.0
LicenciaApache 2.0 · libre
HardwareCualquier hardware
ProtocolosS3 · RBD · CephFS · NVMe-oF
Coste 5 añosBajo
Lock-inNinguno
Op. complejidadAlta (requiere equipo)
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.
Nuestra posición
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 matiz importante
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?
Honestidad técnica
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.
Lo que no justifica quedarse en COS
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.
La mayoría del mercado
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.
La pregunta honesta. No es «¿puedo yo solo con Ceph?». Es «¿tengo a alguien — propio o contratado — que me cubra las espaldas?». Si la respuesta es sí, Ceph upstream da el mejor ratio coste/resultado del mercado. Si es no, hay que conseguir el alguien antes de firmar nada.
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.
La opción intermedia
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.
Sin floritura. COS = producto completo, vendor único, coste alto, lock-in alto, simplicidad operativa alta. IBM Storage Ceph = Ceph de la comunidad con factura IBM, tranquilidad contractual, coste medio-alto. Ceph upstream con partner = máximo control, coste bajo, requiere madurez — propia o prestada.
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.
Casos reales
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».
Casuística real · Tres perfiles, tres decisiones distintas
Hardware Cisco UCS M4 en fin de vida, refresh en hardware certificado IBM prohibitivo. Coste de licencia COS cuestionado internamente desde hacía años. Intención estratégica de consolidar object y block para la plataforma Kubernetes interna. Migración en fases durante 18 meses con dual-running. Resultado: coste operativo total reducido significativamente, equipo autosuficiente, SIXE como soporte de segundo nivel. Tres años después el cluster sigue estable.
Hardware EoLCoste licenciaConsolidación K8s
B
Entidad financiera regulada · 8 PB · Se quedaron en COS
Nos llamaron para evaluar una posible migración motivada por el coste. Hicimos el assessment completo. Recomendamos no migrar: equipo pequeño, sin presupuesto para asumir Ceph de forma autónoma, requisitos SEC 17a-4 con Compliance Enabled Vaults profundamente integrados en sus auditorías anuales, y aversión al riesgo operativo legítimamente alta. Ganamos menos, pero ganamos un cliente de largo plazo. Seguimos trabajando con ellos en optimización del despliegue existente y planificación del siguiente refresh.
Cluster Ceph desplegado internamente sin expertise suficiente: inestable, con incidentes recurrentes que habían quemado al equipo. Nuevo requisito de pliego exigía vendor tier-1 con soporte por contrato — upstream quedaba fuera. Los acompañamos en la migración a IBM Storage Ceph, la estabilización y la formación del equipo. Terminaron con un cluster sano. No era la opción más barata, pero era la única posible dadas las restricciones externas.
Pliego vendor tier-1Cluster inestable→ IBM Storage Ceph
Lo que nadie cuenta
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
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.
Qué es IBM DataStage y por qué sigue siendo el ETL de referencia en entornos enterprise.
Mientras el mercado de integración de datos se fragmenta entre herramientas cloud-native, notebooks y orquestadores de moda, DataStage lleva tres décadas moviendo los datos que importan — los de banca, sanidad, telecomunicaciones y administraciones públicas. Te contamos qué es, cómo funciona y cuándo tiene sentido en 2026.
Abril 2026●9 min lectura
Si trabajas con datos en una empresa grande, probablemente ya has oído hablar de DataStage — aunque quizá no sepas exactamente qué es, o lo confundas con "esa cosa de IBM que se usa para mover datos". Es bastante más que eso.
IBM DataStage es la herramienta ETL (Extract, Transform, Load) de la suite IBM InfoSphere. Lleva más de 25 años en producción, ha pasado por varias adquisiciones y rebrandings, y en 2026 sigue siendo una de las piezas centrales del ecosistema de datos de IBM — ahora también disponible como servicio dentro de IBM Cloud Pak for Data.
Los fundamentos
Qué es DataStage y de dónde viene
IBM DataStage es una herramienta de integración de datos que permite diseñar, desplegar y ejecutar pipelines que extraen información de múltiples fuentes, la transforman según reglas de negocio y la cargan en sistemas destino. En el mundo de la ingeniería de datos, esto se conoce como ETL — Extract, Transform, Load — y DataStage es una de las implementaciones más veteranas y robustas del mercado.
La historia es larga y vale la pena resumirla porque explica mucho de lo que es hoy. DataStage nació en los años 90 como producto de Ardent Software, fue adquirida por Informix, que a su vez fue comprada por IBM en 2001. Desde entonces forma parte de la familia IBM InfoSphere — una suite de herramientas para integración, calidad y gobierno de datos.
Lo que diferencia a DataStage de un script de Python o de un flujo en Apache Airflow no es lo que hace (mover datos de A a B), sino cómo lo hace: con una interfaz visual de diseño de jobs, un motor de procesamiento paralelo distribuido, conectores nativos para prácticamente cualquier base de datos o sistema del planeta, y un sistema de metadatos integrado que permite trazar de dónde viene cada dato y qué transformaciones ha sufrido.
En cristiano: DataStage es lo que usan las organizaciones que mueven millones de registros cada noche entre decenas de sistemas, y que necesitan que eso funcione siempre, sea auditable y no requiera un equipo de 15 personas para mantenerlo.
La arquitectura
Cómo funciona: el motor de procesamiento paralelo
El componente central de DataStage es su motor paralelo (Parallel Framework). A diferencia de las herramientas ETL que procesan datos de forma secuencial — un registro detrás de otro —, DataStage distribuye el trabajo entre múltiples particiones que se ejecutan simultáneamente. Es la misma idea que MapReduce o Spark, pero implementada antes de que esas tecnologías existieran.
Un pipeline típico en DataStage tiene esta estructura:
Pipeline ETL · DataStage Parallel Engine
Extracción
Conectores nativos para más de 80 fuentes de datos. Soporte bulk load, pushdown optimization y lecturas incrementales.
Extract
Fuentes
Db2OracleSAPAPIsCSVKafka
Procesamiento paralelo
El motor distribuye automáticamente la carga entre N nodos. Particionado inteligente, sort, join, aggregation y custom transforms.
Transform
DataStage
ReglasLimpiezaEnriquec.ParaleloN nodos
Carga
Entrega a DWH, data lakes y plataformas cloud con soporte batch y near-real-time via CDC. Rollback y auditoría incluidos.
Load
Destinos
DWHData LakeCloudBatch/RT
Consumo
Los datos transformados alimentan herramientas de BI, dashboards ejecutivos y modelos de ML/AI en producción.
Analytics
Consumo
CognosPower BIAI/ML
Hover sobre cada nodo para más detalle · DataStage gestiona E + T con procesamiento paralelo distribuido
Lo interesante del motor paralelo es que el desarrollador no tiene que pensar en el paralelismo. Diseñas el job como si fuera secuencial — arrastrando stages en el Designer — y el engine decide cómo particionar los datos, cuántos nodos usar y cómo redistribuir la carga. Puedes forzar particionado manual cuando necesitas control fino (por ejemplo, para garantizar que todas las filas con el mismo customer_id acaben en la misma partición), pero en la mayoría de casos el motor lo hace solo.
Los componentes del stack
DataStage Designer. La interfaz visual donde se diseñan los jobs. Arrastras stages (fuentes, transformaciones, destinos), los conectas con links, defines los metadatos de cada columna, y compilas. Es visual pero potente — detrás genera OSH (Orchestrate Shell), que es el lenguaje que el motor paralelo ejecuta.
DataStage Director. La consola de monitorización. Ves qué jobs están corriendo, cuáles han fallado, logs, estadísticas de rendimiento, y puedes relanzar o abortar ejecuciones.
Information Server. La capa que envuelve todo: seguridad, metadatos compartidos con otras herramientas InfoSphere (Quality Stage, Information Analyzer, IGC), API REST para automatización, y el repositorio central de definiciones de jobs.
Conectores. DataStage tiene conectores nativos para un catálogo enorme: Db2, Oracle, SQL Server, PostgreSQL, MySQL, SAP, Teradata, Netezza, Snowflake, Amazon Redshift, S3, Azure Blob, Kafka, ficheros planos, XML, JSON, APIs REST — la lista es larga. Estos no son wrappers genéricos ODBC — son conectores optimizados para cada motor, con soporte de bulk load, pushdown optimization y control fino de sesiones.
Casos de uso
Para qué se usa DataStage en la práctica
La pregunta no es tanto "para qué se puede usar" (la respuesta sería "para mover cualquier dato entre cualquier sitio") sino "para qué tiene sentido usarlo frente a alternativas más modernas o más baratas". Porque DataStage no es la herramienta más sencilla del mercado, y tiene un coste de licencia que no es trivial. Lo que justifica ese coste son escenarios muy concretos.
Alimentación de datawarehouses
Este es el caso clásico y sigue siendo el más común. Organizaciones que tienen un DWH — ya sea IBM Db2 Warehouse, Teradata, Snowflake o Redshift — y necesitan cargar datos limpios, transformados y enriquecidos cada noche (o cada hora) desde docenas de sistemas fuente. DataStage brilla aquí por el procesamiento paralelo: donde un script en Python tarda horas, un job de DataStage bien diseñado procesa el mismo volumen en minutos.
Migración de datos entre sistemas
Cuando una organización cambia de ERP, de core bancario o de sistema hospitalario, hay un proyecto de migración de datos que puede durar meses. DataStage se usa para mapear esquemas viejos a nuevos, aplicar reglas de conversión, validar integridad referencial y ejecutar cargas masivas con rollback. La trazabilidad de metadatos es crucial aquí — necesitas demostrar a auditoría que cada dato migrado tiene origen conocido.
Integración en tiempo real con CDC
Con IBM CDC (Change Data Capture) integrado, DataStage puede replicar cambios en bases de datos con latencias de milisegundos. Esto se usa en entornos donde los datos operacionales tienen que estar sincronizados entre sistemas en casi-tiempo-real — por ejemplo, entre el core bancario y el sistema de antilavado, o entre el ERP y el datawarehouse operacional.
Calidad y gobierno de datos
DataStage se integra nativamente con el resto de la suite InfoSphere: Quality Stage para limpieza y estandarización, Information Analyzer para profiling, e IBM Knowledge Catalog (antes IGC) para gobierno y linaje. Esto hace que los proyectos de gobierno de datos que necesitan trazabilidad de extremo a extremo tengan todo bajo el mismo paraguas.
Dónde DataStage tiene más sentido
Banca, seguros, telecomunicaciones, sanidad, administración pública y utilities. Son sectores con volúmenes masivos, regulación estricta (NIS2, PCI DSS, HIPAA, ENS), y entornos IBM Power donde DataStage corre de forma nativa. Si tu infraestructura ya es IBM — Power11, AIX, Db2 — DataStage encaja como un guante.
La evolución
DataStage en Cloud Pak for Data: la evolución de 2025-2026
La historia reciente de DataStage tiene un protagonista claro: IBM Cloud Pak for Data. Es la plataforma de datos unificada de IBM, construida sobre Red Hat OpenShift, que agrupa todos los servicios de datos (DataStage, Watson Studio, Knowledge Catalog, Db2, etc.) bajo una interfaz común.
El cambio más importante de los últimos meses fue en junio de 2025, con la versión 5.2 de Cloud Pak for Data: DataStage está disponible en OpenShift sobre IBM Power (ppc64le). Esto significa que las organizaciones con servidores Power que antes tenían que ejecutar DataStage en el stack clásico de InfoSphere ahora pueden containerizarlo y gestionarlo con la misma orquestación que el resto de sus workloads cloud-native.
La versión actual — Cloud Pak for Data 5.3 — trae DataStage con soporte completo para ETL y ELT, ejecución en remoto (puedes correr jobs en cloud sin mover los datos de tu datacenter), y el nuevo DataStage Flow Designer integrado en la interfaz web de Cloud Pak for Data. El Designer clásico de escritorio sigue siendo el preferido de los desarrolladores veteranos, pero IBM está empujando el flujo web para proyectos nuevos.
Un apunte sobre seguridad. En febrero y marzo de 2026, IBM publicó varios parches de seguridad para DataStage on Cloud Pak for Data 5.1.2 a 5.3.0, incluyendo vulnerabilidades de inyección de comandos y filtración de información sensible via HTTP. Si tienes DataStage en Cloud Pak for Data, asegúrate de estar en la versión 5.3.1 o posterior. No es un problema de la herramienta en sí — es mantenimiento normal de un producto enterprise — pero sí es un recordatorio de que los entornos on-premise necesitan gestión activa de parches.
El contexto competitivo
DataStage vs las alternativas en 2026
Sería deshonesto hablar de DataStage sin reconocer que el mercado de integración de datos en 2026 es muy diferente al de 2015. Hay alternativas serias, y la decisión depende mucho del contexto. Aquí va el mapa sin discurso comercial.
IBM DataStage Referencia
Licencia IBM
FuerteParalelo, IBM Power, regulación
DébilCoste, curva de aprendizaje
Informatica IDMC
SaaS / on-prem
FuerteCuota de mercado, conectores
DébilMás caro que DataStage
Apache Spark / dbt
Open source
FuerteCloud-native, flexibilidad
DébilNo es llave en mano
Talend (Qlik)
Comercial
FuerteFácil de usar, open core
DébilRoadmap incierto tras Qlik
Azure Data Factory
SaaS Azure
FuerteIntegración nativa Azure
DébilLock-in, limitado fuera Azure
AWS Glue
SaaS AWS
FuerteServerless, coste bajo
DébilLock-in, limitado fuera AWS
¿Cuándo tiene sentido DataStage? Cuando ya tienes inversión en el ecosistema IBM (Power, Db2, InfoSphere), cuando necesitas procesamiento paralelo on-premise con volúmenes que otros no manejan bien, cuando la regulación te exige trazabilidad de metadatos end-to-end, o cuando tu equipo ya sabe DataStage y el coste de reentrenamiento supera al de la licencia.
¿Cuándo no tiene sentido? Cuando tu stack es cloud-native puro (AWS/Azure/GCP sin IBM), cuando tus volúmenes son pequeños, cuando prefieres código sobre interfaz visual, o cuando el presupuesto no da para la licencia IBM y prefieres invertir en ingeniería con herramientas open source.
Formarse en DataStage
Formación oficial de IBM DataStage en España
Si DataStage es parte de tu stack actual o va a serlo, formarse bien es la diferencia entre un equipo que diseña jobs eficientes y uno que genera pipelines que tardan horas en ejecutarse y nadie sabe depurar. Los cursos oficiales de IBM cubren eso — no solo los menús y los botones, sino las mejores prácticas de diseño, particionado, debugging y puesta en producción.
KM204G — IBM InfoSphere DataStage Essentials (4 días). Fundamentos: arquitectura, diseño de jobs, stages de transformación, conectores, monitorización. Para desarrolladores ETL y administradores de proyectos que empiezan con DataStage.
KM520G — DataStage Engine Administration (1 día). Administración del motor paralelo: configuración de runtime, conectividad a bases de datos, gestión de proyectos, monitorización avanzada. Para administradores de sistemas que mantienen la infraestructura DataStage.
Los dos cursos se imparten con instructores acreditados por IBM, materiales oficiales y laboratorios prácticos. Modalidad presencial en España (Madrid, Barcelona, Sevilla, Valencia, Bilbao, Málaga), remota, o in-company adaptada a tu equipo. También disponible en inglés y francés para equipos internacionales.
Formación a medida
Si necesitas un curso adaptado — por ejemplo, centrado en migración de jobs clásicos a Cloud Pak for Data, o en optimización de rendimiento para un entorno concreto — lo diseñamos sobre los materiales oficiales con contenido adicional de nuestros propios despliegues. Consulta el catálogo completo de formación oficial IBM o escríbenos directamente por WhatsApp.
Formación oficial. En español. Con gente que lo despliega.
Ya sea que empieces con DataStage o quieras llevar a tu equipo al siguiente nivel, los cursos oficiales IBM impartidos por SIXE cubren desde los fundamentos hasta la administración avanzada del motor paralelo.
OpenStack Gazpacho: la release que acelera la salida de VMware y prepara tu nube privada para lo que viene.
El 1 de abril se publicó OpenStack 2026.1 Gazpacho. Más de 9.000 cambios, 500 colaboradores, migraciones en vivo paralelas, automatización de bare metal con Ironic y la eliminación progresiva de Eventlet. Es la release SLURP del año — y la más relevante para empresas que están evaluando su infraestructura de virtualización.
Abril 2026●14 min lectura
OpenStack acaba de publicar su versión número 33. En otros tiempos, la noticia habría pasado sin pena ni gloria fuera del círculo habitual de operadores de nubes privadas. Pero 2026 no es un año normal para la infraestructura. Broadcom lleva más de un año forzando el cambio de modelo de VMware. Las empresas europeas están midiendo el coste real de la dependencia tecnológica. Y el cloud privado open source ha dejado de ser una opción ideológica para convertirse en una opción económica.
Gazpacho llega en el momento exacto en que más organizaciones están buscando alternativas serias a vSphere. Y esta release, por primera vez en mucho tiempo, tiene respuestas concretas para las preguntas que se hacen esas organizaciones.
Para entender qué hay de nuevo, conviene empezar por algo que no es glamuroso pero que determina si puedes actualizar o no: el modelo de releases.
El modelo de releases
Qué es una release SLURP y por qué Gazpacho es la que importa
OpenStack publica dos versiones al año. Desde 2022, las releases alternas se marcan como SLURP (Skip Level Upgrade Release Process): permiten a los operadores actualizar una sola vez al año, saltando directamente de una SLURP a la siguiente sin pasar por la versión intermedia.
Esto es lo que hay encima de la mesa a fecha de este post:
Release
Fecha
Estado
2026.1 Gazpacho
1 abril 2026
Release actual. SLURP. Recomendada para nuevos despliegues y actualizaciones.
2025.2 Flamingo
1 octubre 2025
Soportada. No-SLURP (intermedia).
2025.1 Epoxy
Abril 2025
SLURP anterior. Actualización directa a Gazpacho posible.
La consecuencia práctica: si tu entorno ejecuta Epoxy (2025.1), puedes saltar directamente a Gazpacho sin tocar Flamingo. Eso reduce a la mitad las actualizaciones obligatorias y simplifica la planificación de ventanas de mantenimiento en producción.
Y si estás en Flamingo, el salto es de un solo paso — el estándar.
Dato de contexto
Gazpacho es la versión 33 de OpenStack. Unos 500 colaboradores de 100 organizaciones — Ericsson, Rackspace, Red Hat, Samsung SDS, SAP, NVIDIA, Walmart, entre otras — han aportado más de 9.000 cambios durante un ciclo de seis meses. El sistema de CI/CD (OpenDev Zuul) procesó más de un millón de jobs para validar esta release. Y un dato relevante para Europa: el 40% de las contribuciones provienen de desarrolladores europeos, impulsados por las iniciativas de soberanía digital del continente. Los detalles completos están en el blog oficial de la OpenInfra Foundation.
Con el calendario claro, veamos qué justifica actualizar — más allá de cerrar una ventana de soporte.
La novedad estrella
Migraciones en vivo paralelas en Nova: el cambio de juego
Si tuviéramos que elegir una sola novedad de Gazpacho para explicar por qué esta release importa a las empresas, sería esta: Nova ahora soporta migraciones en vivo paralelas.
Hasta ahora, la migración en vivo de instancias procesaba las transferencias de memoria de forma secuencial: una conexión tras otra. Gazpacho introduce múltiples conexiones simultáneas, lo que acelera significativamente el traslado de cargas de trabajo grandes entre hosts o zonas de disponibilidad.
¿Por qué importa tanto? Porque la velocidad de migración es, en la práctica, el factor que determina cuánto dura una ventana de mantenimiento. Para una empresa con cientos de máquinas virtuales — o que está evaluando mover cargas desde VMware — la diferencia entre migrar en serie y migrar en paralelo es la diferencia entre una noche de mantenimiento y un fin de semana entero.
Migración en vivo — tiempo de ventana↕ hover para detalle
t=0t=Tt=2Tt=3Tt=4T
Y eso no es todo lo que cambia en Nova
Las migraciones paralelas son la novedad más visible, pero Nova trae otros tres cambios que se acumulan sobre el mismo principio: menos fricción operativa.
Migración en vivo con vTPM
Otra novedad que acompaña a las migraciones paralelas: Nova permite ahora migrar instancias que utilizan vTPM (módulo de plataforma segura virtual) sin necesidad de apagarlas. Las cargas de trabajo con requisitos de cifrado de disco o arranque seguro — habituales en entornos regulados — ya pueden trasladarse entre nodos sin interrumpir el servicio. Hasta ahora, migrar una VM con vTPM requería apagar, mover, y volver a encender. Eso se ha acabado.
IOThread por defecto en QEMU
Un cambio más sutil pero con impacto real: Nova activa por defecto un IOThread por instancia de QEMU, descargando el procesamiento de E/S de disco de las vCPU. En entornos de alta densidad — muchas VMs por host — esto se traduce en un rendimiento de almacenamiento más consistente bajo carga, sin necesidad de tocar la configuración.
Cobertura completa de OpenAPI en Nova
Nova logra cobertura total de su esquema OpenAPI: cada endpoint del API tiene ahora una especificación legible por máquinas. Para equipos que automatizan con Terraform, Ansible o herramientas propias, esto significa validar peticiones antes de enviarlas al API y reducir errores en despliegues de infraestructura como código.
Bien. Nova controla las VMs. Pero las VMs tienen que vivir en algún sitio. Y si ese sitio es hardware físico que no ha pasado por OpenStack antes — que es exactamente la situación de la mayoría de migraciones desde VMware — entra en escena Ironic.
Bare metal inteligente
Ironic: automatización inteligente que reduce el trabajo manual
Ironic es el servicio de OpenStack para aprovisionar servidores físicos — bare metal — como si fueran máquinas virtuales. En Gazpacho, Ironic recibe un paquete de mejoras que, juntas, representan un salto en la operación del día a día:
Autodetect deploy interface. Ironic detecta automáticamente el método de despliegue adecuado para cada servidor, eliminando la selección manual. No suena espectacular, pero en un datacenter con hardware heterogéneo (distintas generaciones, distintos fabricantes) quita horas de configuración por nodo.
Detección automática de protocolo (NFS/CIFS) para Redfish. La configuración de arranque por virtual media se simplifica: Ironic determina el protocolo correcto sin intervención del operador.
Planificación de puertos basada en traits. La asignación de red se automatiza según los atributos reales de la infraestructura — tipo de NIC, velocidad, capacidades — en lugar de depender de mapeos manuales.
Interfaz de despliegue "noop". Quizá la más interesante para proyectos de migración: permite registrar y monitorizar servidores que ya están desplegados y funcionando sin necesidad de reaprovisionarlos. El caso de uso típico: incorporar hardware existente al inventario de OpenStack durante una migración gradual desde VMware o desde otra plataforma.
En la práctica
La interfaz noop es particularmente útil en los proyectos que hacemos en SIXE de migración desde vSphere. Permite registrar los hosts ESXi existentes en OpenStack, monitorizarlos, y planificar la migración de cargas sin necesidad de reinstalar el sistema operativo del host hasta que llega el momento. Es la diferencia entre "migrar todo de golpe un fin de semana" y "migrar por fases con control".
Guía de drivers en Cyborg
Cyborg, el servicio de aceleradores de OpenStack, publica por primera vez una guía de configuración de drivers que cubre todos los tipos soportados: FPGA, GPU, NIC, QAT, SSD y PCI passthrough. Para organizaciones que están incorporando aceleradores de IA o cargas HPC en su cloud privado, disponer de documentación unificada y probada reduce significativamente la barrera de entrada.
Tenemos las VMs migradas con Nova y el hardware registrado con Ironic. Ahora viene la parte que siempre acaba siendo más complicada de lo esperado: la red.
Redes, almacenamiento, seguridad
Lo que cambia por dentro: OVN, Manila, OpenBao
Redes: BGP nativo y mejoras OVN en Neutron
El controlador OVN de Neutron incorpora novedades que llevan tiempo pidiéndose en entornos enterprise:
Soporte BGP nativo para anunciar rutas directamente desde el controlador de red, sin necesidad de herramientas externas.
Enrutamiento Norte-Sur para puertos externos, simplificando la conectividad con redes físicas.
Pares de direcciones permitidos con MACs virtuales, facilitando escenarios multitenant y arquitecturas de conectividad híbrida.
Históricamente, estos eran escenarios donde OpenStack requería soluciones alternativas o herramientas de terceros. Gazpacho los resuelve de forma nativa.
Almacenamiento: QoS en Manila y adjuntos asíncronos
Manila introduce tipos y especificaciones de QoS que permiten aplicar políticas de rendimiento por carga de trabajo al almacenamiento compartido. Si tienes un pool de almacenamiento para bases de datos y otro para ficheros fríos, ahora puedes establecer límites y prioridades a nivel de la plataforma, no solo a nivel del hardware. Cinder avanza en los adjuntos asíncronos de volúmenes, mejorando la respuesta en entornos de alta densidad.
Seguridad: PKI con OpenBao
La integración con OpenBao — fork abierto de HashiCorp Vault — para la gestión de certificados PKI en OpenStack-Ansible permite alinear la infraestructura de certificados de OpenStack con las herramientas de seguridad empresarial existentes. Especialmente relevante en entornos regulados donde la gestión del ciclo de vida de los certificados está auditada y donde la administración ya utiliza Vault como estándar.
Watcher: estrategias de migración cross-zone
Watcher, el servicio de optimización de recursos, mejora sus estrategias de redistribución de cargas entre zonas con un testing reforzado. Para operadores que gestionan clouds multi-site o con zonas de disponibilidad diferenciadas, esto mejora la fiabilidad de las redistribuciones automáticas durante mantenimientos o ante fallos.
Todo lo anterior — migraciones, automatización, redes — son features visibles que puedes vender internamente. Pero hay un trabajo que Gazpacho hace en silencio, más importante a largo plazo que cualquier feature nueva: limpiar la casa por dentro.
Deuda técnica
Eventlet: el principio del fin de una dependencia heredada
Una de las historias de fondo más importantes de OpenStack en los últimos tres años es la eliminación progresiva de Eventlet, una biblioteca de concurrencia cooperativa que se adoptó en los primeros días del proyecto, cuando Python 2 no tenía una alternativa nativa. Python 3 sí la tiene: asyncio. Pero migrar un proyecto del tamaño de OpenStack de un modelo de concurrencia a otro es un trabajo monumental.
En Flamingo (2025.2), cuatro servicios completaron la migración: Ironic, Mistral, Barbican y Heat. En Gazpacho, Nova avanza significativamente hacia el threading nativo, con mejoras de rendimiento y estabilidad medibles. Neutron también progresa. Y nueve proyectos más están en proceso activo de migración.
¿Por qué importa esto a una empresa que no contribuye código a OpenStack? Porque Eventlet es una fuente conocida de bugs sutiles, dificultades de depuración e incompatibilidades con bibliotecas modernas de Python. Su eliminación hace OpenStack más estable, más mantenible y más predecible en producción a largo plazo. Es el tipo de mejora invisible que no aparece en demos pero que se nota en las 3 de la mañana cuando algo falla y hay que diagnosticarlo.
Progreso de migración de Eventlet
● Completado◐ En progreso○ Pendiente
0
Completados
0
En progreso
0
Pendientes
0%
Completado
Progreso global del proyectoObjetivo: asyncio nativo en todos los servicios
El contexto del mercado
Gazpacho como alternativa a VMware: por qué el timing importa
Volvemos al punto de partida del artículo. Dijimos que 2026 no es un año normal para la infraestructura — que Broadcom ha forzado a muchas organizaciones a replantearse su stack de virtualización. La pregunta que se hace ese tipo de organización no es "¿OpenStack es técnicamente capaz?". Eso quedó resuelto hace tiempo. La pregunta es: "¿tiene respuesta para mis problemas concretos?". Y con Gazpacho, la respuesta ha mejorado notablemente.
Desde que Broadcom reestructuró el modelo de licencias — subidas significativas, eliminación de licencias perpetuas, cambio a bundles — las preguntas de los clientes que nos llegan son siempre las mismas. Gazpacho tiene respuesta para cada una de ellas, y es una respuesta que conecta directamente con lo que acabamos de ver:
Preocupación habitual
Respuesta de Gazpacho
Velocidad de migración
Migraciones en vivo paralelas que rivalizan con vMotion. vTPM sin downtime.
Hardware existente
Ironic noop permite registrar hosts sin reprovisionar. Migración gradual.
Redes complejas
BGP nativo en OVN, enrutamiento N-S, MACs virtuales. Sin herramientas externas.
Aceleradores (GPU, FPGA)
Guía unificada de drivers Cyborg. PCI passthrough mejorado.
Actualizaciones predecibles
Modelo SLURP: una actualización mayor al año, ruta de upgrade probada.
A esto se suma que OpenStack supera los 55 millones de cores en producción a nivel mundial. No es un proyecto de nicho ni una promesa de futuro: es infraestructura que opera en producción en Walmart, CERN, NTT, Deutsche Telekom, y miles de organizaciones más pequeñas que no publican sus números. El proyecto lleva 15 años funcionando y la base de contribuidores está creciendo, no encogiéndose. La release anterior, Flamingo (2025.2), ya había avanzado significativamente en seguridad y en la eliminación de Eventlet.
El ángulo europeo
El 40% de las contribuciones a Gazpacho provienen de desarrolladores europeos. Esto no es casualidad: las iniciativas de soberanía digital de la UE están empujando la adopción de infraestructura abierta en administraciones públicas y empresas reguladas. Para organizaciones españolas que necesitan demostrar independencia tecnológica en sus pliegos o en sus auditorías, OpenStack es una de las pocas opciones que combina madurez técnica con gobernanza verdaderamente abierta.
Siguientes pasos
Cómo encaja esto en tu infraestructura
Modelo de releases, migraciones paralelas, bare metal inteligente, redes sin parches, deuda técnica en retirada, contexto de mercado favorable. Todo confluye en la misma pregunta práctica: ¿y tú, qué haces ahora? La respuesta depende de dónde estás.
Hay tres situaciones habituales, y el diagnóstico es distinto en cada una:
Tienes OpenStack en producción y necesitas planificar el salto a Gazpacho. Si estás en Epoxy, el upgrade directo SLURP-a-SLURP es tu ruta. Si estás en Flamingo, es un salto estándar. En ambos casos, la recomendación es validar en entorno de pruebas, especialmente si usas features que han cambiado entre versiones (migraciones, OVN, Ironic).
Tienes VMware y el coste de renovación te ha hecho mirar alternativas. Aquí la pregunta es de diseño: qué workloads se mueven primero, qué arquitectura OpenStack encaja (sobre qué hardware, con qué almacenamiento — Ceph es la opción natural), cómo se migran los datos sin parar el servicio.
Arrancas un proyecto nuevo — cloud privado, plataforma de datos, infraestructura de IA — y OpenStack es una de las opciones. Gazpacho es la versión correcta para empezar, con Ceph como almacenamiento y, si necesitas contenedores, Kubernetes integrado a través de Magnum.
En los tres casos, el orden sensato es el mismo: conversación técnica corta para entender el caso, propuesta de arquitectura con opciones y trade-offs claros, y laboratorio de validación antes de tocar producción. Lo que cambia con Gazpacho no es el proceso — es que hay más piezas maduras con las que trabajar.
Soporte urgente 24/7 — para entornos donde un problema a las 3 de la mañana es un problema de verdad
¿Evaluando OpenStack o planificando un upgrade?
Hablemos de tu infraestructura.
Nos cuentas dónde estás — upgrade pendiente, salida de VMware, proyecto nuevo — y salimos de la llamada con una idea clara de arquitectura, esfuerzo y siguientes pasos. Sin presupuestos genéricos. Directamente con ingenieros que llevan años con las manos dentro de proyectos como el tuyo.
Ceph Tentacle: el salto silencioso que coloca el almacenamiento open source por delante en 2026.
El 6 de abril salió Tentacle v20.2.1. Reef ha llegado al final de su vida. Viene Umbrella con CephFS reescrito por dentro. Y mientras tanto, el lakehouse on-prem de IBM watsonx.data lleva 768 TiB de Ceph dentro. Repasamos qué ha cambiado de verdad y qué implica si tienes o vas a tener almacenamiento distribuido en España.
Abril 2026●13 min lectura
Hay una conversación que se repite casi cada semana en SIXE desde el último trimestre de 2025. La llamada llega con dos variantes y un mismo tono de cansancio. La primera: "nos toca renovar VMware con Broadcom y lo que nos piden no tiene sentido, ¿Ceph podría cubrir esto?". La segunda: "tenemos un clúster de Ceph que lleva años rodando en Reef y no sabemos a qué upgrade tirarle sin romperlo".
Las dos preguntas se responden bien a día de hoy, pero por razones distintas — y más interesantes de lo que parece. Ceph ha tenido un año muy movido sin que casi nadie lo contase en español. Vamos al grano.
El contexto 2026
El mapa de releases: Tentacle arriba, Reef fuera, Umbrella en camino
Si tu última foto mental del calendario de Ceph es de 2024, está desactualizada. Esto es lo que hay encima de la mesa a fecha de publicación de este post:
Rama
Última versión
Estado
Tentacle (v20.x)
v20.2.1 · 6 abril 2026
Estable actual. Primera minor del ciclo. Recomendada para nuevos despliegues.
Squid (v19.x)
v19.2.3 · 26 septiembre 2024
Soportada. Elección conservadora sólida.
Reef (v18.x)
v18.2.8 · 20 marzo 2026
Fin de vida. Última backport release. Hay que migrar.
Umbrella (v21.x)
En desarrollo
Próxima major. Presentada en FOSDEM 2026 con foco en CephFS y DR.
La transición más importante aquí es la de Reef. El equipo de release anunció en marzo que v18.2.8 era la última — y previsiblemente la definitiva — backport release de la rama Reef. A partir de ahí, Reef entra en modo "si tienes un problema crítico, toca resolverlo actualizando". Si estás en Reef, ya no estás en una rama mantenida activamente. Hay que mover.
Tentacle, por su parte, es un salto mayor con calado real. Se publicó como versión estable inicial (v20.2.0) en noviembre de 2025, y la v20.2.1 del 6 de abril de 2026 corrige varios bugs significativos detectados en los primeros meses en producción — especialmente uno crítico en Erasure Coding que afectaba al scrub de pools con FastEC activado. Volvemos a ese punto en un momento.
Y luego está Umbrella, la próxima major. No hay fecha firme todavía, pero la presentación en FOSDEM 2026 ha dejado claro el enfoque: recorrer de arriba abajo la experiencia de CephFS, con mejoras en disaster recovery, métricas, tuning de MDS y protección de datos de usuario. Si tu caso de uso principal es fichero (HPC, media, home directories a escala), Umbrella es la versión que vas a querer mirar con calma.
Dato que merece la pena tener presente. La Ceph Foundation ha reorganizado su estrategia de eventos en 2026: en lugar de concentrar todo en un único Cephalocon anual, ahora hay Ceph Days regionales distribuidos por el mundo para bajar la barrera de entrada a la comunidad. El siguiente importante es Ceph Days Raleigh en junio, y hay actividad europea creciente. Para empresas españolas que quieran estar cerca de la toma de decisiones del proyecto, 2026 es un año más accesible que los anteriores.
La novedad con más impacto
FastEC: la mejora que cambia la ecuación de coste por TB
Si tuviéramos que elegir una sola novedad de Tentacle para explicar por qué esta release importa, sería FastEC. Es un cambio que se describe en una frase y cuya consecuencia tarda un rato en calar: la pipeline de I/O para Erasure Coding ha sido reescrita, con mejoras de rendimiento sustanciales y algunas mejoras de capacidad para pools EC. Se activa por pool mediante el flag allow_ec_optimizations. Los clientes no necesitan actualizarse.
¿Por qué esto importa tanto? Porque hasta ahora, en la mayoría de despliegues serios, la regla de oro era esta: replicado para lo que rinde (virtualización, bases de datos, CephFS con mucho metadata); Erasure Coding solo para lo que puede permitírselo (objeto frío, backups, archivado). La razón era puramente de rendimiento: EC tradicional tenía una penalización de escritura y una latencia que lo hacían poco adecuado para bloque o fichero con cargas mixtas. FastEC cambia esa regla. No del todo, no en todos los casos — pero sí lo suficiente como para que muchas cargas que antes solo tenían sentido en replicado de tres copias puedan moverse a EC con una relación de eficiencia mucho mejor.
Traducido a dinero, esto se parece bastante a esto:
────────────────────────────────────────────────100 TB útiles, clúster típico de virtualización
────────────────────────────────────────────────Replicado x3 (hasta ahora, lo "obligatorio")
→ 300 TB raw en cabinas · overhead 200%EC 4+2 con FastEC (ahora viable en más casos)
→ 150 TB raw · overhead 50% · ahorro ≈ 50%────────────────────────────────────────────────
El número exacto depende del perfil EC que uses (4+2, 6+3, 8+3...) y de la distribución física, pero el orden de magnitud es real. En un clúster de medio petabyte, estamos hablando del tipo de ahorro que justifica un proyecto entero.
Dos avisos importantes, porque no queremos que nadie se lleve sorpresas:
Aviso operativo
La primera Tentacle (v20.2.0) contenía un bug en FastEC que podía producir millones de errores de scrub al activar el flag sobre pools EC existentes. El informe público está documentado por Clyso. La v20.2.1 del 6 de abril corrige la raíz del problema (length calculation en erase_after_ro_offset y varios ajustes en BlueFS). Si vas a activar FastEC, hazlo desde v20.2.1 o posterior, no desde 20.2.0. Y, como siempre, prueba primero en laboratorio con datos no críticos.
El segundo aviso es más general. FastEC no es magia: sigue habiendo cargas para las que EC, incluso optimizado, no es la respuesta correcta — sobre todo IOPS muy altos con bloque pequeño y latencia muy ajustada (piensa en OLTP serio). La decisión de qué pools van en replicado y cuáles en EC sigue siendo una decisión de arquitectura, no de flag. Lo que ha cambiado no es que ahora todo vaya en EC; es que la conversación sobre "replicado vs EC" ya no está tan decantada hacia replicado como lo estaba hace dos años.
Qué más trae Tentacle
Más allá de FastEC: lo que cambia por dentro
FastEC se lleva los titulares, pero no es el único cambio de calado. Estas son las piezas que importan en operación del día a día:
BlueStore: compresión mejorada y un WAL nuevo
El almacén de objetos nativo de Ceph ha recibido dos cambios importantes. La compresión ha mejorado en eficiencia y velocidad, y hay un WAL (write-ahead log) nuevo y más rápido. El efecto práctico es menos latencia en escritura y menos amplificación sobre los dispositivos físicos — especialmente relevante en clusters de NVMe, donde las write amplification heredadas de generaciones anteriores se notaban.
Data Availability Score por pool
Un nuevo indicador por pool que permite ver "cómo de disponibles están de verdad los datos de este pool", teniendo en cuenta réplicas, EC, fallos históricos y recovery. Suena marketing, pero no lo es — para clusters con multi-tenant interno (por ejemplo, un pool para RGW S3 y otro para RBD con SLAs distintos), tener una métrica directa por pool en el dashboard quita trabajo manual de cálculo sobre OSDs y PGs.
Live migration de RBD entre clusters
Este es el cambio que más hemos visto pedir en proyectos de consolidación. Ahora se pueden importar imágenes RBD de otro cluster Ceph, en formato nativo, o desde una gran variedad de fuentes/formatos externos, de forma instantánea. Sin paradas, sin mover bytes antes de empezar a servir. El caso de uso típico: migración de clusters antiguos, consolidación de varios Ceph pequeños en uno grande, o import desde otro SDS o desde imágenes QCOW2. Para quien haya sufrido migraciones de RBD con rbd import en el pasado, esto es un cambio de juego.
CephFS: proxy propio para Samba y mejoras varias
Se despliega automáticamente un nuevo daemon cephfs-proxy que mejora escalabilidad y uso de memoria cuando Samba conecta con CephFS. Además, los directorios se pueden configurar con nombres case-insensitive o normalizados. Si has sufrido alguna vez montando SMB sobre CephFS en entornos mixtos Windows/Linux, esta es la parte que lleva tiempo pidiéndose.
NVMe/TCP para gateway groups y multi-namespace
Ceph lleva tiempo empujando NVMe-oF sobre TCP como puente hacia el almacenamiento de bloque tradicional. En Tentacle, los gateways NVMe/TCP soportan grupos y múltiples namespaces, gestión multi-cluster y OAuth 2.0. El escenario evidente es dar almacenamiento de bloque a hosts VMware o a otros hipervisores sin pasar por iSCSI y sin SAN propietaria. IBM ha sido muy explícito con esta visión y es una de las razones por las que Ceph está entrando en conversaciones donde antes solo se hablaba de vSAN.
SeaStore en tech preview (con Crimson OSD)
SeaStore — el almacén de objetos de próxima generación, diseñado para hardware NVMe moderno y con threading estructurado — es desplegable en preview junto a Crimson-OSD. Esto no es para producción todavía, pero sí es la primera vez que se puede probar end-to-end en un Tentacle estable. Para laboratorios y equipos que quieran familiarizarse con hacia dónde va Ceph en los próximos años, merece el rato.
Lo que se ha ido
Los módulos restful y zabbix, deprecados desde 2020, se han eliminado oficialmente. Si tu monitorización dependía del módulo Zabbix nativo, toca migrar a Prometheus + exporter de Ceph, que es la vía oficial desde hace tiempo.
El factor empresarial
El factor IBM, watsonx.data y la salida de Broadcom-VMware
La parte técnica de Ceph nunca ha sido el problema. Lo que impedía a muchas empresas españolas mirarlo en serio era el factor "esto es muy open source, no lo veo aprobado por comité". En 2026 ese argumento se ha caído solo, por dos vías independientes que se refuerzan.
IBM watsonx.data incluye 768 TiB de Ceph "de serie"
Desde hace un par de años, IBM ha hecho de Ceph el almacenamiento por defecto del lakehouse on-premise de watsonx.data. IBM Storage Ceph es un producto empresarial con precios publicados desde 0.026 USD/GB/mes, soporte 24/7, integración con Apache Iceberg, Apache Parquet, watsonx.ai, y el ecosistema Red Hat completo (OpenShift, OpenStack). La consecuencia práctica: cuando un CISO o un director de infraestructura pide "una opción soportada por un fabricante gran cuenta", Ceph ya no es "solo comunidad". Es un producto IBM con contrato, SLA y escalado de incidencias.
Broadcom-VMware ha empujado a medio sector a buscar alternativas
No hace falta que nos extendamos en esto. La subida de precios y el cambio de modelo de licenciamiento de VMware desde la compra por Broadcom ha abierto oficialmente la puerta a revisar las pilas de virtualización y almacenamiento. En esa revisión, el combo Proxmox + Ceph, o OpenStack + Ceph, o OpenShift/Kubernetes + Rook-Ceph, está entrando en bastantes shortlists que hace dos años no se planteaban.
Ceph, por diseño, encaja bien en esa conversación porque cubre los tres tipos de almacenamiento en una sola plataforma — bloque para VM y contenedores, fichero para datos compartidos, objeto S3 compatible para backups y datos no estructurados. Eso lo diferencia del resto del catálogo SDS open source: MinIO hace muy bien objeto, pero no bloque ni fichero; Longhorn es bloque para Kubernetes pero no objeto. Ceph hace los tres con el mismo cluster, y eso en proyectos reales ahorra cabinas, ahorra licencias y ahorra pliegos.
Nuestra perspectiva en SIXE
Llevamos años desplegando Ceph en proyectos donde el cliente no quería depender de un único fabricante y necesitaba cubrir bloque, fichero y objeto con una misma arquitectura. En 2025-2026 hemos visto cómo el perfil de los clientes ha cambiado: ya no son solo los "pioneros del open source", son también organizaciones medianas con cabinas tradicionales que están calculando su próximo ciclo de refresh. Si tu caso se parece a alguno de esos, la página de migración a Ceph sin downtime cuenta cómo abordamos la parte complicada: mover datos sin parar el servicio.
El ecosistema
Proxmox, Rook y el empuje del ecosistema
Ceph no existe solo. En 2026, tres ecosistemas están tirando del carro y vale la pena mirarlos por separado porque cada uno aporta un ángulo distinto.
Proxmox VE: Ceph integrado y ahora Tentacle en preview
Proxmox lleva años integrando Ceph de forma nativa como almacenamiento del cluster de virtualización. En enero de 2026 Proxmox publicó Ceph 20.2 Tentacle como test preview, con plan de mover a no-subscription una vez estabilice. Para entornos que ya están en Proxmox, esto significa acceso a FastEC, live migration RBD y NVMe/TCP sin cambiar nada más del stack. Proxmox sigue en Squid como default estable y lo mantendrá hasta septiembre de 2026, así que hay margen para planificar.
Rook y el mundo Kubernetes
Rook, el operator oficial de Ceph en Kubernetes, ha recibido actualizaciones importantes. Ceph-CSI v3.16 ya recomienda Ceph-CSI-Operator como mecanismo de despliegue estándar, e introduce driver NVMe-oF CSI para acceder al almacenamiento por NVMe over Fabrics desde Kubernetes. Para equipos que están construyendo plataformas internas tipo IDP sobre Kubernetes, esto abre posibilidades de rendimiento que antes requerían compromisos.
OpenStack y el campo empresarial
En OpenStack, Ceph sigue siendo el almacenamiento de referencia para Cinder (bloque), Glance (imágenes) y Swift-replacement con RGW (objeto). El trabajo de IBM/Red Hat sobre OpenStack y Ceph es continuo, y para organizaciones con necesidades de cloud privado a escala es, probablemente, la combinación más madura del mercado libre.
¿Qué significa todo esto junto? Que Ceph no depende de un único camino de adopción. Hay tres puertas de entrada naturales — virtualización (Proxmox), contenedores (Rook/OpenShift) y nube privada (OpenStack) — y las tres están activamente mantenidas por equipos grandes. Esa diversidad es, probablemente, la razón estructural por la que Ceph es la pieza de SDS open source más difícil de matar.
La parte operativa
Cuándo actualizar y cómo hacerlo sin estropear nada
Esta es la parte práctica. Tenemos cuatro escenarios típicos y una respuesta razonable para cada uno:
Clúster nuevo desde cero (proyecto greenfield). Directamente Tentacle v20.2.1 o posterior. Con ISA-L como plugin EC por defecto (cambio de Jerasure a ISA-L en pools nuevos), FastEC disponible desde el primer día, y sin deuda técnica heredada. Es el escenario más limpio.
Clúster en producción en Squid (v19.x). Sin urgencia. Squid sigue soportada y funcionando bien. La decisión depende de qué features de Tentacle te aportan valor: si necesitas FastEC, live migration RBD, o NVMe/TCP avanzado, planifica el upgrade para Q3 2026 esperando a v20.2.2 o posterior. Si no las necesitas, puedes esperar con tranquilidad a mitad de vida de Tentacle.
Clúster en producción en Reef (v18.x). Hay que migrar. Reef está en fin de vida tras v18.2.8. La ruta oficial recomendada es Reef → Squid → Tentacle, no Reef → Tentacle directamente — y especialmente no desde Pacific, porque QA ha detectado problemas con upgrades directos desde Pacific. Haz el salto en dos pasos y con ventanas de mantenimiento bien planificadas.
Clúster en Pacific, Quincy o anterior. Esto ya no es "mantenimiento", es deuda técnica activa. Pacific está fuera de soporte, Quincy está en sus últimas backport releases. Si sigues en alguna de esas ramas, es el momento de plantear un proyecto formal de modernización — no solo actualización, porque probablemente haya piezas de arquitectura (cephadm, containerización de daemons, dashboard) que también convenga repensar.
Tres principios de migración que no negociamos
En SIXE, cuando hacemos una migración o una actualización seria de Ceph para un cliente, trabajamos siempre con tres reglas. Las ponemos aquí porque funcionan también si lo gestionas tú mismo:
Laboratorio antes que producción. El flag allow_ec_optimizations, la activación de FastEC, el cambio de versión mayor — todo eso se valida primero en un clúster de pruebas con datos no críticos, incluso si es un clúster pequeño. El coste de mantener un laboratorio durante dos semanas es una fracción ínfima del coste de un incidente en producción.
Nunca saltar etapas. La escalera oficial Reef → Squid → Tentacle existe por buenas razones. Saltarse pasos ahorra dos semanas de proyecto y cuesta dos meses de depurar cosas raras. Respetamos la escalera y documentamos cada paso.
Ventana de rollback viable hasta el último momento. No se borran snapshots del filesystem, no se desactivan backups antiguos, no se retiran nodos viejos hasta que el clúster nuevo lleva funcionando un ciclo de scrub completo con cargas reales encima. Es más tedioso, sí. Y funciona.
Siguientes pasos
Cómo encaja todo esto en un proyecto real
Si has leído hasta aquí, probablemente tu caso se parece a alguno de estos tres:
Tienes Ceph en producción y necesitas planificar el salto a Tentacle o decidir si FastEC te aplica. Aquí el trabajo es de arquitectura: revisar perfiles EC actuales, dimensionar el cambio, planificar la ventana de upgrade, validar en laboratorio.
Tienes VMware con vSAN y el coste de renovación te ha hecho mirar alternativas. Aquí la pregunta es de diseño: qué workloads se mueven primero, qué arquitectura Ceph encaja (Proxmox? OpenStack? Rook?), cómo se migran los datos sin parar el servicio.
Arrancas un proyecto nuevo — lakehouse, plataforma de contenedores, cloud privado — y Ceph es una de las opciones sobre la mesa. Aquí conviene diseñar desde el principio con Tentacle, dimensionar bien la red (spoiler: la red es casi siempre el cuello de botella, no los discos), y elegir la puerta de entrada (k8s vs virtualización vs bare metal).
En los tres casos, el orden sensato es el mismo: conversación técnica corta para entender el caso, propuesta de arquitectura con opciones y trade-offs claros, laboratorio de validación, y proyecto de despliegue con ventanas planificadas. No hay atajos que funcionen bien a medio plazo.
Para seguir leyendo sobre Ceph en SIXE
Migración a Ceph sin downtime — cómo abordamos migraciones desde cabinas propietarias, vSAN o clústeres Ceph antiguos
Nos cuentas dónde estás — clúster existente, proyecto nuevo, salida de VMware, consolidación — y salimos de la llamada con una idea clara de arquitectura, esfuerzo y siguientes pasos. Sin presupuestos genéricos. Directamente con ingenieros que llevan años con las manos dentro de proyectos como el tuyo.
Qué es Wazuh y por qué es la alternativa real a Splunk y QRadar en 2026.
En dos años Cisco compró Splunk por 28.000 millones y Palo Alto Networks compró los activos SaaS de QRadar. Mientras tanto, Wazuh seguía publicando releases, lanzaba threat hunting con LLM local y pasaba los 10 millones de descargas anuales. Te contamos por qué eso cambia la conversación sobre SIEM en 2026.
Abril 2026●11 min lectura
Hay una conversación que llevamos teniendo varias veces al mes en SIXE desde finales de 2024. Llega un director de sistemas o un CISO, normalmente con algo de cansancio en la voz, y nos dice alguna versión de lo mismo: "se nos acaba el contrato de Splunk y el presupuesto del año que viene no lo aguanta", o bien "tenemos QRadar SaaS y IBM nos ha dicho que toca migrar a Cortex XSIAM, pero no sabemos si es lo que queremos".
No es casualidad. El mercado del SIEM comercial ha cambiado en 24 meses más de lo que había cambiado en la década anterior. Y en medio de todo ese movimiento, hay una pieza que sigue donde estaba, que no cotiza en bolsa, que nadie ha comprado, y que mientras tanto no ha parado de crecer. Se llama Wazuh.
El contexto 2024-2026
El mapa del SIEM que cambió en 24 meses
Si llevas años en seguridad defensiva, sabes que el mercado del SIEM comercial siempre ha sido conservador. Los grandes actores cambiaban poco. Los clientes aguantaban contratos dolorosos porque migrar un SIEM es un proyecto serio, y nadie lo hace por gusto. Y entonces, entre la primavera de 2024 y el verano de 2025, pasaron tres cosas que rompieron ese equilibrio.
Marzo 2024 — Cisco compra Splunk por 28.000 millones
El movimiento más caro en la historia del SIEM. Cisco pagó 157 dólares por acción, muy por encima del precio al que había cotizado Splunk ese año. Antes de cerrar la operación, Splunk despidió al 7 % de su plantilla —unas 560 personas— en una reestructuración global. Las encuestas de analistas justo antes de la adquisición ya apuntaban a que el 22 % de los clientes contemplaba cambiarse de proveedor si había subidas de precio tras la compra. Los que hemos visto de cerca este tipo de operaciones sabemos lo que viene después: presión interna por rentabilizar un precio alto, cambios de roadmap y renovaciones cada vez más tensas.
Mayo-septiembre 2024 — Palo Alto Networks compra los activos SaaS de QRadar
Esta fue la que nadie vio venir. En mayo de 2024, IBM y Palo Alto Networks anunciaron que Palo Alto compraba los activos SaaS de QRadar por unos 500 millones de dólares, con cierre confirmado en septiembre. Forrester lo resumió en una frase que los clientes aún están digiriendo: en cuanto venzan los contratos, los clientes de QRadar SaaS tienen que migrar a Cortex XSIAM o marcharse a otro proveedor. No es una opinión, es el plan oficial de la transición.
IBM mantiene el soporte de QRadar on-premise —bug fixes, actualizaciones críticas, conectores nuevos—, así que los clientes que tengan instalaciones propias no se quedan tirados de un día para otro. Pero el mensaje de fondo que están leyendo los comités de seguridad es claro: la inversión fuerte ya no va hacia QRadar, va hacia XSIAM y Precision AI. Muchos están usando esa señal para replantearse toda su estrategia de SOC a medio plazo.
Mientras tanto — Wazuh pasa los 10 millones de descargas anuales
No salió en titulares, porque Wazuh no tiene gabinete de comunicación a la altura de Cisco o Palo Alto. Pero las cifras están ahí. Según los datos que ellos mismos publican, el proyecto supera los 10 millones de descargas anuales, tiene una de las mayores comunidades de seguridad open source del mundo, y en junio de 2025 lanzó una función que ninguno de sus competidores comerciales tiene todavía sin pagar aparte: threat hunting con un modelo de lenguaje grande ejecutándose en local. Volvemos a eso más adelante.
Un apunte importante sobre QRadar. En SIXE seguimos dando soporte y formación oficial de IBM QRadar, y lo vamos a seguir haciendo mientras haya clientes con despliegues activos. QRadar on-prem sigue siendo una herramienta sólida para quien ya lo tiene montado y quiere exprimirlo. Pero si estás arrancando un proyecto SIEM nuevo en 2026, o tienes QRadar SaaS y el contrato se acaba, la conversación que tiene sentido ahora mismo es diferente. Y pasa por Wazuh bastante más a menudo de lo que pasaba hace dos años.
El producto
Qué es Wazuh (más allá del "es gratis")
Si Wazuh fuera solo un recolector de logs barato, esta conversación sería otra. No lo es. Wazuh es una plataforma que unifica, en un mismo agente y en un mismo stack, un montón de funciones que el resto del mercado vende en cajas separadas: SIEM, XDR, detección en endpoint, integridad de ficheros, escaneo de vulnerabilidades CVE, auditoría de configuración contra CIS, cumplimiento regulatorio y respuesta activa. Todo con el mismo agente corriendo en Linux, Windows, macOS, contenedores o máquinas virtuales.
Esto es lo que pasa, en la práctica, cuando un agente de Wazuh se instala en un servidor tuyo:
Recoge y correlaciona logs en tiempo real. Syslog, auditd, Windows Event Log, aplicación — todo con decoders nativos. Lo manda cifrado al manager central, donde se evalúan reglas, se correlaciona entre hosts y se dispara alerta si procede.
Vigila la integridad de ficheros y configuración. Cualquier cambio en /etc, en el registro de Windows, en binarios de sistema o en ficheros que tú marques como sensibles, dispara una alerta inmediata. Esto es detección de manipulación, y es una de las cosas que antes se compraban aparte.
Escanea vulnerabilidades contra bases CVE actualizadas. Wazuh cruza el inventario de paquetes instalados con los feeds oficiales de vendors y bases CVE, y te dice qué máquinas necesitan parche con qué prioridad. Sin pagar Tenable ni Qualys encima.
Audita la configuración contra CIS Benchmarks. Cada agente corre evaluaciones periódicas de hardening contra políticas CIS o políticas internas tuyas, y genera el informe de cumplimiento listo para presentar a auditor.
Responde activamente. Bloqueo automático de IP, kill de procesos sospechosos, aislamiento del host, ejecución de scripts custom. Sin que nadie toque el teclado a las tres de la mañana.
Mapea todo a MITRE ATT&CK. Cada regla disparada se etiqueta con la técnica y táctica ATT&CK correspondiente, lo que hace que los dashboards para el SOC analyst sean mucho más útiles de lo que suelen ser los paneles genéricos.
El stack es sólido y está probado en producción. Un paper académico publicado por Springer en abril de 2026 evalúa arquitecturas Wazuh distribuidas con alta disponibilidad y gestión de picos de ingesta muy por encima del EPS medio, y concluye —con las palabras cuidadas habituales del mundo académico— que las soluciones SIEM open source bien diseñadas pueden igualar y en algunos aspectos superar a las plataformas comerciales. Dicho en cristiano: cuando alguien que no vende Wazuh evalúa Wazuh con método, los resultados son buenos.
La novedad del año
El as en la manga: threat hunting con LLM local
En junio de 2025, casi sin ruido, Wazuh incorporó una capacidad que cambia la forma de trabajar de un analista de SOC: threat hunting asistido por un modelo de lenguaje grande ejecutándose en local. No en la nube de OpenAI. Local. En tu propia infraestructura.
¿Por qué es relevante? Porque todos los "SIEM con IA" que ha lanzado el mercado comercial —Cortex XSIAM con Precision AI, Splunk con su propia suite, las novedades de QRadar antes de la venta— funcionan enviando tus logs a los modelos del fabricante. En muchos casos eso mismo es lo que el cliente no puede hacer por razones regulatorias. Si tus logs contienen datos de pacientes, de clientes bancarios, o información clasificada de una administración pública, mandarlos a un LLM en la nube de un proveedor externo no es negociable — simplemente no puedes.
La solución de Wazuh se salta ese problema. Tú eliges el modelo, tú lo despliegas donde quieras, tus datos no salen. Y las consultas son las que un analista haría en lenguaje natural: "enséñame todos los intentos de escalada de privilegios del último mes correlacionados con cuentas de servicio", "resume los eventos de este host en las últimas 24 horas, prioriza lo anómalo", "¿hay algo en estos logs que se parezca a la TTP T1078 de MITRE?".
Nuestra perspectiva en SIXE
Esta es exactamente la línea en la que llevamos tiempo trabajando desde el lado de infraestructura — LLMs corriendo on-premise, sin mandar nada a ninguna nube, para entornos que manejan datos sensibles. Lo hemos aplicado en IBM Power, en AIX, y en clusters Ceph+Kubernetes para inferencia privada. Cuando vimos que Wazuh iba por ese mismo camino desde el lado del SOC, fue uno de los factores que nos hicieron apostar más fuerte todavía por la plataforma. Si te interesa el lado "infraestructura" de la historia, lo contamos en detalle en nuestra página de inferencia de IA on-premise.
La comparativa
Wazuh vs Splunk vs QRadar vs XSIAM, estado 2026
Sin discursos de marketing, aquí está el estado actual de los cuatro actores que se cruzan en la mayoría de conversaciones que tenemos. Las cifras y estados son verificables a la fecha de publicación de este post.
Plataforma
Estado 2026
Modelo comercial
Wazuh
Independiente. Sin adquisiciones, sin rondas de funding, creciendo en descargas y comunidad.
Open source AGPLv3. Sin coste de licencia. Wazuh Cloud opcional.
Splunk
Propiedad de Cisco desde marzo 2024. Reducción de plantilla del 7 % pre-cierre. Integración en curso.
Por volumen de datos ingeridos (GB/día). Coste alto, presión de renovaciones.
QRadar SaaS
Vendido a Palo Alto Networks en 2024. Migración obligatoria a Cortex XSIAM cuando venzan los contratos.
El destino es Cortex XSIAM. Migración gratuita para "clientes elegibles".
QRadar on-prem
Mantenido por IBM. Bug fixes, conectores, sin grandes novedades funcionales.
Licencia IBM por EPS. Soporte oficial activo.
Cortex XSIAM
Producto estratégico de Palo Alto Networks. IA integrada (Precision AI).
Por capacidad y features. Posiciona arriba en precio.
ELK / OpenSearch puro
Gratis pero te lo construyes tú: reglas, decoders, FIM, compliance.
Gratis la base. El coste real es en tiempo de ingeniería propia.
La parte interesante de esta tabla no está en ninguna columna — está en lo que implica leerla entera. Cuatro de los seis actores comerciales están en transición, en mantenimiento o en migración obligatoria. Wazuh y ELK son los únicos que siguen exactamente donde estaban hace tres años, con sus comunidades intactas y su roadmap público. De esos dos, solo uno viene con SIEM, XDR, FIM, vulnerability scan, active response y compliance de serie: Wazuh.
Una nota sobre coste. Cuando comparamos Wazuh con Splunk en sesiones técnicas con clientes, la discusión casi nunca acaba siendo sobre el coste de la licencia — que, sí, es mucho más barato. Suele acabar siendo sobre la predictibilidad. Splunk sube contigo: más datos que ingieres, más pagas. Wazuh no. Y en un entorno donde los logs crecen un 30-40 % al año —porque metes nuevos servicios, porque NIS2 te obliga a retener más, porque montas más contenedores— esa diferencia se traduce en una factura que los CFO saben leer muy bien.
El ángulo regulatorio
Compliance sin sufrir: NIS2, ENS, PCI DSS, ISO 27001
Hay una razón muy práctica por la que Wazuh está creciendo más en Europa que en ningún otro sitio, y es la presión regulatoria. España traspuso NIS2 a finales de 2025 y está exigiendo evidencia real. El Esquema Nacional de Seguridad lleva años pidiendo trazabilidad, detección y respuesta ante incidentes. Para muchas organizaciones medianas —ayuntamientos, universidades, operadoras de servicios esenciales, hospitales concertados— la pregunta no es si necesitan un SIEM, sino cuál pueden permitirse sin que el comité de dirección les mire mal.
Wazuh trae los dashboards y reportes mapeados a los marcos regulatorios importantes directamente de serie:
NIS2. Controles de detección, trazabilidad de incidentes, reporte de eventos a la autoridad competente, evidencia de medidas de gestión de riesgos.
ENS (Esquema Nacional de Seguridad). Mapeo a las medidas de operación, monitorización y gestión de incidentes. Dashboards listos para los auditores que aplican el ENS en cualquiera de sus categorías.
PCI DSS. Controles de logging, integridad de ficheros, gestión de vulnerabilidades, retención — la checklist que exige el estándar, mapeada requisito a requisito.
ISO/IEC 27001. Evidencia de los controles del Anexo A relacionados con operaciones, comunicaciones, cumplimiento y gestión de incidentes de seguridad.
CIS Benchmarks. Auditoría continua de hardening del sistema operativo y de los servicios, con reporte histórico de desviaciones.
Dicho esto — y lo decimos con cariño porque venimos de este mundo — los dashboards por sí solos no aprueban una auditoría. Lo que los aprueba es que alguien haya diseñado la arquitectura bien, que las reglas estén afinadas al contexto del cliente, que las excepciones estén documentadas, que el flujo de evidencias llegue ordenado a quien lo tiene que firmar. Esa parte no la hace el producto, la hace el equipo que lo despliega. Y esa parte es, probablemente, el 70 % del valor de un proyecto Wazuh bien hecho.
Lo que hacemos en SIXE
Llevamos años desplegando Wazuh en organizaciones sujetas a ENS alto, a la transposición española de NIS2, a PCI DSS y a entornos sectoriales regulados. La página completa del servicio, con la arquitectura, el ciclo de despliegue y los casos de uso, está aquí: Implantación y soporte de Wazuh. Si el compliance es lo que más te presiona ahora mismo, esa es la conversación por la que empezar.
La migración
Cómo se migra desde Splunk, QRadar o ELK sin parar el SOC
Migrar un SIEM es un proyecto que asusta, y con razón. Un SIEM mal migrado deja ciegos los controles de detección justo en el peor momento posible. Por eso la forma en la que lo hacemos tiene que ser aburrida y predecible, con tres principios que no negociamos:
Nunca apagar el SIEM antiguo antes de tener el nuevo funcionando. El viejo sigue tragando logs y generando alertas mientras Wazuh empieza a correr en paralelo. Durante unas semanas tienes cobertura doble y cero riesgo. Ese periodo es caro en recursos, sí, pero mucho más barato que un mes de SOC a ciegas.
Convertir las reglas críticas antes de convertir el catálogo entero. Los SIEM grandes suelen tener miles de reglas acumuladas, y una parte importante son reglas que nadie mira o que disparan falsos positivos. La primera pasada identifica las 50-150 reglas críticas que realmente producen detecciones útiles, se reescriben al formato de Wazuh y se validan con eventos reales. El resto llega después, o no llega — porque muchas veces no merece la pena.
Validar con eventos que duelen, no con tests sintéticos. Antes de considerar Wazuh operativo, reproducimos un conjunto de escenarios reales —intento de escalada, exfiltración, ransomware temprano, compromiso de cuenta— y comprobamos que las alertas se disparan, se correlacionan y llegan al SOC con el contexto correcto. Si no se disparan, no se considera que esté operativo. Es así de simple.
La parte que cambia según de dónde vengas es el trabajo de conversión:
Desde Splunk. El trabajo más interesante. Las SPL (Search Processing Language) no se traducen automáticamente a las reglas de Wazuh, pero el patrón de detección suele ser reproducible con decoders custom y reglas sobre OpenSearch. Hemos hecho varias migraciones y el grueso del trabajo está en los dashboards y las reglas, no en la ingesta.
Desde QRadar. La parte buena es que QRadar y Wazuh comparten mucha filosofía en cuanto a eventos y offenses. La mala es que las DSM de QRadar son propietarias y hay que reconstruir los parsers. Si vienes de QRadar SaaS con la migración a XSIAM encima, esta es una ventana razonable para plantearse la tercera opción.
Desde ELK puro. La más sencilla de las tres — Wazuh ya usa OpenSearch como indexer, así que buena parte del stack de datos ya lo conoces. El salto está en añadir reglas, compliance y active response, que en ELK puro habrías tenido que construir a mano.
Siguientes pasos
Por dónde empezar
Si lees esto y te encuentras pensando "esto me aplica más de lo que me gustaría", probablemente tengas razón. No hace falta un proyecto enorme para dar el primer paso. Lo habitual es empezar por una conversación corta con tres preguntas:
¿Dónde estás exactamente ahora mismo? ¿Tienes Splunk con el contrato por venir? ¿QRadar SaaS con la migración a XSIAM en el horizonte? ¿Nada y te empieza a apretar NIS2 o el ENS?
¿Qué normativa te está obligando? NIS2, ENS, PCI DSS, ISO 27001 — no es lo mismo cumplir uno que cumplir los cuatro, y la arquitectura de Wazuh se dimensiona distinto según cuáles apliquen de verdad.
¿Cuántos endpoints, qué sistemas operativos, qué logs ya tienes, qué integraciones necesitas? Con esos datos ya se puede dibujar un diseño concreto y una estimación de esfuerzo realista.
Cuando tengas claro lo que quieres mirar, la página completa con la arquitectura, los módulos, la comparativa con alternativas comerciales y el ciclo de despliegue está aquí: Wazuh — Implantación y soporte SIXE. Y si quieres hablar con alguien que lleve años con las manos dentro de proyectos como el tuyo, la sesión técnica de 30 minutos es gratuita y sin compromiso. Salimos con un esbozo de arquitectura y una idea real de esfuerzo. Si Wazuh encaja, te lo decimos. Si no, también.
IBM QRadar — si tu caso pasa por mantener QRadar on-prem vivo, también damos soporte y formación oficial
Cursos oficiales de QRadar — para equipos que quieren formar analistas mientras planifican la transición a Wazuh u otra plataforma
¿Estás replanteándote tu SIEM?
Sesión técnica de 30 minutos. Sin compromiso.
Nos cuentas dónde estás, qué normativa te aplica y qué te preocupa. Salimos de la llamada con un esbozo de arquitectura, una estimación de esfuerzo y los siguientes pasos. Sin presupuestos genéricos, sin discurso comercial — directamente con alguien del equipo técnico.
Bacula: el backup que sobrevive al ransomware. Sin cobrarte por TB.
Lo primero que hace hoy un ataque de ransomware serio es reventarte el backup. Lo segundo, cifrarte todo lo demás. Te contamos qué es esto del "backup inmutable" del que todo el mundo habla, por qué Bacula lo hace bien, y por qué sale bastante más barato que Veeam.
Abril 2026●9 min lectura
Durante muchos años, el backup ha sido el patito feo del datacenter. Esa cosa aburrida que el admin dejaba configurada un viernes por la tarde, que corría de noche, y que nadie volvía a mirar hasta que ardía Troya. En 2026 la cosa ha cambiado bastante: el servidor de backup es lo primero que busca un atacante cuando entra en tu red. Y tiene toda la lógica del mundo — si te borra las copias antes de cifrar el resto, no tienes plan B. Pagas el rescate o aceptas la pérdida.
Mientras pasa todo esto, Veeam, Veritas y Commvault siguen facturando por terabyte protegido, como si estuviéramos en 2015. Por suerte hay alternativas. Y una que merece mucho la pena mirar se llama Bacula.
El contexto 2026
Por qué tu backup es lo primero que va a tocar un atacante
En marzo, Bacula Systems publicó un artículo con un título que lo deja todo dicho: la infraestructura de backup vale más para un atacante que una cuenta de administrador de dominio. Y no es un titular para vender; es lo que están viendo los equipos de respuesta a incidentes desde hace un par de años.
Si hablas con cualquiera que haya pasado por una recuperación de ransomware "de las feas", el patrón se repite una y otra vez:
Día 1-3 Compromiso inicial(phishing, VPN vieja, CVE sin parchear)Día 4-10 Movimiento lateral + escalada de privilegiosDía 11-14 Buscan el servidor de backup y se hacen root en élDía 15 Borrado de catálogos y credenciales de repositoriosDía 16 Cifrado masivo del resto de la infraestructuraDía 17 Nota de rescate en el escritorio del CEO
Fíjate en lo que pasa entre el día 11 y el 15. El atacante dedica días enteros a neutralizar tu backup antes de pulsar el botón del cifrado. Porque sabe algo que nosotros a veces olvidamos: si el backup sobrevive intacto, él pierde la partida. Por eso la pregunta correcta de 2026 ya no es "¿tenemos backups?" — esa la tenemos resuelta desde hace 20 años. La pregunta incómoda, la que duele, es: ¿esos backups se pueden destruir desde dentro de mi propia red?
Si la respuesta honesta es "sí, probablemente", no estás solo. La mayoría de entornos que auditamos parten de ahí.
El dato que pone los pelos de punta: en los informes de resiliencia de 2025, más de un tercio de las organizaciones atacadas descubrieron que sus copias también habían caído. Tuvieron que elegir entre pagar o perder los datos. Y en casi todos esos casos, el backup estaba "funcionando perfectamente" el día anterior al ataque. Porque sí funcionaba. Solo que ya estaba comprometido.
La definición sin paja
"Backup inmutable" sin marketing de por medio
Hay un problema con el término "backup inmutable": se ha convertido en la palabra favorita del departamento de marketing de cualquier fabricante. Todos lo usan, todos lo prometen, y significa cosas distintas según quién lo diga.
Vamos a la definición que cuenta, la técnica: un backup es realmente inmutable cuando, una vez escrito, nadie puede modificarlo ni borrarlo hasta que expire su retención. Ni tú. Ni el admin con el password maestro. Ni un atacante que se ha hecho root en el servidor de backup. Nadie. Y eso se consigue de tres formas — las tres sólidas, las tres soportadas por Bacula desde el primer día:
Mecanismo
Cómo funciona
Cuándo lo usas
WORM en cinta LTO
Cartuchos marcados Write-Once-Read-Many. El firmware del drive físicamente se niega a sobrescribirlos.
Cuando quieres air-gap de verdad. La cinta sale de la librería, va a la caja fuerte, y desde ahí ningún atacante llega.
Object Lock en S3 o Ceph
Los objetos se escriben con una retención bloqueada a nivel de API. Ni el dueño del bucket los puede borrar.
Cuando quieres inmutabilidad en almacenamiento de objetos. Funciona con MinIO, Ceph RGW, AWS S3 y Azure Blob.
ZFS o Btrfs append-only
Snapshots que el propio proceso de backup no puede tocar después de crearlos.
Como primera línea para entornos pequeños, o como capa rápida antes de bajar a cinta o S3.
Si nunca habías oído el concepto 3-2-1-1-0, apuntatelo porque lo vas a ver mucho en los próximos meses. Es la evolución del clásico 3-2-1 de toda la vida: tres copias, en dos medios distintos, una offsite… una inmutable, y cero errores de verificación. Ese "1-0" del final es lo nuevo. Ya no vale con tener copias — tienen que ser imposibles de alterar, y alguien tiene que estar verificándolas sin que hagas nada. Bacula hace las dos cosas automáticamente, como parte de su rutina normal.
Por qué la cinta está volviendo
Mucha gente piensa que la cinta es tecnología del siglo pasado. Pues LTO-10 llegó en enero con 30/40 TB nativos por cartucho y 400 MBps de velocidad, y el mismo air-gap físico que tenía LTO-1 hace 25 años. Es literalmente la única tecnología de backup donde, aunque el atacante tenga root en tu servidor Bacula, no puede borrar el dato — porque el dato no está enchufado a ninguna red. En SIXE estamos viendo cómo los despliegues con tape library vuelven a crecer desde 2024, y no es casualidad.
Una librería LTO moderna — el único medio donde el ransomware no llega.
Por qué Bacula
Qué tiene Bacula que otros no
Bacula lleva en producción más de 20 años. No es un proyecto nuevo ni una promesa; está corriendo ahora mismo en bancos, en ministerios, en hospitales, en operadoras de telecomunicaciones y en laboratorios científicos que manejan petabytes. Su edición comercial, Bacula Enterprise 18.0.8, acaba de sumar funciones específicas anti-ransomware: BGuardian (que detecta cuando alguien intenta envenenar el catálogo), un BWeb Security Center para tener todo a la vista, y soporte nativo para Microsoft 365, Nutanix AHV y snapshots CSI de Kubernetes. Vamos, lo que una empresa espera encontrar en 2026.
Pero lo que lo hace especialmente sólido para este juego no es el listado de features. Son cuatro decisiones de diseño que tomaron hace años y que ahora se pagan solas:
Todo está separado por diseño. El director que orquesta, el catálogo que indexa, los storage daemons que escriben, y los clientes que se protegen — cuatro procesos distintos que pueden vivir en hosts distintos con credenciales independientes. Comprometer uno no te da los otros tres.
El catálogo vive en PostgreSQL de verdad. Una base de datos real, con sus backups, sus réplicas, sus permisos, auditable como cualquier otra base de datos crítica. Puedes ponerla detrás de un firewall distinto del plano de datos. Puedes encriptarla. Puedes replicarla a otro sitio.
Se verifica a sí mismo. Bacula vuelve a leer los backups periódicamente, compara checksums y te avisa si algo no cuadra. Si alguien ha metido mano, te enteras antes del día malo, no durante.
Es open source de verdad. El formato de los volúmenes está documentado. Si mañana desaparecemos nosotros, o desaparece Bacula Systems, tus backups se siguen pudiendo recuperar con las herramientas de la comunidad. Eso es propiedad real de tus datos, no un eslogan.
Esa arquitectura no es glamurosa. No sale bien en una presentación de ventas. Pero es exactamente la que necesitas cuando alguien, dentro de tu red, está intentando hacerte todo el daño que puede.
La parte del dinero
La parte del dinero (y por qué Bacula sale a cuenta)
Hablemos claro de precio, porque es ahí donde Bacula hace más ruido. La diferencia con Veeam, Veritas o Commvault no es de descuento — es de modelo. Los tres grandes te cobran por volumen: por terabyte protegido, por workload, por host, por socket. Cuanto más creces, más pagas. Es un modelo fantástico para el fabricante, y cada vez más doloroso para el cliente.
Bacula Systems factura por número de clientes y por funcionalidades. Puedes duplicar el dato protegido durante el año y el coste no se mueve. Y Bacula Community, la edición open source, directamente no tiene licencia — pagas solo el trabajo de los ingenieros que te lo ponen a punto y te lo mantienen.
Fabricante
Qué estás pagando
Qué pasa cuando creces
Veeam
Por workload / por socket / por instancia
El coste sube con cada host o VM nueva
Veritas NetBackup
Por capacidad front-end (TB a proteger)
El coste sube con cada TB nuevo
Commvault
Capacidad + módulos activados
El coste sube por partida doble
Bacula Enterprise
Por número de clientes y plugins
Plano. Duplica el dato, paga lo mismo.
Bacula Community + SIXE
Software gratuito + nuestras horas
Solo pagas el tiempo del equipo técnico.
En las migraciones que hemos hecho, el ahorro suele estar entre el 60% y el 85% en la factura anual de backup el primer año. El pico lo vemos en entornos medianos, de 20 a 200 TB protegidos, que es donde los modelos por capacidad pegan más fuerte. Y lo interesante es que el ahorro se va ampliando con el tiempo: Bacula no te castiga por crecer, así que cada año que pasa la diferencia con el modelo antiguo se hace mayor.
Antes de emocionarnos: los números de arriba son reales, pero dependen mucho de tu contrato concreto, de cuántos hosts tienes, de qué módulos usas y de con quién negociaste la última vez. Por eso, cuando alguien nos pregunta "¿cuánto me voy a ahorrar?", la respuesta siempre es la misma — enséñanos tu factura actual y te lo decimos con números. Si no hay ahorro significativo, también te lo decimos. No estamos aquí para vender Bacula a quien no lo necesita.
Las cinco decisiones
Cinco decisiones que marcan la diferencia
Instalar Bacula es razonablemente fácil. Hay paquetes para casi todo, la documentación es buena y en un par de horas tienes algo haciendo copias. Diseñar un Bacula que aguante a alguien con root en tu red ya es otra historia. Estas son las cinco decisiones que, por experiencia, separan un backup que funciona de un backup que también sobrevive:
1. Separa el plano de control del plano de datos
El director y el catálogo PostgreSQL tienen que vivir en una red administrativa distinta de los servidores que estás protegiendo. Con MFA para quien accede, y a ser posible con un enfoque zero-trust en los propios servidores de backup. Parece una obviedad, pero la mitad de instalaciones que vemos tienen el director colgando del mismo segmento de red que los clientes. Es como guardar la llave de la caja fuerte dentro de la caja fuerte.
2. Al menos dos repositorios independientes
Uno rápido, en disco o en Ceph con Object Lock, para los restores del día a día — el típico "me he cargado una BD a las 11 y la necesito a las 12". Y un segundo repositorio air-gap para retención larga, que puede ser tape LTO, o un Ceph aislado, o ambos. Es lo que hace que un atacante que se ha hecho dueño del primero no se lleve también el segundo. Volvemos a la regla 3-2-1-1-0 — no es un capricho de consultoría, es lo que marca la diferencia el día que pasa algo.
3. Verificación automática, todas las semanas
Bacula sabe volver a leer volúmenes ya escritos y comprobar que los checksums cuadran. Ese job de verificación debería correr semanalmente como mínimo. Es lo que te avisa de la manipulación, del bit rot, del fallo raro del hardware. Configurarlo son cinco minutos y te ahorra el peor día de tu carrera.
4. Retenciones bloqueadas en origen
La retención se define en el director cuando se escribe el volumen, y se sella en el medio en ese mismo momento. Una vez que un volumen está en una cinta WORM o en un bucket con Object Lock activo, ya no hay manera — ni por bconsole, ni por SQL, ni por el soporte del fabricante — de acortar su retención. Si alguien con privilegios de admin intenta borrar ese dato antes de tiempo, no puede. Ese es exactamente el punto.
5. Prueba los restores. De verdad.
Un backup que no se ha restaurado nunca no existe, existe solo en el papel. El ejercicio de recuperación hay que hacerlo, y hay que hacerlo bien: no restaurando una VM vacía de prueba, sino cargas representativas de lo que de verdad duele si se pierde. En SIXE esto lo metemos como parte del Plan de Recuperación ante Desastres, con pruebas calendadas al menos dos veces al año y con un informe que llega al comité de dirección. Porque si no llega al comité, no se hace.
Donde la gente se queda a medias
Los cinco puntos de arriba son exactamente donde la mayoría de proyectos Bacula se quedan cortos. La instalación estándar del paquete no los aplica por defecto — son decisiones de ingeniería que dependen de tu infraestructura concreta y que hay que pensar con tiempo. Cuando SIXE entra en un proyecto de Bacula, este es buena parte del trabajo que hacemos.
La migración
Migrar desde Veeam sin perder el histórico
La objeción que nos llega siempre, en la primera llamada, es la misma. "Tenemos siete años de histórico en Veeam, no nos podemos permitir perderlo". Y es justa — en banca, sanidad o administración pública, la retención larga no es una preferencia, es un requisito regulatorio (ENS, ISO 27001, GDPR, normativa sectorial). Tranquiliza saber que una migración bien diseñada no pierde un solo byte.
La forma en la que lo hacemos se parece siempre un poco a esto:
Ventana de coexistencia. Durante varias semanas — a veces meses — tu Veeam o tu Veritas sigue haciendo lo suyo en paralelo con el Bacula nuevo. Tienes doble cobertura mientras dura la transición. Si algo sale raro en Bacula, el antiguo está ahí.
Restores reales, no de laboratorio. Antes de apagar el sistema antiguo, restauramos desde Bacula cosas que importan de verdad. No una VM de prueba; cargas representativas. Solo cuando esos restores validan el diseño, pasamos de fase.
Histórico en modo solo lectura. El dato viejo se mantiene accesible en modo consulta el tiempo que exija tu política de retención. Si en 2027 alguien pide un restore de 2023, sigue disponible. Lo nuevo ya vive en Bacula.
Este servicio de migración es probablemente lo que más nos están pidiendo últimamente — por la combinación de subidas de precio en el licenciamiento propietario y la nueva exigencia de backup inmutable que está empujando a mucha gente a replantear su estrategia. El detalle completo del servicio, con SLAs y casos reales, lo tienes en la página dedicada: Soporte técnico y migración a Bacula.
Por dónde empiezas
Por dónde empezar hoy mismo
Si has llegado hasta aquí y estás pensando "tendría que revisar nuestro backup", probablemente tengas razón. No hace falta arrancar un proyecto enorme para dar el primer paso. De hecho, lo más útil suele ser una auditoría corta que responda honestamente a tres preguntas:
¿Son mis backups realmente inmutables? Si un atacante con credenciales de admin en mi red quisiera destruirlos, ¿podría?
¿Se están verificando automáticamente? ¿O solo sabré si están corruptos el día que los necesite de verdad?
¿Cuánto estoy pagando al año por TB protegido, y qué cara tendrá esa factura dentro de tres años?
Las tres preguntas las puedes responder tú con tu equipo, sin llamar a nadie. Y si alguna de las respuestas no te gusta, hablamos. Sin comercial por medio, sin PowerPoint, directamente con alguien del equipo técnico que ha tenido las manos dentro de proyectos como el tuyo.
Migración de VMware a Proxmox VE — Bacula integra bien con Proxmox para backup consistente a nivel de VM, y muchas veces van de la mano
Soporte técnico Ceph — si tu repositorio inmutable va a ser Ceph con Object Lock, aquí entra nuestra otra especialidad
¿Tu backup sobreviviría a hoy?
Revisemos juntos tu arquitectura de backup
Sin comerciales, sin presentaciones genéricas, sin compromiso. Una llamada técnica con alguien del equipo de SIXE para ver cómo estás y qué tiene sentido tocar. Si Bacula encaja, te lo diremos. Si no, también.
Ejecutamos un LLM en IBM i. Sin Linux. Sin nube. Sin GPU.
llama.cpp compilado para AIX corre directamente en IBM i vía PASE. Tus programas RPG pueden llamar a un modelo de lenguaje local sin añadir infraestructura y sin enviar datos a la nube. En SIXE te enseñamos a hacerlo ;)
Marzo 2026●8 min lectura
Si administras un IBM i, ya sabes lo que viene cada vez que alguien pregunta por inteligencia artificial: "monta un LPAR Linux", "usa OpenAI", "mira Wallaroo". Todas las respuestas implican salir del entorno, añadir capas, y en algún momento enviar datos de negocio a un servidor que no controlas.
Hay 150.000 sistemas IBM i procesando transacciones de banca, seguros y sanidad. La respuesta no puede ser siempre "añade más infraestructura". Así que probamos otra cosa.
El experimento
Qué hicimos exactamente
Tomamos llama.cpp — el motor de inferencia LLM open source más usado — lo compilamos para AIX y copiamos el binario a una partición IBM i V7R5. Lo ejecutamos vía PASE. Funcionó al primer intento.
IBM i V7R5 en pub400.com — un sistema IBM i público. Big-endian, powerpc-64bit, OS400. No Linux, no AIX. IBM i.
Qué tipo de binario es
$ file llama/llama-simple
llama/llama-simple: 64-bit XCOFF executable or object module
XCOFF de 64 bits: el formato ejecutable nativo de AIX. Compilado en AIX 7.3 POWER con GCC 13.3 y extensiones vectoriales VSX. Es el mismo binario de nuestro proyecto llama-aix, que ya distribuye 10 modelos GGUF big-endian en HuggingFace.
El binario carga, enlaza libggml y libllama, parsea argumentos y responde. Todo dentro de PASE. Para lanzar inferencia real, le pasas un modelo GGUF big-endian:
$ LIBPATH=/home/HBSIXE/llama /home/HBSIXE/llama/llama-simple \
-m models/tinyllama-1.1b-q4_k_m-be.gguf \
-p "What is IBM i?" -n 100 -t 4
El contexto
Por qué tiene sentido para un equipo IBM i
En 2026 la conversación sobre IA en IBM i está más viva que nunca. IBM acaba de lanzar Bob (el sucesor de WCA for i), un asistente de codificación para desarrolladores RPG. El 70% de los clientes IBM i prevé actualizaciones de hardware este año. Y hay una pregunta que sigue sin tener respuesta directa:
¿Cómo integro un modelo de lenguaje en mis aplicaciones IBM i sin depender de servicios externos?
Las opciones habituales, a día de hoy:
Opción
Qué implica
El problema
LPAR Linux
Montar un LPAR aparte, ejecutar el LLM ahí, llamarlo desde RPG vía API
Infraestructura nueva, coste adicional, los datos viajan entre particiones
API cloud
Llamar a OpenAI, Azure o AWS desde RPG
Los datos de negocio salen de la máquina. En banca, seguros o sanidad esto es un problema serio
Wallaroo
La opción 1 empaquetada como servicio
500 $/mes. Sigue siendo un LPAR Linux con marca
PASE + llama.cpp
El LLM corre dentro del propio IBM i vía PASE
Sin hardware adicional. Los datos no salen de la partición.
¿Y IBM Bob?
Bob es para el desarrollador: ayuda a entender, documentar y generar código RPG desde el IDE. Lo que describimos aquí es para la aplicación en producción: un LLM corriendo en la misma partición al que cualquier programa RPG puede llamar como si fuera una API local. Son herramientas complementarias, no alternativas.
La base técnica
PASE: el puente que ya tenías instalado
PASE (Portable Application Solutions Environment) es un entorno de ejecución integrado en IBM i que ejecuta binarios AIX de forma nativa. No es emulación — es una capa que expone las llamadas al sistema AIX directamente sobre el kernel de IBM i. Si algo corre en AIX, puede correr en IBM i vía PASE.
┌──────────────────────────────────────────┐│ IBM i (OS400) ││││ ┌──────────────┐ ┌────────────────┐ ││ │RPG / CL│ │PASE│ ││ │COBOL / Db2│───→│ (AIX runtime) │ ││ ││ ││ ││ │ localhost │ │llama-server│ ││ │ :8080 │ │ + GGUF model │ ││ └──────────────┘ └────────────────┘ ││││ IBM POWER Hardware │└──────────────────────────────────────────┘
Llevamos años compilando paquetes para AIX en LibrePower — más de 30 paquetes open source instalables con DNF. Cuando llama.cpp llegó al repositorio, probar el salto a IBM i era el paso natural. PASE hace el resto.
Para los administradores de IBM i
No necesitas instalar nada especial en el sistema operativo. PASE ya está activo. Solo necesitas el binario XCOFF de llama.cpp y un modelo GGUF big-endian. El LLM corre como cualquier otro proceso PASE, sin tocar el entorno nativo IBM i.
El escollo técnico
El problema del big-endian (y cómo lo resolvimos)
Hay una razón por la que nadie había hecho esto de forma sencilla antes: el orden de bytes. IBM i y AIX son big-endian. La práctica totalidad del software de IA — x86, ARM, Linux ppc64le — asume little-endian. Un archivo GGUF descargado de HuggingFace directamente no funciona en IBM i: los bytes están en el orden equivocado.
Esto ya lo habíamos resuelto en nuestro trabajo con AIX. La solución: convertir los modelos antes de distribuirlos. Los publicamos en huggingface.co/librepowerai, validados en hardware AIX real y listos para cargar directamente en IBM i PASE.
Modelo
Tamaño
Cuantización
TinyLlama 1.1B Chat
668 MB
Q4_K_M
LFM 1.2B Instruct
695 MB
Q4_K_M
LFM 1.2B Thinking
731 MB
Q4_K_M
Y 7 modelos más
—
—
Son los mismos modelos que alcanzan 10–12 tok/s en AIX POWER. En IBM i POWER10 — con aceleración MMA activa a través de OpenBLAS — el rendimiento debería ser comparable o mejor. Los benchmarks concretos en IBM i están en preparación.
De PoC a producción
Del experimento a producción
Ejecutar --help prueba que el binario carga. El camino real hasta que esto es útil para tus aplicaciones tiene tres pasos, y el primero ya está disponible.
Paso 1: Inferencia directa (ya disponible)
Desde cualquier sesión SSH o QSH en el IBM i:
# Inferencia desde línea de comandos
LIBPATH=/ruta/a/llama /ruta/a/llama/llama-simple \
-m /ruta/al/modelo.gguf \
-p "Resume este albarán" -n 200 -t 8
Útil para scripts CL, jobs por lotes, o simplemente para verificar que el modelo carga y responde bien en tu hardware concreto antes de ir más allá.
Paso 2: Servidor con API compatible con OpenAI (a corto plazo)
llama.cpp incluye llama-server, que levanta un endpoint HTTP compatible con la API de OpenAI. Una vez activo en PASE, cualquier programa RPG puede llamarlo usando QSYS2.HTTP_POST como lo haría con cualquier otra API:
# Arrancar el servidor en IBM i vía PASE
LIBPATH=/ruta/a/llama /ruta/a/llama/llama-server \
-m /ruta/al/modelo.gguf \
--host 0.0.0.0 --port 8080 -t 8
// Llamada desde RPG — el LLM está en localhost
dcl-s url varchar(256) inz('http://localhost:8080/v1/chat/completions');
dcl-s cuerpo varchar(65535);
dcl-s respuesta varchar(65535);
// QSYS2.HTTP_POST — sin salir de IBM i
La parte importante: localhost. El modelo está en la misma máquina. Los datos no abandonan la partición.
Paso 3: Integración con aplicaciones de negocio (en desarrollo)
Análisis de documentos: pasar informes Db2 al LLM para generar resúmenes automáticos
Consultas en lenguaje natural: el usuario escribe en español, el LLM devuelve SQL
Modernización de código RPG: el LLM analiza y documenta programas existentes sin salir de IBM i
Monitorización inteligente: analizar mensajes QSYSOPR y logs de trabajos con contexto semántico
Una nota sobre rendimiento: los modelos pequeños (1–2B parámetros) en PASE son más que suficientes para clasificación, resumen, extracción estructurada de datos y respuestas con formato fijo. Para generación de texto más larga o razonamiento complejo, los modelos de 7B+ escalan bien con más cores. Benchmarks específicos en IBM i POWER10 en preparación.
Hands-on
Cómo probarlo
Si tienes acceso a un IBM i con PASE activo, son tres pasos.
TinyLlama es un buen punto de partida: 668 MB, carga rápido, y sirve para verificar que todo funciona antes de pasar a modelos más grandes.
3. Lanzar la inferencia
LIBPATH=/ruta/a/llama ./llama-simple \
-m tinyllama-be.gguf \
-p "¿Qué es IBM i?" \
-n 150 -t 4
¿Tienes sistemas IBM i en producción?
En SIXE llevamos años dando soporte a entornos IBM i. Si quieres ver si esta aproximación encaja con tu arquitectura — o entender qué implica para tus aplicaciones RPG — hablemos, sin compromiso.
Hoja de ruta
Qué viene después
Esto es una prueba de concepto, no un producto terminado. Eso sí, tenemos claro qué queremos hacer a continuación:
llama-server en IBM i — el servidor API HTTP corriendo en PASE, documentado y empaquetado para que puedas levantarlo en minutos
Ejemplos de integración con RPG — código real de llamadas al LLM desde programas RPG con QSYS2.HTTP_POST
Benchmarks en IBM i POWER10/POWER11 — mediciones reales de tok/s con PASE en hardware de producción
Modelos más grandes — pruebas con modelos 7B+ en particiones con memoria suficiente
El primer paquete vLLM precompilado para Linux ppc64le. Lo ha construido la comunidad — y corre en el hardware que ya tienes.
Marzo 2026●18 min lectura
Si administras servidores IBM POWER, ya conoces la dinámica. El hardware es excepcional — POWER9, POWER10 y POWER11 ofrecen RAS incomparable, ancho de banda de memoria y un rendimiento por core que pocas arquitecturas igualan. Pero en el ecosistema de IA, hasta ahora tenías dos opciones: traer tus propias GPUs (normalmente x86) o pasar por Red Hat OpenShift AI. Hoy existe una tercera opción para ejecutar inferencia de LLMs en IBM POWER. Una que tarda 30 segundos, funciona en hardware que ya tienes y usa la aceleración hardware MMA de forma automática.
El paquete: qué y como
Qué hemos construido: vLLM en IBM POWER como paquete .deb
vLLM es el motor de inferencia de LLMs de código abierto más usado. Impulsa inferencia a escala de millones de peticiones diarias en producción. Soporta la API OpenAI completa: /v1/chat/completions, /v1/completions, /v1/models — streaming, llamadas a funciones, uso de herramientas.
El problema era que no existían paquetes precompilados para ppc64le. Ni en PyPI. Ni en los repositorios de Ubuntu. Si querías vLLM en IBM POWER, tenías que apañártelas. La propia comunidad de IBM tiene documentado lo complejo que es el proceso manual.
Así que lo compilamos nosotros. En hardware IBM POWER real. Optimizado para la arquitectura. Y lo empaquetamos como un .deb que APT puede instalar con resolución completa de dependencias.
$ apt-cache show python3-vllm
Package: python3-vllm
Version: 0.9.2-1
Architecture: ppc64el
Maintainer: LibrePower <packages@librepower.org>
Depends: python3 (>= 3.10), python3-numpy, python3-requests
Homepage: https://librepower.org/stack/databases-operating-systems/linux/
Description: Servidor de inferencia LLM compatible con OpenAI para ppc64le
Ubuntu en IBM POWER
Ejecutar Ubuntu en IBM POWER es la base de este flujo de trabajo. SIXE despliega y soporta entornos Ubuntu ppc64le como Canonical Partner — la misma infraestructura que hace posible esta instalación por APT. Si tu equipo necesita profundizar en la administración de Linux en Power, tenemos formación oficial IBM específica para ello.
El código
El proceso: de código fuente a paquete .deb en ppc64le
Compilar vLLM para POWER no es un simple pip install. Aquí está lo que implicó.
PyTorch en POWER
vLLM depende de PyTorch, que no se distribuye para ppc64le en PyPI. IBM publica wheels en wheels.developerfirst.ibm.com — las usamos como base. Puedes consultar el catálogo completo de herramientas de desarrollo soportadas por IBM para POWER.
La extensión C++
La ruta de alto rendimiento de vLLM es una extensión C++ (_C.abi3.so) que gestiona la atención, el caché, las funciones de activación y la cuantización. Hay que compilarla desde el código fuente con CMake, enlazando contra la API C++ de PyTorch y oneDNN para operaciones GEMM optimizadas.
El binario resultante incluye oneDNN con kernels GEMM para PPC64 — la misma librería matemática que Intel usa para x86, pero apuntando a las unidades vectoriales de POWER.
Resolución de dependencias
El ecosistema Python en ppc64le tiene lagunas. Algunos paquetes tienen wheels precompiladas; otros necesitan compilación desde el código fuente; y unos pocos tienen conflictos de versión. Resolvimos todo esto para que tú no tengas que hacerlo.
En la práctica
Inferencia de LLMs en IBM POWER: código y resultado
Así es como se ve en la práctica. Primero, instala el paquete:
# Añadir el repositorio APT de LibrePower
curl -fsSL https://linux.librepower.org/install.sh | sudo sh
# Instalar vLLM para ppc64le
sudo apt update
sudo apt install python3-vllm
# Instalar wheels de PyTorch desde IBM
pip3 install torch --extra-index-url \
https://wheels.developerfirst.ibm.com/ppc64le/linux
Luego ejecuta inferencia desde Python:
# Python
from vllm import LLM, SamplingParams
llm = LLM(
model="Qwen/Qwen2.5-0.5B-Instruct",
dtype="bfloat16",
device="cpu",
enforce_eager=True
)
output = llm.generate(
["Explica la computación cuántica en términos sencillos."],
SamplingParams(temperature=0, max_tokens=100)
)
print(output[0].outputs[0].text)
Pero el valor real de vLLM no está en un script Python — está en el modo servidor, compatible con la API de OpenAI:
# Arrancar el servidor de inferencia compatible con OpenAI
python3 -m vllm.entrypoints.openai.api_server \
--model Qwen/Qwen2.5-0.5B-Instruct \
--device cpu --dtype bfloat16 --port 8000
LangChain, LlamaIndex, Open WebUI, Continue.dev — cualquier aplicación que pueda apuntar a un endpoint OpenAI funciona sin modificaciones. Cambias base_url a tu servidor POWER y listo. Esto es lo que convierte la inferencia en CPU sobre IBM POWER en una ruta real hacia el despliegue de IA generativa en infraestructura propia, sin dependencia de GPU ni de nube pública.
Los números
Rendimiento real en POWER9, POWER10 y POWER11: benchmarks de inferencia
Hicimos benchmarks en ambas generaciones con Qwen2.5-0.5B-Instruct (494M parámetros, BF16). No son numeritos imaginarios :p vienen de ejecutar la herramienta de benchmark en hardware real.
13,9 tok/s desde un único core POWER10. Para contexto: el resultado de POWER9 usa 12 hilos a través de múltiples cores para alcanzar 17,6 tok/s. La mejora de eficiencia por core de POWER9 a POWER10 es dramática, impulsada por la aceleración hardware MMA. POWER11 comparte la misma arquitectura MMA con mejoras adicionales.
Sistema
Hilos
tok/s
Eficiencia por core
POWER10/11
1
13,9
13,9 tok/s/core
POWER9
12
17,6
1,5 tok/s/core
Esto no compite con una A100 — cubre un hueco completamente diferente: ejecutar inferencia de modelos de lenguaje en la infraestructura IBM POWER que ya tienes. Sin presupuesto para GPU, sin slots PCIe, sin dolores de cabeza con drivers. Para organizaciones con servidores POWER9, POWER10 o POWER11 existentes, este es el camino sin inversión en capital adicional hacia la IA privada.
También probamos Qwen2.5-7B-Instruct (7.000 millones de parámetros) en un único core POWER10 — cargó y corrió a 1,0 tok/s. No es suficiente para uso interactivo en un solo core, pero demuestra que los modelos más grandes funcionan. Con más cores, esto escala linealmente. En SIXE recibimos habitualmente esta pregunta de clientes con sistemas IBM POWER en producción: ¿puedo usar este hardware para IA? La respuesta ya es sí.
Dentro de la máquina
Qué ocurre realmente cuando POWER10/11 ejecuta un modelo de lenguaje
Si has visto las presentaciones de IBM sobre IA en POWER, probablemente te hayas encontrado con términos como MMA, Spyre, oneDNN y OpenShift AI. Suelen aparecer juntos en la misma diapositiva. ¿Qué significan realmente? ¿Y cuáles están activos cuando ejecutas python3 -m vllm?
Fuimos al fondo del stack de software para responder a esto. Los resultados nos sorprendieron.
Glosario rápido sin jerga innecesaria
LLM (modelo de lenguaje grande) — Software que genera texto: ChatGPT, Llama, Qwen. Un modelo matemático con miles de millones de números que predice la siguiente palabra.
Inferencia — Ejecutar un modelo ya entrenado para obtener respuestas. El entrenamiento enseña al modelo; la inferencia lo usa. Este artículo habla solo de inferencia.
Token — Una palabra o parte de una palabra. “17,6 tokens por segundo” significa roughly 17-18 palabras por segundo.
BF16 (bfloat16) — Una forma de almacenar números usando 16 bits en lugar de 32. La mitad de memoria, casi la misma precisión. Piénsalo como: “calidad suficiente a la mitad del coste de almacenamiento”.
GEMM (multiplicación de matrices general) — La operación matemática central de las redes neuronales. La mayor parte del tiempo de cómputo en inferencia LLM se invierte en multiplicar matrices grandes.
MMA (Matrix-Multiply Accumulate) — Circuitería dedicada dentro de POWER10 y POWER11 diseñada para acelerar las matemáticas matriciales. Como una calculadora especializada para la operación específica que domina la inferencia LLM.
OpenBLAS — Una librería matemática de código abierto con GEMM optimizada. El motor que hace la multiplicación de matrices real en POWER.
oneDNN — La librería matemática de Intel, también compilada en vLLM. Otro motor para el mismo propósito.
PyTorch — El framework que ejecuta la red neuronal. Llama a OpenBLAS o oneDNN para las matemáticas pesadas.
Cómo encajan las piezas
Cuando vLLM genera un token, este es el camino exacto a través de la máquina:
Escribes una pregunta ↓
vLLM la recibe y la divide en tokens ↓
PyTorch ejecuta las matemáticas de la red neuronal ↓
Para cada capa: multiplica matrices grandes (GEMM) ↓
PyTorch le pide a OpenBLAS: “multiplica estas dos matrices BF16” ↓
OpenBLAS ejecuta sbgemm_kernel_power10 ← AQUÍ SE USA MMA ↓
El hardware POWER10/11 ejecuta instrucciones MMA ↓
El resultado sube, se elige el siguiente token ↓
Ves aparecer la siguiente palabra
La aceleración MMA ya está activa en nuestros benchmarks. No es una función futura ni un flag de configuración — funciona ya, a través de la ruta PyTorch → OpenBLAS → hardware MMA. Sin configuraciones especiales.
La prueba: BF16 frente a FP32 en POWER10/11
En POWER10 y POWER11, MMA acelera las matemáticas BF16. En POWER9 (sin MMA), BF16 es en realidad más lento que FP32 por emulación software. Si MMA funciona, BF16 debe ser más rápido:
# Benchmark de multiplicación de matrices (1024×1024) en POWER10
BF16: 384,4 GFLOPS (5,6 ms)
FP32: 249,6 GFLOPS (8,6 ms)
Ratio BF16/FP32: 1,54×
BF16 es 1,54× más rápido que FP32. MMA está activo y entrega aceleración medible. Nuestros 13,9 tok/s en un único core POWER10 ya incluyen MMA. Ese es el número real, acelerado por hardware. Las capacidades de aceleración de IA de POWER10 y POWER11 son algo que tratamos en profundidad en nuestros servicios de soporte y mantenimiento de IBM POWER.
La investigación sobre oneDNN (y lo que aprendimos)
Inicialmente pensamos que podría haber rendimiento extra sin aprovechar.
La build de vLLM incluye oneDNN (originalmente de Intel). Dentro hay dos rutas matemáticas específicas para POWER:
GEMM int8: Un kernel escrito a mano por ingenieros de IBM con instrucciones MMA para modelos cuantizados.
GEMM BF16: Un paso directo a OpenBLAS — pero solo cuando se compila con flags específicos.
Nuestra build inicial no tenía esos flags. Recompilamos con -DDNNL_BLAS_VENDOR=OPENBLAS, confirmamos que los flags estaban activos, volvimos a hacer el benchmark — mismo rendimiento.
¿Por qué? PyTorch ya iba directamente a OpenBLAS, saltándose oneDNN para las operaciones matriciales principales. La optimización ya estaba ahí; simplemente no lo sabíamos.
Conclusión práctica: No necesitas configurar nada especial. PyTorch en POWER10 y POWER11 con OpenBLAS usa MMA automáticamente para inferencia BF16. Instala el paquete y ejecuta.
¿Y qué hay de IBM Spyre?
IBM Spyre es una tarjeta aceleradora de IA dedicada para POWER — hardware completamente separado con su propio silicio para matemáticas de IA. La distinción clave:
MMA = aceleración integrada dentro de cada core POWER10 y POWER11 (activa ahora mismo en nuestros benchmarks)
Spyre = tarjeta aceleradora de IA separada que se añade al sistema (prometedora, pero requiere stacks de software específicos de IBM)
Nuestro trabajo se centra en lo que está disponible hoy usando la CPU que ya tienes en tu máquina, sin inversión adicional en hardware.
El cuadro completo
Tecnología
Qué es
¿Activa en nuestra build?
POWER10/11 MMA (BF16)
Acelerador matricial integrado en la CPU
Sí — PyTorch → OpenBLAS
POWER10/11 MMA (int8)
El mismo hardware, para modelos de 8 bits
Compilado, no end-to-end aún
IBM Spyre
Tarjeta aceleradora de IA separada
No — hardware diferente
OpenShift AI
Plataforma ML completa en Kubernetes
No — somos la alternativa ligera
oneDNN
Librería matemática incluida en vLLM
Compilada, PyTorch la saltea
OpenBLAS
Librería matemática con kernels POWER10/11 a mano
Sí — el verdadero motor
Contexto
El panorama: inferencia de LLMs en IBM POWER sin OpenShift
Red Hat OpenShift AI
Hasta ahora, la propuesta oficial de IBM/Red Hat para inferencia de LLMs en IBM POWER era OpenShift AI. Soporta notebooks, pipelines, entrenamiento de modelos, serving y monitorización. Desde la versión 3.0, corre en ppc64le con cargas de trabajo solo de CPU.
OpenShift AI es la elección correcta para organizaciones que ya tienen clústeres OpenShift. Viene con RBAC, InstructLab para fine-tuning de modelos y soporte enterprise.
Pero requiere OpenShift. Un clúster Kubernetes, una suscripción Red Hat, gestión de operadores. Para muchos entornos POWER — especialmente los que corren Linux standalone o entornos mixtos AIX/Linux — eso es un compromiso significativo solo para servir un modelo. Estas son exactamente las organizaciones que gestionan su infraestructura IBM POWER con soporte de SIXE.
En SIXE llevamos años ayudando a clientes con IBM POWER a modernizar sus cargas de trabajo. La aparición de inferencia de IA local sobre ppc64le encaja directamente con la línea editorial que describimos en nuestro artículo sobre factoría de IA con stack open source: IA en producción, sin dependencia de nube pública, sobre infraestructura que ya pagas.
Lo que aporta LibrePower
No estamos reemplazando OpenShift AI. Lo complementamos con una ruta más ligera para los muchos entornos POWER que no necesitan la plataforma completa.
OpenShift AI
LibrePower vLLM
Instalación
Clúster OpenShift + operadores
apt install python3-vllm
Infraestructura
Kubernetes obligatorio
Cualquier Ubuntu/Debian ppc64le
Alcance
Ciclo ML completo
Solo inferencia
Soporte
Suscripción Red Hat
Comunidad (código abierto)
GPU
Soportada (x86)
Solo CPU (nativo POWER)
Tiempo hasta la primera inferencia
Horas o días
Minutos
Coste
Licenciamiento OpenShift
Gratuito
IBM construye la autopista — hardware de primer nivel, wheels de PyTorch, OpenShift AI, InstructLab. LibrePower añade un acceso directo para quienes no necesitan la plataforma completa. El roadmap de IA en IBM POWER avanza rápido, y las herramientas de comunidad como esta cubren huecos reales en el ecosistema actual.
La infraestructura
Cómo funciona el repositorio de paquetes de LibrePower
Construimos librepower.org siguiendo el mismo patrón que nuestro repositorio de paquetes AIX — infraestructura que ya sirve más de 30 paquetes de código abierto a sistemas AIX en todo el mundo.
El CI/CD corre en GitLab: cada push regenera los metadatos APT y despliega automáticamente. Todos los paquetes compilados en hardware IBM POWER real — no compilación cruzada, no emulación. El código fuente completo está en GitLab bajo Apache 2.0.
Hoja de ruta
Qué viene después para vLLM en IBM POWER
Más modelos probados — Llama, Mistral, Phi, Granite. Benchmarks sistemáticos por familia de modelos.
llama.cpp para ppc64le — Modelos GGUF cuantizados para una huella de memoria aún menor. Ya disponible para AIX.
Soporte para Ubuntu 24.04 y Debian 12 — Extendiendo el paquete a las últimas versiones LTS.
Variantes optimizadas para POWER10/11 — Profundizando en el tuning de MMA. Nuestros 13,9 tok/s por core son un punto de partida, no un techo.
GEMM int8 end-to-end — Completando la ruta MMA para modelos cuantizados, lo que debería mejorar el throughput.
¿Tienes IBM POWER y quieres ejecutar IA?
SIXE ayuda a las organizaciones a desplegar y operar Linux en IBM POWER — desde formación oficial hasta soporte de infraestructura completo. Si estás evaluando inferencia de LLMs en hardware POWER existente o quieres saber cómo encaja con tu arquitectura actual, hablemos. También puedes leer más sobre el contexto más amplio de IA open source en IBM Power en nuestro artículo sobre cómo montar una factoría de IA con stack open source.
¿Tienes un sistema ppc64le?
Prueba vLLM en IBM POWER
Si tienes un sistema con Ubuntu, son tres comandos. El código fuente está en GitLab si quieres profundizar o contribuir.
# Añadir el repositorio LibrePower
curl -fsSL https://linux.librepower.org/install.sh | sudo sh
# Instalar vLLM para ppc64le
sudo apt update && sudo apt install python3-vllm
# Instalar PyTorch (wheels de IBM)
pip3 install torch --extra-index-url \
https://wheels.developerfirst.ibm.com/ppc64le/linux
# Arrancar el servidor de inferencia compatible con OpenAI
python3 -m vllm.entrypoints.openai.api_server \
--model Qwen/Qwen2.5-0.5B-Instruct \
--device cpu --dtype bfloat16 --port 8000
Qué es una Factoría de IA y cómo montarla con open source en tu datacenter
El concepto de AI Factory lleva dos años en boca de todos, pero pocas organizaciones entienden qué implica técnicamente ni cómo montarla sin depender de un proveedor cloud. Aquí lo explicamos sin rodeos, y con el stack concreto que usamos en producción.
Marzo 2026●20 min lectura
Una factoría de IA no es un servidor con una GPU y un modelo descargado de Hugging Face. Es una infraestructura de cómputo distribuida, diseñada para ejecutar modelos de lenguaje y visión en producción de forma continua, escalable y bajo control total de la organización. La buena noticia: montarla ya no es privilegio de los grandes. La tecnología open source que usa el Barcelona Supercomputing Center para su AI Factory, o la que impulsa las infraestructuras soberanas europeas, está disponible para cualquier empresa con datacenter propio. Lo que leerás a continuación es una guía sobre qué necesitas, qué no y cómo decidir si tiene sentido para ti.
Un poquito de contexto
Qué es exactamente una factoría de IA
El término “AI Factory” lo popularizó Jensen Huang de NVIDIA en 2023 para describir lo que los centros de datos están convirtiéndose: máquinas que producen inteligencia de forma continua, como una fábrica produce bienes. La metáfora no es poética; es técnicamente precisa.
Una factoría de IA clásica tiene cuatro componentes diferenciados: un sistema de almacenamiento para guardar los pesos de los modelos y los datasets (que pesan decenas o cientos de gigabytes), una capa de cómputo GPU para ejecutar la inferencia, un orquestador que gestiona qué modelo corre en qué hardware, y una API que expone los modelos al resto de la organización. Cuando esos cuatro componentes funcionan juntos de forma eficiente, tienes una factoría de IA.
Lo que la diferencia de “tener un LLM corriendo en un servidor” es la escala, la fiabilidad y la gestión. En una factoría de IA se sirven múltiples modelos en paralelo, se gestionan colas de peticiones, se garantiza disponibilidad y se monitoriza el uso de recursos. Es infraestructura de producción, no un entorno de pruebas.
Dato relevanteLa Comisión Europea ha comprometido más de 1.500 millones de euros para construir AI Factories distribuidas por los estados miembros bajo el programa EuroHPC. El objetivo explícito es que Europa tenga infraestructura soberana de IA sin depender de proveedores estadounidenses o asiáticos. España participa a través del BSC con su AI Factory en Barcelona. La misma tecnología que ellos usan, tú puedes montarla en tu datacenter.
¿Por qué recurrir a una factoría de IA?
Por qué las organizaciones se traen la inferencia a casa
Hay tres motivos que aparecen siempre en todas las conversaciones que tenemos con clientes cuando evalúan montar su propia infraestructura de IA. No son argumentos de marketing: son realidades operativas y financieras.
💸
Costes predecibles
Las facturas de GPU en cloud público pueden variar un 30–40% entre ciclos según la demanda. Con infraestructura propia, el coste es fijo, amortizable y sin sorpresas. A partir de un volumen medio de inferencia, la inversión se recupera en 12–18 meses frente a cloud.
🔓
Sin vendor lock-in
APIs propietarias, formatos cerrados, modelos fine-tuneados que viven en infraestructura ajena. Con un stack open source, tus modelos y tus datos son tuyos. Siempre puedes moverlo todo, sin negociaciones ni contratos de salida.
🏛️
Cumplimiento regulatorio
El RGPD y el EU AI Act exigen saber exactamente dónde se procesan los datos. Si tu inferencia toca datos de pacientes, ciudadanos o clientes bancarios, necesitas control total sobre la infraestructura. On-premise es la única respuesta válida.
La pregunta ya no es si montar infraestructura propia de IA, sino cuándo y cómo hacerlo sin repetir los errores del cloud hace diez años: velocidad sin arquitectura.
— Equipo técnico SIXE
Dicho esto, montar una factoría de IA on-premise no es para todo el mundo. Si procesas diez peticiones de inferencia al día y no tienes requisitos regulatorios estrictos, probablemente cloud es lo correcto ahora mismo. La infraestructura propia empieza a tener sentido cuando el volumen de uso es sostenido, cuando los datos son sensibles, o cuando necesitas correr modelos fine-tuneados propietarios sin exponerlos a terceros.
Vale pero y esto… ¿cómo lo monto exactamente?
El stack open source: tres tecnologías, cero dependencias propietarias
Existe una combinación de tres tecnologías que ha emergido como estándar de facto para construir factorías de IA on-premise en entornos europeos. Las mismas que usa el BSC. Las mismas que impulsan infraestructuras soberanas en Francia, Alemania e Italia. Y las mismas con las que trabajamos en SIXE.
Ceph: el almacenamiento distribuido para IA
Los modelos de lenguaje son voluminosos. Llama 3 70B ocupa unos 40 GB en precisión float16. Mixtral 8x7B ronda los 90 GB. Un catálogo razonable de modelos para una organización mediana puede superar fácilmente los 500 GB, sin contar los datasets de fine-tuning ni los registros de inferencia.
Ceph resuelve esto con almacenamiento distribuido que unifica object storage (compatible con S3 de forma nativa), block storage y filesystem en un mismo cluster. Escala de terabytes a petabytes sin interrupciones, soporta erasure coding para eficiencia de almacenamiento y tiene integración nativa con Kubernetes via CSI. Para una factoría de IA, Ceph actúa como el backbone donde viven los pesos de los modelos, los datasets y los resultados.
Perspectiva SIXESomos Canonical Partner y llevamos años desplegando clusters Ceph en producción, incluyendo entornos de IA y HPC. Ceph no es “activar un checkbox”: requiere dimensionamiento cuidadoso, diseño de red y políticas de replicación adaptadas a la carga. En clusters de 3 nodos hay consideraciones de quórum que conviene no improvisar. Ofrecemos formación específica en administración Ceph y soporte para que tu equipo opere Ceph con autonomía real.
OpenStack: tu cloud privado con gestión nativa de GPUs
OpenStack es lo que convierte tu hardware en un cloud privado enterprise. Para una factoría de IA, su función principal es la gestión de recursos GPU: PCI passthrough para acceso directo a la GPU desde la VM, vGPU para compartir una GPU física entre múltiples cargas de trabajo, y NVIDIA MIG (Multi-Instance GPU) para particionar GPUs A100 y H100 en instancias independientes.
Bajo la Linux Foundation desde 2024, OpenStack opera en producción con más de 45 millones de cores en organizaciones como Walmart, GEICO o LINE Corp. No es una tecnología emergente: es infraestructura probada a escala real, con gobernanza independiente que garantiza continuidad.
Detalle importanteOpenStack no es trivial. Comprende más de 30 proyectos de servicio y requiere equipos con experiencia en sistemas distribuidos. Si tu equipo viene de VMware, la curva de aprendizaje existe. Nuestro servicio incluye formación práctica específica para que puedan operar el stack de forma autónoma, sin dependencia de consultoría a largo plazo.
Kubernetes + vLLM: la capa de orquestación de inferencia
Kubernetes es el estándar CNCF para orquestar cargas de trabajo en contenedores, y tiene soporte nativo para GPU scheduling mediante el NVIDIA GPU Operator. Sobre Kubernetes se despliegan los motores de inferencia, siendo vLLM el más relevante en este momento para modelos de lenguaje.
vLLM implementa PagedAttention, una técnica que gestiona la memoria KV cache de forma eficiente y permite servir múltiples peticiones en paralelo sin desperdiciar VRAM. En benchmarks representativos, vLLM supera entre 3 y 5 veces el throughput de una implementación naive del mismo modelo. Expone una API compatible con OpenAI, lo que facilita la migración de aplicaciones que ya consumen GPT-4 o similares.
Arquitectura de referencia: del dato al modelo en producción
Una factoría de IA on-premise con este stack sigue un flujo de cuatro capas. No es el único diseño posible, pero sí el que mejor balancea complejidad operacional, rendimiento y portabilidad.
01 — Datos
Ceph S3
Modelos, datasets, resultados de inferencia. API compatible S3 para integración con pipelines MLOps.
02 — Cómputo
OpenStack
GPU scheduling, bare metal, redes aisladas por proyecto. PCI passthrough y MIG para máxima eficiencia.
03 — Orquestación
Kubernetes
GPU Operator, autoscaling de pods de inferencia, gestión del ciclo de vida de los deployments.
04 — Producción
vLLM / Triton
APIs de inferencia, RAG, agentes. Compatibilidad OpenAI para integración sin fricción.
La clave de este diseño es que cada capa es independiente y reemplazable. Si mañana aparece un orquestador mejor que Kubernetes para cargas de IA, puedes sustituirlo sin tocar el almacenamiento ni la capa de cómputo. Eso es lo que significa no tener vendor lock-in: no es solo que el software sea open source, sino que la arquitectura tiene separación de responsabilidades real.
Componente
Función en la factoría
Alternativas viables
Gobernanza
Ceph
Almacenamiento de modelos y datos
IBM Storage Scale (GPFS)
Linux Foundation
OpenStack
Cloud privado con gestión GPU
MaaS + bare metal directo
OpenInfra / LF
Kubernetes
Orquestación de contenedores
MicroK8s, OpenShift
CNCF / LF
vLLM
Motor de inferencia LLM
Triton, TensorRT-LLM
Apache 2.0
Ubuntu / Canonical
OS base + soporte del stack
RHEL, SUSE
Canonical Partner
¿Sirve para mi empresa?
Quién necesita una factoría de IA on-premise
No todos los sectores tienen la misma urgencia ni las mismas restricciones. Hay cuatro ámbitos donde la infraestructura propia no es una opción: es la única respuesta posible.
🏥
Sanidad y farmacéutica
Historiales clínicos, imágenes diagnósticas, datos genómicos. El RGPD y el Reglamento de Datos Sanitarios de la UE prohíben transferencias a terceros países sin salvaguardias explícitas. La inferencia on-premise es la arquitectura de cumplimiento por defecto. Ceph para IA y HPC ofrece el almacenamiento masivo que estos entornos necesitan.
🏦
Banca y seguros
Scoring crediticio, detección de fraude, análisis de riesgo. Las directrices de la EBA sobre uso de IA en servicios financieros y el EU AI Act clasifican estos sistemas como de alto riesgo, con requisitos de trazabilidad y control que solo se cumplen on-premise.
🏛️
Sector público y defensa
Soberanía tecnológica, ENS, datos clasificados. La Estrategia Nacional de Inteligencia Artificial de España exige que los sistemas de IA de uso público se operen sobre infraestructura europea o nacional. Sin discusión posible.
🏭
Industria y manufactura
Visión artificial en línea de producción, mantenimiento predictivo, control de calidad. La latencia de cloud no es viable cuando necesitas respuesta en milisegundos en la planta. La inferencia edge o datacenter propio es el único modelo que funciona.
FAQ
Las preguntas que hay que responder antes de empezar
Montar una factoría de IA on-premise no es un proyecto de fin de semana. Requiere análisis previo honesto sobre cuatro dimensiones que determinan si tiene sentido y cómo hacerlo bien.
¿Qué modelos vas a servir y cuántas peticiones?
El dimensionamiento de GPU depende directamente del tamaño de los modelos (número de parámetros y precisión) y del throughput objetivo (peticiones por segundo, latencia P99 aceptable). Un modelo de 7B parámetros en float16 cabe en una GPU L40S de 48 GB. Un modelo de 70B necesita varias GPUs con tensor parallelism. No hay atajos aquí: el dimensionamiento correcto requiere conocer las cargas reales, no estimaciones optimistas.
¿Tiene tu equipo la capacidad para operar este stack?
La pregunta más importante y la que menos se hace. Un equipo con experiencia en Linux, Kubernetes y sistemas distribuidos puede aprender a operar este stack. Pero si partes de cero, la curva de aprendizaje tiene que estar dentro del plan, no fuera. En SIXE ofrecemos formación certificada en Ceph, OpenStack y Kubernetes (como IBM BP y Canonical Partner) precisamente para que la transición no dependa de consultoría indefinida.
¿Cuál es el TCO real a 3 años?
El software es open source, así que no hay coste de licencias. La inversión es hardware (GPUs, servidores, networking de alta velocidad) más la formación del equipo. Comparado con el coste de GPU en cloud a ese mismo volumen de inferencia, los números suelen hablar solos. Pero el modelo financiero tiene que incluir mantenimiento, actualizaciones y el tiempo de operación del equipo. Nada es gratis, y los proyectos que parten de esa premisa acaban teniendo sorpresas desagradables.
Cómo trabajamos en SIXEAntes de cualquier despliegue, hacemos una evaluación de arquitectura donde auditamos tus cargas de trabajo reales, requisitos de latencia, volumen de datos y obligaciones regulatorias. Entregamos un diseño completo: dimensionamiento GPU, topología de red, almacenamiento Ceph y plan de capacidad a 12–24 meses. Sin humo, sin promesas de ahorro que no hemos calculado. Solo un análisis técnico sobre si tiene sentido y cómo ejecutarlo.
¿Tienes un proyecto de inferencia de IA?
Tu factoría de IA, con el stack que usamos nosotros
IBM Business Partner y Canonical Partner. Más de 15 años desplegando open source en producción. Diseñamos la arquitectura, formamos a tu equipo y te acompañamos hasta que la infraestructura funciona sola. Nuestro trabajo termina cuando el tuyo empieza de verdad.
En SIXE, priorizamos tu comodidad y seguridad. Estas tecnologías nos ayudan a optimizar nuestros servicios, personalizar contenidos y ofrecerte soluciones adaptadas a lo que realmente necesitas. Tu privacidad es importante: siempre estarás al mando de lo que compartes con nosotros.
Funcional
Siempre activo
El almacenamiento o acceso técnico es estrictamente necesario para el propósito legítimo de permitir el uso de un servicio específico explícitamente solicitado por el abonado o usuario, o con el único propósito de llevar a cabo la transmisión de una comunicación a través de una red de comunicaciones electrónicas.
Preferencias
El almacenamiento o acceso técnico es necesario para la finalidad legítima de almacenar preferencias no solicitadas por el abonado o usuario.
Estadísticas
El almacenamiento o acceso técnico que es utilizado exclusivamente con fines estadísticos.El almacenamiento o acceso técnico que se utiliza exclusivamente con fines estadísticos anónimos. Sin un requerimiento, el cumplimiento voluntario por parte de tu Proveedor de servicios de Internet, o los registros adicionales de un tercero, la información almacenada o recuperada sólo para este propósito no se puede utilizar para identificarte.
Marketing
El almacenamiento o acceso técnico es necesario para crear perfiles de usuario para enviar publicidad, o para rastrear al usuario en una web o en varias web con fines de marketing similares.
