Category Archives: Erfahrungsberichte

Erfahrungen aus dem Alltag eines Linux-Anwenders

SSD Raid Arrays unter Linux – VII – problematische Aspekte von Raid-5-Arrays

Posted on by

In früheren Artikeln dieser Serie

SSD Raid Arrays unter Linux – III – SW- Raid vs. Intel-iRST-Raid – Performance?
SSD Raid Arrays unter Linux – V – SW-Raid vs. iRST-Raid – Boot-Unterstützung?
SSD Raid Arrays unter Linux – VI – SW-Raid vs. iRST-Raid – Flexibilität?

hatte ich am Beispiel des Intel Z170 RST Controllers ausgeführt, dass es auf einem reinen Linux-System für Raid-Setups nicht notwendig ist, iRST-Technologie zu benutzen. Man betreibt den Intel-Onboard-Controller besser als einfachen SATA3-Controller und nicht als iRST-Raid-Controller. Die (SSD)-Raid-Arrays baut man sich dann lieber mit Hilfe von mdadm als Linux-SW-Raid-Arrays. Man gewinnt dadurch an Flexibilität, hat keine Performance-Nachteile und kann sogar – wenn nötig – eine Linux-OS vom Array booten.

Bei Einsatz eines SW-Raid-Arrays für SSDs ist unter Linux allerdings ein wenig Umsicht angebracht. U.a. stellt sich die Frage nach der Wahl der Raid-Variante. In meinem Fall für vier SSDs. Da liegen als grundsätzliche Alternativen etwa Raid-10- oder Raid-5-Arrays nahe.

In diesem Beitrag möchte ich zwei Argumente dafür anführen, dass die Wahl eines Raid-5-Arrays nicht unbedingt die beste Entscheidung ist – und zwar

  • trotz des größeren nutzbaren Netto-Platzes auf dem SSD-Raid-Array
  • und trotz der im sequentiellen Read-Bereich für große Datenpakete besseren Performance.

Die Argumentation hat mit der Resynchronisation des Raid-Arrays nach einem Plattenausfall, der relativ schlechten Performance von Random-Write-Prozessen für kleine Datenpakete und der Nichtausführbarkeit des “fstrim”-Befehls zu tun (Stand Nov. 2016).

Nachtrag 14.06.2017:
Von all diesen Punkten ist der letzte derjenige, der sich am einfachsten überprüfen lässt. Zum zweiten Punkt werde ich bei Gelegenheit Daten nachliefern. Bzgl. des ersten Punktes bin ich mir inzwischen nicht mehr sicher, ob ich wirklich alle Einflussfaktoren verstanden habe. Ich habe den Artikel heute abgeändert; er spiegelt nun meine aktuelle Einschätzung wieder.

Was sprach im HDD-Zeitalter gegen Raid-5- oder Raid-6-Arrays?

Raid-5-Arrays stellten schon zu HDD-Zeiten ein Problem dar. Zu nennen war/ist hier aus meiner Sicht an erster Stelle der erhebliche Zeitbedarf zur Rekonstruktion eines degraded Raid-5- oder Raid-6-Arrays.

Ein degradiertes Array kann z.B. aufgrund des Ausfall einer Platte wegen echten HD-Defekten oder aber wegen einer losen SATA-Verbindung (ist mir schon passiert!) zu Stande kommen. Eine Degradierung kann aber durch einen ernsten Fehlers des Linux-Systems ausgelöst werden. Ja, letzteres kommt ab und zu auch mal unter Linux vor! Probleme gibt es u.U. auch dann, wenn Inhalte von Schreib-Caches bei einer Systemstörung nicht rechtzeitig auf alle Platten geschrieben werden konnten. Die Raid-SW muss nach einer Systemstörung mit Reboot u.U. eine Rekonstruktion betroffener Arrays vorschlagen, um wieder auf die sichere Seite zu kommen.

Überlebenswichtige Paritätsinformation muss dann wieder hergestellt werden; fehlerhafte Informationen auf der betroffenen Platte sind neu zu synchronisieren.

Statt Rekonstruktion spricht man oft auch von einer “Resynchronisierung” oder “Rebuild” eines Raid-Arrays. Ich verwende diese Ausrücke nachfolgend synonym.

Extrem lange Resynchronisationszeiten für Raid-Arrays mit mehreren Terrabyte an Kapazität gab es vor allem dann, wenn man die Zeitanteile für Rekonstruktionsaufgaben im Raid-
Controller oder aber in der Linux-SW zugunsten der produktiven Performance operativer Prozesse (also für den laufenden Alltagsbetrieb) reduzieren musste. Die Rekonstruktion eines Raid-5-Arrays konnte dann schon mal etliche Stunden in Anspruch nehmen. In dieser Zeit lebte man immer mit der Gefahr weiterer Ausfälle.

Resynchronisation von SW-Raid-Arrays mit SSDs

Nun sind SSDs ja sehr viel rascher als konventionelle HDDs. Aus diesem Grund sagten einige Systemadministratoren in Internet-Foren sogar eine Renaissance für Raid-5-Arrays voraus. Der Optimismus ist in der Praxis tatsächlich nachvollziehbar: Setzt man die Priorität für eine Raid-5-Resynchronisierung auf Mittelwerte, so liegen die Zeiten für ein 1TB-Array deutlich unter einer Stunde. Das ist aus meiner Sicht OK. Hinzu kommt bei Raid-5 ja die bessere Netto-Plattenplatzkapazität für Nutzdaten im Vergleich zu einem Raid-10-System.

Welche Faktoren beeinflussen die Resynchronisation eines Raid-5-Arrays?

Es erscheint klar, dass nach einem Verlust von Redundanz ggf. zwei Dinge notwendig sind:

  • Wiederherstellen von Information auf der ausgefallenen Platte/Partition bei einem Timeout oder auf einer Ersatz-Platte/Partition nach Totalausfall.
  • Erneutes Herstellen der Redundanz durch Berechnung und Schreiben valider Parity-Informationen.

Verkompliziert wird der Rekonstruktionsvorgang, wenn das Raid-5 Array im degradierten Zustand aktiv weiter betrieben wird oder betrieben werden muss. Zudem stellt sich die Frage, was die Ursache des Redundanzverlustes war und ob die ausgefallene Platte (oder Partition) aufgrund eines Defekts ersetzt werden muss – oder aber, ob die ursprünglich vorhandene Platte aus irgendwelchen Gründen nur einen vorübergehenden Timeout hatte, und weiterverwendet werden kann. Ein solcher Timeout kann z.B. durch ein locker sitzendes SATA-Kabel verursacht worden sein. Letzteres ist mir tatsächlich passiert (s.u.)!

Fall 1: Notwendiger Ersatz einer Platte/Partition nach einem Defekt
Dieser Fall ist logisch am einfachsten zu überblicken. Daten und Paritity-Informationen müssen dann auf der neuen Platte/Partition vollständig neu geschrieben werden.

Dazu muss der gesamte (!) Datenvorrat sukzessive von den verbliebenen Platten ausgelesen werden, über die noch vorhandenen Parity-Daten ist die verlorengegangene Information über Berechnungen zu rekonstruieren, der fehlende Datenanteil ist auf die neue Platte/Partition zuschreiben, Redundanz ist durch Berechnen und Schreiben neuer Parity-Information auf die neue Platte/Partition herzustellen. Das ist ein aufwändiger Vorgang, der die alten, noch funktionierenden Platten des Arrays enorm stresst, CPU kostet und vor allem viele Schreibvorgänge auf der neuen Platte/Partiton nach sich zieht.

Der ganze Prozess ist deshalb zwangsläufig langsam – es ist klar, dass ein weiterer Betrieb des degradierten Arrays nur mit schlechter Performance möglich sein wird. Die Wahrscheinlichkeit, dass eine weitere Platte im Rekonstruktionsprozess ausfällt, ist wegen der vielen Zugriffe nicht vernachlässigbar. Das Schreiben neuer Daten während eines weitergeführten Betriebs muss zudem in den Datentransfers zur neuen Platte und bei zugehörigen Paritätsberechnungen berücksichtigt werden. Das ist ein Grund dafür, die Array-Rekonstruktion möglichst ohne operative Belastung durchzuführen.

Fall 2: Die alte Platte/Partition kann weiter verwendet werden
Tja, da wird es dann komplizierter. Nehmen wir mal an, wir machen dem Array die ausgefallene Partition wieder zugänglich. In der Zwischenzeit lief/läuft aber der operative Betrieb auf dem Array weiter. Ein paar entscheidende Frage sind dann:

Woher soll das System eigentlich wissen, welche Parity-Information seit dem Ausfall noch verlässlich ist? Welche Sektoren und Blöcke
waren vom Ausfall betroffen? Welche Informaiton wurde neu hinzugefügt? Wo hat das zwischenzeitliche Überschreiben von Daten die ursprüngliche Parity-Information verändert?

Für die betroffenen Blöcke muss die Daten- und Parity-Information ja in jedem Fall neu berechnet und die nunmehr ungültige Information auf der wieder eingehängten Platte ersetzen!

Das Schreiben neuer Information kann aber irgendwo im Filesystem und damit auf der Platte erfolgt sein! Kennt das System die betroffenen Sektoren und Datenblöcke nicht, muss es deshalb im Rekonstruktionsprozess zur Sicherheit alle Daten des degradierten Arrays mit den veralteten Informationen auf der wieder eingegliederten Platte vergleichen und ggf. korrigieren!

Es wird klar: Man braucht für solche Situationen eine Art “Logging” der Adressen modifizierter Datenbereiche.

Bitmaps!
Linux SW-Raid (mittels mdadm) sieht für diesen Zweck das Schreiben sog. “Bitmaps” als Option für Raid-Arrays mit Datenredundanz vor. Genauere Informationen erhält man hier: https://raid.wiki.kernel.org/ index.php/ Write-intent_bitmap.

Ich zitiere den wichtigsten Punkt:

“When an array has a write-intent bitmap, a spindle (a device, often a hard drive) can be removed and re-added, then only blocks changes since the removal (as recorded in the bitmap) will be resynced. Therefore a write-intent bitmap reduces rebuild/recovery (md sync) time if:
  – the machine crashes (unclean shutdown)
  -one spindle is disconnected, then reconnected.
If one spindle fails and has to be replaced, a bitmap makes no difference.”

Für das Anschalten einer “Bitmap” und damit des gewünschten “Loggings” steht eine mdadm-Befehlsoption zur Verfügung (s. für die mdadm-Praxis einen späteren Artikel).

Haben Bitmaps auch Nachteile?
Leider muss ich die Frage mit Ja beantworten. Im Artikel
SSD Raid Arrays unter Linux – III – SW- Raid vs. Intel-iRST-Raid – Performance?
hatte ich ja verschiedene Performancedaten zum Vergleich eines reinen (über mdadm angelegten) Linux-SW-Raid-10-Arrays mit einem iRST-Raid-10-Array präsentiert. Dabei wurden erhebliche Unterschiede in der Performance von mdadm-SW-Arrays festgestellt, die mit unterschiedlichen Parametern angelegt wurden:

Die festgestellte, um bis zu 30% schlechtere sequentielle Write-Performance gehörte zu Linux-SW-Arrays, bei denen im operativen Betrieb eine Bitmap mit geschrieben wurde!

Bitmaps kosten also Schreib-Performance – manchmal in signifikanter Weise. Wie hoch die Einbußen genau sind, hängt jedoch auch davon ab, ob man die Bitmap-Daten auf das Array selbst oder auf eine Partition einer separaten Platte außerhalb des Arrays schreibt. Wir werden auf entsprechende Effekte und Zahlen in späteren Artikeln zurückkommen.

Raid-5 mit einem Onboard-Sata3-Controller – Intel Z170 Sunrise Point – und iRST-Technologie

Wie sieht es mit der Rekonstruktion eines Raid-5-Arrays nun eigentlich im schlimmsten Fall aus? Ich schildere hierzu mal eines meiner Erlebnisse:

In meiner grenzenlosen Naivität begann ich bei der Einrichtung meines SSD-Testsystem zunächst damit, unter Einsatz von iRST ein “Raid 5”-Array aufzubauen. Die SSDs hingen dabei am “Sunrise Point”-Controller im Z170-Chipsatz des Mainboards. Nun ist ja bekannt, dass eine gerade Anzahl von Platten und Raid-5 nicht sonderlich gut zueinander passen. Für einen ersten Anlauf mit einem Raid-5-Array sprachen aus meiner Sicht aber folgende Punkte:

  • Bessere Nutzung der (relativ teuren) Plattenkapazität als mit Raid-10.
  • Optimierung vieler (Fake-)
    Raid-Controller auf die Nutzung von Raid-5.
  • Schlechte Erfahrungen mit Raid-10 auf 3ware-Controllern bei Random I/O.

Meine vier 500 GB-SSDs [Samsung EVO 850] wurden also zu einem Linux-SW-Raid-Array zusammengeschaltet; dabei wurden ca. 460 GB pro Platte effektiv genutzt. Zum Aufsetzen nutzte ich die UEFI-BIOS-Bordmittel für den Intel-Controller (iRST). Die resultierende Performance war wirklich überzeugend:

Ein Read-Durchsatz im sequentiellen Bereich um die 1.45 GB/sec und hohe sequentielle Schreibraten im Bereich von 1.1 GB/sec ließen mich zunächst nicht an meinem Vorgehen zweifeln. Hinzu kam – im Vergleich zu Raid 10 – die relativ hohe verfügbare Plattenkapazität (> 1,36 GB bei 4 EVO 850 500GB SSDs).

Das Betriebssystem hatte ich im ersten Anlauf dummerweise auch auf dem Raid-Array selbst installiert. Das kostet, wie bereits in einem früheren Artikel festgestellt, ca. 10% an Performance. Ich habe die Entscheidung für Raid-5 dann aber aus einem anderen Grund als vordergründigen Performance-Einbußen bereut.

Resynchronisation des Raid-5-Systems nach Ausfall einer Platte

Es geschah nämlich etwas, dass normalerweise nicht passieren sollte. Ich hatte ein SATA-Verbindungskabel nicht richtig gesteckt. Als das PC-Gehäuse dann mal bewegt wurde, löste sich das Kabel aus der SSD – mit dem Effekt, dass das Array in einen “degraded” Zustand überging. Kein Problem, dachte ich. Genau für solche Situationen hat man ja ein RAID-System. Ich ließ das Array danach wieder aufbauen – der Resynchronisierungsprozess wurde mit der entsprechenden iRST-Funktionalität des Controllers im BIOS aufgesetzt; die eigentliche Ausführung erfolgte dann im neu gestarteten Linux-System unter Kontrolle der “md-raid”-Module des Kernels. Insgesamt nahm das nicht so viel Zeit in Anspruch wie aufgrund vieler Internet-Artikel befürchtet. Ich habe die Zeit nicht gemessen, aber es dauerte, wie gesagt, sicher deutlich weniger als 1 Stunde.

Was mich dann allerdings schockte, war ein Blick auf den SSD-Zustand mit Hilfe des Kommandos smartctl. Ist Smart im BIOS aktiviert, so ist eine Zustandsüberprüfung einzelner SSDs (zumindest auf meinem ASRock-Board) sowohl bei Einsatz eines nativen Linux-SW-Raids als auch bei Einsatz von iRST-Raid-Containern möglich. Die durch den Ausfall betroffene SSD lief bei mir als Device “/dev/sdd”. Die übrigen Devices des Raid-5-Arrays unter /dev/sda, /dev/sdb, /devsdc. Unter den vielen ausgewiesenen Smart-Daten stelle ich nachfolgend nur die Anzahl der “Total_LBAs_written” nach dem Resynchronisationsprozess dar:

Total_LBAs_Written
sda : 604127952
sdb : 846533123
sdc : 603302987
sdd: 3763859973 !!!

Vor dem Resynchronisationsprozess befand sich der Wert für “/dev/sdd” dagegen auf dem Niveau von “/dev/sdc” – also < 603302987 !!

Dass der Basiswert auf “/dev/sdb” so hoch war, lag übrigens daran, dass auf diesem Device noch andere Tests zur Performance einer einzelnen SDD durchgeführt worden waren.
Nach vielen, vielen weiteren Testläufen und ca. 12 (!) immer neuen initialen Raid-10-Synchronisationen über 100 GB, 200 GB oder 400 GB umfassende (Raid-10-) Arrays sieht das heute (Nov. 2016) so aus:

Total_LBAs_Written
sda: 979783261
sdb: 1211867704
sdc: 995650995
sdd: 4121599736

Es ist offensichtlich, dass die eine Resynchronisations-Aktion für die Wiederherstellung des ehemaligen Raid-5(!)-Arrays über die gesamte Platte “/dev/sdd” hinweg geschrieben hat (Daten- und Paritätsinformationen). Gleichzeitig ging der Parameter “Wear_Leveling_Count” der vom Ausfall betroffenen Platte um 1 Prozentpunkt nach unten. Die Belastung der (vorher ausgefallenen) Platte durch den einen Raid-5-
Resynchronisationsprozess ist also substanziell gewesen!

Wie lässt sich der extreme Befund zur Schreibbelastung erklären?

Im Artikel
SSD Raid Arrays unter Linux – III – SW- Raid vs. Intel-iRST-Raid – Performance?
hatten wir eine relativ gute Schreib-Performance des iRST-imsm-Raid-Arrays festgestellt. Eine spätere Überprüfung brachte dann die Ursache zu Tage:

Die iRST-BIOS-Funktionen legen die imsm-Raid-Container grundsätzlich ohne “Bitmap” an!

Nächste Frage: Welche Auswirkungen hat denn das Fehlen einer Bitmap auf eine Resynchronisation? Eine Antwort finden wir in folgendem Artikel:
https://raid.wiki.kernel.org/ index.php/ Replacing_a_ failed_drive

Dort wird erläutert, dass man im Falle von Timeouts versuchen kann und sollte, die ausgefallene Platte/Partition einem Raid-Array wieder zur Verfügung zu stellen. Ich zitiere aus dem Abschnitt “So you have no redundancy!”:

“Before attempting to replace a failed drive, you should ALWAYS attempt to restore redundancy before replacing a drive. If the array is redundant, a replace will just copy the dodgy drive, only stressing the old drives if it can’t read the dodgy drive. If the array is not redundant, then adding a new drive will stress the entire array as it has to recreate the new drive from the remaining old drives. This is true even for a mirror.”

Und:

“If you have set up a bitmap on your array, then even if you plan to replace the failed drive it is worth doing a re-add. With a bitmap, the raid will know which sectors need writing, and will recover the array for you. You can then consider doing a replace of the faulty drive.
mdmad /dev/mdN –re-add /dev/sdX1
mdadm /dev/mdN –add /dev/sdY1 –replace /dev/sdX1 –with /dev/sdY1
If possible, do not mount the partitions on the raid (or do it read-only) while the rebuild takes place, to avoid undue stress on the array.
If you do not have a bitmap then don’t re-add the old drive unless it was a (now fixed!) timeout problem and you don’t intend replacing the drive. Without a bitmap, then the raid will treat it like a new drive and do a total rebuild.“

Aha! Der letzte Satz erklärt mein Erlebnis und bedeutet gleichzeitig:

Wenn schon Raid-5, dann bitte mit Bitmap!

Es ist eigentlich bemerkenswert, dass Intel für iRST-Raid-5-Arrays nicht automatisch die Anlage von Bitmaps vorsieht. Intel weiß wohl, dass die Schreibraten dann nicht mehr so werbewirksam wären!

Wie ist das Schreiben für eine Raid-5-Rekonstruktion – ohne Bitmap – im Vergleich zu einer normalen Plattenbelastung zu werten?

Zum Vergleich: Eine in einem anderen System seit 2 Jahren als Betriebssystemplatte mit virtuellen Maschinen im Dauereinsatz, aber nicht in einem Raid-Verbund befindliche Samsung EVO 840 Pro weist heute einen Wert von

Total_LBAs_Written
sdx: 7968906003

auf. Das ist also immer noch weniger als das Doppelte dessen, was mich eine einzige (!) Resync-Aktion einer Raid-5-SSD gekostet hat!

Wie oft muss man eigentlich mit einem Resync-Prozess rechnen?

Der oben genannte Artikel wiesen ja darauf hin, dass Crashes und unsaubere Shutdowns einen Rebuild-Vorgang für ein Array auslösen können. Machen wir uns nichts vor: Zumindest auf Linux-Desktop-Systemen kommt sowas öfter vor, als man sich das wünscht. Erst vor kurzem hatte ich mal einen Hänger des KDE-Plasma-Desktops auf meinem Testsystem. Das System war danach nicht mehr bedienbar. Ich befürchtete schon das
Schlimmste; der Filesystemzustand war zum Absturzzeitpunkt zwar fehlerhaft, der Plattenzustand über das Raid-Array hinweg aber noch konsistent. Das Filesystem-Fehler konnte nach einem Reboot ohne ein Raid-Rebuild korrigiert werden.

Aber dafür gibt es nun leider überhaupt keine Garantie – schon gar nicht im Falle eines Absturzes während eines intensiven Datentransfers (lesend und schreibend) zu dem Raid-5-Array. Ein inkonsistenter Zustand der Platten im Raid-System nach einem ernsthaften Systemfehler ist aus meiner Sicht dann eher wahrscheinlich. Und anschließend würde – bei fehlender Bitmap – vermutlich das gesamte Raid-5-System resynchronisiert werden.

Wie schaut es mit Raid-10 aus?

Ich habe für Tests in den letzten Monaten mehrfach Raid-10-Arrays angelegt und auch rekonstruiert. Die Wiederherstellung eines Raid-10-Arrays nach einem Timeout einer Platte erwies sich hinsichtlich der durchgeführten Schreiboperationen regelmäßig als relativ harmlos. Die Resynchronisation eines degradierten Raid-10-Array wird zudem erheblich (!) schneller als die eines gleich großen Raid-5-Arrays abgeschlossen.

Ein Grund liegt auf der Hand – im Falle von Raid-10 ist keine Paritätsinformation zu berechnen oder zu schreiben. Ich vermute ferner, dass im Zuge der Rekonstruktion nach einem Timeout möglicherweise nicht alle Daten, sondern lediglich abweichende, bereits genutzte und während des Timeouts geänderte Blöcke durch Schreibvorgänge abgeglichen werden. Das Prüfen auf Identität von Datenblöcken auf zwei Laufwerken lässt sich bei reiner Spiegelung ja relativ einfach und vor allem schnell durchführen.

Reichweite des TRIM-Befehls?

Ein wichtiger weiterer Punkt, der im Zusammenhang mit SSDs zu beachten ist, ist das Thema der sog. “Write Amplification” (s. https://en.wikipedia.org/ wiki/ Write_amplification). Ein Flash-Speicher muss vor einem Neubeschreiben erst gelöscht werden; das führt u.U. zu Verschiebungen von Speicherinhalten und mehrfachen Schreiboperationen. Das reduziert potentiell sowohl die Performance als auch die Lebenszeit von SSDs.

Neben den reinen Nutzdaten müssen im Normalbetrieb auf allen Platten eines Raid 5/6-Verbunds Paritätsinformationen geschrieben werden. Write Amplification (durch Verlagerung von Blöcken auf SSDs) trägt also gerade im Fall von Paritäts-Raids zusätzlich zu einer stärkeren Abnutzung der SSDs bei – gerade in kleineren Arrays (< 8 disks). Theoretisch ist aber die Anzahl der insgesamt durchzuführenden Schreiboperationen auch bei Raid-10 nicht kleiner als bei Raid-5. Insofern erscheint mir das Thema der Write Amplification als solches allein noch kein Argument für oder gegen Raid-5 oder Raid-10 zu sein.

Eine Konsequenz zur Aufrechterhaltung der Performance und zur Vermeidung von Zeitverlust durch Löschungen besetzter Blöcke bzw. durch das Suchen nach freien Blöcken auf der Platte ist aber, dass die Information über freie Knoten mit dahinterliegenden direkt beschreibbaren Speicherelementen regelmäßig upgedated werden muss. Das Filesystem muss den SSD-Controller – gemeint ist hier der Controller auf der SSD und nicht der Fake-Raid-Controller – über freigewordene, ungenutzte Speicherelemente informieren. [Der SSD-Controller muss mit den im Rahmen des (S)ATA-Protokolls übertragenen Information natürlich auch was anfangen können; letzteres ist heute praktisch bei allen Marken-SSDs der Fall.]

Unter Linux erledigt das der “fstrim“-Befehl für gemountete Partitionen: einerseits erfolgt dadurch die Weitergabe der Information zu freien Knoten; andererseits werden dann von den SSD-Controllern sog. “discard”-Operationen für logisch freigegebene Speicherelemente durchführt. Fortschrittliche Controllers sehen zudem regelmäßige Lösch- und Speicher-Reorganisationsverfahren auf den SSDs vor (SSD garbadge collection).

Nun können Betriebssystem und Raid-(Controlling)-SW in intelligenter Weise dazu beizutragen, um “Write Amplification” zu reduzieren. Hierfür sind meist Zwischenpufferungen von Operationen nötig. Siehe hierzu die interessanten Diskussionen unter

http://www.webhostingtalk.com/ showthread.php?t=1457939

http://cesg.tamu.edu/ wp-content/ uploads/2012/02/ hotstorage13.pdf

Aber:
Das Thema der Speicher-Freigabe und -Reorganisation bleibt unabhängig von der Anzahl der Schreiboperationen für SSD-Raid-Arrays bestehen. Somit stellt sich für die Auswahl eines bestimmten Raid-Verfahrens für SSDs auch die Frage, ob der “fstrim”-Befehl für die verschiedenen Raid-Varianten eigentlich durch die potentiell betroffenen Layer

Linux-Filesystem (z.B. ext4) – Logical Volume einer LVM-Gruppe – Array über Raid-Partitionen – Partitionen verschiedener SSDs

zu den Controllern der beteiligten SSDs durchgereicht wird.

Leider ist das gerade für Raid-5- oder Raid-6-Arrays nicht der Fall – weder im Falle von mdadm-SW-Raid-Arrays noch im Falle des Einsatzes von iRST-Technologie und imsm-Raid-Containern. Ich erhalte bei entsprechenden Versuchen regelmäßig Meldungen, dass die zugrundeliegende Infrastruktur den fstrim-Befehl nicht unterstützen würde.

Auf meinen Test-Systemen konnte ich dagegen feststellen, dass der “fstrim”-Befehl an logische LVM-Volumes auf Raid-0-, Raid-1– und Raid-10-Arrays anstandslos durchgereicht wird – zumindest für ext4-Filesysteme. (Andere Filesysteme wie BTRFS habe ich nicht getestet; generell herrscht ja die begründete Meinung vor, dass EXT4 dem Verhalten von SSDs am besten entgegenkommt). Das gilt für reines SW-Raid unter mdadm wie auch für den Einsatz von iRST/imsm-Containern. (Diese Aussagen kann ich genau genommen im Moment nur für Opensuse-Leap 42.1/42.2 (Kernel 4.4) und ein Debian Jessie-Test-Systeme mit Kernel 4.7 treffen.)

D.h.: Potentielle Einschränkungen der Performance sind zumindest bei ext4-Filesystemen auf Raid-5-Arrays vorprogrammiert, wenn nicht der Plattencontroller selbst die Garbage Collection und Speicherreorganisation übernimmt. Tatsächlich konnte ich für ext4-Partitionen nach Durchführung von Tests, bei denen mehr als 40 % eines Filesystems beschrieben wurden, regelmäßig Performanceverbesserungen nach Absetzen eines fstrim-Befehls feststellen. Zwar keine weltbewegenden Änderungen, aber doch im 10% – 20%-Bereich. Einschränkungen der Performance tauchen mit dem Auffüllen einer Partition also mit hoher Wahrscheinlichkeit auf.

Nun wird und wurde von SSD-Herstellern und Kommentatoren im Internet oft angeführt, dass gerade größere SSDs, die für den professionellen Einsatz gedacht sind, selbst für eine regelmäßige Garbage Collection sorgen. Ich habe sowohl EVO 840 Pros und EVO 850 Pros mit 500GB Kapazität auf verschiedenen Systemen im Einsatz und setze ab und zu den fstrim-Befehl für eingerichtete Partitionen manuell ab. Die benötigten Zeiten zur Speicherreorganisation dauern für meine Gefühl relativ lange und betreffen manchmal etliche zig GB. Dabei werden offenbar auch echte Operationen auf den Disks durchgeführt. Das spricht aus meiner Sicht zumindest nicht für eine hohe Frequenz der automatischen Garbage Collection durch die SSD-Controller von Samsung. Das mag bei anderen SSDs jedoch anders sein.

Aus meiner Sicht ist es daher empfehlenswert, vor dem produktiven Einsatz sicherzustellen, dass der fstrim-Befehl im angestrebten Raid-Verbund funktioniert.

Warnung von Red Hat vor dem Einsatz von SW-Raid-5 mit SSDs

Wie eine Recherche im Internet ergab, warnt(e) Red Hat vor dem Einsatz u.a. von Raid-5 für SSDs; s.

https://access.redhat.com/ documentation/ en-US/Red_Hat_ Enterprise_Linux/ 6/html/ Storage_Administration_Guide/ ch-ssd.html

https://access.redhat.com/ documentation/ en-US/ Red_Hat_Enterprise_Linux/ 7/html/ Storage_Administration_Guide/ ch-ssd.html

Zitat:

Red Hat also warns that software RAID levels 1, 4, 5, and 6 are not recommended for use on SSDs. During the initialization stage of these RAID levels, some RAID management utilities (such as mdadm) write to all of the blocks on the storage device to ensure that checksums operate properly. This will cause the performance of the SSD to degrade quickly.

Schlechte Schreibperformance von Raid-5 bei kleinen Datenpaketen?

Das anderes Argument gegen Raid-5 war die meist schlechte Performance für Random I/O-Bereich und dies vor allem bei einer kleinen Größe der stückweise zu schreibenden Datenpakete. Write-Caches einiger echter HW-Raid-Controller haben hier geholfen; der Einsatz eines Schreibpuffers ist aber – wie oben erläutert – auch mit Risiken verbunden; Batteriepuffer waren für dedizierte HW-Raid-Controller daher meist obligatorisch.

Eine vergleichsweise schlechte Performance attestieren viele Admins Raid-5-Arrays auch heute noch – selbst bei Einsatz von SSDs. Ich bin hier etwas vorsichtiger. Weder Raid-10 noch Raid-5 sind bei kleinen Datenpaketgrößen besonders schnell. Die Performance hängt aber auch stark von anderen Faktoren ab; u.a. von Raid-Array-Parametern, wie der Chunk Size, aber auch dem Lastprofil.

Um das Thema Performance Raid-5 vs. Raid-10 von SW-Raids unter Linux kümmere ich mich deshalb genauer in einem der kommenden Artikel. Bzgl. konkreter Zahlen muss ich den Leser deshalb noch vertrösten.

Fazit

Legt man die obigen Erfahrungen zugrunde, so läuft die Entscheidung zwischen Raid-10 und Raid-5 im Normalbetrieb auf

  • eine Abwägung von Performance-Vor- und -Nachteilen,
  • eine Bewertung des effektiv verfügbaren Plattenplatzes
  • und eine Bewertung des SSD-Verschleißes, der im Fall der Resynchronisation eines Degraded Raid-5-Arrays auftritt,

hinaus.

Man sollte ein Raid-5-Array aus meiner Sicht jedenfalls nicht ohne eine Bitmap betreiben. Das führt aber wieder zu zusätzlichen Schreibprozessen. Selbst wenn man die auf eine Platte außerhalb des Raid-Arrays verlagert, muss man den Overhead und den resultierenden Durchsatz testen. Diese separate Platte muss hinreichend schnell ansprechbar sein und sollte nicht die native und hohe Schreibperformance eines Raid-5-Arrays ohne Bitmap beeinträchtigen. Sequentielle Schreibraten von > 1GB/sec sind auf einem Raid-5-Array mit Consumer-SSDs durchaus möglich; auch wenn die Menge der Bitmap-Daten im Vergleich zur Menge der Realdaten relativ klein sein sollte – die Schreibrate dafür muss zum Gesamtdurchsatz passen. Man würde vermuten, dass das besonders bei kleinen Datenpaketen problematisch wird.

Hinzu kommen potentielle Performance-Einbußen durch ein fehlendes Weiterreichen des fstrim-Befehls an Filesysteme auf Raid-5-Arrays. Das relativiert die Performance-Vorteile beim Lesen, die ein Raid-5-System gegenüber einem Raid-10-System für sequentielles Schreiben aufweist, etwas. Zudem gilt:

Wer aus irgendwelchen Gründen eine verbesserte Lese-Performance unter Raid 10 anstrebt, kann auch mal das Far-Layout oder ein Near/Far-Layout des Raid10-Arrays ausprobieren. Das Far-Layout geht allerdings zu Lasten der Schreibperformance – und dies besonderes für Random I/O. Aber Raid-5 ist gerade für häufigen Random I/O kleinerer zu schreibender Datenmengen noch weniger performant.

Insgesamt erschien/erscheint mir das Aufsetzen eines Raid-5-Arrays doch ein
ziemlicher Balanceakt zu sein. Ich befasse mich in den kommenden Artikeln daher zuerst mit Raid-10-Arrays.

Ausblick

Im nächsten Beitrag
SSD Raid Arrays unter Linux – VIII – Setup von Raid-10-Arrays mit mdadm
gehe ich endlich ein wenig mehr auf praktische Schritte ein. Diskutiert wird dort die Anlage und Parametrierung eines SW-Raid-10-Arrays mit Hilfe von mdadm.

Interessante Links

https://www.thomas-krenn.com/ de/wiki/ ATA_Trim

https://wiki.debian.org/ SSDOptimization

http://cesg.tamu.edu/ wp-content/ uploads/2012/02/ hotstorage13.pdf

https://en.wikipedia.org/ wiki/Write_amplification

http://www.webhostingtalk.com/ showthread.php?t=1457939

http://serverfault.com/questions/ 513909/ what-are-the-main-points-to-avoid-raid5-with-ssd

https://lowendtalk.com/ discussion/ 10000/ don-t-build-ssd-in-raid5

https://www.reddit.com/ r/sysadmin/ comments/ 3m9req/ how_would_you_configure_ an_mdadm_raid_5_w_ssds/? st=ivpbg325&sh=a09d50fd

http://researchweb.watson.ibm.com/ haifa/ conferences/ systor2011/ present/ session5_talk2_systor2011.pdf

http://superuser.com/ questions/ 461506/ intel-matrix-storage-manager-vs-linux-software-raid

Bzgl. der grundsätzlichen Einstellung von LVMs und des Absetzens von TRIM-Anweisungen im Kontext von LVM-Operationen siehe etwa:
http://blog.neutrino.es/ 2013/ howto-properly-activate-trim-for-your-ssd-on-linux-fstrim-lvm-and-dmcrypt/

Near/Far-Layout füe Linux SW-Raid-10
http://www.ilsistemista.net/ index.php/ linux-a-unix/ 35-linux-software-raid-10-layouts-performance-near-far-and-offset-benchmark-analysis.html?start=1

Bitmaps
http://www.tutorialspoint.com/ unix_commands/ mdadm.htm

 

SSD Raid Arrays unter Linux – VI – SW-Raid vs. iRST-Raid – Flexibilität?

Posted on by

Wer für ein Desktop-System oder einen kleinen Server ein Raid-Array aufbauen will, kann dafür (nach einer Risiko-Analyse) ggf. den Onboard-SATA3-Controller des Mainboard-Chipsatzes nutzen. Auf Intel-Chipsätzen findet man dann Controller vor, die das Einrichten von Arrays mit Hilfe der iRST-Technologie erlauben. Darauf bin ich im früheren Beitrag

SSD Raid Arrays unter Linux – III – SW- Raid vs. Intel-iRST-Raid – Performance?

dieser Blog-Post-Serie bereits genauer eingegangen. Zusammen mit einem weiteren Artikel

SSD Raid Arrays unter Linux – V – SW-Raid vs. iRST-Raid – Bootunterstützung?

hatte ich dann erläutert, dass wir unter einem aktuellen Linux-Betriebssystem auch gut ohne Intels iRST-Technologie für die Konfiguration von Raid-Arrays auskommen können.

Der Einsatz von iRST ist auf einem reinen Linux-System weder aus Performance-Gründe noch aus Gründen einer hinreichenden Boot-Unterstützung erforderlich. iRST ändert ferner nichts am Faktum, das z.B. eine Z170-Sunrise-Point-Controller von Intel letztlich als kostengünstiger Fake-Raid-Controller betrieben wird.

In diesem Artikel möchte ich einen weiteren Aspekt gegen den Einsatz von iRST unter Linux ins Spiel bringen – nämlich eine begrenzte Flexibilität. Daneben gibt es aus meiner Sicht noch ein paar weitere erwähnenswerte Nachteile.

CLI vs. “komfortable” BIOS-Funktionen?

Linux-SW-Raids werden in der Regel mit Hilfe von mdadm-Kommandos über die Command Line eingerichtet, iRST-Arrays dagegen über EFI-BIOS-Funktionen oder aber eben auch über “mdadm”. Siehe: https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/rst-linux-paper.pdf.

Einige Betriebsysteme bieten für die Einrichtung von Arrays auch grafische Hilfsfunktionen an – unter Opensuse etwa dem YaST-Partitioner. Die Status-Überwachung beider Arrays erfolgt im laufenden Betrieb mit Hilfe von mdadm (mit bestimmten Optionen) und einen Blick ins Verzeichnis “/proc/mdstat”; für imsm-Metadatencontainer gibt es auch das CLI-Kommando “mdmon”. Aber wer unbedingt grafisch arbeiten muss, der findet eine (begrenzte) mdadm-Unterstützung im Tool “webmin”.

Manch einer mag ja das Anlegen und ggf. die Rekonstruktion von Raid-Arrays über BIOS-Funktionalitäten für bequem halten. Ich sehe das nur begrenzt so. Ein Linux-Admin wird sich durch den Einsatz der Kommandozeile nicht abschrecken lassen. Zumal mdadm ein feingranulareres Arbeiten ermöglicht. Einen kleinen “Kurs” zu mdadm bietet übrigens die Seite https://www.tecmint.com/understanding-raid-setup-in-linux/.

Zudem hilft einem im laufenden Betrieb das BIOS gar nichts. Ferner ist eine Raid-Rekonstruktion über BIOS-Funktionen typischerweise langsamer als über ein laufendes Betriebssystem. Hier kommt das zum Tragen, was ich bereits im Artikel

herausgearbeitet hatte: Im Schadensfall (degradiertes Raid-Array) benötigt man zur Reparatur und zur laufenden Überwachung ein funktionierendes OS auf einer separaten Platte! Der Rückgriff auf BIOS-Funktionalitäten ist dann überflüssig. Das gilt für imsm-Raid-Arrays wie für mdadm-Raid-Arrays!

mdadm bietet für Linux-SW-Raid-Arrays mehr Möglichkeiten als iRST für imsm-Container

Bei Einsatz von iRST und imsm-Containern geht einem im Vergleich zu den Konfigurationsmöglichkeiten von nativen SW-Raid-Arrays über “mdadm” viel Flexibilität verloren. Das sollte man in der Praxis nicht unterschätzen:

So
lässt iRST nur genau 2 Raid-Arrays (Volumes) per Container zu – und der zweite anzulegende Verband kann dann in seiner Kapazität nicht mehr begrenzt werden. Er wird vielmehr den gesamten verbliebenen Platz der bereits einander zugeordneten Container Platten beanspruchen. Das ist eine massive Einschränkung.

“mdadm” unter Linux erlaubt dagegen die Erstellung beliebig vieler, in ihrer Größe definierbarer SW-Raid-Arrays über Partitionen gleicher oder unterschiedlicher SSDs hinweg. Dabei werden dann auch solche exotischen, aber performancesteigernden Dinge wie etwa ein Raid 10 über Partitionen von nur 2 SSDs möglich! Typ und Kapazität eines jeden einzelnen Arrays dürfen dabei im Rahmen der Größe der genutzten Rohpartitionen frei festgelegt werden.

Alle gängigen Typen an Raid-Konfigurationen werden dabei unterstützt. Gerade für Raid-10-Konfigurationen gibt es jedoch im Detail eine Vielzahl von verschiedenen Layout-Möglichkeiten für das Array, die es unter iRST nicht gibt. Diese Optionen erlauben einem eine weitere Optimierung für spezielle Einsatzszenarien. Siehe hierzu etwa:
http://www.ilsistemista.net/index.php/linux-a-unix/35-linux-software-raid-10-layouts-performance-near-far-and-offset-benchmark-analysis.html?start=1
Ich selbst komme darauf aber in einem weiteren Artikel zurück.

Potentielle Folgen von iRST-Einschränkungen bzgl. der Volume-Größe

Die fehlende Freiheit bzgl. der Größenbegrenzung des zweiten imsm-Volumes hat unter iRST bei bestimmten Raid Levels, besonders aber im Fall von großen Raid-5- oder Raid-6-Arrays erhebliche Auswirkungen für evtl. Wiederherstellungsverfahren:

Legt man zwangsweise ein zweites imsm-Volume mit großer Kapazität an, so wird das iRST-Raid-Volume bei irgendwelchen Problemen mit darauf aufgesetzten Filesystemen immer als Ganzes einer Resynchronisation unterworfen. Das passiert z.B. nach unsauberen Shutdowns, bei denen Filesysteme des Raid-Verbandes nicht mehr abschließend mit Caches synchronisiert werden konnten. Fällt gar eine Platte aus, wird der gesamte Container mit beiden Arrays rekonstruiert.

Das kostet bei allen Raid-Formen erhebliche Zeit – vor allem aber für Raid 5/6-Arrays. Die SSD-Geschwindigkeit hilft hier zwar, aber bei großen Arrays mit > 1 TB Kapazität zehrt das im Falle von Raid 5 trotzdem an den Nerven. Zudem wird im Falle von RAID 5 dabei der Verschleiß der eingebundenen SSDs erheblich beschleunigt. Mehr dazu im nächsten Beitrag.

Flexible Größenänderung angelegter Arrays?

Die Größe eines definierten iRST-Raid-Volumes kann im Nachhinein nach meiner Erfahrung weder durch Partitionsausweitung noch durch das Hinzufügen von weiteren Partitionen verändert werden. Bei einem reinen SW-Raid-Array unter Linux ist beides aber über ein paar Zwischenschritte möglich (s. hierzu die mdadm-Literatur; u.a. https://raid.wiki.kernel.org/index.php/Growing und https://www.howtoforge.com/how-to-resize-raid-partitions-shrink-and-grow-software-raid).

Für einen imsm-Container ist mir das bislang mit Linux-Bordmitteln dagegen nicht gelungen. So war es mir u.a. nicht möglich, auf Platten, die bereits einem iRTS-Verband im “imsm”-Format zugeordnet waren, neue Partitionen anzulegen, die ich einem bereits definierten imsm-Raid-5-Volume hätte zuordnen können.

Flexibilität bei Ausfall des Controllers?

Gerade beim Aufbau eines Server-Systems muss man sich fragen: Was geschieht eigentlich, wenn der Controller selbst ausfällt? Ein solcher Ausfall kann, muss aber nicht zum Austausch des gesamten Mainboards führen. Das ist in der Regel immer noch sehr viel billiger
als ein HW_Raid-Controller. Eine Frage ist aber: Kann man in der Zwischenzeit die Raid-Platten zur Not auch an ein anderes Linux-System anschließen und die wichtigsten Daten auf andere System transferieren? Unter der Voraussetzung, dass das Array überhaupt noch lauffähig ist?

Nun, da bin ich im Fall von imsm-Containern unsicher. Im schlimmsten Fall benötigt man ein neues Mainboard-Board mit iRST-Funktionalität, um wieder an die Daten des Arrays zu kommen. Andererseits unterstützt mdadm ja auch imsm-Container … Ich weiß es schlicht nicht – und habe ein solches Ausfallszenario mit iRST/imsm-Containern bislang nicht getestet. Was man aber mit Sicherheit sagen kann, ist Folgendes :

Im Falle eines Linux-SW-Raid-Arrays kann man ein funktionstüchtiges Array auch auf einem anderen Linux-System zum Laufen bringen, wenn die Platten denn physikalisch an einen dortigen Controller angeschlossen werden können. Man hängt die SSD-Platten an den dortigen SATA-Controller,l bootet, aktiviert die md-Raid Module und nutzt ein Plattenverwaltungssystem seiner Wahl – und schon hat man – ggf. nach einer Rekonstruktion des Arrays – wieder Zugriff auf seine Daten.

Zwischenfazit

Ich finde, allein die mangelnde Flexibilität von iRST bei der Definition mehrerer Raid-Arrays mit selbst festgelegter Größe ist ein guter Grund, auf den Einsatz von iRST unter Linux zu verzichten.

Weitere Gründe, die gegen den Einsatz des iRST auf reinen Linux-Systemen sprechen, findet ihr übrigens hier:
http://superuser.com/questions/461506/intel-matrix-storage-manager-vs-linux-software-raid
Siehe dort auch die interessante Diskussion des Themas.

Verbleiben eigentlich noch Gründe für den Einsatz des iRST?

Mir fallen dazu nur noch folgende Punkte ein:

  • Die Restaurierung bzw. Resynchronisation eines defekten Raid-Verbunds mit einer Ersatz-SSD lässt sich zur Not auch unabhängig vom Betriebssystem – nämlich über BIOS-Funktionen – durchführen. Dies ist im Besonderen dann zu bedenken, wenn man das Betriebssystem selbst auf einem Raid-Array bzw. imsm-Volume und/oder die EFI-Boot-Partition in einem imsm-Container installiert hat.
  • Auf Dual-Boot-Systemen (mit Windows) bringt das Intel-spezifische “imsm”-Format Vorteile. Der Raid-Verbund selbst und entsprechend formatierte Partitionen können dann auch direkt unter MS Windows angesprochen werden.

Der letzte Punkt kann auf Dual-Boot-Systemen tatsächlich einige Bedeutung haben. Die eigentliche Frage ist hier jedoch: Braucht man zwingend eine Dual-Boot-System für den Einsatz von MS Windows? Nun, das wird meist wohl von Kundenwünschen abhängen. Für mich selbst gilt jedenfalls:

Wenn man als Linuxer schon in die Untiefen von MS Windows-Systemen abtauschen muss, dann über Virtualisierung. Etwa über VMware (wenn man unbedingt eine wenig 3D-Effekte unter MS Win sehen will), Virtualbox oder KVM. Und bzgl. Performance des Zugriffs auf virtualisierte “Platten” (bzw. entsprechende Container-Files) gilt dann:

Man kann das virtualisierte Windows ja gerade auf einer Partition eines Linux-SW-Raid-Arrays zum Laufen bringen, wenn man die Disk-Perfromance in die Höhe treiben muss. Das klappt nach meiner Erfahrung sehr gut! Ein Win 7-System, das unter VMware läuft, weist einen Leistungsindex mit 7.9 Punkten von 7.9 möglichen Punkten für seine virtualisierte Platte aus. Diese “Platte” besteht aus einem “vdmk”-Container-File, das auf einer ext4-Partition eines Linux-SW-Raid-Arrays mit SSDs untergebracht wurde. Die ext4-“Partition” wurde dabei auf einem LVM-Volume angelegt. Einen noch besseren Durchsatz würde ich für einen direkten Durchgriff auf eine NTFS-Partition auf dem Array erwarten.

Ausblick

Unsere Artikelserie zu SSD-Raid-Arrays hat bislang ergeben, dass wir uns für kleinere
Linux-Systeme auf SW-Raid (unter mdadm) konzentrieren sollten. Will man einen Onboard-Controller von Intel benutzen, so kann und sollte man auf den Einsatz von iRST gut verzichten.

Eine weitere wichtige Frage ist nun: Welche Raid-Variante ist für SSD-Arrays sinnvoll? Nach meiner Einschätzung ist das vor allem eine Frage des Geldbeutels. Überraschenderweise spricht das ggf. gegen den Einsatz von Raid-5- oder Raid-6-Arrays. Das ist Gegenstand des nächsten Artikels dieser Serie:

SSD Raid Arrays unter Linux – VII – problematische Aspekte von Raid-5-Arrays

 

SSD Raid Arrays unter Linux – V – SW-Raid vs. iRST-Raid – Boot-Unterstützung?

Posted on by

Im letzten Beitrag dieser Serie zu SSD-Raid-Arrays unter Linux

SSD Raid Arrays unter Linux – IV – OS und Daten auf demselben Raid-Array?

hatte ich mich mit der Frage auseinandergesetzt, ob wir eigentlich das Betriebssystem [OS] nicht auch auf einem Raid-Array unterbringen können oder sollten, das für hochperformante Datenzugriffe von Anwendungen vorgesehen ist. Ich habe dafür zwar wenig übrig; aber dennoch kann es Umstände geben, in denen man das Betriebssystem in einem (ggf. separaten) Raid-Array installieren muss oder will.

In einer solchen Situation könnte man größere Sorgen bzgl. der Boot-Unterstützung bekommen. Im Besonderen, wenn man vor hat, Linux-SW-Raids zu nutzen. Das Thema beim Booten ist ja immer:

Wer oder was findet eigentlich das Kernel-Image und eine ggf. notwendige Informationen zu einem initramfs, wenn das alles auf Partitionen eines Raid-Arrays liegt? Ggf. auch noch unter einem LVM-Layer versteckt? Der Kernel jedenfalls nicht – der ist zu diesem Zeitpunkt ja noch nicht geladen. Und wenn er geladen wäre, müsste er mit dem jeweiligen Raid-Verbund umgehen können. Dazu braucht er Treiber, sprich Kernel-Module, die er aus dem initramfs auslesen müsste. Wer aber stellt im Bootvorgang die “initram” auf Basis von File-Informationen bereit, die selbst auf einem Raid-Array liegen?

Braucht es da nicht schon irgendwelche magischen Kenntnisse des BIOS über das Raid-Layout? Und im Fall von Intel-Sata-Controllern, die in Mainboard-Chipsätze integriert sind: Braucht man dann nicht zwingend iRST-Technologie ? Und einen Layer in einem System mit (U)EFI-BIOS, der das Raid-Layout der Platten am Intel-Raid-Controller kennt?

Das sind berechtige Fragen. Evtl. Sorgen sind jedoch unbegründet.

Grub2 ist intelligent – dieser Bootmanager kann mit Linux-SW-Raid-Arrays, dortigen Partitionen und auch LVM umgehen

Grub2 ist in den letzten Jahren so ertüchtigt worden, dass dieser Boot-Manager nicht nur mit verschiedenen Partionierungs-und Filesystem-Schemata, sondern auch mit verschiedenen Varianten von Linux-SW-Raids und auch mit LVM/LVM2 umgehen kann. Dass es dafür letztlich kein Hexenwerk benötigt, mag man daran erkennen, dass unter Linux sowohl Raid- als auch LVM-Informationen im Superblock der beteiligten Partitionen auf den einzelnen miteinander verkoppelten Platten bzw. Partitionen hinterlegt werden.

Auf Basis der dortigen Imformationen kann Grub2 die angelegte (komplexe und sich ggf. über mehrere Platten erstreckende Filesystemstruktur aufdröseln, von dort ein Kernel-Image laden und ein initramfs bereitstellen.

Ferner ist Grub2 ist in seiner EFI-Variante natürlich auch in der Lage, Boot-Informationen in EFI-Partitionen zu lesen bzw. über den Grub-Installer Boot-Informationen in EFI-Partitionen zu schreiben und auch den EFI-Bootmanager mit Informationen zur Boot-Reihenfolge und mit entsprechenden Zieladressen zu versorgen.

https://www.gnu.org/software/grub/manual/grub.html
https://wiki.gentoo.org/wiki/GRUB2/AdvancedStorage

Ist der Einsatz von iRST auf einem UEFI-System notwendig, damit Grub2 ein Linux-System aus einer Partition eines Linux-SW-Raid-Arrays oder eines imsm-Raid-Arrays booten kann?

Die Antwort ist: Mit Grub2 kann man Linux-Betriebsysteme auf einem UEFI-System von beiden Raid-Varianten (SW-Raid und von iRST-imsm-Volumes) booten. Der Einsatz von Intels iRST-Technologie ist jedenfalls nicht erforderlich! Mann kann auch von Linux-SW-Arrays booten!

Das Aufsetzen des Betriebssystems auf einem reinen Linux-SW-Raid-Array ist nur geringfügig komplizierter als auf einem im BIOS
vorkonfigurierten iRST-Array. Allerdings sind ein paar Regeln zu beachten:

  1. Die efi-boot-Partition selbst darf nicht Bestandteil einer Linux-LVM– oder mdadm-Raid-Gruppe an Partitionen werden. Das erscheint logisch: Grub2 oder Linux müssen schon da sein, um LVM oder mdadm-Raids auswerten zu können. Das Grub2-Modul “grubx64.efi” wird ja aber gerade auf der EFI-Partition für den EFI-Bootmanager hinterlegt und von dort geladen.
  2. Die efi-Boot-Partition darf nicht Bestandteil des reinen SW-Raid-Arrays sein. Es gilt eine analoge Begründung wie beim vorherigen Punkt.
  3. Eine “initram” mit einem initramfs mit den notwendigen Treibermodulen für den Kernel ist erforderlich. Aber das wird von den meisten Linux-Installern sowieso im Zuge der Erstinstallation ordentlich prepariert.

Das bedeutet in der Praxis, dass ihr die EFI-Partition entweder auf eine separate SSD oder HDD Platte legen müsst, die nicht am vorgesehenen SSD-Raid-Verbund beteiligt ist. Oder aber: Ihr legt auf jeder der SSD-Platten, deren größere Roh-Partitionen man später in SW-Raid-Arrays unter mdadm einbinden will, zunächst eine kleine, ca. 170 MB umfassende Partition an; eine dieser Partitionen wird im Installationsvorgang bereits mit FAT formatiert und erhält dann die richtigen EFI-Einträge udn EFI-Module. Die anderen 170MB-Partitionen werden später per “”dd”-Kommando als Clones dieser ersten EFI-Partition mit Inhalten versorgt.

Keine dieser kleinen EFI-Partitionen auf den SSDs wird aber an den anzulegenden SW-Raid-Arrays beteiligt.

Grundsätzliches Vorgehen im Zuge der OS-Installation am Beispiel Opensuse

Auf einem laufenden Linux-System legt man SW-Raid-Arrays mittels mdadm-Befehlen auf der Kommandozeile an. Es lohnt sich jedenfalls, sich mit diesem Linux Raid-Tool und seinen Optionen auseinanderzusetzen. Wir gehen auf mdadm ganz konkret in einem späteren Blog-Beitrag ein. Eine etwas weniger mächtige Möglichkeit zur Anlage von SW-Raid-Arrays ergibt sich unter Opensuse aber z.B. auch der über den “YaST-Partitioner”; der kommt ja auch während einer Standardinstallation um Tragen.

Man beginnt bei der Installation zunächst mit der Anlage einer EFI-System-Partition [ESP] – z.B. unter “/dev/sda1”. Diese wird dann mit FAT formatiert. Unter Opensuse bietet der Installer über YaST-Module aber auch

  • eine grafisch unterstützte Konfiguration von mdadm-SW-Raid-Arrays aus verschiedenen unformatierten (Raid-)Roh-Partitionen unterschiedlicher HDDs/SSDs an,
  • und eine automatische Konfiguration des Grub2-Bootloaders unter Einbeziehung einer EFI-Partition an.

Partitionierungs- und mdadm-Befehle können während der Installation aber auch an einer Konsole (Wechsel etwa mit Ctrl-Alt-F2) abgesetzt werden. Das ist zu einer genaueren Parametrierung als mit YaST ggf. nötig. Der YaST-Partitioner bietet nämlich leider nicht alle für die Performance relevanten Raid-Konfigurationsmöglichkeiten als Optionen an! Eine Erstellung der Raid-Arrays über mdadm-befehle empfiehlt sich also unmittelbar vor Verwendung des YaST-Partitioners.

Der YaST-Partitioner erkennt dann die bereitgestellten Raid-Arrays und erlaubt deren weitere Bearbeitung.

Angelegte mdadm-SW-Arrays werden dann entweder direkt für bestimmte Filesysteme formatiert oder aber über LVM in Logical Volumes unterteilt und dann formatiert; geeignete Partitionen werden im Zuge der Plattenkonfiguration dann dem “/”- wie dem “/boot”-Verzeichnis zugeordnet und dort gemountet.

Die als EFI-Device mit Modulen auszustattende Partition (z.B. unter /dev/sda1) wird im weiteren Verlauf des Installationsprozesses ausgewählt, mit FAT formatiert und vom
Installer in den UEFI-Boot-Prozess eingebunden; der Grub2-Installer in seiner EFI-Variante schreibt die dafür notwendigen Infos in die ausgewählte EFI-Partition und der System-Installer nordet per “efibootmgr”-Kommando hinter den Kulissen auch das UEFI-Bootsystem richtig ein.

Installer wie YaST sorgen zudem dafür, dass das “initramfs” mit den notwendigen Kernelmodulen für den Umgang mit Raid-Arrays ausgestattet wird.

Warum mehrere EFI-Partitionen?

Der Grund, warum man letztlich mehrere EFI-Partitionen (je eine auf jeder SSD) erzeugt, ist eine Absicherung gegenüber einem Plattenausfall. Man kopiert dazu nach einer Installation die Inhalte der auf “/dev/sda1” angelegten EFI-Partition mittels des Kommandos “dd” auf die vorbereiteten, noch leeren, aber für EFI vorgesehenen 170MB-Partitionen der anderen am Array beteiligten SSDs.

Die meisten UEFI-Systeme erkennen selbständig gültige ESPs; fällt die erste davon aus, wird automatisch die nächste gültige im Bootvorgang herangezogen. Man kann die Reihenfolge der für den Bootvorgang heranzuziehenden ESPs aber auch gezielt vorgeben.

Hinweise darauf, wie man insgesamt zu verfahren hat, liefert etwa der folgende Artikel, der sich von Ubuntu auf andere Linux-Varianten verallgemeinern lässt:
http://askubuntu.com/questions/660023/how-to-install-ubuntu-14-04-64-bit-with-a-dual-boot-raid-1-partition-on-an-uefi

Ein vorkonfiguriertes iRST-Container-Volume würde das Leben bzgl. der EFI-Partition lediglich etwas vereinfachen: Da der iRST-Controller für UEFI-Systeme Boot-Unterstützung (Zwischenschicht) liefert, wird die EFI-Boot-Partition direkt als unabhängige Partition eines definierten “imsm”-Containers vorbereitet.

Hat man alles richtig gemacht, wird man feststellen, dass das EFI/Grub2-Gespann Linux-Betriebssysteme sowohl von reinen Linux-SW-Raid-Arrays als auch von iRST-Arrays bootet. Man hat das vor allem der Fähigkeit von Grub 2 zu verdanken, Files aus Raid- und LVM-Konfigurationen auszulesen.

Wir können somit Linux-Betriebssysteme und auch andere Daten auf einem Linux-SW-Raid-System bereitstellen – aber wir müssen das nicht unbedingt. Wer es dennoch tun will, kann trotzdem regulär booten!

Eine Fallgrube

Allerdings ist das “iRST/efi/grub2”-Geschäft manchmal auch mit unerwarteten Falltüren versehen:

Irrtümliches Löschen einer gültig beschriebenen EFI-Partition
Ein spezieller Fall ist der, dass man im Zuge einer OS-Installation auf einem neuen Raid-Array die Grub-Informationen nicht auf eine spezifische, neu angelegte EFI-Partition hat schreiben lassen – sondern den Grub-Eintrag auf eine bereits existierenden EFI-Partition (auf einer anderen Platte) anlegen ließ. Löscht man später wiederum irrtümlich diese ursprüngliche EFI-Partition, so geht im Bootprozess natürlich gar nichts mehr.

Mir ist das z.B. passiert, als ich das erste Mal mit einer OS-Installation auf einem SW-Raid experimentierte. Vorher lag die bis dahin gültige EFI-Partition auf einer separaten Platte und blöderweiser habe ich diese vorhandene Partition während der Installation anstelle der neu formatierten EFI-Partitionen auf den SSDs ausgewählt. Später habe ich diese Partition aber irrtümlich gelöscht, da ich ja Partitionen auf den SSDs für EFI vorgesehen hatte – aber nicht mit GRUB-Einträgen versehen hatte. Hat man dann keine weitere Partition mit einem gültigen grub-Eintrag mehr, so führt das ins Boot-Nirwana.

Ähnliches kann auch passieren, wenn parallel auch noch iRST-Container mit einer EFI-Partition vorhanden sind. Hat man die während der Installation eines OS auf neuen SW-Raid-Arrays ausgewählt, und vernichtet anschließend das iRST-Array, so kann man auch nicht mehr booten. Selbst wenn man auf anderen Platten noch gültige Grub-Boot-Einträge haben
sollte, so muss man den SATA-Controller im BIOS zunächst auf den AHCI-Modus umstellen (Storage-Einstellungen), um diese alten gültigen EFI-Boot-Einträge überhaupt finden zu können. Hier wird die iRST-Zwischenschicht offenbar auch mal zum Verhängnis. Ein Grund mehr, von vornherein nicht auf den iRST-Mechanismus zurückzugreifen.

Also: Bevor man Experimente mit der Installation eines Linux OS auf einem iRST-Raid oder auf einem SW-Raid-Array macht, vorab einen gültigen Grub-Boot-Eintrag für ein bereits existierendes Linux OS auf einer anderen Platte erstellen lassen.

Ich lege ach meinen ersten schlechten Erfahrungen vor solchen Experimenten auf irgendeiner unbeteiligten Platte meines Systems immer ein kleines Not-Linux an, dass ich zur Not von einer zugehörigen separaten EFI-Partition booten kann. Diese EFI-Partition rühre ich dann nie mehr ohne Not an. So kommt man wenigstens immer und auch nach Auflösung der experimentell angelegten RAID-Arrays oder Löschung zugehöriger EFI-Partitionen wieder in ein gültiges System. Hinweis: Manchmal muss dazu im EFI-Bootmanager (sprich im UEFI-BIOS die eingetragene Bootreihenfolge ändern).

Ein paar zusammenfassende Ratschläge

Folgende Ratschläge erscheinen mir deshalb bedenkenswert:

  • OS-Anlage – wenn möglich – am besten auf einer separaten SSD außerhalb des Raid-Systems.
  • Wenn ihr dennoch unbedingt einen Raid-Verbund mit OS auf dem Raid betreibt, so sorgt dafür, dass ihr ein zweites (!) boot- und lauffähiges OS auf einer separaten Platte (außerhalb des Raid-Verbunds) verfügbar habt. Legt auf dieser Platte (außerhalb des Raids) ebenfalls eine funktionierende EFI-Partition an. Schreibt dann vom sekundären OS einen funktionierenden Bootloader-Eintrag in genau diese EFI-Partition.
    Kurz gesagt: Sorgt dafür, dass ihr eine gültige EFI-Partition mit gültigen Grub-Einträgen auch außerhalb der am Raid-Array beteiligten Platten habt. Definiert dann die Boot-Prioritäten im BIOS. Viele UEFI-BIOS suchen bei Problemen automatisch die nächste valide efi-Partition. Ansonsten sollte man immer ein gutes Linux-Live-System parat haben.
  • Vergesst nicht, dass gerade bei SSDs der zunehmende gleichmäßige Verschleiß der Platten im Raid-Verbund die Wahrscheinlichkeit eines parallelen und zeitlich kurz hintereinander getakteten Ausfalls mehrerer Platten erhöht. Macht also von allem regelmäßig Backups. Das erspart einem im Ernstfall viel Ärger.

Ausblick

Ich habe versucht zu verdeutlichen, dass wir mit Grub2 auch auf UEFI-Systemen Linux-Systeme booten können, die auf einem Linux-SW-Raid-Array eingerichtet wurden. Weder aus Gründen der Boot-Unterstützung, noch aus Gründen der Performance (s. die früheren Artikel) ist also ein Rückgriff auf iRST-Technologie erforderlich.

Linux-SW-Raids bieten aber auch noch andere Vorteile – nämlich u.a. eine weitgehenden Flexibilität bei der Anlage verschiedener Raid-Arrays. Das ist das Thema des nächsten Beitrags dieser Serie:

SSD Raid Arrays unter Linux – VI – SW-Raid vs. iRST-Raid – Flexibilität?