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

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