Bei unstrukturierten Daten, wie sie insbesondere auf NAS Systemen liegen, ist die Situation komplizierter. Die Daten stammen unter Umständen von Hunderten Benutzern mit unterschiedlichsten Profilen und Datentypen. Hier gilt es, die ‚richtigen’ Daten auf den ‚richtigen’ Speichermedien zu speichern.
Was unter ‚richtig’ zu verstehen ist, hängt von den Anforderungen ab. Übliche Kriterien sind Performance, Verfügbarkeit, Größe, Anwendungscharakteristik oder Benutzergruppen. Ganz häufig sind in Unternehmen ‚manuelle’ Strategien anzutreffen, die bestimmte Speicherklassen wie Tier1, Tier2 oder Tier3 definieren und bei denen dann Anwendungsdaten nach bestimmten Kriterien und / oder SLAs diesen Tiers zugewiesen werden. Diese Vorgehensweise ist aber bestenfalls suboptimal, weil sich so weder eine optimale Kosteneffizienz noch die optimale Performance eines Gesamtsystems erreichen lässt. Ferner ist eine solche Kategorisierung oft statisch, das heißt, einmal gespeicherte Daten verbleiben während ihres gesamten Lebenszyklus auf dem Medium, auf dem sie erstmalig gespeichert wurden. Typischerweise ändert sich aber bei den allermeisten Daten das Zugriffprofil über die Zeit erheblich.
Kurz nach der ersten Speicherung von Dokumenten werden diese in der Regel häufig verwendet. Dies gilt sowohl für Office-Dokumente, weil sie nach der ersten Speicherung bearbeitet werden, als auch zum Beispiel für Fotos. Diese werden nach ihrer Erstellung noch häufiger angesehen, später dann immer weniger. Es kann aber auch umgekehrt sein, denkt man etwa an Videos in entsprechenden Portalen. Zu Beginn gibt es mäßige Zugriffe, bis sich durch Empfehlungen und Soziale Netzwerke ein echter Zugriffssturm entwickelt, der dann über die Zeit wieder abklingt. Solche Zugriffsmuster sollte ein System mit integrierten Life Cycle Management berücksichtigen, damit die Daten zur richtigen Zeit auf dem richtigen Speichermedium gespeichert werden.
Ein weiteres Problem bei einer manuellen Festlegung von Daten zu bestimmten Tiers besteht darin, dass sich die Benutzer gegebenenfalls merken müssen, auf welchen Medien ihre unterschiedlichen Daten gespeichert werden, weil auch der logische Speicherort, das heißt Laufwerk beziehungsweise Verzeichnispfad, damit verknüpft ist. Wenn sich bei der Migration von Daten auch der Zugriffspfad ändert, werden viele User ihre Daten nicht auf Anhieb auf ihrem Storage finden.
Lifecycle Management: Daten zum richtigen Zeitpunkt am richtigen Ort
Die skizierten Probleme können mit einem integrierten Lifecycle Management gelöst werden, wie es zum Beispiel IBM Scale Out NAS System SONAS oder im parallelen Dateisystem GPFS sowie bei entsprechenden Systemen anderer Hersteller vorhanden ist. Hier werden Speichertechnologien sogenannten Pools zugeordnet, wobei jeder Pool immer nur eine Speichertechnologie enthält. Zur besseren Illustration gehen wir nachfolgend von folgendem Beispiel aus:
Pool 1 = Tier 1: FC oder SAS Disks mit 15k PRM, RAID 10 (schnell, teuer)
Pool 2 = Tier 2: SAS Disks mit 10k RPM, RAID 5 (gutes Preis/Performance Verhältnis)
Pool 3 = Tier 3: SATA Disks mit 7,2k RPM RAID 6 (günstig, langsam)
Pool 4 = Tier4 (externe Pool, Tape Library oder VTL) (sehr günstig für langfr.Archivierung)
Das oder die Dateisysteme werden nun über alle Pools (Tiers) gespannt. Die Zuweisung, welche Daten in welchen Pool gespeichert werden, erfolgt auf zweierlei Weise.
-
1. Sogenannte Placement-Rules legen den Speicherort zum Zeitpunkt der erstmaligen Speicherung einer Datei fest. Es können hierfür verschiedenste Meta-Daten als Kriterium herangezogen werden, beispielweise Dateigröße, Typ, Benutzer oder Zeitpunkt.
-
2. Migration-Rules sind dann im späteren Verlauf für die neue Zuweisung, das heißt für dieMigration auf einen anderen Pool , verantwortlich. Auch hier dienen die Meta-Daten als Kriterium, zum Beispiel letzter Zugriff oder Größe.
Foto: IBM
Das parallele Dateisystem GPFS stellt sicher, dass Daten, die nach den Migration-Rules auf einen anderen Pool migriert werden, ihren logischen Speicherort, das heißt den Zugriffspfad, beibehalten. So können unterschiedlichste Dateien in einem Verzeichnis physikalisch auf unterschiedlichen Pools (also unterschiedlichen Medien) gespeichert sein. Für den Benutzer ist dies ebenso transparent wie eine mögliche spätere Verschiebung der Dateien.
Beispiele für transparente Migrationsregeln in Pools
Die Formulierung der Storage-Placement- und Migration-Policies erfolgt nun mithilfe einer SQL-ähnlichen Syntax. Nachfolgend ein Beispielregelwerk mit vier einfachen Regeln:
RULE 'vip' set pool 'tier1' where USER_ID <= 100
RULE 'ppt_files' SET POOL 'tier1' WHERE UPPER(name) like '%.PPT';
RULE 'mp3_files' SET POOL 'tier3' WHERE UPPER(name) like '%.MP3' or file_size > 2048 kB;
RULE 'default' set POOL 'tier2'"
Die erste Regel mit dem Namen ‚vip’ sorgt dafür, dass alle Dateien von Usern mit User-IDs kleiner als 100 im Pool ‚tier1’ gespeichert werden, also in unserem Beispiel im Pool mit den schnellsten Disks.
Die zweite Regel ‚ppt_files’ speichert alle PowerPoint-Dateien sämtlicher User ebenfalls im Pool ‚tier1’.
Die dritte Regel speichert MP3 Dateien sowie alle anderen Dateien, die größer sind als 2 Mbyte, im Pool ‚tier3’.
Eine letzte Default-Regel sollte immer vorhanden sein. Sie gilt für jene Dateien, die keiner der vorherigen Regeln entsprechen. In unserem Fall werden also sämtliche anderen Dateien im Pool ‚tier2’ gespeichert.
Migrationsregeln in der Praxis
Nun wollen wir uns noch ein Beispiel mit möglichen Migrationsregeln anschauen. Nachfolgende Regel greift bei einem Füllgrad des Dateisystems von 90 Prozent und migriert so lange Daten von ‚tier1’ nach ‚tier2’, bis ein Füllgrad von 70 Prozent erreicht ist.
rule 'clean-tier1' migrate from pool ‘tier1' threshold (90,70) to pool ‘tier2’
Diese Regel würde in der Praxis so eher nicht eingesetzt, weil noch die Angabe fehlt, mit welchen Daten das System die Migration beginnen soll. Dies würde dann etwa so aussehen:
rule 'clean-tier1' migrate from pool ‘tier1' threshold (90,70) weight(current_timestamp - access_time) to pool ‘tier2’ where file_size > 1024kB
Jetzt würde die Migration auch bei einem Füllgrad von 90 Prozent anspringen, aber die Migration würde mit älteren Dateien starten und nur die Dateien migrieren, die größer sind als 1 MByte. Die Migration muss aber nicht wie im obigen Beispiel gezeigt immer durch Schwellwerte getriggert sein, sie kann auch zeitlich gesteuert werden:
rule 'clean_tier1' when day_of_week()=Monday migrate from pool 'tier1' to pool 'tier2' where access_age > 30 days
rule 'clean_tier2' when day_of_week()=Tuesday migrate from pool 'tier2' to pool 'tier3' where access_age > 60 days
In diesem Beispiel würden montags alle Dateien von ‘tier1’ nach ‘tier2’ migriert werden, die länger als 30 Tage nicht geöffnet wurden, und solche, die länger als 60 Tage nicht geöffnet wurden, würden dienstags von ‚tier2’ nach ‚tier3’ kopiert. Selbstverständlich sind auch Fälle denkbar, in denen es sinnvoll ist, Daten in einen höherwertigen Pool zu kopieren.
Meta-Daten scannen
Bei großen Dateisystemen mit Hunderttausenden oder Millionen von Dateien gilt es noch eine andere Problematik zu lösen. Ähnlich wie bei einem Backup-Prozess müssen alle Dateien gescannt werden, um sie mit dem Regelwerk abzugleichen und zu prüfen, welche Dateien in die Kandidatenliste für die Migration aufgenommen werden. Bei einem traditionellen Scan-Vorgang, wie er etwa auch von Backup-Software verwendet wird, würde man bei Millionen von Dateien niemals zum Ende kommen, weshalb hier ein anderes Verfahren angewendet wird.
Bei parallelen Dateisystemen werden üblicherweise die Meta-Daten aller Dateien separat verwaltet. Der Scan braucht sich also nicht durch das Dateisystem zu arbeiten, sondern kann sich direkt an den Meta-Daten-Server wenden. Im Falle von GPFS kann der Scan nun parallel auf mehreren oder allen Cluster-Nodes erfolgen, sodass der Scan um Faktoren beschleunigt wird.
Mit diesem parallelen Scan-Verfahren können circa zehn Millionen Files pro Minute und Cluster-Knoten mithilfe der Policy Engine gescannt werden. Dieses Verfahren wird zum Beispiel auch für Backup-Zwecke verwendet: Der parallele Scan erzeugt dabei eine Liste aller Dateien, die zu sichern sind. Diese Liste wird dann an die Backup-Software übergeben, die selbstständig die Dateien (ohne notwendigen eigenen Scan) sichern kann. Ohne solche Maßnahmen ist es kaum möglich, große Dateisysteme effizient zu sichern.
Freilich muss man darauf hinweisen, dass eine solche Backup Lösung zwar recht flott sichert (die Sicherung erfolgt in der Regel von mehreren Nodes parallel), aber eher nicht als Disaster-Recovery-Lösung infrage kommt, denn ein Restore würde im Fall des Falles bei Millionen von Dateien und Terabyte von Daten vermutlich viel zu lange dauern. In solchen Fällen wird man eher über sinnvolle Replikationsmechanismen nachdenken, die beim Ausfall eines ganzen Rechenzentrum eine mehr oder weniger unterbrechungsfreie Fortführung des Betriebes erlauben.
Hierarchical Storage Management (HSM): auf externe Medien migrieren
Führt man den Gedanken fort, dass Daten über ihren Lebenszyklus auf andere Medien zu migrieren sind, drängt sich von selbst die Idee auf, Daten auf externe Medien zu migrieren. Der Gedanke wird ja auch beim traditionellen Archivieren verfolgt. Hier müssen allerdings die Benutzer wissen, dass eine Archivierungssoftware ihre Daten migriert hat, und sie müssen sich entsprechender Tools bedienen, um die Daten zurückzuholen. Dieses Vorgehen wird häufig als umständlich empfunden.
Beim Hierarchical Storage Management (HSM) wird mithilfe der oben beschriebenen Regeln eine Datei auch auf externe System, zum Beispiel eine Tape Library oder VTL, migriert; dabei bleibt allerdings ein Stub-File im Dateisystem vorhanden. Für den Benutzer ist das transparent, das heißt, er sieht nach wie vor alle seine Dateien, auch wenn einige davon bereits auf Tapes oder externe Disks ausgelagert wurden.
Greift der Benutzer oder eine Anwendung nun auf solche Daten zu, werden sie sofort vom externen Medium zurückkopiert. Dies verzögert natürlich den Zugriff auf die Daten, weshalb HSM üblicherweise für Dateien verwendet wird, auf die in Zukunft eher selten zugegriffen wird oder bei denen eine etwas längere Recall-Zeit akzeptabel ist.
Fazit
In einem Speichersystem integrierte ILM- und HSM-Funktionen sorgen dafür, dass Daten nach einem flexibel konfigurierbaren Regelwerk stets auf dem günstigsten Speichermedium gespeichert werden, ohne dass sich der logische Zugriffspfad ändert. Was ‚günstig’ ist, hängt vom Einsatzszenario ab, ist aber in der Regel immer eine Abwägung zwischen Performance und Verfügbarkeit einerseits und Kosten andererseits. Benutzer oder Administratoren werden so von der Last befreit, regelmäßig die eigenen Datenbestände aufzuräumen; dies erledigt die Software beziehungsweise das Dateisystem selbstständig.
Zum Schluss sei noch anzumerken das es auch Techniken gibt, die eine Verlagerung von Daten zum Zwecke der Performance-Optimierung auf Blockebene erledigen. Dies führt zum Beispiel beim Einsatz von derzeit noch sehr teuren SSD-Disks zu ihrer sehr effizienten Nutzung, weil durch die Migration weniger ‚heißer Blöcke’ oft ein sehr starker Effekt erreicht werden kann. (hal)