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

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?

 

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

In den ersten beiden Beiträgen zu SSD-Raid-Arrays unter Linux

SSD Raid Arrays unter Linux – I – ein facettenreiches Thema
SSD Raid Arrays unter Linux – II – Hardwarecontroller ?

hatte ich angekündigt, die Frage zu beantworten, ob sich auf einem Linux-System der Einsatz des Intel-Z170-SATA3-Controllers als iRST-Controller im Gegensatz zur Erstellung eines nativen Linux-SW-Raids lohnen würde.

iRST bedeutet Intel Rapid Storage Technologie; sie erlaubt eine Bündelung von Platten, die an den Z170-Onboard-Controller angeschlossen sind, zu einem Raid-Verbund (Raid 0, 1, 10, 5, 6) – und zwar erfolgt die Konfiguration dabei über BIOS-Funktionalitäten.

Einen iRST-fähigen Raid-Controller findet man im Moment auf vielen aktuellen Consumer-Mainboards mit Intel-Chipsätzen vor. Ein Beispiel liefert das von mir auf einem Testssystem eingesetzte Board “ASRock Z170 Extreme 7”.

Die vorweggenommene Antwort auf die Eingangsfrage ist aus meiner Sicht: Nein – zumindest nicht aus Performancegründen.

Das gilt, obwohl einfache Performance-Tests für RAID 10-Arrays zunächst das Gegenteil anzudeuten schienen.

Grundsätzliche Anmerkungen zur Intel RST Technologie

Intels Z170 SATA3 Controller im iRST-Modus entspricht einem Raid-Fake-Controller mit minimaler Intelligenz – aber guter Boot-Unterstützung. Im AHCI-Modus behandelt der SATA3-Controller die angeschlossenen SSDs über das SATA3-Interface als einzelne Platten. Der iRST-Modus lässt sich im BIOS dagegen über die Option “Array” statt AHCI aktivieren. Die Platten werden dann zu einem sog. Container-Verband (Raid) zusammengeschlossen, auf dem wiederum Volumes definiert werden können.

Konfigurationsoptionen im (UEFI-) BIOS
Der iRST-Modus zieht eine Zwischenschicht zum (UEFI-) BIOS ein. Je nach Board, BIOS und OpRom-Einstellungen ist das iRST-Setup-Menü über eine spezielle Tastenkombination (Ctrl-I) während des BIOS Self-Tests oder durch einen Menüpunkt im UEFI-Interface selbst zugänglich. Oft unter “Advanced” – nach dem man vorher unter einem Punkt “Storage” (o.ä.) die Behandlung der SSDs von “AHCI” auf “RAID” umgestellt hat.

Eigenes Containerformat “imsm”
iRST benutzt für die Datenorganisation eines Raid-Verbunds ein eigenes Container-Metaformat (das sog. “imsm”-Format; man spricht von sog. “imsm”-Containern; dei Abkürzung steht für “Intel Matrix Storage Manager”). Ein Container bindet mehrere Platten zu einer Gruppe zusammen. Bei hinreichender Plattenanzahl können auch mehrere Raid-Container angelegt werden, die sich über jeweils unterschiedliche, disjunkte Gruppen von vorhandenen Platten erstrecken. Hat man einen Raid-10-Verbund als Ziel und nur 4 Platten zur Verfügung, so ist jedoch bereits mit einem Container das Ende der Fahnenstange erreicht.

Genau zwei Volumes pro Container
Ein imsm-Raid-Container, der sich über n definierte Platten hinweg erstreckt, kann genau zwei sog. Raid-Volumes (entspricht landläufigen Raid-Arrays) enthalten.

Für das erste Volume ist die Kapazität (also die Größe in MByte) noch festlegbar; das zweite nutzt dann aber den kompletten Rest der verbliebenen Container-Kapazität. Die einmal definierten Kapazitäten sind im Nachhinein nicht dynamisch veränderbar. Das ganze Raid-System ist bei notwendigen Modifikationen neu anzulegen.

Die zwei möglichen Volumes erstrecken sich über dieselbe Anzahl an Platten; sie können aber 2 verschiedenen Raid-Levels (z.B. Raid 1 und
Raid 10) zugeordnet werden (das ist gerade das Kennzeichen der Intel Raid Matrix Technologie).

Ein Volume – also ein Raid Array – steht unter Linux (mit aktiven Raid-Modulen) dann als ein partitionierbares Block-Device zur Verfügung.

Der/die Raid-Container mit jeweils maximal 2 Raid-Volumes können bereits im (UEFI)-BIOS (über ein OpROM Optionsmenü für Storagesysteme) erstellt werden. Die Möglichkeit zur Anlage von Raid-Containern und Arrays über BIOS-Funktionen ist im Besonderen für Dual-Boot-Systeme mit Windows nützlich.

Anlage von imsm-Containern über mdadm unter Linux
Auf einem reinen Linux-System kann man Container wie Volumes im laufende Betrieb aber auch über das Raid-Administrations-Tool mdadm erstellen und verwalten – unter Angabe des imsm-Metadaten-Formats (mdadm-Option “-e imsm”). Bei Linux-Installern, die während des Install-Prozesses den Rückgriff auf Terminals erlauben, geht das auch während des Installierens.

So weit, so gut. Es ist auf den ersten Blick durchaus bequem, bereits vor einer Linux-Installation die Raid-Arrays über UEFI-BIOS-Funktionen anzulegen, um sie dann schon während der Installation als einfache Pseudo-Laufwerke vorzufinden, die man direkt formatieren kann. Unter Opensuse Leap 42.1/42.2 klappt das ohne Probleme.

Die Volumes der angelegten Container sind auf einem Dual-Boot-System auch von der Windows-Installation aus ansprechbar, formatier- und bootbar. Das ist ein echter Vorteil des iRST.

Links zu iRST
Details zu iRST – im Besonderen zur Einrichtung unter Linux mit Hilfe von mdadm – findet man hier:
http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/rst-linux-paper.pdf
https://en.wikipedia.org/wiki/Intel_Matrix_RAID
http://www.intel.de/content/www/de/de/support/boards-and-kits/000005789.html
http://www.intel.de/content/www/de/de/support/boards-and-kits/000006040.html
http://www.intel.com/content/dam/support/us/en/documents/solid-state-drives/RSTe_NVMe_for_Linux_SW_User_Guide.pdf
http://www.intel.com/content/dam/support/us/en/documents/
chipsets/rste/sb/intelr_rste_linux.pdf

Wie intelligent ist iRST wirklich? Ist ein iRST-Controller unter Linux ein Fake-Controller?

Es stellen sich die Frage:

  • Wer oder was steuert eigentlich bei einem laufenden Betriebssystem [OS] die Datenverteilung auf die Platten? Das Betriebssystem [OS] oder der iRST-Controller?

Hierzu ist Folgendes zu sagen:

Die Funktionalität der definierten Container und ihrer Arrays hängt völlig von den Treibern und den Fähigkeiten des gebooteten Betriebssystems ab. Der iRST wird unter Linux durch angepasste Komponenten/Module des “md”-Raid-Systems und administrationsseitig durch mdadm unterstützt. Ohne eine vorhandene Linux-Steuer-SW und zugehörige Kernel-Module (u.a. md_mod, raid5, raid10, etc.) bringt iRST unter Linux gar nichts.

Ein iRST-Controller ist also tatsächlich ein sog. Fake Controller:

Die Hauptarbeit wird nicht durch den Controller selbst, sondern durch das Betriebssystem und zugehörige Software (Treiber) geleistet. Es ist deshalb zwar nicht ausgeschlossen, aber zumindest unwahrscheinlich,
dass der in mdadm integrierte spezielle iRST/imsm-Treiber unter Linux besondere Performancevorteile gegenüber einem reinen, nativen SW-Raid, das man auch mit mdadm aufsetzt, bieten wird.

Raid 10 aus 4 SSDs – sequentielle I/O-Performance mit und ohne iRST

Wir betrachten nachfolgend die Performance eines mit Hilfe des Z170-iRST-Controllers erstellten Raid10-Verbands aus 4 850 EVO SSDs von Samsung. Verglichen wird das iRST-Raid-Array mit einem reinen Linux-SW-Raid-Array, das mit denselben Platten aufgesetzt wurde.

Das Betriebssystem lag in beiden Fällen auf einer separaten SSD und nicht auf einer Partition des Raid-Verbunds. (Das gibt uns im Schnitt mindestens 10% Performance-Vorteile.)

Bei der Erstellung des iRST-Raid10-Volumes habe ich mich an die Default-Chunksize gehalten, die die BIOS Funktionen angeboten werden.

Default Chunk-Size des iRST: 32 KB

Ein Hinweis für diejenigen, die die Tests konkret nachstellen wollen:

Für die SW-Raid-Konfigurationen unter Linux sollte man den Controller in den AHCI-Modus für den SSD-Zugriff versetzen! Dies ist i.d.R. über eine Option im BIOS möglich!

An dieser Stelle mag ein Blick auf Daten des Test-Tools “gnome-disks” genügen. Ich zeige hier Daten für Lese/Schreib-Zugriffe für relativ große sog. “Messwertgrößen” – was immer das genau bei diesem Test intern bedeutet. Aus bestimmten Gründen glaube ich nicht, dass es sich bei der “Messwertgröße” um die Blocksize von einzelnen Datenpaketen handelt; das verträgt sich nämlich nicht mit Daten aus anderen Tests. Aber im vorliegenden Artikel kommt es mir ja nur auf relative Verhältnisse an! Differenziertere und genauere Tests, die ich später mit dem Tool “fio” durchgeführt habe, ändern übrigens nichts am Ergebnis des hier präsentierten Vergleichs des iRST-Raids gegenüber einem Standard SW-Linux Raid.

Die untersuchten Partitionen waren (soweit nichts anderes angegeben ist) in beiden Fällen als LVM-Volumes erstellt worden.

Daten für den iRST-Controller – 20 MB “Messwertgröße”
irst_raid_ssdroot_20mb

Daten für ein reines Linux SW-Raid – 20 MB “Messwertgröße”
swraid_ssdroot_20mb

Die bereits hier erkennbare Tendenz etwas höherer Lese- und geringerer Schreibraten wird scheinbar noch deutlicher bei kleineren “Meßwertgrößen”:

Daten für den iRST-Controller – 1 MB “Messwertgröße” – nach TRIM
irst_raid_ssdroot_1mb_after_trim

Daten für den iRST-Controller – 1 MB “Messwertgröße” – Sättigung
irst_raid_ssdroot_1mb

Dagegen:
Daten für eine reines Linux SW-Raid – 1 MB “Messwertgröße” – Sättigung
swraid_ssdroot_1mb

Zwischenergebnis:

Die obigen Daten wirken so, als ob ein reines SW-Raid unter Linux langsamer sei. Der
gemessene Unterschied in der Schreibrate von bis zu 100 MB/sec bei 1MB Daten (vermutlich mit deutlich kleinerer Blocksize geschrieben) bei einem Minimalwert von 290 MB/sec wiegt auf den ersten Blick schwer und entspricht einem relativen Unterschied von ca. 34%.

Zudem wird die theoretisch mögliche reine Datenschreibrate einer einzelnen EVO 850 SSD (zw. 300 und 490 MB/s je nach Testsetup und Größe der zu schreibenden Blöcke) durch das Raid-System bereits unterschritten.

Aber ist dieser Befund tatsächlich valide?

iRST-Performance-Vorteile ?

Bringt der iRST-NModus des Intel SATA-3-Controllers gegenüber einem reinen SW-Raid doch spürbare Vorteile? Nein, das obige Ergebnis täuscht in zweierlei Hinsicht.

Nachfolgend betrachten wir zunächst die Daten für ein besser parametriertes reines SW-Raid-System: Die Performance wird nun mit der des iRST-Arrays vergleichbar wird.

Bei den nachfolgenden Abbildungen ist ferner zu beachten, dass die Unsicherheit der Daten (u.a. durch nicht getrimmtes Filesystem, interferierende Prozesse im OS) ca. 10 – 20 MB/sec ausmachen kann. Die dargestellten Abbildungen zeigen zufällige und nicht die in Tests zeitweise erreichten maximalen Werte.

Daten für besser parametriertes reines SW-Raid – mit LVM – 20 MB “Messwertgröße”
swraid_ssd_optimiert_20mb_with_lvm

Daten für besser parametriertes reines SW-Raid-Array – ohne LVM – 20 MB “Messwertgröße”
swraid_ssd_optimiert_20mb_without_lvm

Daten für besser parametriertes reines SW-Raid-Array – mit LVM – Chunk Size: 16KB – 20 MB “Messwertgröße”
swraid_ssd_optimiert_16k_20mb_with_lvm

Für die Messgröße 1MB betrachten wir nun mal den Einfluss der sog. Chunk-Size des Arrays etwas genauer:

Daten für ein besser parametriertes reines SW-Raid-Array – ohne LVM – Chunk Size: 512KB – 1 MB “Messwertgröße”
swraid_ssd_optimiert_512k_1mb_without_lvm

Daten für ein besser parametriertes reines SW-Raid-Array – mit LVM – Chunk Size: 64KB – 1 MB “Messwertgröße”
swraid_ssd_optimiert_64k_1mb_with_lvm

Daten für besser parametriertes reines SW-Raid-Arrays – mit LVM – – Chunk Size: 32KB – 1 MB “Messwertgröße”
swraid_ssd_optimiert_32k_1mb_with_lvm
 
Die letzten Bilder deuten bereits an, dass die Chunk-Size eines Raid-Arrays gerade bei kleineren Datenblöcken offenbar einen größeren Einfluss auf die Performance – und im besonderen die Write-Performance – hat. Wir kommen hierauf in detaillierterer und systematischer Weise in einem späteren Beitrag zurück.

Der Einsatz von LVM als Zwischenschicht zwischen Partitionen und Filesystem der LVM-Volumes fällt
dagegen kaum ins Gewicht.

Ich darf an dieser Stelle verraten, dass für die Annäherung an die bzw. das Übertreffen der iRST-Werte genau eine kleine Änderung bei der Erstellung des SW-Raids eine wesentliche Rolle spielte. Siehe hierzu einen der nächsten Beiträge in dieser Serie.

Die Graphiken zu den Schreibraten täuschen aber auch in anderer Hinsicht:

Sie geben nicht die tatsächlich erreichbaren Schreibraten wieder. Ein differenzierter und genauer einstellbarer Test mit dem Tool FIO liefert ganz andere und deutlich höher Schreibraten für Datenpaketgrößen von 1 MB. Ich komme hierauf in einem späteren Artikel der Serie zurück. Die “gnome-diskd”-Ergebnisse für die erreichbaren Schreibraten sind aus meiner Sicht also mit einem Fragezeichen zu versehen.

Ist der Einsatz des iRST-Modus des Intel Z170-SATA3-Controllers notwendig für eine optimale SSD-Performance?

Die Antwort auf Frage ist klar Nein. Die obigen Daten belegen, dass Performance-Aspekte keinen Grund für oder gegen den Einsatz des iRST-Modus darstellen. Sie sprechen eher für den Einsatz eines reinen SW-Raid-Systems unter Linux:

Richtig konfiguriert, erreicht man bei den Schreibraten mindestens die Werte des iRST und in der Leserate übertrifft man sie regelmäßig.

Kein Argument für oder gegen den iRST-Einsatz stellt aus meiner Sicht zudem die CPU-Belastung dar. Ich konnte keine substanziellen Unterschiede erkennen:

Auf einem Linux-System mit 4 CPU Cores (i7 6700K) und Hyperthreading ist die CPU-Belastung für die 8 CPU-Threads außerhalb von (Re-)Sync-Phasen in der Praxis unerheblich, solange nicht viele große Raid-Verbände angesteuert werden müssen. Die Raid-Behandlung (Striping etc.) erfolgt in aktuellen Kerneln (seit Version 3.12) zudem multi-threaded.

Ausblick

Genug für heute. Im nächsten Artikel

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

gehe ich ein wenig auf die Datenverteilung ein. Sollte man z.B. das Betriebssystem samt root-Verzeichnis auf demselben Raid-Array installieren, das für hochperformante Datenzugriffe von Spezialanwendungen gedacht ist? Ich werde einen solchen Lösungsansatz kritisch hinterfragen.

Auf einem UEFI-System könnte sich anschließend folgende Frage stellen:

Muss nicht schon das UEFI-BIOS das Intel-RAID-System des Z170-Controllers genau kennen, damit über Grub2 ein Linux-OS, das auf einem SSD-Raid-Array am Intel-Controller installiert wird, anstandslos gebootet werden kann? Ist deswegen nicht zwingend iRST erforderlich?

Wir werden aber in einem kommenden Beitrag

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

sehen, dass diese Sorgen ganz unbegründet sind.