¡Nos vemos en Common Iberia 2025!

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

Cartel Common Iberia 2025Click en la imagen para acceder al formulario de registro del evento

Nuestras sesiones en Common Iberia Madrid:

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

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

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

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

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


Reserva tu plaza ahora

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

Almacenamiento open source para IA y HPC: cuando Ceph deja de ser una alternativa para convertirse en el único camino viable

Cuando el CERN necesita almacenar y procesar los datos del Gran Colisionador de Hadrones (en inglés Large Hadron Collider o LHC, el acelerador de partículas más grande y potente del mundo), la escala lo condiciona todo. A ese nivel, la técnica y la economía convergen en una conclusión clara: tecnologías open source como Ceph, EOS y Lustre no son una “alternativa” a las soluciones enterprise tradicionales; en muchos escenarios, son el único camino viable.

Con más de 1 exabyte de almacenamiento en disco, 7.000 millones de archivos y 45 petabytes semanales procesados durante las campañas de toma de datos, el mayor laboratorio de física de partículas del mundo se mueve en un terreno donde los modelos clásicos de licencias por capacidad dejan de tener sentido económico.

Esta realidad, documentada en el paper presentado en CHEP 2025, “Ceph at CERN in the multi-datacentre era”, refleja lo que cada vez más universidades y centros de investigación están comprobando: hay casos de uso donde el open source no compite con las soluciones enterprise, define su propia categoría, para la que las arquitecturas tradicionales simplemente no fueron diseñadas.

almacenamiento open source cern

El CERN: cifras que cambian las reglas

Las cifras del CERN no solo impresionan; explican por qué se eligen ciertas tecnologías:

  • >1 exabyte de almacenamiento en disco, distribuido en ~2.000 servidores con 60.000 discos. 
  • >4 exabytes de transferencias anuales. 
  • Hasta 45 PB/semana y un throughput sostenido >10 GB/s en periodos de toma de datos. 

La arquitectura es heterogénea por necesidad:

  • EOS para los ficheros de física (más de 1 EB). 
  • CTA (CERN Tape Archive) para archivo a largo plazo. 
  • Ceph (más de 60 PB) para bloques, objetos S3 y CephFS, vertebrando OpenStack. 

Lo relevante no es solo el volumen, sino la trayectoria. En una década han pasado de unos pocos petabytes al exabyte sin saltos arquitectónicos disruptivos, añadiendo nodos commodity de forma horizontal. Esa elasticidad no existe en las cabinas propietarias con licencias por capacidad.

La economía del exabyte: dónde fallan los modelos por capacidad

Los modelos de licencias actuales en el mercado enterprise son razonables para entornos típicos (decenas o cientos de terabytes, crecimientos previsibles, CapEx y OpEx equilibrados). Aportan integración, soporte 24×7, certificaciones y un ecosistema de partners. Pero a escala petabyte o exabyte con crecimientos rápidos, la ecuación cambia.

  • En SIXE somos Premier Partner de IBM, y hemos evolucionado hacia licencias basadas en capacidad. 
    • IBM Spectrum Virtualize utiliza Storage Capacity Units (SCU): ~1 TB por SCU. El coste anual por SCU puede oscilar entre 445 y 2.000 €, según volumen, perfil de cliente y condiciones del entorno. 
    • IBM Storage Defender usa Resource Units (RUs). Por ejemplo, IBM Storage Protect consume 17 RUs/TB para los primeros 100 TB y 15 RUs/TB para los siguientes 250 TB, permitiendo combinar capacidades de resiliencia bajo una licencia unificada. 
  • Modelos similares existen en NetApp (term-capacity licensing), Pure Storage, Dell Technologies y otros: pagar por capacidad gestionada o aprovisionada. 

Todo esto funciona en entornos enterprise convencionales. Sin embargo, gestionar 60 PB bajo licencias por capacidad, incluso con descuentos altos por volumen, puede traducirse en millones de euros anuales solo en software, sin contar hardware, soporte o servicios. En ese punto, la pregunta ya no es si el open source es “viable”, sino si existe alguna alternativa realista a él para esas escalas.

Capacidades técnicas: un open source ya maduro

La ventaja económica no valdría si la tecnología fuese inferior. No es el caso. Para ciertas cargas de IA y HPC, las capacidades son equivalentes o superiores:

  • Ceph ofrece virtualización unificada de almacenamiento con thin provisioning, compresión en BlueStore, snapshots y clones COW sin penalización significativa, replicación multisite (RGW y RBD), y tiering entre medios, y si quieres que tu equipo comprenda cómo sacarle partido a Ceph, tenemos… 
  • El CERN documenta estrategias multi-datacenter para continuidad de negocio y disaster recovery usando stretch clusters y multisite replication, con RPO/RTO comparables a soluciones enterprise. 

IBM reconoce esta madurez con IBM Storage Ceph (derivado de Red Hat Ceph Storage), que combina tecnología open source con soporte, certificaciones y SLAs de nivel enterprise. En SIXE, como IBM Premier Partner, implementamos IBM Storage Ceph cuando se requiere soporte comercial y también Ceph upstream cuando se prioriza flexibilidad e independencia.

Diferencia clave de arquitectura:

  • IBM Spectrum Virtualize es una capa enterprise que gestiona almacenamiento heterogéneo de bloque, con nodos o instancias dedicadas, y funciones avanzadas de movilidad, replicación y automatización. 
  • Ceph es un sistema distribuido nativo que sirve bloques, objetos y archivos desde la misma infraestructura horizontal, eliminando silos. En pipelines de IA —objetos para datasets, bloques para metadatos, archivos compartidos para colaboración— esta unificación aporta ventajas operativas claras. 

Conceptual digital illustration symbolizing mature open source storage technology. Three distinct data flows (subtly different colors) converge into a single glowing structure, symbolizing integration and scalability. The environment evokes a modern data center with soft blue and white lighting, clean geometry, and a sense of precision and reliability.

IA a gran escala y HPC: donde lo distribuido brilla

Las cargas de entrenamiento de modelos fundacionales leen petabytes en paralelo, con anchos de banda agregados de 100 GB/s o más. La inferencia exige latencias sub-10 ms con miles de peticiones concurrentes.

Las arquitecturas tradicionales con controladoras SAN sufren cuellos de botella cuando cientos de GPU (A100, H100…) acceden a datos a la vez. Se estima que alrededor del 33 % de las GPUs en entornos corporativos de IA trabajan por debajo del 15 % de uso por saturación del almacenamiento, con el consiguiente coste en activos infrautilizados.

Las arquitecturas distribuidasCeph, Lustre, BeeGFS— nacieron para estos patrones:

  • Lustre impulsa 7 de los 10 supercomputadores del Top500, con >1 TB/s de throughput agregado en grandes instalaciones. Frontier (ORNL) usa ~700 PB en Lustre y escribe >35 TB/s sostenidos. 
  • BeeGFS escala almacenamiento y metadatos de forma independiente, superando 50 GB/s sostenidos con decenas de miles de clientes en producción. 
  • MinIO, optimizado para objetos en IA, ha demostrado >2,2 TiB/s de lectura en entrenamiento, difícil de igualar por arquitecturas centralizadas. 

La integración con GPU también ha madurado: GPUDirect Storage permite que las GPUs lean desde NVMe-oF sin pasar por la CPU, reduciendo latencia y liberando ciclos. Los sistemas open source modernos soportan estos protocolos de forma nativa; en soluciones propietarias, a menudo dependen de firmware y certificaciones que tardan trimestres en llegar.

SIXE: open source sostenible, con o sin soporte comercial

Migrar a almacenamiento open source a gran escala no es trivial. Los sistemas distribuidos requieren experiencia específica.

En SIXE llevamos más de 20 años con Linux y open source. Como IBM Premier Partner, ofrecemos lo mejor de ambos mundos:

  • IBM Storage Ceph e IBM Storage Scale (antes Spectrum Scale/GPFS) para quienes necesitan SLAs garantizados, certificaciones y soporte global 24×7. 
  • Ceph upstream (y tecnologías afines) para organizaciones que prefieren máxima flexibilidad y control. 

No es una postura contradictoria, sino estratégica: distintos perfiles, distintas necesidades. Un banco multinacional valora certificaciones y soporte enterprise. Un centro de investigación con equipos técnicos fuertes puede operar upstream directamente.

Nuestras formaciones intensivas en Ceph son talleres prácticos de tres días: se despliegan clústeres reales y se explican las decisiones de diseño. La transferencia de conocimiento reduce la dependencia de consultores y empodera al equipo interno. Si tu equipo aún tiene poca experiencia con Ceph, haz click aquí para ver nuestro curso de iniciación, si por el contrario quieres exprimir al máximo Ceph, te dejamos aquí el curso avanzado en Ceph, donde tu equipo será capaz de integrar dos factores tecnológicos cruciales ahora mismo: Almacenamiento + IA. 

 

Nuestra filosofía: no vendemos tecnología, transferimos capacidad. Implementamos IBM Storage Ceph con soporte completo, Ceph upstream con nuestro respaldo especializado o enfoques híbridos, según cada caso.

La oportunidad para ciencia y datos masivos

Se alinean varios factores:

  • Los datos crecen exponencialmente: un NovaSeq X Plus puede generar 16 TB por ejecución; el telescopio SKA producirá exabytes anuales; los modelos de IA demandan datasets crecientes. 
  • Los presupuestos no crecen al mismo ritmo. Los modelos de licencias por capacidad hacen inviable escalar sistemas propietarios al ritmo requerido. 

Las soluciones open source, ya sea upstream o comercialmente soportadas (p. ej., IBM Storage Ceph), eliminan esa dicotomía: se planifica el crecimiento por coste de hardware y capacidad operativa, con software cuyos costes no escalan linealmente por terabyte.

Centros como Fermilab, DESY, el propio CERN o el Barcelona Supercomputing Center han demostrado que este enfoque es técnicamente viable y operativamente superior para sus casos. En su paper reciente, el CERN detalla multi-datacenter para DR con Ceph (stretch y multisite), logrando disponibilidad comparable a soluciones enterprise, con flexibilidad y control total.

Un ecosistema en plena madurez: planificar ahora

El ecosistema de almacenamiento open source para HPC e IA evoluciona rápido:

  • Ceph Foundation (Linux Foundation) coordina contribuciones de CERN, Bloomberg, DigitalOcean, OVH, IBM, entre otros, alineadas con necesidades reales de producción. 
  • IBM mantiene IBM Storage Ceph como producto soportado y contribuye activamente upstream. 

Es la confluencia ideal entre innovación open source y respaldo enterprise. Para organizaciones con horizonte de décadas, la pregunta ya no es si adoptar open source, sino cuándo y cómo hacerlo de forma estructurada.

La tecnología es madura, los casos de éxito están documentados y el soporte existe tanto en modalidad comunitaria como comercial. Lo que suele faltar es el expertise para trazar la hoja de ruta: modelo (upstream, comercial o híbrido), dimensionamiento, formación y operación sostenible.

SIXE: tu partner hacia un almacenamiento que crece contigo

En SIXE trabajamos en esa intersección. Como IBM Premier Partner, accedemos a soporte de primer nivel, roadmaps y certificaciones. A la vez, mantenemos expertise profundo en upstream y en otras tecnologías del ecosistema, porque no hay una única solución válida para todo.

Cuando un centro nos contacta, no empezamos por el catálogo, sino por las preguntas clave:

  • ¿Cuáles son tus patrones de acceso? 
  • ¿Qué crecimiento proyectas? 
  • ¿Qué capacidades tiene tu equipo? 
  • ¿Qué riesgos puedes asumir? 
  • ¿Qué presupuesto manejas (CapEx/OpEx)? 

Las respuestas guían la recomendación: IBM Storage Ceph con soporte enterprise, upstream con nuestro soporte, un híbrido, o incluso valorar si una solución tradicional sigue teniendo sentido en tu caso. Diseñamos soluciones que funcionen a 5 y 10 años, lo importante para nosotros es crear soluciones duraderas y sostenibles en el tiempo ;)

Nuestro compromiso es con tecnologías sostenibles, no sujetas a vaivenes comerciales, que den control sobre la infraestructura y escalen técnica y económicamente.

El caso del CERN no es una curiosidad académica: muestra hacia dónde va el almacenamiento para cargas intensivas en datos. La cuestión no es si tu organización llegará ahí, sino cómo llegará: preparada o a la carrera. La ventana de oportunidad para planificar con calma está abierta. Los éxitos existen. La tecnología está lista. El ecosistema también. Falta tomar la decisión estratégica de invertir en infraestructuras que acompañen a tu organización en las próximas décadas de crecimiento de datos.

¿Hablamos?

¿Tu organización genera volúmenes masivos de datos para IA o investigación? En SIXE ayudamos a centros de investigación, universidades y organizaciones innovadoras a diseñar, implementar y operar almacenamiento escalable con Ceph, Storage Scale y otras tecnologías líderes, tanto upstream como con soporte comercial de IBM, según tus necesidades. Contáctanos para una consulta estratégica sin compromiso.

Referencias

Cómo hacer tu primer agente de N8N IA de forma gratuita

Las automatizaciones están a la orden del día. Seguro que has leído miles de noticias y has usado chatgpt. Sin embargo, hay una forma de sacarle partido… MUCHO partido. Hoy te vamos a enseñar a dar tus primeros pasitos. Te enseñaremos cómo crear tu primer agente inteligente con n8n IA desde cero, completamente gratis, y sin complicarte la vida. Si tu negocio recibe preguntas repetitivas por email, formularios o chat, este tutorial es para ti.

Vamos a montar un chatbot que responda preguntas sobre tu empresa, recopile datos de clientes cuando sea necesario, y además verifique si ya existen en tu base de datos para no duplicarlos. Todo esto usando n8n con Ollama, modelos de IA locales, y Docker.

¿Qué es n8n? ¿qué tiene que ver con la IA y por qué puede servir para mi empresa?

n8n es una plataforma de automatización de código abierto (como Zapier o Make) que te permite conectar aplicaciones, bases de datos, APIs y, lo más importante para nosotros hoy, modelos de inteligencia artificial.

Lo que hace especial a n8n es que puedes crear flujos de trabajo (workflows) visuales arrastrando nodos, sin necesidad de ser un crack programando. Y como es open source, tienes control total sobre tus datos.

Las 3 formas de usar n8n (y cuál es la mejor)

Antes de meternos en faena, te explicaremos las opciones que tienes para trabajar con n8n:

1. n8n Cloud (la opción rápida)

La versión en la nube de n8n. Te registras, pagas una suscripción mensual y ya está. Cero instalación, cero mantenimiento. Perfecto si quieres empezar ya mismo, pero tiene limitaciones en el plan gratuito y tus datos están en servidores de terceros. ¿Problema? quizá el precio…n8n precios 2025

2. En local en tu ordenador (lo que haremos hoy)

Instalas n8n en tu máquina local con Docker. Es gratis al 100%, ideal para aprender y hacer pruebas. El problema es que solo funciona cuando tu ordenador está encendido. Si lo apagas, adiós workflows.

3. VPS con n8n (la opción más práctica y eficiente)

Contratas un VPS (servidor privado virtual) y montas n8n ahí. Tu agente de IA estará disponible 24/7, los 365 días del año. Es la opción profesional si quieres que tu negocio funcione sin interrupciones. Es la opción que recomendamos y tenemos una buena noticia: Con el código SIXE puedes conseguir descuento en tu VPS para tener n8n siempre disponible. Contáctanos para más información sobre cómo configurarlo.

Hoy vamos a usar la opción 2 (local con Docker) para que aprendas sin gastar un euro. Luego, cuando veas el potencial, puedes migrar fácilmente a un VPS.

Requisitos previos para usar n8n en local

Antes de empezar, asegúrate de tener:

  • Windows 10/11 (64-bit)
  • Recomendamos al menos 8GB de RAM (necesario para ejecutar modelos de IA localmente)
  • Ganas de aprender (esto es gratis)

Paso 1: Instalar Docker

Docker Desktop es la forma más sencilla de usar Docker en Windows. Descárgalo haciendo click aquí. Para verificar que lo hayas instalado escribe docker --version para comprobar que esté listo.

Si ves la versión, ¡perfecto! Docker está listo.

Paso 2: Instalar n8n con Docker Desktop

Ahora viene la parte fácil. Con un solo comando tendrás n8n funcionando.

Pasos:

  1. Abre PowerShell
  2. Ejecuta este comando:
docker run -it --rm --name n8n -p 5678:5678 -v n8n_data:/home/node/.n8n n8nio/n8n

¿Qué hace este comando?

  • docker run: ejecuta un contenedor
  • -it: modo interactivo (verás los logs en tiempo real)
  • --rm: borra el contenedor al cerrarlo (no te preocupes, los datos se guardan en el volumen)
  • --name n8n: le pone nombre “n8n” al contenedor
  • -p 5678:5678: mapea el puerto 5678 (accederás por http://localhost:5678)
  • -v n8n_data:/home/node/.n8n: crea un volumen para guardar tus workflows
  1. Espera unos 30-60 segundos mientras descarga la imagen de n8n
  2. Cuando veas algo como Editor is now accessible via: http://localhost:5678/, ya lo tienes
  3. Abre tu navegador y ve a: http://localhost:5678
  4. Crea tu cuenta local:
    • Email: el que quieras (es local, no se envía a ningún sitio)
    • Contraseña: la que quieras
    • Nombre: tu nombre o el de tu negocio

¡Ya tenemos todo disponible para usar n8n! Para cualquier duda, recomendamos seguir el tutorial oficial de n8n (haz click aquí para verlo). Si vas a usar Ollama, como es nuestro caso, te recomendamos que uses el pack oficial que incluye Ollama y así tengas todo en el mismo entorno. Click aquí para n8n + ollama.

Paso 3: Instalar Ollama (tu modelo de IA local)

Para usar n8n IA necesitamos un modelo de lenguaje. Vamos a usar Ollama, que ejecuta modelos de IA directamente en tu ordenador, gratis y sin límites. Es decir, puedes usar con los recursos de tu ordenador modelos de IA.

Instalar Ollama en Windows:

  1. Descarga Ollama haciendo click aquí (oficial)
  2. Instala Ollama
  3. Verifica la instalación:
    • Abre PowerShell
    • Escribe: ollama --version
    • Deberías ver la versión instalada

Descargar el modelo recomendado:

Vamos a usar Qwen2.5:1.5b, un modelo pequeño pero potente, perfecto para chatbots empresariales. Es rápido y no necesita un superordenador. Sin embargo, desde aquí puedes encontrar miles de modelos para usar.

En la shell, ejecuta:

ollama pull qwen2.5:1.5b

Verificar que funciona:

ollama run qwen2.5:1.5b

Si te sale un prompt interactivo donde puedes escribir, funciona. Escribe /bye para salir.

Debes tener en cuenta una cosa bastante importante: Los agentes dependiendo de su modelo de IA podrán usar tools o no. Puedes usar otros modelos como

Cuanto mayor el modelo, mejores respuestas pero más RAM necesitas. Esto se traduce en tiempo de respuesta.

 

Paso 4: Configurar Ollama para n8n

Aquí viene un paso crítico. Docker Desktop en Windows tiene un pequeño “problema” de red que debemos solucionar. Ollama está corriendo en tu Windows, pero n8n está dentro de un contenedor Docker. Necesitan hablar entre ellos.

La solución:

  1. Detén n8n si lo tienes corriendo (Ctrl + C en PowerShell)
  2. Vuelve a arrancar n8n con este comando:
docker run -it --rm --name n8n -p 5678:5678 --add-host=host.docker.internal:host-gateway -v n8n_data:/home/node/.n8n n8nio/n8n

El parámetro --add-host=host.docker.internal:host-gateway permite que n8n acceda a Ollama.

  1. Anota esta URL porque la necesitarás: http://host.docker.internal:11434

Esa es la dirección que usarás para conectar n8n con Ollama.

Paso 5: Crear tu primer agente en n8n

¿Qué tal vas? vamos a empezar a divertirnos. Vamos a crear un chatbot que:

  • Responda preguntas sobre tu negocio usando información de un documento
  • Recopile datos de clientes interesados
  • Busque si el cliente ya existe antes de guardarlo
  • Avise a tu equipo cuando alguien necesite atención humana

Importar el workflow base:

En SIXE nos gusta hacerte las cosas fáciles. En lugar de crear todo desde cero, te vamos a regalar una plantilla y la personalizaremos para ti.

  1. En n8n, haz clic en “Workflows” (menú superior)
  2. Haz clic en el botón “+ Add workflow” y selecciona “Import from File”
  3. Descarga aquí la plantilla del tutorial de ia con n8n de SIXE. 
  4. Importa el archivo en n8n (en el workflow, hay un iconito de más, click e importar desde archivo).

Configurar el modelo de IA (Ollama):

  1. En el workflow, arrastra un nodo nuevo desde el panel izquierdo
  2. Busca “Ollama Chat Model” y añádelo al canvas
  3. Haz clic en el nodo Ollama para configurarlo:
    • Base URL: http://host.docker.internal:11434
    • Model: qwen2.5:1.5b
    • Temperature: 0.7 (controla la creatividad: 0 = muy preciso, 1 = muy creativo)
  4. Conecta el nodo Ollama al nodo “AI Agent”:
    • Arrastra desde el punto (abajo) del nodo Ollama
    • Hasta el punto del nodo AI Agent
    • Esto le dice al agente que use Ollama como cerebro

Personalizar el prompt del agente:

El prompt es la personalidad de tu chatbot. Aquí le dices qué hace, cómo habla y qué información tiene.

  1. Haz clic en el nodo “AI Agent”
  2. En “System Message”, copia este prompt y personalízalo:
Eres el asistente virtual oficial de "[TU EMPRESA]".

Tu función es ayudar a los usuarios que escriben al chatbot de la web, ofreciendo respuestas claras, útiles y verídicas.

📌 Reglas principales:
- Nunca inventes información
- Si no sabes algo, admítelo y ofrece derivar al equipo humano
- Sé profesional pero cercano

🧠 Información sobre [TU EMPRESA]:
[Aquí describe tu negocio: qué hacéis, servicios, precios, horarios, etc.]

Ejemplo:
"Somos una agencia de automatización que ayuda a empresas a ahorrar tiempo usando herramientas como n8n, Airtable y Make. Nuestros servicios incluyen:
- Consultoría inicial (gratis)
- Implementación de automatizaciones (desde 500€)
- Formación para equipos (200€/persona)
Horario: L-V de 9h a 18h"

📩 Si detectas interés en contratar:
Pregunta educadamente:
- Nombre
- Email
- Teléfono (opcional)
- Qué necesita específicamente

Una vez tengas estos datos, los guardarás automáticamente.

🔄 Si no puedes ayudar:
Ofrece derivar al equipo humano y contacto por WhatsApp.

Añadir memoria al chatbot:

Para que el chatbot recuerde la conversación (no repita preguntas), necesita memoria.

  1. Haz clic en el nodo “AI Agent”
  2. Busca la sección “Memory” en las opciones del agente
  3. Añade un nodo de memoria (memoria simple que recuerda los últimos mensajes, con 5, que es el predeterminado de mensajes, debería de ser suficiente)

Ya tienes un chatbot funcional. Pero vamos a añadirle más chicha.

Paso 6: Añadir conocimiento y herramientas al agente

Las herramientas son como apps que el agente puede usar cuando las necesita. Vamos a añadir las esenciales. Para empezar a crear dale a añadir tool al agente.

Tool 1: Google Docs (base de conocimiento)

En lugar de meter toda la info en el prompt (que tiene límite), usaremos un Google Doc como base de conocimiento.

  1. Crea un Google Doc con toda la información posible de tu negocio
Pregunta: ¿Cuánto cuestan vuestros servicios?
Respuesta: Nuestro servicio básico cuesta X€, el premium Y€...

Pregunta: ¿Cuánto tarda un proyecto?
Respuesta: Entre 2-4 semanas dependiendo de la complejidad...

[Añade todas las preguntas frecuentes, horario, contacto etc]
  1. En n8n, arrastra el nodo “Google Docs Tool”
  2. Conecta tu Google Account. Este paso es algo pesado si no tienes experiencia pero te prometemos guiarte de la forma más sencilla posible.
    1. Inicia sesión en Google Cloud Console
    2. Crea un proyecto si no lo tienes
    3. Ve a APIs y servicios y en credenciales configura la pantalla de consentimiento
      Conecta Google Sheets, Docs y Drive a N8N
    4. Una vez hecho eso, añade el servicio de google que necesites. En nuestro caso, google docs. Google Docs API con n8n
    5. Volvemos a APIs/credenciales y creamos un cliente de OAuth. Ahí lo más importante es dar permisos y en “URL de redireccionamientos autorizados” pondremos la URL que nos arroja n8n.Conectar n8n con Google Docs
    6. Copiamos el ID de cliente y el secreto y los ponemos en n8n.
  3. Selecciona el documento que creaste
  4. Conecta el nodo al AI Agent

Ahora el chatbot puede consultar ese documento cuando alguien pregunta. Recuerda que es importante indicarle al agente cuándo debe usar cada herramienta en “System Message” dentro de la configuración del agente.

Tool 2: Buscar contacto (Airtable)

Antes de guardar un cliente, hay que ver si ya existe. Usaremos Airtable como CRM simple. Crea una nueva tool y únela al agente.

Preparación en Airtable:

  1. Crea una cuenta gratuita en airtable.com
  2. Crea una nueva Base llamada “CRM”
  3. Crea una tabla “Contactos” con estas columnas:
    • Nombre (texto)
    • Email (email)
    • Teléfono (teléfono)
    • Fecha de contacto (fecha)

En n8n:

  1. Arrastra el nodo “Airtable Tool”
  2. Configura:
    • Operation: “Search”
    • Base: [tu base CRM]
    • Table: Contactos
    • Activa “From AI” en Filter Formula

Esto permite al agente buscar si un email ya existe.

Tool 3: Guardar/actualizar contacto (Airtable)

Si el contacto no existe, lo guardamos. Si existe, lo actualizamos solo si hay datos nuevos. De nuevo, añadimos una nueva tool.

  1. Arrastra otro nodo “Airtable Tool”
  2. Configura:
    • Operation: “Create or Update” (Upsert)
    • Base: [tu base CRM]
    • Table: Contactos
    • Matching Column: Email
    • Activa “From AI” en todos los campos

El agente ahora puede guardar contactos automáticamente sin duplicarlos.

Tool 4: Avisar al equipo por Slack o Telegram

Cuando alguien necesite atención humana, el chatbot puede avisar por Slack/Telegram.

  1. Arrastra el nodo “Slack Tool” (o Telegram si prefieres)
  2. Conecta tu cuenta de Slack
  3. Selecciona el canal donde quieres las notificaciones
  4. En el prompt del agente, añade:
Si el usuario pide hablar con una persona o su caso es complejo, usa la herramienta de Slack para avisar al equipo con:
- Nombre del usuario
- Email o teléfono
- Resumen breve del problema

Paso 7: Activar y probar el chatbot

¡Ya está todo listo! Es hora de probar.

  1. Prueba el chatbot:
    • Haz clic en “Test workflow”
    • Escribe: “Hola, ¿qué servicios ofrecéis?”
    • Comprueba cómo responde usando la info del Google Doc.
  2. Prueba guardar un contacto:
    • Escribe: “Me interesa, soy Juan Pérez, mi email es juan@ejemplo.com”
    • El chatbot debería guardar el contacto en Airtable
    • Compruébalo en tu tabla de Airtable
  3. Prueba un duplicado:
    • Escribe: “Soy Juan Pérez de nuevo, mi teléfono es 666777888”
    • El chatbot debería actualizar el registro existente, no crear uno nuevo

Paso 8: Integrar en tu web

El chatbot ya funciona, pero está en localhost. Para usarlo en tu web necesitas dos cosas:

Opción A: Migrar a VPS (recomendado)

Como ya sabes, nosotros trabajamos con Krystal, el cual ofrece VPS a medida y están comprometidos con el medio ambiente :) Además puedes aprovecharte de un descuento con el código “SIXE”. Con un VPS tu chatbot estará 24/7 disponible. n8n ofrece la opción de embeber en tu web, así que es perfecto.

Si quieres aprender a hacerlo con instructores, configurarlo correctamente con HTTPS, dominio personalizado y todo listo para producción… Ofrecemos un curso básico y un curso avanzado en n8n.

Opción B: Usar ngrok (temporal, solo para pruebas)

Si quieres probar ngrok ya en tu web sin VPS:

ngrok http 5678
  • Copia la URL que te da (tipo https://xyz.ngrok.io)
  • Usa esa URL en lugar de localhost en tu web

Importante: La URL de ngrok cambia cada vez que lo reinicias. No es para producción.

n8n significa libertad con IA

Y eso es todo. Ya tienes tu primer agente de n8n IA funcionando localmente con Ollama. En producción recomendamos OpenAI, sobre todo gpt-4o-mini gracias a su precio y su buen funcionamiento. Ahora te toca experimentar. Prueba otros modelos, ajusta los prompts, añade más herramientas.

¿Dudas? ¿Quieres que formemos a ti o a tu equipo para configurar agentes de n8n y IA en producción? Escríbenos.

Y si te ha molado el artículo, compártelo con otros que estén buscando automatizar con IA sin gastarse una pasta.

 

Recursos adicionales:

Cómo implementar NFS con alta disponibilidad en Ceph usando Ganesha-NFS

Introducción a Ceph y Ceph-Ganesha

Ceph-Ganesha representa una herramienta NFS integrada en CEPH que ofrece potentes funciones de orquestación para conseguir alta disponibilidad y gestión dinámica en clusters Ceph multinodo. En este artículo nos centraremos en la simplicidad declarativa de su despliegue y demuestra sus capacidades de alta disponibilidad.

Ceph es una plataforma de almacenamiento definida por software y de código abierto que proporciona almacenamiento de objetos, bloques y archivos altamente escalable desde un cluster unificado.

La arquitectura de Ceph se basa fundamentalmente en una red distribuida de nodos independientes. Los datos se almacenan mediante OSDs (Object Storage Daemons), se gestionan a través de Monitores y se orquestan por medio de Gestores.

Arquitectura Ceph: fundamentos técnicos

El Sistema de Archivos Ceph (CephFS) es un sistema de archivos compatible con POSIX que se asienta sobre esta infraestructura, proporcionando un espacio de nombres distribuido y tolerante a fallos. Para los administradores de sistemas, Ceph supone una alternativa sólida a las matrices de almacenamiento tradicionales, ya que ofrece una plataforma única y resistente que puede crecer linealmente con la incorporación de hardware básico.

Las capacidades de autorreparación y autogestión son ventajas clave, reduciendo la sobrecarga operativa.

 

NFS Ganesha en Ceph: características distintivas

NFS Ganesha funciona como un servidor NFS de código abierto que actúa como pasarela en el espacio de usuario, una distinción clave respecto a los servidores NFS convencionales que residen en el núcleo del sistema operativo. Esta decisión de diseño fundamental proporciona un entorno de servicio más robusto y estable. Los errores en un demonio de espacio de usuario tienen muchas menos probabilidades de provocar un fallo catastrófico del sistema, una ventaja crucial para un punto final de servicio crítico. La arquitectura de Ganesha también está diseñada para ofrecer la máxima compatibilidad, ya que admite una gama completa de protocolos NFS, desde NFSv3 hasta NFSv4.2, lo que garantiza que puede atender a una base de clientes diversa.

 

La verdadera innovación de Ganesha reside en su capa de abstracción del sistema de archivos, o FSAL. Esta arquitectura modular desacopla la lógica del protocolo NFS del almacenamiento subyacente. Para un entorno Ceph, el módulo FSAL_CEPH resulta fundamental, ya que permite a Ganesha actuar como un sofisticado cliente Ceph. Esto significa que los administradores pueden proporcionar una interfaz NFS consistente a los clientes, al tiempo que se benefician de toda la potencia y escalabilidad del cluster Ceph, sin exponer directamente la infraestructura Ceph subyacente. Si quieres profundizar en estas tecnologías puedes acceder al curso de despliegue y administración básica de Ceph que ofrecemos en SIXE.
Un moderno centro de datos lleno de resplandecientes nodos de almacenamiento Ceph conectados en un clúster resistente. En el centro, una simpática deidad Ganesha de dibujos animados está sentada ante una consola con múltiples brazos que gestiona exportaciones NFS, cables y servidores. Una mano sostiene un cable de red, otra un ordenador portátil, otra un logotipo Ceph resplandeciente, que simboliza la alta disponibilidad y la orquestación.

Integración de Cephadm: despliegue declarativo simplificado

La integración de Ganesha con el orquestador Ceph (cephadm) eleva su despliegue desde una tarea manual específica de cada host hasta una elegante operación a nivel de cluster. Esta asociación permite un enfoque declarativo de la gestión de servicios, donde un único comando puede gestionar todo el ciclo de vida del servicio Ganesha.

Para cualquier servicio de misión crítica, la principal preocupación de los administradores de sistemas es garantizar la continuidad del negocio. Las interrupciones no planificadas pueden provocar pérdidas significativas de datos, reducción de la productividad y daños reputacionales. La Alta Disponibilidad (HA) constituye el principio arquitectónico que aborda esta preocupación eliminando los puntos únicos de fallo. Para un servicio NFS, esto significa que si un nodo servidor falla, otro nodo puede asumir sus funciones de manera transparente. Esto proporciona tranquilidad a los administradores y permite realizar mantenimiento planificado sin afectar al usuario final. En el caso de Ceph, su naturaleza distribuida inherente complementa perfectamente un servicio NFS de HA, ya que el almacenamiento subyacente es resistente por diseño a los fallos de los nodos.

Preparación del almacenamiento CephFS para Ganesha

Un despliegue exitoso de Ganesha comienza con la preparación adecuada del almacenamiento CephFS subyacente

Crear un pool dedicado para datos NFS Ganesha con autoescalado activado
# sudo ceph osd pool create ganeshapool 32 32
# sudo ceph osd pool set ganeshapool pg_autoscale_mode on

Crear un pool de metadatos, marcado como bulk para un comportamiento optimizado
# sudo ceph osd pool create ganeshapool_metadata 16 16
# sudo ceph osd pool set ganeshapool_metadata bulk true

Vincular los pools a un nuevo sistema de archivos CephFS
# sudo ceph osd pool application enable ganeshapool cephfs
# sudo ceph osd pool application enable ganeshapool_metadata cephfs
# sudo ceph fs new ganeshafs ganeshapool_metadata ganeshapool

# ceph fs set ganeshafs max_mds 3
# ceph orch apply mds cephfs --placement="3 ceph-node1 ceph-node2"

Despliegue del servicio Ceph NFS Ganesha

Una vez establecidos los cimientos del almacenamiento, el despliegue de Ganesha puede realizarse tanto con archivos .yaml como con comandos CLI de orquestación sencillos. El comando ceph orch apply constituye una instrucción potente al orquestador, indicándole que garantice el estado deseado del servicio NFS. Al especificar un recuento de ubicaciones y enumerar los hosts del cluster, los administradores se aseguran de que se ejecutará un demonio Ganesha en cada nodo designado, un paso crítico para conseguir un servicio resistente y de alta disponibilidad.

Desplegar el servicio NFS de Ganesha en los tres hosts especificados

# sudo ceph orch apply nfs myganeshanfs ganeshafs --placement="3 ceph-node1 ceph-node2 ceph-node3"

Este comando único inicia un despliegue complejo y multifacético. El orquestador extrae las imágenes de contenedor necesarias, configura los demonios y los distribuye entre los hosts especificados. Esto contrasta claramente con las instalaciones manuales host por host, mostrando la potencia de la orquestación centralizada. Estos escenarios los tratamos detalladamente en el curso de administración avanzada de Ceph que ofrecemos, donde se cubre paso a paso la orquestación con cephadm y las configuraciones de HA.

Capacidades avanzadas: exportaciones dinámicas y resistencia del servicio

Una vez que el servicio Ganesha está en funcionamiento, su potencia se revela aún más a través de sus capacidades de gestión dinámica de exportaciones. En lugar de editar archivos de configuración estáticos, los expertos pueden crear, modificar y eliminar exportaciones NFS sobre la marcha mediante una serie de comandos sencillos. Esta funcionalidad resulta inestimable en entornos dinámicos donde las necesidades de almacenamiento cambian rápidamente.

Crear una nueva exportación para hacer accesible el sistema de archivos CephFS

# sudo ceph nfs export create cephfs myganeshanfs /ganesha ganeshafs --path=/

El verdadero valor de este despliegue distribuido reside en la resistencia de sus servicios. El orquestador Ceph supervisa constantemente la salud de los demonios Ganesha. Si falla un host, el orquestador detectará automáticamente la pérdida y tomará medidas para garantizar que el servicio siga disponible. Este proceso automatizado de conmutación por error proporciona un alto grado de transparencia a los clientes, haciendo que Ganesha pase de ser una simple pasarela a convertirse en un servicio de verdadera alta disponibilidad. Su arquitectura está construida para resistir interrupciones, convirtiéndola en una parte indispensable de una estrategia de almacenamiento robusta.

Ejemplo práctico

Supongamos que disponemos de un cluster con 3 nodos preparados para Ganesha. Esto significa que se pueden exportar exitosamente los filesystems ceph subyacentes del nodo 1 al nodo 2 y del nodo 2 al nodo 3, o en cualquier configuración deseada.

Conclusión: por qué Ceph-Ganesha resulta esencial para el almacenamiento moderno

NFS Ganesha trasciende el concepto de simple pasarela para convertirse en un componente crítico para integrar los servicios de archivos tradicionales con el almacenamiento moderno y escalable. Aprovechando la orquestación de línea de comandos de cephadm, los administradores pueden desplegar un servicio altamente disponible, resistente y gestionable dinámicamente. El proceso constituye un testimonio del poder de la gestión declarativa de infraestructuras, simplificando lo que de otro modo sería una tarea compleja. El diseño arquitectónico de Ganesha, combinado con la potencia del orquestador Ceph, lo convierte en una solución perfecta para satisfacer los exigentes requisitos de almacenamiento de los entornos híbridos actuales. Precisamente por eso, en SIXE no sólo se ofrece formación sobre Ceph, sino también apoyo especializado para que las empresas puedan mantener la estabilidad de sus infraestructuras de producción.
👉 Soporte técnico Ceph
👉 Curso de despliegue y administración básica en Ceph
👉 Curso de administración avanzada y resolución de problemas de Ceph

QRadar no estaba muerto, solo de parranda | Los rumores sobre su venta a Palo Alto

En los últimos meses se ha extendido un rumor alarmante: “IBM ha vendido QRadar a Palo Alto Networks”. La noticia de la adquisición de la parte SaaS (Software como Servicio) de QRadar por parte de Palo Alto sacudió el mercado de la ciberseguridad, pero también creó confusión entre clientes y partners. En este artículo vamos a aclarar qué se ha vendido y qué no, basándonos en información oficial de IBM, y también la hoja de ruta de QRadar para 2025 y 2026. Al final te contaremos cómo, en SIXE, seguimos ayudando a nuestros clientes a desplegar y sacar el máximo partido de QRadar SIEM, SOAR, EDR y demás productos relacionados.

¿Qué se ha vendido realmente?

La transacción anunciada por IBM y Palo Alto Networks en mayo de 2024 y cerrada el 31 de agosto de 2024 afecta exclusivamente a la edición SaaS de QRadar, no al conjunto de la plataforma. Los motores de correlación, la consola on-premise y el resto de componentes siguen en manos de IBM, de sus partners y de miles de clientes en todo el mundo que compraron licencias y que podrán renovarlas muchos años más.

Aclaración oficial de IBM sobre la continuidad del producto

IBM ha sido muy clara en sus comunicaciones oficiales: QRadar SIEM y SOAR on-premise continúan siendo productos activos con roadmap de desarrollo completo. Según la documentación oficial del roadmap 2025, IBM mantiene equipos dedicados de desarrollo y ha confirmado el soporte continuado para todas las instalaciones on-premise.Roadmap IBM QRadar SIEM 2025 - 2026

La confusión aumenta porque el acrónimo QRadar se ha utilizado para varias ofertas: la clásica plataforma SIEM on-premise, la suite cloud-native (parte del Cloud Pak for Security) y los servicios gestionados. Palo Alto Networks adquirió únicamente la oferta SaaS para integrarla con su plataforma Cortex XSIAM, pero no compró el núcleo del SIEM ni los derechos de la versión instalable.

¿Por qué se vendió el SaaS de QRadar?

En nuestra humilde opinión (que no la de IBM) porque era una…. queremos decir, un producto nuevo y prometedor que iba a requerir inversiones multimillonarias, y que probablemente nunca sería mejor que otros productos similares en manos de compañías como Palo Alto. Al final, el sentido común (o el interés de los accionistas) se impone y se vende lo que probablemente se acabaría abandonando por no dar los resultados esperados sin inversiones aún mayores. Palo Alto compra una pequeña base instalada, algunos buenos clientes e IBM sale airoso de esta aventura. Ya lo hizo unos años antes con el escáner de vulnerabilidades que venía en la compra de QRadar (QVM) y que se dejó de desarrollar recomendando a los clientes adquirir uno de Qualsys o Tenable (empresas de nicho centradas en ese tipo de productos).

Además la confusión aumenta porque el acrónimo QRadar se ha utilizado para varias ofertas: la clásica plataforma SIEM on-premise, la suite cloud-native (parte del Cloud Pak for Security) y los servicios gestionados. Palo Alto Networks adquirió la oferta SaaS para integrarla con su plataforma Cortex XSIAM, pero no compró el núcleo del SIEM ni los derechos de la versión instalable. El roadmap on-premise sigue siendo propiedad de IBM y cuenta con equipos de desarrollo dedicados.

La continuidad de QRadar on-premise

Un temor frecuente de los clientes es que la venta implique la desaparición del producto on-premise. Varios hilos de la comunidad –incluso usuarios de Reddit– señalan que QRadar on-premise continúa comercializándose y evolucionando. IBM ha emitido una carta de garantía de cinco años de soporte y actualizaciones para todas las instalaciones on-premise. Este compromiso se ve reforzado por el hecho de que la lista de productos SaaS con fecha de fin de vida publicada por Palo Alto Networks no incluye ninguna SKU on-premise.

En otras palabras, si tienes una instalación de QRadar que administras tú en tu centro de datos o nube privada, IBM seguirá proporcionándote soporte, parches de seguridad y nuevas funcionalidades como mínimo hasta 2029. Además, mantiene activos los canales de venta y la formación, sin obligación de migrar a la nube ni a soluciones de terceros.

QRadar SIEM – Características disponibles y roadmap 2025

Según el roadmap oficial de IBM para 2025, QRadar SIEM ha incorporado múltiples mejoras significativas:

Funcionalidades ya disponibles:

  • Investigación asistida por IA: QRadar Investigation Assistant impulsado por watsonx.ai
  • Análisis de comportamiento avanzado: User & Entity Behavior Analytics (UEBA) mejorado
  • Optimización de búsquedas: Mejoras en rendimiento para entornos multi-tenant
  • Interfaz modernizada: Renovación completa de múltiples interfaces clave
  • Parsing predictivo: Reducción de dependencia de expresiones regulares

Funcionalidades planificadas para 2025-2026:

  • Correlación de activos avanzada: Integración con fuentes externas para enriquecimiento contextual
  • Análisis forense de red mejorado: Detección precisa de movimiento lateral
  • IA generativa integrada: Generación automática de reglas y enriquecimiento de threat intelligence
  • Búsquedas federadas: Capacidad de búsqueda distribuida across múltiples fuentes
  • Gestión de versiones de reglas: Control de versioning para reglas personalizadas

Nuevas funcionalidades QRadar 2025 2026

QRadar SOAR – Evolución y nuevas capacidades

El roadmap oficial también detalla importantes mejoras para QRadar SOAR:

Características ya disponibles:

  • Integración nativa de playbooks: Playbooks OOTB (Out-of-the-Box) listos para usar
  • Desarrollo de integraciones simplificado: Generación de nuevas integraciones en minutos
  • API OpenAPI compatible: Creación de integraciones personalizadas
  • Reducción de costes de mantenimiento: Menor requerimiento de habilidades técnicas

La tradición de renombrar… y marear

No podemos hablar de IBM sin mencionar su afición por renombrar productos. Q1 Labs se convirtió en IBM Security QRadar, luego llegaron QRadar on Cloud, Security Intelligence Platform, Security QRadar Suite… La venta parcial a Palo Alto ha sumado más etiquetas, pero el QRadar on-premise sigue siendo el mismo producto robusto que conocemos.

Qué hacemos en SIXE

En SIXE implantamos, optimizamos y mantenemos soluciones basadas en QRadar desde hace años. Trabajamos en entornos corporativos con miles de EPS y en pymes que necesitan visibilidad con presupuestos ajustados. Conocemos a fondo UP12 y estamos listos para ayudar a aprovechar las mejoras, así como para integrar las novedades forenses y de IA de cara a 2026.

Aunque la parte SaaS haya cambiado de manos, nuestro compromiso permanece: seguimos vendiendo licencias, desplegando arquitecturas, actualizando infraestructuras y ofreciendo soporte proactivo. 

Nuestros servicios incluyen:

  • Implementación y optimización de QRadar SIEM y SOAR
  • Integración del nuevo QRadar Investigation Assistant
  • Configuración de UEBA avanzado
  • Desarrollo de playbooks personalizados
  • Soporte proactivo y mantenimiento

En SIXE ofrecemos formación en QRadar para que tu plantilla sepa como lidiar con esta tecnología.

Y si tienes dudas… ofrecemos soporte técnico y venta de licencias

👉Curso fundamental de QRadar

👉Soporte técnico en QRadar

Conclusiones

El ruido mediático sobre la compra de QRadar se debe a no leer la letra pequeña: IBM no ha vendido el 95 % del producto, solo la (nueva) parte SaaS. El QRadar tiene soporte garantizado, equipo de desarrollo propio y un roadmap con mejoras reales. Las fechas de fin de vida afectan solo al SaaS.

En resumen: QRadar sigue siendo una apuesta sólida para 2025–2026… lo llamen como lo llamen 😛

Terraform + AWS: De estados gigantes a deploys de 3 minutos

“Llevamos 3 meses sin tocar nuestra infraestructura AWS por miedo a romper algo”. ¿Te suena? La solución no es cambiar de herramienta, es cambiar de metodología.

La mentira que nos hemos creído

Todos empezamos igual: “Vamos a hacer Infrastructure as Code, será genial”. Y efectivamente, los primeros días son mágicos. Creas tu primera VPC, tus security groups, unas cuantas instancias… Todo funciona. Te sientes como un mago.

Después llega la realidad.

Seis meses después tienes estados gigantes, módulos acoplados hasta las cejas, y cada cambio es una ruleta rusa. ¿Te suena?

  1. terraform plan → 20 minutos esperando
  2. Plan de 400 líneas que nadie entiende
  3. “¿Seguro que quieres aplicar esto?”
  4. Tres horas de debugging porque algo falló en la línea 247

Pero hay un factor que pocos equipos consideran…

Lo que realmente funciona (y por qué nadie te lo cuenta)

Después de rescatar decenas de proyectos de Terraform, la fórmula es más simple de lo que crees:

Estados pequeños + módulos inteligentes + GitOps que no dé miedo.

Estados por capas (no por proyecto)

Olvídate de “un estado para gobernarlos a todos”. Divide así:

terraform/
├── network/     # VPC, subnets, NAT gateways
├── data/        # RDS, ElastiCache  
├── compute/     # EKS, ECS, ASGs
└── apps/        # ALBs, Route53

Cada capa evoluciona independientemente. El equipo de datos puede actualizar RDS sin tocar la red. Este puede ser tu Game changer.

El truco del remote state

La magia está en conectar capas sin acoplarlas:

data "terraform_remote_state" "network" {
  backend = "s3"
  config = {
    bucket = "company-terraform-states"
    key    = "network/terraform.tfstate"
  }
}

# Usar outputs de otra capa
subnet_id = data.terraform_remote_state.network.outputs.private_subnet_id

Módulos que no dan dolor de cabeza

Para cada tipo de workload, un módulo específico:

  • secure-webapp/ – ALB + WAF + instancias
  • microservice/ – EKS service + ingress + monitoring
  • data-pipeline/ – Lambda + SQS + RDS con backups

Nada de módulos “universales” que requieren 47 parámetros.

El multi-cloud ya está aquí

Aquí es donde se pone interesante. Muchos equipos están adoptando estrategias híbridas: AWS para aplicaciones críticas, OpenStack para desarrollo y testing.

¿Por qué? Coste y control.

# Mismo módulo, diferente cloud
module "webapp" {
  source = "./modules/webapp"
  
  # En OpenStack para dev
  provider = openstack.dev
  instance_type = "m1.medium"
  
  # En AWS para prod  
  # provider = aws.prod
  # instance_type = "t3.medium"
}

El futuro no es “AWS o nada”. Es flexibilidad arquitectónica. El poder elegir la solución que quieras cuando tu quieras y adaptado a tu presupuesto.

OpenTofu cambia las reglas del juego

Con los cambios en Terraform, OpenTofu se está convirtiendo en la opción inteligente. Misma sintaxis, governance open source, zero vendor lock-in.

La ventaja es brutal: puedes migrar gradualmente sin cambiar ni una línea de código. Perfecto para equipos que quieren control sin dramas.

La pregunta que deberías hacerte

¿Tu último terraform apply te quitó años de vida?

Si la respuesta es sí, el problema no es técnico. Es metodológico.

¿Reconoces estos síntomas en tu equipo? La diferencia entre el éxito y el infierno está en aplicar las técnicas correctas desde el principio.


Si quieres profundizar en estas metodologías, nuestros cursos de Terraform/OpenTofu cubren desde fundamentos hasta GitOps avanzado con casos reales multi-cloud.

Cómo corregir el error más común en Ceph

Ceph es una solución potente y flexible para almacenamiento distribuido, pero como toda herramienta compleja, no está exenta de errores difíciles de diagnosticar. Si te ha aparecido el mensaje “could not connect to ceph cluster despite configured monitors”, ya sabes que algo no va bien en tu cluster. Y no, no es que los monitores estén dormidos. Este error es más común de lo que parece, especialmente después de cambios de red, reinicios o cuando alguien ha tocado la configuración “solo un poquito”.

En este artículo vamos al grano: te contamos las causas reales detrás de este problema y lo más importante, cómo solucionarlo sin perder los datos ni la cordura en el proceso.

Qué significa realmente el error ” could not connect to ceph cluster despite configured monitors “

Cuando Ceph te dice que no puede conectar al cluster “despite configured monitors”, lo que realmente está pasando es que el cliente o daemon puede ver la configuración de los monitores, pero no puede establecer comunicación con ninguno de ellos. Es como que te hagan ghosting, por mucho que llames, no te lo cogen.

Los monitores de Ceph son el cerebro del cluster: mantienen el mapa de la topología, gestionan la autenticación y coordinan el estado global. Sin conexión a los monitores, tu cluster Ceph es básicamente un montón de discos caros sin funcionalidad.

Solucionar errores de Ceph

Las 5 causas más comunes (y sus soluciones)

1. Problemas de red y conectividad

La causa número uno suele ser la red. Ya sea por firewalls mal configurados, cambios de IP o problemas de routing.

Diagnóstico rápido:

# Verifica conectividad básica
telnet [IP_MONITOR] 6789
# o con netcat
nc -zv [IP_MONITOR] 6789

# Comprueba las rutas
ip route show

Solución:

  • Asegúrate de que los puertos 6789 (monitor) y 3300 (msgr2) estén abiertos
  • Verifica que no hay reglas de iptables bloqueando la comunicación
  • Si usas firewalld, abre los servicios correspondientes:
firewall-cmd --permanent --add-service=ceph-mon
firewall-cmd --reload

2. Monmap desactualizado tras cambios de IP

Si has cambiado IPs de los nodos o modificado la configuración de red, es probable que el monmap (mapa de monitores) esté obsoleto.

Diagnóstico:

# Revisa el monmap actual
ceph mon dump

# Compara con la configuración
cat /etc/ceph/ceph.conf | grep mon_host

Solución:

# Extrae un monmap actualizado de un monitor funcionando
ceph mon getmap -o monmap_actual

# Inyecta el monmap corregido en el monitor problemático
ceph-mon -i [MON_ID] --inject-monmap monmap_actual

3. Problemas de sincronización de tiempo

Los monitores de Ceph son muy estrictos con la sincronización temporal. Un desfase de más de 50ms puede causar este error.

Diagnóstico:

# Verifica el estado de NTP/chrony
chrony sources -v
# o con ntpq
ntpq -p

# Comprueba el skew entre nodos
ceph status

Solución:

# Configura chrony correctamente
systemctl enable chronyd
systemctl restart chronyd

# Si tienes servidores NTP locales, úsalos
echo "server tu.servidor.ntp.local iburst" >> /etc/chrony.conf

4. Monitores en estado crítico o corruptos

Si los monitores han sufrido corrupción de datos o están en un estado inconsistente, pueden no responder correctamente.

Diagnóstico:

# Revisa los logs del monitor
journalctl -u ceph-mon@[MON_ID] -f

# Verifica el estado del almacén del monitor
du -sh /var/lib/ceph/mon/ceph-[MON_ID]/

Solución:

# Para un monitor específico, reconstruye desde los OSDs
systemctl stop ceph-mon@[MON_ID]
rm -rf /var/lib/ceph/mon/ceph-[MON_ID]/*
ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --journal-path /var/lib/ceph/osd/ceph-0/journal --type bluestore --op update-mon-db --mon-store-path /tmp/mon-store
ceph-mon --mkfs -i [MON_ID] --monmap /tmp/monmap --keyring /tmp/ceph.mon.keyring

5. Configuración de cliente incorrecta

A veces el problema está en el lado del cliente: configuración obsoleta, claves incorrectas o parámetros mal definidos.

Diagnóstico:

# Verifica la configuración del cliente
ceph config show client

# Comprueba las claves de autenticación
ceph auth list | grep client

Solución:

# Regenera las claves de cliente si es necesario
ceph auth del client.admin
ceph auth get-or-create client.admin mon 'allow *' osd 'allow *' mds 'allow *' mgr 'allow *'

# Actualiza la configuración
ceph config dump > /etc/ceph/ceph.conf
Cuándo pedir ayuda (antes de que sea tarde)

Este error puede escalar rápidamente si no se maneja correctamente. Si te encuentras en alguna de estas situaciones, es momento de parar y buscar ayuda profesional:

  • Todos los monitores están caídos simultáneamente
  • Has perdido el quorum y no puedes recuperarlo
  • Los datos parecen corruptos o inaccesibles
  • El cluster está en producción y no puedes permitirte experimentos

Los clusters Ceph en producción no son terreno para prueba y error. Un movimiento en falso puede convertir un problema de conectividad en una pérdida de datos.

La mejor solución al error  “could not connect to ceph cluster despite configured monitors” : prevenir

Para evitar encontrarte con este error en el futuro:

Monitorización proactiva:

  • Configura alertas para el estado de los monitores
  • Monitoriza la latencia de red entre nodos
  • Supervisa la sincronización temporal

Buenas prácticas:

  • Siempre despliega al menos 3 monitores (mejor 5 en producción)
  • Mantén backups regulares del monmap y las claves
  • Documenta cualquier cambio de configuración de red
  • Usa automatizaciones (Ansible, por ejemplo, es perfecto para para cambios de configuración)

Testing regular:

  • Prueba periódicamente la conectividad entre nodos
  • Simula fallos de monitores en entorno de desarrollo
  • Verifica que tus procedimientos de recovery funcionan

¿Necesitas ayuda con tu cluster Ceph?

Los clusters de almacenamiento distribuido como Ceph requieren experiencia específica para funcionar de manera óptima. Si te has encontrado con este error y las soluciones anteriores no resuelven tu problema, o si simplemente quieres asegurar que tu infraestructura Ceph está correctamente configurada y optimizada, podemos ayudarte.

En nuestro equipo tenemos experiencia solucionando problemas complejos de Ceph en entornos de producción, desde troubleshooting urgente hasta optimización de rendimiento y planificación de alta disponibilidad.

Te ofrecemos ayuda con

No dejes que un problema de conectividad se convierta en un dolor de cabeza mayor. La experiencia correcta puede ahorrarte tiempo, dinero y, sobre todo, estrés.

¿Tu servidor necesita reemplazo? El derecho a reparar dice que no

La nueva Directiva Europea sobre el derecho a reparar está poniendo fin a uno de los mitos más caros del sector IT: que cambiar a hardware “más eficiente” es siempre más sostenible. El derecho a reparar hace que los productos se reacondicionen con mayor facilidad y rapidez. Y en el mundo IT, esto significa repensar completamente nuestra relación con el hardware.

El mito del “hardware nuevo siempre es mejor”

Durante años hemos escuchado el mismo discurso: “este servidor ya tiene 5 años, hay que cambiarlo”. Pero, ¿realmente es así?, ¿has mirado sobre el papel si te merece la pena de verdad cambiar ese IBM Power9 solo porque ya no le dan soporte? Porque quizá te lleves una sorpresa. La realidad es mucho más compleja y, sobre todo, más cara de lo que aparenta.

Cuando compras un servidor nuevo, no solo pagas el precio de etiqueta. Pagas:

  • La huella de carbono de su fabricación
  • El transporte desde la fábrica
  • La gestión de residuos del equipo anterior
  • Los costes de migración y configuración
  • La pérdida de tiempo de productividad durante la transición

Por el contrario, cuando renuevas tu hardware existente, aprovechas al máximo una inversión ya amortizada y reduces drásticamente el impacto ambiental.

Hagamos matemática verde: los números no mienten

Las nuevas regulaciones del derecho a reparar pueden extender la vida útil de los productos hasta 10 años más, lo que en términos de IT se traduce en:

¿Por qué estos números son tan favorables? Porque la fase de fabricación representa el 70-85% de la huella de carbono total de cualquier equipo IT. Mantener funcionando un servidor durante 8-10 años en lugar de 3-5 es, literalmente, multiplicar por dos su eficiencia ambiental.

Derecho a reparar en IT y tecnología sostenible

Más allá del hardware: el software también cuenta

El derecho a reparar en IT no se limita al hardware. Incluye:

  • Soporte extendido para sistemas operativos fuera del ciclo oficial. En SIXE apostamos por el soporte fuera del ciclo de vida impuesto y podemos alargar la vida útil de Linux, AIX, Ceph, y otros sistemas.
  • Mantenimiento independiente de bases de datos como DB2, Oracle o Informix
  • Actualizaciones de seguridad sin necesidad de migrar toda la plataforma
  • Optimización continua del rendimiento en lugar de reemplazos masivos

El derecho a reparar: más que una ley, una filosofía

“Mi proveedor dice que es inseguro”

Los fabricantes tienen incentivos comerciales evidentes para vender hardware nuevo. Sin embargo, un servidor de 2018 con mantenimiento adecuado puede ser más seguro que uno nuevo mal configurado.

“No hay repuestos disponibles”

Con proveedores de mantenimiento independientes, la disponibilidad de repuestos se extiende años más allá de lo que ofrecen los fabricantes originales.

“El rendimiento será inferior”

Un sistema optimizado de 5 años puede superar en rendimiento a uno nuevo sin configurar adecuadamente.

Nuestro compromiso sostenible en SIXE: hacer que dure todo lo que el propio hardware permita

En SIXE llevamos años defendiendo esta filosofía. No porque sea tendencia, sino porque los números lo demuestran: un enfoque basado en el mantenimiento preventivo, la optimización continua y la reutilización inteligente de recursos genera mejor ROI que el ciclo tradicional de compra-usa-tira.

Nuestro compromiso con el “make it last forever” no es marketing. Es ingeniería aplicada con criterio económico y ambiental.

Conclusión: el futuro es circular, no lineal

El derecho a reparar en IT no es una imposición regulatoria. Es una oportunidad de repensar cómo gestionamos la tecnología empresarial. Un enfoque donde mantener, optimizar y extender la vida útil de los equipos no solo es más verde, sino también más rentable.

La pregunta no es si tu empresa se adaptará a esta realidad. La pregunta es si lo hará antes o después que tu competencia.

¿Listo para dar el salto hacia una IT más sostenible y eficiente? Descubre nuestros servicios de tecnología sostenible y comienza a optimizar tu infraestructura hoy mismo.

Y si tu sistema te está dando problemas, podemos valorar su eficiencia antes de cambiarlo.

👉​Nuestro catálogo de consultoría / servicio técnico

IBM Power11 | Descubre todas las novedades

🆕 IBM Power11 ya está aquí

La espera ha terminado: hoy se presenta oficialmente IBM Power11, la nueva generación de servidores que busca consolidar a Power como referente en rendimiento, eficiencia y apertura.Nuevos IBM Power11

¿Qué novedades traen los nuevos servidores Power?

IBM apuesta por un diseño full-stack, con integración desde el procesador hasta la nube, pensado para simplificar la gestión, reducir costes y habilitar la IA sin necesidad de GPUs. Power11 nos ofrece:

  • Acelerador IBM Spyre para IA generativa y procesos empresariales

  • Hasta un 25% más de núcleos por chip respecto a Power10

  • Memoria DDR5 con mejor ancho de banda y eficiencia

  • Mantenimiento concurrente, criptografía cuántico-segura, y modo de eficiencia energética automatizado

  • Soporte completo para AIX, IBM i, Linux, y despliegues híbridos (Power Virtual Server)

Conoce los modelos de Power11 disponibles desde hoy:

  • 🔹 IBM Power S1122

    Servidor compacto 2U, ideal para entornos con espacio limitado. Hasta 60 núcleos Power11, 4 TB de RAM DDR5 y capacidades avanzadas de ciberresiliencia y eficiencia energética. Perfecto para cargas Linux, AIX o IBM i en entornos de producción mixtos.

    🔹 IBM Power S1124

    Diseñado para consolidar cargas críticas en formato 4U con hasta 60 núcleos, 8 TB de memoria y doble socket. Ideal para empresas medianas o grandes que quieren flexibilidad cloud, sin sacrificar rendimiento ni seguridad.

    🔹 IBM Power E1150

    Modelo intermedio con gran escalabilidad, pensado para cargas exigentes y despliegues SAP, bases de datos o virtualización intensiva.

    🔹 IBM Power E1180

    El más potente de la familia Power11. Hasta 256 núcleos, 64 TB de memoria y eficiencia energética mejorada hasta un 28%. Diseñado para IA, análisis avanzado y consolidación masiva en entornos críticos con disponibilidad del 99,9999%.

Power más abierto y preparado para híbrido

Todos los modelos Power11 se pueden desplegar también en Power Virtual Server, integrando cargas AIX, IBM i y Linux en entornos híbridos, sin necesidad de reescribir aplicaciones. Además, la compatibilidad con KVM y PowerVM permite elegir el hipervisor que mejor se ajuste al entorno.

Disponibilidad: IBM Power11 estará disponible globalmente a partir del 25 de julio de 2025. El acelerador IBM Spyre estará disponible en el cuarto trimestre de 2025.

¿Y el futuro?

Power11 inaugura una nueva etapa donde IA, seguridad cuántica y eficiencia energética ya no son promesas, sino características nativas.

Si te han gustado los nuevos modelos de Power11 tenemos buenas noticias para ti, porque en SIXE realizamos la venta y migración del Power11 (y del Power10, 9…). En SIXE llevamos años ayudando a nuestros clientes a aprovechar al máximo la potencia de Power.

Aprende a construir y desplegar agentes de IA con LangGraph usando watsonx.ai

La inteligencia artificial ya no solo responde, también toma decisiones. Con frameworks como LangGraph y plataformas como watsonx.ai , puedes construir agentes que razonen y actúen de forma autónoma 🤯.

En este artículo, te explicaremos cómo implementar un agente ReAct (Reasoning + Action) localmente y desplegarlo en IBM Cloud, todo esto con un ejemplo práctico que incluye una herramienta de consulta del clima 🌤️.

Cómo construir y desplegar agentes IA autónomos con LangGraph y watsonx.ai

Preparemos el entorno para nuestro agente

Necesitamos:

  • Python 3.12 instalado
  • Acceso a IBM Cloud y watsonx.ai
  • Poetry para gestión de dependencias

¿Lo tienes todo? Pues lo primero es lo primero, clonar el repositorio que usaremos como ejemplo. Está basado en los ejemplos oficiales de IBM.

git clone https://github.com/thomassuedbroecker/watsonx-agent-langgraph-deployment-example.git 
cd ./agents/langgraph-arxiv-research

Arquitectura del proyecto

Antes de nada, entendamos el proyecto de ejemplo.

[Developer Workstation] → [CI/Build Process] → [Deployment] ↓
[IBM Cloud / watsonx.ai]

Los principales archivos del agente son:

ai_service.py
Archivo principal que inicia el servicio del agente en producción.
agent.py
Lógica central del agente IA basado en LangGraph. Define el flujo de trabajo.
tools.py
Herramientas conectadas al agente (Weather API).

Diagrama del repo de ejemplo de Langgraph y watson.ai

Pasemos a configurar el entorno

python3.12 -m venv .venv
source ./.venv/bin/activate
python3 -m pip install --upgrade pip
python3 -m pip install poetry

También recomendamos el uso de Anaconda o miniconda. Nos permite gestonar entornos virtuales o paquetes de Python de forma sencilla y es muy utilizado en ML.

Para que Python pueda encontrar nuestros módulos personalizados (como los agentes y las herramientas), necesitamos incluir el directorio actual en la variable de entorno PYTHONPATH

 

export PYTHONPATH=$(pwd):${PYTHONPATH}

echo ${PYTHONPATH}

 

Una vez tenemos listo el entorno es el momento de las variables. Debes crear un archivo config.toml si no lo tienes ya y usar tus credenciales de IBM Cloud:

[deployment]
  watsonx_apikey = "TU_APIKEY"
  watsonx_url = ""  # Tiene que seguir el siguiente formato: `https://{REGION}.ml.cloud.ibm.com0`
  space_id = "SPACE_ID"
  deployment_id = "YOUR_DEPLOYMENT_ID"
[deployment.custom]
  model_id = "mistralai/mistral-large"  # underlying model of WatsonxChat
  thread_id = "thread-1" # Más información: https://langchain-ai.github.io/langgraph/how-tos/persistence/
  sw_runtime_spec = "runtime-24.1-py3.11"

Encontrarás tus variables aquí:

https://dataplatform.cloud.ibm.com/developer-access

Una vez allí, selecciona tu espacio de despliegue y copia los datos necesarios (API Key, Space ID, etc.).

Ejecución en local del agente

Toca probar el agente:

source ./.venv/bin/activate
poetry run python examples/execute_ai_service_locally.py

Ya que es un agente meteorológico ¿por qué no lo pruebas con algo como algo como…?

“What is the current weather in Madrid?”

La consola debería darte el tiempo en Madrid. ¡Enhorabuena! solo nos falta hacer el deploy en watsonx.ai

Despliegue del agente en watsonx.ai

source ./.venv/bin/activate
poetry run python scripts/deploy.py
Este código desplegará el agente en Watsonx.ai 
deploy.py hace lo siguiente:
  1. Lee la configuración (config.toml) con tus credenciales y espacio de despliegue.
  2. Empaqueta tu código en un ZIP para subirlo a IBM Cloud.
  3. Crea una especificación de software personalizada basada en un entorno base (como runtime-24.1-py3.11).
  4. Despliega el agente como un servicio REST en watsonx.ai.
  5. Guarda el deployment_id , necesario para interactuar con el agente después.

En resumen:
Toma tu agente local, lo prepara y lo convierte en un servicio accesible desde la nube.

Revisamos que esté todo correcto en watsonx.ai y vamos al apartado de “Test”. Allí pegaremos el siguiente json (es tan solo una pregunta)
{
"messages": [
{
"content": "What is the weather in Malaga?",
"data": {
"endog": [
0
],
"exog": [
0
] },
"role": "User"
}
] }
Dale a predict y el agente usará la herramienta weather_service.
En el json de respuesta podrás ver el proceso del agente -> llamar a la herramienta -> recoger la ciudad -> procesar y devolver la temperatura.
¡Ya está funcionando tu agente en watsonx.ai!
Si quieres probarlo desde la terminal para asegurarte de que funciona, solo tienes que usar
source ./.venv/bin/activate
poetry run python examples/query_existing_deployment.py
Conclusiones

Si te ha quedado alguna duda, te recomendamos el siguiente vídeo tutorial donde podrás seguir paso a paso el desarrollo conectado con watsonx.ai

Si quieres seguir explorando este tipo de implementaciones o aprender más sobre desarrollo cloud e inteligencia artificial, te invitamos a explorar nuestros cursos de IA👇

SIXE