Wie können Hot- und Cold-Data-Tiering die Speicherkosten senken und dabei eine akzeptable Anwendungsperformance erhalten?

Hot- und Cold-Data-Tiering senkt die Speicherkosten, indem häufig genutzte oder performancekritische Daten auf schnellerem Speicher bleiben und selten genutzte Daten auf günstigere Kapazität verschoben werden, sofern der Workload das zulässt. Damit die Anwendungsperformance erhalten bleibt, sollte sich die Tiering-Richtlinie am Zugriffsverhalten orientieren und nach jeder Datenverschiebung anhand von Speicherdurchsatz, IOPS, Latenz und Workload-Auswirkung überprüft werden.

Das Quellmaterial unterstützt die Überwachung von Speicherkapazität und -performance und beschreibt die automatisierte Datenverschiebung zwischen Storage-Tiers auf Basis von Nutzungsmustern. Einen universellen Schwellenwert für Hot-Daten, ein universelles Alter für Cold-Daten oder ein universelles Kostenverhältnis definiert es nicht. Diese Regeln müssen für das jeweilige Speichersystem und den jeweiligen Workload festgelegt werden.

Was sind Hot-Daten?

Hot-Daten sind Daten, die unter dem aktuellen Workload schnellen oder häufigen Zugriff benötigen. Dazu können aktive Trainingsdatensätze, häufig geladene Modelldateien, aktuelle Anwendungsdatenbanken, aktuelle Checkpoints und Dateien gehören, die Produktionsdienste wiederholt nutzen.

Die genaue Definition sollte operativ sein. Eine Datei ist hot, wenn ihr Zugriffsmuster oder ihre Serviceanforderung es rechtfertigt, sie auf einem leistungsstärkeren Tier zu halten, und nicht schon deshalb, weil sie neu ist. Ein großes neues Archiv kann fast sofort cold sein, während eine ältere Modelldatei, die bei jedem Inference-Deployment verwendet wird, monatelang hot bleiben kann.

Das Quellmaterial unterstützt deshalb die Überwachung des Speicherpfads, statt Daten nur nach Alter zu klassifizieren.

Was sind Cold-Daten?

Cold-Daten sind Daten, auf die so selten zugegriffen wird, dass sie auf einem kostengünstigeren Tier liegen können, ohne das erforderliche Service-Level zu verletzen. Beispiele sind ältere Checkpoints, die für die routinemäßige Wiederherstellung nicht mehr genutzt werden, historische Trainingsdatensätze, archivierte Logs, abgelöste Modellversionen, die zu Audit-Zwecken aufbewahrt werden, und langfristige Projektdaten.

Cold heißt meist nur, dass die Zugriffsanforderung niedriger ist. Wertlos sind die Daten deshalb nicht: Sie müssen möglicherweise trotzdem durchsuchbar, wiederherstellbar, aufbewahrt oder geschützt bleiben. Eine Tiering-Strategie sollte darum neben dem Speicherpreis auch Abrufzeit und operative Bedeutung berücksichtigen.

Warum kann Tiering die Speicherkosten senken?

Unterschiedliche Storage-Tiers können für unterschiedliche Kombinationen aus Performance, Kapazität und Kosten optimiert sein. Liegt jedes Byte auf dem leistungsstärksten Speicher, zahlt die Organisation möglicherweise einen Aufpreis für Daten, die diese Performance nur selten brauchen.

Tiering ändert die Zuteilung: Hochwertige Performance-Kapazität bleibt den Workloads vorbehalten, die sie benötigen, und selten genutzte Daten wandern auf ein kapazitätsorientiertes Tier. Das Quellmaterial unterstützt dieses Betriebskonzept, indem es die Datenverschiebung zwischen Storage-Tiers auf Basis von Nutzungsmustern als Fähigkeit zur Ressourcenoptimierung beschreibt. Es unterstützt außerdem die Speicherüberwachung über Kapazität und Performance hinweg, die man braucht, um zu prüfen, ob die Verschiebung tatsächlich hilft.

Einen festen Einsparungsprozentsatz gibt die Quelle nicht vor. Die tatsächlichen Einsparungen hängen von den Speicherplattformen, der Preisgestaltung, dem Datenprofil und der Aufbewahrungsrichtlinie ab.

Warum kann schlecht gestaltetes Tiering die Performance beeinträchtigen?

Tiering kann der Performance schaden, wenn Daten vom schnellen Tier verschoben werden, obwohl die Anwendung weiterhin schnellen Zugriff braucht. Ein Trainingsjob benötigt vielleicht plötzlich einen älteren Datensatz, oder ein Wiederherstellungsprozess sucht einen Checkpoint, der bereits verschoben wurde. Eine Anwendung kann auch ein monatliches Muster haben, das den größten Teil des Monats cold wirkt und während eines Reporting-Zyklus hot wird.

Hat das niedrigere Tier höhere Latenz oder geringeren Durchsatz, muss der Workload möglicherweise auf die Daten warten. Bei KI-Infrastruktur kann sich dieses Warten als geringere GPU-Auslastung zeigen, obwohl der Beschleuniger gesund ist und nur der Datenpfad langsam ist. Deshalb behandelt der Artikel darüber, warum die GPU-Auslastung niedrig sein kann, Speicher als möglichen Engpass, statt vorschnell die GPU für das Problem zu halten.

Welche Speichermetriken sollten vor dem Tiering überwacht werden?

Überwachen Sie Metriken, die sowohl Kapazität als auch Performance beschreiben. Das Speichermodell der Quelle umfasst Kapazität, Durchsatz, IOPS und Latenz, und diese vier Dimensionen sind ein solides Minimum.

Die Kapazität zeigt, ob auf dem Tier noch Platz ist, und der Durchsatz, wie viele Daten sich über die Zeit bewegen lassen. IOPS zählt bei Workloads, die viele Operationen auslösen, und die Latenz zeigt, wie lange Anfragen dauern.

Ob das Ziel-Tier genug freie Terabyte hat, reicht als Frage nicht aus. Entscheidend ist, ob es das Zugriffsmuster der zu verschiebenden Daten tragen kann. Eine Tiering-Richtlinie, die sich nur an der Kapazität orientiert, kann ein Performance-Problem erzeugen.

Welche Zugriffsdaten sollten das Tiering beeinflussen?

Nutzen Sie das tatsächliche Zugriffsverhalten, wo Speicher- und Anwendungsumgebung es liefern können. Nützliche Signale sind etwa der letzte Zugriffszeitpunkt, die Zugriffshäufigkeit, Lese- und Schreibvolumen, jüngste Projektaktivität, die Bindung an einen Workload, Aufbewahrungsanforderungen und die Bedeutung eines Checkpoints.

Die Quelle unterstützt ausdrücklich Tiering auf Basis von Nutzungsmustern, definiert aber nicht den genauen Klassifizierungsalgorithmus. Ein Unternehmen kann also die Signale nutzen, die es zuverlässig messen kann. Bauen Sie keine Richtlinie auf Metadaten auf, denen Sie im eingesetzten Speichersystem nicht trauen.

Die Klassifizierung sollte nachvollziehbar bleiben: Ein Betreiber sollte erklären können, warum ein Datensatz verschoben wurde und ein anderer geblieben ist.

Sollte allein das Alter entscheiden, ob Daten cold sind?

Nein. Das Alter ist nützlich, stuft aber allein wichtige Daten leicht falsch ein. Ein sechs Monate altes Modell kann immer noch täglich aufgerufen werden, während ein einwöchiges Experiment vielleicht nie wieder verwendet wird. Das Zugriffsmuster sagt deshalb mehr als das Erstellungsdatum, und der nutzungsmusterbasierte Ansatz der Quelle stützt diese Sicht.

Das Alter kann trotzdem eine Regel unter mehreren sein, zum Beispiel zusammen mit diesen Bedingungen: keine Lesezugriffe innerhalb eines definierten Zeitraums, keine aktive Projektabhängigkeit, keine aktuelle Wiederherstellungsabhängigkeit und kein SLO, das schnellen Zugriff verlangt.

Den genauen Zeitraum legt das Unternehmen fest. Die Quelle schreibt weder 30 Tage noch 90 Tage noch eine andere universelle Zahl vor.

Wie sollten KI-Trainingsdaten getiert werden?

Trainingsdaten sollten danach getiert werden, wie nah sie am aktiven Training liegen und wie schnell sie eventuell wieder verfügbar sein müssen. Ein praxistaugliches Betriebsmodell kann den aktiven Datensatz, den laufende Jobs nutzen, den vorbereiteten Datensatz, der voraussichtlich bald gebraucht wird, und den historischen Datensatz, der zur Wiederverwendung oder für Audits aufbewahrt wird, unterscheiden.

Aktive Daten brauchen Speicherperformance, die zur Trainings-Pipeline passt. Historische Daten können auf ein niedrigeres Tier wandern, sofern die Abrufzeit akzeptabel ist.

Die wichtigste Kontrolle besteht darin, den Datensatz mit der Trainingsaufgabe und dem Projekt zu verknüpfen. Referenziert ein wartender oder geplanter Job den Datensatz noch, kann eine Verschiebung auf ein langsameres Tier eine vermeidbare Verzögerung verursachen. Die Datenbasis und die Aufgabenbeziehungen der Quelle liefern die Zuordnungsdaten, die diese Entscheidung braucht.

Wie sollten Modelldateien getiert werden?

Modellversionen haben unterschiedliche operative Bedeutung. Ein aktuelles Produktionsmodell ist hot. Eine Rollback-Version braucht möglicherweise ebenfalls schnellen Zugriff, auch wenn sie gerade keinen Traffic bedient, während eine alte Version, die nur für Audits aufbewahrt wird, kälter sein kann. Tiering sollte deshalb neben der Zugriffshäufigkeit auch den Lifecycle-Status berücksichtigen.

Das Modell-Repository der Quelle hält Version und operativen Status für Modelle fest. Damit lassen sich Produktion, Rollback-Kandidat, Evaluierung und Archiv auseinanderhalten, und die Speicherrichtlinie kann den Modell-Lifecycle als einen Eingabewert nutzen.

Eine Tiering-Regel für Modelldateien gibt die Quelle nicht vor, die genaue Richtlinie bleibt also eine Design-Entscheidung des Unternehmens.

Wie sollten Checkpoints getiert werden?

Checkpoint-Tiering sollte die Wiederherstellungsziele schützen. Ein aktueller Checkpoint für einen laufenden, mehrtägigen Trainingsjob kann operativ kritisch sein, und eine Verschiebung auf ein langsames Tier kann die Wiederherstellungszeit nach einem GPU- oder Node-Ausfall verlängern. Ältere Checkpoints können für kälteren Speicher infrage kommen, sobald der Job fortgeschritten ist und die Wiederherstellungsrichtlinie nicht mehr von ihnen abhängt.

Das Trainings-Recovery-Modell der Quelle nutzt Checkpoints, damit Jobs nicht von vorn beginnen müssen. Die Checkpoint-Speicherung gehört damit zur Zuverlässigkeit. Für den Recovery-Workflow erklärt der Artikel darüber, wie KI-Infrastruktur Trainingsjobs nach einem GPU- oder Server-Ausfall automatisch wiederherstellen kann, warum die Verfügbarkeit von Checkpoints verlorene Rechenzeit und Wiederherstellungszeit beeinflusst.

Wie sollte automatisches Tiering kontrolliert werden?

Automatisches Tiering sollte eine definierte Richtlinie verwenden und, wo das System es unterstützt, einen Audit-Trail der Verschiebungen führen. Die Richtlinie sollte klären, welche Daten infrage kommen und welche auf dem schnellen Tier bleiben müssen, welche Anhaltspunkte Daten cold machen und wann sie auf das Hot-Tier zurückkehren können. Außerdem sollte sie festlegen, welche Performance nach dem Abruf erforderlich ist und wie die Verschiebung überprüft wird.

Automatisierung sollte Verschiebungen nicht unsichtbar machen. Steigt die Anwendungslatenz, nachdem ein Datensatz verschoben wurde, müssen Betreiber wissen, dass sich die Speicherplatzierung geändert hat, denn bei der Fehlersuche ist genau das ein nützlicher Anhaltspunkt.

Wie sollte der Abruf aus dem Cold-Tier funktionieren?

Der Abruf sollte um die Wartezeit herum gestaltet werden, die für die Anwendung akzeptabel ist. Mancher Cold-Speicher kann Daten direkt liefern, allerdings mit geringerer Performance, andere Designs verschieben die Daten zuerst zurück auf ein Hot-Tier.

Die Quelle legt den Abrufmechanismus nicht fest, das Unternehmen muss also das Verhalten seiner tatsächlichen Speicherplattform dokumentieren. Im Betrieb überwachen Sie Abrufzeit, Leselatenz, Durchsatz nach dem Abruf, Wartezeit der Anwendung und Fehlerrate.

Kann ein Workload die Abrufverzögerung nicht tolerieren, hätten die Daten für diesen Service nicht als cold eingestuft werden dürfen.

Wie können Speicherquoten das Tiering unterstützen?

Das Speichermodell der Quelle umfasst Quota-Verwaltung. Quoten können helfen zu steuern, wie viel hochwertigen Speicher ein Mandant oder ein Projekt verbraucht. Ein Projekt kann etwa eine Kapazitätsquote für das schnelle Tier, eine allgemeine Speicherkapazität und eine Bandbreiten- oder Performance-Richtlinie haben. Die genauen Quota-Dimensionen hängen von der Plattform ab.

Tiering und Quoten lösen unterschiedliche Probleme: Die Quote begrenzt den Verbrauch, Tiering optimiert die Platzierung. Zusammen können sie verhindern, dass ein einzelnes Projekt das Premium-Tier mit selten genutzten Daten füllt.

Wie sollte Business-Kritikalität das Tiering beeinflussen?

Business-Kritikalität sollte die reine Kostenoptimierung überstimmen, wenn die Servicekontinuität es verlangt. Ein selten genutzter Recovery-Datensatz braucht bei einem strengen Wiederherstellungsziel möglicherweise trotzdem schnellere Verfügbarkeit. Auf ein Rollback-Modell wird vielleicht nur im Fehlerfall zugegriffen, aber genau dann muss es da sein.

Storage-Tiering sollte deshalb mit Anwendungs- und Servicebeziehungen verknüpft sein. Das Business-Topologie-Modell der Quelle kann erkennen, was eine Speicherressource unterstützt. Für die Mapping-Ebene erklärt der Artikel darüber, wie Organisationen Geschäftsanwendungen mit Servern, Containern, Datenbanken, Netzwerkgeräten und Speicher verknüpfen können, wie sich Speicherabhängigkeiten mit Services verbinden lassen.

Wie erkennt man, ob Tiering tatsächlich Geld spart?

Messen Sie Speicherzuteilung und Performance, nachdem die Richtlinie angewendet wurde. Erfassen Sie die freigegebene Premium-Tier-Kapazität, die verbrauchte Kapazität auf dem niedrigeren Tier, die verschobenen Daten und das Abrufvolumen, dazu Anwendungslatenz, Speicherdurchsatz, IOPS, Performance-Vorfälle und die Speichernutzung pro Projekt.

Wenden Sie anschließend das Speicherkostenmodell der Organisation an. Die Quelle definiert keinen universellen Preis pro Speichereinheit, die Kosten sollten also aus der tatsächlichen Umgebung stammen.

Wichtig ist die Prüfung, dass die günstigere Platzierung nicht so viel Performance gekostet hat, dass Compute im Leerlauf wartet oder Serviceanforderungen verletzt werden.

Was sollte ein Tiering-Dashboard anzeigen?

Eine praxistaugliche Ansicht kann die Kapazität nach Storage-Tier, das Volumen von Hot- und Cold-Daten, die im Zeitraum verschobenen Daten und die Top-Projekte nach Premium-Tier-Nutzung. Dazu kommen Durchsatz, IOPS, Latenz, Abrufaktivität, Tiering-Ausnahmen und der zugehörige Workload oder Service.

Die Quelle unterstützt die Überwachung von Kapazität und Performance sowie die Ressourcenoptimierung über Storage-Tiers hinweg. Ein Plattformbeispiel, das den Speicherstatus mit dem breiteren Infrastrukturbetrieb verknüpfen kann, ist Sensaka.

Würde ich Tiering einführen, finge ich mit Daten an, die eindeutig inaktiv und leicht abrufbar sind, und würde die Wirkung messen, bevor ich die Richtlinie ausweite. Möglichst viele Terabyte auf günstigeren Speicher zu schieben, ist das falsche Ziel. Sinnvoll ist, weniger Premium-Speicher zu verbrauchen, ohne dass Anwendungen, Trainingsjobs oder Wiederherstellungsabläufe genau dann warten müssen, wenn es darauf ankommt.