Mobile-Menu

Michael Matzer im Gespräch mit Alexander Wallner, NetApp, über moderne RZ-Infrastrukturen mit Systemblöcken und Objekten

Die Nachfrage nach Systemblöcken für die Private Cloud nimmt zu

Seite: 3/3

Anbieter zum Thema

Ein kritischer Faktor in diesem Zusammenhang ist auch der Mangel an qualifizierten Fachkräften: "Das Up-Leveling, vulgo: Höherqualifizierung, eigenen Personals hat den Vorteil, dass ein Unternehmen seine Mitarbeiter behält, sie aber binnen zwei Jahren in strategische Positionen 'emporhieven' kann."

Objektspeicher arbeiten ohne Index

Bislang werden Objekte wie Video- oder Audiodateien auf einem Fileserver als Dateien in einem Dateisystem gespeichert. Das Problem ist nicht die Menge von dafür nötigem Speicherplatz, sondern die schiere Anzahl der Dateien.

Jedes File-System muss bislang in einem Index einen Tabelleneintrag für jedes Objekt (Datei) machen. Bei 50 Millionen Dateien wird erst das Backup, dann aber besonders der Restore-Vorgang ein Problem: Das Zeitfenster für die Wiederherstellung wird zu klein, selbst wenn man wie Netapp den Speicherplatz um 50 Prozent reduzieren kann.

Da heute bereits ein Ausfall der IT von wenigen Stunden ein Unternehmen massiv schädigen kann (es kommen Konventionalstrafen der Auftraggeber hinzu), muss man sich Gedanken um eine fortschrittlichere Methode der Objektspeicherung machen.

Funktionelle Objektklassen

Die Antwort sind Next Generation File Services (NGFS). Statt Dateinamen und Freigabenamen zu vergeben, wird nur ein Inventarname in einem Katalog angelegt. Die Aufnahme der Objekte kann über Unix- und Windows-Filesysteme in einem Storage Grid (Cluster im Petabyte-Bereich) erfolgen.

Nun kann der Nutzer Klassen von Objekten anlegen und jeder Klasse eine Policy zuweisen, also eine Behandlungsregel. Das kann etwa eine automatische Verlagerung auf eine SATA-Platte in den USA oder Indien sein.

Im Katalog der Objekte kann der Nutzer mit einer leistungsfähigen Suchfunktion das Objekt leicht wiederfinden und es durch Zurückholen wiederherstellen - das macht Backup überflüssig. Für Big Data und Content Repository ist dies ein zentraler Gedanke: Ein Objekt wird in einer Bibliothek zusammen mit Metadaten abgelegt.

Ein Storage Grid für Big Data?

Es gibt für den Bibliotheks-Katalog die offene CDMI-Schnittstelle, aber auch andere, die sich hier etablieren. Man will ja nicht schon wieder einen Silo bauen. Netapp setzt deshalb auf offene Standards. Wir können also Meta-Index-Suchmaschinen leicht anbinden. Unsere Domäne: hochverfügbare, skalierbare Speichersysteme mit extrem hoher Packungsdichte.

Darüber sorgt die Storage-Grid-Software dafür, Daten und Objekte Policy-basiert und vollautomatisiert dorthin zu verlagern, wo der Nutzer sie haben möchte. Was passiert aber, wenn der Repository-Katalog so groß wird, dass er die Kapazität einer Festplatte übersteigt? Der Index ist zwar relativ klein, selbst wenn es sich um 900 TByte im Repository handeln sollte, aber dennoch ist das Verteilen eines solchen Katalogindexes kein Problem: Wie in einem RAID-Array wird er gestriped und so verteilt.

Big Data ist für Wallner einer der wichtigsten Einsatzbereiche für Content Repository und Storage Grid. "Dieser Markt hat drei Teilbereiche: A wie Analyse, B wie Bandbreite (also hoher I/O-Durchsatz etwa in Videoüberwachung und High Performance Computing) und C wie in Content Repository."

(ID:39405870)