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. Um die Anwendungsperformance zu erhalten, sollte die Tiering-Richtlinie sich 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. Es definiert keinen universellen Schwellenwert für Hot-Daten, kein universelles Alter für Cold-Daten und kein universelles Kostenverhältnis — 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 gehören:

Aktive Trainingsdatensätze
Häufig geladene Modelldateien
Aktuelle Anwendungsdatenbanken
Aktuelle Checkpoints
Von Produktionsdiensten wiederholt genutzte Dateien

Die genaue Definition sollte operativ sein.

Eine Datei ist nicht hot, weil sie neu ist.

Sie ist hot, weil ihr Zugriffsmuster oder ihre Serviceanforderung es rechtfertigt, sie auf einem leistungsstärkeren Tier zu halten.

Diese Unterscheidung ist wichtig.

Ein großes neues Archiv kann fast sofort cold sein.

Eine ältere Modelldatei, die bei jedem Inference-Deployment verwendet wird, kann monatelang hot bleiben.

Das Quellmaterial unterstützt 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 gespeichert werden können, ohne das erforderliche Service-Level zu verletzen.

Beispiele können sein:

Ä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
Langfristige Projektdaten

Cold bedeutet nicht wertlos.

Es bedeutet meist, dass die Zugriffsanforderung niedriger ist.

Die Daten müssen möglicherweise trotzdem durchsuchbar, wiederherstellbar, aufbewahrt oder geschützt bleiben.

Deshalb sollte eine Tiering-Strategie Abrufzeit und operative Bedeutung berücksichtigen, nicht nur den Speicherpreis.

Warum kann Tiering die Speicherkosten senken?

Unterschiedliche Storage-Tiers können für unterschiedliche Kombinationen aus Performance, Kapazität und Kosten optimiert sein.

Wird jedes Byte auf dem leistungsstärksten Speicher gehalten, zahlt die Organisation möglicherweise einen Aufpreis für Daten, die diese Performance nur selten brauchen.

Tiering verändert die Zuteilung.

Hochwertige Performance-Kapazität wird für Workloads reserviert, die sie benötigen.

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 Ressourcenoptimierungs-Fähigkeit beschreibt.

Es unterstützt außerdem die Speicherüberwachung über Kapazität und Performance hinweg, die nötig ist, um zu prüfen, ob die Verschiebung tatsächlich hilft.

Die Quelle gibt keinen festen Einsparungsprozentsatz 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 die Performance beeinträchtigen, wenn Daten vom schnellen Tier verschoben werden, obwohl die Anwendung weiterhin schnellen Zugriff benötigt.

Ein Trainingsjob benötigt möglicherweise plötzlich einen älteren Datensatz.

Ein Wiederherstellungsprozess benötigt möglicherweise einen Checkpoint, der bereits verschoben wurde.

Eine Anwendung kann ein monatliches Workload-Muster haben, das den größten Teil des Monats cold wirkt, aber 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.

Der Beschleuniger ist gesund.

Der Datenpfad ist langsam.

Deshalb behandelt der Artikel darüber, warum die GPU-Auslastung niedrig sein kann, Speicher als einen möglichen Engpass, statt vorschnell die GPU als Problem anzunehmen.

Welche Speichermetriken sollten vor dem Tiering überwacht werden?

Überwachen Sie die Metriken, die sowohl Kapazität als auch Performance beschreiben.

Das Speichermodell der Quelle umfasst:

Kapazität
Durchsatz
IOPS
Latenz

Diese vier Dimensionen sind ein solides Minimum.

Die Kapazität zeigt, ob auf dem Tier noch Platz ist.

Der Durchsatz zeigt, wie viele Daten sich über die Zeit bewegen lassen.

IOPS ist wichtig für Workloads, die viele Operationen auslösen.

Die Latenz zeigt, wie lange Anfragen dauern.

Die entscheidende Frage ist nicht einfach, ob das Ziel-Tier genug freie Terabyte hat.

Sie lautet, ob das Ziel-Tier das Zugriffsmuster der zu verschiebenden Daten unterstützen kann.

Eine Tiering-Richtlinie, die sich nur an der Kapazität orientiert, kann zu einem Performance-Problem führen.

Welche Zugriffsdaten sollten das Tiering beeinflussen?

Nutzen Sie das tatsächliche Zugriffsverhalten, wo die Speicher- und Anwendungsumgebung es liefern kann.

Nützliche Signale können sein:

Letzter Zugriffszeitpunkt
Zugriffshäufigkeit
Lesevolumen
Schreibvolumen
Jüngste Projektaktivität
Workload-Bindung
Aufbewahrungsanforderung
Bedeutung des Checkpoints

Die Quelle unterstützt ausdrücklich Tiering auf Basis von Nutzungsmustern, definiert aber nicht den genauen Klassifizierungsalgorithmus.

Das bedeutet, ein Unternehmen kann die Signale nutzen, die es zuverlässig messen kann.

Vermeiden Sie es, eine Richtlinie auf Metadaten aufzubauen, die im eingesetzten Speichersystem nicht vertrauenswürdig sind.

Die Klassifizierung sollte nachvollziehbar sein.

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, aber allein kann es wichtige Daten falsch einstufen.

Ein sechs Monate altes Modell kann immer noch täglich aufgerufen werden.

Ein einwöchiges Experiment wird möglicherweise nie wieder verwendet.

Das Zugriffsmuster ist daher aussagekräftiger als das Erstellungsdatum allein.

Der nutzungsmusterbasierte Ansatz der Quelle unterstützt diese Idee.

Das Alter kann trotzdem eine Regel unter mehreren sein.

Zum Beispiel:

Keine Lesezugriffe innerhalb eines definierten Zeitraums
Keine aktive Projektabhängigkeit
Keine aktuelle Wiederherstellungsabhängigkeit
Kein SLO, das schnellen Zugriff erfordert

Der genaue Zeitraum sollte vom Unternehmen festgelegt werden.

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 unterscheiden zwischen:

Aktivem Datensatz, der von laufenden Jobs genutzt wird
Vorbereitetem Datensatz, der voraussichtlich bald genutzt wird
Historischem Datensatz, der zur Wiederverwendung oder für Audits aufbewahrt wird

Aktive Daten benötigen Speicherperformance, die zur Trainings-Pipeline passt.

Historische Daten können Kandidaten für ein niedrigeres Tier sein, sofern die Abrufzeit akzeptabel ist.

Die wichtige Kontrollgröße ist, den Datensatz mit der Trainingsaufgabe und dem Projekt zu verknüpfen.

Wird ein Datensatz noch von einem wartenden oder geplanten Job referenziert, kann eine Verschiebung auf ein langsameres Tier eine vermeidbare Verzögerung verursachen.

Die Datenbasis und die Aufgabenbeziehungen der Quelle liefern die Art von Zuordnungsdaten, die für diese Entscheidung nötig sind.

Wie sollten Modelldateien getiert werden?

Modellversionen können unterschiedliche operative Bedeutung haben.

Ein aktuelles Produktionsmodell ist hot.

Eine Rollback-Version benötigt möglicherweise ebenfalls schnellen Zugriff, auch wenn sie gerade keinen Traffic bedient.

Eine alte Version, die nur für Audits aufbewahrt wird, kann kälter sein.

Deshalb sollte Tiering den Lifecycle-Status berücksichtigen, nicht nur die Zugriffshäufigkeit.

Das Modell-Repository der Quelle hält Version und operativen Status für Modelle fest.

Diese Information kann helfen zu unterscheiden zwischen:

Produktion
Rollback-Kandidat
Evaluierung
Archiviert

Die Speicherrichtlinie kann den Modell-Lifecycle dann als einen Eingabewert nutzen.

Die Quelle gibt keine Tiering-Regel für Modelldateien vor, daher bleibt die genaue Richtlinie 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.

Eine Verschiebung auf ein langsames Tier kann die Wiederherstellungszeit nach einem GPU- oder Node-Ausfall verlängern.

Ältere Checkpoints können Kandidaten für kälteren Speicher sein, sobald der Job fortgeschritten ist und die Wiederherstellungsrichtlinie nicht mehr von ihnen abhängt.

Das Trainings-Recovery-Modell der Quelle nutzt Checkpoints, um zu vermeiden, dass Jobs von vorn beginnen müssen.

Das bedeutet, dass die Checkpoint-Speicherung Teil der Zuverlässigkeit ist.

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.

Eine Richtlinie sollte beantworten:

Welche Daten sind dafür infrage?

Welche Daten müssen auf dem schnellen Tier bleiben?

Welche Anhaltspunkte machen Daten cold?

Wann können Daten auf das Hot-Tier zurückkehren?

Welche Performance ist nach dem Abruf erforderlich?

Wie wird die Verschiebung überprüft?

Automatisierung sollte nicht bedeuten, dass Verschiebungen unsichtbar geschehen.

Steigt die Anwendungslatenz, nachdem ein Datensatz verschoben wurde, müssen Betreiber wissen, dass sich die Speicherplatzierung geändert hat.

Diese Änderung wird bei der Fehlersuche zu einem nützlichen Anhaltspunkt.

Wie sollte der Abruf aus dem Cold-Tier funktionieren?

Der Abruf sollte um die für die Anwendung akzeptable Wartezeit herum gestaltet werden.

Mancher Cold-Speicher kann Daten direkt liefern, allerdings mit geringerer Performance.

Andere Designs verschieben die Daten zunächst zurück auf ein Hot-Tier.

Die Quelle legt den Abrufmechanismus nicht fest.

Das Unternehmen muss daher das Verhalten seiner tatsächlichen Speicherplattform dokumentieren.

Operativ überwachen Sie:

Abrufzeit
Leselatenz
Durchsatz nach dem Abruf
Wartezeit der Anwendung
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 Folgendes haben:

Kapazitätsquote für das schnelle Tier
Allgemeine Speicherkapazität
Bandbreiten- oder Performance-Richtlinie

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 eingesetzt 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 benötigt möglicherweise trotzdem schnellere Verfügbarkeit, wenn das Wiederherstellungsziel streng ist.

Auf ein Rollback-Modell wird vielleicht nur im Fehlerfall zugegriffen, aber genau dann muss es verfügbar sein.

Deshalb sollte Storage-Tiering 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 sowohl die Speicherzuteilung als auch die Performance, nachdem die Richtlinie angewendet wurde.

Erfassen Sie:

Freigegebene Premium-Tier-Kapazität
Verbrauchte Kapazität auf dem niedrigeren Tier
Verschobene Daten
Abrufvolumen
Anwendungslatenz
Speicherdurchsatz
IOPS
Performance-Vorfälle
Speichernutzung pro Projekt

Wenden Sie anschließend das Speicherkostenmodell der Organisation an.

Die Quelle definiert keinen universellen Preis pro Speichereinheit, daher sollten die Kosten aus der tatsächlichen Umgebung stammen.

Entscheidend ist zu überprüfen, dass die günstigere Platzierung nicht so viel Performance gekostet hat, dass dadurch Compute-Leerlaufzeit entsteht oder Serviceanforderungen verletzt werden.

Was sollte ein Tiering-Dashboard anzeigen?

Eine praxistaugliche Ansicht kann zeigen:

Kapazität nach Storage-Tier
Volumen von Hot- und Cold-Daten
Im Zeitraum verschobene Daten
Top-Projekte nach Premium-Tier-Nutzung
Durchsatz
IOPS
Latenz
Abrufaktivität
Tiering-Ausnahmen
Zugehöriger 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 implementieren, würde ich mit Daten beginnen, die eindeutig inaktiv und leicht abrufbar sind, und erst dann die Wirkung messen, bevor ich die Richtlinie ausweite. Das falsche Ziel ist, die maximale Anzahl an Terabyte auf günstigeren Speicher zu verschieben. Das richtige Ziel ist, den Verbrauch von Premium-Speicher zu senken, ohne Anwendungen, Trainingsjobs oder Wiederherstellungsabläufe genau in den Momenten warten zu lassen, in denen es darauf ankommt.