El dilema de almacenamiento de 120PB que encarece el código abierto
Hay preguntas sobre almacenamiento que hacen que todos en la sala se pongan rectos en su asiento, y ciento veinte petabytes para HPC e IA orientados a la investigación cuantitativa es una de ellas. Nadie pregunta qué NAS comprar. Tampoco es una fantasía de homelab con demasiados discos duros y pocos puertos USB, aunque se hicieran esas bromas, porque los profesionales del almacenamiento sobrellevan el pánico mediante el sarcasmo. Se trata de un proyecto con una huella física imponente, contratos de soporte, una batalla de compras y aproximadamente £30 million detrás de una apuesta a 3 años. Si sale mal, no será una migración incómoda: será un incidente que marcará carreras profesionales rodeado de racks.
La pregunta básica suena sencilla: ¿ir con DDN porque un contacto en NVIDIA lo recomendó como rentable a esta escala, o intentar ahorrar con Lustre de código abierto y quizás 3FS de DeepSeek, recomendado por colegas de Hong Kong y Alemania para cargas de trabajo de IA? Sobre el papel parece razonable. A 120PB, sin embargo, lo «razonable» queda devorado por la operativa diaria. La elección de fondo consiste en decidir si la organización quiere comprar un resultado con soporte garantizado, crear un equipo propio de ingeniería de almacenamiento o pretender equivocadamente que ambas cosas son lo mismo.
Con 120PB, la organización importa más que la plataforma de almacenamiento
El número más importante de toda la conversación es 3 años, más incluso que los 120PB. Ese plazo transforma el enfoque de la decisión. Cualquiera puede dibujar una arquitectura brillante en una pizarra. Muy pocos equipos consiguen mantenerla sana lidiando con firmware, fallos de hardware, ampliaciones de capacidad, ajustes de rendimiento, presión sobre los metadatos, hábitos de los usuarios, cambios de red, revisiones de seguridad, auditorías, escalados a proveedores y la presión constante de investigadores a los que solo les importa que sus trabajos terminen antes. A esta escala, el almacenamiento deja de ser una caja y se convierte en un modelo operativo.
Lustre en código abierto puede resultar sumamente potente y funciona en entornos serios de HPC por muy buenas razones. Pero «ahorrar un poco con Lustre de código abierto» es una de esas frases que exigen una advertencia clara. Ahorrar en licencias o en empaquetado comercial puede transferir el coste hacia personal, procesos, pruebas continuas y riesgo operativo. Puede ser un intercambio magnífico si la organización cuenta con el equipo adecuado, y una catástrofe si la dirección cree que el código abierto equivale a almacenamiento empresarial barato sin personal especializado.
Un participante resumió la visión más cínica de los sistemas de archivos scale-out con una broma: no es más que pegar servidores NAS con cinta adhesiva. Resulta injusto para la auténtica ingeniería de almacenamiento distribuido, pero la broma funciona porque los malos diseños scale-out suelen parecer exactamente eso: un grupo de nodos, un diagrama optimista y la plegaria de que la capa de metadatos no se convierta en una pesadilla ingobernable.
Lustre funciona. Lo delicado es si esta organización en concreto está preparada para asumir la gestión directa de Lustre a 120PB con usuarios de IA y de análisis cuantitativo respirándole en la nuca.
DDN es la respuesta clásica en HPC, lo que hace que las malas experiencias pesen más
El nombre de DDN surge de forma natural en este tipo de debates. El almacenamiento para HPC, los pipelines de entrenamiento de IA, las grandes cargas de trabajo científicas y los sistemas de archivos paralelos a gran escala son el terreno donde DDN lleva años presente, por lo que la recomendación de un contacto de NVIDIA no sorprende. A esa escala, una plataforma empaquetada y con soporte que comprende las cargas orientadas a alimentar GPUs y evita que el almacenamiento sea el cuello de botella cuenta con un argumento claro: invertir lo suficiente en almacenamiento para que el cómputo rinda, pero sin asfixiar el presupuesto destinado a procesamiento y redes.
Ese es el escenario optimista. Luego, los comentarios abrieron la puerta a otra perspectiva.
Una persona describió a DDN como terriblemente poco fiable y relató una historia desoladora sobre un técnico de servicios profesionales que estuvo días en las instalaciones tras una caída, solo para ser despedido en mitad de la reparación. Otra afirmó que cada interacción mantenida con DDN había sido nefasta, con incumplimientos de SLA críticos para el negocio. Una anécdota así no es un benchmark ni un informe de laboratorio, pero quienes compran almacenamiento ignoran estos testimonios bajo su propia responsabilidad, ya que la experiencia con el soporte técnico forma parte inseparable del producto.
Con 120PB, nadie adquiere solo tecnología. Se compran vías de escalado, logística de piezas de repuesto, experiencia sobre el terreno y la tranquilidad de que, si surge una anomalía un viernes por la noche, el fabricante no se convierta en un sistema adicional al que haya que depurar.
Para ser justos, cualquier proveedor importante de almacenamiento tiene historias para no dormir (incluidos NetApp, Dell, IBM, Pure y VAST), y los despliegues de código abierto desde luego no se libran. Lo que perjudicó a DDN en este hilo fue más allá de las dudas técnicas: fue el desgaste de la confianza. Si tu lista de candidatos arranca con «NVIDIA los recomendó» y las primeras réplicas responden con «lo desinstalamos en cuanto venció el contrato», la evaluación debe ser muchísimo más rigurosa.
NetApp entró en el debate con corona y signo de interrogación
Surgió un debate paralelo muy llamativo en torno a NetApp. Varios participantes la defendieron como la opción empresarial más segura. Un usuario afirmó que NetApp era el camino tras coincidir con las críticas hacia DDN. Otro defendió a NetApp con vehemencia, señalando que ONTAP acumula décadas de desarrollo a sus espaldas y que el almacenamiento empresarial premium justifica su precio cuando la seguridad, la gobernanza y los datos de investigación están en juego. Calificaban la alternativa como una compra de sistemas más baratos que exigen parches continuos y trasladan los problemas de actualizaciones constantes al mundo del almacenamiento.
Es el argumento clásico de NetApp. La madurez, el gobierno del dato, la seguridad y la solidez operativa tienen un peso innegable, y no todo debe convertirse en una carrera hacia lo más barato cuando la información es de alto valor.
La réplica contraria también fue contundente. Alguien cuestionó si NetApp encaja de verdad a una escala de 120PB en HPC e IA, sobre todo en lo relativo a NFS 4.2, pNFS, FlexFiles y servicios de metadatos. Otro sentenció sin rodeos: «No con 120PB». Otros debatieron si NetApp ofrece un NAS verdaderamente scale-out, si AFX alteraba el panorama y si un producto nuevo puede considerarse maduro solo porque la empresa que lo comercializa lo sea.
Este último matiz importa mucho, porque la madurez de un fabricante y la madurez de un producto son cosas distintas. Una compañía puede acumular 30 years de trayectoria en ingeniería y lanzar una arquitectura nueva que merezca una verificación exhaustiva; asimismo, un producto puede heredar ideas de plataformas veteranas y comportarse de forma muy diferente a gran escala. A los compradores les reconforta la reputación de marca, pero a la física y a los metadatos eso les tiene sin cuidado.
NetApp puede ser una opción sólida para la gestión de datos corporativos, e incluso la elección idónea para ciertos segmentos de una infraestructura de 120PB. Sin embargo, para espacio de scratch en HPC e IA, datos de entrenamiento y accesos paralelos a esta escala, limitarse a decir que NetApp es una solución empresarial resulta insuficiente. La demostración debe centrarse en las cargas de trabajo concretas.
El problema de las startups es en realidad un problema de confianza
El hilo mostró también una marcada desconfianza hacia las startups. Varios comentarios miraban con recelo a VAST y a Hammerspace. Uno afirmó que prefería confiar antes en NetApp que en una startup montada sobre servidores genéricos (white-box), mientras otro pronosticó que Hammerspace desaparecería o sería adquirida en menos de cinco años. Aunque estas opiniones suenen tajantes, reflejan un temor de compras fundado: ¿qué ocurre si el rumbo del proveedor cambia antes de que concluya el ciclo de vida de los datos?
Con 120PB, la viabilidad del fabricante a largo plazo es decisiva. Migrar resulta complicadísimo y los costes de salida son dolorosos. La gravedad de los datos deja de ser una metáfora para convertirse en una fuerza física y económica. Si una plataforma resulta una elección errónea, abandonarla puede exigir años de trabajo, capacidad duplicada temporalmente, reingeniería de redes, ventanas de inactividad, modificaciones en el software y una disciplina de proyecto agotadora para el equipo.
Descartar nuevas plataformas por el mero hecho de ser recientes puede ser simplista. Ciertas arquitecturas modernas existen precisamente porque los sistemas tradicionales no se concibieron para los patrones de acceso de la era de la IA. VAST capta el interés en entornos de big data e inteligencia artificial porque intenta superar los compromisos clásicos de almacenamiento entre rendimiento, capacidad y diseño del espacio de nombres. Hammerspace destaca porque la orquestación global de datos y los accesos basados en metadatos responden a necesidades reales. Los proveedores emergentes no son imprudentes por defecto, pero tienen la obligación de demostrar su soporte, su hoja de ruta, su viabilidad económica y su tolerancia a fallos a la escala requerida.
Para un entorno de investigación de 120PB, la opción más prudente puede no ser el fabricante más veterano ni la arquitectura más novedosa. Puede ser aquella plataforma capaz de soportar la carga real de trabajo de la organización y responder al teléfono con solvencia técnica cuando algo falle.
3FS de DeepSeek es emocionante, pero el entusiasmo no es una estrategia de almacenamiento
La mención a 3FS de DeepSeek aporta un aire renovado propio de la IA al debate. Los equipos de inteligencia artificial valoran las propuestas de infraestructura frescas porque el entrenamiento de modelos y los flujos de datos sacan a relucir cuellos de botella con rapidez. Si compañeros de Hong Kong y Alemania recomiendan 3FS, merece la pena investigarlo. A 120PB, sin embargo, esa recomendación debe abrir una fase de pruebas en laboratorio, no cerrar un expediente de compras.
Los sistemas de archivos emergentes pueden deslumbrar en el entorno para el que fueron diseñados. La dificultad empieza cuando se enfrentan al modelo de seguridad, los usuarios, el planificador de tareas, la red, las normativas de cumplimiento, las expectativas de soporte, los ciclos de actualización y los modos de fallo de otra organización distinta. De repente, esa arquitectura elegante exige documentación, utilidades, integración con copias de seguridad, observabilidad, cuotas, control del ciclo de vida, procedimientos de recuperación y especialistas capaces de solventar incidencias cuando los desarrolladores originales duermen o están ilocalizables.
3FS aún puede ganarse su sitio, pero los datos de investigación en producción no deberían gestionarse como un proyecto experimental a menos que la organización desee explícitamente convertirse en parte de ese experimento.
Los sistemas emergentes y de código abierto funcionan mejor cuando el equipo técnico cuenta con la solvencia interna suficiente para participar activamente y no limitarse a ser un mero consumidor. Eso implica leer código fuente, comprender los modos de fallo, aportar correcciones, crear automatizaciones, diseñar la monitorización y asumir que el soporte no se parecerá al escalado tradicional con un fabricante. Si la organización busca ese grado de control, perfecto. Si prefiere una experiencia similar a la de un appliance a 120PB, el desenlace será más duro, y el software más económico puede acabar siendo el sistema más costoso si el equipo debe aprender a dominarlo durante una caída de servicio.
Las bromas eran absurdas porque la escala es absurda
El hilo de comentarios hizo lo que siempre ocurre en los foros técnicos cuando una cifra resulta inverosímil: derivar hacia la comedia. Alguien preguntó si 120PB bastarían para almacenar contenido para adultos. Otro bromeó sobre cuántas imágenes ISO de Linux cabrían ahí. Otro imaginó miles de adaptadores USB a SATA y el desafío de reunir 4,000 puertos USB. Son disparates, pero el humor ayuda a asimilar peticiones de almacenamiento tan descomunales que parecen irreales.
Bajo esas bromas subyace una realidad palpable: 120PB implican electricidad, refrigeración, superficie de suelo técnico, redes, tiempos de reconstrucción, tasas de fallo de discos, repuestos, dominios de firmware, estrategias de protección del dato, diseño del espacio de nombres, hábitos de los clientes, monitorización y políticas presupuestarias. A esta escala, hasta los porcentajes mínimos representan volúmenes masivos. El uno por ciento de 120PB es 1.2PB. Un error de migración deja de ser un problema de carpetas, un cuello de botella de rendimiento deja de ser una queja aislada y una mala decisión en compras puede dilapidar millones.
Por eso las analogías con el almacenamiento doméstico caen por su propio peso. No puedes extrapolar la mentalidad de un homelab a este tipo de sistemas, ni limitarte a añadir discos sin dominar las fórmulas de reconstrucción, la densidad por rack, el consumo energético, la sobresuscripción de la red y el personal operativo requerido. Tampoco puedes decidirte por la recomendación aislada de un proveedor, una mala experiencia leída en un foro o un proyecto favorito de código abierto. La escala misma es el desafío, y cada elección de diseño añade una carga enorme.
El debate central: soporte frente a control
La forma más constructiva de enfocar la decisión es comparar soporte frente a control, en vez de reducirlo a DDN contra Lustre, 3FS, NetApp o VAST.
La plataforma de un fabricante te ofrece un responsable directo al que exigir explicaciones, configuraciones probadas, contratos de soporte, arquitecturas de referencia y, por lo general, rigor en los ciclos de vida. A cambio, introduce dependencia tecnológica, presión en las tarifas, ataduras a su hoja de ruta y el riesgo de que la calidad del soporte defraude justo en el momento más crítico.
Una solución interna o basada en código abierto aporta control, transparencia, flexibilidad y, potencialmente, un mejor rendimiento económico a nivel de hardware. No obstante, convierte a tu propio equipo en el escalado final ante cualquier fallo. Eres responsable de la integración, los errores atípicos, el ajuste fino del rendimiento y las consecuencias directas de tener un equipo reducido.
Ninguno de los dos enfoques es intrínsecamente superior, pero confundirlos puede resultar letal. Si la organización cuenta con ingenieros de almacenamiento de élite en HPC, sólidos conocimientos de Linux y sistemas de archivos paralelos, entornos de prueba rigurosos y la disposición de actuar internamente como un proveedor de almacenamiento, Lustre en código abierto o incluso opciones más recientes pueden ser viables. Si prefiere concentrarse en la investigación cuantitativa y la inteligencia artificial en lugar de convertirse en una división de almacenamiento, contratar una plataforma con soporte tiene mucho más sentido, aun asumiendo un sobrecoste.
La opción costosa puede resultar más rentable si mantiene a los investigadores trabajando a pleno rendimiento, y la alternativa económica puede ser preferible si el equipo tiene capacidad real para dominarla. El auténtico error radica en comprar barato mientras se dimensiona el personal como si existiera un soporte prémium detrás.
La prueba de concepto debe ser despiadada
Con 120PB, una prueba de concepto convencional se queda corta. Los proveedores brillan en las demostraciones comerciales y los sistemas de archivos responden de maravilla en condiciones ideales. Las cargas de investigación son cualquier cosa menos un camino de rosas: avalanchas de metadatos, lecturas secuenciales masivas, accesos aleatorios continuos, ráfagas intensas de checkpoints, el suplicio de los ficheros diminutos, flujos de entrenamiento de modelos, limpiezas traumáticas de áreas temporales de scratch y usuarios que encontrarán la manera más insospechada de saturar el espacio de nombres.
Por eso la evaluación debe ser implacable. Hay que probar la carga de trabajo real, la desatención de GPUs por falta de datos, directorios repletos de metadatos y picos repentinos de checkpoints. Conviene estresar el sistema con lecturas y escrituras combinadas, caídas de clientes, pérdidas de racks enteros y congestión en la red, forzando reconstrucciones mientras los usuarios continúan lanzando procesos. Hay que evaluar actualizaciones de software, funcionamiento de cuotas, snapshots o mecanismos de protección del dato si se precisan, auditorías, gobernanza y tiempos de restauración. Y después, comprobar qué ocurre cuando el soporte de primer nivel del fabricante proporciona una respuesta equivocada.
Exige a cada proveedor 3 referencias reales a una escala semejante y con un tipo de carga comparable, ya que una diapositiva con logotipos apenas demuestra nada. Pregunta por despliegues fallidos y por los aspectos que más descontento generan entre sus clientes. Averigua qué ocurre si la capacidad se duplica y cómo varía la estructura de precios cuando el sistema demanda mayor rendimiento de metadatos en vez de capacidad bruta. Consulta cómo se gestiona la movilidad de los datos si llega el momento de sustituir la plataforma y cuánto tardaría una migración completa. Un proveedor riguroso sabrá defenderse ante cuestiones difíciles, mientras que uno frágil se escudará en diagramas de arquitectura.
El presupuesto es grande, pero no infinito
Treinta millones de libras en 3 años parece una cantidad desorbitada hasta que se enfrenta a 120PB de almacenamiento para HPC e IA, equipamiento de red, contratos de soporte, piezas de repuesto, energía, centros de datos y plantilla técnica. La adquisición del almacenamiento representa solo una parte. Si el contacto de NVIDIA presentó a DDN como una opción rentable porque liberaba fondos para cómputo y redes, se trata de una inquietud sistémica muy razonable. La infraestructura de IA exige equilibrio. Si gastas de más en almacenamiento, las GPUs tendrán que conformarse con un clúster más modesto; si recortas en exceso, las GPUs sufrirán por falta de datos. En ambos casos, procesadores carísimos quedarán infrautilizados como un reproche constante.
Por esta razón, evaluar únicamente el coste por petabyte resulta engañoso; el coste por resultado científico útil es un indicador mucho más acertado. Si una solución de almacenamiento más cara mantiene alimentados los aceleradores, reduce caídas, simplifica la operativa y evita contratar a un ejército de especialistas, en la práctica resultará más barata. Si una opción más económica en código abierto rinde adecuadamente y el equipo la gestiona con solvencia, el sobreprecio del fabricante será un gasto superfluo. La única equivocación real consiste en optimizar el precio de compra obviando por completo el gasto operativo.
A 120PB, cualquier ineficiencia se traduce en una partida presupuestaria, cada parada del servicio sale carísima, cada migración desata tensiones internas y cada enlace de red mal dimensionado deviene en un cuello de botella con nombre propio y reuniones de urgencia. El presupuesto debe servir para comprar capacidad, desde luego, pero por encima de todo debe comprar tranquilidad operativa.
Puede que no exista una única plataforma para gobernarlo todo
El hilo tiende de forma espontánea a buscar «el mejor almacenamiento» como una respuesta única, cuando la arquitectura real suele estructurarse en capas. Los entornos de HPC e IA presentan diversas facetas de almacenamiento: datos calientes de entrenamiento, espacio temporal para scratch, repositorios de checkpoints, conjuntos de datos de investigación a largo plazo, datos corporativos sujetos a gobernanza estricta, archivado, copias de seguridad y replicación. Es poco probable que un solo producto encaje de forma óptima en todas ellas.
Plataformas como DDN o Lustre tienen sentido para cargas paralelas de alto rendimiento. NetApp puede ser perfecta para NAS corporativo con gobernanza o datos de investigación con altos requerimientos de seguridad y cumplimiento. El almacenamiento de objetos encaja en determinados pipelines, y la cinta o el archivado frío continúan vigentes para la retención a largo plazo. VAST puede responder bien a casos de uso de datos no estructurados de gran velocidad, y 3FS merece un entorno de pruebas si los flujos específicos de IA aprovechan sus puntos fuertes.
Encajar cada carga de trabajo en una sola plataforma puede agilizar la contratación, pero complica el día a día. Dividir las cargas en varias plataformas mejora la adecuación técnica, aunque añade complejidades en la gestión y el trasvase de datos. No hay soluciones milagrosas, solo distintas combinaciones de compromisos y concesiones.
La clasificación de los datos marca el rumbo. ¿Qué debe ser rápido, qué debe estar auditado, qué requiere bajo coste, qué exige retención prolongada o distribución global? ¿Qué información puede regenerarse y cuál resulta insustituible? ¿Qué patrones de acceso existen hoy y cuáles surgirán en cuanto los usuarios descubran que el nuevo sistema responde con mucha más agilidad? La arquitectura de almacenamiento debe adaptarse al comportamiento del dato, no a las promesas de los folletos comerciales.
La respuesta sensata es incómoda: adquiere experiencia antes de comprar petabytes
La recomendación más prudente para un proyecto de 120PB en HPC e IA no es «elige DDN», ni «quédate con NetApp», ni «despliega Lustre». Consiste en garantizar que la organización cuente con criterio técnico independiente antes de comprometer los fondos. Contrata o incorpora profesionales que hayan gestionado almacenamiento a esta escala y hayan lidiado con fallos de OST, cuellos de botella en metadatos, avalanchas de clientes, escalados conflictivos con fabricantes, firmware defectuoso y sistemas millonarios comportándose de forma errática con usuarios reales, en lugar de perfiles que solo hayan visto grandes cifras en diapositivas.
La organización debería organizar una comparativa técnica estructurada y, en paralelo, una auditoría de recursos humanos. ¿Quién va a operar el entorno, ajustarlo y aplicar parches? ¿Quién atenderá las quejas de los usuarios? ¿Quién sabrá distinguir si una caída de rendimiento procede del almacenamiento, la red, el gestor de colas, las GPUs, la aplicación o el sistema de archivos? ¿Quién liderará la planificación de capacidad, justificará los costes ante finanzas y diseñará la estrategia de salida? Si esas respuestas no están claras, decantarse por una tecnología resulta precipitado.
Un programa de almacenamiento de £30 million no puede guiarse únicamente por las recomendaciones de un fabricante, ni siquiera si proceden de NVIDIA. Tampoco debe definirse por malas experiencias leídas en un foro, por alarmantes que parezcan. Exige pruebas reales sobre las cargas de trabajo, referencias directas de otros clientes, diseño operativo, modelos financieros y una decisión nítida sobre si el equipo busca un producto llave en mano o una plataforma que deba cogestionar internamente.
La decisión final trata sobre qué tipo de dolor resulta asumible
DDN puede seguir siendo la opción adecuada si la carga de trabajo encaja en los patrones clásicos de HPC e IA, las referencias de otros clientes son sólidas, el contrato de soporte tiene cláusulas estrictas y la prueba de concepto ratifica un rendimiento consistente en condiciones adversas. Los testimonios negativos obligan a examinar con lupa el modelo de soporte, pero no justifican un descarte automático.
Lustre en código abierto puede ser la alternativa acertada si la organización dispone del talento técnico y la determinación de gestionarlo con rigor, ya que el ahorro solo es tangible si el modelo operativo es viable. Puede merecer la pena poner a prueba 3FS de DeepSeek, en especial para flujos orientados a IA, pero debe ganarse la confianza en producción paso a paso. NetApp puede ser formidable para datos empresariales regulados y ciertas necesidades scale-out, pero cualquier promesa de rendimiento a 120PB en HPC e IA debe demostrarse sobre el terreno y no darse por sentada por la reputación de la marca. VAST y otras arquitecturas más recientes merecen atención, pero la viabilidad del fabricante, la calidad del soporte y los costes de salida exigen tanta consideración como las cifras de rendimiento.
A 120PB le da igual el fabricante preferido de cada cual, la ideología sobre el código abierto, la fidelidad de marca, el entusiasmo por las startups o quién tuvo una mala experiencia de soporte en 2021. Le importan los dominios de fallo, los metadatos, el ancho de banda, la latencia, los tiempos de reconstrucción, las personas, el consumo eléctrico, la refrigeración, la red y si la plataforma sigue teniendo sentido cuando todo el equipo está agotado. A esta escala, la duda de «qué almacenamiento comprar» se transforma en «con qué modo de fallo estamos dispuestos a convivir», y esa elección viene implícita en cada petabyte.