Festplattenpuzzles

Tipps und Tricks rund um Linux-Software-RAID

Praxis & Tipps | Praxis

Nicht nur Desktop-Linux-Systeme, sondern auch ein Großteil gängiger Netzwerkspeicher können mehrere Festplatten per Software-RAID kombinieren, um die Zuverlässigkeit oder Performance zu verbessern. Vom Wissen, wie man havarierte RAIDs wieder flott bekommt, wo die Tücken des Vergrößerns vorhandener Installationen liegen und wie man fremde RAIDs analysiert, können also durchaus auch Windows- und Mac-Nutzer profitieren.

Das Einrichten eines Software-RAID mit Linux ist denkbar einfach: Die meisten Distributionen bieten es beim Installieren des Betriebssystems gleich an. NAS-Geräte, die sich diese Linux-Funktion zunutze machen, erledigen das ebenfalls ohne Komplikationen bei der Inbetriebnahme. Je nach Menge der Platten bieten sie die üblichen Redundanz- oder Beschleunigungsstufen an, etwa RAID 1, RAID 5 oder RAID 0 beziehungsweise Kombinationen. Mancher NAS-Hersteller denkt sich auch wohlklingende Namen dafür aus, nutzt unter der Oberfläche aber doch nur, was Linux von Haus aus mitbringt.

Vorab eine eindringliche Warnung: Die hier beschriebenen direkten Manipulationen an RAID-Installationen gefährden Ihre Daten, sofern Sie Änderungen an der Konfiguration vornehmen. Das Auslesen der Daten allein schadet nichts. Änderungen sollten Sie nicht ohne sicheres Backup im Schrank ausführen. Und: Wenn Sie unsicher sind, fragen Sie jemanden, der auf der Linux-Kommandozeile sattelfest ist.

Eine nützliche Hilfe kann eine Linux-Recovery-CD sein, entweder die, die zur eingesetzten Distribution gehört, oder ein Generalist wie Grml (siehe c’t-Link). Letzteres hat den Vorteil, dass es beim Start erst auf explizite Aufforderung hin die Platten daraufhin absucht, ob sie womöglich bereits als Software-RAID konfiguriert sind – beim Reparieren kann das ungemein praktisch sein.

Was beim ersten Einrichten eines RAID-Verbunds (RAID-Array) technisch passiert, ist schnell erklärt: Auf allen beteiligten Datenträgern (Festplatten oder Partitionen) landet eine spezielle Kennung, der Superblock. Er beschreibt, welche Rolle der Datenträger innehat (normales Mitglied oder Reserve), zu welchem Verbund er gehört (über eine eindeutige ID) und dessen Typ (RAID 0, 1, 5 …). Der Superblock steht an einer definierten Stelle und ist auf jedem Mitglied nur einmal vorhanden.

Für die Inbetriebnahme eines RAID-Verbunds greift Linux auf die Daten im Superblock zurück. Kriegt es alle Mitglieder zu fassen, setzt es einen neuen Datenträger mit den im Superblock vorgegebenen Eigenschaften zusammen. Er taucht dann als eigenes Blockgerät auf, konkret unter /dev/md0 und so weiter, und lässt sich dann mit einem Dateisystem versehen (formatieren) oder mit dem Logical Volume Manager (LVM) in weitere logische Blockgeräte aufteilen. Auch einige NAS-Systeme unterteilen im RAID zusammengefasste Platten per LVM.

Inventur

Ob ein NAS-Gerät wirklich Linux-Software-RAID benutzt, lässt sich im Betrieb mit wenigen Handgriffen herausfinden. Die meisten erlauben es, dass man sich per Telnet oder SSH darauf verbindet (Telnet ist bei Windows dabei und der beliebteste SSH-Client heißt Putty). Oft ist diese Funktion aber zu aktivieren. Bei Synology heißt sie etwa „Terminal-Dienst“ und unterscheidet die beiden Protokolle.

Wenn Sie per SSH oder Telnet verbunden sind, liefert der Befehl mdadm -Evvs einen Überblick über alle Software-RAID-Verbünde. An den im Bild unten rechts nur teilweise zitierten Ausgaben auf einem älteren NAS-Gerät, in dem zwei Platten stecken, kann man viel erkennen. Der Befehl liest die Daten in den Superblocks angeschlossener Festplatten und gibt sie partitionsweise aus. Die erste Erkenntnis ist, dass diese Daten eine Versionsnummer tragen und dann unterschiedlich dargestellt werden. Bei Version 0.9 folgt eine Tabelle der im Verbund enthaltenen Mitglieder, Version 1.2 nennt nur die Rolle und Position des einzelnen Mitglieds im Verbund (Device Role).

Die ausgegebenen UUIDs sind für ein Linux-System nützlich, um über die Konfigurationsdatei mdadm.conf vorzugeben, welches RAID beim Starten unter welchem Gerätenamen erreichbar sein soll (es geht aber durchaus auch ohne). Sie helfen natürlich auch, verschiedene Mitglieder einem RAID-Verbund zuzuordnen, wenn man es mit nackten Platten aus mehreren RAIDs zu tun bekommt und sie sortieren muss. Apropos sortieren: Hilfreich dabei ist es, nicht nur die Namen im Linux-Gerätebaum zu kennen (/dev/sda, /dev/sdb …), sondern den Namen auch konkrete Platten zuzuordnen.

Dabei helfen die Programme smartctl oder hdparm. Mit dem Parameter -i und einem Gerätenamen aufgerufen (smartctl -i /dev/sda oder hdparm -i /dev/sda) liefern sie die Seriennummer der Platte, die meist auch auf dem Etikett steht. Auf diese Weise können Sie Platten, Partitionen und RAID-Verbundgeräte inklusive der Position (RaidDevice in Version 0.9, DeviceRole in Version 1.x des Superblocks) eindeutig einander zuordnen.

Die Position kann wichtig sein, wenn auf einem Mitglied im Verbund der Superblock verloren geht. Kennt man die Position der übrigen Geräte, kann man die Superblöcke neu schreiben und das RAID so wieder flottmachen. Die übrigen Informationen sprechen für sich selbst: Größe, Anzahl der Geräte, Zustand et cetera.

Wer schlau ist, bringt die von mdadm -Evvs ausgegebenen Daten sowie die per smartctl -i für jede Festplatte ermittelten Informationen in Sicherheit, solange alles in Ordnung ist. Bei einer RAID-Havarie hat man so alle Informationen beieinander, die im Notfall weiterhelfen könnten. Auch lassen sich damit gezielt ausgefallene Platten lokalisieren. Nichts ist ärgerlicher als bei einem ohnehin schon geschwächten RAID auch noch die falsche Platte zu entfernen …

Versionsfallen

Die unterschiedlichen Superblock-Versionen erfüllen einen konkreten Zweck: Version 0.9 (auch als 00.90.01 anzutreffen) war der erste Ansatz, diese Daten anzulegen. Ältere Boot-Loader wie LILO können nur von einem RAID-Verbund booten, wenn er in dieser Version angelegt ist. Die automatische Erkennung von RAID-Geräten im Linux-Kernel, die dann aktiv ist, wenn RAID nicht als Modul geladen, sondern integriert ist, findet nur RAID-Geräte mit Superblocks dieser Version; sie müssen zudem als Partitionstyp 0xfd verwenden. Heute spielt das kaum noch eine Rolle, die meisten Distributionen erledigen das Zusammenbauen von RAID-Geräten während des Systemstarts.

Die Wahrscheinlichkeit, dass ein mehrere Jahre altes RAID mit der Version 0.9 angelegt wurde, ist groß. Auf lange Sicht hat das Nachteile: Bis Kernel 3.0 konnten die einzelnen RAID-Mitglieder nicht größer als 2 TByte sein, seit Kernel 3.2 maximal 4 TByte. Die Felder im Superblock waren nicht hinreichend dimensioniert. Mit Version 1 hat Neil Brown, der Entwickler des Software-RAID im Linux-Kernel, die praktischen Beschränkungen aufgehoben, indem er 64 Bit große Felder zur Beschreibung nutzt und die Anzahl der Geräte pro RAID-Verbund deutlich erhöht hat.

Allerdings gibt es drei Varianten des Version-1-Superblocks, die sich darin unterscheiden, wo die Daten auf dem Mitglied liegen: bei 1.0 am Ende, wo auch Version 0.9 zu liegen kommt, bei 1.1 am Anfang und bei 1.2 mit 4 KByte Abstand zum Anfang. Ein Aktualisieren der Superblock-Daten von einem älteren in ein neues Format, um überhaupt größere Mitglieder in ein RAID einfügen zu können, gelingt lediglich von Version 0.9 auf 1.0. Ein Update auf 1.1 oder 1.2 würde Nutzdaten überschreiben, ohne Vorteile zu versprechen.

Die Wörter Aktualisieren und Updaten schmeicheln allerdings der Art und Weise, wie man einen bestehenden RAID-Verbund mit Superblock zu Fuß von Version 0.9 auf 1.0 umstellt – eine Verbalform von Kneifzange würde dem Vorhaben eher gerecht. Das Folgende führt das am Beispiel eines RAID 1 mit zwei 400-GByte-Platten mit je einer Partition (/dev/sdb1 und /dev/sdc1) vor, die durch zwei 3 TByte große, analog partitionierte Exemplare ersetzt werden sollen.

Die folgenden Schritte gehen davon aus, dass das behandelte RAID nicht in Benutzung ist. Im Idealfall läuft nur die Wiederherstellungsumgebung der Distribution oder Grml. Für NAS-Nutzer kommt die gezeigte Behandlung eher nicht in Frage. Wenn deren Firmware nicht von sich aus geeignete Superblock-Versionen schreibt, kann man das auch nicht aus einer Wiederherstellungsumgebung heraus empfehlen, an die man die Platten aus dem NAS anklemmt.

RAID 1 groß machen

Zuerst prüfen Sie, ob der zu vergrößernde RAID-1-Verbund im Normalzustand ist. Der Befehl cat /proc/mdstat sollte

Personalities : [raid1] 
md0 : active raid1 sdb1[0] sdc1[1]
      390708736 blocks [2/2] [UU]

ausgeben. Entscheidend ist, dass in dem RAID 1 zwei Mitglieder aktiv sind (sdb1 und sdc1) und zwei U in eckigen Klammern stehen, also beide Mitglieder aktiv sind. Mit mdadm - -detail /dev/md0 sehen Sie mehr Details, unter anderem, dass die Version des Superblocks 0.90 ist. Sie können jetzt ein Mitglied als defekt markieren und aus dem Verbund entfernen:

mdadm --fail /dev/md0 /dev/sdc1
mdadm --remove /dev/md0 /dev/sdc1

Nun fahren Sie das System herunter, bauen die Platte, die zu sdc1 gehört, aus und die erste größere, neue Platte ein. Die alte Platte heben Sie als Faustpfand auf, falls das andere RAID-Mitglied bei der Umstellung Schaden nimmt. Nach dem Booten sollte das RAID weiterhin aktiv sein, allerdings nur noch aus einer Platte bestehen:

md0 : active (auto-read-only) raid1 sdb1[0]
      390708736 blocks [2/1] [U_]

Jetzt ist ein guter Zeitpunkt, um das Format des Superblocks von Version 0.9 auf 1.0 zu ändern. Zunächst lassen Sie sich die Konfigurationsdetails anzeigen:

mdadm --detail /dev/md0

Besonders wichtig sind die ausgegebenen Daten, wenn Sie mit einem RAID-5-Gerät hantieren – zu den Besonderheiten später. Zurück zum einfacheren RAID-1-Beispiel. Zuerst halten Sie das RAID-Device an:

mdadm --stop /dev/md0

und lassen mdadm anschließend einen neuen Superblock erstellen. Der muss exakt dem entsprechen, der zuvor bestanden hat.

mdadm --create /dev/md0 -l1 -n2 --metadata=1.0 ⤦
 --assume-clean /dev/sdb1 missing

Der Parameter - -assume-clean hindert das System daran, Schreibzugriffe auf die RAID-Mitglieder loszulassen – das wäre bei einem herkömmlichen Aufruf von mdadm der Fall, weil es das Synchronisieren der beteiligten Platten anstößt. Hier soll ja nur der Superblock aktualisiert werden. Mit einem weiteren

mdadm --detail /dev/md0

können Sie prüfen, ob das Neuschreiben des Superblocks geklappt und sich die Versionsnummer passend geändert hat. Sie sollten sich von den Unterschieden von Version 0.9 auf Version 1 in der Ausgabe des Kommandos nicht ins Boxhorn jagen lassen. Der --create-Aufruf hat den RAID-Verbund wieder aktiv geschaltet.

Die Änderung wirkt zunächst nur auf die alte Platte im RAID-Verbund. Durch das Neuschreiben des Superblocks ändert sich dessen UUID. Wenn Sie diese eindeutige Nummer in der Konfigurationsdatei mdadm.conf verwenden, müssen Sie die Datei anpassen.

Die bereits entfernte alte Platte und die noch aktive verlieren durch die UUID-Änderung den Draht zueinander. Wenn man sie wieder nebeneinander in ein System einbaut, würden sie von den gängigen Distributionen jeweils als eigener RAID-Verbund erkannt, dem jeweils ein Mitglied fehlt.

Erst partitionieren …

Die neu eingebaute, größere Platte müssen Sie zunächst partitionieren. Jenseits von 2 TByte scheitern die klassischen Werkzeuge wie fdisk. Es bedarf neuerer, die das erweiterte Partitionsschema GPT beherrschen. Unter der Voraussetzung, dass die neue Platte als /dev/sdc im System hängt, geht das zum Beispiel mit einem Aufruf von parted /dev/sdc und den folgenden Befehlseingaben:

mklabel gpt
unit TB
mkpart primary 0% 100%
print
quit

Die Befehle schreiben leere Partitionstabellen auf die Platte, legen eine primäre Partition mit maximaler Größe der Platte an und geben die neue Partitionstabelle vor dem Beenden zur Kontrolle aus.

Jetzt können Sie die neue Platte in den RAID-Verbund integrieren:

mdadm --manage /dev/md0 --add /dev/sdc

Das System beginnt sogleich, die Daten vom vorhandenen RAID-Mitglied auf das neue zu übertragen. Den Fortgang dieser Operationen können Sie mit cat /proc/mdstat verfolgen:

Personalities : [raid1] 
md0 : active raid1 sdb1[2] sdc1[0]
      390708736 blocks [2/1] [U_]
      [=======>.............]  recovery = 37.7% ⤦
 (147315648/390708736) finish=100.1min ⤦
 speed=40512K/sec

Ist die Synchronisation abgeschlossen, liefert cat /proc/mdstat wieder die gleiche Ansicht wie zu Beginn:

Personalities : [raid1] 
md0 : active raid1 sdb1[0] sdc1[1]
      390708736 blocks [2/2] [UU]

Um auch die zweite Platte auszutauschen, wiederholen Sie die Schritte, die Sie für /dev/sdc ausgeführt haben mit /dev/sdb. Sie entfernen /dev/sdb1 aus dem RAID, ersetzen die Festplatte durch die neue, partitionieren sie, fügen sie dem RAID hinzu und warten die Synchronisation ab. Vorsicht: In diesem zweiten Durchlauf arbeiten Sie mit dem Gerätenamen für die andere Platte, also nicht mit sdc, sondern sdb! Kontrollieren Sie aber, ob sich durch den Neustart nicht womöglich Plattennamen geändert haben.

… dann aufblasen

Wenn auch dieser Teil der Operation abgeschlossen ist, können Sie den RAID-Verbund auf die maximale Größe aufblasen:

mdadm --grow /dev/md0 --size=max

Wenn Sie es versäumt haben, den Superblock in Version 1 zu überführen, lehnt mdadm dieses Ansinnen jetzt idealerweise ab. Die in Debian Squeeze enthaltene Version (und auch die anderer Linux-Distributionen) tut das leider nicht. Sie ändert die Größe, liefert aber anschließend negative Angaben für die „Used Dev Size“, wenn Sie mit mdadm - -examine /dev/sdb1 die Details für ein Mitglied anzeigen lassen. Auch mdadm - -detail /dev/md0 gibt dann negative Werte zum Besten.

Es sind diverse Fälle überliefert, in denen die Nutzung solcher RAID-Verbünde für massive Datenverluste gesorgt hat. Deswegen: Wenn Sie versäumt haben, die Version des Superblocks zu korrigieren, sollten Sie es jetzt nicht mehr tun. Starten Sie den Prozess mit dem verbliebenen RAID-Mitglied, also der zur Seite gelegten alten Platte von vorn.

Apropos Nutzung: Das Vergrößern des RAID-Verbunds allein reicht natürlich nicht. Ein direkt darauf angelegtes Linux-Dateisystem lässt sich mit den passenden Werkzeugen an die neuen Größenverhältnisse anpassen, die ext-Familie etwa mit resize2fs. Steht der Platz unter der Obhut von LVM, genügt pvresize /dev/md0, um das Physical Volume auf die Kapazität des darunterliegenden (RAID-)Geräts zu vergrößern und anschließend für Logical Volumes zu nutzen.

Das Vorurteil, dass besonders Fernost-NAS-Ware womöglich über die Versionsunterschiede des Superblocks in Probleme mit großen Platten gerät, ließ sich in Stichproben auf verschiedenen Modellen nicht bestätigen. Dennoch kann ein misstrauischer Blick auf die Kompatibilitätslisten und auch über den eingangs erwähnten Zugang zu einem laufenden System nicht schaden. Das hier geschilderte Vergrößern zu Fuß können sich NAS-Nutzer sparen. Den Part übernimmt die Firmware – Näheres sollte in der Dokumentation stehen.

Das grundsätzliche Vorgehen bei anderen RAID-Spielarten ist identisch. Dabei kann allerdings das Zusammensetzen des mdadm - -create-Aufrufs deutlich schwieriger sein, weil es dabei auf die Reihenfolge ankommt, in der Sie die einzelnen Mitglieder aufführen. Das dazu nötige Wissen ist nicht nur beim Vergrößern nützlich, sondern auch dann, wenn man Platten eines zerbröselten NAS wieder zu einem ansprechbaren Verbund zusammenbringen will oder Superblöcke in einem Anfall von Übermut gehimmelt hat.

Superblockpuzzle

Um Platten aus einem RAID-Verbund auf den Zahn zu fühlen, über den nichts oder nur wenig bekannt ist (für den letztlich versäumt wurde, die Ausgaben von mdadm -Evvs zu sichern), empfiehlt sich folgendes Vorgehen: Hängen Sie die Festplatten einzeln an ein Linux-(Rettungs-)System und untersuchen Sie diese mit dem Befehl mdadm -Evvs /dev/sdc; /dev/sdc ist das Gerät, unter dem die jeweilige Platte sichtbar ist.

Das einzelne Anhängen ist zwar mühsam, verhindert aber bei komplexeren RAID-Leveln, dass das verwendete Linux-System einen womöglich unvollständigen Verbund eigenmächtig startet, im schlimmsten Fall einen unerwünschten Resync anstößt und die Daten dadurch vernichtet. Erst wenn Sie sicher sind, dass auf allen beteiligten Platten plausible Informationen im Superblock stehen, können Sie den Verbund weitgehend gefahrlos im Ganzen anschließen und Linux starten.

Der zum Starten eines vollständigen RAID-Verbunds nötige Befehl mdadm - -assemble erwartet die Gerätenamen der Mitglieder als Parameter. Die Reihenfolge spielt auch bei RAID 5 keine Rolle. Das RAID-System orientiert sich an den Daten im Superblock. Anders ist das allerdings, wenn Sie den Superblock für ein Update von Version 0.9 auf 1.0 neu schreiben wollen. Dann müssen Sie die Mitglieder exakt in der Reihenfolge angeben, in der sie auch beim Erstellen des Verbunds angegeben worden sind.

Beispiel: Sie haben die drei Platten eines RAID-5-Verbunds nacheinander einzeln angeschlossen und mit mdadm -Evvs analysiert. Alle Platten enthalten eine primäre Partition vom Typ 0xfd und Superblöcke der Version 0.9. Auf Platte A ist RaidDevice Nummer 2, auf Platte B RaidDevice 1 und auf Platte C findet sich RaidDevice 0.

Wenn Sie die Platte A als /dev/sda, Platte B als /dev/sdb und Platte C als /dev/sdc anschließen, sollte nach dem Stoppen des RAID-Verbunds mit

mdadm --stop /dev/md0

der Befehl

mdadm --create /dev/md0 -l5 -n3 -c64 --layout=la ⤦
 --metadata=1.0 --assume-clean /dev/sdc1 /dev/sdb1 
 /dev/sda1

auf allen Platten gleich das neue Superblock-Format in Version 1 schreiben und den Verbund starten.

Entscheidend ist, dass auch die übrigen Parameter passen: -l5 für RAID 5, -n3 für drei Geräte im Verbund, -c64 für die Chunksize und --layout=la für die Verteilung der Daten auf den Mitgliedern, hier left-asymmetric. Diese Informationen liefern die Aufrufe von mdadm -Evvs für die Mitglieder zurück. Die Option - -assume-clean sorgt dafür, dass kein Rebuild- oder Resync-Lauf auf dem Verbund startet. Durch das Neuerstellen des Superblocks auf allen Mitgliedern ändert sich die UUID des RAID-Verbunds.

Auf die gleiche Art kann man auch die Superblöcke neu schreiben, wenn diese für mehrere RAID-Mitglieder verloren gegangen sind. Für die Grundparameter genügt ein erhaltener Superblock. Für die Reihenfolge muss man experimentieren. Durch das Setzen einer Option im Sys-Dateisystem können Sie das RAID-Subsystem daran hindern, einen Resync- oder Recovery-Prozess anzustoßen:

echo 1 > /sys/module/md_mod/parameters/start_ro 

Nach jedem Aufruf von mdadm - -create mit einer Versuchsreihenfolge der Gerätenamen der potenziellen Mitglieder müssen Sie dann prüfen, ob die Daten auf dem gestarteten RAID-Verbund sichtbar sind. Zugriffe dürfen dabei nur lesend erfolgen. Sobald ein Prozess auf den RAID-Verbund schreibt, löst das die zuvor per Sys-Dateisystem gesetzte Schreibsperre für das RAID-Subsystem.

Ganz harte Nüsse knackt übrigens der Linux-Software-RAID-Entwickler Neil Brown höchstselbst immer mal wieder auf der Mailingliste. Sein Support geht so weit, dass er schon mal Patches für den mdadm-Code veröffentlicht, die ein spezielles Problem lösen helfen. Um keinen falschen Eindruck entstehen zu lassen: Das Software-RAID-Subsystem ist sehr robust. Normalerweise geht es ohne solche Tricks. (ps)

Literatur
  1. [1] Thorsten Leemhuis, Geschickt verpackt, Festplatten unter Linux zu einem RAID verbinden, c’t 22/08, S. 184
  2. [2] Mirko Dölle, Plattenbau, Software-RAIDs unter Linux einrichten, c’t 1/09, S. 188

Artikel kostenlos herunterladen

weiterführende Links

Anzeige
Anzeige