RAIDs sind heute meist die Basis für Storage Systeme, die als zentrale Bestandteile der IT-Architekturen im Unternehmen eingesetzt werden.
Ursprünglich entstand der Ansatz in den 80er Jahren, um aus einzelnen, preisgünstigen (das “I” stand damals tatsächlich für “inexpensive”) Standard-Festplatten große und performante Speicherbereiche zu generieren, ohne die Verfügbarkeit zu gefährden.
Das Verfahren ist in dieser Zeit Allgemeingut geworden: bei RAID5 z.B. wird die benötigte Paritätsinformation blockweise zyklisch über alle beteiligten Disks verteilt. Die Nettokapazität ist dann um die Kapazität einer einzelnen Platte verringert – dafür darf eben auch eine Disk ausfallen. In diesem Fall wird die defekte Platte getauscht und dann ein Rebuild-Vorgang eingeleitet, der aus den Informationen der übrigen Platten die fehlenden Daten auf der getauschten Platte rekonstruiert.
Während dieses Rebuilds ist natürlich die Performance des RAIDs beeinträchtigt, weil das Array mit sich selbst beschäftigt ist. Und es besteht in dieser Phase natürlich auch keine Redundanz mehr. Die in der Vergangenheit stetig gewachsenen Plattenkapazitäten bedingen natürlich auch, dass der Rebuild-Vorgang entsprechend länger dauert – auch weil die Performance der Festplatten sich nicht ähnlich wie ihre Größe entwickelt hat.
Hier kommt ins Spiel, dass jede Festplatte vom Hersteller mit einer statistischen Fehlerrate für nicht korrigierbare Lesefehler (unrecoverable read error – URE) angegeben wird. Wenn nun ein Rebuild startet, ist die Wahrscheinlichkeit für einen nicht behebbaren Bitfehler abhängig von der Größe der Platten – und somit in den letzten Jahren signifikant größer geworden.
Aus diesem Grund sind seit einigen Jahren statt RAID5- eher RAID6-Verfahren im Einsatz, in denen die Redundanz erhöht wurde (doppelte Paritätsinformation). Aber mit den heute verfügbaren Plattengrößen resultieren auch hier schon mal Wahrscheinlichkeiten für einen Ausfall des RAID-Systems, die höher sind als die für das “Überleben” des RAIDs bei einem Rebuild.
