In der Arbeit durfte ich in der letzten Zeit mich ein wenig mit den diversen Fake-RAID-Controllern beschäftigen und wie gut diese unter Linux unterstützt sind. Die Ergebnisse sind leider wenig begeisternd.

Die gute Nachricht ist, dass ich mit keiner dieser RAID-Lösungen Probleme hatte Linux auf dem so eingerichteten RAID zu installieren. Die Installationsprogramme von RHEL oder SLES 11 (bis SLES10 war die Philosophie bei SUSE solche RAIDs nur lesend einzubinden) erkannten das im BIOS definierte RAID und benutzten es. Dazu wird der dmraid-Treiber verwendet, der abhängig vom verwendeten RAID-Stack das RAID als Gerät mit Namen „abc_uvwxyz“ definiert, wobei „abc“ für den verwendeten RAID-Stack stehen , also beispielsweise „pdc“ für Promise-basierende RAIDs und „uvwxyz“ einfach eine zufällige Zeichenfolge darstellen.

Damit sind wir aber leider auch schon am Ende der guten Nachrichten. RAID macht man ja aus zwei Gründen:

1. RAID-0 (Striping) um die Plattenperformance zu erhöhen, da abwechselnd auf die im RAID verwendeten Platten geschrieben wird und so der Datendurchsatz steigen kann, denn während die Daten aus dem Cache der einen Platte auf die Scheibe geschrieben werden füllt man bereits den Cache der anderen Platte.
2. RAID-1 (Mirroring) um Ausfallsicherheit zu bekommen. Das Buch „Unix Backup & Recovery“ meint zum Thema Festplatte: „Die Frage ist nicht ob sie ausfallen wird, sondern wann„. Daher hofft man durch das parallele und damit redundante Schreiben der Daten auf zwei (oder mehr) Platten im Fehlerfall die Daten immer noch auf der noch funktionierenden Platte zu haben um so weiterarbeiten zu können.

Genau von diesem RAID-1-Szenario mit zwei Platten ging ich in meinen weiteren Tests aus. Und wie das im Testlabor so ist, wird dann halt auch mal der Fehlerfall simuliert. Ich habe also eine Platte aus dem RAID-Verbund abgeklemmt und die Platte „platt“ gemacht, so wie ich das neulich beschrieben habe. Das RAID ist also dann „degraded“ und wenn man in dieser Konfiguration die Maschine bootet, dann sollte das System trotzdem keine Probleme beim Start haben, denn die Spiegelplatte ist ja noch intakt. Das haben auch alle getesten RAID-Lösungen geschafft.

Im richtigen Leben ist so ein Fehlerfall der Anlass, sich schnellstens eine neue Platte für die gerade ausgefallene zu besorgen, denn meistens richtet man das RAID-1 ja mit zwei identischen Platten irgendwann ein, und wenn eine dann stirbt ist es durchaus nicht unwahrscheinlich, dass auch die andere Platte sich dem Ende ihrer Lebenszeit nähert.

Da ist es nur logisch, dass man die defekte Platte durch eine funktionierende ersetzt und das RAID anweist, die neu hinzugekommene Platte zu befüllen, also das RAID zu „rebuild“en. Genau das habe ich in meinen Tests dann auch versucht.

Und hier kommt die große Ernüchterung. Sowohl RHEL als auch SLES als auch grml (die alle ähnliche Versionen von dmraid nutzen) scheiterten an dieser Aufgabe. Jeder Versuch das RAID mit

zu rebuilden endeten in einem Segfault. Das ist äußerst unschön und daher habe ich auch flugs mal Bugzillas bei Red Hat und SUSE aufgemacht. dmraid wird ja von einem Mitarbeiter bei Red Hat betreut und der hat schon kommentiert, dass ein Rebuild sowieso nur für Intel-basierende Software-Raids (isw_) implementiert ist, aber es nicht sein sollte, dass die Fehlermeldung bei anderen Stacks „segfault“ heißt.

Damit ist der traurige Zustand definiert, dass ein Rebuild des RAIDs nur dann möglich ist, wenn dieser vom BIOS unterstützt ist. Gerade aber der Promise-RAID-basierte Rechner den ich im Fokus hatte bietet das nicht. Eine Rückfrage bei der „Windows-Fraktion“ ergab dann, dass die einen „Storage-Manager“ haben der das im Betriebssystem kann, also minimale Downtime zum Plattenwechseln und dann der Rebuild des RAID im laufenden Betrieb. Der kann zwar dann auch einige Stunden dauern, aber während dieser Zeit ist das System (meist ein billiger Server) einsatzbereit.

In meinem Fall für Linux wäre die Lösung bestenfalls, Images der Partitionen von der „gesunden“ RAID-Platte zu erstellen, dann alles zu löschen und das RAID neu aufzusetzen um dann die Images zurückzuspielen. Das dürfte eine sehr lange Downtime bedeuten und man braucht externe Platten um die Images dort abspeichern zu können.

Aber auch wenn das BIOS das RAID rebuilded bedeutet das, dass man für etliche Stunden einen Fortschrittsbalken im BIOS genießen kann statt mit dem Rechner zu arbeiten.

Das ist auch der Grund warum ich bei solchen Fake RAIDs unter Linux weiterhin die Meinung vertrete, dass man das gar nicht erst anfangen sollte sondern wenn schon, dann das Linux Software RAID zu verwenden, denn das kann alles woran das Fake RAID unter Linux momentan noch scheitert. Wie man das macht ist im Buch „Managing RAID on Linux“ aus dem O’Reilly Verlag beschrieben.

[ratings]