10 Das Tiering paralleler Dateisysteme auf Objektspeicher ermöglicht es Zentren für wissenschaftliches Rechnen, KI-Teams und Medienunternehmen, die Geschwindigkeit eines Hochleistungs-Dateisystems mit der Kapazität und Wirtschaftlichkeit von Objektspeicher zu verbinden. Parallele Dateisysteme versorgen Rechencluster mit sehr hohem Durchsatz und hoher Metadatenleistung, meist auf Flash. Objektspeicher fasst weit mehr Daten zu deutlich geringeren Kosten pro Terabyte. Tiering verbindet beide: Heiße Daten bleiben schnell, kalte Daten wandern in den Objektspeicher – oft ohne dass Benutzer ändern müssen, wie sie ihre Dateien finden. Dieser Artikel erläutert die wichtigsten Tiering-Modelle, ihr Verhalten beim Zurücklesen von Daten, die Bewertungskriterien sowie Dimensionierung und Betrieb einer gestuften Umgebung. Den übergreifenden Kontext bietet unsere Übersicht zum HPC-Daten-Tiering. Warum parallele Dateisysteme auf Objektspeicher auslagern Kosten: Flash-basierte parallele Dateisysteme sind pro Terabyte teuer; Objektspeicher auf hochkapazitiven Laufwerken ist weit günstiger. Kapazität: Forschungs- und KI-Datensätze wachsen schneller als die Flash-Budgets. Leistung: Wird die schnelle Ebene für aktive Daten reserviert, bleiben Durchsatz und Reaktionsfähigkeit der Metadaten erhalten. Langlebigkeit: Objektspeicher schützt Daten mit Erasure Coding über Knoten und Standorte hinweg. Zugänglichkeit: Auf Daten im Objektspeicher können andere Tools und Kooperationspartner über S3 zugreifen, nicht nur über das Dateisystem. Tiering-Modelle Natives Tiering im Dateisystem Einige moderne Hochleistungs-Dateisysteme lagern nativ auf S3-kompatiblen Objektspeicher aus. Die Metadaten bleiben auf der schnellen Ebene, während Dateidaten richtliniengesteuert, oft in großen Chunks, in den Objektspeicher verschoben werden. Lesezugriffe auf ausgelagerte Daten werden transparent aus dem Objektspeicher bedient, mitunter mit Prefetching. Für Benutzer ist dieses Modell am nahtlosesten, da sich der Namespace nie ändert. Policy Engine mit externen Pools Manche parallelen Dateisysteme enthalten Policy Engines, die Dateien nach Attributen wie Alter, Größe, Eigentümer oder Pfad auswählen und in externe Speicherpools verschieben, einschließlich Cloud- oder Objektspeicher-Zielen. Ein Stub oder Platzhalter bleibt im Dateisystem, und ein Zugriff löst eine Rückholung aus. Richtlinien können Daten auch vorab migrieren, damit die Rückholung schneller geht. Hierarchisches Speichermanagement HSM-Frameworks migrieren Dateiinhalte in ein Archiv und lassen die Metadaten der Datei im Namespace. Öffnet ein Benutzer eine freigegebene Datei, stellt das HSM sie aus dem Archiv wieder her. HSM-Frameworks paralleler Dateisysteme arbeiten typischerweise so und nutzen Data-Mover-Agenten, um Dateien in eine Archivebene zu verschieben, die S3-kompatibler Objektspeicher sein kann. Kopierbasierte Archivierung Statt transparent auszulagern, werden Daten mit Tools oder Workflows in den Objektspeicher kopiert und aus dem Dateisystem entfernt. Die Kopie im Objektspeicher wird zum maßgeblichen Datensatz. Das ist einfach und hält die Daten in ihrer nativen Form über S3 zugänglich, doch Benutzer müssen wissen, wo sie sie finden. Transparentes vs. natives Objektformat Eine wichtige Frage ist, wie die Daten im Objektspeicher aussehen: Vom Dateisystem verwaltetes Format: Manche Tiering-Ansätze speichern Daten in Chunks oder proprietären Layouts. Das ist für das Dateisystem effizient, über S3 aber nicht als normale Dateien lesbar. Eine Datei pro Objekt: Andere Ansätze speichern jede Datei als Objekt mit erkennbarem Namen, sodass andere Tools direkt über S3 auf die Daten zugreifen können. Native S3-Lesbarkeit ist wichtig, wenn der Objektspeicher als gemeinsame Datenplattform dienen soll – etwa für KI-Pipelines, Datenportale oder Zusammenarbeit – und nicht nur als Back-End des Dateisystems. Rückholverhalten Bei der Rückholung entscheidet sich, ob Tiering gelingt oder Benutzer frustriert: Latenz: Der erste Lesezugriff auf eine ausgelagerte Datei muss Daten aus dem Objektspeicher abrufen. Mit On-Premises-Objektspeicher geht das in der Regel schnell, große Dateien brauchen aber Zeit. Teilweise Rückholung: Manche Systeme holen nur den benötigten Teil einer großen Datei, was Workloads hilft, die Dateien teilweise lesen. Massenrückholung: Jobs, die Tausende ausgelagerter Dateien gleichzeitig lesen, können Rückholstürme auslösen. Werden die Daten vor dem Jobstart bereitgestellt, lassen sich Verlangsamungen vermeiden. Prefetching: Manche Systeme laden Daten vorab, wenn auf ein Verzeichnis zugegriffen oder ein Job eingeplant wird. Informieren Sie die Benutzer, welche Daten ausgelagert sind, und stellen Sie Tools bereit, um Daten vor großen Jobs bereitzustellen. Was der Objektspeicher leisten muss Hoher Durchsatz für Migrationen und Rückholungen, der mit der Kapazität skaliert. Leistung bei großen Objekten für Übertragungen in Chunks oder ganzer Dateien. Starke Konsistenz, damit zurückgeholte Daten immer aktuell sind. Skalierung auf Milliarden von Objekten, wenn eine Datei pro Objekt verwendet wird. Schutz über mehrere Standorte für archivierte Daten. Netzwerkaspekte Tiering bewegt große Volumen zwischen Dateisystem und Objektspeicher. Sorgen Sie für ausreichend Bandbreite zwischen den Dateisystem-Servern oder Data Movern und den Objektspeicherknoten, besonders für initiale Migrationen und Massenrückholungen. Objektspeicher im selben Rechenzentrum wie das parallele Dateisystem liefert meist die besten Ergebnisse. Richtlinien gestalten Typische Tiering-Richtlinien berücksichtigen: Alter: Dateien, auf die über einen festgelegten Zeitraum nicht zugegriffen wurde, wandern in den Objektspeicher. Größe: Große Dateien profitieren am meisten vom Tiering, da kleine Dateien wenig Kapazität einsparen und der Rückhol-Overhead überwiegt. Projektstatus: Daten abgeschlossener Projekte werden en bloc verlagert. Füllstandsgrenzen: Erreicht die schnelle Ebene einen Auslastungsschwellenwert, werden die ältesten Daten ausgelagert. Ausnahmen: Aktive Datensätze, Software und kleine Konfigurationsdateien bleiben auf der schnellen Ebene. Beginnen Sie konservativ, messen Sie die Rückholraten und passen Sie nach. Eine gestufte Umgebung dimensionieren Schnelle Ebene für aktive Arbeitsbestände, typischerweise ein Bruchteil der Gesamtdaten. Objektebene für die Gesamtdaten abzüglich der schnellen Ebene, zuzüglich Wachstum und Schutz-Overhead. Migrationsdurchsatz, ausgelegt darauf, mit den aus der schnellen Ebene alternden Daten Schritt zu halten. Rückholdurchsatz, ausgelegt auf die Spitzennachfrage der Jobs. Tiering für KI-Workloads KI-Training verändert die Annahmen beim Tiering. Trainingsdatensätze werden über viele Epochen wiederholt gelesen, oft in zufälliger Reihenfolge – sie während einer Trainingskampagne auszulagern führt daher zu ständigen Rückholungen. Besser ist es, den maßgeblichen Datensatz im Objektspeicher zu halten und die Arbeitskopie vor Trainingsbeginn auf die schnelle Ebene oder auf lokales NVMe der GPU-Server zu bringen und sie danach wieder freizugeben. Während des Trainings geschriebene Checkpoints können auf der schnellen Ebene landen und zur dauerhaften Sicherung in den Objektspeicher kopiert werden. Betrieb und Monitoring Überwachen Sie die Auslastung der schnellen Ebene, das täglich migrierte und zurückgeholte Datenvolumen, Rückhollatenz und -fehler, Kapazität und Durchsatz des Objektspeichers sowie die Zahl der Stub-Dateien im Namespace. Überprüfen Sie die Richtlinien regelmäßig anhand der Rückholstatistik: Häufige Rückholungen kürzlich ausgelagerter Daten deuten auf zu aggressive Richtlinien hin, eine sich ständig füllende schnelle Ebene auf zu zaghafte. Stimmen Sie Wartungsfenster beider Ebenen ab, damit Wartungsarbeiten am Objektspeicher keine Rückholungen während kritischer Jobs blockieren. Häufige Fallstricke Tiering kleiner Dateien, das riesige Objektzahlen bei geringem Kapazitätsgewinn erzeugt. Rückholstürme, wenn große Jobs ausgelagerte Daten ohne vorherige Bereitstellung lesen. Undurchsichtige Objektformate, die Daten an das Dateisystem binden. Unzureichende Netzwerkbandbreite zwischen den Ebenen. Verwirrung beim Backup, wenn Backup-Tools die Rückholung jeder ausgelagerten Datei auslösen. Unklare Kommunikation mit den Benutzern über das Verhalten ausgelagerter Daten. Regionale Besonderheiten Forschungszentren in Europa, im Vereinigten Königreich, in Japan und andernorts betreuen häufig Projekte mit Vorgaben zum Speicherort, etwa Gesundheits- oder sicherheitsrelevante Daten, die im Land bleiben müssen. Tiering auf On-Premises-Objektspeicher hält archivierte Daten lokal – anders als Tiering in die Public Cloud. Checkliste: Tiering paralleler Dateisysteme auf Objektspeicher Ein Tiering-Modell wählen: nativ, Policy Engine, HSM oder kopierbasiert. Entscheiden, ob Objekte über S3 als normale Dateien lesbar sein müssen. Richtlinien nach Alter, Größe, Projekt und Füllstandsgrenzen festlegen. Kleine Dateien und aktive Datensätze ausnehmen. Netzwerk und Objektspeicher für Migrations- und Rückholdurchsatz dimensionieren. Tools zur Bereitstellung anbieten, um Rückholstürme zu vermeiden. Tiering mit den Backup-Tools abstimmen. Daten im Objektspeicher über mehrere Standorte schützen. Das Tiering-Verhalten an die Benutzer kommunizieren. Zusammenfassung Das Tiering paralleler Dateisysteme auf Objektspeicher gibt Forschungs- und KI-Umgebungen schnellen Speicher dort, wo es darauf ankommt, und bezahlbare Kapazität für alles andere. Natives Tiering, Policy Engines und HSM funktionieren alle, mit unterschiedlichen Abwägungen bei Transparenz, Rückholverhalten und Datenformat. Wählen Sie einen Ansatz, der die Rückholung vorhersehbar hält, dimensionieren Sie Netzwerk und Objektspeicher für die realen Datenbewegungen und halten Sie die Daten nach Möglichkeit über S3 lesbar, damit der Objektspeicher als gemeinsame Plattform für Forschungsdaten dienen kann. Häufig gestellte Fragen Was ist Dateisystem-Tiering auf Objektspeicher? Die richtliniengesteuerte Verlagerung von Daten aus einem Hochleistungs-Dateisystem auf kostengünstigeren Objektspeicher, wobei sie über das Dateisystem oder über S3 zugänglich bleiben. Merken Benutzer, wenn Daten ausgelagert sind? Bei transparentem Tiering bleiben die Dateien sichtbar, der erste Lesezugriff auf ausgelagerte Daten kann während der Rückholung jedoch langsamer sein. Was ist ein Rückholsturm? Ein sprunghafter Anstieg von Rückholungen, wenn viele ausgelagerte Dateien gleichzeitig abgerufen werden, oft durch große Jobs, was das System verlangsamen kann. Sollten kleine Dateien ausgelagert werden? In der Regel nicht. Sie sparen wenig Kapazität und erzeugen viele Objekte und Rückhol-Overhead. Lässt sich direkt über S3 auf ausgelagerte Daten zugreifen? Nur wenn der Tiering-Ansatz Dateien als normale Objekte speichert. Manche speichern Daten in dateisystemspezifischen Formaten. Weiterführende Lektüre HPC-Daten-Tiering Speicher für Gerätedaten S3-Speicherdienste an Universitäten Tiered Storage für KI
