Erasure Coding bringt mehr für die Datensicherung als RAID

In der Kombination mit Erasure Coding können RAID-Systeme neue Aufgaben in der Datensicherung übernehmen.

RAID hat seit fast 30 Jahren das Rückgrat der lokalen Datenverfügbarkeit in den Arrays gebildet, aber die Technologie zeigt erste Alterserscheinungen. Das exponentielle Wachstum der Kapazitäten ohne ein gleichartiges Wachstum bei der Performance der Platten bedeutet, dass RAID-Systeme Schwierigkeiten mit wirksamer Skalierbarkeit bekommen. Das lässt sich mit einer der allerneuesten Entwicklungen lösen – mit Erasure Coding.

Erasure Coding erfüllt die Bedürfnisse von besonders skalierenden Speicherinstallationen, und manche Beobachter sind der Meinung, dass es sogar die Anforderungen von Daten-Backup eliminieren könnte. Erasure Coding ist jedoch nicht, wie wir sehen werden, die Lösung für alle RAID-Probleme – RAID wird auch weiterhin seinen Platz in modernen Speichersystemen haben.

RAID-Grundlagen

Um zu verstehen, warum RAID an die Grenzen seiner Leistungsfähigkeit geraten ist, müssen wir genau betrachten, wie RAID-Systeme funktionieren. In einem RAID-System wird ein Teil der Speicherkapazität für Recovery-Zwecke reserviert, wobei Datensicherung durch Datenredundanz geschaffen wird. Zum Beispiel spiegelt ein 1/10-RAID-System einfach die Daten zwischen zwei Platten mit einem effektiven Overhead von 100 Prozent oder 50 Prozent der Kapazität. Es gibt auch eine Reihe von anderen RAID-Verfahren einschließlich RAID 2, RAID 3 und RAID 4, die selten oder gar nicht mehr eingesetzt werden.

Heute wird der größte Teil der Datensicherung über RAID-5- und RAID-6-Konfigurationen erreicht. RAID-5-Systeme speichern redundante Daten in der Form von Parity, berechnet auf der Basis aller Anwendungs- und Host-Daten. Zum Beispiel verfügt eine 3+1-Konfiguration unter RAID 5 über drei Festplatten und eine Parity-Disk. In der Praxis bedeutet das, dass die Daten und die Parity- oder Kontroll-Bits aus Performance-Gründen über alle Platten verteilt sind, aber der Overhead (33 Prozent) und die effektive Kapazität (75 Prozent) bleiben gleich.

Um die Kapazität tatsächlich zu vergrößern, erlauben einige Hersteller große RAID-Gruppen (bis zu 28 Platten). Jedoch erhöht jede Platte, die zu einer RAID-Gruppe hinzugefügt wird, die Gefahr eines Crashs der gesamten RAID-Gruppe. Die Wiederherstellung von Daten in großen RAID-Gruppen zieht auch eine signifikante I/O-Beeinträchtigung nach sich, weil alle Platten gelesen werden müssen, um die ausgefallenen Daten wiederherzustellen. Mit anderen Worten, es besteht ein Missverhältnis zwischen der tatsächlichen Größe einer RAID-Gruppe und dem Overhead bei der Datenredundanz zum Schutz der Informationen.

Einige Hersteller bieten Kapazitäten von Disk-Pools mehrerer RAID-Gruppen an, um die Risiken von Plattenausfällen in einer Gruppe zu mildern. Dies liefert etwas zusätzlichen Schutz, da einzelne Platten in mehreren Gruppen ausfallen können, ohne dass dadurch Probleme entstehen. Aber in diesen Fällen gibt es immer noch den effektiven Overhead an Parity – mehrere RAID-Gruppen mit 3+1 benutzen weiter 25 Prozent der Daten für Parity-Zwecke. Außerdem hat ein zweifacher Plattenausfall in einer Gruppe immer noch Auswirkungen auf den gesamten Pool, da die Daten in diesem Konfigurationsfall aus Performance-Gründen über mehrere RAID-Gruppen verteilt sind.

Datensicherung und Recovery mit RAID

Wenn man Daten in eine RAID-5-Gruppe schreibt, wird eine Datenverteilung (Striping oder Stripe) aufgebaut, einschließlich der Daten- und der Parity-Komponente. Dieser „Stripe“ wird dann auf alle Platten in der RAID-Gruppe als ein „Stripe-Set“ geschrieben. Die Parity-Berechnung beruht auf der XOR-Logik (exclusive OR in der Booleschen Algebra) und wird entweder in Software oder in dedizierten RAID-Controllern vorgenommen. Anschließende Re-Reads der Daten kommen ausschließlich von den Datenteilen des Stripe-Sets, und die Parity-Daten werden nur für Ausfallszenarien genutzt.

Veränderungen von Daten in einem RAID-Stripe gehen einher mit zusätzlichem I/O-Overhead, verglichen mit dem Schreiben von Daten ohne Sicherungsmaßnahmen. Sobald die Daten verändert sind, werden die alten Daten und die Parity-Angaben in einem Stripe gelesen und die Parity wird auf Basis der neuen Daten neu berechnet. Anschließend werden Daten und Parity wieder auf die Platten verteilt. Insgesamt resultiert jeder Schreib-I/O-Vorgang einer Anwendung oder eines Hosts in vier I/O-Operationen auf den Platten – unabhängig von der Größe der RAID-Gruppe.

Innerhalb einer RAID-Gruppe besteht die Ausfall-Domain aus einem einzigen Plattenlaufwerk. Als Platten noch über kleinere Kapazitäten und ein gutes Verhältnis von Kapazität zu IOPS verfügten, war die Wiederherstellung (Rebuild) eines ganzen Plattenlaufwerks unkompliziert und ohne einen bedeutsamen Overhead. Die RAID-Logik las alle guten Datenplatten plus Parity und stornierte die XOR-Parity-Berechnung, um die verloren gegangenen Daten wieder herzustellen.

Mit den wachsenden Kapazitäten der Platten werden jedoch die Recovery-Zeiten zur Achillesferse der RAID-Sicherung. Wenn eine einzelne Platte nur noch 200 Random IOPS liefern kann, wird sich die Wiederherstellung von Platten mit mehreren Terabyte an Kapazität über Tage oder gar Wochen erstrecken. Es sind bereits gruselige Geschichten in Umlauf, die Wiederherstellungszeiten für 10-Terabyte-Platten in der Größenordnung von Monaten voraussagen.

Wiederherstellungszeiten von RAID-Konfigurationen wären kein Problem, wenn es nicht um die besondere Situation einer RAID-Gruppe ginge, in der sich eine ausgefallene Platte befindet. Bei einer RAID-5-Anordnung bedeutet eine einzige ausgefallene Platte, dass die gesamte Datensicherung verloren gegangen ist. Fällt ein weiteres Laufwerk in der gleichen Plattengruppe aus, bevor die erste ausgefallene Platte wieder hergestellt ist, führt dies zu Datenverlust und signifikanter manueller Arbeit, um die Daten des ausgefallenen Geräts zu rekonstruieren.

Von Herstellerseite aus wurde dieses Problem etwas entschärft, indem man Double-Parity-Schutzmechanismen wie RAID 6 anbietet. Eine RAID-6-Gruppe nutzt zwei Parity-Laufwerke pro RAID-Gruppe, so dass sie den Ausfall von zwei Platten tolerieren kann und keinen Datenverlust erleidet. Natürlich zieht dieses Sicherungsniveau einen Overhead bei Kapazität und Performance nach sich. Man spricht in der Industrie bereits über Triple-Parity-Verfahren, aber gegenwärtig sind noch keine Produkte erhältlich.

Abschließend müssen wir das Problem von Unrecoverable Read Error (URE) beim Wiederherstellen von Daten betrachten. Obwohl es nur sehr selten auftritt – Hersteller sprechen bei SATA-Platten von einer Ausfallrate pro 12,5-Terabyte-Schreibzyklus –, ist es möglich, dass eine Platte einen Sektor nicht lesen kann. Bei sehr großen Platten und großen RAID-Gruppen steigt die Wahrscheinlichkeit eines URE. Tritt dieser Fall während eines Parity-Wiederaufbaus ein, können die Daten, die von einem URE betroffen sind, nicht wieder hergestellt werden.

In der Praxis dürfte die Wahrscheinlichkeit eines URE viel geringer ausfallen, als die Hersteller angeben, aber Festplatten sind mechanische Geräte und nicht immun gegen Herstellungsprobleme. Je größer die Systeme mit bis zu tausenden von Platten werden, desto wahrscheinlicher wird man mit dem erwähnten URE-Phänomen zu tun haben.

Wie Erasure Coding funktioniert

Ganz offensichtlich ist Data Protection auf RAID-Basis nicht geeignet für sehr große Platten- und Datenvolumen, wie man sie zum Beispiel bei Object Storage findet. Die Hersteller haben sich stattdessen der Technologie von Erasure Coding zugewendet, als ein Verfahren, das Datensicherung ohne die Skalierungsprobleme von RAID-Systemen bietet. Erasure Coding (manchmal auch als Forward Error Correction bezeichnet) geht in ähnlicher Weise wie RAID vor, indem es zusätzliche redundante Daten als Sicherungsmethode verwendet.

Der Prozess von Erasure Coding trennt zunächst die Ursprungsdaten in Chunks (dt. Haufen) auf. Anschließend kommt eine mathematische Funktion zum Einsatz, um aus den Chunks kleinere Slices oder Shards zu machen. Zum Beispiel kann ein Erasure-Coding-System acht Daten-Chunks erstellen und zehn Slices produzieren, von denen nur acht für die Datenwiederherstellung gebraucht werden. In diesem Fall beträgt der Overhead von Erasure Coding 25 Prozent (= zwei von acht), aber das System kann auch den Verlust von zwei Slices tolerieren: Sind die Daten auf zehn Platten gespeichert, kann ein doppelter Plattenausfall toleriert werden.

Erasure Coding verfügt ferner über den Vorteil, dass die Anzahl der erzeugten Slices und die Anzahl, die für Recovery notwendig ist, leicht verändert werden kann: So lassen sich sogar auf dem gleichen Set von physikalischen Platten viele Datensicherungsprozeduren implementieren. Anders als RAID verbessert Erasure Coding die Effizienz und Zuverlässigkeit, wenn die Datenvolumen und Plattenanzahl anwachsen. Werden Daten über eine größere Anzahl von Platten mit dem gleichen prozentualen Overhead verteilt, bedeutet das, dass der Verlust von mehreren Platten für jeden der Erasure-coded Sets toleriert werden kann. Außerdem können nicht-wiederherstellbare Lesefehler abgemildert werden, da alle ursprünglichen Datenteile neu erzeugt (und bewertet) werden können, indem viele Chunk-Kombinationen benutzt werden.

Diese Vorteile bei der Zuverlässigkeit haben jedoch ihren Preis. Die mathematischen Funktionen, die für Erasure Coding (die meisten von ihnen basieren auf Reed-Solomon-Code) verwendet werden, sind wesentlich rechenintensiver als die traditionelle XOR-Formel von RAID. Dies führt zu einem größeren Prozessor-Overhead, der wiederum erhöhte Host-Latenzen bewirkt. Außerdem verlangen die Anforderungen an die Lese-I/O-Prozesse die Wiederherstellung der Originaldaten der Shards, wobei im Vergleich zu RAID eine andere mathematische Funktion nutzt wird, bei der die Daten nicht nur einfach von der Platte gelesen werden. In einer ähnlichen Weise erfordern die Veränderungen von Daten das Lesen des ganzen Shard-Sets, der die codierten Daten enthält, sowie einen erneuten Erasure-Coding-Prozess und das erneute Schreiben der Daten zurück auf die Festplatte.

Angesichts dieser Arten von Overhead kann man gut verstehen, warum Erasure Coding ursprünglich bei Object Storage angewandt wurde: Bei dieser Technologie ist ein Objekt in der Regel unveränderlich und wird im allgemeinen neu geschrieben als eine neue Version, anstatt die Veränderungen in die alte Fassung einzufügen.

Replikation versus Erasure Coding

Ein Einsatzgebiet, in dem Erasure Coding einen deutlichen Vorteil genießt, findet sich bei Data Protection im Zusammenhang mit Disaster Recovery. RAID-Systeme sichern Daten innerhalb eines einzigen Speicher-Arrays. In diesem Fall müssen sich die Anwender auf entfernte Replikation verlassen, um etwas gegen den Ausfall eines Arrays oder eines Rechenzentrums zu tun.

Replikation ist eine teure Angelegenheit, die zwei identische Datensets erfordert, wobei einer in der Regel selten oder nie verwendet wird. Durch den Einsatz von Erasure Coding können Shards dagegen geographisch verteilt und dazu genutzt werden, etwas gegen den Ausfall eines Rechenzentrums oder einer Appliance zu tun.

Man stelle sich zum Beispiel einen Erasure-Coding-Plan vor, der 12 oder 16 Slices für den Datenzugang vorsieht. Diese 16 Slices könnten über vier Rechenzentren verteilt werden, wodurch der Ausfall eines der Rechenzentren tolerierbar wäre, da keine Informationen verloren gehen. Dieser Grad an Zuverlässigkeit oder Verfügbarkeit wird ohne den Bedarf an zusätzlicher Plattenkapazität erreicht, obwohl man sich daran erinnern sollte, dass die Performance der Verbindungen durch das Lesen von mindestens 12 Slices in Anspruch genommen wird – Latenzprobleme zwischen den Rechenzentren sind deshalb ein Faktor, den man einkalkulieren sollte.

Bedeutet Erasure Coding also das Ende von Backup? Für traditionelle blockbasierte Daten, bei denen sich Veränderungen bei kleinen Blockgrößen (in der Regel 4 KB/8 KB) abspielen, ist Erasure Coding wegen des Overheads, der bei den Erasure-Coding-Algorithmen entsteht, nicht angebracht. Aus diesem Grund implementieren viele Hersteller RAID-Sicherung in ihren Objektspeichern, solange es sich um kleine Objektdaten handelt. Für diese Daten werden noch immer Backup-Prozesse gebraucht.

Bei größeren Objekten jedoch – hier geht es um die meisten der unstrukturierten Daten und Files – liefert Erasure Coding einen zuverlässigen und effizient skalierbaren Sicherungsmechanismus: Wird er zusammen mit Versionsspeicherung (Schutz gegen Datenkorruption oder Löschen) eingerichtet, kann er in vielen Fällen klassisches Backup überflüssig machen.

Wahrscheinlich werden wir eine allmähliche Einführung von Erasure Coding bei gemischten Speicher-Arrays sehen – als eine Sicherungsmethode neben den eigentlichen RAID-Aufgaben. Hinzu kommt eine Systemintelligenz, um die richtige Sicherungsmethode auf der Basis von Anwender-Policies auszuwählen. RAID wird nicht verschwinden, aber zu einer von mehreren Sicherungslösungen in zukünftigen Speichersystemen werden.

Folgen Sie SearchStorage.de auch auf Facebook, Twitter und Google+!

Artikel wurde zuletzt im August 2015 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über Sichere Datenspeicherung

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Mit dem Absenden dieser Daten erklären Sie sich bereit, E-Mails von TechTarget und seinen Partnern zu erhalten. Wenn Ihr Wohnsitz außerhalb der Vereinigten Staaten ist, geben Sie uns hiermit Ihre Erlaubnis, Ihre persönlichen Daten zu übertragen und in den Vereinigten Staaten zu verarbeiten. Datenschutz

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchNetworking.de

SearchEnterpriseSoftware.de

SearchDataCenter.de

Close