Linux/Software-RAID
ubuntuusers Software-RAID
Dieser Artikel wurde für die folgenden Ubuntu-Versionen getestet:
- Ubuntu 16.04 Xenial Xerus
Artikel für fortgeschrittene Anwender
Dieser Artikel erfordert mehr Erfahrung im Umgang mit Linux und ist daher nur für fortgeschrittene Benutzer gedacht. Zum Verständnis dieses Artikels sind folgende Seiten hilfreich:
- Systeminformationen ermitteln (Abschnitt „Festplatten“)
- Installation von Programmen
- Wie heißen die Datenträger
- Partitionierung
- Ein Terminal öffnen
- Root-Rechte erlangen
- Dateisystem
- mount
- fstab
Inhaltsverzeichnis
Grundsätzliche Informationen Installation Anlegen eines RAID Wartung Begriffe und Details Problembehebung Komplexe Aufgaben Links
Wiki/Icons/hd.png Ein RAID (Redundant Array of Independent Disks) dient dazu, mehrere physikalische Festplatten zu einem oder mehreren logischen Laufwerken zu vereinen und dadurch einen schnelleren Datenzugriff und/oder eine erhöhte Verfügbarkeit des Systems im Falle eines Festplattendefektes zu erreichen.
Native Hardware-RAID-Controller, die unter Linux unterstützt werden (z.B. von 3Ware, Adaptec, etc.), sind aber für den Heimgebrauch oft zu teuer. Diese braucht man aber nicht zwingend, wenn man unter Linux ein Software-RAID verwendet.
Als weitere Alternative können auch sog. FakeRAID-Controller verwendet werden, z.B. Onboard-RAID-Controller. Allerdings wird von dieser Variante im Allgemeinen abgeraten, da beispielsweise oft Kernelmodule (Treiber) fehlen oder diese nur für bestimmte Kernelversionen zur Verfügung stehen.
Dies spricht dann eher für ein Software-Raid, zumal bei modernen, schnellen CPUs die zusätzliche Rechenbelastung für ein Software-RAID kaum eine Rolle spielt.
Der Einsatz der Fake-Raid Variante würde dann Sinn machen, wenn via Dual Boot Linux und Windows auf die gleichen RAID-Partitionen zugreifen sollen.
Außerdem sollte man beachten, dass sowohl Software-Raid als auch Fake-Raid keinen batteriegepufferten Cache besitzen.
Dies kann bei einem Stromausfall zum Datenverlust führen (write hole in den RAID-Leveln 5 und insbesondere 6).
Hardware-RAID-Controller verfügen in der Regel über einen batteriegepufferten Cache (BBU) oder NVRAM, der auch bei einem plötzlichen Stromausfall noch nicht physisch gespeicherte Daten solange vorhält, bis das System wieder gestartet ist.
Software-Raid unter Linux versucht dieses Problem mit einem Journal 🇬🇧 zu lösen (ab Ubuntu 17.10).
Grundsätzliche Informationen
Im Allgemeinen macht es nur Sinn, Partitionen gleicher Größe zu verwenden, die auf unterschiedlichen Festplatten angelegt sind.
Um das komplette System auf einem RAID-Verbund zu installieren, bietet es sich an, das System über die Alternate-CD aufzusetzen.
Die Alternate-CD unterstützt bereits bei der Installation das Erstellen üblicher RAID-Varianten.
Dies findet man unter dem Punkt: "Partitionieren".
Die Alternate-CD ist nur noch bei Lubuntu verfügbar.
Dann kann man auf die Server-CD ausweichen und den gewünschten Desktop nachträglich installieren.
Ubuntu unterstützt von Haus aus die RAID-Varianten 0, 1, 5, 6 und 10. Details zu den einzelnen Typen finden sich im Abschnitt RAID-Level.
Soll von einem neuen RAID-Verbund gebootet werden (Root-Dateisystem), sollte zusätzlich der Abschnitt Bootloader beachtet werden.
RAID und Backup
Ein RAID ersetzt keine Datensicherung! Auch wenn es verlockend scheint, z.B. ein RAID 1 mit externer USB-Festplatte aufzusetzen, um eine automatische Sicherung zu erhalten, ist dies kein Backup:
Das Entfernen der externen Festplatte führt immer dazu, dass sich das RAID im Fehlerzustand (degraded) befindet.
Bei Wiederanschluss muss die interne Festplatte jedesmal komplett neu mit der externen Platte synchronisiert werden.
Ein RAID schützt ausschließlich vor Datenverlust durch Plattendefekte.
Ein Datenverlust, der durch Fehler des Betriebssystems, des Dateisystems, durch die verwendeten Programmen oder den Benutzer entsteht, wird sofort automatisch auf alle Laufwerke synchronisiert, so dass das vermeintliche Backup automatisch mit fehlerhaften Daten überschrieben wird.
IDE/SATA
Generell sollte man bei RAIDs moderne SATA-Festplatten[1] verwenden, da der Datendurchsatz bei diesen zum Teil erheblich höher ist als bei älteren IDE-Platten.
Zudem sind SATA-Platten prinzipiell "hotplugable".
Das heißt, sie sind im laufenden Betrieb eines RAIDs an- und abschaltbar und damit auch austauschbar.
Allerdings sollte man genau wissen, was man tut, bevor man sich an solcherlei Aktionen heranwagt.
Achtung!
Nicht jeder SATA-Controller ist in der Lage, mit "Hotplug" auch richtig umzugehen.
Man sollte auch darauf achten, dass man die richtige Festplatte angibt, um Datenverlust zu vermeiden.
Bei älteren IDE-ATA-Festplatten gilt: die verwendeten Festplatten sollten nicht am selben IDE-Kanal hängen, da im Fehlerfall einer Festplatte unter Umständen der komplette IDE-Kanal gestört wird und dadurch u.U. das RAID nicht mehr nutzbar ist.
Bei einem RAID 0 erhöht sich die Gesamtleistung, da paralleles Lesen/Schreiben auf verschiedenen IDE-Kanälen schneller geht als auf nur einem.
Installation
Folgende Pakete müssen installiert[2] werden, um ein Software-RAID erstellen zu können:
mdadm
parted
Paketliste zum Kopieren:
sudo apt-get install mdadm parted
Oder mit apturl installieren, Link: apt://mdadm,parted Anlegen eines RAID
Partitionierung
Achtung!
Veränderungen an den Festplatten löschen die vorherigen Inhalte der beteiligten Festplatten.
Es ist daher dringend angeraten, vorher eine Datensicherung durchzuführen.
Zunächst müssen die Bezeichnungen der zu verwenden Festplatten bekannt sein[3].
Auf jeder Festplatte wird eine Partition erstellt, die (fast) den gesamten Platz der Platte einnimmt. Im Beispiel wird das Laufwerk /dev/sde[4] vorbereitet.
Die Schritte müssen für jedes Laufwerk, das am RAID teilnehmen soll, mit der entsprechenden Bezeichnung vom eigenen System wiederholt werden:
Eine neue, leere Partitionstabelle auf dem Laufwerk erstellen[5][6]Für neuere PCs mit UEFI Bios:
sudo parted /dev/sde mklabel gpt
Für ältere PCs mit altem Bios:
sudo parted /dev/sde mklabel msdos
Eine einzelne Partition erstellen:
sudo parted -a optimal -- /dev/sde mkpart primary 2048s -8192s
Möchte man die gesamte Platte nutzen, gibt man statt "2048s -8192s" einfach "0% 100%" an.
Die neue Partition als RAID-Partition markieren:
sudo parted /dev/sde set 1 raid on
Hinweis:
Es werden bewusst 8192 Sektoren am Ende der Festplatte ungenutzt gelassen, um für Ausfälle gewappnet zu sein.
Falls nach Jahren keine baugleiche Festplatte mehr beschafft werden kann, ermöglicht es der frei gelassene Platz auch Laufwerke als Ersatz zu nehmen, die einige Sektoren weniger haben.
Am Anfang des Laufwerks werden 2048 Sektoren ungenutzt gelassen, um ein optimales Alignment zu ermöglichen.
Über den Parameter -a optimal kümmert sich parted um weitere Anpassungen, falls nötig.
Es ist auch möglich, die Laufwerke unpartitioniert zusammenzufassen.
Dies birgt jedoch einige Nachteile.
Zunächst verkompliziert es das Alignment und kann damit zu Geschwindigkeitseinbußen führen.
Außerdem kann im Falle eines Defekts nur ein Laufwerk mit genau gleicher oder höherer Sektorzahl als Ersatz benutzt werden.
RAID anlegen
Das Hauptwerkzeug für alle Arbeiten an Software-RAIDs unter Linux ist mdadm.
Es bildet die Schnittstelle zu den RAID-Funktionen des Kernels.
Mehr Informationen finden sich im Abschnitt MDADM. Hiermit werden auch RAID-Verbunde erstellt:
Beispiel 1: RAID 1 über zwei Partitionen, sde1 und sdf1:
sudo mdadm --create /dev/md0 --auto md --level=1 --raid-devices=2 /dev/sde1 /dev/sdf1
Beispiel 2: Software-RAID 5 mit 4 Partitionen:
sudo mdadm --create /dev/md0 --auto md --level=5 --raid-devices=4 /dev/sde1 /dev/sdf1 /dev/sdg1 /dev/sdh1
Die Parameter im Einzelnen:
--create /dev/md0 - Erzeugt ein neues Verbundgerät unter der Bezeichnung md0. Falls bereits Verbundgeräte vorhanden sind, muss ein anderer freier Bezeichner gewählt werden (md1,md2, etc.).
--auto md - Erzeugt ein "klassisches" Verbundgerät ohne Vor-Partitionierung (diese können bei Bedarf ab Kernelversion 2.6.28 trotzdem partitioniert werden).
--level= - Die Art des RAID-Verbundes. RAID 1 im ersten Beispiel, im zweiten RAID 5. Eine Übersicht über die möglichen RAID-Level gibt die Tabelle RAID-Level
--raid-devices - Die Anzahl der Einzelgeräte, aus denen das RAID bestehen soll.
/dev/sde1 /dev/sde2 ... - Die einzelnen Geräte[6], die zusammengefasst werden sollen.
Die Reihenfolge der Bezeichner, bzw. idealerweise die der entsprechenden physischen Geräte sollte man sich aufschreiben, falls im Notfall das RAID von Hand neu zusammengesetzt werden muss.
Die nötigen Initialisierungsmaßnahmen laufen nun selbstständig im Hintergrund ab.
Das neu erstellte Blockgerät md0 kann jedoch sofort benutzt werden und das System darf auch währenddessen normal heruntergefahren oder neu gestartet werden.
Dateisystem
Um den RAID-Verbund als normales Speicherlaufwerk zu nutzen, muss noch ein Dateisystem[7] darauf erstellt und dieses ins System eingebunden werden, z.B. ext4. Im Falle eines RAID 1 ist dies recht einfach:
sudo mkfs.ext4 /dev/md0
Bei komplexeren Verbunden wie RAID 0, 5, 6 oder 10 sollte das Dateisystem auf das RAID angepasst werden, um optimale Leistung zu ermöglichen.
Dafür muss zunächst die sog. "Chunk Size", also die Datenmenge, die in einem einzelnen Schreibvorgang geschrieben wird, bekannt sein.
Diese lässt sich wie folgt ermitteln:
sudo mdadm -D /dev/md0 | grep "Chunk Size"
Bei einem RAID 5 mit Standardeinstellungen liefert dies Beispielsweise:
Chunk Size : 512K
Es werden also 512 KiB Chunks verwendet.
Hieraus können, zusammen mit der Anzahl der Partitionen und des RAID-Levels, die Dateisystem-Parameter berechnet werden.
Am einfachsten geht das mittels des Raid Stride Calculators 🇬🇧.
Alternativ können die Parameter auch von Hand ermittelt werden:
block-size - Die Größe der Dateisystemblöcke in Bytes. Heutzutage werden fast ausschließlich 4096 Byte (4 KiB) Blöcke verwendet.
stride-size - Die Chunk Size umgerechnet in Dateisystemblöcke. Bei 512 KiB Chunk Size mit 4 KiB Blöcken ergibt sich (512 KiB/ 4 KiB) = 128.
stripe-width - Die Größe eines Datenstreifens, also die Menge an Blöcken, die geschrieben wird, wenn ein voller Chunk auf jedes Laufwerk geschrieben wird.
Diese berechnet sich aus (stride-size * Anzahl der effektiv nutzbaren Partitionen).
Bei einem RAID 5 über 4 Partitionen ergibt sich beispielsweise (128 * 3) = 384.
Details zur Anzahl der effektiv nutzbaren Partitionen finden sich im Abschnitt RAID-Level.
Sind die Parameter ermittelt, wird das Dateisystem erstellt:
sudo mkfs.ext4 -b 4096 -E stride=128,stripe-width=384 /dev/md0
RAID mounten
Das RAID muss noch in die Verzeichnisstruktur eingebunden[8] werden.
Dies geschieht einfach mittels mount, z.B. am Mountpunkt /media/daten.
sudo mount /dev/md0 /media/daten
Damit das System beim Start das Dateisystem selber einhängt, muss eine entsprechende Zeile in die Datei /etc/fstab[9] eingetragen werden:
/dev/md0 /media/daten ext4 defaults 0 2
mdadm.conf aktualisieren
Alle Informationen zum RAID werden auf jeder verwendeten Partition in den sog. Superblock geschrieben (auch Metadaten genannt).
Der Kernel sucht beim Starten automatisch nach diesen Superblöcken und startet alle voll funktionsfähigen RAIDs, ohne dass eine Konfigurationsdatei nötig ist.
Trotzdem kann es sinnvoll sein, eine Konfigurationsdatei zu erstellen, z.B. wenn man über Ausfälle am RAID per E-Mail benachrichtigt werden möchte.
Die Konfigurationsdatei kann bequem mit einem Skript von mdadm erstellt werden und enthält dann direkt alle Definitionen aller momentan aktiven RAIDs:
sudo su -c "/usr/share/mdadm/mkconf > /etc/mdadm/mdadm.conf"
Achtung!
Je nach Konfiguration kommt es zu Fehlern in der mdadm.conf.
Daher ist es sinnvoll diese zu überprüfen. Typische Fehler sind, wenn das RAID-System nicht wie im Beispiel als md0 sondern als md127 nach einem Neustart angezeigt wird.
Das System kommt mit der Option "-name" in der mdadm.conf nicht klar.
Diese Option auskommentieren und System neu starten.
Um bei Ausfällen per E-Mail benachrichtigt zu werden, muss in der neuen Datei /etc/mdadm/mdadm.conf die Zeile
MAILADDR root
root durch die gewünschte E-Mail-Adresse ersetzt werden.
Dafür muss der E-Mail-Versand durch das System eingerichtet sein, z.B. via Postfix als Satellitensystem.
Über die Konfigurationsdatei können sehr viele Details der RAIDs angepasst werden.
Nähere Informationen liefert die Manpage von mdadm.conf.
Generell gilt bei neu aufgesetzten RAIDs allerdings: Je weniger, desto besser.
Standardmäßig werden alle wichtigen Informationen (Metadaten) direkt auf den beteiligten Partitionen gespeichert, auch wenn nachträglich Änderungen vorgenommen werden.
Andererseits haben die Parameter aus der mdadm.conf Vorrang.
So ist es z.B. möglich, alle am RAID beteiligten Partitionen in der Datei anzugeben.
Ändert sich jedoch die Reihenfolge der Festplatten (z.B. bei Austausch des Controllers, Umstecken der Kabel, Anschließen eines USB-Sticks etc.) ließe sich das RAID nicht mehr starten.
Auch dann nicht, wenn in den Superblöcken der RAID-Laufwerke die richtigen Metadaten (unabhängig von den Buchstabenbezeichnungen) gespeichert sind.
Dieses Problem lässt sich nur dann beheben, wenn die falschen Angaben in der mdadm.conf korrigiert oder explizit übergangen werden.
Damit die Konfiguration beim Booten verfügbar ist, muss schließlich noch die Initrd aktualisiert werden:
sudo update-initramfs -u -k all
Wartung
Einige der folgenden Punkte kann man man auch mit der GUI der Laufwerksverwaltung palimpsest aus dem Paket gnome-disk-utility machen.
Man geht dort in der linken Spalte auf die gewünschte RAID-Anordnung und kann dann in der rechten Spalte im Punkt "Komponenten bearbeiten" die gewünschten Aktionen veranlassen. RAID überwachen
Eine Kurzzusammenfassung für alle RAIDs erhält man mittels
cat /proc/mdstat
Eine Beispielausgabe eines Systems mit mehreren RAID-Verbünden ohne Ausfälle:
Personalities : [raid6] [raid5] [raid4] [raid1] [linear] [multipath] [raid0] [raid10] md1 : active raid1 sde5[0] sdf5[1]
195114936 blocks super 1.2 [2/2] [UU]
md0 : active raid1 sdf1[1] sde1[0]
242676 blocks super 1.2 [2/2] [UU]
md2 : active raid6 sdg1[4] sdh1[5] sdi1[6] sdj1[7] sda1[0] sdd1[3] sdb1[1] sdc1[2]
2930304000 blocks super 1.2 level 6, 512k chunk, algorithm 2 [8/8] [UUUUUUUU]
Das Beispiel zeigt zwei RAID 1 (md0 und md1) mit je zwei Partitionen und ein RAID 6 (md2) mit 8 Partitionen.
In der jeweils zweiten Zeile wird am Ende in eckigen Klammern der Zustand der einzelnen Partitionen angezeigt, wobei ein U bedeutet, dass das jeweilige Gerät in Ordnung (up) ist.
Ausführliche Informationen zu einem RAID-Device liefert:
sudo mdadm --detail /dev/md0
Hotspare hinzufügen
Ein RAID kann Ersatzplatten vorhalten und diese beim Ausfall einer anderen Festplatte automatisch als Ersatz nutzen.
Solche Platten werden als Hotspares, oft auch einfach nur Spare, bezeichnet.
Um eine Platte als Spare zu nutzen, muss diese zunächst entsprechend partitioniert werden.
Danach kann diese zum Verbund hinzugefügt werden, hier am Beispiel des eingänglichen beschriebenen RAID 5 und einer neuen Partition /dev/sdi1:
mdadm /dev/md0 --add /dev/sdi1
Falls nun eine Partition ausfallen sollte, startet automatisch ein Rebuild, die Spare-Partition wird dabei aktiviert und als Ersatz für die ausgefallene Partition genutzt.
Festplattenausfall
Details ermitteln
Dieses Beispiel zeigt eine ausgefallene Platte in einem RAID 6.
Personalities : [raid6] [raid5] [raid4] [raid1] [linear] [multipath] [raid0] [raid10] md2 : active raid6 sdj1[7] sdi1[6] sdh1[5] sdg1[4] sdd1[3] sda1[0] sdb1[1] sdc1[2]
3418688000 blocks super 1.2 level 6, 512k chunk, algorithm 2 [9/8] [UUUUUUUU_]
unused devices: <none>
In diesem Fall wurde das fehlerhafte Gerät bereits automatisch entfernt.
Genauere Details, u.a. den Namen des defekten Geräts kann mit mdadm ermittelt werden:
sudo mdadm --detail /dev/md2
Festplatte wechseln
Achtung!
Bei einem RAID 0 äußert sich der Ausfall einer Platte im Totalausfall des gesamten RAID-Verbunds.
Das RAID 0 kann daher nicht mit den folgenden Anweisungen repariert werden, sondern muss neu aufgesetzt werden und die hoffentlich vorhandene Datensicherung eingespielt werden.
Ist das defekte Gerät (hier im Beispiel /dev/sdk1) ermittelt, kann die entsprechende Festplatte ausgetauscht werden:
Falls der Kernel das Gerät noch nicht aus dem Verbund entfernt hat (d.h. es wird beim Befehl mdadm --detail noch aufgeführt), muss es zunächst aus dem Verbund entfernt werden:
sudo mdadm /dev/md2 --remove /dev/sdk1
Nun kann die entsprechende Platte gewechselt werden.
Ist eine entsprechende Austauschplatte eingebaut, muss diese zunächst partitioniert werden.
Die neue Partition muss mindestens die gleiche Anzahl an Sektoren aufweisen, wie die bereits genutzten Partitionen.
Von einer bestehenden Platte erhält man die Sektorenzahl der Partitionen (hier am Beispiel von /dev/sda) mittels:
sudo parted /dev/sda u s print
Ist die neue Platte entsprechend partitioniert, wird die neue Partition zum RAID-Verbund hinzugefügt (hier am Beispielaustausch von /dev/sdk1 in /dev/md2):
sudo mdadm /dev/md2 --add /dev/sdk1
Im Hintergrund beginnt nun ein Rebuild, aus den noch vorhandenen Partitionen wird also der Inhalt für die neue Partition berechnet und geschrieben.
Je nach RAID-Level und Größe dauert ein Rebuild mehrere Stunden bis Tage.
Das System darf währenddessen neu gestartet oder heruntergefahren werden.
Ein Systemabsturz kann jedoch zu Datenverlust führen. Manchmal lässt sich der Vorgang beschleunigen.
Hinweis:
Wurden Partitionen einer Platte von verschiedenen RAIDs genutzt, dann kann es vorkommen, dass eine verwendete Festplatte teilweise defekt ist und sich z.B. die Partition von md0 im Status [U_] befindet, während alle anderen im Status [UU] sind.
In diesem Fall müssen diese mit dem Befehl:
mdadm /dev/mdX --fail /dev/sdXY
alle einzeln in den Modus [U_] versetzt werden.
Controller-Fehler
In Einzelfällen kann es vorkommen, dass aufgrund eines defekten Netzteils (oder Controller) ein RAID nicht mehr funktionsfähig ist.
In so einem Fall liegt oft kein Schaden an den Festplatten vor und das Problem kann mit der folgenden Vorgehensweise behoben werden:
RAID stoppen:
sudo mdadm --stop /dev/md0
Das RAID muss manuell wieder zusammengefügt werden, dabei ist es wichtig, die letzte funktionierende Konfiguration zu verwenden.
Bei dem o.g. Beispiel, ein RAID 5 mit 4 Partitionen, bei dem zwei Festplatte wegen Controller-Defekt ausgestiegen sind, müssen die ersten zwei Partitionen verwendet werden, da sie bis zum Ausfall noch zusammen aktiv waren.
Nun reaktiviert man das Arrays mit:
sudo mdadm --assemble /dev/md0 /dev/sde1 /dev/sdf1 --force
.
Die weiteren Partitionen können nun mit:
sudo mdadm --re-add /dev/md0 /dev/sdg1 /dev/sdh1
wieder in den Verbund aufgenommen werden.
RAID erweitern
Falls zum Beispiel der Speicherplatz eines RAIDs nicht mehr ausreicht, kann man es durch weitere Festplatten bzw. Partitionen erweitern.
Dies gilt allerdings nur für ein RAID 1, 5 oder 6. Das RAID darf während des Vorgangs eingebunden sein.
Die neue Partition muss zunächst wie oben beschrieben als Hotspare hinzugefügt werden.
Danach kann das RAID um das neue Laufwerk erweitert werden:
Das RAID neu aufbauen, um somit den neuen Speicherplatz nutzen zu können:
sudo mdadm --grow --raid-devices=5 /dev/md0 --backup-file=/tmp/md0.bak
Die Option raid-devices gibt dabei die Anzahl der Geräte an, aus denen das RAID nach der Erweiterung bestehen soll.
In der mittels backup-file angegebenen Datei werden kritische Bereiche gesichert (typischerweise einige wenige MiB).
Falls das System während der Erweiterung abstürzt, kann die Erweiterung später mittels
sudo mdadm /dev/md0 --continue --backup-file=/tmp/md0.bak
fortgesetzt werden.
Die Sicherungsdatei darf nicht auf dem zu erweiternden RAID liegen!
Die Verwendung von backup-file ist zwar nicht zwingend notwendig, wird aber dringend empfohlen.
Das Dateisystem muss noch erweitert werden, damit der neu entstandene Speicherplatz genutzt werden kann.
Das Dateisystem sollte dabei, wenn möglich, nicht eingehangen sein.
Bei ext-Dateisystemen muss außerdem vorher eine Überprüfung durchgeführt werden.
Am Beispiel von ext4:
sudo umount /dev/md0 # Das Dateisystem aushängen sudo fsck.ext4 -f /dev/md0 # Die Prüfung erzwingen, selbst wenn vor Kurzem geprüft wurde sudo resize2fs /dev/md0 # Das Dateisystem auf Maximalgröße erweitern sudo mount /dev/md0 # Das Dateisystem wieder einhängen
Die mdadm.conf sollte noch auf den aktuellen Stand gebracht werden (evtl. alte Einträge löschen).
Der Status lässt sich wieder jederzeit einsehen.
Begriffe und Details
RAID-Level
Eine Übersicht über die gebräuchlichen und unterstützten RAID-Level.
Bei der Angabe des Speicherplatzes im RAID bezeichnet k die Kapazität je Partition und n die Anzahl der verwendeten Partitionen.
Auswahl von RAID-Typen im Überblick
Typ mind. Partitionen Speicher-
platz Vorteil Bemerkung
0 2 k*n Geschwindigkeit (Lesen & Schreiben), Plattenplatz Keine Partition darf ausfallen, deshalb ein Zweck des RAID nicht erreicht - Reißverschlussverfahren
1 2 k Ausfallsicherheit, Geschwindigkeit (Lesen) Alle bis auf eine Partition dürfen ausfallen - Spiegelung
5 3 k*(n-1) Plattenplatz, Ausfallsicherheit, Geschwindigkeit (Lesen) Eine Partition darf ausfallen - Striping & Parität
6 4 k*(n-2) Plattenplatz, bessere Ausfallsicherheit als RAID 5, Geschwindigkeit (Lesen) Zwei Partitionen dürfen ausfallen - Striping & doppelte Parität
10 4 Sicherheit und gesteigerte Schreib-/Lesegeschwindigkeit. Kombination aus RAID 0 über mehrere RAID 1
RAID unterstützt auch unbenutzte Reservelaufwerke, sog. Hotspares.
Dabei werden vorab Partitionen bekannt gegeben, die beim Ausfall eines Laufwerks innerhalb des RAID-Verbundes durch das Reservelaufwerk automatisch ersetzt werden.
RAID-Zustände
Ein RAID kann sich in unterschiedlichen Zuständen befinden, die seinen Status zusammenfassen:
RAID-Zustände im Überblick Zustand Beschreibung Clean Bezeichnet den Normalzustand. Es liegt kein Fehler vor und alle Prüf- und Initialisierungsaufgaben sind abgeschlossen. Degraded Es liegt ein Ausfall vor. Je nach RAID-Level kann dieser durch Austausch einer Festplatte mit einem anschließenden Rebuild behoben werden um das RAID wieder in den Clean-Zustand zu versetzen. Resync Bei einem Resync werden je nach RAID-Level Sicherungsinformation, z.B. Paritäten, geprüft und ggf. neu erstellt. Ein neu angelegtes RAID befindet sich in der Regel in diesem Zustand. Auch während eines Resync sind die Daten auf dem RAID bereits vor einem Ausfall gesichert. Die volle Lese- und Schreibgeschwindigkeit kann jedoch erst nach Abschluss des Resync erreicht werden. Rebuild Bei einem Rebuild "erholt" sich das RAID von einem Ausfall. Die verlorenen Daten werden aus den Sicherungsinformationen wiederhergestellt und damit das Austauschlaufwerk gefüllt. Ein weiterer Ausfall eines Laufwerks während eines Rebuilds wird in der Regel zu Datenverlust führen.
Resync und Rebuild können je nach Größe und Art des RAIDs mehrere Stunden bis Tage in Anspruch nehmen.
Unter Umständen lassen sich die Vorgänge beschleunigen. Experten-Info:
Da Rebuilds eine intensive Datenträgernutzung bedeuten, passiert es des Öfteren, das sich die noch funktionierende(n) Platte(n) ebenfalls ausfällt(ausfallen).
Bei unternehmenskritischen Daten sollte man bereits beim Kauf der Komponenten auf hohe Qualität achten.
Alignment
Festplatten, RAID-Verbunde und Dateisysteme fassen Daten jeweils für sich in Blöcke zusammen, bevor sie gespeichert werden.
Diese Blöcke haben im Allgemeinen alle unterschiedliche Größen.
Ein Beispiel für das Lesen einer sehr kleinen Datei:
Das Dateisystem möchte einen einzelnen 4 KiB großen Block lesen
Das RAID muss dafür den oder die 512 KiB großen RAID-Blöcke (bei RAIDS oft Chunks genannt) laden, in denen der Dateisystem-Block abgelegt ist.
Die Festplatten müssen dafür wiederum alle 512 Byte großen Blöcke (hier meist Sektoren genannt) laden, die am entsprechenden RAID-Block beteiligt sind.
Im Idealfall muss also das RAID nur einen 512 KiB Block laden und die Festplatten dafür 1024 Blöcke (512 KiB = 512 B * 1024).
Dafür müssen diese geschachtelten Blöcke jedoch aufeinander ausgerichtet sein.
Im schlechtesten Fall könnte ein Dateisystem-Block kurz vor dem Ende eines RAID-Blocks liegen, so dass für einen Dateisystem-Block zwei RAID-Blöcke geladen werden müssen.
Analog könnte ein RAID-Block auch 1025 anstatt 1024 Festplatten-Blöcke belegen, falls er mitten in einem Festplatten-Block anfängt.
Das Lesen eines Dateisystem-Blocks würde damit im schlechtesten Fall das Laden von 2050 Festplatten-Blöcken erfordern.
Dies führt zu dramatischen Performance-Einbußen schon beim Lesen.
Da beim Schreiben oft auch zuerst die vorherigen Daten gelesen werden müssen, sind die Einbußen beim Schreiben noch stärker.
Daher sollte bei der Verwendung von Blockgeräten immer auf das Alignment, also die Ausrichtung der verschiedenen Block-Arten aufeinander, geachtet werden:
Der erste Dateisystem-Block eines RAID-Blocks sollte genau am Anfang des RAID-Blocks beginnen.
Ein RAID-Block sollte genau am Anfang eines Festplatten-Blocks beginnen.
Die Größe der RAID-Blöcke sollte ein ganzzahliges Vielfaches der Dateisystem-Blöcke sein.
Die Größe der RAID-Blöcke sollte ein ganzzahliges Vielfaches der Festplatten-Blöcke sein.
Partitionen sollten auf Sektorgrenzen der Festplatten ausgerichtet sein, wie im Abschnitt Partitionierung beschrieben.
Dem Dateisystem sollten Informationen zum unterliegenden RAID bereitgestellt werden, um seine Blöcke passend auszurichten.
Falls noch weitere Schichten zwischen Dateisystem und Festplatte verwendet werden, z.B. bei Verschlüsselung, muss auch bei diesen auf das Alignment geachtet werden.
MDADM
mdadm ist das Administrator-Werkzeug für alle Arbeiten an Software-RAIDs.
Durch die Angabe eines Schlüsselwortes wird ein bestimmter Modus eingeleitet, der für die ordnungsgemäße Verarbeitung der weiteren Optionen entscheidend ist.
Eine komplette Beschreibung zu Modi und Optionen befindet sich in der Manpage zu mdadm.
mdadm OPTIONEN
Syntax-Übersicht der Modi Nr. Syntax Modus Kurzbeschreibung 1 mdadm --assemble MD-DEVICE OPTIONS DEVICES Assemble Startet ein bestimmtes Array mit den angegebenen Festplatten/Partitionen 1.1 mdadm --assemble --scan MD-DEVICE OPTIONS Startet das angegebene Array; sucht dazu automatisch nach Superblöcken auf allen angeschlossenen Festplatten/Partitionen und verwendet diese, sofern der Array-Name in den gefundenen Metadaten übereinstimmt 1.2 mdadm --assemble --scan OPTIONS Durchsucht alle angeschlossenen Festplatten/Partitionen nach Superblöcken und startet die gefundenen Arrays 2. mdadm --create MD-DEVICE OPTIONS DEVICES Create Anlegen/Definieren eines neues Arrays 3. mdadm --grow MD-DEVICE OPTIONS Grow Vergrößern/Verkleinern eines bestehenden Arrays 4. mdadm --monitor MD-DEVICE OPTIONS DEVICES Monitor Monitoring von einem oder allen md-devices, inkl. Reaktion auf Status-Veränderungen 5. mdadm MD-DEVICE OPTIONS DEVICES Manage Verwaltung eines RAIDs 6. mdadm OPTIONS DEVICES Misc Sonstige Aufgaben Legende: MD-DEVICES[4] beschreibt die RAID-Arrays und DEVICES die am Array teilnehmenden Festplatten/Partitionen[5]
Optionen
Neben dem einzelnen Modus gibt es eine ganze Reihe von Optionen, die unterschiedliche Funktionen bei den einzelnen Modi haben.
Eine komplette Beschreibung zu Modus und Optionen befindet sich in der Manpage zu mdadm.
Auswahl einiger Optionen mit dem zugeordneten Modus, wie er in den Beispielen angewendet wird.
Option Beschreibung gültig bei Modi --add Hinzufügen weiterer Festplatten/Partitionen 1, 6 --backup-file=... Erzeugt eine Backup-Datei - darf nicht im Array liegen 1, 3 --detail Details zu den Arrays ausgeben 6 --fail Status eines Array verändern 5 --force Erzwinge die Ausführung, auch wenn es unsinnig erscheint 1, 2, 6 --help Ausgabe eines generellen Hilfetextes - hinter eine Option gestellt = spezielle Optionshilfe 1, 2, 3, 4, 5, 6 --level=... Bezeichnet den RAID-Typ 1, 2, 3 --query Überprüfen, ob das angegebene Device ein md-Device ist bzw. zu einem Array gehört(e) 6 --raid-device=... Anzahl der aktiven am Array teilnehmenden Festplatten/Partitionen 1, 2 --remove Festplatten/Partitionen die aus dem Array entnommen werden sollen 5 --stop Stoppen eines Arrays 4, 5, 6 --spare-device=... Anzahl der inaktiven (Ersatz-) Festplatten/Partitionen eines Arrays 2, 3 --test Testen der angegebenen Optionen 5, 6 --uuid=... Die UUID des Arrays 1 --verbose Mehr Ausgabe-Informationen erzeugen - kann 2x gesetzt werden 4, 5, 6 --zero-superblock Löschen des RAID-Superblocks 6
Problembehebung
Bootprobleme
GRUB 2: unknown Filesystem
Falls das System nicht bootet, nachdem man es auf ein RAID 1 kopiert, die /etc/fstab[9] angepasst, die grub.cfg und die mdadm.conf korrekt erscheinen sowie das initramfs aktualisiert wurde, kann es helfen, GRUB 2 wie unter GRUB 2/Reparatur (Abschnitt „Root-Directory-Methode“) beschrieben erneut zu installieren.
Dabei muss auf die Art der Partitionstabelle geachtet werden.
Die obige Anleitung nutzt GPT-Partitionstabellen.
RAID startet nicht
mdadm: Cannot open /dev/sdXY: Device or resource busy
Falls beim Erstellen eines RAIDs diese Meldung erscheint und mit den Partitionen bereits einmal ein RAID erstellt wurde, muss zunächst der alte Verbund aufgelöst werden.
Fehler beim Update des Kernels nach Festplattentausch
Grub-Konfigurationsdatei wird generiert … grub-probe: Warnung: Physischer Datenträger »(null)« konnte nicht gefunden werden.
Einige Module könnten im Core-Abbild fehlen.. /usr/sbin/grub-probe: Warnung: Physischer Datenträger »(null)« konnte nicht gefunden werden. Einige Module könnten im Core-Abbild fehlen..
Treten nach dem Tausch einer Festplatte diese Fehler auf muss die Device Map von Grub neu geschrieben werden.
Dies geschieht mit:
sudo grub-mkdevicemap
Geht alles glatt, darf keine Ausgabe erscheinen. Anschließend noch einmal Grub aktualisieren:
sudo update-grub
Nun sollte der Fehler behoben sein und die Grubkonfiguration sich ohne Fehler aktualisieren.
Komplexe Aufgaben
Dieser Abschnitt fasst komplexere Szenarien und Methoden zusammen, die im normalen Betrieb nicht auftreten, aber für Nutzer mit speziellen Anforderungen nützlich sein können.
Resync und Rebuild beschleunigen
Wie eingangs erläutert ermöglicht ein RAID unterbrechungsfreien Zugriff auf die gespeicherten Daten auch während eines Ausfalls.
Daten können also auch während eines Resyncs oder Rebuilds gelesen und geschrieben werden, wenn auch mit verringerter Geschwindigkeit.
Lese- und Schreibzugriffe wirken sich umgekehrt wiederum auf die Geschwindigkeit von Resnyc- und Rebuild-Vorgängen aus.
Die Balance zwischen Lese-/Schreib-Performance und Resync-/Rebuild-Geschwindigkeit kann über zwei (virtuelle) Dateien im proc-System gesteuert werden:
Pfad Standardwert (in KiB/s) Bedeutung /proc/sys/dev/raid/speed_limit_min 1000 Das System wird ggf. Lese- und Schreibzugriffen verlangsamen, falls die Resync-/Rebuild-Geschwindigkeit unter diesen Wert zu fallen droht. /proc/sys/dev/raid/speed_limit_max 200000 Das System wird Rebuild und Resync höchstens mit dieser Geschwindigkeit durchführen und eventuellen Überschuss für Lese-/Schreib-Zugriffe frei halten.
Da der Standard-Maximalwert von knapp 200 MiB/s die Leistung normaler Festplatten (mit Ausnahme von SSDs) übersteigt, wird das System effektiv immer versuchen, Resync und Rebuild so schnell wie möglich zu beenden, falls keine Lese- oder Schreibzugriffe stattfinden.
Falls sich Zugriffe nicht vermeiden lassen (zum Beispiel, wenn das root-Dateisystem auf dem RAID liegt) und Rebuild/Resync trotzdem Vorrang haben sollen, kann die Mindestgeschwindigkeit temporär auf einen praktisch nicht erreichbaren Wert angehoben werden:
sudo su -c "echo 200000 > /proc/sys/dev/raid/speed_limit_min"
Gerade im Fall des root-Dateisystems kann die damit einhergehende verringerte Lese- und Schreibgeschwindigkeit jedoch zu einem instabilem, effektiv nicht mehr nutzbaren System führen.
Änderung an den Standardwerten sind daher mit Vorsicht zu genießen.
Bei einem Neustart werden automatisch die Standardwerte wiederhergestellt.
Um den Wert per Hand zurückzusetzen:
sudo su -c "echo 1000 > /proc/sys/dev/raid/speed_limit_min"
In Einzelfällen kann das Aushängen des Dateisystems (falls möglich) den Vorgang beschleunigen.
Im Regelfall wird dies jedoch keinen Vorteil bringen.
In jedem Fall widerspricht dies natürlich dem Grundgedanken eines RAIDs, die Daten in jedem Fall verfügbar zu halten:
sudo umount /dev/md0
Generell sollte man von diesen Möglichkeiten keine Wunder erwarten.
Resync und Rebuild erfordern im Allgemeinen das komplette Lesen und Neubeschreiben aller beteiligten Laufwerke und können damit maximal so schnell durchgeführt werden, wie es das langsamste, am RAID beteiligte, Laufwerk erlaubt.
Zeiten im Bereich von mehreren Tagen sind bei entsprechender Größe völlig normal.
Wenn man möchte, kann man während der Vorgänge mit watch den Fortschritt kontrollieren:
watch cat /proc/mdstat
Die Anzeige kann mit Strg + C beendet werden.
Wechsel des Betriebssystems
Für den Fall, dass man das Betriebssystem neu aufsetzen muss oder ein zweites Betriebssystem auf dem Rechner installieren will, kann man das Software-RAID weiter verwenden – sofern das Betriebssystem nicht direkt auf dem Software-RAID angelegt ist.
Dazu muss auf dem neuen System das Paket
mdadm
Paketliste zum Kopieren:
sudo apt-get install mdadm
Oder mit apturl installieren, Link:
apt://mdadm
installiert[2] werden.
Spätestens bei einem Neustart sollten bestehenden Arrays automatisch erkannt und gestartet werden.
Falls dies nicht funktioniert, weil z.B. Arrays mit alten Superblock-Versionen vorhanden sind, kann man dies auch per Hand aktivieren:
Achtung!
Auf keinen Fall darf man hier die Optionen "--create" verwenden, da sonst die Lesbarkeit auf den beteiligten Partitionen zerstört wird.
Das RAID nutzbar machen:
RAID aus den gefundenen Superblöcken neu assemblieren:
sudo mdadm --assemble --scan
Hat man mehrere Software-RAIDs und möchte ein bestimmtes RAID zusammenführen, kann man dies durch die Angabe der UUID des entsprechenden RAIDs tun:
sudo mdadm --assemble --scan --uuid=6c926c35:380d7ab2:3603cf0e:ecfa67b9
Durch die Angabe der einzelnen Partitionen:
sudo mdadm --assemble /dev/md0 /dev/sde1 /dev/sdf1 /dev/sdg1
Soll von dem neuen RAID-Verbund gebootet werden (Root-Dateisystem), dann muss noch der Bootloader installiert und das initramfs aktualisiert werden.
Live System
Um auf einen RAID-Verbund mittels einer Live-CD bzw. eines Live-USB zuzugreifen, muss das Programmpaket mdadm mit
sudo apt-get install --no-install-recommends mdadm
installiert werden.
Die Option --no-install-recommends verhindert dabei die Installation des Mail-Server Postfix.
Anschließend werden mit:
sudo mdadm --assemble --scan
alle gefundenen RAID-Verbunde aktiviert.
Mit dem Befehl:
cat /proc/mdstat
kann man dann wieder die gefundenen RAID-Verbunde anzeigen.
Nun wird das RAID noch mit:
mkdir /media/raid mount /dev/md0 /media/raid
in den Verzeichnisbaum integriert.
Jetzt kann man die Daten im Verzeichnis /media/raid lesen (bei Bedarf auch verändern), sowie auf eine externe Festplatte oder in ein Netzwerkverzeichnis kopieren.
Wenn man auf defekte/fehlende Festplatten zugreifen muss, dann schlägt ein --assemble --scan fehl und die Partitionen müssen einzeln assemblieren werden.
Dazu wird z.B. sda1 als Quelle angegeben (bei RAID 0 nicht möglich):
sudo mdadm --assemble --run /dev/md0 /dev/sda1
Dabei bewirkt das --run, dass der Verbund aktiviert wird.
Nach dem Einhängen in den Verzeichnisbaum sollte man auf die Daten zugreifen können.
Weitere Möglichkeiten, z.B. bei der Reparatur des RAID, bieten die Root-Directory-, die Chroot- oder die Setup-Methode.
Kombinierte RAIDs
Wem die oben genannten Möglichkeiten nicht ausreichen, kann auch nach eigenen Anforderungen verschiedenen RAID-Arten kombinieren.
So ist es zum Beispiele möglich, zwei RAID 5 zu spiegeln, also als RAID 1 zu betreiben:
Aus sde1, sdf1 und sdg1 wird ein RAID 5 erstellt
Aus sdh1, sdj1 und sdk1 wird ebenfalls ein RAID 5 erstellt
Aus den beiden RAID 5 wird dann ein RAID 1 erstellt:
sudo mdadm --create --verbose /dev/md0 --level=5 --raid-devices=3 /dev/sde1 /dev/sdf1 /def/sdg1 sudo mdadm --create --verbose /dev/md1 --level=5 --raid-devices=3 /dev/sdh1 /dev/sdj1 /dev/sdk1 sudo mdadm --create --verbose /dev/md2 --level=1 --raid-devices=2 /dev/md0 /dev/md1
Ein solcher Verbund würde als RAID 51 bezeichnet werden, also ein RAID 1 über mehrere RAID 5.
Im Allgemeinen sind solche exotischen Kombinationen zwar selten sinnvoll (je komplexer, desto fehleranfälliger sind Wartung und Reparatur), aber prinzipiell sind beliebige Kombinationen möglich.
Eine sinnvolle Kombination, ein RAID 0 über mehrere RAID 1, also ein RAID 10, wird direkt von mdadm als RAID-Level unterstützt und muss nicht wie hier beschrieben per Hand angelegt werden.
Alternativ verwendet man auch gerne mehrere RAIDs in Zusammenarbeit mit LVM, da dieses einen sehr flexiblen Umgang mit RAID-Verbünden ermöglicht.
Zudem sind dadurch auch sehr große Dateisysteme mit etlichen Terabytes und sogar Petabytes realisierbar.
RAID auflösen
Um den Verbund eines RAID aufzulösen, d.h. die Ressourcen wieder freizugeben, geht man wie folgt vor:
Stoppen des RAID-Verbundes:
sudo umount /dev/md0 sudo mdadm --stop /dev/md0
In der /etc/fstab die aufgelösten RAIDs entfernen.
Mit einem Editor in der mdadm.conf die Array-Angaben löschen.
Den Superblock der entfernten Partitionen löschen, hier am Beispiel von sde1 und sdf1:
sudo mdadm --zero-superblock /dev/sde1 /dev/sdf1
Die Partitions-ID wieder auf normale Linux-ID ändern (bei MBR) beziehungsweise das RAID-Flag der Partition ausschalten (bei GPT).
Auf die vorhandenen Daten kann anschließend nicht mehr zugegriffen werden.
Die Partitionen auf den Festplatten sind aber immernoch vorhanden, solange diese nicht überschrieben werden.
Bootloader
Betreibt man einen RAID-Verbund als Systemlaufwerk, ist es praktisch, wenn das System auch noch nach Ausfall einer Festplatte hochfahren kann.
Das wird z.B. bei ferngewarteten Rechnern benötigt, auf die man keinen direkten Zugriff hat.
Da sich der Bootloader GRUB 2 in der Standardkonfiguration nur auf einem der Laufwerke installiert, muss man etwas nachhelfen.
Dazu installiert man den Bootloader auf allen dem RAID-Verbund angehörenden Laufwerken.
MPT: Installation des Bootloaders in alle MBR aller beteiligten Festplatten (grub-install /dev/sdX), wobei die neu eingerichteten Festplatten anzugegeben sind. Am schnellsten geht es mit dem Befehl:
sudo dpkg-reconfigure grub-pc
und der anschließenden Auswahl der gewünschten Festplatten.
GPT: Der Bootloader muss in die entsprechenden Boot-Partitionen installiert werden. Bei z.B. einer Installation mit GPT & BIOS bricht die Installation von GRUB 2 sonst ab und weist mit einer Fehlermeldung auf die fehlende Partition hin.
grub-installer: /usr/sbin/grub-setup: warn: This GPT partition label has no BIOS Boot Partition; embedding won't be possible!
Damit die Boot-Partitionen durch die initrd auch einwandfrei gemountet werden, sollte nach Änderung die mdadm.conf und initrd aktualisiert werden.
USB und RAID
RAID 0 (stripping) ist denkbar ungeeignet für ein USB-RAID, da bei diesem das Entfernen einer Platte direkt zum Defekt des RAID-Verbunds führt.
Mit RAID 5 und 6 kann es kritisch werden, es sollte aber funktionieren, auch wenn davon stark abzuraten ist.
RAID 1 (mirror) mit mehreren Partitionen auf verschiedenen USB-Festplatten ist prinzipiell kein Problem, auch wenn davon im Allgemeinen abzuraten ist (siehe RAID und Backup).
Wer trotzdem sicher ist, dass in Spezialfällen ein RAID mit USB-Geräten sinnvoll ist, sollte noch folgendes beachten:
Bei USB-Festplatten muss man unterbinden, dass ein Benutzer versucht, diese einzuhängen bzw. dass das System dies am Anfang nicht selbst probiert. Da alle am RAID beteiligten Partitionen die gleiche UUID haben sollten, kann man die /etc/fstab auf diese abstellen und um die Parameter nouser und noauto erweitern.
Raid 1 zu Raid 0 konvertieren
Ausgangssituation:
/dev/md0 ist ein Raid 1 aus /dev/sda1 und /dev/sdb1
Ziel:
/dev/md0 ist ein Raid 0 aus beiden Partitionen
mdadm --grow /dev/md0 -l 0
mdadm: level of /dev/md0 changed to raid0
/dev/sda1 wurde aus dem Raid 1 entfernt
mdadm --zero-superblock /dev/sda1 mdadm --grow /dev/md0 --level=4 --raid-devices=2 --add /dev/sda1 --backup-file=/root/raid.bak
mdadm: level of /dev/md0 changed to raid4 mdadm: added /dev/sda1 mdadm: Need to backup 128K of critical section.. mdadm: /dev/md0: could not set level to raid0
/dev/md0 ist jetzt ein Raid 4 das gesynced wird.
Raid 4 ist hier ein notwendiger Zwischenschritt. Synchronisation abwarten...
Dann Raid 4 zu Raid 0 konvertieren
mdadm --grow /dev/md0 --level=0 --raid-devices=2 --backup-file=/root/raid.bak
Wieder das Reshaping abwarten...
watch mdadm -D /dev/md0
Fertig ist das Raid 0.
Links
Manpages zu mdadm 🇬🇧 und mdadm.conf 🇬🇧
Linux Raid 🇬🇧 - Dokumentation im Wiki von Kernel.org
ausführliches Howto 🇩🇪 Dokumentation zum Einrichten und warten von einem Software-RAID
Quick HOWTO - Linux Software RAID
RAID Stride Calculator 🇬🇧 - Webseite zur Berechnung der Stride-Parameter
Krenn Linux Software-RAID
Linux Software RAID Hauptseite > Server-Software > Linux > Linux Software RAID
Linux Software RAID (häufig auch als mdraid oder MD/RAID bezeichnet) ermöglicht die Nutzung von RAID Funktionalität ohne Hardware RAID Controller.
Die dazu verwendeten Datenträger (Festplatten, SSDs, ...) werden dabei einfach als einzelne Laufwerke am Rechner angeschlossen, etwa direkt an den SATA Ports des Mainboards.
Hardware RAID Controller haben im Gegensatz zu Software RAID meistens einen eingebauten Cache (häufig 512 MB oder 1GB), der mit einer BBU oder ZMCP geschützt werden kann (siehe Unterschiede zwischen Hardware RAID und Linux Software RAID).
Inhaltsverzeichnis
1 Funktionsweise 1.1 SSD RAIDs 2 RAID Superblock 2.1 Superblock Metadaten-Version 0.90 2.2 Superblock Metadaten-Version 1.* 3 RAID erstellen 3.1 Festplatten Cache deaktivieren 3.2 Partitionen vorbereiten 3.3 RAID 1 erstellen 3.4 Alignment überprüfen 3.5 Sync Rate anpassen 4 RAID löschen 5 ATA Trim 6 Einzelnachweise 7 Weitere Informationen
Funktionsweise
Beispiel: Linux Software RAID mit zwei RAID 1 Devices (eines für das Root Dateisystem, ein weiteres für swap.
Linux Software RAID unterstützt die folgenden RAID Level:[1]
RAID 0 RAID 1 RAID 4 RAID 5 RAID 6[2] RAID 10
SSD RAIDs
Linux Software RAID verwendet bis Kernel 3.11 nur einen Thread für RAID5/RAID6 Berechnungen.
Das kann die Performance von SSD RAIDs limitieren.
Im Januar 2013 gab es erste Patches von Fusion-io, diese waren zu diesem Zeitpunkt aber noch nicht reviewed.[3]
Die RAID5 multithreading Unterstützung wurde im Linux Kernel mit 3.12 aufgenommen.
RAID Superblock
Linux Software RAID speichert alle notwendigen Informationen zu einem RAID Array in einem Superblock.
Je nach Metadaten-Version liegt dieser an unterschiedlichen Stellen. Superblock Metadaten-Version 0.90
Der version-0.90 Superblock ist 4.096 Byte groß und liegt in einem 64 KiB aligned block am Ende eines Devices.
Der Superblock beginnt ja nach Devicegröße frühestens 128 KiB vor dem Ende des Devices, bzw. spätestens 64 KiB vor dem Ende des Devices.
Um die Adresse des Superblocks zu berechnen wird die Device-Größe auf ein vielfaches von 64 KiB abgerundet und dann 64 KiB vom Ergebnis abgezogen.[4]
Einschränkungen der Metadaten-Version 0.90:
maximal 28 Devices in einem Array
jedes Device kann maximal 2 TiB groß sein
keine Unterstützung des Bad-Block-Managements[5]
Superblock Metadaten-Version 1.*
Die Position des Superblock hängt von der Version der Metadaten ab:[6]
Version 1.0: Der Superblock liegt am Ende des Devices.
Version 1.1: Der Superblock liegt am Anfang des Devices.
Version 1.2: Der Superblock liegt 4 KiB nach dem Beginn des Devices.
RAID erstellen
Das folgende Beispiel zeigt die Erstellung eines RAID 1.
Im Beispiel wird ein Fedora 15 Live System verwendet.
Festplatten Cache deaktivieren
Wie auch bei Hardware RAID, ist es auch bei Software RAID zu empfehlen den Schreibcache von Festplatten zu deaktivieren, um bei einem Stromausfall keinen Datenverlust zu erleiden.
Ausnahme sind dabei SSDs mit integrierten Kondensatoren, die den Cacheinhalt bei einem Stromausfall noch auf den Flash Speicher schreiben (z.B. Intel DC S3510 Series SSDs).
Partitionen vorbereiten
Das Software RAID wird über /dev/sda1 und /dev/sdb1 gelegt.
Diese Partitionen haben den Typ Linux raid autodetect (fd):
[root@localhost ~]# fdisk -l /dev/sda
Disk /dev/sda: 120.0 GB, 120034123776 bytes 139 heads, 49 sectors/track, 34421 cylinders, total 234441648 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x2d0f2eb3
Device Boot Start End Blocks Id System
/dev/sda1 2048 20973567 10485760 fd Linux raid autodetect
[root@localhost ~]# fdisk -l /dev/sdb
Disk /dev/sdb: 120.0 GB, 120034123776 bytes 139 heads, 49 sectors/track, 34421 cylinders, total 234441648 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0xe69ef1f5
Device Boot Start End Blocks Id System
/dev/sdb1 2048 20973567 10485760 fd Linux raid autodetect [root@localhost ~]#
RAID 1 erstellen
[root@localhost ~]# mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda1 /dev/sdb1 mdadm: Note: this array has metadata at the start and
may not be suitable as a boot device. If you plan to store '/boot' on this device please ensure that your boot-loader understands md/v1.x metadata, or use --metadata=0.90
Continue creating array? y mdadm: Defaulting to version 1.2 metadata mdadm: array /dev/md0 started. [root@localhost ~]#
Der Fortschritt der Initialisierung wird über das proc-Dateisystem oder mdadm abgefragt:
[root@localhost ~]# cat /proc/mdstat Personalities : [raid1] md0 : active raid1 sdb1[1] sda1[0]
10484664 blocks super 1.2 [2/2] [UU]
[========>............] resync = 42.3% (4440832/10484664) finish=0.4min speed=201856K/sec
unused devices: <none>
[root@localhost ~]#
[root@localhost ~]# mdadm -D /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Tue Jul 26 07:49:50 2011
Raid Level : raid1
Array Size : 10484664 (10.00 GiB 10.74 GB)
Used Dev Size : 10484664 (10.00 GiB 10.74 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent
Update Time : Tue Jul 26 07:50:23 2011
State : active, resyncing
Active Devices : 2
Working Devices : 2
Failed Devices : 0 Spare Devices : 0
Rebuild Status : 62% complete
Name : localhost.localdomain:0 (local to host localhost.localdomain)
UUID : 3a8605c3:bf0bc5b3:823c9212:7b935117
Events : 11
Number Major Minor RaidDevice State
0 8 1 0 active sync /dev/sda1
1 8 17 1 active sync /dev/sdb1
[root@localhost ~]#
Alignment überprüfen
Im Beispiel wird die Metadaten-Version 1.2 verwendet.
Die Metadaten liegen also ziemlich am Anfang der Devices, die tatsächlichen Daten dahinter sind aber auf 1 MiB (Data Offset : 2048 sectors, ein Sektor hat 512 Byte) aligned:
[root@localhost ~]# mdadm -E /dev/sda1
/dev/sda1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 3a8605c3:bf0bc5b3:823c9212:7b935117
Name : localhost.localdomain:0 (local to host localhost.localdomain)
Creation Time : Tue Jul 26 07:49:50 2011
Raid Level : raid1
Raid Devices : 2
Avail Dev Size : 20969472 (10.00 GiB 10.74 GB)
Array Size : 20969328 (10.00 GiB 10.74 GB)
Used Dev Size : 20969328 (10.00 GiB 10.74 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
State : active
Device UUID : 10384215:18a75991:4f09b97b:1960b8cd
Update Time : Tue Jul 26 07:50:43 2011
Checksum : ea435554 - correct
Events : 18
Device Role : Active device 0
Array State : AA ('A' == active, '.' == missing)
[root@localhost ~]#
Abhängig von der mdadm Version variiert die Größe des Data Offset:
Hinweis
Data Offset manuell zu spezifizieren (für --create, --grow, allerdings noch nicht für --add): Add --data-offset flag for Create and Grow
Hinweis: Unter Umständen kann es zu Problemen kommen, wenn RAID Arrays mit unterschiedlichen mdadm-Versionen erzeugt werden:
If upon running the above with the --size parameter you get, as one of the authors of this page did, an error such as: "mdadm: /dev/sdb1 is smaller than given size. xxxK < yyyK + metadata", you may have stumbled upon a problem where the array was initially created with an earlier version of mdadm that reserved less device space. The solution seems to be to find an earlier version of mdadm to run with the creation command above (in this author's case, mdadm from Debian "squeeze" worked while mdadm from Debian "wheezy" refused to recreate the array of the required size).[7] Das Problem hierbei ist eine unterschiedlich Größe der Arrays, da frühere mdadm Versionen weniger Speicherplatz reservierten.
ab mdadm-3.2.5: 128 MiB Data Offset (262144 sectors), sofern möglich: super1: fix choice of data_offset. (14.05.2012): While it is nice to set a high data_offset to leave plenty of head room it is much more important to leave enough space to allow of the data of the array. So after we check that sb->size is still available, only reduce the 'reserved', don't increase it. This fixes a bug where --adding a spare fails because it does not have enough space in it. ab mdadm-3.2.4: 128 MiB Data Offset (262144 sectors) super1: leave more space in front of data by default. (04.04.2012): The kernel is growing the ability to avoid the need for a backup file during reshape by being able to change the data offset. For this to be useful we need plenty of free space before the data so the data offset can be reduced. So for v1.1 and v1.2 metadata make the default data_offset much larger. Aim for 128Meg, but keep a power of 2 and don't use more than 0.1% of each device. Don't change v1.0 as that is used when the data_offset is required to be zero.
ab mdadm-3.1.2: 1 MiB Data Offset (2048 sectors) super1: encourage data alignment on 1Meg boundary (03.03.2010): For 1.1 and 1.2 metadata where data_offset is not zero, it is important to align the data_offset to underlying block size. We don't currently have access to the particular device in avail_size so just try to force to a 1Meg boundary. Also default 1.x metadata to 1.2 as documented. (siehe auch Re: Mixing mdadm versions)
Sync Rate anpassen
Ein RAID Volume kann direkt nach der Erstellung schon während der Synchronisation genutzt werden.
Das vermindert aber die Sync Rate.
In diesem Beispiel mit einem RAID 1 direkt über zwei SSDs (ohne Partitionen auf /dev/sda und /dev/sdb) beginnt die Synchronisation mit ca. 200 MB/s und fällt auf 2,5 MB/s zurück sobald Daten auf das Dateisystem des RAID 1 geschrieben werden:
[root@localhost ~]# dd if=/dev/urandom of=/mnt/testfile-1-1G bs=1G count=1 oflag=dsync
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB) copied, 115.365 s, 9.3 MB/s
[root@localhost ~]# cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdb[1] sda[0]
117219728 blocks super 1.2 [2/2] [UU]
[============>........] resync = 63.3% (74208384/117219728) finish=279.5min speed=2564K/sec
unused devices: <none> [root@localhost ~]#
Durch eine manuelle Erhöhung der Sync Rate lässt sich die Synchronisation wieder beschleunigen:[8]
[root@localhost ~]# cat /proc/sys/dev/raid/speed_limit_max 200000 [root@localhost ~]# cat /proc/sys/dev/raid/speed_limit_min 1000 [root@localhost ~]# echo 100000 > /proc/sys/dev/raid/speed_limit_min [root@localhost ~]# cat /proc/mdstat Personalities : [raid1] md0 : active raid1 sdb[1] sda[0]
117219728 blocks super 1.2 [2/2] [UU]
[============>........] resync = 64.2% (75326528/117219728) finish=41.9min speed=16623K/sec
unused devices: <none> [root@localhost ~]# cat /proc/mdstat Personalities : [raid1] md0 : active raid1 sdb[1] sda[0]
117219728 blocks super 1.2 [2/2] [UU]
[=============>.......] resync = 66.3% (77803456/117219728) finish=7.4min speed=88551K/sec
unused devices: <none> [root@localhost ~]# cat /proc/mdstat Personalities : [raid1] md0 : active raid1 sdb[1] sda[0]
117219728 blocks super 1.2 [2/2] [UU]
[=============>.......] resync = 66.4% (77938688/117219728) finish=6.4min speed=101045K/sec
unused devices: <none> [root@localhost ~]#
RAID löschen
Wird ein RAID Volume nicht mehr benötigt, kann es mit dem folgenden Kommando deaktiviert werden:
[root@localhost ~]# mdadm --stop /dev/md0
mdadm: stopped /dev/md0
[root@localhost ~]#
Der Superblock der einzelnen Devices (in diesem Fall /dev/sda1 und /dev/sdb1 vom obigen Beispiel) wird mit folgenden Kommandos gelöscht - damit können Sie diese Partitionen wieder für neue RAID Verbünde nützen.
[root@localhost ~]# mdadm --zero-superblock /dev/sda1
[root@localhost ~]# mdadm --zero-superblock /dev/sdb1
ATA Trim
Im August 2012 hat Shaohua Li ein Patchset eingereicht, das ATA TRIM Support bringt (siehe ATA Trim mit Linux Software RAID).
ATA Trim mit Linux Software RAID ist damit ab Linux Kernel 3.7 möglich.
Ab Linux Kernel 3.17 (bzw. 3.10.57 für Kernel für den longterm 3.10) wird für RAID4/5/6 ATA Trim standardmäßig deaktiviert, weil manche SSDs zwar melden, dass ein ATA Trim Daten zuverlässig löscht und danach bei Lesezugriffen Null als Antwort kommt (discard_zeroes_data) - dies allerdings dann nicht tun.
Ein Modul Parameter erlaubt weiterhin, bei korrekt funktionierenden SSDs Trim zu verwenden.[9]
Ab Linux Kernel 3.19 gibt es eine Whitelist, die zuverlässig funktionierende SSDs auflistet (z.B. alle Intel SSDs bis auf die 520 Serie).[10]
Beim Einsatz solcher SSDs kann der Administrator überlegen, den Modul Parameter zu setzen.
Im Patch wird jedoch ausdrücklich darauf hingewiesen, dass diese Whitelist auf Tests beruht und nicht auf Produktspezifikationen:
This patch whitelists SSDs from a few of the main vendors. None of the whitelists are based on written guarantees. They are purely based on empirical evidence collected from internal and external users that have tested or qualified these drives in RAID deployments.
Im Juli 2015 sind Probleme zwischen dem RAID- und dem SATA-Treiber des Linux Kernels bekannt geworden, die zu Datenverlust beim Einsatz von ATA Trim bei RAID0 oder RAID10 führen können.[11]
Ein Patch, der die bio_split Funktion anpasst, behebt das Problem.[12]
Der Patch wird in Linux Kernel 4.2 einfließen.[13] Einzelnachweise
mdadm (en.wikipedia.org)
ALERT: md/raid6 data corruption risk. (lkml.org, Neil Brown, 18.08.2014)
RAID is more than parity and mirrors Threads für RAID5/RAID6, ca. Min. 25 (Vortrag Neil Brown bei der LCA 2013)
RAID superblock formats - The version-0.90 Superblock Format (Linux Raid Wiki)
Was 3.1 bringt (2): Storage und Dateisysteme: Software-RAID und Device Mapper (heise Open Kernel Log)
RAID superblock formats - Sub-versions of the version-1 superblock (Linux Raid Wiki)
raid Wiki RAID Recovery (raid.wiki.kernel.org)
SSDs vs. md/sync_speed_(min|max) (Lutz Vieweg, linux-raid mailing list, 18.07.2011)
one last-minute update for md/raid5 As we cannot trust 'discard_zeroes_data', ignore it by default and so disallow DISCARD on all raid4/5/6 arrays. As many devices are trustworthy, and as there are benefits to using DISCARD, add a module parameter to over-ride this caution and cause DISCARD to work if discard_zeroes_data is set. If a site want to enable DISCARD on some arrays but not on others they should select DISCARD support at the filesystem level, and set the raid456 module parameter. raid456.devices_handle_discard_safely=Y
ibata: Whitelist SSDs that are known to properly return zeroes after TRIM (git.kernel.org)
Linux: RAID und SSD-TRIM können zu Datenverlust führen (www.admin-magazin.de, 24.07.2015)
block: Do a full clone when splitting discard bios (git.kernel.org, 23.07.2015)
(GIT PULL) Block fixes for 4.2-rc3 Linux Kernel Mailing Lis
Wiki Software-RAID
Software-RAID
Von Software-RAID spricht man, wenn das Zusammenwirken der Festplatten komplett softwareseitig organisiert wird.
Auch der Begriff Host based RAID ist geläufig, da nicht das Speicher-Subsystem, sondern der eigentliche Computer die RAID-Verwaltung durchführt.
Die meisten modernen Betriebssysteme wie FreeBSD, OpenBSD, Apple macOS, HP HP-UX, IBM AIX, Linux, Microsoft Windows ab Windows NT oder SUN Solaris sind dazu in der Lage.
Die einzelnen Festplatten sind in diesem Fall entweder über einfache Festplattencontroller am Computer angeschlossen oder es werden externe Storage-Geräte wie Disk-Arrays von Unternehmen wie EMC, Promise, AXUS, Proware oder Hitachi Data Systems (HDS) an den Computer angeschlossen.
Die Festplatten werden zunächst ohne RAID-Controller als sogenannte JBODs („just a bunch of disks“) in das System integriert, dann wird per Software-RAID (z. B. unter Linux mit dem Programm mdadm) die RAID-Funktionalität realisiert.
Eine besondere Variante des Software RAID sind Dateisysteme mit einer integrierten RAID-Funktionalität.
Ein Beispiel dafür ist das von Sun Microsystems entwickelte RAID-Z.[6]
Pro
Der Vorteil von Software-RAID ist, dass kein spezieller RAID-Controller benötigt wird.
Die Steuerung wird von der RAID-Software erledigt, diese ist entweder schon Teil des Betriebssystems oder wird nachträglich installiert.
Dieser Vorteil kommt besonders bei der Disaster Recovery zum Tragen, wenn der RAID-Controller defekt und nicht mehr verfügbar ist.
Praktisch alle derzeit verfügbaren Software-RAID-Systeme benutzen die Festplatten so, dass diese auch ohne die spezifische Software ausgelesen werden können.
Contra
Bei einem Software-RAID werden bei Festplattenzugriffen neben dem Hauptprozessor des Computers auch die System-Busse wie PCI stärker belastet als bei einem Hardware-RAID.
Bei leistungsschwachen CPUs und Bus-Systemen verringert dies deutlich die Systemleistung; bei leistungsstarken, wenig ausgelasteten Systemen ist dies belanglos.
Storage-Server sind in der Praxis oft nicht voll ausgelastet; auf solchen Systemen können Software-RAID-Implementierungen unter Umständen sogar schneller sein als Hardware-RAIDs.
Ein weiterer Nachteil ist, dass bei vielen Software-RAID kein Cache genutzt werden kann, dessen Inhalt auch nach einem Stromausfall erhalten bleibt, wie es bei Hardware-RAID-Controllern mit einer Battery Backup Unit der Fall ist.
Dieses Problem lässt sich mit einer unterbrechungsfreien Stromversorgung für den gesamten PC vermeiden.
Um die Gefahr von Datenverlusten und Fehlern in der Datenintegrität bei einem Stromausfall oder Systemabsturz zu minimieren, sollten außerdem die (Schreib-)Caches der Festplatten deaktiviert werden.[7]
Da die Platten eines Software-RAIDs prinzipiell auch einzeln angesprochen werden können, besteht bei gespiegelten Festplatten die Gefahr, dass Änderungen nur noch an einer Platte durchgeführt werden – wenn etwa nach einem Betriebssystem-Update die RAID-Software oder der Treiber für einen RAID-Festplatten-Controller nicht mehr funktionieren, eine der gespiegelten Festplatten aber weiterhin über einen generischen SATA-Treiber angesprochen werden kann.
Entsprechende Warnhinweise oder Fehlermeldungen während des Bootens sollten deshalb nicht ignoriert werden, nur weil das System trotzdem funktioniert.
Ausnahmen bilden hier Software-RAID mit Datenintegrität wie z. B. ZFS.
Unvollständige Speichervorgänge werden zurückgesetzt.
Fehlerhafte Spiegeldaten werden erkannt und durch korrekte Spiegeldaten ersetzt.
Es wird wohl beim Lesen eine Fehlermeldung geben, da die fehlerhafte oder alte Spiegelseite nicht mit dem aktuellen Block übereinstimmt.
Software-Raid und Storage-Server
Mit einem Software-RAID-ähnlichen Ansatz lassen sich auch (logische) Volumes, die von unterschiedlichen Storage-Servern zur Verfügung gestellt werden, auf Seite des Anwendungsservers spiegeln.
Das kann in hochverfügbaren Szenarien nützlich sein, weil man damit unabhängig von entsprechender Cluster-Logik in den Storage-Servern ist, welche häufig fehlt, andere Ansätze verfolgt oder herstellerabhängig und somit in gemischten Umgebungen nicht zu gebrauchen ist.
Allerdings muss das Host-Betriebssystem entsprechende Features mitbringen (z. B. durch Einsatz von GlusterFS, des Logical Volume Manager oder von NTFS).
Solche Storage-Server sind üblicherweise in sich schon redundant.
Ein übergreifendes Cluster richtet sich also eher gegen den Ausfall des ganzen Servers oder eines Rechnerraumes (Stromausfall, Wasserschaden, Brand usw.)
Ein einfacher Spiegel, vergleichbar mit RAID 1, reicht hier aus; siehe auch Hauptartikel Storage Area Network.