Die 120-PB-Storage-Frage, die jede „Nimm doch Open Source“-Antwort plötzlich teuer aussehen lässt

Es gibt Storage-Fragen, und dann gibt es Storage-Fragen, bei denen sich alle im Raum aufrechter hinsetzen. Einhundertzwanzig Petabyte für HPC und KI zur Unterstützung quantitativer Forschung gehören zur zweiten Kategorie. Das ist kein „Welches NAS soll ich kaufen?“-Problem, und es ist auch keine Homelab-Fantasie mit zu vielen Festplatten und zu wenigen USB-Ports, auch wenn genau solche Witze gemacht wurden, weil Storage-Leute Terror mit Sarkasmus verarbeiten. Das ist ein Programm mit physischem Footprint, Supportvertrag, Beschaffungskrieg und einer Drei-Jahres-Wette, hinter der rund 30 Millionen Pfund stehen. Geht es schief, wird daraus ein karriereprägender Vorfall mit Racks.

Die Kernfrage klingt trügerisch einfach: DDN nehmen, weil ein NVIDIA-Kontakt es in dieser Größenordnung als kosteneffizient empfohlen hat, oder mit Open-Source-Lustre und vielleicht DeepSeeks 3FS Geld sparen, das Kollegen in Hongkong und Deutschland für KI-Workloads empfohlen hatten? Auf dem Papier ist das eine vernünftige Frage. Bei 120 PB wird „vernünftig“ allerdings vom Betrieb bei lebendigem Leib gefressen, und entschieden wird am Ende etwas ganz anderes: ob die Organisation ein unterstütztes Ergebnis kaufen, ein Storage-Engineering-Team aufbauen oder versehentlich so tun will, als wäre beides dasselbe.

Bei 120 PB wird das Betriebsmodell zum eigentlichen Produkt

Die drei Jahre sind in dieser Diskussion die wichtigere Zahl als die 120 PB. Dieser Zeitrahmen verändert die Textur der Entscheidung, denn eine großartige Architektur kann jeder auf ein Whiteboard zeichnen. Weniger Teams können diese Architektur anschließend durch Firmware, Ausfälle, Kapazitätserweiterungen, Performance-Tuning, Metadaten-Druck, Nutzerverhalten, Netzwerkänderungen, Sicherheitsüberprüfungen, Audits, Vendor-Eskalationen und das langsame Mahlwerk von Forschern gesund halten, denen nur wichtig ist, dass ihre Jobs schneller fertig werden. In dieser Größenordnung hört Storage auf, eine Box zu sein, und wird zu einem Betriebsmodell.

Open-Source-Lustre kann absolut leistungsfähig sein. Es existiert aus gutem Grund in ernsthaften HPC-Umgebungen. Aber „mit Open-Source-Lustre etwas sparen“ ist einer dieser Sätze, die ein Warnetikett brauchen. Wer bei Lizenzierung oder Vendor-Verpackung spart, verschiebt Kosten in Richtung Personal, Prozesse, Tests und Risiko. Das kann ein hervorragender Tausch sein, wenn die Organisation das nötige Team hat. Es kann katastrophal sein, wenn die Führungsebene glaubt, „Open Source“ bedeute „günstiger Enterprise-Storage ohne Enterprise-Personal“.

Ein Kommentator brachte die zynische Version von Scale-out-Dateisystemen auf einen Witz: Es sei einfach, NAS-Server mit Klebeband zusammenzuflicken. Das ist unfair gegenüber echtem verteiltem Storage-Engineering, aber der Witz zieht, weil schlechte Scale-out-Designs sich oft genau so anfühlen. Ein paar Knoten, ein mutiges Diagramm und das Gebet, dass die Metadaten-Ebene nicht zum Spukhaus wird.

Lustre funktioniert. Offen ist, ob genau diese Organisation bereit ist, Lustre bei 120 PB mit KI- und quantitativen Forschungsnutzern im Nacken selbst zu betreiben.

DDN ist die naheliegende HPC-Antwort, was die Horrorgeschichten umso härter treffen lässt

DDNs Name taucht in solchen Gesprächen naturgemäß auf. HPC-Storage, KI-Trainings-Pipelines, große wissenschaftliche Workloads, große parallele Dateisysteme: das ist die Welt, in der DDN seit Langem zum Vokabular gehört. Dass ein NVIDIA-Kontakt DDN empfiehlt, überrascht nicht. In dieser Größenordnung hat eine gepackte, unterstützte Plattform, die GPU-gespeiste Workloads versteht und verhindert, dass die Storage-Seite zum Flaschenhals wird, ein klares Argument: genug für Storage ausgeben, um die Rechenleistung nutzbar zu machen, aber nicht so viel, dass das Budget bei Verarbeitung und Netzwerk geraubt wird.

Das ist der optimistische Fall. Dann traten die Kommentare die Tür ein.

Eine Person beschrieb DDN als schrecklich unzuverlässig und erzählte eine brutale Geschichte über einen Professional-Services-Mitarbeiter, der nach einem Ausfall tagelang vor Ort war, nur um mitten in der Reparatur entlassen zu werden. Eine andere sagte, jede Interaktion, die sie mit DDN gehabt habe, sei katastrophal gewesen, einschließlich geschäftskritischer SLA-Verletzungen. Solche Anekdoten sind kein Benchmark und kein Laborergebnis. Aber Storage-Käufer ignorieren solche Geschichten auf eigene Gefahr, weil Support-Erfahrung Teil des Produkts ist.

Bei 120 PB kauft man mit der Technologie immer auch Eskalationspfade, Ersatzteil-Logistik, Feldexpertise und das Vertrauen, dass der Vendor nicht zu einem weiteren System wird, das man debuggen muss, wenn Freitagnacht etwas Seltsames passiert.

Fair betrachtet hat jeder große Storage-Vendor seine Horrorgeschichten, NetApp, Dell, IBM, Pure und VAST eingeschlossen, und Open-Source-Deployments haben sie definitiv auch. Bei DDN ging es in diesem Thread aber um mehr als technische Skepsis, nämlich um Vertrauensschaden. Wenn Ihre Shortlist mit „NVIDIA hat sie empfohlen“ beginnt und die ersten Antworten „wir haben es nach Vertragsablauf rausgerissen“ lauten, muss die Bewertung deutlich schärfer werden.

NetApp betrat die Debatte mit Krone und Fragezeichen

Um NetApp bildete sich eine faszinierende Nebendebatte. Manche pushten es als sicherere Enterprise-Wahl. Ein Kommentator sagte, nachdem er der DDN-Kritik zugestimmt hatte: „NetApp ist der richtige Weg.“ Ein anderer verteidigte NetApp vehement und argumentierte, ONTAP habe Jahrzehnte an Entwicklung hinter sich, und Premium-Enterprise-Storage könne sich lohnen, wenn Sicherheit, Governance und Forschungsdaten eine Rolle spielten. Die Alternative rahmten sie als den Kauf billigerer Systeme, die ständiges Herumfrickeln erfordern und „Patch Tuesdays“ in die Storage-Welt bringen.

Das ist das klassische NetApp-Argument: Reife, Governance, Sicherheit und operative Politur zählen, und wenn die Daten wertvoll sind, sollte nicht alles zum Wettlauf nach unten werden.

Auch das Gegenargument war scharf. Jemand hinterfragte, ob NetApp bei 120 PB HPC/KI-Größenordnung wirklich passt, besonders rund um NFS 4.2, pNFS, FlexFiles und Metadatendienste. Ein anderer sagte schlicht: „Nicht bei 120 PB.“ Andere diskutierten, ob NetApp echtes Scale-out-NAS habe, ob AFX das Bild ändere, und ob man ein neues Produkt schon deshalb als ausgereift bezeichnen könne, weil das Unternehmen dahinter ausgereift sei.

Dieser letzte Punkt ist wichtig, denn Vendor-Reife und Produktreife sind zwei verschiedene Dinge. Ein Unternehmen kann 30 Jahre Engineering-Geschichte haben und trotzdem eine neue Architektur ausliefern, die sorgfältigen Nachweis verdient. Ein Produkt kann Ideen von ausgereiften Systemen erben und sich in großem Maßstab trotzdem anders verhalten. Käufer lieben Markenkomfort, aber Physik und Metadaten kümmern sich nicht um Markenkomfort.

NetApp mag eine ernsthafte Option für Enterprise-Datenmanagement sein, vielleicht sogar die richtige Option für bestimmte Teile eines 120-PB-Bestands. Für HPC/KI-Scratch, Trainingsdaten und parallelen Zugriff in dieser Größenordnung reicht „NetApp ist Enterprise“ trotzdem nicht aus. Der Nachweis muss workload-spezifisch sein.

Das Startup-Problem ist eigentlich ein Vertrauensproblem

Der Thread trug auch einen deutlich Startup-kritischen Ton. VAST und Hammerspace wurden von manchen Kommentatoren mit Misstrauen behandelt. Eine Person sagte, sie würde NetApp jederzeit einem Startup vorziehen, das auf White-Box-Systemen läuft. Eine andere prognostizierte, Hammerspace werde innerhalb von fünf Jahren verschwunden oder aufgekauft sein. Diese Kommentare mögen abwertend klingen, aber sie deuten auf eine reale Beschaffungsangst hin: Was passiert, wenn sich die Vendor-Geschichte ändert, bevor der Daten-Lebenszyklus endet?

Bei 120 PB zählt die Überlebensfähigkeit des Vendors. Migration ist nicht einfach, Exit-Kosten sind brutal, und Data Gravity wirkt hier ganz real als physische und wirtschaftliche Kraft. Wird eine Plattform strategisch falsch, kann der Wechsel Jahre, temporäre doppelte Kapazität, Netzwerkplanung, Ausfallfenster, Anwendungsänderungen und ein Maß an Projektdisziplin erfordern, das alle zur Verzweiflung treibt.

Allerdings kann es auch faul sein, neuere Plattformen einfach abzutun, nur weil sie neuer sind. Manche Architekturen aus der Startup-Ära existieren, weil ältere Systeme nicht für Zugriffsmuster im KI-Zeitalter gebaut wurden. VAST etwa bekommt Aufmerksamkeit in Big-Data- und KI-Gesprächen, weil es versucht, einige klassische Storage-Trade-offs rund um Performance, Kapazität und Namespace-Design aufzuheben. Hammerspace bekommt Aufmerksamkeit, weil globale Datenorchestrierung und metadatengesteuerter Zugriff reale Probleme sind. Entscheidend ist, ob diese Vendoren Support, Roadmap, Wirtschaftlichkeit und Ausfallverhalten in der erforderlichen Größenordnung nachweisen können.

Für eine 120-PB-Forschungsumgebung ist die sicherste Wahl vielleicht weder der älteste Vendor noch die neueste Architektur. Es könnte die Plattform sein, die den tatsächlichen Workload der Organisation überlebt und trotzdem intelligent ans Telefon geht, wenn etwas kaputtgeht.

DeepSeeks 3FS ist aufregend, aber Aufregung ist keine Storage-Strategie

Die Erwähnung von DeepSeeks 3FS verleiht der gesamten Debatte eine neuere KI-Note. KI-Teams lieben frische Infrastruktur-Ideen, weil Modelltraining und Datenpipelines Schmerzpunkte schnell offenlegen. Wenn Kollegen in Hongkong und Deutschland 3FS empfehlen, ist das eine Untersuchung wert. Aber bei 120 PB sollte „Kollegen haben es empfohlen“ eine Laborbewertung starten und keinen Beschaffungsprozess beenden.

Aufstrebende Dateisysteme können in der Umgebung, für die sie gebaut wurden, unglaublich aussehen. Dann treffen sie auf das Sicherheitsmodell, die Nutzerbasis, den Scheduler, das Netzwerk, den Compliance-Prozess, die Support-Erwartungen, den Update-Rhythmus und die Ausfallmodi einer anderen Organisation. Plötzlich braucht die elegante Architektur Dokumentation, Tooling, Backup-Integration, Observability, Quotas, Lifecycle-Kontrollen, Wiederherstellungsverfahren und Menschen, die sie tief genug verstehen, um sie zu reparieren, wenn die ursprünglichen Autoren schlafen oder unerreichbar sind.

Das ist kein Einwand gegen 3FS. Produktive Forschungsdaten sollte man aber nur dann wie ein Wissenschaftsprojekt behandeln, wenn die Organisation explizit Teil dieses Wissenschaftsprojekts werden will.

Open-Source- und aufstrebende Systeme funktionieren am besten, wenn das Team genug interne Engineering-Stärke hat, um ein echter Teilnehmer zu sein und kein reiner Konsument. Das bedeutet Code lesen, Ausfallmodi verstehen, Fixes beisteuern, Automatisierung bauen, Monitoring entwerfen und akzeptieren, dass Support möglicherweise nicht wie eine klassische Vendor-Eskalation aussieht. Wenn die Organisation dieses Maß an Kontrolle will, umso besser. Wenn sie bei 120 PB eine Appliance-artige Erfahrung will, wird die Realität weniger gnädig sein, denn die billigste Software kann zum teuersten System werden, sobald das Team sie während eines Ausfalls lernen muss.

Die Witze waren absurd, weil die Größenordnung absurd ist

Der Kommentarthread tat auch das, was technische Foren immer tun, wenn eine Zahl lächerlich wird: Er verwandelte sich in Comedy. Jemand fragte, ob 120 PB für eine Erwachsenensammlung ausreichen würden. Jemand witzelte über die Anzahl an Linux-ISOs, die hineinpassen. Ein anderer stellte sich Tausende von USB-zu-SATA-Adaptern vor und die Herausforderung, 4.000 USB-Ports zu finden. Es ist albern, aber es erfüllt einen Zweck. Witze sind die Art, wie Menschen eine Storage-Anfrage mental verarbeiten, die groß genug ist, um sich unwirklich anzufühlen.

Unter den Witzen steckt eine nützliche Wahrheit: 120 PB sind mehr als „eine Menge Festplatten“. Es sind Strom, Kühlung, Stellfläche, Netzwerk, Rebuild-Zeit, Ausfallraten, Ersatzteile, Firmware-Domänen, Datenschutzstrategie, Namespace-Design, Client-Verhalten, Monitoring und Budgetpolitik. In dieser Größenordnung werden selbst winzige Prozentsätze riesig. Ein Prozent von 120 PB sind 1,2 PB. Ein Migrationsfehler betrifft dann keinen Ordner, ein Performance-Engpass keinen einzelnen wütenden Nutzer, und eine falsche Beschaffungsannahme kann Millionen verschwenden.

Deshalb bricht konsumentenartiges Denken sofort zusammen. Man kann sich nicht per Homelab in diese Systemklasse vorarbeiten. Man kann nicht einfach „Festplatten hinzufügen“, ohne Rebuild-Mathematik, Rack-Dichte, Strom, Netzwerk-Überbuchung und operative Personaldecke zu verstehen. Und man kann nicht auf Basis einer einzigen Vendor-Empfehlung, einer einzigen Horrorgeschichte oder eines einzigen Lieblings-Open-Source-Projekts auswählen. Die Größenordnung selbst ist der Gegner, und jede Design-Entscheidung wird dadurch schwerer.

Support gegen Kontrolle

Am nützlichsten lässt sich die Entscheidung als Support gegen Kontrolle rahmen. Die Namensliste DDN, Lustre, 3FS, NetApp, VAST ordnet sich dieser Frage unter.

Eine Vendor-Plattform gibt Ihnen jemanden, den Sie zur Rechenschaft ziehen können, eine getestete Konfiguration, Supportverträge, Referenzarchitekturen und meist ein gewisses Maß an Lifecycle-Disziplin. Sie gibt Ihnen auch Vendor-Lock-in, Preisdruck, Roadmap-Abhängigkeit und die Möglichkeit, dass die Support-Qualität genau dann enttäuscht, wenn Sie sie am meisten brauchen.

Ein Open-Source- oder selbstgebauter Ansatz gibt Ihnen Kontrolle, Transparenz, Flexibilität und potenziell bessere Wirtschaftlichkeit in großem Maßstab. Er macht auch Ihr eigenes Team zum Eskalationspfad: Ihnen gehören die Integration, die seltsamen Bugs, das Performance-Tuning und die Konsequenzen einer Unterbesetzung. Klüger ist keines der beiden Modelle von sich aus, aber sie zu verwechseln ist tödlich.

Hat die Organisation elite HPC-Storage-Ingenieure, starke Linux- und Parallel-Filesystem-Expertise, richtige Testumgebungen und den Appetit, intern wie ein Storage-Vendor zu operieren, könnten Open-Source-Lustre oder sogar aufstrebende Optionen tragfähig sein. Will die Organisation sich auf quantitative Forschung und KI konzentrieren, statt zu einem Storage-Produktunternehmen zu werden, macht der Kauf einer unterstützten Plattform mehr Sinn, selbst zu einem Aufpreis.

Die teure Lösung kann günstiger sein, wenn sie Forscher produktiv hält, und die günstige Lösung kann besser sein, wenn das Team sie tatsächlich betreiben kann. Zur Katastrophe wird es, günstig zu kaufen und dabei so zu besetzen, als gäbe es teuren Support.

Der Proof of Concept muss grausam sein

Bei 120 PB reicht ein normaler Proof of Concept nicht aus. Vendoren sind gut in Demos, Dateisysteme sind gut in Happy Paths, und Forschungs-Workloads sind keine Happy Paths. Sie sind Metadaten-Stürme, riesige sequenzielle Lesevorgänge, zufällige Zugriffsmuster, Checkpoint-Bursts, Small-File-Elend, Modelltraining-Pipelines, Scratch-Cleanup-Katastrophen und Nutzer, die garantiert den seltsamsten möglichen Weg finden werden, den Namespace zu missbrauchen. Die Bewertung darf deshalb ruhig gemein sein.

Testen Sie den echten Workload, GPU-Hunger, metadatenlastige Verzeichnisse, Checkpoint-Stürme, gemischten Lese- und Schreibdruck, Client-Ausfälle, Rack-Verlust und Netzwerküberlastung. Testen Sie Rebuilds, während Nutzer weiter Jobs laufen lassen, dazu Software-Updates, Quota-Verhalten, Snapshots oder Datenschutz, falls erforderlich, Audit und Governance und den Restore. Und testen Sie, was passiert, wenn der First-Line-Support des Vendors die falsche Antwort gibt.

Fragen Sie jeden Vendor nach drei Referenzen in ähnlicher Größenordnung und mit ähnlichem Workload, nicht nur nach Logos. Fragen Sie nach gescheiterten Deployments, danach, was Kunden hassen, und danach, was passiert, wenn sich die Kapazität verdoppelt. Fragen Sie, wie sich die Preise ändern, wenn das System mehr Metadaten-Performance statt roher Kapazität braucht, wie Datenmobilität aussieht, falls die Plattform ersetzt werden muss, und wie lange eine vollständige Migration wirklich dauern würde. Ein ernsthafter Vendor sollte harte Fragen überstehen, ein schwacher zieht sich in Architekturdiagramme zurück.

Das Budget ist groß, aber nicht unendlich

Dreißig Millionen Pfund über drei Jahre klingen riesig, bis sie auf 120 PB HPC/KI-Storage, Netzwerk, Support, Ersatzteile, Strom, Facilities und Personal treffen. Der Storage-Kauf ist nur ein Teilstück. Wenn der NVIDIA-Kontakt DDN als kosteneffizient dargestellt hat, weil es mehr Budget für Verarbeitung und Netzwerke freisetzt, ist das ein valides systemisches Argument. KI-Infrastruktur ist eine Balance. Wer bei Storage überzieht, lässt die GPUs in einem kleineren Cluster warten. Wer bei Storage unterinvestiert, lässt die GPUs verhungern. So oder so sitzt teures Silizium herum und beurteilt alle anderen.

Deshalb ist Kosten pro Petabyte allein zu grob. Die eigentliche Kennzahl sind Kosten pro nutzbarem Forschungsergebnis. Hält eine teurere Storage-Plattform Beschleuniger gefüttert, reduziert Ausfälle, vereinfacht den Betrieb und vermeidet die Einstellung einer kleinen Armee von Spezialisten, kann sie in der Praxis günstiger sein. Läuft eine günstigere Open-Source-Plattform gut und kann das Team sie sicher betreiben, könnte der Vendor-Aufpreis verschwendet sein. Falsch ist nur, den Kaufpreis zu optimieren und die operativen Kosten zu ignorieren.

Bei 120 PB wird jede Ineffizienz zu einem Posten. Jeder Ausfall wird teuer, jede Migration politisch, und jede unterdimensionierte Netzwerkverbindung zu einem Engpass mit Namen und angehängtem Meeting. Das Budget muss also Kapazität kaufen, vor allem aber Vertrauen.

Es gibt vielleicht nicht die eine Plattform, die alles beherrscht

Der Thread behandelt „beste Storage“ naturgemäß als eine einzige Antwort, aber die eigentliche Architektur ist womöglich geschichtet. HPC/KI-Umgebungen haben oft unterschiedliche Storage-Persönlichkeiten: heiße Trainingsdaten, Scratch-Space, Checkpoint-Storage, langfristige Forschungsdatensätze, governance-kontrollierte Enterprise-Daten, Archiv, Backup und Replikation. Ein Produkt ist möglicherweise nicht ideal für alle davon.

DDN- oder Lustre-artige Systeme können für performancelastige parallele Workloads sinnvoll sein. NetApp kann für governance-gesteuertes Enterprise-NAS oder Forschungsdaten mit hohem Sicherheits- und Policy-Bedarf sinnvoll sein. Objektspeicher könnte zu manchen Pipelines passen. Tape oder Kaltarchiv könnte für die langfristige Aufbewahrung weiterhin relevant sein. VAST könnte zu bestimmten hochperformanten unstrukturierten Anwendungsfällen passen. 3FS könnte einen Labortest verdienen, wenn KI-spezifische Workloads zu seinen Stärken passen.

Zu versuchen, jeden Workload in eine Plattform zu zwängen, kann die Beschaffung vereinfachen und dabei das Leben verkomplizieren. Plattformen aufzuteilen kann die Passgenauigkeit verbessern und dabei Datenbewegungs- und Managementschmerz erzeugen. Es gibt kein Free Lunch, nur unterschiedliche Speisekarten des Bedauerns.

Der Schlüssel ist Datenklassifizierung. Was muss schnell sein? Was muss governance-gesteuert sein? Was muss günstig sein? Was muss aufbewahrt werden? Was muss global geteilt werden? Was kann regeneriert werden? Was ist unersetzlich? Welche Zugriffsmuster existieren heute, und welche werden wahrscheinlich auftauchen, sobald Nutzer entdecken, dass das System schneller ist? Die Storage-Architektur sollte dem Datenverhalten folgen und nicht den Vendor-Slogans.

Die vernünftige Antwort ist unbequem: Expertise kaufen, bevor man Petabyte kauft

Für ein 120-PB-HPC/KI-Projekt ist die verantwortungsvollste Empfehlung eine organisatorische: die Organisation braucht unabhängige Expertise, bevor sie sich festlegt. Stellen Sie Menschen ein oder beauftragen Sie sie, die Storage in dieser Größenordnung betrieben haben. Gemeint sind Leute, die mit ausgefallenen OSTs, Metadaten-Engpässen, Client-Stürmen, Vendor-Eskalationen, schlechter Firmware und teuren Systemen zu tun hatten, die sich unter echten Nutzern schlecht verhalten, und nicht Leute, die große Zahlen auf Folien gesehen haben.

Die Organisation sollte einen strukturierten Bake-off durchführen, aber auch einen Personal-Bake-off. Wer wird das betreiben? Wer wird es tunen? Wer wird es patchen? Wer wird Nutzerbeschwerden übernehmen? Wer wird erkennen, wann Performance-Probleme Storage-, Netzwerk-, Scheduler-, GPU-, Anwendungs- oder Dateisystem-Verhalten sind? Wer wird die Kapazitätsplanung managen? Wer wird die Architektur gegenüber dem Finanzbereich verteidigen? Wer wird den Exit-Pfad entwerfen? Solange diese Antworten vage bleiben, ist die Technologieentscheidung verfrüht.

Ein 30-Millionen-Pfund-Storage-Programm kann nicht allein durch Vendor-Empfehlungen gesteuert werden, selbst wenn sie von NVIDIA kommen. Es kann auch nicht allein durch Forum-Horrorgeschichten gesteuert werden, selbst wenn sie erschreckend klingen. Es braucht Workload-Nachweise, Referenzkunden, operatives Design, Finanzmodellierung und eine klare Entscheidung, ob das Team ein Produkt will oder eine Plattform, die es effektiv mitbesitzt.

Die endgültige Entscheidung hängt davon ab, welcher Schmerz sich überlebbar anfühlt

DDN könnte immer noch die richtige Antwort sein, wenn der Workload klassisches HPC/KI ist, die Referenzen stark sind, der Supportvertrag Biss hat und der Proof of Concept unter unschönen Bedingungen echte Performance zeigt. Die Horrorgeschichten bedeuten, dass das Support-Modell intensiv geprüft werden muss, und nicht, dass man DDN automatisch verwirft.

Open-Source-Lustre könnte die richtige Antwort sein, wenn die Organisation das Talent und den Appetit hat, es ernsthaft zu betreiben. Die Ersparnisse sind nur real, wenn das operative Modell real ist. DeepSeeks 3FS könnte einen Test wert sein, besonders für KI-spezifische Workflows, sollte sich Produktionsvertrauen aber langsam verdienen.

NetApp könnte für governance-gesteuerte Enterprise-Daten und manche Scale-out-Bedürfnisse exzellent sein, aber jede Behauptung rund um 120-PB-HPC/KI-Performance muss brutal bewiesen und nicht aus Markenreife angenommen werden. VAST und andere neuere Architekturen könnten einen Blick verdienen, wobei Vendor-Überlebensfähigkeit, Support und Exit-Kosten genauso viel Aufmerksamkeit brauchen wie Benchmark-Zahlen.

120 PB kümmern sich um niemandes Lieblings-Vendor, um keine Open-Source-Ideologie, um keine Markentreue, keine Startup-Energie und nicht darum, wer 2021 eine schlechte Support-Erfahrung hatte. Sie kümmern sich um Failure Domains, Metadaten, Durchsatz, Latenz, Rebuilds, Menschen, Strom, Netzwerk und darum, ob die Plattform noch Sinn ergibt, wenn alle erschöpft sind. Wer in dieser Größenordnung fragt, welchen Storage er kaufen soll, entscheidet deshalb vor allem, mit welchem Storage-Ausfallmodus die Organisation leben will.