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. Das ist 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. Ein physischer Footprint. Ein Supportvertrag. Ein Beschaffungskrieg. Eine Drei-Jahres-Wette mit rund 30 Millionen Pfund im Rücken. Und wenn es schiefgeht, wird es keine kleine Migration sein. Es wird ein karriereprägender Vorfall mit Racks sein.
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“ jedoch vom Betrieb bei lebendigem Leib gefressen. Die eigentliche Entscheidung ist nicht Produkt gegen Produkt. Sie ist, 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 ist nicht mehr die Storage-Plattform das Produkt — sondern die Organisation
Die wichtigste Zahl in der gesamten Diskussion ist nicht 120 PB. Es sind drei Jahre. Dieser Zeitrahmen verändert die Textur der Entscheidung. Jeder kann eine großartige Architektur auf ein Whiteboard zeichnen. Weniger Teams können diese Architektur 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, denen es nur wichtig ist, dass ihre Jobs schneller fertig werden, gesund halten.
In dieser Größenordnung hört Storage auf, eine Box zu sein. Es 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.
Die unbequeme Frage ist nicht, ob Lustre funktioniert. Es funktioniert. Die Frage 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. Sie sind kein Laborergebnis. Aber Storage-Käufer ignorieren solche Geschichten auf eigene Gefahr, weil Support-Erfahrung Teil des Produkts ist.
Bei 120 PB kauft niemand reine Technologie. Man kauft Eskalationspfade. Man kauft Ersatzteil-Logistik. Man kauft Feldexpertise. Man kauft das Vertrauen, dass der Vendor nicht zu einem weiteren System wird, das debuggt werden muss, wenn Freitagnacht etwas Seltsames passiert.
Die faire Version ist: Jeder große Storage-Vendor hat Horrorgeschichten. NetApp hat sie. Dell hat sie. IBM hat sie. Pure hat sie. VAST hat sie. Open-Source-Deployments haben sie definitiv auch. Aber DDNs Risiko in diesem Thread war nicht allein technische Skepsis. Es war 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 zählt. Governance zählt. Sicherheit zählt. Operative Politur zählt. Nicht alles sollte ein Wettlauf nach unten sein, wenn die Daten wertvoll sind.
Aber 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. Vendor-Reife und Produktreife sind nicht dasselbe. 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. Es könnte sogar die richtige Option für bestimmte Teile eines 120-PB-Bestands sein. Aber für HPC/KI-Scratch, Trainingsdaten und parallelen Zugriff in dieser Größenordnung reicht „NetApp ist Enterprise“ 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. Data Gravity ist keine Metapher mehr; es ist eine 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. Die Frage ist nicht, ob neuere Vendoren automatisch leichtsinnig sind. Die Frage ist, ob sie Support, Roadmap, Wirtschaftlichkeit und Ausfallverhalten in der erforderlichen Größenordnung nachweisen können.
Für eine 120-PB-Forschungsumgebung ist die sicherste Antwort vielleicht nicht der älteste Vendor oder die neueste Architektur. Es könnte diejenige 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, nicht einen 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 Argument gegen 3FS. Es ist ein Argument dagegen, produktive Forschungsdaten wie ein Wissenschaftsprojekt zu behandeln, es sei denn, die Organisation will explizit Teil dieses Wissenschaftsprojekts werden.
Open-Source- und aufstrebende Systeme funktionieren am besten, wenn das Team genug interne Engineering-Stärke hat, um ein echter Teilnehmer zu sein, nicht nur ein 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.
Die billigste Software kann zum teuersten System werden, wenn 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 nicht nur „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 ist kein Ordnerproblem. Ein Performance-Engpass ist nicht ein wütender Nutzer. 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. 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 Feind.
Jede Design-Entscheidung wird schwerer.
Die eigentliche Schlacht ist Support gegen Kontrolle
Der nützlichste Weg, die Entscheidung zu rahmen, ist nicht DDN gegen Lustre gegen 3FS gegen NetApp gegen VAST. Es ist Support gegen Kontrolle.
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. Sie besitzen die Integration. Sie besitzen die seltsamen Bugs. Sie besitzen das Performance-Tuning. Sie besitzen die Konsequenzen einer Unterbesetzung.
Kein Modell ist automatisch klüger. 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.
Die günstige Lösung kann besser sein, wenn das Team sie tatsächlich betreiben kann.
Die Katastrophe ist, günstig zu kaufen, aber 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. 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 muss gemein sein.
Testen Sie den echten Workload. Testen Sie GPU-Hunger. Testen Sie metadatenlastige Verzeichnisse. Testen Sie Checkpoint-Stürme. Testen Sie gemischten Lese-/Schreibdruck. Testen Sie Client-Ausfälle. Testen Sie Rack-Verlust. Testen Sie Netzwerküberlastung. Testen Sie Rebuilds, während Nutzer weiter Jobs laufen lassen. Testen Sie Software-Updates. Testen Sie Quota-Verhalten. Testen Sie Snapshots oder Datenschutz, falls erforderlich. Testen Sie Audit und Governance. Testen Sie Restore. 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. Fragen Sie, was Kunden hassen. Fragen Sie, 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. Fragen Sie, wie Datenmobilität aussieht, falls die Plattform ersetzt werden muss. Fragen Sie, wie lange eine vollständige Migration wirklich dauern würde.
Ein ernsthafter Vendor sollte harte Fragen überstehen.
Ein schwacher Vendor wird sich in Architekturdiagramme zurückziehen.
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.
Der einzige falsche Schritt ist, 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 wird politisch. Jede unterdimensionierte Netzwerkverbindung wird zu einem Engpass mit Namen und angehängtem Meeting.
Das Budget muss Kapazität kaufen, ja.
Aber mehr noch muss es Vertrauen kaufen.
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?
Storage-Architektur sollte dem Datenverhalten folgen, nicht Vendor-Slogans.
Die vernünftige Antwort ist unbequem: Expertise kaufen, bevor man Petabyte kauft
Die verantwortungsvollste Empfehlung für ein 120-PB-HPC/KI-Projekt lautet nicht „DDN wählen“ oder „NetApp wählen“ oder „Lustre bauen“. Es geht darum sicherzustellen, dass die Organisation unabhängige Expertise hat, bevor sie sich festlegt. Stellen Sie Menschen ein oder beauftragen Sie sie, die Storage in dieser Größenordnung betrieben haben. Nicht Menschen, die große Zahlen auf Folien gesehen haben. Menschen, 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.
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?
Wenn 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, nicht automatisch verworfen werden sollte.
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 aber Produktionsvertrauen 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 werden, nicht aus Markenreife angenommen.
VAST und andere neuere Architekturen könnten einen Blick verdienen, aber Vendor-Überlebensfähigkeit, Support und Exit-Kosten brauchen genauso viel Aufmerksamkeit wie Benchmark-Zahlen.
Die harte Wahrheit ist: 120 PB kümmern sich um niemandes Lieblings-Vendor. Sie kümmern sich nicht um Open-Source-Ideologie. Sie kümmern sich nicht um Markentreue, Startup-Energie oder wer 2021 eine schlechte Support-Erfahrung hatte. Sie kümmern sich um Failure Domains, Metadaten, Durchsatz, Latenz, Rebuilds, Menschen, Strom, Netzwerk und ob die Plattform noch Sinn ergibt, wenn alle erschöpft sind.
In dieser Größenordnung lautet die Frage nicht „Welchen Storage sollen wir kaufen?“
Sie lautet: „Mit welchem Storage-Ausfallmodus wollen wir leben?“
Das ist die Wahl, die sich in jedem Petabyte versteckt.