10 Errores de Arquitectura y ROI en la Migración Post-VMware

/en ,
Análisis Técnico · Febrero 2026

10 Errores de Arquitectura y ROI que Nadie Evaluó en la Huida Post‑VMware

Las alternativas open source son viables. Pero “viable” y “adecuado para tu negocio” son preguntas radicalmente distintas que exigen análisis técnico, financiero y de gobernanza antes de comprometer tu infraestructura una década.

Febrero 2026●25 min lectura●Para CIOs, CTOs y Directores de Infraestructura
El 86 % de los clientes de VMware están reduciendo activamente su footprint. Solo el 4 % ha completado la migración. Entre esos dos números hay un abismo de decisiones técnicas, financieras y estratégicas que la mayoría de organizaciones están tomando con más prisa que cabeza. Este artículo no recomienda ninguna plataforma: plantea las preguntas que todo equipo directivo debería responder antes de comprometer su infraestructura para los próximos 5–10 años. Spoiler: no hay respuesta mágica, pero sí hay un camino sensato.

Error 01 de 10

Confundir urgencia con estrategia

La adquisición de VMware por Broadcom en noviembre de 2023 por 61.000 millones de dólares desencadenó la mayor sacudida en virtualización empresarial de la última década. Y cuando decimos sacudida, nos quedamos cortos. Licencias perpetuas eliminadas, ~8.000 SKUs consolidados en 4 bundles, mínimo de compra de 72 cores y subidas de precio reportadas entre el 150 % y el 1.500 %. Tesco presentó una demanda de 100 millones de libras. Fidelity advirtió de riesgos para 50 millones de clientes. Vamos, que el panorama invitaba a salir corriendo.

Y eso es exactamente lo que ha pasado: mucha gente ha salido corriendo, pero no siempre en la dirección correcta. Una encuesta de CloudBolt (2026) reveló que el 63 % ha cambiado su estrategia de migración al menos dos veces (sí, dos veces). Gartner estima que la cuota de VMware caerá del 70 % al 40 % para 2029, pero el camino hasta allí está lleno de curvas que merecen bastante más reflexión de la que están recibiendo.

Perspectiva SIXE

La urgencia que genera Broadcom es totalmente comprensible —a nadie le gusta que le multipliquen la factura de un día para otro. Pero cada decisión de infraestructura tomada bajo presión se convierte en deuda técnica que los equipos heredarán durante años. La primera decisión correcta es separar la respuesta táctica inmediata de la estrategia a medio plazo y evaluar ambas con criterios diferentes. Respira, planifica y luego actúa.

Error 02 de 10

Ignorar la gobernanza del proyecto open source

No todo el open source es igual, ni mucho menos. La diferencia más relevante para una decisión empresarial a largo plazo no es la licencia, sino algo que casi nadie mira: quién controla el proyecto y qué mecanismos protegen a la comunidad si las prioridades comerciales cambian.

Proxmox Server Solutions GmbH es una empresa privada austriaca con un capital social de 35.000 € y un equipo estimado de 14–24 personas. Gente estupenda, seguro, pero no existe fundación independiente, ni consejo de gobernanza abierto, ni representación comunitaria en las decisiones de desarrollo. Es decir: el futuro de tu plataforma depende de las decisiones de una sola empresa.

Contrástese con la MariaDB Foundation, donde ninguna empresa puede ocupar más del 25 % de los asientos del consejo — un mecanismo que protegió al proyecto cuando MariaDB Corporation fue adquirida por K1 en septiembre de 2024. O con OpenStack, ahora bajo la Linux Foundation, con gobernanza distribuida entre cientos de organizaciones. Eso sí que es un colchón de seguridad.

Pregunta clave

¿Tu plataforma de virtualización —esa sobre la que van a correr tus aplicaciones de negocio los próximos 10 años— está controlada por una fundación independiente, un consorcio o una única empresa privada de menos de 25 empleados? No es una pregunta retórica: la respuesta tiene implicaciones directas sobre el riesgo a largo plazo.

Error 03 de 10

No leer el Contributor License Agreement

Lo sabemos, leer un CLA no es exactamente un plan de viernes noche. Pero merece la pena. El CLA de Proxmox otorga a la compañía una licencia perpetua, mundial e irrevocable sobre todas las contribuciones, con derecho a relicenciarlas bajo términos comerciales o propietarios. Este mecanismo no es inherentemente problemático, pero es exactamente la combinación estructural (empresa única + AGPL + CLA permisivo) que precedió a cada cambio de licencia relevante de los últimos siete años. Es como ver las nubes de tormenta y decir “seguro que no llueve”.

ProyectoAñoCambioConsecuenciaGobernanza
MongoDB2018AGPL → SSPLDropped by Debian/Red HatSingle vendor
Elasticsearch2021Apache 2.0 → SSPLFork: OpenSearch (Linux Foundation)Single vendor
HashiCorp2023MPL 2.0 → BSLFork: OpenTofu · IBM: $6.4BSingle vendor
Redis2024BSD → SSPLFork: Valkey (Linux Foundation)Single vendor
MinIO2021–26Apache → AGPL → AbandonedRepo: “NO LONGER MAINTAINED”Single vendor
Kubernetes——Apache 2.0 stableFoundation (CNCF)
PostgreSQL——PostgreSQL License stableCommunity
Linux——GPLv2 stableFoundation (LF)

¿Ves el patrón? Es bastante claro: ningún proyecto respaldado por una fundación independiente ha sufrido un cambio de licencia unilateral. Ni uno. Este dato debería informar cualquier evaluación de riesgo, independientemente de la plataforma que estés considerando.

Error 04 de 10

Asumir que los costes de suscripción se mantendrán

Toda empresa que desarrolla software open source necesita monetizar su trabajo, y eso es completamente legítimo — nadie vive del aire. La cuestión no es si habrá subidas de precio (las habrá, como en todo), sino si las estás incluyendo en tu modelo de TCO.

La suscripción Community de Proxmox pasó de 49,90 € a 120 €/año (~140 % de incremento), y en enero de 2026 todos los tiers subieron otro 3,8–4,3 %. El nuevo Proxmox Datacenter Manager requiere que al menos el 80 % de los nodos tengan suscripciones Basic o superiores (370+ €/socket/año). ¿Te suena familiar? A nosotros un poco también.

OpenStack, Ceph y otras alternativas también tienen estructuras de coste propias. Ninguna plataforma es gratuita en producción — si alguien te dice lo contrario, desconfía amablemente. La diferencia está en qué costes son predecibles y cuáles dependen de decisiones unilaterales.

Perspectiva SIXE

Cuando evaluamos alternativas con nuestros clientes, siempre modelamos tres escenarios de coste: optimista, realista y adverso, con proyecciones a 5 y 10 años que incluyen posibles cambios en la estructura de licenciamiento. Sí, es más trabajo. Pero también es la única forma de hacer un TCO que no se desmorone al primer cambio de precios.

Error 05 de 10

Subestimar la complejidad operacional de OpenStack

Vamos a ser justos con OpenStack: opera en producción con más de 45 millones de cores en organizaciones como Walmart, GEICO o LINE Corp. Su gobernanza —ahora bajo la Linux Foundation— es de las más sólidas del ecosistema. Estas son ventajas reales y de peso.

Pero (siempre hay un pero) el propio proyecto reconoce que el 44 % de los proveedores IT y el 39 % de las empresas reportan dificultad para encontrar profesionales cualificados. La plataforma comprende más de 30 proyectos de servicio. Desplegar y operar ese stack requiere equipos con experiencia en sistemas distribuidos que la mayoría de los equipos VMware no poseen —no por falta de talento, sino porque son conjuntos de competencias fundamentalmente distintos. Es como pedirle a un gran chef de cocina mediterránea que prepare sushi de competición: ambos son cocina de alto nivel, pero las habilidades no se transfieren automáticamente.

Matiz importante

OpenStack puede ser la elección perfecta para organizaciones con la escala y los equipos adecuados. El modelo gestionado (Canonical, Mirantis, Platform9) resuelve parte de la complejidad, aunque añade costes y dependencia. La pregunta no es “¿OpenStack sí o no?” sino “¿nuestro equipo, presupuesto y escala encajan con lo que OpenStack necesita para brillar?”

Error 06 de 10

Asumir que Ceph es “solo activar el checkbox”

Ceph es un sistema potente y está en producción en sitios impresionantes: CERN, Bloomberg y DigitalOcean, entre otros. Pero la distancia entre un clúster Ceph a hiperescala y uno de 3–5 nodos típico de una migración VMware es como la distancia entre pilotar un Airbus y un ultraligero: ambos vuelan, pero las reglas son muy diferentes.

Los benchmarks de StarWind en entornos Proxmox HCI muestran que Ceph alcanzó 270.000 IOPS en cargas mixtas 4K, frente a 1.088.000 IOPS de LINSTOR/DRBD y 1.199.000 de StarWind VSAN. Y los riesgos de los clústeres pequeños merecen atención especial: perder un nodo en un clúster de 3 con replicación 3x puede dejar el sistema en solo lectura. No es el mejor escenario a las 3 de la madrugada de un lunes.

Existen alternativas interesantes: LINSTOR/DRBD con rendimiento cercano al nativo, StorPool con latencias sub-100 µs, IBM Storage Virtualize con integración enterprise probada. Cada opción tiene sus fortalezas, limitaciones y requisitos de expertise.

Perspectiva SIXE

La capa de storage es posiblemente la decisión más crítica y menos reversible de toda la migración. Es donde no te puedes permitir improvisar. Debe evaluarse con pruebas reales sobre cargas de trabajo reales, no con benchmarks genéricos ni con “a fulanito le va fenomenal”. Es precisamente donde un integrador con experiencia en múltiples plataformas de almacenamiento aporta más valor.

Error 07 de 10

No inventariar las funcionalidades enterprise que desaparecen

VMware lleva más de una década construyendo funcionalidades sobre las que muchas organizaciones han diseñado sus procesos operativos. Son esas cosas que “simplemente funcionan” hasta que dejan de estar ahí. Y cuando desaparecen, el impacto va mucho más allá de lo tecnológico.

⚖️

Balanceo automático (DRS)

Proxmox no tiene equivalente nativo: toca scripting propio. OpenStack ofrece funcionalidad parcial con Nova scheduling. En ambos casos, prepárate para arremangarte.

🛡️

Fault Tolerance y DR

VMware FT/SRM proporcionan failover automático. Las alternativas open source requieren orquestación propia con ZFS replication, Ansible y runbooks manuales. Funciona, pero alguien tiene que construirlo y mantenerlo.

🌐

SDN y microsegmentación

Proxmox SDN soporta VLANs/VXLANs/EVPN, pero IPAM/DHCP están en “tech preview” (léase: todavía no está listo del todo). No existe equivalente al firewall distribuido de NSX.

📋

Certificaciones de vendor

SAP, Oracle y Microsoft no certifican Proxmox. NVIDIA AI Enterprise tampoco está soportado oficialmente. Si dependes de estas certificaciones, es un detalle que conviene no pasar por alto.

🔧

Automatización y API

Los providers de Terraform para Proxmox son comunitarios. La API requiere especificar el nodo de destino manualmente. Nada insalvable, pero son fricciones que suman.

📞

Soporte 24/7

Proxmox opera en horario austriaco (7:00–17:00 CET), sin opción 24/7 a ningún nivel. Cuando producción cae a las 3 AM, literalmente no hay a quién llamar. Y no, Google no cuenta.

Ninguna de estas limitaciones invalida la plataforma — que quede claro. Pero cada una representa un hueco que hay que cubrir con ingeniería, herramientas o consultoría, y cada solución tiene un coste que debe figurar en el modelo financiero. Hacer como que no existen es la receta perfecta para sorpresas desagradables.

Error 08 de 10

Calcular el ROI solo con la línea de licenciamiento

El ahorro en licencias es real. Pero presentar ese ahorro como el ROI del proyecto es como valorar una mudanza solo por lo que cuesta el camión: técnicamente correcto, prácticamente incompleto.

Gartner estima que los servicios de migración cuestan entre 300 y 3.000 dólares por VM. El 44 % de las organizaciones sufre downtime no planificado durante la migración. Y los proyectos estimados en 6 meses se convierten en 24 con una frecuencia que ya nadie debería ignorar.

Los costes ocultos que erosionan el ROI

Formación: 5.000–15.000 $/técnico + 3–6 meses de productividad reducida (tu equipo aprende rápido, pero no es instantáneo). Integración: backup, monitorización, CMDB, automatización — conectores maduros para VMware que no existen para Proxmox. Desarrollo custom: scripts de balanceo, DR, monitorización = deuda técnica interna. Rotación: cuando el ingeniero que los construyó se marcha, el conocimiento se va con él. Y siempre se marcha en el peor momento.

Error 09 de 10

Diseñar para el Día 1 e ignorar el Día 2

La migración es solo el principio — la luna de miel, si quieres verlo así. El coste real se manifiesta en las operaciones del día a día durante años.

Cybernews reveló que muchas organizaciones que migraron a Proxmox no mantienen las actualizaciones de seguridad. Es comprensible: cuando todo el esfuerzo se concentra en migrar, es fácil olvidar que después hay que mantener. A escala, la UI se vuelve poco responsiva con varios miles de VMs y pmxcfs alcanza sus límites en torno a 11.000 VMs.

🔐

Seguridad y compliance

Gestión de CVEs, hardening, auditorías (ENS, ISO 27001, PCI DSS). ¿Qué SLA de respuesta ante vulnerabilidades críticas ofrece cada plataforma? Pregunta incómoda pero necesaria.

📊

Telemetría y observabilidad

Las alternativas open source (Prometheus, Grafana, Zabbix) son excelentes — de verdad que lo son — pero requieren integración y mantenimiento dedicado. No se configuran solas.

💾

Backup y recuperación

Proxmox Backup Server es funcional pero juega en otra liga de ecosistema comparado con Veeam, Commvault o IBM Spectrum Protect.

🏗️

Deuda técnica

Cada script custom es código que hay que mantener, documentar, testear y transferir. La deuda técnica es invisible hasta que no lo es — y entonces es lo único que ves.

Error 10 de 10

Creer que la tecnología es la decisión

La migración desde VMware no es un proyecto tecnológico: es una transformación operacional que afecta a personas, procesos, proveedores, presupuestos y riesgos. La tecnología es importante, por supuesto. Pero es solo una pieza del puzzle.

La migración de VMware no es un problema tecnológico. Es un problema de desacoplamiento operacional disfrazado de problema tecnológico.— Keith Townsend, The CTO Advisor

Las preguntas que realmente importan: ¿qué nivel de riesgo de gobernanza es aceptable para nosotros? ¿Tenemos el equipo necesario — o podemos formarlo a tiempo? ¿Cuál es nuestro TCO real a 5 y 10 años? ¿Cómo protegemos la inversión si el proyecto open source cambia de rumbo? ¿Qué cargas de trabajo migramos primero y cuáles quizá nunca deberían moverse? ¿Y quién será nuestro partner técnico cuando las cosas no funcionen como esperábamos? (Porque en algún momento, no funcionarán como se esperaba. Así es la vida.)

Nuestra convicción

El open source es, sin duda, la respuesta correcta para la infraestructura del futuro. De eso no tenemos ninguna duda. La cuestión no es si migrar, sino cómo hacerlo con el rigor que la decisión merece. La diferencia entre una migración exitosa y una que genere años de quebraderos de cabeza está en la calidad del análisis previo, la arquitectura elegida y el acompañamiento experto durante todo el proceso. Y oye, si después de leer todo esto te apetece hablar, aquí estamos.

La mejor migración es la que se hace con criterio, no con prisa

Más de 15 años diseñando, implementando y operando infraestructura de misión crítica. Conocemos VMware, Proxmox, OpenStack, Ceph, IBM Storage y las alternativas porque trabajamos con todas. Sin preferencias: solo la solución que encaja con tu negocio.

Hablemos de tu caso →
Conocer SIXE
Liquid AI’s New Model on IBM AIX

Corremos el último modelo de Liquid AI en IBM Power sin GPU | AIX

/en

Olvidémonos por un momento de los clusters de H100. En SIXE nos planteamos un reto: llevar hardware empresarial de 2018 al límite absoluto. La pregunta era simple pero ambiciosa: ¿Puede un IBM Power System ejecutando AIX y funcionando únicamente con CPU manejar modelos de IA de última generación?

Tomamos el nuevo modelo LFM2.5-1.2B de Liquid AI y lo ejecutamos en un procesador IBM POWER9. Hasta donde sabemos, esta es la primera vez que un modelo LFM2.5 funciona en AIX en modo Big-Endian.

El resultado

Casi 27 tokens por segundo, respuestas coherentes y menos de 750 MB de uso de memoria. Sin GPU. Sin NPU. Solo la potencia bruta de la arquitectura Power.

Pero la velocidad bruta es solo la mitad de la historia. Para demostrar que esto no es solo un juguete de benchmark, sometimos a LFM2.5 a un “Desafío de SysAdmin” — tareas reales de administración AIX — y lo comparamos con un Transformer estándar (TinyLlama 1.1B). Los resultados fueron impactantes.

IBM POWER9 + Liquid AI

La “salsa secreta”: ¿Qué es LFM2.5?

LFM2.5 es una arquitectura híbrida diseñada para máxima eficiencia, combinando bloques convolucionales (shortconv) para velocidad y capas de atención (GQA) para contexto. Cuenta con una enorme ventana de contexto de 128k tokens — suficiente para leer miles de líneas de logs sin olvidar el principio.

El hardware: IBM Power S924

Estas son las configuraciones específicas del benchmark:

EspecificaciónValor
ServidorIBM Power System S924
ProcesadorIBM POWER9 @ 2.75 GHz
ConfiguraciónEnterprise Multi-Core (compatible SMT-8)
Sistema operativoAIX 7.3 TL4
ArquitecturaBig-Endian

Rendimiento: encontrando el punto óptimo

Descubrimos que lanzar todos los núcleos contra el modelo perjudica el rendimiento debido a la sobrecarga de sincronización. El veredicto fue claro: usar solo 8 núcleos en modo SMT-2 (16 hilos) nos dio 26.7 tokens por segundo.

El momento de las pruebas: el desafío del admin

Los números están bien, pero ¿realmente funciona? Ejecutamos exactamente los mismos prompts a través de LFM2.5-1.2B y TinyLlama 1.1B (un transformer puro de tamaño similar). Aquí están las salidas reales.

Ronda 1: El error críptico (errpt)

Alimentamos los modelos con un log de error AIX relacionado con un fallo en la fuente de alimentación.

La entrada:

$ errpt -a -l BFE4C025

Description: Power/Cooling subsystem Unrecovered Error,
             bypassed with loss of redundancy.
Possible FRUs:
  Priority: H
  FRU:      PWRSPLY
  Location: U78D2.001.WZS00P4

❌ TinyLlama 1.1B:

“7. What is the location of the FRU that is affected by this error? The FRU that is affected by this error is PWRSPLY. 8. What is the description of the FRU that is affected by this error? The FRU that is affected by this error is PWRSPLY…”

Veredicto: Fallo. Se quedó atascado en un bucle infinito repitiendo “PWRSPLY”.

✅ LFM2.5 1.2B:

“What is the likely cause? The error usually points to a problem with the power or cooling hardware (like a fan or power supply) that couldn’t be fixed automatically. It might be a hardware failure or a misconfiguration. What action should I take? First, check the hardware — look at the fans (especially the power fans)…”

Veredicto: Éxito. Identificó el componente y dio consejos accionables para revisar los ventiladores.

Ronda 2: La auditoría de seguridad

Proporcionamos un historial de logins que contenía un evento de crash oculto.

La entrada:

$ last -20

root   pts/0   10.10.10.1   Jan 28 11:14 - 18:38 (07:23)
reboot ~                     Jan 28 11:12
root   pts/0   10.10.10.1   Jan 27 22:09 - System halted abnormally. (13:03)

❌ TinyLlama 1.1B:

(generó 1 token y se detuvo)

Veredicto: Fallo. Silencio absoluto.

✅ LFM2.5 1.2B:

“Suspicious patterns: The system was halted abnormally on Jan 27. This could indicate a security incident or a misconfiguration. Security recommendations: Investigate the cause of the system halt on Jan 27. Review the login history for any unauthorized access attempts.”

Veredicto: Éxito. Detectó inmediatamente la detención anormal del 27 de enero y recomendó una investigación.

Ronda 3: El consejo peligroso (/etc/passwd)

Pedimos a los modelos que auditaran un archivo de contraseñas estándar. Los resultados aquí fueron impactantes.

La entrada:

$ cat /etc/passwd

root:!:0:0::/:/usr/bin/bash
daemon:!:1:1::/etc:
bin:!:2:2::/bin:
...

❌ TinyLlama 1.1B:

“1. root:!:0:0::/:/usr/bin/bash — This user is not required for system maintenance and should be removed. 2. daemon:!:1:1::/etc: — This user is not required for system maintenance and should be removed.”

Veredicto: FALLO CATASTRÓFICO. Afirmó que el usuario “root” no era necesario y recomendó eliminarlo. Seguir este consejo destruiría el servidor.

✅ LFM2.5 1.2B:

“Unauthorized or suspicious accounts: You should be very concerned about the presence of the following accounts: guest with a high UID (100), nobody with a high UID (4294967294)… These accounts are either misconfigured, potentially malicious, or not needed.”

Veredicto: Éxito. Identificó correctamente riesgos potenciales reales como las cuentas “guest” y “nobody” con UIDs altos.

Ronda 4: Endurecimiento de servicios (lssrc -a)

Pedimos a los modelos que revisaran los servicios en ejecución.

La entrada:

$ lssrc -a

Subsystem    Group      Status
sendmail     mail       active
portmap      portmap    active
inetd        tcpip      active
snmpd        tcpip      active

❌ TinyLlama 1.1B:

(generó 0 tokens)

Veredicto: Fallo. Silencio de nuevo.

✅ LFM2.5 1.2B:

“1. sendmail Risk: Running mail daemon can be a target for attacks. Recommendation: Disable sendmail. stopsrc -s sendmail 2. portmap Risk: Running portmap daemon can be abused… stopsrc -s portmap”

Veredicto: Éxito. Marcó servicios arriesgados como sendmail y portmap, y proporcionó el comando AIX correcto (stopsrc) para deshabilitarlos.

Por qué esto importa para los usuarios de IBM Power

Este benchmark demuestra que los IBM Power son motores de inferencia de IA capaces para tareas críticas on-premise:

Soberanía de datos: Analiza logs errpt sensibles, datos financieros o auditorías de usuarios localmente. Ningún dato sale de tu servidor.

Modernización de legacy: Usa LLMs locales para ayudar a entender y documentar código legacy COBOL o C que reside en el servidor.

Eficiencia: No necesitas un cluster de GPUs. Probablemente ya tienes el hardware capaz de hacer esto.

Pruébalo tú mismo :)

En SIXE creemos en el código abierto. Te dejamos aquí el código y el modelo para que puedas hacer tus pruebas. Cualquier aportación que quieras hacer, somos todo oídos.

Código: gitlab.com/librepower/llama-aix

Modelos: huggingface.co/librepowerai

user@aix:~$ # Inicio rápido en AIX
user@aix:~$ git clone https://gitlab.com/librepower/llama-aix.git
user@aix:~$ ./scripts/build_aix_73.sh

user@aix:~$ # Optimizar threading para el "punto óptimo"
user@aix:~$ smtctl -t 2 -w now

user@aix:~$ # ¡A disfrutar!
Flash systems 2026

Nuevo IBM FlashSystem 2026 | 5600, 7600 y 9600

/en

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.

Nuevo Flash System Storage de IBM para 2026

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 5600FlashSystem 7600FlashSystem 9600
Factor de forma1U · 12 drives2U · 32 drives2U · 32 drives (antes 4U)
CPU2×12 Core Intel Xeon · PCIe Gen 42×16 Core AMD EPYC · PCIe Gen 52×48 Core AMD EPYC · PCIe Gen 5
Capacidad raw633 TB1,68 PB3,37 PB (vs 1,8 PB del 9500)
Capacidad usable400 TBu1,2 PBu2,4 PBu
Capacidad efectivaHasta 2,4 PBeHasta 7,2 PBeHasta 11,8 PBe
IOPS2,6 millones4,3 millones6,3 millones
Read BW30 GB/s55 GB/s86 GB/s (vs 100 GB/s del 9500)
Puertos16× FC o 20× Ethernet32× FC o Ethernet32× FC o Ethernet (vs 48 del 9500)
Caso de usoEdge, ROBO, CPDs pequeñosVirtualización, analíticasBanca, 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:

AspectoIBM FlashSystem (nuevo)Pure Storage FlashArrayDell PowerStoreNetApp AFF
Unidades propietarias✅ FlashCore Module (QLC→TLC)✅ DirectFlash (150 TB)❌ SSDs estándar❌ SSDs estándar
IA en gestiónFlashSystem.ai (agéntica)Pure1 MetaCloudIQBlueXP / AIOps
Detección ransomware HW✅ En la unidad flash❌ Software❌ Software❌ Software (ONTAP)
Soporte cabinas 3ros✅ +500 vendors❌ Ecosistema cerradoParcialParcial (FabricPool)
Cifrado quantum-safe HW✅❌❌❌
Modelo de licenciamientoTradicional IBMEvergreen (muy transparente)APEX / tradicionalKeystone / 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 unidad flash propietaria para nuevo IBM FlashSystem con detección ransomware por hardware

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

/en

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.

minio vs ceph se 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:

  1. Governance de fundación: Ceph es un proyecto de la Linux Foundation con gobierno abierto. No puede pasar lo de MinIO.
  2. Comunidad activa: Miles de contribuidores, releases regulares, bugs corregidos rápidamente.
  3. Flexibilidad: Es tu cluster, tu configuración. Si mañana decides cambiar de partner de soporte, no pierdes nada.
  4. TCO transparente: El software es gratis. Inviertes en hardware apropiado y en conocimiento.
  5. 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.


Conclusiones para 2026

  1. MinIO está muerto para uso serio. Busca alternativas. Ceph RGW, SeaweedFS, o incluso el fork OpenMaxIO si eres valiente.
  2. 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.
  3. Ceph upstream está maduro y es production-ready. Bloomberg, DigitalOcean, CERN y 320+ proyectos de telecos no pueden estar todos equivocados.
  4. 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.
  5. El control sobre tu infraestructura tiene valor. Pregúntale a los clientes de SUSE SES cómo les fue cuando el vendor decidió pivotar.
  6. 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.

mariadb en AIX

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

/en

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.

Engineering debugging process visualization

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ónQPS SecuencialCon 12 workers
Base42~42
+ 4 GB caché112–
+ 64K pages2082.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ó)

IntentoResultadoRazón
-flto (Link Time Optimization)ImposibleGCC LTO requiere formato ELF; AIX usa XCOFF.
-fprofile-generate (PGO)Falla compilaciónErrores del ensamblador con reubicación TOC.
-ffast-mathRompe todoViolaciones IEEE corrompen el hash del Bloom filter.
-funroll-loopsMás lentoInfla 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:

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

Y entonces, lancé el benchmark:

Compilador30 ConsultasPor consulta
GCC 13.3.00.190s6,3 ms
Open XL 17.1.30.063s2,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:

  1. Compilar con -fprofile-generate
  2. Ejecutar carga de entrenamiento
  3. 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 LPARGCCOpen XL
12 vCPUs compartidas0.190s0.063s
12 dedicadas (Capped)0.205s0.082s
21 dedicadas (Capped)0.320s0.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.

ModoGCCOpen XL
Capped0.205s0.082s
Donating0.325s0.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:

PlataformaNúcleos30 Consultas
Linux24 dedicados0.057s
AIX + Open XL12 compartidos0.063s
AIX + Open XL21 dedicados0.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:

  1. Una caché mal configurada (16MB vs 4GB).
  2. Tamaño de página incorrecto (4 KB vs 64 KB).
  3. 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é probamosResultadoNotas
mhnsw_max_cache_size = 4GB5x más rápidoElimina el “thrashing” de caché.
LDR_CNTRL 64K pages~40% más rápidoReduce fallos de TLB.
IBM Open XL 17.1.33x más rápidoMejor generación de código POWER9.
Open XL + LTO27% más lentoConflicto con exportaciones AIX.
POWER VSX Bloom Filter41% más lentoNo hay multiplicación de vectores de 64-bit en P9.
Software PrefetchingSin efectoEl hipervisor desaloja los datos antes de usarlos.
DSCR TuningBloqueadoEl 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:

  1. Usa la build con Open XL (versión 3, próximamente).
  2. Configura mhnsw_max_cache_size a mínimo 4GB si usas vectores.
  3. Usa LPAR compartida para latencia de consultas individuales (WoF ayuda).
  4. Nunca uses modo “Donating” para BBDD.
  5. 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.
mariadb en AIX

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

/en

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.

MariaDB en AIX

“¿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:

PlataformaAPIEstado
LinuxepollSoportado
FreeBSD/macOSkqueueSoportado
Solarisevent portsSoportado
WindowsIOCPSoportado
AIXpollsetNo 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:

PruebaResultado
100 conexiones concurrentes✓
500 conexiones concurrentes✓
1.000 conexiones✓
30 minutos de carga sostenida✓
Más de 11 millones de queries✓
Memory leaksCERO

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ón100 clientes mixtosvs. Baseline
Original -O2 un hilo por conexión11.34s–
-O3 + Thread Pool v111.96s83% 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)

  1. 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.
  2. 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.
  3. -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.
  4. 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.
  5. 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.
  6. 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 🌍

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

/en

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.

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)

/en

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:

NivelSignificado
✅ Works on PowerCompila y ejecuta correctamente en ppc64le. Validación básica.
⚡ Optimized for PowerAjustado para SMT, VSX/MMA. Incluye datos de rendimiento.
🏆 LibrePower CertifiedValidació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:

¿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. 🌍

OpenUEM soporte y despliegue

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

/en

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.

OpenUEM

¿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:

  1. El agente: Se instala un pequeño programa en los equipos finales.

  2. El servidor: Recopila la información en tiempo real y permite ejecutar acciones.

  3. 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.

Logo Claroty xDome vs CTD

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

/en

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.

Interfaz de Claroty visualizando activos OT

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:

  1. 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).

  2. Nozomi: Muy fuerte en visibilidad pasiva.

  3. 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

SIXE