Monthly Archives: November 2016

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?

 

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

Posted on by

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

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

hatte ich mich mit der Frage auseinandergesetzt, ob ein SSD-Raid-Array an einem Intel-Raid-Controller typischer aktueller Mainboards als iRST-Array oder nicht besser gleich als natives Linux-SW-Raid-Array erstellt werden sollte.

iRST bedeutet Intel Rapid Storage Technologie; wir hatten diese Technologie im letzten Artikel genauer beleuchtet. Aus Performance-Tests für sequentielle Read- oder Write-Zugriffe haben sich dabei keine Anhaltspunkte ergeben, die zwingend für den Einsatz der iRST-Technologie sprechen würden:

Ein natives Linux-SW-Raids mit dem gleichen Onboard-Controller im AHCI-Modus (!) liefert eine vergleichbare oder höhere Performance!

Nun könnte man aber noch Sorgen bzgl. der Boot-Unterstützung haben. Einige Leute werden ja mit dem Gedanken spielen, das Linux-Betriebssystem [OS] selbst auf dem zu konfigurierenden Raid-Array zu installieren.

Ich möchte diesen Wunsch nachfolgend zunächst kritisch hinterfragen, da die Platzierung des OS auf einem ggf. hoch belasteten Raid-Array zumindest einen zusätzlichen Komplexitätsgrad erzeugt. Im nächsten Blog-Beitrag sehe ich mir dann die Boot-Unterstützung genauer an.

Motive für die Installation des Betriebssystem auf einem Raid-Array?

Typische Motive für die Installation des Betriebssystems auf einer Partition des SSD-Raid-Arrays könnten sein:

Verbesserung der Ausfallsicherheit und potentieller Performance-Gewinn

Raid-10- oder Raid-5-Arrays können ja die Lese- und Schreibperformance eines Raid-Verbundes deutlich über die einer einzelnen SSD hinaustreiben! Bei angeblich guter Sicherheit gegenüber dem Ausfall einer einzelnen der beteiligten Platten! Warum das nicht nur für Datenzugriffe von Spezialanwendungen sondern gleich auch für normale operationale Lese- und Schreibzugriffe das Betriebssystems mit nutzen?

Aus meiner Sicht gilt jedoch :

Es gibt mehr gute Gründe gegen die Installation des OS auf einem Raid-Array für die Daten von Anwendungen als dafür. Auf gewöhnlichen Systemen empfiehlt sich eher eine Installation des OS auf einer separaten SSD. Auf Hochperformance-Systemen würde ich das OS zumindest auf einem anderen Array als einem High-Performance-Array für datenintensive Anwendungen anlegen.

Ich führe dafür nachfolgend ein paar Argumente an. Als Voraussetzung nehme ich ein Einsatz-Szenario an, in dem vor allem Datenzugriffe spezieller Anwendungen durch ein Raid-10- oder ein Raid-5-Array beschleunigt werden sollen. Das Raid-Array mit den zugehörigen Daten sei dabei einer regelmäßig hohen Belastung ausgesetzt. Wir nennen es nachfolgend “Last-Array”.

Das ist zwar eine spezielles Szenario; einige der angeführten Argumente sind jedoch auch in anderen Szenarien valide. Das gewählte Szenario zeigt zumindest auf, dass man über die Sinnhaftigkeit einer OS-Installation auf einem für Last ausgelegten Raid-Array nachdenken sollte.

Verbesserung der Ausfallsicherheit?

Aus meiner Sicht gilt ganz grundsätzlich:

Keine einzige Raid-Variante entbindet von regelmäßigen Backups!

Das liegt auf der Hand und ist für Zweifler so oft im Internet begründet worden, dass ich hier auf weitere Ausführungen verzichte.

Zu berücksichtigen ist ferner, dass die Wahrscheinlichkeit, dass gleich belastete SSDs in einem Raid-1/10/5-Verbund etwa gleichzeitig ausfallen werden, ziemlich hoch ist. Auf einem Raid-1, einem Raid-10- oder Raid-5-System darf genau nur eine Platte ausfallen. (Dass es bei Raid-10
Situationen gibt, in denen auch das noch verkraftbar ist, ändert nichts am Grundargument.) Da die Platten in solchen Raid-Verbünden einem in etwa gleichen Verschleiß ausgesetzt sind, wird auch ihr Lebensende etwa zum gleichen Zeitpunkt eintreffen – ggf. stirbt die zweite Platte noch während eines langwierigen Rekonstruktionsvorgangs. Bei einem nicht mehr rekonstruierbaren Raid-System muss man dann aber aber in jedem Fall auf Backups zurückgreifen können.

Ein Szenario mit dem OS auf einer separaten SSD oder einem separaten SSD-Array plus Backups ist demgegenüber also nicht unsicherer. Es reduziert aber die Komplexität und beinhaltet auch eine Lastentkopplung.

Komplexitätsreduktion und Lastentkopplung

Liegen das OS und das Root-Verzeichnis auf einer vom Last-Array separaten SSD bzw. auf einem separaten SSD-Array, so werden die Ausfallmöglichkeiten des Last-Arrays von denen der OS-SSD entkoppelt.

Zudem kommt es zu einer Entkopplung der Last und damit des Verschleißes: Ein hoher Verschleiß der SSDs des Last-Arrays für High-Performance-Anwendungen schlägt sich nicht 1 zu 1 auf die SSD oder das separate SSD-Array des OS nieder. Und ggf. vice versa.

Zudem werden die Strukturen einfacher und flexibler, auch wenn das zunächst nicht den Anschein hat: Nicht ohne Grund mountet man von Haus aus Datenpartitionen oder spezielle Anwendungspartitionen auf bestimmte Zweige des Verzeichnisbaums. Das ermöglicht separate Backups und im Fall von System-Upgrades bleibt die Datenhaltung völlig außen vor. Man denke etwa an Datenbank-Daten, imap-Daten, die Partitionen virtualisierter Systeme etc., die man ggf. auf dem Last-Array platziert hat.

Fällt das Last-Array aus oder degradiert, ist nicht das OS betroffen. Fällt dagegen die SSD des OS aus, kann man das Array sofort wieder auf das Rootverzeichnis eines OS auf einer Ersatz-SSD mounten.

Die Rekonstruktion eines Raid-Arrays erfordert ein laufendes Betriebssystem – eine schnelle Rekonstruktion ein OS auf einer separaten Platte!

Es ergibt sich ein weiterer Punkt, über den man nachdenken sollte:

Hat das Raid-System einen Schaden oder fällt es gar ganz aus, will man trotzdem zeitnah booten können. Die Rekonstruktion eines (SW-) Arrays und das Monitoring dieses Prozesses setzen meist ein laufendes Linux-System voraus. Es ist also durchaus sinnvoll, das OS auf einer separaten SSD oder einem separaten (kleinen) Raid-Array zu halten.

Das Betriebssystem selbst ist bei vernünftiger Partitionierung relativ klein; bei Ausfall der OS-Platte oder -Partition ist es auf einer separaten Ersatzplatte sehr viel schneller rekonstruiert als ein großes Raid-System insgesamt.

Die Rekonstruktion eines defekten degraded Raid-Arrays aus einem auf dem Raid selbst liegenden OS heraus dauert ggf. sehr lange: Eine von Haus aus schlechte Restaurierungs-Performance von z.B. Raid-5-Arrays würde durch den laufenden OS-Betrieb im beschädigten Raid-Verbund noch einmal verschlechtert. Laufende Schreibprozesse aus dem Betriebssystem interferieren mit der Array-Rekonstruktion und können über die heranzuziehenden Paritätsalgorithmen auch nur langsam an das (noch) beschädigte Raid-Array übertragen werden.

Performancegewinn für das Betriebssystem durch RAID?

Linux puffert den normalen Festplattenzugriff so gut, dass man aus meiner Sicht nicht zwingend ein SSD-Array für eine hinreichend gute Basisperformance des Linux-Systems benötigt. Das sieht für spezielle Anwendungen oder etwa einen hochbelasteten Fileservice ggf. anders aus. Für das Kern-OS und seine Platteninteraktionen selbst genügt eine einzelne SSD bei möglichst großem RAM jedoch völlig. Das gilt umso mehr, als gerade bei kleineren Datenpaketen die Raid-Performance je nach Parametrierung sich nur wenig von der perfromance einer SSD abheben mag. Ich werde auf diesen interessanten Punkt in späteren Artikeln zurückkommen.

Beeinträchtigung der Performance eines Last-Raid-Arrays durch ein dort installiertes OS?

Nach meiner bisherigen Erfahrung gilt:

Würde man das OS auf einer Partition eines vorgesehenen (Daten-) Raid-Arrays installieren, so hätte das spürbaren (!) Einfluss auf die Gesamt-Performance dieses Last-Array und dessen Latenz. Random I/O-Prozesse des OS interferieren dann mit denen der Anwendungsprozesse, die man ja eigentlich mit Hilfe des Raid-Systems performanter machen will. Ich habe im Mittel etwa 10% an Performance-Einbußen durch Tests von Arrays mit aktivem OS nachvollziehen können. Für Datenbankanwendungen wie Fileservices, die verschieden konfigurierte Last-Arrays nutzten.

Man sollte das auf seinen eigenen Systemen in jedem Falle überprüfen.

Separates Raid-System für das OS?

Die Frage, ob das OS auf einem (separaten) Raid-System liegen soll, hängt letztlich auch von der Anzahl erstellbarer Raid-Arrays (bzw. im Fall des iRST von der Anzahl separat erstellbarer Container) und damit vom Geldbeutel ab. Ich sehe für eine Installation des OS auf einem Raid-Array, das primär für performanten Daten-I/O bestimmter High-Performance-Anwendungen gedacht ist, keinen überzeugenden Grund. (Es sei denn, man möchte aus irgendwelchen Eitelkeiten heraus extrem schnelle Bootzeiten produzieren.)

Will man das OS aber aus Gründen einer verbesserten Ausfallsicherheit auf einem SSD-Array anlegen, dann bitte auf einem separaten Array (bzw. beim iRST: auf einem Volume eines separaten Containers); dieses Array sollte nicht auch gleichzeitig die Daten geplanter Hochperformance-Anwendungen beherbergen.

Unbestritten ist: Ein separates Raid-10-System mit ggf. hochwertigen Enterprise SSDs ist ein guter Ort für das OS eines Hochperformance-Systems – wenn man denn das dafür nötige Kleingeld hat.

Rücksichtnahme auf Lastprofile!

Ein Raid-System für ein OS erfordert aus Performancegründen ggf. eine andere Parametrierung als ein Last-Array für die Daten von Anwendungen mit einer ganz bestimmten Zugriffs-Charakteristik. Ein Lastprofil, das laufend durch kurze einzelne aufeinander folgende I/O-Spikes für kurze Datenblöcke (< 64KB) gekennzeichnet ist (OS oder bestimmte DB-Anwendungen), ist anders zu bewerten als ein Lastprofil, bei dem viele Jobs parallel große Datenpakete (> 1 MB) auf und von einem Raid-System befördern müssen (Fileserver) oder gar ein Profil, auf dem große Videodateien (> n x 10MB) sequentiell verarbeitet werden.

Entsprechend unterschiedlich sollten zugehörige Raid-Systeme konfiguriert werden. Ich komme darauf in weiteren Artikeln zurück. Auch dieser Punkt spricht für die Trennung des Last-Arrays von Arrays für das OS.

Lösungsansatz: Wie gehe ich persönlich vor?

Sieht man einmal von puren Performance ab, so ist aus den obigen Gründen in vielen Fällen ein Vorgehen sinnvoll, bei dem das OS samt Root-Filesystem auf einer vom Raid-Verband unabhängigen SSD liegt und das Last-Array auf ein Spezialverzeichnis gemountet wird. Zudem ist für eine hinreichende RAM-Ausstattung des Systems zu sorgen. Zu finanzieren ist ferner eine Ersatz-SSD.

Für dieses Vorgehen gilt:

  • Es reduziert Komplexität im Bootvorgang.
  • Es kann durch Einsatz einer weiteren Ersatz-SSD, die mit einer boot- udn laufenden OS-Installation versehen wird, gegen Ausfälle der OS-SSD abgesichert werden. Die Ersatz-SSD kann gegen Verschleiß weitgehend geschont werden; sie muss erst im Notfall mit einem aktuellen OS-Abbild aus einer Sicherung, die z.B. täglich auf konventionellen Medien (HDD) hinterlegt wurde, versehen werden. Ein solcher Transfer dauert heutzutage nur wenige Minuten. Tipp am Rande: Die Identifikation der OS-Platten im Boot-Loader in diesem Szenario eher konventionell, also neutral und nicht über eindeutige Device-IDs, vornehmen.
  • Eine
    eintretende Degradierung des Last-Arrays durch einen SSD-Ausfall betrifft nicht die Operabilität anderer Systembestandteile. Mit einem “degraded SSD-Spezial-Array” kann man sich dann kontrolliert von einem immer noch funktionierenden separaten OS aus befassen.
  • Die SSD für das OS sollte aber Enterprise-Qualität haben und seitens des Herstellers gegen schnellen Verschleiß gewappnet sein.

Käme es auf Geld nicht an, würde ich auf manchen Systemen dem OS und der Root-Partition ein eigenes Raid-10-Array spendieren.

Ausblick

OK – man hat schon gemerkt: Ich halte nicht viel davon, das OS auf einem Raid-Array für die Daten von Hoch-Performance-Anwendungen unterzubringen. Aber manch einer hat entweder so viel Geld, dass er sich ein separates, dediziertes SSD-Raid-Array für das Betriebssystem leisten kann. Oder manch einer ist aus anderen Gründen gzwungen, das OS im einzigen vorhandenen SSD-Raid-Array zu installieren (z.B. auf einem Laptop). dann stellt sich die Frage:

Wird das Booten eines OS in einem Linux-SW-Raid-Array überhaupt unterstützt? Oder ist man hier beim Einsatz von Mainboards mit Intel Chipsatz auf iRST angewiesen?

Darum dreht sich der nächste Artikel dieser Serie:
SSD Raid Arrays unter Linux – V – SW-Raid vs. iRST-Raid – Bootunterstützung?