Dateispeicher vs. Blockspeicher vs. Objektspeicher

Immer mehr Daten werden weltweit übertragen und generiert als jemals zuvor. Die Marktforscher von IDC erwarten, dass bis 2025 die globale Datensphäre auf 163 Zettabytes anwachsen wird. Das ist ein Anstieg um mehr als 1000% gegenüber den 16,1 ZB der Daten von 2016. Die Gründe für diese enorme Zunahme der Daten sind vielfältig:

Die Anzahl der Quellen und Geräte, die Daten erzeugen, steigt weiterhin rasant. Embedded Systems und Internet of Things-Geräte sammeln Daten und übertragen diese in Big-Data-Anwendungen und -Lösungen, um eine Echtzeitanalyse durchzuführen. Der anhaltende Trend, mobile Geräte und Social-Media-Plattformen sowie Online-Shopping und alle Arten von Anwendungen zu nutzen, egal wann und wo auch immer, produziert jeden Tag viele, viele Daten. Auch Unternehmen verändern sich stetig beim Datenmanagement, um die steigende Nachfrage nach Nachrichten und Echtzeitdaten ihrer Kunden zu befriedigen.

Laut einer neuen Gartner-Prognose wird mehr als die Hälfte der Unternehmen bei den wichtigsten Geschäftsprozessen und -systemen mindestens ein Element des IoT (Internet der Dinge) bis zum Jahr 2020 in ihre Organisation integrieren. Und damit wird die Menge an Daten, die von Big-Data-Anwendungen generiert, übertragen und analysiert werden (und die entweder vor Ort oder außerhalb des Unternehmens gespeichert werden), enorm wachsen.

Aus diesem Grund ist die Nachfrage - durch das Management und die Vertreter der IT-Abteilungen - nach Speicherlösungen, die in der Lage sind, noch mehr digitale Inhalte für lange Zeit zu verwalten und zu archivieren, drastisch gestiegen.

Es ist jedoch nicht nur die größere Menge an Speichergeräten, die jetzt aus einer Hardware-Perspektive benötigt wird - wie zum Beispiel Festplatten, SSDs oder SSHDs. Auch der Bedarf an geeigneten Dateisystemen, die das Wachstum der Big Data bewältigen kann ist gestiegen. Denn selbst wenn nicht alle Daten auf Speichergeräten gespeichert werden, so müssen doch die wichtigsten Daten sowie die Analyseergebnisse auf jedem Fall gespeichert werden. Dies führt zu mehr Nachfrage nach Speicherplatz. Ein großer Teil dieses gewachsenen Speicherbedarfs wird sowohl intern als auch in der Cloud mit Diensten wie Amazon S3 oder Microsoft Azure von Unternehmen abgewickelt.

Die alten Konzepte der Speicherung mit Dateispeicher und Blockspeicher werden für dieses Datenwachstum sowohl für Unternehmen als auch für die Cloud-Anbieter in Zukunft nicht mehr funktionieren. Die Lösung für die Speicherung dieser riesigen Datenmengen ist der Objektspeicher (engl. Object storage), der auch als objektbasierter Speicher bezeichnet wird. Aber was sind die Unterschiede und was macht den Objektspeicher geeignet für die Datenexplosion als die früheren Konzepte?

Um die Vorteile zu verstehen, die Objektspeicher bieten, muss man sich zuerst die älteren Konzepte - Dateispeicher (File storage) und Blockspeicher (Block storage) - ansehen, da sie sich stark unterscheiden.

Die Unterschiede zwischen Datei-, Block- und Objektspeicher (File, Block and Object storage)

Datei- und Blockspeicher sind Methoden zum Speichern von Daten auf NAS- und SAN-Speichersystemen.

Auf einem NAS-System wird der Speicher als Netzwerkdateisystem verfügbar gemacht. Wenn Geräte an ein NAS-System (Network Attached Storage) angeschlossen werden, wird ein gemountetes Dateisystem angezeigt und Benutzer können mit ihren Zugriffsrechten auf ihre Dateien zugreifen. Aus diesem Grund muss ein NAS-System Benutzerrechte, Dateisperren und andere Sicherheitsmaßnahmen verwalten, damit mehrere Benutzer auf Dateien zugreifen können. Der Zugriff auf das NAS erfolgt über NFS- und SMB / CIFS-Protokolle. Wie bei jedem Server oder jeder Speicherlösung ist ein Dateisystem für die Positionierung der Dateien im NAS zuständig. Das funktioniert sehr gut für Hunderttausende oder sogar Millionen von Dateien, aber nicht für Milliarden.

Der Blockspeicher funktioniert ähnlich, aber im Gegensatz zum Dateispeicher, bei dem die Daten auf Dateiebene verwaltet werden, werden Daten in Datenblöcken gespeichert. Mehrere Blöcke (zum Beispiel in einem SAN-System) ergeben eine Datei. Ein Block besteht aus einer Adresse und die SAN-Anwendung bekommt den Block, wenn sie eine SCSI-Anfrage an diese Adresse sendet. Die Speicheranwendung entscheidet dann, ob die Datenblöcke innerhalb des Systems gespeichert werden und auf welchem spezifischen Datenträger oder Speichermedium. Wie die Blöcke am Ende kombiniert werden und wie auf sie zugegriffen wird, entscheidet die Speicherverwaltungsanwendung der Storagelösung. Blöcke in einem SAN haben keine Metadaten, die sich dezidiert auf das Speichersystem oder die Storageanwendung beziehen. Mit anderen Worten: Blöcke sind Datensegmente ohne Beschreibung, Zuordnung und ohne einen Besitzer für die Speicherverwaltungsapplikation. Alles wird von der SAN-Software gehandhabt und gesteuert. Aus diesem Grund werden SAN- und Block-Speicher häufig für leistungshungrige Anwendungen wie Datenbanken oder für Transaktionen verwendet, da hier die Daten abgerufen, geändert und gespeichert werden können.

Beide Methoden zum Speichern von Daten funktionierten jahrelang einwandfrei. Warum braucht man dann ein anderes Konzept? Das liegt daran, dass Lösungen für beide Konzepte und Funktionen für Benutzerzugriffsrechte implementiert werden müssen, damit sie Änderungen an den Daten vornehmen können.

Was wir jetzt sehen, ist, dass viele der Daten, die jetzt produziert werden, "eingekerkerte" oder unstrukturierte Daten sind. Inhalte oder Material, das nie wieder geändert wird. Und hier kommt der Objektspeicher ins Spiel:

Objekte im Objektspeicher sind "gebündelte Daten" (aka eine Datei) mit entsprechenden Metadaten. Dieses Objekt erhält eine eindeutige ID (Identifizierungsbezeichnung), die aus dem Dateiinhalt und den Metadaten berechnet wird. Anwendungen identifizieren das Objekt dann über diese ID. Die vielen Objekte innerhalb eines Objektspeichersystems sind über die gesamten gegebenen Speicherplatten hinweg gespeichert. In seiner reinen Form kann ein Objektspeicher "nur" eine Version einer Datei (Objekt) speichern. Wenn ein Benutzer eine Änderung vornimmt, wird eine andere Version derselben Datei als neues Objekt gespeichert. Aus diesem Grund ist ein Objektspeicher die perfekte Lösung für eine Backup- oder Archivierungslösung. Oder auch für Speicher, die große Mengen an Videos oder Filmen enthalten, die nur angeschaut, aber nicht verändert werden, wie zum Beispiel Online-Videostreaming-Seiten oder Videos auf youtube.com.

Der Hauptunterschied zwischen den anderen Konzepten besteht darin, dass die Objekte über die Anwendung selbst verwaltet werden, die den Objektspeicher unterstützt. Das bedeutet, dass hier kein echtes Dateisystem benötigt wird. Diese Ebene ist hier obsolet. Eine Anwendung, die den Objektspeicher verwendet, sendet eine Speicheranfrage direkt an die Lösung, in der das Objekt gespeichert werden soll. Das Objekt erhält dann eine Adresse innerhalb des großen Speicherplatzes und wird dann dort von der Anwendung selbst gespeichert.

Aufgrund der sehr einfachen Verwaltung von Daten - ohne echtes Dateisystem - können Objektspeicherlösungen viel einfacher skaliert werden als Dateispeicher oder blockspeicherbasierte Systeme. Sie fügen nur einige Festplatten in die Lösung ein und es ist keine große Verwaltung mehr erforderlich, um mehr Speicherplatz zu bekommen. Das ist gerade in Zeiten exponentiellen Datenwachstums ein immenser Vorteil.

Object Storage ist also eine perfekte Lösung für große Datenmengen und wird daher von großen Cloud-Service-Providern wie Amazon, Google und anderen genutzt.

Erasure Coding als Sicherheitsmaßnahme gegen Datenverlust in objektbasierten Speichersystemen

Lange Zeit war RAID eine gute Wahl, um vor Datenverlust aufgrund eines Hardwarefehlers von einer oder mehrerer kaputten Festplatten sicher zu sein (RAID 6). Das Konzept der Paritätsberechnung und der Datenwiederherstellung auf diese Art funktioniert gut mit kleineren Datenträgergrößen, die in den letzten Jahren üblich waren. Bei Festplattengrößen von 10 Terabyte oder mehr kann die Wiederherstellung einer vollständigen Festplatte zukünftig Monate dauern. Es ist nicht so einfach, die genaue Wiederherstellungszeit vor dem Start zu bestimmen, da dies von der vorhandenen Arbeitsauslastung des Systems abhängt. Aus diesem Grund wird RAID in Datenspeichersystemen nicht als Data Protection Methode oder Datenwiederherstellungsverfahren verwendet. Es wäre unmöglich, Daten in einem überschaubaren Zeitrahmen zurückzugewinnen. Und ein anderes Problem kann zudem bei RAID auftreten: Wenn ein anderer Datenträger während eines RAID-Rebuild-Prozesses ausfällt, gehen die Daten endgültig verloren, ohne dass sie wiederhergestellt werden können. Aus diesem Grund wurde für große Speicher und ihre Festplatten die Methode des Erasure Coding eingeführt.

Wie bereits erwähnt, können Objekte überall in einem funktionierenden Objekt-Speichersystem vorliegen: im Unternehmen vor Ort, an vielen verschiedenen Standorten oder in der Cloud. Der Zugriff auf Objekte ist wegen ihrer internetfähige Struktur faktisch über jedes Gerät mit Internetzugang möglich. Um die Objekte sicherer gegen Datenverlust zu machen, kommt Erasure Coding zum Einsatz:

Methodisch ähnelt die Erasure-Codierung einer klassischen RAID-Absicherung bzw. Wiederherstellung. Auch hier werden zusätzliche Informationen aus den zu speichernden Objekten erzeugt. In einem System mit Erasure Coding (EC) werden die Objekte in Teile aufgeteilt. Diese Datenblöcke sind typischerweise mehrere Megabyte groß und daher viel größer als die Blöcke, die normalerweise in einem RAID-geschützten System erstellt werden.

Jeder Datenblock wird dann analysiert und zusätzlich zu dem ursprünglichen Datenblock werden mehrere kleinere Fragmente erzeugt. Um Originaldaten wiederherzustellen, wird eine Mindestmenge dieser sogenannten Scherben (Sherds=Blockteile) benötigt. Wenn zum Beispiel mit EC ein Datenblock "16 Fragmente" erzeugt, werden 12 davon (unabhängig davon, welche davon verfügbar sind) benötigt, um die ursprünglichen Informationen wiederherzustellen.

Zur Erstellung dieser Fragmente wird eine spezielle mathematische Formel - der XOR-Scheduling-Algorithmus - verwendet. Für mehr Informationen darüber, sollten Sie am besten die Originalarbeit lesen: http://nisl.wayne.edu/Papers/Tech/dsn-2009.pdf .

Die Aufteilung von Daten und Objekten in Fragmente hat einige Vorteile: Da diese Fragmente auf verschiedenen Datenträgern oder an verschiedenen Speicherorten gespeichert sind, führt ein Fehler auf einem Laufwerk nicht zu Datenverlusten. Und noch besser: Da nicht alles von den ursprünglichen Daten neu aufgebaut werden muss, sondern nur eine verpflichtende Anzahl von Fragmenten, ist der gesamte Wiederherstellungsprozess viel schneller als sein RAID-Gegenstück. Darüber hinaus  ist es wesentlich einfacher, Fragmente an einem anderen Speicherort zu speichern als das Speichern eines vollständigen Backups auf einem externen Speichersystem. Der Administrator muss nur sicherstellen, dass genügend Fragmente verfügbar sind, wenn sie benötigt werden.

Können Datenwiederherstellungsingenieure Daten aus Objektspeichern wiederherstellen?

Aufgrund der Tatsache, dass diese Systeme sehr sicher gegen Ausfälle sind, hat keines dieser neuen Objektspeichersysteme bislang den Weg in eines der vielen Data Recovery Labs von Ontrack Data Recovery auf der ganzen Welt gefunden.

Was Ontrack Data Recovery-Ingenieure jedoch bereits erfolgreich wiederherstellen konnten, waren Daten aus einer Beta-Version eines EMC Isilon-Speichersystems, das speziell für die Speicherung großer Mengen von Big Data entwickelt wurde. Einfach ausgedrückt, basiert ein Isilon-System auf dem Konzept, alle Daten in einem sogenannten "Datensee" zu speichern, der sich über viele Festplattenlaufwerke verteilt. Die Idee, Daten in einem Big Data Lake von EMC zu speichern, ist vergleichbar mit dem Konzept des Objektspeichers. Zusätzlich arbeitet das EMC-System mit einem speziellen Dateisystem, das speziell für Big Data und das Konzept eines Datensees entwickelt wurde.

In einem Datenverlustfall mit einer Beta-Version eines solchen Systems trat eine Kernel-Panik auf und mehrere Festplatten zeigten Fehler. Obwohl EMC die meisten Daten mit den normalen integrierten Wiederherstellungstools selbst wiederherstellen konnte, zeigte eine Konsistenzprüfung, dass mehrere Festplatten fehlerhaft waren und daher nicht alle Daten auf diese Weise gerettet werden konnten.

Um die Daten wiederherzustellen, entwickelten die Ingenieure von Ontrack aus der Forschungs- und Entwicklungsabteilung spezielle Tools, um ein vorhandenes OneFS-Laufwerk schnell zu analysieren und fehlende oder beschädigte Datenstrukturen zu finden. Nachdem die Ingenieure schließlich die ursprüngliche Struktur des Systems herausgefunden hatten, konnten sie fast alle der 4 Millionen fehlenden Dateien wiederherstellen.

Dieses Beispiel zeigt, dass moderne Datenwiederherstellung im Prinzip in der Lage ist, verlorene Daten von einem Objektspeichersystem wiederherzustellen, und zwar selbst in dem höchst unwahrscheinlichen Fall, dass die integrierten Datenwiederherstellungswerkzeuge und Sicherheitsfunktionen ausfallen.

Wie der Beispiel-Fall jedoch zeigt, wird es sehr mühsam sein, tief in die Systemstruktur einzutauchen, mehrere Datenschichten zu analysieren und zu entpacken oder Teile auf verschiedenen Platten wieder zusammenzubauen, bis schließlich die ursprünglichen Daten abgerufen werden können.

Und es gibt einige andere Herausforderungen in einem Objektspeichersystem, die bewältigt werden müssen: Da die Adressverwaltung der Daten in einem Objektspeichersystem in der Anwendung selbst erfolgt, bedeutet dies, dass in einem solchen Fall eine spezifische Lösung entwickelt werden muss, die den Ingenieuren hilft herauszufinden, wo konsistente Datenblöcke auf den Hunderten von Festplatten gespeichert sind oder wo fehlende Datenblöcke zum Beispiel durch Erasure Coding oder spezielle Datenrettungstechniken wiederhergestellt werden müssen.