Este documento explica qué problema resuelve el driver CSI de Seagate Exos X (ME5), cómo encaja en la arquitectura multi-site y cuál es su estado real dentro del clúster.
No es una guía de instalación. El detalle técnico (Helm, manifests, iSCSI, multipath, etc.) está en el repositorio Git correspondiente.
Además del almacenamiento distribuido (Ceph), existen cabinas físicas ME5 con:
La intención inicial era integrarlas como almacenamiento de alto rendimiento y con replicación entre sites.
👉 Para eso se utiliza un driver CSI.
CSI es el estándar que permite a Kubernetes hablar con sistemas de almacenamiento externos.
En términos simples:
Todo de forma declarativa (YAML) y reproducible.
Arquitectura física:
| Site | Cabina |
|---|---|
| site-a | ME5-A |
| site-b | ME5-B |
La idea inicial era:
Pero aquí aparece una limitación importante.
Las cabinas no disponen de licencia de replicación activa.
Esto implica:
Por tanto:
👉 Cada cabina es independiente.
👉 No existe resiliencia cruzada entre sites a nivel de datos.
Esto cambia completamente el papel de estas cabinas en la arquitectura.
Otro factor relevante:
El driver CSI de Exos X / ME5 no está especialmente optimizado para entornos Kubernetes exigentes.
No es un driver diseñado originalmente para:
Funciona, pero:
👉 Es usable, pero no es “cloud-native first”.
Actualmente el driver se utiliza únicamente con volúmenes RWO (ReadWriteOnce).
No hay soporte práctico para:
Esto significa:
En una arquitectura moderna basada en microservicios:
👉 La tendencia es diseñar aplicaciones only-RWO.
Por tanto, esta limitación no es necesariamente un problema estructural, pero sí limita casos de uso tradicionales.
Dadas las limitaciones anteriores:
La cabina ME5 se está utilizando de forma controlada y limitada.
Actualmente su función principal es:
👉 Almacenamiento de MinIO utilizado por Velero para backups.
Es decir:
Se usa como:
Esto reduce el impacto arquitectónico de sus limitaciones.
En el modelo stretch cluster:
Por tanto:
👉 El almacenamiento verdaderamente multi-site es Ceph.
👉 Las cabinas son almacenamiento local por site.
Esto deja claro su papel dentro del diseño global.
Existen varias opciones a futuro:
El diseño actual (una StorageClass por zona) ya permite migrar a dos clústeres independientes sin cambios conceptuales fuertes.
En el modelo actual (stretch cluster), las cabinas ME5 tienen un margen de uso limitado porque:
En un escenario distinto —dos clústeres independientes, uno por site— la situación cambiaría:
En ese modelo:
👉 Las ME5 podrían tener más protagonismo como almacenamiento principal local por site.
Pero en el modelo stretch actual:
👉 Su papel debe mantenerse acotado, porque no aportan resiliencia inter-site.
Después de leer este documento debe quedar claro que:
Almacenamiento externo integrado, pero con rol limitado y controlado dentro de la arquitectura.