Montar una SAN casera: cómo funciona el almacenamiento moderno con doble controladora
La mayoría de las dudas sobre almacenamiento empresarial giran en torno a qué fabricante es mejor, por qué una licencia cuesta tanto o por qué el panel se rompió tras actualizar el firmware. Esta consulta era más limpia y mucho más peligrosa: ¿cómo funciona por dentro una cabina SAN moderna con doble controladora?
Un ingeniero de software que trabaja en un proveedor cloud decidió construir una versión reducida del sistema que los fabricantes venden por sumas astronómicas. La configuración sonará familiar a cualquiera que observe la evolución de las cabinas actuales: dos plataformas x86, enlaces directos de 25Gb, unidades NVMe con doble puerto, NVMe sobre TCP o RDMA, namespaces expuestos y una topología inspirada en sistemas HA sin conmutadores como HPE Alletra MP B10000. El ingeniero ya había experimentado con Mellanox OFED y SPDK, logrando exponer namespaces NVMe hacia los hosts. Luego llegó la parte dura: multipath, RAID, alta disponibilidad, fencing, failover, metadatos y todo el engranaje invisible que transforma "unos discos rápidos en red" en una cabina de almacenamiento en la que la gente confía.
Todo el mundo adora el diagrama arquitectónico hasta que aparece la coherencia
El lado seductor del almacenamiento moderno es que su diseño físico parece casi comprensible: dos controladoras, discos compartidos, un tejido de red veloz, multipath en el host, una capa de gestión y algún tipo de estado replicado o distribuido. Un diagrama limpio lo hace parecer un juego de construcción para adultos con cables más caros. Lo que el diagrama oculta es que el almacenamiento tiene que mover bytes de forma impecable, y la velocidad es apenas la mitad fácil. Debe mantener la coherencia mientras los componentes fallan, falsean datos, compiten en carreras de hilos, agotan tiempos de espera, se reinician e intentan arruinarte el fin de semana.
Ahí es donde los comentarios ganaron interés. Una persona rebatió de inmediato la idea de que las cabinas comerciales sean solo un Linux con una interfaz gráfica añadida por encima. Puede que ocurra a veces, pero no de forma general. Varios fabricantes recurren a BSD por cuestiones históricas de licencias. Otros emplean BSD únicamente para el arranque mientras el trabajo pesado sortea la ruta tradicional del sistema operativo, de forma parecida a como ESX gestiona ciertas funciones de bajo nivel. Otro participante con experiencia en el sector del almacenamiento confirmó que BSD abunda sorprendentemente, y que sistemas como Hitachi VSP y Dell PowerMax no son simples máquinas con controladores Linux haciendo tareas ordinarias de Linux.
Esa matización cuenta. A menudo se imagina el almacenamiento corporativo como fontanería de código abierto con una cara bonita y un contrato de soporte. En ocasiones es así. Sin embargo, las cabinas de gama alta suelen arrastrar décadas de ingeniería a medida, microcódigo privativo, requisitos extraños de hardware y rutas de datos especializadas que no encajan en el esquema mental clásico de Linux.
La primera lección dura: activo-activo no es un proyecto de fin de semana
La respuesta más práctica fue directa contra la ilusión del montaje casero. Si alguien quiere montar una cabina SAN basada en Linux, los bloques probables son device-mapper para RAID o asignación de volúmenes, metadatos personalizados para describir la distribución de discos, quizá LVM en clúster, y luego Pacemaker junto con Corosync para coordinar la alta disponibilidad. Para el fencing, las reservas persistentes en los discos resultan esenciales. Esa pila tecnológica permite lograr una cabina activo-pasivo. Lo que difícilmente ofrecerá es un sistema de almacenamiento activo-activo auténtico usando solo componentes estándar, y la diferencia es enorme.
El modelo activo-pasivo ya entraña gran dificultad. Una controladora asume los recursos mientras la otra aguarda, monitoriza y toma el control si la primera cae o recibe un fencing. Hay un desgaste tremendo de ingeniería en ese punto: tiempos de failover, prevención de split-brain, replicación de estado, orden de escritura, gestión de reservas, comportamiento de rutas en los clientes y secuencias de recuperación. Al menos el modelo de propiedad es relativamente simple.
Activo-activo suena mejor en marketing, puesto que ambas controladoras procesan operaciones de E/S y dan la impresión de rendir al máximo. Todo parece más moderno. Sin embargo, un verdadero esquema activo-activo exige que ambos extremos alcancen un acuerdo constante sobre propiedad, ordenamiento, estado de caché, metadatos, escrituras pendientes, reservas, reconstrucciones y gestión de fallos. Si ambas controladoras pueden escribir sobre la misma estructura lógica, la concurrencia se transforma en una pesadilla.
Un participante lo resumió sin rodeos: la mayoría de cabinas ni siquiera aplican un activo-activo real. Esa observación merece más atención de la que suele recibir. Gran parte de la publicidad de almacenamiento corporativo usa el término activo-activo con ligereza. A veces solo significa que ambas controladoras están encendidas y sirven volúmenes diferentes. En otras ocasiones alude a rutas optimizadas o comportamientos ALUA. A veces implica que ambas controladoras acceden a los soportes físicos traseros sin escribir al mismo tiempo en las mismas estructuras de datos de forma totalmente simétrica. Las mismas dos palabras describen diseños radicalmente opuestos.
Los componentes aburridos guardan los mayores peligros
Quienes diseñan almacenamiento se obsesionan con detalles rutinarios porque las cosas monótonas destruyen datos: metadatos, superbloques, sumas de verificación, barreras de escritura, semántica de volcado, reservas, fencing, contadores de generación, detección de split-brain, identificadores estables, reglas de importación, registros de reproducción y seguimiento de regiones sucias. Todo esto parece minucias de implementación hasta que una controladora muere en mitad de una actualización y la superviviente debe resolver cuál es la realidad válida.
Por ese motivo, un comentario aconsejaba al creador reflexionar a fondo sobre el modelo de concurrencia y los niveles de integridad de datos. Los discos y los SSD pueden mentir sobre las escrituras completadas, fallar en los volcados o ejecutar acciones técnicamente válidas que resultan desastrosas si las capas superiores asumen una fidelidad absoluta. La recomendación fue estudiar ZFS con detalle. ZFS no tiene por qué ser la respuesta exacta para construir una cabina NVMe-oF comercial, pero enseña el grado de desconfianza metódica que requiere cualquier almacenamiento serio.
Esa cautela marca la frontera entre una demostración técnica y una cabina de producción. Una demostración expone un namespace y supera una prueba de rendimiento. Una cabina sobrevive a las peores crisis: sabe actuar cuando un disco devuelve datos corruptos, una controladora desaparece, un host reintenta peticiones de forma agresiva, un enlace oscila y una escritura fue confirmada justo antes de que el entorno se partiera en dos.
Muchos subestiman ese abismo porque el camino feliz parece despejado. SPDK transfiere E/S a enorme velocidad. Linux soporta destinos NVMe. RDMA vuela. Multipath permite a los clientes ver más de una ruta, Pacemaker migra recursos y device-mapper crea asignaciones de bloques. Todas esas piezas existen y funcionan, pero ninguna produce por sí sola una plataforma de almacenamiento fiable. Sigue haciendo falta un cerebro con criterio que las articule.
Hay piezas de código abierto, pero el producto es el pegamento
Varios participantes señalaron componentes de software reales. Linux moderno incluye soporte de destino NVMe mediante nvmet. Corosync abunda en infraestructuras de HA. RSF-1 aparece en entornos comerciales de almacenamiento con alta disponibilidad. Pacemaker coordina conmutaciones por error. Device-mapper presenta dispositivos de bloques y sustenta la lógica de volúmenes. La utilidad dmsetup manipula esas asignaciones directamente, o bien el desarrollador puede programar un gestor de volúmenes a medida mediante API, al estilo de LVM.
Eso no es más que una lista de piezas sueltas; el producto reside en el pegamento que las mantiene unidas.
¿Cómo decide el sistema qué controladora es dueña de un namespace? ¿Cómo publica ese estado ante los hosts? ¿Cómo coordina las reservas en unidades NVMe de doble puerto? ¿Cómo distingue la muerte de una controladora de una partición de red? ¿Qué sucede si cae el enlace de HA pero ambas controladoras siguen encendidas? ¿Quién aplica fencing a quién? ¿Qué ocurre si el fencing falla? ¿Y si ambas controladoras creen que la otra ha muerto? ¿Qué metadatos residen en disco, quién puede actualizarlos y cómo se controlan sus versiones? ¿Cómo funciona la reconstrucción mientras continúa la actividad de E/S? ¿Puede un nodo entregar datos desactualizados? ¿Cómo demuestras de forma fehaciente que no lo hará?
Por eso un comentarista afirmó que se requiere una pila de software completa y que esto no funciona enchufar y listo: tienes que engranar multitud de factores para obtener el resultado. Es una descripción modesta, pero certera. Los sistemas de almacenamiento se parecen menos a una aplicación convencional y más a tratados de paz entre capas hostiles que apenas se fían unas de otras.
El ecosistema de código abierto aporta ingredientes formidables, y las cabinas comerciales preparan el menú con ellos. A veces emplean piezas abiertas, a veces módulos privativos, y con frecuencia rutas de kernel personalizadas, motores de E/S en espacio de usuario, formatos propietarios de metadatos y años de pruebas ante fallos que nunca aparecen en los folletos publicitarios.
Los proveedores comerciales no revelan su fórmula secreta
Una réplica dijo lo que los fabricantes callan: si la pregunta es qué software exacto utiliza una cabina NVMe-oF comercial en sus entrañas, esa información es confidencial, y quien la conozca probablemente no la compartirá. Así funciona este negocio. Las partes que otorgan valor a una cabina corporativa suelen ser esos mecanismos internos rutinarios, curtidos en mil batallas, que ningún fabricante desea ver clonados.
Lo que protegen es el comportamiento, algo que una interfaz visual o la fórmula "Linux más controladores" no pueden darte: cómo conmuta la cabina ante fallos, cómo se actualiza, cómo recupera el servicio, cómo gestiona la caché sucia y las reservas, y cómo operan su plano de gestión, su telemetría y su soporte técnico. Los clientes solo reparan en todo eso cuando falla.
El impulso del ingeniero original era excelente. Reconstruir una versión simplificada es una de las mejores vías para aprender. La lección del debate es que el diseño de una SAN moderna se resume en decisiones minuciosas sobre fallos, y elegir componentes es la parte sencilla. Cada arquitectura debe contestar las mismas incógnitas. ¿Qué puede fallar? ¿Quién se entera? ¿Quién decide? ¿Quién frena las escrituras? ¿Quién mantiene el servicio? ¿Quién reconstruye la verdad después? Los malos sistemas evitan esas preguntas, los buenos definen respuestas y los excelentes demuestran esas respuestas bajo las condiciones más adversas.
El debate entre Linux y BSD esconde una duda mayor de diseño
La discusión sobre si las cabinas de almacenamiento usan Linux, BSD o algo más exótico resulta llamativa, pero puede convertirse en una distracción. El sistema operativo importa por licencias, controladores, proceso de arranque, herramientas y ecosistema. En cabinas profesionales, sin embargo, el dilema central de diseño reside en saber dónde reside la ruta de datos autoritativa, y qué sistema operativo arranca queda en segundo plano.
Determinados sistemas dependen de las pilas de almacenamiento del sistema operativo. Otros se saltan gran parte de la ruta del kernel por rendimiento, control o herencia técnica. Algunos exponen la gestión mediante entornos Unix reducidos mientras la ruta real de E/S corre en módulos propietarios. Ciertos diseños usan virtualización interna para sus servicios. Un participante mencionó que varios fabricantes usan bhyve para entregar funciones de gestión, interfaz y administración de datos en imágenes BSD compactas. A otro le causó gracia porque NetApp creó bhyve y aparentemente no terminó utilizándolo como hicieron los demás.
Ese apunte al margen resulta muy revelador. Los fabricantes de almacenamiento son pragmáticos. Reutilizan lo que encaja, inventan lo estrictamente necesario y arrastran decisiones pasadas durante décadas porque reescribir código de almacenamiento funcional es la forma más rápida de descubrir el miedo.
Un ingeniero de nube que examine el almacenamiento NVMe moderno puede esperar algo nuevo y reluciente. En la práctica, las cabinas más recientes suelen contener ideas veteranas vestidas con redes más veloces. Reservas, propiedad, fencing, journaling de metadatos, sumas de verificación, coherencia de caché, máquinas de estados de conmutación y políticas multipath son retos clásicos. NVMe solo acelera los procesos, incluidas las consecuencias de equivocarse.
Multipath es un contrato
El multipath suele verse como una ventaja práctica del lado cliente: múltiples rutas desde los hosts a las unidades de almacenamiento, mayor tolerancia a fallos y quizá mejor balanceo. En una cabina con doble controladora, multipath forma parte de un contrato más amplio entre host, red, propiedad de las controladoras y semántica de conmutación por error.
El host necesita saber qué rutas están operativas. La cabina debe exponer las rutas con coherencia. Durante un fallo, las rutas deben desaparecer, degradarse o cambiar de estado de forma que el host lo entienda. Si una controladora transfiere un namespace en una conmutación, el host no puede quedarse escribiendo en una ruta muerta de manera indefinida ni, peor aún, escribiendo en una zona insegura. Con NVMe-oF, el mecanismo ANA cumple un papel semejante al control de estados de ruta en entornos multipath anteriores, pero la pregunta de fondo sigue siendo la misma: ¿cómo saben los clientes dónde reside la información correcta en cada instante?
Esa cuestión enlaza directamente con la alta disponibilidad, que exige mucho más que dos equipos interconectados. Demanda sincronización de configuración, sincronización de estado, claridad en los dominios de fallo y un modelo de fencing suficientemente sólido para evitar el split-brain. Un participante lo definió con precisión: HA significa sincronización de configuración y estado con dominios de fallo bien delimitados. Suena elemental, pero es la frase contra la que toda cabina artesanal acaba estrellándose. Conectar dos controladoras es fácil; lograr que se comporten como un único sistema de almacenamiento coherente es lo difícil.
Por esto los ingenieros de almacenamiento viven en alerta permanente
El hilo resultó gratificante porque abordó el almacenamiento desde la ingeniería pura y no como una guerra de marcas. Alguien incluso bromeó diciendo que era una publicación sobre almacenamiento verdaderamente interesante y merecía diez votos positivos. La reacción tiene lógica. La pregunta apuntaba directa a la sala de máquinas del sector: ¿qué hay debajo de esas cabinas tan llamativas?
La respuesta combina tecnologías abiertas, herencia propietaria, dificultades de sistemas distribuidos y una dosis de prudencia obsesiva muy cara.
Un experimento casero de SAN moderna puede enseñar muchísimo. Conviene empezar en activo-pasivo. Usar nvmet o SPDK para exponer destinos. Estudiar device-mapper, metadatos de LVM, reservas persistentes, Pacemaker, Corosync y ZFS. Observar cómo reaccionan los hosts cuando las rutas oscilan. Desconectar cables, forzar la caída de controladoras y corromper metadatos en un laboratorio para comprobar qué ocurre cuando las suposiciones fallan. Ahí es donde arranca el verdadero aprendizaje.
También invita a la humildad. Las cabinas de almacenamiento corporativo resultan costosas en parte porque los fabricantes buscan buenos márgenes, algo innegable. Pero también son caras porque los componentes aburridos son difíciles, la matriz de posibles fallos es inmensa y los clientes esperan que el almacenamiento sea la única capa de la infraestructura que jamás parpadee. Las redes NVMe modernas han transformado la velocidad, pero los viejos fantasmas siguen presentes, ahora con menor latencia.