Noticias

Nuevo IBM FlashSystem 2026 | 5600, 7600 y 9600

10 febrero, 2026/en Noticias

📑 Contenido del artículo

Qué trae IBM y por qué es el mayor lanzamiento en seis años
Los tres modelos: 5600, 7600 y 9600
FlashCore Module 5: QLC que rinde como TLC (y por qué eso importa)
FlashSystem.ai: IA agéntica en la cabina, con sus luces y sus sombras
Detección de ransomware en 60 segundos: los datos y los asteriscos
El argumento que no sale en los datasheets: la cadena de suministro
Pure Storage, Dell, NetApp… ¿Ahora qué?
¿Para quién tiene sentido?
Conclusiones

IBM acaba de presentar en Varsovia la nueva generación de IBM FlashSystem. Tres modelos nuevos (5600, 7600 y 9600), un motor de IA integrado llamado FlashSystem.ai, la quinta generación de su unidad flash propietaria y un mensaje que suena muy bien en un keynote: “almacenamiento autónomo co-dirigido por IA agéntica”.

Trabajamos con las cabinas FlashSystem a diario. Pero precisamente por eso creemos que merece un análisis de verdad ;) Así que vamos a desgranar qué hay detrás de cada cifra y dónde está el valor real.

Qué trae IBM y por qué es el mayor lanzamiento en seis años

IBM no exagera cuando dice que este es su lanzamiento más importante desde 2020. No es un refresh cosmético: son tres cabinas simultáneas, un rediseño completo de la unidad flash y una capa de IA que va mucho más allá de lo que tenía la generación anterior.

La idea de fondo es que la cabina de almacenamiento deje de ser un “armario que guarda datos” y se convierta en un sistema que analiza, optimiza y se protege de forma autónoma.

Sam Werner, GM de IBM Storage, fue bastante claro durante la presentación: no se trata de reemplazar al administrador, sino de que deje de pasarse el día haciendo tareas repetitivas y pueda dedicar tiempo a arquitectura y planificación.

¿Suena a slide de keynote? Un poco. Pero los números de hardware que hay detrás son reales y, en algunos casos, genuinamente impresionantes.

Los tres modelos de FlashSystem de 2026: FlashSystem 5600, 7600 y 9600

La nueva línea sustituye a los FlashSystem 5300, 7300 y 9500 con mejoras sustanciales en capacidad, densidad y eficiencia. Los tres modelos estrenan formato de unidades NVMe EDSFF (Enterprise and Data Center SSD Form Factor), que es el estándar de la industria para máxima densidad y refrigeración en entornos de CPD:

	FlashSystem 5600	FlashSystem 7600	FlashSystem 9600
Factor de forma	1U · 12 drives	2U · 32 drives	2U · 32 drives (antes 4U)
CPU	2×12 Core Intel Xeon · PCIe Gen 4	2×16 Core AMD EPYC · PCIe Gen 5	2×48 Core AMD EPYC · PCIe Gen 5
Capacidad raw	633 TB	1,68 PB	3,37 PB (vs 1,8 PB del 9500)
Capacidad usable	400 TBu	1,2 PBu	2,4 PBu
Capacidad efectiva	Hasta 2,4 PBe	Hasta 7,2 PBe	Hasta 11,8 PBe
IOPS	2,6 millones	4,3 millones	6,3 millones
Read BW	30 GB/s	55 GB/s	86 GB/s (vs 100 GB/s del 9500)
Puertos	16× FC o 20× Ethernet	32× FC o Ethernet	32× FC o Ethernet (vs 48 del 9500)
Caso de uso	Edge, ROBO, CPDs pequeños	Virtualización, analíticas	Banca, ERP, cargas IA

Un salto generacional interesante: el 7600 y el 9600 usan AMD EPYC con PCIe Gen 5, mientras que el 5600 se queda con Intel Xeon y PCIe Gen 4. Tiene sentido por segmento — PCIe Gen 5 duplica el ancho de banda por lane, pero para el caso de uso edge del 5600, Gen 4 es más que suficiente y probablemente ayuda a mantener el precio contenido.

El dato que más llama la atención es el FlashSystem 5600 metiendo 2,4 PBe en 1U. Para entornos edge o centros de datos con limitaciones de espacio, esto cambia la ecuación. Y el 9600 pasa de 4U a 2U casi duplicando la capacidad raw (de 1,8 PB a 3,37 PB). Eso es progreso real, no marketing.

Eso sí, un matiz importante: las capacidades “efectivas” (PBe) asumen ratios de deduplicación y compresión que dependen enormemente del tipo de datos. Con datos ya comprimidos o cifrados, esos 11,8 PBe del 9600 se quedan en sus 2,4 PBu (usables) o 3,37 PB raw. Es física, no magia. IBM lo especifica en las notas al pie, pero conviene tenerlo muy presente.

Otro dato interesante que ha pasado bastante desapercibido: el 9600 baja de 48 a 32 puertos de I/O y su ancho de banda máximo de lectura pasa de 100 GB/s a 86 GB/s respecto al 9500. Es un tradeoff de diseño: más densidad a costa de algo de conectividad bruta. Dependiendo de tu arquitectura, esto puede importar o no, pero conviene saberlo.

Los modelos 7600 y 9600 incorporan biseles LED interactivos para visualizar el estado del sistema. Parece un detalle menor, pero cualquier admin que haya identificado un chasis a las 3 de la madrugada en un CPD lo va a agradecer.

Familia nuevo IBM FlashSystem 2026 modelos 5600 7600 9600 vista frontal con biseles LED

Nuevos IBM FlashSystem 2026 modelos 5600 7600 9600

FlashCore Module 5: QLC que rinde como TLC (y por qué eso importa)

Aquí es donde IBM tiene una ventaja competitiva que no es humo: diseñan y fabrican sus propias unidades flash. Y esto en el nuevo FlashCore Module de quinta generación (FCM5) se traduce en algo muy concreto.

El FCM5 ofrece capacidades de 6,6 / 13,2 / 26,4 / 52,8 y 105,6 TB en el nuevo formato NVMe EDSFF. Esa última cifra, 105 TB por unidad, es la más alta de la industria para cargas de trabajo enterprise. ¿Cómo lo consiguen? Usando NAND QLC con IP propietaria que rinde como TLC.

Para los que no vivan el día a día del almacenamiento: QLC (Quad-Level Cell) es más denso y barato que TLC (Triple-Level Cell), pero normalmente tiene menor resistencia a escritura y peor rendimiento. Los competidores que usan QLC estándar la limitan a cargas de lectura intensiva. IBM, al controlar el diseño de la unidad de principio a fin, ha conseguido superar esa limitación. De hecho, según las propias cifras de IBM, los FCM consiguen 5,5 veces más ciclos de escritura que las unidades QLC estándar de la industria.

Alistair Symon, VP de desarrollo de sistemas de almacenamiento, lo explicó durante el briefing previo al lanzamiento: otros fabricantes ofrecen unidades QLC de mayor capacidad, pero al ser QLC estándar, no soportan cargas de escritura intensiva durante la vida útil de depreciación del hardware. Los FCM5 de IBM sí.

¿Qué más integra el FCM5 directamente en el hardware?

Cifrado quantum-safe para todos los datos, directamente en la unidad
Compresión por hardware
Deduplicación en la propia unidad (novedad de esta generación), habilitando ratios de reducción 5:1
Análisis de E/S acelerado por hardware: estadísticas complejas en cada operación sin impactar rendimiento

Al descargar estas operaciones al módulo flash en lugar de hacerlas en los controladores de la cabina, IBM libera capacidad de procesamiento para las cargas de trabajo del cliente. Es la misma filosofía que aplicaron con las generaciones anteriores de FCM para la detección de anomalías, pero llevada un paso más allá con la deduplicación integrada.

FlashSystem.ai: IA agéntica en la cabina, con sus luces y sus sombras

FlashSystem.ai es la nueva capa de servicios de datos con IA agéntica (nosotros también implementamos agentes en de ia en empresas por cierto, jeje). Según IBM, está entrenada con decenas de miles de millones de puntos de telemetría y años de datos operativos reales. El sistema ejecuta miles de decisiones automatizadas al día que antes requerían supervisión humana.

Las capacidades que más interesan:

Se adapta al comportamiento de las aplicaciones en horas, no en semanas como los sistemas basados en plantillas
Recomienda optimizaciones de rendimiento explicando su razonamiento (esto permite auditar las decisiones de la IA, algo crucial para compliance)
Incorpora feedback del administrador para refinar recomendaciones con el tiempo
Ubicación inteligente de cargas de trabajo con movilidad de datos no disruptiva, incluyendo cabinas de terceros
Reduce a la mitad el tiempo de documentación para auditorías y cumplimiento

Y por supuesto, el dato estrella: reducción del 90% del esfuerzo manual de gestión. Es un número espectacular, pero viene con una nota al pie que merece leerse con cariño. IBM lo mide comparando tareas rutinarias específicas (provisionamiento de volúmenes con políticas de copia protegida y DR) en la nueva generación con FlashSystem.ai vs. la misma generación sin FlashSystem.ai. Es una comparación interna, en laboratorio, sobre operaciones seleccionadas.

¿Significa que el 90% es inventado? No. Significa que es el mejor escenario en tareas concretas. En la operativa real, con sus integraciones, sus peculiaridades y la entropía natural de cualquier infraestructura, el beneficio será menor. Probablemente seguirá siendo significativo — la automatización de tareas repetitivas aporta valor real — pero no esperéis que vuestro admin de storage de repente trabaje un día a la semana.

Hay algo que sí nos parece genuinamente útil: el razonamiento operativo explicable. Que el sistema no solo haga cosas, sino que explique por qué las hace. Para auditorías y compliance (que cada vez pesan más en sectores regulados), tener un log generado por IA de las decisiones operativas es una ventaja real frente a la competencia.

Detección de ransomware en 60 segundos: los datos y los asteriscos

Otro de los datos llamativos: el FCM5 detecta ransomware en menos de un minuto. Vamos a mirarlo con lupa.

El sistema analiza cada operación de E/S directamente en el hardware, buscando patrones anómalos asociados a cifrado malicioso. El modelo de detección (versión 3.3, lanzado en Q4 2025) acumula 24 meses de entrenamiento con telemetría de producción y mantiene una tasa de falsos positivos por debajo del 1%, medida durante 3 meses.

Combinado con Safeguarded Copy (copias con air gap lógico, inmutables y ocultas a cualquier conexión externa), IBM afirma que es posible recuperarse de un ataque en menos de un minuto.

Ahora bien, los asteriscos que IBM pone al pie:

La prueba original de detección sub-minuto se hizo en un FlashSystem 5200 (generación anterior) con un simulador de ransomware propio de IBM llamado WannaLaugh. Sí, se llama así. Puntos extra por el naming.
La detección es sobre el inicio del proceso de cifrado, no sobre la intrusión en el sistema.
Un ransomware suficientemente sofisticado que cifre lentamente y mimetice patrones normales de escritura podría evadir la detección

Dicho esto — y esto es importante — tener detección a nivel de hardware con menos del 1% de falsos positivos es objetivamente bueno. La mayoría de soluciones de detección de ransomware del mercado operan a nivel de sistema de archivos o red, con latencias mayores y tasas de error superiores. IBM opera una capa más abajo, directamente en el I/O del almacenamiento. Como capa adicional en una estrategia de seguridad por capas, aporta un valor real que la competencia no puede replicar fácilmente porque no controla el hardware de sus unidades flash.

El argumento que no sale en los datasheets: la cadena de suministro

Un ángulo que puede ser más relevante que cualquier benchmark para muchos responsables de TI en 2026: la crisis de suministro de almacenamiento. La demanda de capacidad para entrenamiento de modelos de IA está generando escasez y subidas de precios en SSDs a nivel global.

Werner fue directo al respecto: IBM está mejor posicionada que la mayoría de competidores porque fabrica sus propias unidades flash.

Si estás planificando una expansión de capacidad para los próximos 12-18 meses y te encuentras con lead times de 6 meses en SSDs estándar, tener un proveedor que controla la fabricación de sus unidades es un argumento que no aparece en ningún comparador de Gartner pero que puede definir un proyecto.

Pure Storage, Dell, NetApp y el resto, ¿ahora qué?

El mercado de cabinas all-flash enterprise está reñido. Comparemos lo que realmente diferencia al nuevo FlashSystem del resto:

Aspecto	IBM FlashSystem (nuevo)	Pure Storage FlashArray	Dell PowerStore	NetApp AFF
Unidades propietarias	✅ FlashCore Module (QLC→TLC)	✅ DirectFlash (150 TB)	❌ SSDs estándar	❌ SSDs estándar
IA en gestión	FlashSystem.ai (agéntica)	Pure1 Meta	CloudIQ	BlueXP / AIOps
Detección ransomware HW	✅ En la unidad flash	❌ Software	❌ Software	❌ Software (ONTAP)
Soporte cabinas 3ros	✅ +500 vendors	❌ Ecosistema cerrado	Parcial	Parcial (FabricPool)
Cifrado quantum-safe HW	✅	❌	❌	❌
Modelo de licenciamiento	Tradicional IBM	Evergreen (muy transparente)	APEX / tradicional	Keystone / tradicional

Donde IBM gana terreno claramente:

El FlashCore Module es una ventaja real y difícil de replicar. Controlar el diseño de la unidad flash permite integrar funcionalidades a nivel de hardware (detección de ransomware, cifrado quantum-safe, deduplicación) que la competencia solo puede hacer en software. Pure Storage también diseña sus propias unidades (DirectFlash), pero a día de hoy no integra detección de ransomware ni cifrado post-cuántico en el hardware.

La compatibilidad con más de 500 vendors de almacenamiento de terceros a través de FlashSystem Grid es una jugada inteligente. En la vida real nadie tiene un entorno homogéneo, y poder mover datos de forma no disruptiva entre cabinas IBM y de otros fabricantes resuelve un problema real de consolidación y migración.

Donde la competencia aprieta:

Pure Storage tiene una experiencia de usuario consistentemente mejor valorada y su modelo Evergreen es difícil de superar en transparencia de licenciamiento. Si el precio y la simplicidad de contratación son tus prioridades, Pure sigue siendo un rival formidable.
NetApp cuenta con ONTAP, un sistema operativo de almacenamiento con una madurez brutal en entornos híbridos y una base instalada enorme. Para quien ya está en el ecosistema NetApp, migrar es difícil de justificar solo por features nuevas.
Dell PowerStore compite bien en precio y tiene una integración profunda con el ecosistema VMware (ahora Broadcom), que sigue siendo el hipervisor dominante en muchas organizaciones.

En resumen: IBM no llega a barrer a la competencia, pero con esta generación sí se posiciona con argumentos técnicos sólidos que van más allá del marketing, especialmente en seguridad a nivel de hardware y en flexibilidad multivendor.

FlashCore Module 5 de IBM

¿Para quién tiene sentido?

Después de digerir toda la información, los escenarios donde el nuevo FlashSystem encaja mejor:

Entornos de misión crítica (banca, seguros, sanidad) donde la combinación de detección de ransomware por hardware, Safeguarded Copy y cifrado quantum-safe aporta capas de seguridad que la competencia no iguala al mismo nivel.
Organizaciones con infraestructura heterogénea que necesitan consolidar sin hacer un rip-and-replace total. La compatibilidad con +500 vendors y la movilidad de datos entre cabinas es un argumento genuino.
CPDs con limitaciones de espacio donde la densidad del 5600 (2,4 PBe en 1U) puede evitar ampliaciones físicas.
Empresas que ya trabajan con infraestructura IBM Storage y buscan una evolución natural que se integre con sus inversiones existentes, especialmente si combinan con SVC u otras soluciones del portfolio.

¿Y quién debería pensárselo dos veces? Si tu entorno es 100% virtualizado con VMware y toda tu gestión pasa por vCenter, la integración con Dell puede tener más sentido operativo. Si tu prioridad es simplicidad de contratación y tu equipo es pequeño, el modelo Evergreen de Pure Storage es difícil de batir.

Conclusiones

IBM ha hecho los deberes con este lanzamiento. La combinación de hardware propietario (FCM5 con QLC que rinde como TLC), IA agéntica integrada (FlashSystem.ai) y la estrategia de compatibilidad multivendor posiciona al nuevo FlashSystem como una propuesta seria.

¿Es perfecto? No. El marketing infla algunos números (como hacen todos, no nos engañemos), la etiqueta de “almacenamiento autónomo” es más aspiracional que descriptiva, y hasta que no veamos benchmarks independientes y experiencias de campo con meses de operación, ciertos claims quedan como promesas.

Pero si ponemos todo en una balanza: la tecnología es sólida, la arquitectura tiene sentido, la dirección es la correcta. Y el hecho de que IBM controle desde el diseño de la unidad flash hasta la capa de IA pasando por el sistema operativo SVC le da una coherencia de stack que no muchos fabricantes pueden ofrecer.

Disponibilidad general: 6 de marzo de 2026.

¿Estás evaluando el nuevo IBM FlashSystem o planificando una migración?

En SIXE llevamos años trabajando con cabinas IBM FlashSystem en entornos de producción reales. Diseñamos, implantamos, migramos y damos soporte técnico de IBM Storage sin intermediarios. Si necesitas asesoramiento sobre cómo encajaría esta nueva generación en tu infraestructura, estaremos encantados de echar un cable.

Ceph vs MinIO 2026 | Guía de almacenamiento distribuido

30 enero, 2026/en Noticias

📑 Contenido del artículo

El drama del año: MinIO pasa a “modo mantenimiento”
Mientras tanto, Ceph sigue nadando tranquilo
↳ Los números que importan
El ecosistema enterprise: entendiendo qué estás comprando
↳ IBM Fusion: dos sabores para diferentes necesidades
↳ Red Hat Ceph Storage: el estándar enterprise
↳ SUSE: una lección sobre dependencia de vendors
↳ Pure Storage y NetApp: el enfoque appliance
La pregunta que nadie hace: ¿qué estás comprando realmente?
Desmitificando los claims de marketing
La jugada inteligente: decidir con información
¿Dónde conseguir ese conocimiento?
Conclusiones para 2026

Otro año más vivo, otro año más viendo cómo la industria del almacenamiento distribuido consigue superarse a sí misma en creatividad comercial. Si 2024 fue el año en que todos descubrieron que necesitaban “almacenamiento para IA” (spoiler: es el mismo almacenamiento de siempre, pero con mejor marketing), 2025 ha sido el año en que MinIO decidió inmolarse públicamente mientras el resto del ecosistema sigue evolucionando a buen ritmo.

Agarraos, que vienen curvas.

El drama del año: MinIO pasa a “modo mantenimiento” (léase: modo abandono)

Si no habéis seguido la telenovela de MinIO, dejadme que os ponga en contexto. MinIO era el object storage open source que todo el mundo desplegaba. Sencillo, rápido, compatible con S3. Lo tenías funcionando en 15 minutos. Era el WordPress del almacenamiento de objetos.

Pues bien, en diciembre de 2025, un commit silencioso en el README cambió todo: “This project is currently under maintenance and is not accepting new changes.” Sin comunicado. Sin guía de migración. Sin despedida. Solo un commit y adiós muy buenas.

La comunidad, como era de esperar, ardió. Un desarrollador lo resumió perfectamente: “A silent README update just ended the era of MinIO as the default open-source S3 engine.”

Pero esto no vino de la nada. MinIO llevaba años con una estrategia de “open source pero no te pases”:

2021: Cambio silencioso de Apache 2.0 a AGPL v3 (sin anuncio, sin PR, sin nada)
2022-2023: Campañas agresivas contra Nutanix y Weka por “violaciones de licencia”
Febrero 2025: Eliminan la consola web, gestión de buckets y replicación de la versión Community
Octubre 2025: Dejan de distribuir imágenes Docker
Diciembre 2025: Modo mantenimiento

El mensaje es claro: si quieres MinIO de verdad, paga. Su producto enterprise AIStor empieza en 96.000€/año para 400 TiB. Para 1 PB, hablamos de más de 244.000€/año.

¿La lección? En 2025, “Open Source” sin Gobernanza Abierta no vale nada. MinIO era una empresa con un producto open source, no un proyecto de comunidad. La diferencia importa.

Mientras tanto, Ceph sigue nadando tranquilo

Mientras MinIO se autodestruía, Ceph celebraba su vigésima release estable: Tentacle (v20.2.0), lanzada en noviembre de 2025. El proyecto acumula más de 1 exabyte de almacenamiento desplegado globalmente en más de 3.000 clusters.

Lo más interesante de Tentacle es FastEC (Fast Erasure Coding), que mejora el rendimiento de lecturas y escrituras pequeñas entre 2x y 3x. Esto hace que erasure coding sea finalmente viable para cargas de trabajo que no son puro archivo frío. Con un perfil EC 6+2, ahora puedes conseguir aproximadamente el 50% del rendimiento de réplica 3 mientras usas solo el 33% del espacio.

Para los que llevamos años oyendo “erasure coding es lento para producción”, esto es un cambio de juego real.

Otras novedades de Tentacle:

Soporte SMB integrado via Samba Manager
Grupos de gateway NVMe/TCP con soporte multi-namespace
Autenticación OAuth 2.0 en el dashboard
Directorios CephFS case-insensitive (por fin)
ISA-L reemplaza a Jerasure (que estaba abandonado)

El Crimson OSD (basado en Seastar para optimización NVMe) sigue en technical preview. No está listo para producción, pero el roadmap es prometedor.

Los números que importan

Bloomberg opera más de 100 PB en clusters Ceph. Son Diamond member de la Ceph Foundation y su Head of Storage Engineering está en el Governing Board. DigitalOcean tiene 54+ PB en 37 clusters de producción. CERN mantiene 50+ PB en más de 10 clusters.

Y aquí viene lo interesante: ZTE Corporation está entre los top 3 contribuidores globales a Ceph y el número 1 en China. Su producto TECS CloveStorage (basado en Ceph) está desplegado en más de 320 proyectos NFV en todo el mundo, incluyendo China Mobile, izzi Telecom (México) y Deutsche Telekom.

El sector telco es el superpoder secreto de Ceph. Mientras muchos siguen pensando en appliances tradicionales, las telecos están corriendo Ceph en producción a escala masiva.

El ecosistema enterprise: entendiendo qué estás comprando

Aquí es donde la cosa se pone interesante. Y merece la pena entender bien qué hay detrás de cada opción.

IBM Fusion: dos sabores para diferentes necesidades

IBM tiene dos productos bajo la marca Fusion, y es importante entender la diferencia:

IBM Fusion HCI: Usa IBM Storage Scale ECE (el antiguo GPFS/Spectrum Scale). Sistema de ficheros paralelo con erasure coding distribuido. Appliance hiperconvergente que escala de 6 a 20 nodos.
IBM Fusion SDS: Usa OpenShift Data Foundation (ODF), que está basado en Ceph empaquetado por Red Hat.

Storage Scale es una tecnología genuinamente diferenciada, especialmente para HPC. Su arquitectura de sistema de ficheros paralelo ofrece capacidades que Ceph simplemente no tiene: gestión avanzada de metadatos, tiering integrado, AFM para federación… Si tienes cargas de trabajo de computación de alto rendimiento, supercomputación o IA a escala seria, Storage Scale tiene argumentos técnicos sólidos que lo justifican.

Los claims de rendimiento de IBM Fusion HCI son impresionantes: aceleración 90x en queries S3 con caching local, rendimiento equivalente a Databricks Photon al 60% del coste, etc.

Ahora bien, siempre merece la pena preguntarse: ¿cuánto de ese rendimiento es la tecnología propietaria y cuánto es simplemente hardware bien dimensionado con una configuración adecuada? No es una crítica, es una pregunta legítima que cualquier arquitecto debería hacerse antes de tomar una decisión.

En el caso de Fusion SDS, estás comprando Ceph con el valor añadido del empaquetado, la integración con OpenShift, y el soporte enterprise de IBM. Para muchas organizaciones, eso tiene un valor real.

Red Hat Ceph Storage: el estándar enterprise

Red Hat Ceph Storage sigue siendo la distribución enterprise de referencia. Ofrecen 36 meses de soporte de producción más 24 meses opcionales de soporte extendido. El producto está sólido y bien integrado.

Lo que estás comprando realmente es:

Paquetes testeados y certificados
Soporte enterprise 24/7
Ciclos de vida predecibles
Integración con OpenShift

¿Vale la pena? Depende de tu contexto. Si tu organización necesita un contrato de soporte para cumplir con compliance o simplemente para dormir tranquila, probablemente sí. Y nosotros encantados de ayudarte con ello. Pero si tienes el equipo técnico para operar Ceph upstream, es una decisión que merece análisis.

SUSE: una lección sobre dependencia de vendors

Aquí hay una historia que merece reflexión: SUSE abandonó completamente el mercado de Ceph enterprise. Su producto SUSE Enterprise Storage (SES) llegó a fin de soporte en enero de 2023. Tras adquirir Rancher Labs en 2020, pivotaron hacia Longhorn para almacenamiento Kubernetes-nativo.

Si eras cliente de SES, te encontraste huérfano. Tus opciones fueron migrar a Red Hat Ceph Storage, Canonical Charmed Ceph, community Ceph, o buscar un partner especializado que te ayudara con la transición.

No es una crítica a SUSE; las empresas pivotan según su estrategia. Pero es un recordatorio de que el control sobre tu infraestructura tiene un valor que no siempre aparece en el TCO.

Pure Storage y NetApp: el enfoque appliance

Pure Storage ha creado una categoría llamada “Unified Fast File and Object” (UFFO) con su familia FlashBlade. Hardware impresionante, rendimiento consistente, experiencia de usuario pulida. Su FlashBlade//S R2 escala hasta 60 PB por cluster con DirectFlash Modules de 150 TB.

NetApp StorageGRID 12.0 se enfoca en IA con mejoras de throughput de 20x via caching avanzado y soporte para más de 600 mil millones de objetos en un solo cluster.

Ambas son soluciones sólidas que compiten con Ceph RGW en object storage compatible con S3. El rendimiento es excelente. La pregunta que cada organización debe hacerse es si el premium justifica la dependencia del vendor para su caso de uso específico.

La pregunta que nadie hace: ¿qué estás comprando realmente?

Aquí es donde me pongo el sombrero de ingeniero reflexivo.

Ceph upstream es extremadamente estable. Lleva 20 releases. La Ceph Foundation incluye a IBM, Red Hat, Bloomberg, DigitalOcean, OVHcloud y decenas más. El desarrollo está activo, la comunidad es sólida, y la documentación es extensa.

Entonces, ¿cuándo tiene sentido pagar por una distribución enterprise y cuándo no?

Tiene sentido cuando:

Tu organización requiere un contrato de soporte por compliance o política interna
No tienes el personal técnico para operar Ceph y no quieres desarrollarlo
Necesitas ciclos de actualización predecibles y testeados
El coste del downtime es mayor que el coste de la licencia
Necesitas integración específica con otros productos del vendor

Merece más análisis cuando:

La decisión se basa en “es lo que hace todo el mundo”
Nadie ha evaluado realmente las alternativas
La principal razón es que “el vendor nos dijo que el open source no tiene soporte”
Tienes equipo técnico capaz pero no se ha invertido en su formación

El desafío real es el conocimiento. Ceph tiene una curva de aprendizaje pronunciada. Diseñar un cluster correctamente, entender CRUSH maps, tunear BlueStore, optimizar placement groups… esto requiere formación seria y experiencia práctica.

Pero una vez que tienes ese conocimiento, tienes opciones. Puedes elegir un vendor enterprise con criterio, sabiendo exactamente qué valor añadido estás comprando. O puedes operar upstream con soporte especializado. La clave es que la decisión sea informada.

Desmitificando los claims de marketing

Una cosa que siempre recomiendo es leer los benchmarks y claims de marketing con espíritu crítico constructivo.

“Nuestro producto es 90x más rápido” — ¿Comparado con qué baseline? ¿En qué workload específico? ¿Con qué configuración del competidor?

“Rendimiento equivalente a [competidor] al 60% del coste” — ¿Incluye el TCO completo? ¿Licenciamiento, soporte, formación, personal?

“Solución certificada enterprise-grade” — ¿Qué significa eso exactamente? Porque Ceph upstream también es “enterprise-grade” en CERN, Bloomberg, y cientos de telecos.

No digo que los claims sean falsos. Digo que el contexto importa. La realidad es que el rendimiento de almacenamiento distribuido depende enormemente de:

Diseño correcto del cluster (failure domains, placement groups)
Hardware apropiado (red 25/100GbE, NVMe con protección power-loss)
Configuración del sistema operativo (IOMMU, CPU governors)
Tuning específico del workload (osd_memory_target, bluestore settings)

Un cluster Ceph bien diseñado y operado por gente con experiencia puede alcanzar rendimientos impresionantes. El benchmark de Clyso alcanzó 1 TiB/s con 68 servidores Dell PowerEdge. IBM demostró más de 450.000 IOPS en un cluster Ceph de 4 nodos con 24 NVMe por nodo.

A veces, ese sello de “solución certificada” que ves en un datasheet es, en el fondo, software libre con una configuración experta, hardware bien dimensionado, y mucho testing. Lo cual tiene valor, pero conviene saberlo.

La jugada inteligente: decidir con información

Después de 15 años en este sector, mi conclusión es que no hay una respuesta única. Lo que hay son decisiones informadas.

Para algunas organizaciones, una solución enterprise empaquetada es exactamente lo que necesitan: soporte garantizado, ciclos predecibles, integración validada, y la tranquilidad de tener un vendor responsable. IBM Fusion con Storage Scale es una opción excelente para HPC. Red Hat Ceph Storage es sólido para quien quiere Ceph con respaldo enterprise.

Para otras organizaciones, Ceph upstream con soporte y formación especializada ofrece ventajas importantes:

Governance de fundación: Ceph es un proyecto de la Linux Foundation con gobierno abierto. No puede pasar lo de MinIO.
Comunidad activa: Miles de contribuidores, releases regulares, bugs corregidos rápidamente.
Flexibilidad: Es tu cluster, tu configuración. Si mañana decides cambiar de partner de soporte, no pierdes nada.
TCO transparente: El software es gratis. Inviertes en hardware apropiado y en conocimiento.
Control de versiones: Actualizas cuando tiene sentido para ti, no cuando el vendor saca la siguiente release empaquetada.

El denominador común en ambos casos es el conocimiento. Ya sea que compres una solución enterprise o despliegues upstream, entender Ceph a fondo te permite tomar mejores decisiones, negociar mejor con vendors, y resolver problemas más rápido.

¿Dónde conseguir ese conocimiento?

Ceph es complejo. Pero habemus caminos..

La documentación oficial es extensa y ha mejorado mucho. El Ceph blog tiene deep-dives técnicos excelentes.

Cephalocon es la conferencia anual donde puedes aprender de los que operan Ceph a escala real (Bloomberg, CERN, DigitalOcean).

Formación estructurada con labs prácticos es la forma más eficiente de construir competencia real. No se aprende Ceph leyendo slides; se aprende rompiendo y arreglando clusters.

Soporte técnico L3 de gente que vive Ceph a diario te saca de los apuros cuando las cosas se complican en producción. Porque se van a complicar. En SIXE llevamos años formando equipos técnicos en Ceph y dando soporte L3 a organizaciones de todo tipo: las que operan upstream, las que usan distribuciones enterprise, y las que están evaluando opciones.

Nuestro programa de formación en Ceph cubre desde arquitectura básica hasta operaciones avanzadas con labs prácticos reales. Y si ya tienes Ceph en producción y necesitas respaldo técnico de verdad, nuestro soporte técnico especializado está diseñado exactamente para eso.

Además, acabamos de lanzar un programa de certificación con badges en Credly para que tu equipo pueda demostrar sus competencias de forma tangible. Porque en este sector, “sé Ceph” no significa lo mismo para todo el mundo.

Badge de certificación CEPH Administrator de SIXE - Nivel inicial de administración de almacenamiento Ceph

Badge de certificación CEPH Advanced Administrator de SIXE - Nivel avanzado de administración de almacenamiento Ceph

Badge de certificación CEPH Production Operations de SIXE - Nivel experto en operaciones de producción Ceph

Conclusiones para 2026

MinIO está muerto para uso serio. Busca alternativas. Ceph RGW, SeaweedFS, o incluso el fork OpenMaxIO si eres valiente.
Entiende qué estás comprando. Hay casos donde una solución enterprise empaquetada aporta valor real. Hay otros donde estás pagando principalmente por un logo y una configuración que podrías replicar.
Ceph upstream está maduro y es production-ready. Bloomberg, DigitalOcean, CERN y 320+ proyectos de telecos no pueden estar todos equivocados.
El verdadero coste del almacenamiento distribuido es el conocimiento. Invierte en formación y soporte técnico de calidad, independientemente de qué opción elijas.
El control sobre tu infraestructura tiene valor. Pregúntale a los clientes de SUSE SES cómo les fue cuando el vendor decidió pivotar.
La governance del proyecto importa tanto como la tecnología. Fundación abierta > empresa con producto open source.

El 2026 se presenta interesante. FastEC va a cambiar la ecuación de erasure coding. La integración con IA y ML va a seguir presionando por más rendimiento. Y el ecosistema de vendors va a seguir evolucionando con propuestas que merecen evaluación seria.

Tú decides.

Portar MariaDB a IBM AIX | Cómo AIX empata con Linux – Parte 2

28 enero, 2026/en Noticias

De “AIX es lento” a “AIX iguala a Linux” (si usas las herramientas adecuadas)

En la Parte 1, peleé con CMake, implementé un Thread Pool desde cero y logré una versión estable de MariaDB 11.8.5 para AIX. El servidor aguantó 1.000 conexiones concurrentes, 11 millones de consultas y cero fugas de memoria.

Entonces, lancé un benchmark de búsqueda vectorial.

AIX: 42 consultas por segundo (QPS).
Linux (mismo hardware): 971 consultas por segundo.

Veintitrés veces más lento. En idéntico hardware IBM Power S924. Misma versión de MariaDB. Mismo dataset.

Esta es la historia de cómo descubrimos que no existía tal brecha de rendimiento: solo errores de configuración y un compilador que no estaba a la altura.

Capítulo 1: Esa sensación de hundimiento

Existe un tipo particular de desesperación que sientes al ver una diferencia de rendimiento de 23x en hardware idéntico. Es ese momento en el que piensas: “quizá debería haberme hecho florista”.

Pongámonos en situación: ambas máquinas son LPARs corriendo en servidores IBM Power S924 con procesadores POWER9 a 2750 MHz. El mismo MariaDB 11.8.5. El mismo dataset de prueba: 100.000 vectores con 768 dimensiones, usando el índice MHNSW (Hierarchical Navigable Small World) de MariaDB.

La prueba era simple: encontrar los 10 vecinos más cercanos (KNN) a un vector de consulta. Es el tipo de operación que alimenta todas las funciones de búsqueda por IA (RAG) modernas.

Linux lo hizo en ~1 milisegundo.
AIX tardó 24 milisegundos.

Mi primer instinto fue la negación. “El benchmark está mal”. No lo estaba. “El índice está corrupto”. No lo estaba. “La red va lenta”. Era una conexión socket local.

Tocaba remangarse y cavar hondo.

Capítulo 2: Los primeros 65x – La configuración importa

La caché amnésica

La primera pista nos la dio el profiler de MariaDB. Cada consulta tardaba exactamente lo mismo, fuera la primera o la número cien. Las cachés no funcionan así.

Revisé la configuración MHNSW de MariaDB:

SHOW VARIABLES LIKE 'mhnsw%';

mhnsw_max_cache_size: 16777216

16 MB. Nuestro grafo vectorial necesita unos 300 MB para mantener la estructura HNSW en memoria.

Aquí está el problema: cuando la caché se llena, MariaDB no expulsa las entradas antiguas (no hay LRU). Lo tira todo y empieza de cero. En. Cada. Consulta.

Imagina una biblioteca donde, cuando las estanterías se llenan, el bibliotecario quema todos los libros y pide copias nuevas. Para cada usuario.

El arreglo: mhnsw_max_cache_size = 4GB en la configuración.

Resultado: 42 QPS → 112 QPS. Una mejora de 2.7x con una línea de configuración.

El problema del tamaño de página (Page Size)

AIX usa por defecto páginas de memoria de 4 KB. Linux en POWER usa páginas de 64 KB.

Para el patrón de acceso de MHNSW —que consiste en perseguir punteros a través de un grafo de 300 MB— esto es crítico. Con páginas de 4 KB, necesitas 16 veces más entradas en el TLB (Translation Lookaside Buffer) para mapear la misma memoria. Los fallos de TLB (TLB misses) son caros.

Piénsalo como navegar por una ciudad. Con páginas de 4 KB, necesitas instrucciones paso a paso para cada edificio. Con páginas de 64 KB, te dan instrucciones por barrios. Mucho más rápido cuando te mueves constantemente.

El arreglo: Un script wrapper que establece LDR_CNTRL=DATAPSIZE=64K@TEXTPSIZE=64K@STACKPSIZE=64K@SHMPSIZE=64K.

Resultado: 112 QPS → 208 QPS secuenciales, y 2.721 QPS con 12 workers paralelos.

Marcador tras la Fase 1

Configuración	QPS Secuencial	Con 12 workers
Base	42	~42
+ 4 GB caché	112	–
+ 64K pages	208	2.721

Mejora de 65x con dos cambios de configuración. Sin tocar código.

Pero seguíamos siendo 6 veces más lentos que Linux por núcleo. La investigación continuó.

Capítulo 3: El misterio de CPU vs. Memory Stalls

Con la configuración arreglada, saqué las herramientas de profiling. MariaDB tiene un profiler interno que desglosa el tiempo por fases.

AIX:

Sending data: 4.70ms total
  - CPU_user: 1.41ms
  - CPU_system: ~0ms
  - Stalls: 3.29ms (¡70% del total!)

Linux:

Sending data: 0.81ms total
  - CPU_user: 0.80ms
  - Stalls: ~0.01ms (1% del total)

El tiempo de CPU era 1.8x más lento en AIX (esperable por diferencias de compilador). Pero los “stalls” (paradas de memoria) eran 329 veces peores.

La causa raíz: Invalidación de caché por el Hipervisor

Tardé dos días en descubrir esto: en una LPAR compartida, el hipervisor POWER interrumpe periódicamente a los procesadores virtuales para dar tiempo a otras particiones. Cuando lo hace, puede invalidar líneas de caché L2/L3.

Recorrer un grafo MHNSW es una “persecución de punteros” a través de 300 MB de memoria: literalmente el peor escenario para la invalidación de caché. Saltas de nodo en nodo y el hipervisor te vacía la caché periódicamente.

Es como intentar leer un libro mientras alguien te lo cierra y lo devuelve a la estantería cada dos por tres.

El sistema Linux tenía procesadores dedicados. El AIX estaba en modo compartido. No estábamos comparando manzanas con manzanas.

Pero antes de probar procesadores dedicados, tenía que arreglar el problema del compilador.

Capítulo 4: La odisea del compilador

Todo lo que intenté con GCC (y por qué falló)

Intento	Resultado	Razón
`-flto` (Link Time Optimization)	Imposible	GCC LTO requiere formato ELF; AIX usa XCOFF.
`-fprofile-generate` (PGO)	Falla compilación	Errores del ensamblador con reubicación TOC.
`-ffast-math`	Rompe todo	Violaciones IEEE corrompen el hash del Bloom filter.
`-funroll-loops`	Más lento	Infla la caché de instrucciones (I-cache bloat). A POWER9 no le gusta.

El toolchain de GCC en AIX no tiene soporte LTO real. No es un flag que olvidé: es arquitecturalmente imposible porque la implementación LTO de GCC requiere ELF, y AIX usa XCOFF. Los paquetes de MariaDB en Ubuntu usan -flto=auto. Esa optimización simplemente no existe para AIX con GCC.

IBM Open XL: El giro de guion

Llevaba tres días intentando que GCC fuera más rápido. Era hora de probar algo diferente.

IBM Open XL C/C++ 17.1.3 es el compilador moderno de IBM, basado en LLVM/Clang. Genera un código significativamente mejor para POWER9 que GCC.

Compilar MariaDB con Open XL requirió resolver cinco problemas:

Falta header HTM: Open XL no tiene el htmxlintrin.h de GCC. Creé un stub.
32-bit por defecto: Las herramientas de AIX son de 32 bits. Tuve que forzar OBJECT_MODE=64.
LLVM AR incompatible: El AR de Open XL no manejaba bien XCOFF. Usé el /usr/bin/ar del sistema.
Conflictos OpenSSL: Usar -DWITH_SSL=system para evitar líos con wolfSSL.
Rutas de librerías: Flags explícitos -L/opt/freeware/lib para el linker.

Y entonces, lancé el benchmark:

Compilador	30 Consultas	Por consulta
GCC 13.3.0	0.190s	6,3 ms
Open XL 17.1.3	0.063s	2,1 ms

Tres veces más rápido. Mismo código fuente. Mismos flags de optimización (-O3 -mcpu=power9).

Y un detalle clave: la varianza con GCC era del 10-40% entre ejecuciones. Con Open XL fue menor al 2%. Una estabilidad roca.

¿Por qué tanta diferencia?

Open XL (al estar basado en LLVM) tiene:

Mejor planificación de instrucciones (instruction scheduling) para la ejecución fuera de orden (Out-of-Order) de POWER9.
Asignación de registros superior.
Pasadas de optimización más agresivas.

Capítulo 5: Los callejones sin salida de LTO y PGO

La esperanza es lo último que se pierde. ¿Quizás LTO y PGO sí funcionan en Open XL?

LTO: La ironía

Open XL soporta -flto=full en XCOFF. ¡Compila! Pero…

Resultado: 27% más lento que Open XL sin LTO.

¿Por qué? Las librerías compartidas en AIX requieren una lista explícita de exportaciones (exports.exp). El script de CMake vio ~27.000 símbolos para exportar.

La ventaja principal de LTO es la internalización de funciones (hacerlas locales para optimizarlas o hacer inlining). Cuando te obligan a exportar 27.000 símbolos, no puedes internalizar nada. Te quedas con el overhead de LTO pero sin sus ventajas.

Es como pagar el gimnasio y que te digan que no puedes usar ninguna máquina.

PGO: Los perfiles que nunca existieron

Profile Guided Optimization sonaba prometedor:

Compilar con -fprofile-generate
Ejecutar carga de entrenamiento
Recompilar con -fprofile-use

El paso 1 funcionó. El paso 2… los perfiles nunca aparecieron.

La causa raíz: El runtime de profiling de LLVM usa destructores al salir. En AIX con XCOFF, la semántica de los destructores en librerías compartidas es distinta a ELF. Simplemente, no se llaman de forma fiable en configuraciones complejas como MariaDB.

Capítulo 6: La revelación de la LPAR

Ahora tenía un compilador rápido. Toca probar procesadores dedicados y eliminar el problema de la caché del hipervisor.

La matriz de pruebas

Configuración LPAR	GCC	Open XL
12 vCPUs compartidas	0.190s	0.063s
12 dedicadas (Capped)	0.205s	0.082s
21 dedicadas (Capped)	0.320s	0.067s

Espera. ¿El modo Compartido es más rápido que el Dedicado?

El factor WoF

POWER9 tiene una función llamada Workload Optimized Frequency (WoF). En modo compartido con baja utilización, un solo núcleo puede acelerar hasta ~3.8 GHz (turbo). Los procesadores dedicados “Capped” suelen estar limitados a la frecuencia base (2750 MHz).

Para una consulta mono-hilo, el modo compartido gana un 38% extra de velocidad de reloj. Eso supera la penalización de la caché para esta carga específica.

Es como elegir entre un Ferrari en una autopista con tráfico ocasional (Compartido) vs un camión en un carril exclusivo pero con limitador de velocidad (Dedicado).

El desastre del modo Donación

Hay una tercera opción: procesadores dedicados en modo “Donación” (Donating), que ceden ciclos ociosos al pool compartido.

Modo	GCC	Open XL
Capped	0.205s	0.082s
Donating	0.325s	0.085s

Regresión del 60% con GCC.
Cada vez que llega una consulta (burst), hay una latencia para recuperar los ciclos donados. Para bases de datos, esto es devastador.

Recomendación: Nunca uses modo Donating para bases de datos.

Capítulo 7: El marcador final (el verdadero giro)

Nuevos benchmarks en hardware POWER9 idéntico, Enero 2026:

Plataforma	Núcleos	30 Consultas
Linux	24 dedicados	0.057s
AIX + Open XL	12 compartidos	0.063s
AIX + Open XL	21 dedicados	0.067s

Un momento. El sistema AIX tiene 21 núcleos vs los 24 de Linux. Eso es un 12.5% menos de núcleos (y menos caché L3).

¿La “diferencia” medida? Entre 10-18%.

Eso no es una diferencia de rendimiento de software. Es una diferencia de hardware pura y dura.

Con IBM Open XL, AIX ofrece un rendimiento por núcleo idéntico a Linux. ¿La diferencia de 23x con la que empezamos? Nunca fue culpa de AIX. Fue culpa de:

Una caché mal configurada (16MB vs 4GB).
Tamaño de página incorrecto (4 KB vs 64 KB).
El compilador equivocado (GCC vs Open XL).

El mito de “AIX es lento” ha muerto.

El Museo de los Intentos Fallidos

La ciencia no va solo de lo que funciona, sino de documentar lo que no funciona. Aquí mi muro de “buen intento”:

Qué probamos	Resultado	Notas
`mhnsw_max_cache_size = 4GB`	5x más rápido	Elimina el “thrashing” de caché.
`LDR_CNTRL` 64K pages	~40% más rápido	Reduce fallos de TLB.
IBM Open XL 17.1.3	3x más rápido	Mejor generación de código POWER9.
Open XL + LTO	27% más lento	Conflicto con exportaciones AIX.
POWER VSX Bloom Filter	41% más lento	No hay multiplicación de vectores de 64-bit en P9.
Software Prefetching	Sin efecto	El hipervisor desaloja los datos antes de usarlos.
DSCR Tuning	Bloqueado	El hipervisor controla el DSCR en LPAR compartida.

El dato del VSX es interesante: implementamos un Bloom Filter SIMD usando extensiones vectoriales de POWER. Fue un 41% más lento que el escalar. POWER9 no tiene multiplicación vectorial de 64 bits, por lo que simularla es más lento que dejar que el motor Out-of-Order maneje el bucle escalar.

Lecciones aprendidas

1. Los “defaults” los carga el diablo

Una caché por defecto de 16MB convertía consultas de 1ms en 24ms. Una penalización de 24x por un parámetro de configuración. Cuestiona siempre los valores por defecto al portar software.

2. El mito de la lentitud era un problema de Toolchain

Con GCC, éramos 3-4x más lentos que Linux. Con Open XL, igualamos a Linux. La plataforma nunca fue lenta; la cadena de herramientas por defecto (GCC en AIX) no está optimizada para alto rendimiento.

3. No todas las optimizaciones se portan

LTO, PGO y vectorización SIMD fallaron en AIX por razones arquitecturales. Lo que hace rápido a Linux no siempre se traduce directamente. Mídelo todo.

Recomendaciones para usuarios

Si usas MariaDB en AIX:

Usa la build con Open XL (versión 3, próximamente).
Configura mhnsw_max_cache_size a mínimo 4GB si usas vectores.
Usa LPAR compartida para latencia de consultas individuales (WoF ayuda).
Nunca uses modo “Donating” para BBDD.
Fuerza páginas de 64K con el wrapper LDR_CNTRL.

¿Qué sigue?

Los RPMs están publicados en aix.librepower.org. La Release 2 incluye los arreglos de configuración. La Release 3 (con Open XL) está en camino.

Para las organizaciones que ya corren cargas críticas en AIX —bancos, aseguradoras, sanidad— la opción de correr también MariaDB moderno con rendimiento nativo abre un mundo de posibilidades.

AIX iguala a Linux. El mito ha muerto. Y MariaDB en AIX está listo para producción.

TL;DR

Empezamos con un gap de 23x de rendimiento (42 QPS vs 971 QPS).
Arreglo de caché: Mejora de 5x.
Arreglo de Page Size (64K): ~40% extra.
Cambio a compilador IBM Open XL: 3x mejor que GCC.
Resultado final: GAP CERO (la diferencia del 10% corresponde a tener 12.5% menos núcleos).
“AIX es lento para Open Source” siempre fue un mito causado por usar el compilador incorrecto.

Ver Repositorio en GitLab

Portar MariaDB a IBM AIX | 3 semanas de sufrimiento – Parte 1

28 enero, 2026/en Noticias

Llevamos MariaDB a AIX (Parte 1)

Hay decisiones en la vida que tomas sabiendo perfectamente que te van a doler. Casarte. Tener hijos. Correr una maratón. Portar MariaDB 11.8 a IBM AIX.

Esta (Parte 1) es la historia de la última decisión.

“¿Tan difícil puede ser llevar MariaDB a AIX?”

Todo empezó con una pregunta inocente durante una reunión de equipo: “¿Por qué no tenemos MariaDB en nuestros sistemas AIX?”.

Esto es lo que pasa con AIX que la gente que nunca ha trabajado con él no entiende: AIX no se anda con chiquitas. Cuando los bancos necesitan un uptime de “cinco nueves” para sus sistemas core, usan AIX. Cuando las aerolíneas necesitan sistemas de reservas que no pueden fallar, usan AIX. Cuando Oracle, Informix o DB2 necesitan ofrecer un rendimiento brutal para cargas OLTP de misión crítica, corren sobre AIX.

AIX no es “trendy”. AIX no tiene una mascota cuqui. AIX no será el tema de los blogs tecnológicos sobre “disrupción”. Pero cuando las cosas no pueden fallar bajo ningún concepto, AIX está ahí, haciendo su trabajo en silencio mientras todos los demás están ocupados reiniciando sus contenedores.

Entonces, ¿por qué MariaDB no soporta oficialmente AIX? Simple economía: la comunidad Open Source se ha centrado en Linux, y la portabilidad requiere conocimientos muy específicos de la plataforma. MariaDB soporta Linux, Windows, FreeBSD, macOS y Solaris. AIX no está en la lista, no porque sea una mala plataforma, sino porque nadie había hecho el trabajo sucio todavía. Hasta que… entró LibrePower .

Mi primer error fue pensar: “Probablemente sea solo cuestión de compilar y ajustar un par de cosas”.

Lección nº 1: Cuando alguien dice “solo hay que compilarlo” refiriéndose a software en AIX, está a punto de recibir una clase magistral de humildad y programación de sistemas.

Capítulo 2: CMake y los tres invitados inesperados

El primer día de compilación fue… educativo. Usar CMake en AIX es como jugar a las cartas con alguien que tiene un reglamento totalmente diferente al tuyo y espera que adivines las reglas sobre la marcha.

El bug de la función fantasma

AIX tiene una característica curiosa: declara funciones en las cabeceras por compatibilidad, incluso cuando esas funciones no existen realmente en tiempo de ejecución. Es como si tu GPS te dijera “gira a la derecha en 200 metros” pero la calle fuera un muro de ladrillos.

CMake ejecuta un CHECK_C_SOURCE_COMPILES para comprobar si pthread_threadid_np() existe. El código compila. CMake dice “¡Genial, lo tenemos!”. El binario arranca y… BOOM. Symbol not found.

Resulta que pthread_threadid_np() es exclusivo de macOS. AIX lo declara en los headers porque… bueno, aún no lo sé. ¿Quizás por alguna oscura compatibilidad POSIX de hace décadas? Sea cual sea la razón, GCC lo compila felizmente y el linker no se queja hasta que intentas ejecutarlo.

Lo mismo ocurre con getthrid(), que es específico de OpenBSD.

La solución:

IF(NOT CMAKE_SYSTEM_NAME MATCHES "AIX")
  CHECK_C_SOURCE_COMPILES("..." HAVE_PTHREAD_THREADID_NP)
ELSE()
  SET(HAVE_PTHREAD_THREADID_NP 0)  # Trust but verify... okay, just verify
ENDIF()

poll.h: A jugar al escondice

AIX tiene <sys/poll.h>. Está ahí. Puedes hacerle un cat. Pero CMake no lo detecta.

Después de tres horas depurando un error “POLLIN undeclared” en viosocket.c, descubrí que la solución era simplemente forzar la definición a mano:

cmake ... -DHAVE_SYS_POLL_H=1

Tres horas. Por un flag.

(esto es un problema de detección de plataforma de CMake, no de AIX. Los checks de CMake asumen estructuras de directorios estilo Linux).

Los malditos plugins

Al 98% de compilación — el plugin wsrep_info explotó con símbolos indefinidos. ¿La razón? Depende de Galera. Que no estamos usando. Pero CMake intenta compilarlo de todos modos.

Lo mismo pasó con S3 (requiere símbolos Aria), Mroonga (requiere Groonga) y RocksDB (profundamente ligado a optimizaciones específicas de Linux).

Configuración final de CMake (“La poda”):

-DPLUGIN_MROONGA=NO -DPLUGIN_ROCKSDB=NO -DPLUGIN_SPIDER=NO 
-DPLUGIN_TOKUDB=NO -DPLUGIN_OQGRAPH=NO -DPLUGIN_S3=NO -DPLUGIN_WSREP_INFO=NO

Parece una amputación, pero en realidad es eliminar paja. Estos plugins son casos de uso muy específicos (edge cases) que pocas implementaciones necesitan.

Capítulo 3: Thread Pool, o cómo aprendí a dejar de preocuparme y amar el Mutex

Aquí es donde las cosas se pusieron interesantes. Y por “interesantes” quiero decir “casi me provocan un tic nervioso permanente”.

MariaDB tiene dos modos de gestión de conexiones:

one-thread-per-connection: Un hilo por cliente. Simple. Escala igual de bien que un coche subiendo una pared vertical.
pool-of-threads: Un conjunto fijo de hilos gestiona todas las conexiones. Elegante. Eficiente. Y no disponible en AIX.

¿Por qué? Porque el Thread Pool requiere APIs de multiplexación de E/S específicas de la plataforma:

Plataforma	API	Estado
Linux	epoll	Soportado
FreeBSD/macOS	kqueue	Soportado
Solaris	event ports	Soportado
Windows	IOCP	Soportado
AIX	pollset	No soportado (hasta ahora)

Así que… ¿tan difícil puede ser implementar el soporte para pollset?

El problema de ONESHOT

El epoll de Linux tiene un flag maravilloso llamado EPOLLONESHOT. Garantiza que un descriptor de fichero dispare eventos una sola vez hasta que lo vuelvas a armar explícitamente. Esto impide que dos hilos procesen la misma conexión simultáneamente.

El Pollset de AIX es level-triggered (activado por nivel). Solo por nivel. Sin opciones. Si hay datos disponibles, te avisa. Y te vuelve a avisar. Una y otra vez. Como ese compañero de trabajo “servicial” que no para de recordarte el email que aún no has contestado.

Once versiones para alcanzar la sabiduría

Lo que siguió fueron once iteraciones de código, cada una más compleja que la anterior, intentando simular el comportamiento de ONESHOT:

v1-v5 (La edad de la inocencia)
Probé a modificar los flags de eventos con PS_MOD. “Si cambio el evento a 0, dejará de saltar”, pensé. Spoiler: no dejó de saltar.

v6-v7 (La era de las máquinas de estado)
“Lo tengo! Mantendré un estado interno y filtraré los eventos duplicados”. El problema: existe una ventana de tiempo (race condition) entre que el kernel te da el evento y tú actualizas tu estado. En esa ventana, otro hilo puede recibir el mismo evento.

v8-v9 (La fase de negación)
“Pondré el estado en PENDING antes de procesar”. Funcionó… más o menos… hasta que dejó de funcionar.

v10 (Esperanza)
Por fin encontré la solución: PS_DELETE + PS_ADD. Cuando recibas un evento, borra inmediatamente el file descriptor del pollset. Cuando estés listo para más datos, vuélvelo a añadir.

// Al recibir eventos: REMOVE
for (i = 0; i < ret; i++) {
    pctl.cmd = PS_DELETE;
    pctl.fd = native_events[i].fd;
    pollset_ctl(pollfd, &pctl, 1);
}

// Cuando estemos listos: ADD
pce.command = PS_ADD;
pollset_ctl_ext(pollfd, &pce, 1);

¡Funcionó! Con compilación -O2.

Con -O3… segfault.

Se acerca la noche y sigo teniendo bugs (El Bug de -O3)

Imagínate mi cara. Tengo el código funcionando perfecto en desarrollo (`-O2`). Habilito `-O3` para las pruebas de producción y el servidor explota con “Got packets out of order” o un fallo de segmentación en CONNECT::create_thd().

Pasé dos días convencido de que era un bug del compilador. GCC 13.3.0 en AIX. Culpé al compilador. Culpé al linker. Culpé a todo el universo excepto a mi propio código.

El problema era más sutil: MariaDB tiene dos rutas de código concurrentes que llaman a io_poll_wait en el mismo pollset:

El listener bloquea con timeout=-1.
El worker llama con timeout=0 para comprobaciones no bloqueantes.

Con -O2, los tiempos eran tales que rara vez colisionaban. Con -O3, el código era más rápido, las colisiones ocurrían más a menudo, y boom: condición de carrera.

v11 (Iluminación)
La solución fue un mutex dedicado protegiendo tanto pollset_poll como todas las operaciones pollset_ctl:

static pthread_mutex_t pollset_mutex = PTHREAD_MUTEX_INITIALIZER;

int io_poll_wait(...) {
    pthread_mutex_lock(&pollset_mutex);
    ret = pollset_poll(pollfd, native_events, max_events, timeout);
    // ... procesar y borrar eventos ...
    pthread_mutex_unlock(&pollset_mutex);
}

Sí, esto serializa el acceso al pollset. Sí, teóricamente añade latencia. ¿Pero sabes qué tiene más latencia? Un servidor que se cae.

El código final de la v11 superó 72 horas de pruebas de estrés con 1.000 conexiones simultáneas. Cero caídas. Cero fugas de memoria. Cero paquetes desordenados.

Capítulo 4: La cosa del `-blibpath` (que en realidad es una feature)

Una característica genuina de AIX: tienes que especificar explícitamente la ruta de las librerías en tiempo de enlace con -Wl,-blibpath:/tu/ruta. Si no lo haces, el binario no encontrará libstdc++ aunque esté en el mismo directorio.

Al principio esto parece molesto. Luego te das cuenta: AIX prefiere rutas explícitas y deterministas a búsquedas implícitas “mágicas”. En entornos de producción crítica donde “en mi máquina funcionaba” no es una excusa válida, eso es una feature, no un bug.

Capítulo 5: Estabilidad – Los números que importan

Después de todo este sufrimiento, ¿dónde estamos realmente?

El RPM está publicado en aix.librepower.org y desplegado en un sistema IBM POWER9 (12 cores, SMT-8). MariaDB 11.8.5 corre en AIX 7.3 con el Thread Pool activado. El servidor ha superado una batería de QA brutal:

Prueba	Resultado
100 conexiones concurrentes	✓
500 conexiones concurrentes	✓
1.000 conexiones	✓
30 minutos de carga sostenida	✓
Más de 11 millones de queries	✓
Memory leaks	CERO

1.648.482.400 bytes de memoria, constantes durante 30 minutos. Ni un solo byte de deriva (drift). El servidor funcionó durante 39 minutos bajo carga continua y realizó un apagado limpio.

Funciona. Es estable. Está listo para producción.

El impacto del Thread Pool

El trabajo en el pool de hilos proporcionó ganancias masivas para cargas de trabajo concurrentes:

Configuración	100 clientes mixtos	vs. Baseline
Original `-O2` un hilo por conexión	11.34s	–
`-O3` + Thread Pool v11	1.96s	83% más rápido

Para cargas de trabajo OLTP de alta concurrencia, esta es la diferencia entre arrastrarse y volar.

Lo que he aprendido (hasta ahora)

CMake asume que eres Linux. En sistemas no-Linux, verifica manualmente la detección de características. Los falsos positivos te morderán en tiempo de ejecución.
La E/S level-triggered requiere disciplina. EPOLLONESHOT existe por una razón. Si tu sistema no lo tiene, prepárate para implementar tu propia serialización.
-O3 expone errores latentes. Si tu código “funciona con -O2 pero no con -O3”, tienes una condición de carrera. El compilador está haciendo su trabajo; el fallo es tuyo.
Los mutex son tus amigos. Sí, tienen overhead. ¿Pero sabes qué tiene más overhead? Depurar condiciones de carrera a las 3 de la mañana.
AIX premia la comprensión profunda. Es un sistema que no perdona los atajos, pero una vez entiendes sus convenciones, es predecible y robusto como una roca. Hay una razón por la que los bancos lo siguen usando.
El ecosistema importa. Proyectos como linux-compat de LibrePower hacen viable el desarrollo moderno en AIX.

¿Qué sigue? La incógnita del rendimiento

El servidor es estable. El Thread Pool funciona. Pero hay una pregunta en el aire que aún no he respondido:

¿Es rápido comparado con Linux?

Ejecuté un benchmark de búsqueda vectorial (el tipo de operación que potencia la IA moderna). Índice MHNSW de MariaDB, 100.000 vectores, 768 dimensiones.

Linux en hardware POWER9 idéntico: 971 queries por segundo.
AIX con nuestra nueva build: 42 queries por segundo.

23 veces más lento.

Se me cayó el alma a los pies. ¿Tres semanas de trabajo para ser 23 veces más lentos que Linux en el mismo hardware?

Pero esto es lo bonito de la ingeniería: cuando los números no tienen sentido, siempre hay una razón. Y a veces, esa razón resulta ser una noticia sorprendentemente buena.

En la Parte 2, os contaré:

Cómo descubrimos que la diferencia de 23x era mayormente un error de configuración.
El compilador que lo cambió todo.
Por qué “AIX es lento” resultó ser un mito.
El “Museo de los Fracasos”: optimizaciones que no sirvieron para nada.

Los RPMs están publicados en aix.librepower.org. La build GCC es funcionalmente estable.

¿Pero la historia del rendimiento? Ahí es donde la cosa se pone realmente interesante.

Pronto la Parte 2.

MariaDB 11.8.5 ahora funciona en AIX 7.3 con Thread Pool nativo.
Primera implementación de un pool de hilos para AIX usando pollset (necesité 11 iteraciones para simular ONESHOT correctamente).
El servidor es estable: 1.000 conexiones, 11M+ queries, cero memory leaks.
El Thread Pool mejora un 83% el rendimiento en cargas concurrentes.
El benchmark inicial de vectores muestra una diferencia de 23x vs Linux… pero no es lo que parece.
RPMs disponibles en aix.librepower.org

¿Preguntas? ¿Ideas? ¿Quieres contribuir al ecosistema Open Source de AIX?

Este trabajo es parte de LibrePower – Desbloqueando IBM Power a través del Open Source. RAS inigualable. TCO superior. Huella mínima 🌍

Ver Repositorio en GitLab

🦙 LLMs en AIX: experimentación técnica más allá del hype de las GPUs

12 enero, 2026/en Noticias

En LibrePower hemos publicado Llama-AIX: una prueba de concepto para ejecutar inferencia de modelos LLM ligeros directamente sobre AIX 7.x, utilizando únicamente CPU y memoria, sin GPUs.

Ver repositorio en GitLab

Conviene aclararlo desde el inicio: esto es diversión técnica y experimentación, no un producto, no una promesa comercial, ni una alternativa a grandes plataformas de IA aceleradas por GPU.

Dicho esto, hay una base técnica sólida detrás del experimento.

La teoría: no todos los casos de uso de LLM son GPU-bound

En muchos escenarios empresariales habituales en entornos Power:

RAG (Retrieval Augmented Generation)
Preguntas sobre documentación interna
Asistentes técnicos on-prem
Búsqueda semántica sobre conocimiento propio
Análisis de texto con fuerte dependencia de latencia y proximidad a los datos

el cuello de botella no siempre es el cálculo masivo, sino:

CPU
Ancho de memoria
Latencia de acceso a datos
Localización de los datos

En estos casos, inferencias pequeñas y bien acotadas pueden ejecutarse de forma razonable sin GPUs, especialmente cuando el modelo no es el centro del sistema, sino una pieza más.

⚙️ CPU, MMA y aceleradores de bajo consumo

La evolución natural no pasa únicamente por GPUs:

CPUs cada vez más vectorizadas
Extensiones como MMA
Aceleradores específicos y de bajo consumo (como el futuro Spyre)
Integración más cercana al sistema operativo y al stack de datos

Este tipo de aceleración es especialmente relevante en arquitecturas Power, donde el diseño prioriza throughput sostenido, coherencia y fiabilidad, no solo picos de FLOPS.

¿Por qué AIX?

Ejecutar esto en AIX no es una necesidad, es una elección consciente para:

Entender los límites reales
Explorar su viabilidad técnica
Desmontar supuestos simplistas
Aprender cómo encajan los LLMs en sistemas Power existentes

Muchos clientes Power operan infraestructuras estables, amortizadas y críticas, donde mover datos a la nube o introducir GPUs no siempre es deseable ni viable.

Qué es (y qué no) Llama-AIX

✔ Un PoC técnico
✔ Una exploración honesta
✔ Un ejercicio de ingeniería
✔ Open source
✖ No es un benchmark
✖ No es una plataforma IA completa
✖ No pretende competir con soluciones GPU
✖ No es “AI marketing”

La idea es sencilla: mirar más allá del hype, entender los matices y evaluar dónde los LLMs aportan valor real en entornos Power y AIX.

Por pura curiosidad técnica.

Y porque experimentar sigue siendo parte fundamental de la ingeniería.

💬 ¿En qué caso de uso concreto tendría sentido para ti un LLM on-prem en Power?

Lanzamos LibrePower (y este es su Manifiesto)

8 enero, 2026/en Noticias

Queremos liberar todo el potencial de IBM Power

Construimos comunidad para hacer crecer el ecosistema Power — más soluciones, más usuarios, más valor.

El hardware más capaz que aún no aprovechas del todo

IBM Power sostiene la computación de misión crítica en todo el mundo. Transacciones bancarias, reservas de vuelos, sistemas hospitalarios, instalaciones SAP — las cargas de trabajo que no pueden permitirse fallar corren sobre Power.

No es casualidad.

Los sistemas Power ofrecen una fiabilidad legendaria gracias a su arquitectura RAS (Reliability, Availability, Serviceability) que x86 sencillamente no puede igualar. Funcionan sin problemas durante 10, 15 años o más. Su diseño — cachés de gran tamaño, SMT8, un ancho de banda de memoria extraordinario — está pensado para mantener el rendimiento a escala de forma sostenida.

Pero hay una oportunidad que la mayoría de organizaciones están dejando pasar:

Power puede hacer mucho más de lo que se le pide habitualmente.

La capacidad está ahí. El potencial es enorme. Lo que ha faltado es validación independiente, impulso desde la comunidad y herramientas accesibles que abran la puerta a nuevos casos de uso.

Exactamente lo que LibrePower está construyendo.

¿Qué es LibrePower?

LibrePower es una iniciativa comunitaria para ampliar lo que es posible en IBM Power — en todo el ecosistema:

AIX — El Unix veterano que mueve las cargas enterprise más exigentes
IBM i — El sistema integrado sobre el que operan miles de empresas en todo el mundo
Linux on Power (ppc64le) — Ubuntu, Rocky, RHEL, SUSE, Fedora sobre arquitectura POWER

No venimos a sustituir nada. Venimos a sumar:

Más soluciones certificadas corriendo en Power
Más desarrolladores y administradores que confían en la plataforma
Más razones para invertir en Power — tanto en equipos nuevos como en los que ya tienes

Qué hacemos en LibrePower

1. LibrePower Certified — validación independiente

Los ISVs y los proyectos open source necesitan saber que su software funciona en Power. Los compradores necesitan confianza antes de desplegar. La certificación de IBM tiene su valor, pero hay espacio para una validación independiente impulsada por la comunidad.

LibrePower Certified ofrece tres niveles:

Nivel	Significado
✅ Works on Power	Compila y ejecuta correctamente en ppc64le. Validación básica.
⚡ Optimized for Power	Ajustado para SMT, VSX/MMA. Incluye datos de rendimiento.
🏆 LibrePower Certified	Validación completa + caso de estudio + soporte continuado.

Gratuito para proyectos open source. Niveles premium para ISVs que busquen una colaboración más profunda.

2. Repositorios open source

Compilamos, empaquetamos y distribuimos software que la comunidad Power necesita:

AIX (aix.librepower.org): herramientas CLI modernas, utilidades de seguridad, capas de compatibilidad
ppc64le: herramientas de contenedores (AWX, Podman), utilidades de desarrollo, monitorización
IBM i: integración open source (en desarrollo)

Todo es gratuito. Todo está documentado. Todo está en GitLab.

3. Pruebas de rendimiento y optimización

El hardware Power tiene características únicas que la mayoría del software no aprovecha. Hacemos benchmarks, identificamos oportunidades y trabajamos con los proyectos upstream para mejorar el rendimiento en Power.

Cuando encontramos optimizaciones, las contribuimos de vuelta. Todo el ecosistema se beneficia.

4. Construir comunidad

El mundo Power está fragmentado. Administradores de AIX, equipos de Linux on Power, entornos IBM i — todos resolviendo problemas similares de forma aislada.

LibrePower conecta estas comunidades:

Compartir conocimiento entre plataformas
Amplificar la voz colectiva ante fabricantes y proyectos
Crear una red de expertise en Power

5. Expandir el mercado

Cada nueva solución validada en Power es una razón más para que las organizaciones elijan la plataforma. Cada desarrollador que aprende Power es talento para el ecosistema. Cada caso de éxito demuestra valor.

Más soluciones → más adopción → ecosistema más fuerte → más inversión en Power

Este círculo virtuoso beneficia a todos: IBM, partners, ISVs y usuarios.

¿Por qué debería importarte?

Si administras sistemas Power:

Accede a herramientas y soluciones que echabas en falta
Únete a una comunidad que entiende tu entorno
Maximiza el retorno de tu inversión en hardware

Si eres desarrollador:

Aprende una plataforma con características técnicas únicas
Contribuye a proyectos con impacto real en el mundo enterprise
Desarrolla expertise en un nicho de alto valor

Si eres un ISV:

Consigue que tu software esté validado en Power
Conecta con clientes enterprise
Descubre oportunidades de mercado en el ecosistema Power

Si estás evaluando infraestructura:

Descubre qué es realmente posible en Power más allá de las cargas tradicionales
Encuentra validación independiente de soluciones
Conecta con la comunidad para conocer experiencias reales

En qué estamos trabajando

AIX (aix.librepower.org)

✅ Gestor de paquetes moderno (dnf/yum para AIX)
✅ fzf — buscador difuso (binario Go compilado para AIX)
✅ nano — editor moderno
✅ Herramientas 2FA — Google Authenticator con códigos QR
🔄 Próximamente: ripgrep, yq, coreutils modernos

Linux ppc64le

🔄 AWX — automatización Ansible (port completo en progreso)
🔄 Herramientas de contenedores — Podman, Buildah, Skopeo
🔄 Herramientas de desarrollo — lazygit, k9s, CLIs modernos

IBM i

📋 Fase de planificación — evaluando prioridades con input de la comunidad

La visión

Imagina:

Cada proyecto open source importante considera Power en el momento del release
Los ISVs ven Power como una plataforma estratégica, no como algo secundario
Las organizaciones despliegan nuevas cargas en Power con confianza
Una comunidad conectada y creciente que impulsa el ecosistema

Eso es The Power Renaissance.

No es nostalgia del pasado. No es solo alargar la vida de los despliegues existentes.

Expansión activa de lo que Power puede hacer y de quién lo usa.

Únete

LibrePower crece con la comunidad. Así puedes participar:

📬 Suscríbete a las novedades — nuevos releases, guías, noticias de la comunidad
💻 Explora nuestros repos — usa, contribuye, solicita
✅ Certifica tu software — valida tu software en Power
🤝 Hazte sponsor — apoya la iniciativa

¿Quién está detrás?

LibrePower es una iniciativa de SIXE, Business Partner de IBM y Canonical con más de 20 años de experiencia en el ecosistema Power.

Hemos visto lo que Power puede hacer. Hemos visto lo que falta. Ahora construimos lo que debería existir.

LibrePower — Liberando el potencial de Power Systems a través del software libre 🌍. RAS inigualable. TCO superior. Huella mínima. 🌍

¿Qué es OpenUEM? La revolución Open Source para la gestión de dispositivos

23 diciembre, 2025/en Noticias

En el mundo de la administración de sistemas, a menudo nos encontramos con herramientas sobredimensionadas, costosas y complejas. Sin embargo, cuando analizamos qué es lo que más busca la gente sobre alternativas eficientes, el nombre de OpenUEM empieza a sonar con fuerza.

Desde SIXE, como especialistas en infraestructura y código abierto, queremos responder a las preguntas más frecuentes sobre esta tecnología y explicarte por qué hemos apostado por ella.

¿Qué es OpenUEM y cómo funciona?

OpenUEM (Unified Endpoint Management) es una solución de código abierto diseñada para simplificar la vida de los administradores de TI. A diferencia de las suites tradicionales que cobran por agente o dispositivo, OpenUEM ofrece una plataforma centralizada para el inventario, despliegue de software y gestión remota de equipos sin costes de licencia abusivos.

Su funcionamiento es muy bueno por su sencillez y eficiencia:

El agente: Se instala un pequeño programa en los equipos finales.
El servidor: Recopila la información en tiempo real y permite ejecutar acciones.
La consola web: Desde un navegador, el administrador puede ver todo el parque informático, instalar aplicaciones o conectarse remotamente.

OpenUEM vs Otras herramientas tradicionales

Una de las dudas más comunes es cómo se compara esta herramienta con los gigantes del mercado. Hemos hecho una lista de pros y contras con la perspectiva de SIXE, para que saquéis vuestras propias conclusiones :)

A favor:
- Coste: Al ser Open Source, eliminas el gasto por licencias. Ideal para PYMES y grandes despliegues donde el coste por agente se dispara.
- Privacidad: Es self-hosted. Tú controlas los datos, no una nube de terceros.
- Ligereza.
En contra:
- Al ser una herramienta más joven, puede no tener (todavía) el ecosistema de plugins infinito de soluciones que llevan 20 años en el mercado. Sin embargo, cubre con creces el 90% de las necesidades habituales de gestión.

¿Cómo integrar OpenUEM con tu infraestructura TI actual?

La integración es menos traumática de lo que parece. OpenUEM está diseñado para convivir con lo que ya tienes.

Despliegue de software: Se integra nativamente con repositorios como Winget (Windows) y Flatpak (Linux), utilizando los estándares de la industria en lugar de formatos propietarios cerrados.
Soporte remoto: Incorpora tecnologías probadas como VNC, RDP y RustDesk para que puedas dar soporte a empleados remotos sin configuraciones complejas de VPN en muchos casos.

Si te preguntas cómo configurar OpenUEM para monitorizar empleados en remoto, la respuesta está en su arquitectura flexible. El servidor puede desplegarse mediante Docker en minutos, permitiendo que los agentes se reporten de forma segura desde cualquier ubicación con internet.

¿Quién ofrece soporte y soluciones OpenUEM para empresas?

Aunque el software es libre, las empresas necesitan garantías, soporte y una implementación profesional. Aquí es donde entramos nosotros. En SIXE, no solo implementamos la herramienta; ofrecemos el soporte empresarial necesario para que duermas tranquilo. Sabemos que integrar una nueva plataforma puede generar dudas sobre precios o modelos de despliegue para pequeñas y medianas empresas. Por eso, nuestro enfoque no es venderte una licencia (ni siquiera las hay), sino ayudarte a desplegar, mantener y asegurar tu infraestructura de gestión de dispositivos con OpenUEM.

¿Hablamos?

Si estás buscando una plataforma para gestionar tus dispositivos móviles y de escritorio que sea transparente, auditable y económica, OpenUEM puede ser una solución para ti. ¿Quieres ver cómo funcionaría en tu entorno? Echa un vistazo a nuestra solución profesional de OpenUEM y descubre cómo podemos ayudarte a gestionar el control de tus dispositivos. Para los más curiosos o que quieran trastear con la herramienta de forma autónoma, siempre recomendamos visitar el repositorio oficial de OpenUEM.

Claroty xDome vs CTD: ¿Nube o local? Análisis de arquitectura para tu red OT

2 diciembre, 2025/en Noticias

En SIXE llevamos más de 15 años pegándonos con la infraestructura, las redes y la seguridad. Hemos visto de todo: desde PLCs conectados “a la brava” a internet, hasta redes de hospitales donde una cafetera inteligente podía tumbar un servidor crítico. Por eso, cuando hablamos de Ciberseguridad Industrial (OT) e IoMT (Internet de las Cosas Médicas), no nos casamos con cualquiera. Pero, si has llegado hasta aquí buscando en Google, seguramente tienes un lío de nombres importante. ¿Qué es xDome? ¿Qué es CTD? ¿Cuál necesito? Tranquilo/a, que hoy nos ponemos el mono de ingenieros para explicártelo claro.

La gran duda: ¿Cuál es la diferencia entre Claroty CTD y xDome?

Esta es la pregunta del millón. Ambas soluciones buscan lo mismo: visibilidad total y protección de tu entorno industrial, pero su arquitectura es radicalmente distinta.

1. Claroty xDome (El futuro Cloud-Native)

Es la evolución SaaS. xDome está diseñado para empresas que quieren aprovechar la agilidad de la nube sin sacrificar seguridad.

¿Cómo funciona? Es una solución basada en la nube que realiza el descubrimiento de activos, gestión de vulnerabilidades y detección de amenazas.
Lo mejor: Se despliega rapidísimo y escala que da gusto. Ideal si tu organización ya tiene una mentalidad “Cloud First” y quieres gestionar múltiples sitios desde un panel único sin desplegar toneladas de hardware.

2. Claroty CTD (Continuous Threat Detection – On-Premise)

Es el clásico peso pesado para entornos que, por normativa o filosofía, no pueden (o no quieren) tocar la nube.

¿Cómo funciona? Todo se queda en casa. Se despliega en tu propia infraestructura local.
Lo mejor: Soberanía total de los datos. Es la opción preferida para infraestructuras críticas muy sensibles (energía, defensa) donde los datos no salen del perímetro físico bajo ninguna circunstancia.

El consejo de SIXE: No hay uno “mejor” que otro, hay uno que se adapta mejor a tu arquitectura. En SIXE realizamos análisis exhaustivos antes de recomendarte nada.

¿Y qué pinta Claroty Edge en todo esto?

A veces no necesitas desplegar una infraestructura completa de monitoreo continuo desde el día uno, o simplemente necesitas una auditoría rápida para saber “qué demonios tengo conectado en mi planta”.

Claroty Edge no requiere cambios en la red (ni SPAN ports, ni TAPs complejos de entrada). Es un ejecutable que lanzas, escanea, te da una “foto” completa de tus activos y vulnerabilidades en minutos, y se cierra sin dejar rastro.

¿Con quién compite Claroty y cuáles son las mejores empresas de ciberseguridad?

Si estás evaluando software, seguro que te suenan nombres como Nozomi Networks, Dragos o Armis. Son los grandes “rivales” en el cuadrante mágico.

¿Cuáles son las mejores? Depende de a quién preguntes, pero la realidad técnica es esta:

Claroty: Líder indiscutible en amplitud de protocolos (habla el idioma de tus máquinas, ya sea Siemens, Rockwell, Schneider, etc.) y su integración con entornos médicos (Medigate).
Nozomi: Muy fuerte en visibilidad pasiva.
Dragos: Muy centrado en inteligencia de amenazas pura.

¿Por qué en SIXE elegimos Claroty? Porque entendemos lo que hay debajo del software. La convergencia IT/OT es compleja y Claroty ofrece la suite más completa (Secure Remote Access + CTD/xDome). No solo te dice “hay un virus”, te permite gestionar accesos remotos de terceros (adiós a las VPNs inseguras de proveedores) y segmentar la red correctamente.

Si quieres profundizar en cómo se comparan los estándares de seguridad industrial a nivel global, puedes echar un ojo a la normativa IEC 62443, que es la biblia que seguimos para estas implementaciones.

Implementar Claroty no es solo instalar, es entender

Aquí es donde entramos nosotros. Una herramienta potente configurada por manos inexpertas es solo un generador de ruido y falsos positivos.

En SIXE no nos limitamos a la implementación, nosotros pensamos en:

Diseñar la arquitectura: Planificamos dónde poner los sensores (SPAN Ports, TAPs) para no generar latencia. La planta NO se puede parar.
Afinar las políticas: Un falso positivo en una planta puede significar un ingeniero corriendo a las 3 de la mañana. Ajustamos la herramienta a la realidad de tus protocolos (Modbus, Profinet, CIP).
Formar a tu equipo: Capacitamos a tu SOC para que entiendan que una alerta OT no es igual que una IT.

👉 Descubre cómo implementamos Claroty en SIXE

Cómo aprender Ceph | La realidad que NADIE cuenta

10 noviembre, 2025/en Noticias

“Lanzo comandos pero no entiendo nada”. “Leo la documentación pero cuando algo falla no sé ni por dónde empezar”. “Llevo un año con Ceph y siento que apenas rasco la superficie”. Si alguna de estas frases te resuena, no estás solo. Y lo más importante: no es culpa tuya.

Después de más de 10 años trabajando con Ceph en producción, enseñando a cientos de administradores, y rescatando clusters “imposibles” a las 3AM, hemos llegado a una conclusión que nadie te dirá en las certificaciones oficiales: Ceph es brutalmente difícil de dominar. Y no porque seas mal administrador, sino porque la tecnología es intrínsecamente compleja, está en evolución constante, y la documentación asume conocimientos que nadie te enseñó explícitamente.

No te vamos a vender un “aprende Ceph en 30 días”. Queremos contarte la verdad sobre cómo se aprende realmente, cuánto tiempo toma, qué malentendidos te van a frenar, y cuál es la ruta más efectiva para pasar de lanzar comandos a ciegas a tener expertise real ;)

Por qué Ceph es tan difícil de aprender (y no es tu culpa)

La complejidad no es accidental: es inherente

Ceph no es “otro sistema de almacenamiento”. Es una arquitectura distribuida masivamente que debe resolver simultáneamente:

Consistencia en escritura con replicación multi-nodo y consenso distribuido
Disponibilidad continua ante fallos de hardware (discos, nodos, racks completos)
Rebalanceo automático de petabytes de datos sin downtime
Performance predecible bajo cargas variables y multi-tenant
Tres interfaces completamente diferentes (block, object, filesystem) sobre la misma base
Integración con múltiples ecosistemas (OpenStack, Kubernetes, virtualización tradicional)

Cada una de estas capacidades por separado es un sistema complejo. Ceph las integra todas. Y aquí está el problema: no puedes entender una sin entender las demás.

Error #1 de principiantes: Intentar aprender Ceph como si fuera un servicio stateless más. “Configuro, lanzo comandos, y debería funcionar”. No. Ceph es un sistema distribuido con estado compartido, consenso entre nodos, y comportamientos emergentes que solo aparecen bajo carga o fallos. Si no entiendes la arquitectura subyacente, cada problema será un misterio indescifrable.

La documentación asume conocimientos que nadie te enseñó

Lee cualquier página de la documentación oficial de Ceph y encontrarás términos como:

Placement groups (PGs)
CRUSH algorithm
BlueStore / FileStore
Scrubbing y deep-scrubbing
Peering y recovery
OSDs up/down vs in/out

La documentación explica qué son, pero no por qué existen, qué problema resuelven, o cómo interactúan entre sí. Es como intentar aprender a programar empezando por la referencia del lenguaje en lugar de los conceptos fundamentales.

Ejemplo real: Un alumno nos escribió: “He estado 3 meses intentando entender PGs. Leo que ‘son una abstracción lógica’, pero… ¿por qué existen? ¿Por qué no mapear objetos directamente a OSDs?”

Esa pregunta muestra entendimiento profundo. La respuesta (escalabilidad del CRUSH map, granularidad de rebalanceo, overhead de metadatos) requiere entender primero sistemas distribuidos, teoría de hashing consistente, y trade-offs de arquitectura. Nadie te enseña eso antes de soltar ceph osd pool create.

La evolución constante invalida conocimiento

Ceph cambia RÁPIDO. Y no estoy hablando de features opcionales, sino de cambios arquitecturales fundamentales:

FileStore → BlueStore (2017): Cambia completamente cómo se escribe en disco
ceph-deploy → ceph-ansible → cephadm (2020): Tres herramientas de deployment diferentes en 5 años
Luminous → Nautilus → Octopus → Pacific → Quincy → Reef → Squid: 7 versiones major en 7 años, cada una con breaking changes
Crimson/Seastore (2026+): Reescritura completa del OSD que invalidará gran parte del conocimiento de tuning

Lo que aprendiste hace 2 años sobre tuning de FileStore es completamente irrelevante ahora. Los PGs por pool que calculabas manualmente ahora los gestiona el autoscaler. Las mejores prácticas de networking cambiaron con msgr2.

Error #2 de principiantes (y expertos): Aprender configuraciones de memoria sin entender por qué existen. Vi un administrador que configuraba manualmente PG count con las fórmulas de Luminous… en un cluster Squid con autoscaler activado. El autoscaler lo ignoraba, él no entendía por qué. El contexto histórico importa para saber qué conocimiento está obsoleto.

Cuánto tiempo toma realmente dominar Ceph

Hablemos con números reales basados nuestra experiencia formando administradores:

40h

Para deployment básico funcional

6 meses

Para troubleshooting sin pánico

2-3 años

Para expertise real en producción

La progresión realista de aprendizaje

Mes 1-2: “No entiendo nada pero funciona”

Sigues tutoriales. Lanzas comandos ceph osd pool create, ceph osd tree. El cluster funciona… hasta que no. Un OSD se marca como down y entras en pánico porque no sabes diagnosticar.

Síntoma típico: Copias comandos de Stack Overflow sin entender qué hacen. “Lo arreglé” pero no sabes cómo ni por qué.

Mes 3-6: “Entiendo comandos pero no arquitectura”

Ya memorizaste los comandos principales. Sabes crear pools, configurar RBD, montar CephFS. Pero cuando aparece PG 3.1f is stuck in peering, no tienes idea de qué significa “peering” ni cómo solucionarlo.

Síntoma típico: Resuelves problemas por ensayo-error reiniciando servicios hasta que funciona. No hay método, hay suerte.

Mes 6-12: “Entiendo la arquitectura pero no el tuning”

Finalmente entiendes MON/OSD/MGR, el CRUSH algorithm, qué son los PGs. Puedes explicar la arquitectura en una pizarra. Pero tu cluster rinde mal y no sabes si es CPU, red, discos, o configuración.

Síntoma típico: Lees sobre BlueStore tuning, cambias parámetros al azar, no mides antes/después. El performance sigue igual (o peor).

Año 1-2: “Puedo troubleshootear pero sin método”

Ya rescataste algunos clusters. Sabes usar ceph health detail, interpretar estados de PG, recuperar un OSD caído. Pero cada problema es una nueva aventura de 4 horas probando cosas.

Síntoma típico: Puedes arreglar problemas… eventualmente. Pero no puedes predecirlos ni explicar a tu jefe cuánto tardará la solución.

Año 2-3: “Tengo método y entiendo trade-offs”

Diagnosticas sistemáticamente: recoges síntomas, formulas hipótesis, validas con herramientas específicas. Entiendes trade-offs: cuando usar replicación vs erasure coding, cómo dimensionar hardware, cuándo vale la pena el NVMe.

Síntoma típico: Tu respuesta ante problemas es “déjame revisar X, Y y Z” con plan claro. Puedes estimar tiempos de recuperación realistas.

Año 3+: expertise real

Diseñas arquitecturas desde cero considerando workload, presupuesto, SLAs. Haces disaster recovery sin manual. Optimizas BlueStore para cargas específicas. Entiendes el código fuente lo suficiente para debuggear comportamientos raros.

Síntoma típico: Otros admins te llaman cuando un cluster está “imposible”. Tú tardas 20 minutos en identificar el problema que ellos llevan 3 días atacando.

La buena noticia: Puedes acelerar SIGNIFICATIVAMENTE esta progresión con formación estructurada. Un buen curso de 3 días puede condensar 6 meses de ensayo-error. No porque “enseñe más rápido”, sino porque te evita callejones sin salida y malentendidos que consumen semanas.

Los malentendidos típicos que frenan tu aprendizaje

Malentendido #1: “Más hardware = más performance”

He visto clusters con 40 OSDs rindiendo peor que clusters con 12. ¿Por qué? Porque tenían:

Red pública y cluster en la misma interfaz (saturación garantizada)
CPU frequency governor en “powersave” (5x degradación en replication)
PG count totalmente desbalanceado entre pools
BlueStore cache muy bajo para cargas RGW

La realidad: Ceph performance depende del eslabón más débil. Un single-threaded bottleneck en un MON puede hundir todo el cluster. Más hardware mal configurado solo multiplica el caos.

Malentendido #2: “Erasure coding siempre ahorra espacio”

Un alumno una vez dijo orgulloso: “Pasé todo mi cluster a erasure coding 8+3 para ahorrar espacio”. Le preguntamos: “¿Qué workload tienes?” – “RBD con snapshots frecuentes”. Ups.

Erasure coding con workloads que hacen overwrites pequeños (RBD, CephFS) es TERRIBLE para performance. Y el “ahorro” de espacio se come con los partial stripes y metadata overhead.

La realidad: EC es fantástico para object storage cold data (RGW archives). Es pésimo para block devices con high IOPS. Conocer el workload antes de decidir arquitectura es fundamental.

Malentendido #3: “Si ceph health dice HEALTH_OK, todo está bien”

No. HEALTH_OK significa que Ceph no detectó problemas que él conoce. No detecta:

Degradación progresiva de discos (SMART warnings)
Network packet loss intermitente
Memory leaks en daemons
Scrubbing que lleva 2 semanas sin completar
PGs con placement subóptimo que causan hotspots

La realidad: Necesitas monitoring externo (Prometheus + Grafana mínimo) y revisar métricas que Ceph no expone en ceph health. HEALTH_OK es necesario pero no suficiente.

Malentendido #4: “Leo la doc oficial y con eso basta”

La documentación oficial es reference material, no teaching material. Asume que ya entiendes:

Sistemas distribuidos (Paxos, quorum, consensus)
Storage fundamentals (IOPS vs throughput, latency percentiles)
Networking (MTU, jumbo frames, TCP tuning)
Linux internals (cgroups, systemd, kernel parameters)

Si no traes esa base, la doc te va a confundir más que ayudar.

La realidad: Necesitas recursos adicionales: papers académicos de sistemas distribuidos, blogs de experiencias reales, formación que conecte los puntos que la doc omite.

Errores típicos (que todos cometemos)

Errores de principiantes

No configurar cluster network: La red pública se satura con replicación interna. Performance se hunde. Solución: --cluster-network desde el día 1.

Usar defaults para PG count: En versiones pre-Pacific creabas pools con 8 PGs… para un pool que crecería a 50TB. Imposible rebalancear después. Solución: Autoscaler o calcular bien desde inicio.

No entender la diferencia OSD up/down vs in/out: Sacas un OSD para mantenimiento con ceph osd out y arranca inmediatamente rebalanceo masivo que tarda 8 horas. Querías noout. Ups.

Errores de intermedios

Oversized erasure coding: Configurar 17+3 EC en cluster de 25 nodos. Un nodo se cae y el cluster entra en modo lectura-only porque no hay suficientes OSDs para escribir. Trade-off no entendido.

Ignorar el I/O scheduler: Usar deadline scheduler con NVMe (absurdo). O none scheduler con HDD (desastroso). El scheduler correcto importa 20-30% de performance.

No planificar disaster recovery: “Tenemos replicación 3x, estamos seguros”. Luego un rack entero se cae y pierden quorum de MONs. No practicaron recovery nunca. Pánico.

Errores de expertos (sí, también los cometemos)

Over-tuning: Cambiar 15 parámetros de BlueStore simultáneamente “para optimizar”. Algo rompe. ¿Cuál de los 15 cambios fue? Nadie sabe. Principio: cambiar UNA cosa, medir, iterar.

Confiar demasiado en el conocimiento antiguo: Aplicar técnicas de tuning de FileStore a BlueStore. No funciona porque la arquitectura interna es totalmente diferente. Contexto histórico importa.

No documentar decisiones arquitecturales: Hace 2 años decidiste usar EC 8+2 en cierto pool por razón X. Nadie lo documentó. Ahora un nuevo admin quiere “simplificar” a replication. Desastre evitable con documentación.

La ruta más efectiva para aprender Ceph

Fase 1: fundamentos arquitecturales (40-60 horas)

Antes de tocar un comando, entiende:

Qué problema resuelve Ceph (vs NAS, vs SAN, vs cloud storage)
Arquitectura RADOS: cómo funcionan MON, OSD, MGR
CRUSH algorithm: por qué existe, qué problema resuelve
Placement groups: la abstracción que hace escalable el sistema
Diferencia entre pools, PGs, objects, y su mapeo a OSDs

Cómo estudiar esto: No con comandos, sino con diagramas y conceptos. Un buen curso de fundamentos es 100x más efectivo que tutoriales de “deploy en 10 minutos”.

Curso recomendado: Administración Ceph

Nivel: fundamental
3 días intensivos

Programa diseñado específicamente para construir base sólida desde cero. No asume conocimientos previos de storage distribuido.

Ver programa completo →

Fase 2: configuración avanzada y troubleshooting (60-80 horas)

Con fundamentos sólidos, ahora profundizas:

BlueStore internals: cómo se escriben los datos realmente
CRUSH rules customizadas para topologías complejas
Tuning de performance: identificar bottlenecks
Multi-site RGW para geo-replication
RBD mirroring para disaster recovery
Troubleshooting sistemático con método

El objetivo: Pasar de “puedo configurar” a “entiendo por qué configuro así y qué trade-offs estoy haciendo”.

Curso recomendado: Ceph avanzado

Nivel: avanzado
3 días intensivos

Para administradores que ya tienen cluster running pero quieren dominar configuraciones complejas y prepararse para EX260.

Ver programa completo →

Fase 3: operaciones productivas críticas (80-100 horas)

El salto final: de “sé configurar y troubleshootear” a “puedo rescatar clusters en producción a las 3AM”.

Troubleshooting forense: diagnosticar fallos multi-factor complejos
Disaster recovery REAL: recuperación de metadata corrupta, journals perdidos
Performance engineering: optimization a nivel kernel y hardware
Arquitecturas para cargas específicas: AI/ML, video streaming, compliance
Security hardening y compliance (GDPR, HIPAA)
Scaling a petabytes: problemas que solo aparecen a gran escala

El objetivo: Expertise real verificable. Eliminar ese “respeto” (miedo) a escenarios críticos.

Curso recomendado: Ceph production engineering

Nivel: expert
3 días intensivos

El único curso del mercado enfocado 100% en operaciones críticas de producción. No simulaciones – problemas reales.

Ver programa completo →

Práctica continua: el ingrediente no negociable

Aquí está la verdad incómoda: puedes hacer los 3 cursos y seguir sin tener expertise si no practicas. El conocimiento teórico se olvida si no lo aplicas.

La recomendación de SIXE tras cada curso:

Monta un cluster de práctica (puede ser VMs locales o cloud barato)
Rompe cosas intencionalmente: mata OSDs, llena discos, satura red
Practica recovery sin manual: ¿puedes recuperarlo sin Google?
Mide todo: benchmarks antes/después de cada cambio
Documenta tus aprendizajes: blog, notas, lo que sea

Pro tip: Los mejores administradores Ceph que conozco mantienen un “lab cluster” permanente donde prueban cosas locas. Algunos incluso tienen scripts que inyectan fallos aleatorios para practicar troubleshooting. Suena extremo, pero funciona.

“La diferencia entre un administrador intermedio y un experto no es que el experto no cometa errores. Es que el expert oreconoce el error en 5 minutos en lugar de 5 horas, porque ya lo cometió antes y documentó la solución.”

Conclusión: el camino es largo pero acelerable

Si llegaste hasta aquí, ya estás en el 10% superior de administradores Ceph por pura intención de aprender correctamente. La mayoría abandona cuando se da cuenta de la complejidad real.

Las verdades incómodas que debes aceptar:

Dominar Ceph toma 2-3 años de experiencia práctica continua. No hay shortcuts mágicos.
Vas a cometer errores. Muchos. Algunos en producción. Es parte del proceso.
El conocimiento se deprecia rápido. Lo que aprendes hoy estará parcialmente obsoleto en 18 meses.
La documentación oficial nunca será tutorial-friendly. Necesitas recursos complementarios.

Pero también las buenas noticias:

La demanda de expertos Ceph excede masivamente la oferta. Buen momento para especializarse.
Puedes acelerar 6-12 meses de curva de aprendizaje con formación estructurada que evita callejones sin salida.
Una vez que “cliquea” la arquitectura fundamental, el resto se construye lógicamente sobre esa base.
La comunidad es generalmente abierta a ayudar. No estás solo.

Nuestro consejo final después de 10+ años con Ceph: Empieza con fundamentos sólidos, practica constantemente, y no tengas miedo de romper cosas en entornos de prueba. Los mejores administradores que conozco son los que han roto más clusters (en labs) y documentado meticulosamente cada recovery.

Y si quieres acelerar significativamente tu curva de aprendizaje, considera formación estructurada que condense años de experiencia práctica en semanas intensivas. No porque sea más fácil, sino porque te evita los 6 meses que todos perdemos atacando problemas que alguien ya resolvió.

¿Por dónde empezar hoy?

Si eres principiante total: Curso de administración Ceph
Si ya gestionas un cluster: Curso de Ceph avanzado
Si tienes 2+ años y quieres expertise real: Ceph production engineering

O simplemente monta un cluster de 3 VMs, rompe cosas, y aprende troubleshooting. El camino es tuyo, pero no tiene por qué ser solitario.

¡Nos vemos en Common Iberia 2025!

17 octubre, 2025/en Noticias

El equipo de SIXE asistirá como parte de Common Iberia 2025. Volveremos a Madrid los días 13 y 14 de noviembre para el evento de referencia del ecosistema IBM i, AIX y Power. Dos días dedicados a las últimas novedades en tecnología Power, desde el anuncio de Power 11 hasta casos de uso reales de IA, con expertos internacionales, IBM Champions y líderes de la comunidad.

Click en la imagen para acceder al formulario de registro del evento

Nuestras sesiones en Common Iberia Madrid:

Document Intelligence on IBM Power with Docling and Granite
Descubre cómo implementar inteligencia documental avanzada directamente en tu infraestructura Power.

AIX 7.3 novedades y mejores prácticas: rendimiento, disponibilidad y seguridad
Todo lo que necesitas saber sobre las últimas capacidades de AIX 7.3 para optimizar tus sistemas críticos.

Ubuntu en Power: contenedores, IA, BBDD y otras maravillas 100% open source
Explora las posibilidades del ecosistema open source en arquitecturas Power.

ILE RPG – Uso de Servicios IBM i (SQL) y Funciones SQL de QSYS2
Aprende a aprovechar al máximo los servicios SQL nativos de IBM i en tus aplicaciones RPG.

Además de la presentación de Project BOB (el asistente de desarrollo integrado de IBM), el evento incluye sesiones sobre IA, alta disponibilidad, PowerVS, desarrollo moderno con VS Code, y un debate abierto sobre casos de uso de IA en IBM i.

✅Reserva tu plaza ahora

Conecta con la comunidad de IBM Power, comparte casos de éxito y descubre las últimas innovaciones en sistemas críticos. ¡Te esperamos en Madrid!

Qué trae IBM y por qué es el mayor lanzamiento en seis años

Los tres modelos de FlashSystem de 2026: FlashSystem 5600, 7600 y 9600

FlashCore Module 5: QLC que rinde como TLC (y por qué eso importa)

FlashSystem.ai: IA agéntica en la cabina, con sus luces y sus sombras

Detección de ransomware en 60 segundos: los datos y los asteriscos

El argumento que no sale en los datasheets: la cadena de suministro

Pure Storage, Dell, NetApp y el resto, ¿ahora qué?

Donde IBM gana terreno claramente:

Donde la competencia aprieta:

¿Para quién tiene sentido?

Conclusiones

El drama del año: MinIO pasa a “modo mantenimiento” (léase: modo abandono)

Mientras tanto, Ceph sigue nadando tranquilo

Los números que importan

El ecosistema enterprise: entendiendo qué estás comprando

IBM Fusion: dos sabores para diferentes necesidades

Red Hat Ceph Storage: el estándar enterprise

SUSE: una lección sobre dependencia de vendors

Pure Storage y NetApp: el enfoque appliance

La pregunta que nadie hace: ¿qué estás comprando realmente?

Desmitificando los claims de marketing

La jugada inteligente: decidir con información

¿Dónde conseguir ese conocimiento?

Conclusiones para 2026

De “AIX es lento” a “AIX iguala a Linux” (si usas las herramientas adecuadas)

Capítulo 1: Esa sensación de hundimiento

Capítulo 2: Los primeros 65x – La configuración importa

La caché amnésica

El problema del tamaño de página (Page Size)

Marcador tras la Fase 1

Capítulo 3: El misterio de CPU vs. Memory Stalls

La causa raíz: Invalidación de caché por el Hipervisor

Capítulo 4: La odisea del compilador

Todo lo que intenté con GCC (y por qué falló)

IBM Open XL: El giro de guion

¿Por qué tanta diferencia?

Capítulo 5: Los callejones sin salida de LTO y PGO

LTO: La ironía

PGO: Los perfiles que nunca existieron

Capítulo 6: La revelación de la LPAR

La matriz de pruebas

El factor WoF

El desastre del modo Donación

Capítulo 7: El marcador final (el verdadero giro)

El Museo de los Intentos Fallidos

Lecciones aprendidas

1. Los “defaults” los carga el diablo

2. El mito de la lentitud era un problema de Toolchain

3. No todas las optimizaciones se portan

Recomendaciones para usuarios

¿Qué sigue?

TL;DR

Llevamos MariaDB a AIX (Parte 1)

“¿Tan difícil puede ser llevar MariaDB a AIX?”

Capítulo 2: CMake y los tres invitados inesperados

El bug de la función fantasma

poll.h: A jugar al escondice

Los malditos plugins

Capítulo 3: Thread Pool, o cómo aprendí a dejar de preocuparme y amar el Mutex

El problema de ONESHOT

Once versiones para alcanzar la sabiduría

Se acerca la noche y sigo teniendo bugs (El Bug de -O3)

Capítulo 4: La cosa del -blibpath (que en realidad es una feature)

Capítulo 5: Estabilidad – Los números que importan

El impacto del Thread Pool

Lo que he aprendido (hasta ahora)

¿Qué sigue? La incógnita del rendimiento

Pronto la Parte 2.

La teoría: no todos los casos de uso de LLM son GPU-bound

⚙️ CPU, MMA y aceleradores de bajo consumo

¿Por qué AIX?

Qué es (y qué no) Llama-AIX

Queremos liberar todo el potencial de IBM Power

El hardware más capaz que aún no aprovechas del todo

¿Qué es LibrePower?

Qué hacemos en LibrePower

1. LibrePower Certified — validación independiente

2. Repositorios open source

3. Pruebas de rendimiento y optimización

4. Construir comunidad

Capítulo 4: La cosa del `-blibpath` (que en realidad es una feature)