5 Mit HPC-Daten-Tiering halten Zentren für wissenschaftliches Rechnen teuren Hochleistungsspeicher für laufende Jobs frei, während sie jahrelang Forschungsdaten auf bezahlbarer Kapazität aufbewahren. Universitäten, nationale Labore und Forschungsinstitute betreiben Cluster, die Daten mit enormer Geschwindigkeit lesen und schreiben – aus Simulationen, Genomik-Pipelines, Bildgebung und zunehmend aus KI-Training. Die parallelen Dateisysteme, die diese Cluster versorgen, sind pro Terabyte teuer und schnell voll. Ohne einen klaren Weg vom Scratch über den Projektspeicher bis ins Archiv drohen volle Dateisysteme, frustrierte Forschende und Daten, die entweder verloren gehen oder für immer auf der falschen Ebene liegen. Dieser Artikel erläutert die typischen Speicherebenen im wissenschaftlichen Rechnen, wie Daten zwischen ihnen wandern, die Rolle von Objektspeicher und die Richtlinien, mit denen Tiering funktioniert. Er richtet sich an Architekten für wissenschaftliches Rechnen und HPC-Speicher. Zur Governance von Forschungsdaten siehe Speicher für das Forschungsdatenmanagement. Die Ebenen in einem Zentrum für wissenschaftliches Rechnen Scratch Hochleistungsspeicher auf parallelen Dateisystemen, oft auf Flash, für Eingabe-, Ausgabe- und Zwischendateien aktiver Jobs. Scratch ist auf Durchsatz und Metadatenleistung optimiert. Dateien werden typischerweise nach einem festgelegten Zeitraum gelöscht, etwa nach 30 bis 90 Tagen ohne Zugriff, und nicht gesichert. Projekt- oder Arbeitsspeicher Gemeinsamer Speicher für aktive Forschungsgruppen mit Datensätzen, Code und Ergebnissen, die über einzelne Jobs hinaus bestehen. Er kann auf demselben parallelen Dateisystem wie Scratch liegen oder auf einer separaten Ebene mit größerer Kapazität und wird oft gesichert oder per Snapshot geschützt. Home-Verzeichnisse Kleiner, gesicherter Speicher für Benutzerkonfiguration, Skripte und kleine Dateien. Archiv- oder Kampagnenspeicher Speicher mit großer Kapazität für Daten, auf denen nicht mehr aktiv gerechnet wird, die aber Monate oder Jahre aufbewahrt werden müssen: Daten abgeschlossener Projekte, Gerätedaten im Rohformat, veröffentlichte Ergebnisse und Daten für die Reproduzierbarkeit. Objektspeicher und Band sind gängige Lösungen. Langzeitarchivierung Für Daten mit langfristigem Wert: Erhaltungskopien mit Fixity-Prüfungen an mehreren Standorten. Warum Tiering wichtig ist Kosten: Flash-basierte parallele Dateisysteme kosten pro Terabyte weit mehr als Objektspeicher oder Band. Leistung: Ein aufgeräumter Scratch erhält Metadaten- und Durchsatzleistung für laufende Jobs. Kapazität: Forschungsdaten wachsen schneller als die Budgets für Hochleistungsspeicher. Datensicherheit: Scratch wird nicht gesichert, daher müssen wertvolle Daten auf geschützte Ebenen wandern. Compliance: Förderer und Einrichtungen verlangen, dass Forschungsdaten aufbewahrt und verwaltet werden. Wie Daten zwischen den Ebenen wandern Manuelle Verlagerung Forschende kopieren Daten mit Tools wie rsync oder parallelen Kopierwerkzeugen. Das ist einfach, hängt aber davon ab, dass Benutzer daran denken, und führt oft dazu, dass Daten auf dem Scratch bleiben, bis sie gelöscht werden. Richtlinienbasiertes Tiering im Dateisystem Viele parallele Dateisysteme unterstützen Richtlinien, die Dateien nach Alter, Größe oder Zugriff in kostengünstigere Pools oder externe Ziele verschieben und einen Stub oder Namespace-Eintrag hinterlassen, sodass Benutzer die Datei weiterhin sehen. Hierarchisches Speichermanagement HSM-Systeme migrieren Dateiinhalte in eine Archivebene, oft Band oder Objektspeicher, und holen sie bei Zugriff zurück. Parallele Dateisysteme bieten häufig ein HSM-Framework, das Data-Mover-Agenten zum Verschieben der Dateien nutzt. Workflow-gesteuerte Verlagerung Pipelines stellen Daten vor den Jobs aus dem Archiv im Scratch bereit und schreiben die Ergebnisse danach zurück, mithilfe von Workflow-Managern oder Data Movern. Das ist bei Gerätedaten und KI-Training üblich. Die Rolle von Objektspeicher Objektspeicher ist zu einer zentralen Ebene im wissenschaftlichen Rechnen geworden: Kapazität zu geringeren Kosten als parallele Dateisysteme, skalierbar auf viele Petabytes durch Hinzufügen von Knoten. S3-Zugriff für moderne Tools, Workflow-Manager, Datenportale und KI-Frameworks. Langlebigkeit mit Erasure Coding und Replikation über mehrere Standorte. Online-Zugriff, deutlich schneller abrufbar als Band. Austausch, da sich Objekte über vorsignierte URLs oder Zugriffsrichtlinien mit Kooperationspartnern teilen lassen. Servicemodell, mit dem Zentren Forschenden direkt S3-Speicher anbieten können. Viele Zentren nutzen Objektspeicher heute als Kampagnen- und Archivebene, mit Band als tieferer oder sekundärer Kopie, wo eine sehr langfristige, kostengünstige Aufbewahrung nötig ist. Geräte- und KI-Daten Geräte wie Kryo-Elektronenmikroskope, Sequenzierer, Lichtblattmikroskope und Teleskope erzeugen kontinuierliche Datenströme, die vor der Verarbeitung zuverlässig abgelegt werden müssen. Viele Zentren nehmen Gerätedaten direkt in Objektspeicher oder ein Landing-Dateisystem auf und stellen sie dann zur Verarbeitung im Scratch bereit. KI-Training bringt große Datensätze hinzu, die wiederholt gelesen und oft aus dem Objektspeicher auf schnellen Speicher nahe den GPUs gebracht werden. Richtlinien, mit denen Tiering funktioniert Löschrichtlinien für Scratch, klar kommuniziert, mit Warnungen vor dem Löschen. Projektkontingente, die zum Verlagern inaktiver Daten ins Archiv anregen. Archivzuteilungen pro Projekt, kostenpflichtig oder kostenlos, mit klaren Aufbewahrungsbedingungen. Automatisierung, die Daten nach Alter oder Projektstatus verlagert. Anforderungen an Metadaten, damit archivierte Daten später auffindbar sind. Prozesse zum Projektende, um zu entscheiden, was aufbewahrt, veröffentlicht oder gelöscht wird. Ein typischer Datenweg Verfolgen wir einen einzelnen Datensatz durch ein Zentrum. Eine Forschungsgruppe führt eine Klimasimulation aus, die über eine Woche 200 TB Ausgabe in den Scratch schreibt. Nachbearbeitungsjobs reduzieren sie auf 20 TB analysefertige Dateien im Projektspeicher, während die Rohausgabe mit Projektmetadaten in das Objektspeicher-Archiv kopiert und die Scratch-Kopie gelöscht wird. In den folgenden Monaten fragen die Forschenden die Analysedateien ab und holen gelegentlich Teile der Rohausgabe für neue Analysen zurück in den Scratch. Wird ein Paper veröffentlicht, werden die zugrunde liegenden Daten im institutionellen Repository registriert, und die Archivkopie bedient die Downloads. Zum Projektende entscheidet die Gruppe, welche Rohausgaben gemäß den Aufbewahrungsvorgaben des Förderers aufbewahrt werden; der Rest wird planmäßig gelöscht. Bei jedem Schritt liegen die Daten auf der Ebene, die zu ihrer Nutzung passt. Die Wirksamkeit des Tierings messen Nützliche Kennzahlen sind die Auslastung des Scratch und der Anteil der Dateien, die länger als 30 Tage unberührt sind, das Wachstum des Projektspeichers nach Gruppe, Aufnahme- und Rückholvolumen des Archivs, die Zeit bis zur Rückholung von Daten aus dem Archiv und die Zahl der Support-Tickets zu verlorenen oder gelöschten Daten. Wer diese Werte über die Zeit verfolgt, sieht, ob Richtlinien und Automatisierung wirken oder ob Forschende mehr Unterstützung beim Verlagern von Daten brauchen. Die Ebenen dimensionieren Scratch: ausgelegt auf die Arbeitsbestände und den Durchsatz aktiver Jobs, nicht auf die Gesamtdaten. Projekt: ausgelegt auf die aktiven Datensätze aller Gruppen. Archiv: ausgelegt auf die über die Aufbewahrungsfristen angesammelten Daten zuzüglich Wachstum – meist mit Abstand die größte Ebene. Netzwerk: ausgelegt auf die Bewegung zwischen den Ebenen, insbesondere das Bereitstellen von Daten in den und aus dem Scratch. Regionale Aspekte und Förderung Wissenschaftliches Rechnen in Europa, im Vereinigten Königreich, in den USA und in Asien unterliegt unterschiedlichen Fördermodellen und Datenrichtlinien. Nationale und regionale Zentren in Europa bedienen oft viele Einrichtungen und müssen Daten für manche Projekte innerhalb nationaler oder EU-Grenzen halten. Förderer wie Horizon Europe, die britischen Research Councils und US-Behörden verlangen Datenmanagementpläne, die Aufbewahrung und Austausch beeinflussen. Archivebenen müssen diese Pflichten unterstützen, wo nötig auch beim Speicherort. Checkliste: HPC-Daten-Tiering Scratch-, Projekt-, Home-, Archiv- und Langzeitebenen samt ihrem Zweck definieren. Löschrichtlinien für Scratch und Projektkontingente festlegen. Objektspeicher als skalierbare Archiv- und Kampagnenebene nutzen. Verlagerung mit Dateisystem-Richtlinien, HSM oder Workflows automatisieren. Aufnahme und Bereitstellung von Geräte- und KI-Daten planen. Forschenden wo sinnvoll S3-Zugriff bereitstellen. Metadaten für archivierte Daten verlangen. Archivkapazität für Ansammlung und Wachstum dimensionieren. Netzwerke für die Bereitstellung zwischen den Ebenen dimensionieren. Aufbewahrung und Speicherort an den Vorgaben der Förderer ausrichten. Zusammenfassung HPC-Daten-Tiering hält Hochleistungsspeicher schnell und bezahlbar, indem es Daten zur richtigen Zeit auf die richtige Ebene verlagert. Scratch bedient laufende Jobs, der Projektspeicher hält aktive Arbeit, und Objektspeicher bietet ein skalierbares Online-Archiv für alles, was aufbewahrt werden muss, mit Band oder Erhaltungskopien wo nötig. Klare Richtlinien, Automatisierung und S3-Zugriff machen Tiering zum Teil des Forschungsalltags statt zu einem nachträglichen Gedanken und halten Forschungsdaten sicher – lange nachdem die erzeugenden Jobs beendet sind. Häufig gestellte Fragen Was ist Scratch-Speicher im HPC? Hochleistungsspeicher für die Daten aktiver Jobs, typischerweise auf einem parallelen Dateisystem, der nach einem festgelegten Zeitraum geleert und nicht gesichert wird. Wohin sollten HPC-Daten nach Projektende gehen? In eine Archivebene, oft Objektspeicher, mit Metadaten und einer Aufbewahrung, die den Vorgaben der Einrichtung und der Förderer entspricht. Kann Objektspeicher Band für HPC-Archive ersetzen? Für das primäre Archiv oft ja, da er online und schneller abrufbar ist. Viele Zentren behalten Band als tiefere oder sekundäre Kopie. Wie gelangen Daten von parallelen Dateisystemen in den Objektspeicher? Über manuelle Kopien, Tiering-Richtlinien des Dateisystems, HSM oder Workflow-gesteuerte Bereitstellung. Warum nicht alles auf dem parallelen Dateisystem behalten? Es ist pro Terabyte teuer, und Unordnung verschlechtert die Leistung für laufende Jobs. Weiterführende Lektüre Tiering paralleler Dateisysteme auf Objektspeicher Speicher für Gerätedaten S3-Speicherdienste an Universitäten Speicher für das Forschungsdatenmanagement
