Anbieter zum Thema
Seit der Version 3.2 kann man innerhalb eines Dateisystems sogenannte Pools definieren, die beispielsweise aus logischen Laufwerken (LUNs) und Bandspeichern bestehen können. Damit lassen sich hierarchische Speicherkonzepte realisieren, die – wie beim Information Lifecycle Management (ILM) geplant – länger nicht genutzte Daten erst auf langsamere, günstigere Festplatten verlagern und schlussendlich alle ungenutzten Daten aufs Band verschieben. Eine Option, die etwa vom Rechenzentrum des GridKa des Forschungszentrums Karlsruhe lange vermisst wurde. Man behalf sich schließlich mit einer selbst programmierten Lösung.
Über die implementierte, SQL-ähnliche Syntax bestimmt der Anwender die Migrations-Regeln. Alte oder extrem selten benötigte Datenbestände lagert das System anschließend selbstständig auf Bandspeicher aus. Im Dateisystem verbleiben sogenannte Stubs, die Informationen zum wahren Lagerort enthalten. Sollte wieder ein Zugriff auf einen Stub stattfinden, rekonstruiert GPFS den Datei-Inhalt mit geringer Verzögerung vom Tape. Kriterien für die Migration sind üblicherweise das Datum des letzten Zugriffs, die Größe der Datei, der Dateiname oder der Dateityp.
Beschleunigter Backup-Scan-Prozess
Über den GPFS-internen Inode-Scanner und die Policy-Engine lassen sich Backup-Prozesse stark beschleunigen. Dauert das Durchsuchen von zig Millionen Dateien mit normalen Dateisystemen Tage, so kann das IBM-Dateisystem mit einem Scan Millionen von Dateien in der Minute auf bestimmte Attribute untersuchen (etwa letztes Schreibdatum), sodass ein Backup-Programm schnellstmöglich die wichtige Information „Datei nach der letzten Datensicherung verändert“ bekommt. Das erspart dem Backup-Programm eine zeitraubende Suche nach Änderungen über die klassischen Systemaufrufe.
Morgen unter anderem in Teil zwei: GPFS verteilt Daten I/O-optimiert über alle angeschlossenen Festplatten und stellt Anwendern eine breite Auswahl an möglichen Blockgrößen zur Verfügung.
(ID:2018669)