RAID-Technologie verspricht höhere Performance und mehr Sicherheit beim permanenten Speichern von Daten. Die ADMIN-Redaktion gibt einen Überblick über ... (mehr)

RAID 5

RAID 5 übernimmt die blockweise Datenablage von RAID 4, verteilt aber die Paritätsinformationen über alle Platten, statt sie auf einer zu konzentrieren. Dadurch werden auch die Schreibzugriffe verteilt und parallelisiert und der Bottleneck einer Paritätsdisk vermieden. Allerdings erfordert RAID 5 zwei Lese- und zwei Schreiboperationen pro Schreibanforderung, was die Schreibperformance zwangsläufig bremst.

Abbildung 2 zeigt den schematischen Aufbau eines RAID-5-Verbunds. Die Daten sind darin in sogenannten Stripes abgelegt. Das sind aufeinander folgende Segmente auf verschiedenen physischen Datenträgern (Disks). Jeder Stripe zieht sich über alle 4 Platten. Die Segmente mit weißem Hintergrund enthalten die eigentlichen Daten, die Segmente mit gelbem Hintergrund die Paritätsinformationen. Zu sehen ist, dass die Paritätsdaten wie beschrieben gleichmäßig über alle Laufwerke verteilt sind.

Abbildung 2: Schema eines RAID-5-Verbundes. Die gelben Felder enthalten die Paritätsinformationen, die sich durch XOR-Verknüpfung der anderen Segmente des Stripe ergeben.

Die Paritätsdaten errechnen sich aus den Nutzdaten durch eine sogenannte XOR-Verknüpfung (Exklusive OR, auch Antivalenz genannt). Die XOR-Funktion verknüpft zwei Werte derart, dass sich eine logische 1 ergibt, wenn die Eingangsgrößen verschieden waren. 0 XOR 1 = 1; 0 XOR 0 = 0; 1 XOR 1 = 0; 1 XOR 0 = 1. Die Nutzdaten aller Segmente eines Stripes werden nun nacheinander bitweise XOR-verknüpft. Beispielsweise ergibt sich in der zweiten Zeile des Schemas in der Grafik: 0010 XOR 0000 ergibt 0010 und 0010 XOR 0100 ergibt 0110. Das ist der Wert im gelb hinterlegten Segment am Schnittpunkt Stripe 2/Drive 3. Entsprechendes gilt für die anderen Stripes im Beispiel.

Fällt nun eine Platte aus, dann lassen sich die fehlenden Daten durch XOR-Verknüpfung der übrig gebliebenen errechnen (Rebuild), wenn mindestens drei Platten pro Stripe im Spiel waren. Nehmen wir beispielsweise an, dass auf Drive 2 nicht mehr zugegriffen werden kann. Dann rechnet der RAID-Controller für Stripe 2: 0010 XOR 0110 (Drive 1 und Drive 3) – das Ergebnis ist 0100. Dieser Wert 0100 XOR 0100 von Drive 4 ergibt 0000. Damit ist klar, dass im fehlenden Segment des ausgefallenen Drive 2 der Wert 0000 hinterlegt gewesen sein muss. Das ist auch tatsächlich der Fall, wie ein Blick auf die Grafik zeigt. Entsprechend lässt sich in jedem Stripe jedes Segment durch XOR-Verknüpfung der anderen Segmente des Stripe auf einfache Weise berechnen. Fällt mehr als eine Platte aus, funktioniert das Spiel allerdings nicht mehr – dann sind alle Daten aller Stripes unwiederbringlich verloren.

RAID und Risiko

Der Betrieb mit einer ausgefallenen Platte (Status »degraded« ) oder während der Wiederherstellung der Inhalte eines zuvor ausgefallenen Laufwerks (Status »rebuild« ) ist bei den klassischen RAID-Leveln 3 bis 5, die auf der beschriebenen Paritätsberechnung beruhen, aber auch bei einer Spiegelung besonders kritisch. Fällt jetzt eine weitere Platte aus, oder ist auch nur ein einziger Sektor auf den verbliebenen Platten unleserlich, sind alle Daten verloren.

Aber wie wahrscheinlich ist es, dass gerade in dieser sensiblen Zeit ein weiterer Schaden eintritt? Das kann man ausrechnen. Ein einfacher Ansatz geht davon aus, dass in die gesuchte Mean Time To Data Loss (MTTDL) die Gesamtzahl der Festplatten, ihre durchschnittliche Betriebsdauer bis zu einem Fehler (Mean Time To Failure, MTTL) und die Dauer des Wiederherstellungsprozesses einhergehen. Die Formel dafür ist noch gut überschaubar (und solche Berechnungen stellten bereits die RAID-Erfinder in [1] an), sie hat aber einen Schönheitsfehler: Sie geht nämlich von der Annahme aus, dass die Festplattenausfälle voneinander unabhängig sind. So kommt man zu recht hohen MTTDL-Werten, die auf den ersten Blick beruhigend wirken. Praktisch sind diese Voraussetzungen aber meistens nicht gegeben: In der Regel stammen alle Platten aus einer Produktionscharge, waren denselben Umweltbedingungen ausgesetzt, altern auf ähnliche Weise und so weiter. Außerdem erhöht sich die Ausfallwahrscheinlichkeit mit der Betriebsdauer. Im Ergebnis sinkt die MTTF nach jedem Ausfall, das heißt, ein weiterer Ausfall nach dem ersten ist damit um ein Vielfaches wahrscheinlicher.

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023