SSD Raid Arrays unter Linux – Optimiertes SW Raid oder Intel RST Fake Raid? – II

Im ersten Beitrag zu SSD-Raid-Arrays unter Linux

SSD Raid Arrays unter Linux – Optimiertes SW Raid oder Intel RST Fake Raid? – I

hatte ich versprochen, die Frage zu beantworten, ob sich der Einsatz des Intel-Z170-SATA3-Controllers als iRST-Controller für reine Linux-Systeme lohnen würde. Einen solchen Controller findet man im Moment auf vielen aktuellen Consumer-Mainboards 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 bisherigen Sicht: Nein.

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

Grundsätzliche Anmerkungen zum Intel RST Controller

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 über die Option "Array" statt AHCI aktivieren.

Der iRST-Modus zieht eine Zwischenschicht zum (UEFI-) BIOS ein und benutzt für die Datenorganisation eines Raid-Verbunds ein eigenes Container-Metaformat (sog. "imsm"-Container). 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 Raid10-Verbund als Ziel und nur 4 Platten zur Verfügung, so ist bereits mit einem Container das Ende der Fahnenstange erreicht.

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 noch festlegbar; das zweite nutzt dann aber den kompletten Rest der verbliebenen Container-Kapazität. Die Kapazitäten sind im Nachhinein nicht veränderbar. Die zwei möglichen Volumes erstrecken sich über dieselbe Anzahl an Platten; die 2 Volumes können aber 2 verschiedenen Raid-Levels (z.B. Raid 1 und Raid 10) zugeordnet werden (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. 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.

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.

Auf einem reinen Linux-System kann man Container wie Volumes in einem laufenden System 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 anzulegen, um sie dann schon während der Installation als einfache Pseudo-Laufwerke vorzufinden, die man direkt formatieren kann. Man kann dann eine solche Partition als efi-Partition nutzen und auf einer weiteren Standard-Linux-Partition das Betriebssystem installieren. Unter Opensuse 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.

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

Fragen

Es stellen sich sofort zwei Fragen:

  • Wer oder was steuert eigentlich bei einem laufenden Betriebssystem [OS] die Datenverteilung auf die Platten? Das OS oder der iRST-Controller?
  • Will man als Linuxer das OS überhaupt auf einer Partition eines [iRST-] Raid-Arrays installieren?

Zur ersten Frage: Die Funktionalität der definierten Container und ihrer Arrays hängt ganz von 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 die Steuer-SW und zugehörige Module (u.a. md_mod, raid5, raid10, etc.) unter Linux geht gar nichts.

Eigentlich ist der iRST also 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-Treiber unter Linux besondere Performancevorteile gegenüber einem reinen, nativen SW-Raid, das man auch mit mdadm aufsetzt, bieten wird.

Zur zweiten Frage: Diese Frage ist eigentlich unabhängig von der Frage des Einsatzes eines iRST oder SW-Raids. Aus meiner Sicht gilt: Nein, man will keineswegs in jedem Fall das OS auf einer Partition des geplanten und möglicherweise einzigen SSD-Raid-Arrays installieren.

Dies gilt vor allem dann, wenn das geplante Raid-Array nicht die Ausfallsicherheit, sondern primär die Performance bestimmter I/O-lastiger Anwendungen verbessern soll.

Installiert man das OS direkt auf einer Partition eines vorgesehenen (Daten-) Raid-Arrays, so hat das spürbaren (!) Einfluss auf die Gesamt-Performance dieses Raid-Systems 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.

Die Frage, ob das OS auf einem Raid-System liegen soll, hängt deshalb aus meiner Sicht stark von der Anzahl erstellbarer Raid-Arrays (bzw. im Fall des iRST von der Anzahl erstellbarer separater Container) und deren Einsatzzweck ab. Ich sehe für eine Installation des OS auf einem Raid-Array, das primär für performanten Daten-I/O bestimmter Anwendungen gedacht ist, keinen vernünftigen Grund. (Es sei denn, man möchte aus irgendwelchen Eitelkeiten heraus extrem schnelle Bootzeiten produzieren.)

Will man das OS aber aus Gründen der Ausfallsicherheit auf einem SSD-Array anlegen, dann bitte auf einem separaten Array (bzw. beim iRST: auf einem Volume eines separaten Containers), das nicht auch gleichzeitig die Daten geplanter Hochperformance-Anwendungen beherbergt. Wenn es im OS Prozesse gibt, die substanziell vom I/O auf die SSDs abhängen (Beispiel Datenbanken), so sollte man versuchen, deren Datenhaltung ins Daten-Raid-System zu verschieben oder aber im RAM zu puffern. Im Falle produktiver High-Performance-Systeme ist das OS in der Regel auf einem separaten Raid 1-System mit ggf. teuren Enterprise SSDs viel besser aufgehoben als auf einem auf Performance Plattensystem aus Raid10-Gruppen. Auf Test- und Desktop-Systemen kann man das OS auch auf einer einzelnen normalen Enterprise-tauglichen SSD (mit regelmäßigen Backups) oder gar einer normalen Harddisk liegen, wenn man nicht zwingend superschnelle Bootzeiten haben muss.

Zudem gilt u.U., dass das Raid-System für das OS aus Performancegründen eine andere Parametrierung erfordert als ein Array für Daten von Anwendungen mit einer ganz bestimmten Last-Charakteristik. Ein System, das laufend durch kurze einzelne und sequentielle I/O-Spikes für kurze Datenblöcke (< 16KB) gekennzeichnet ist, benötigt andere Parameter als ein Raid-Array, das laufend viele parallele Anfragen nach unterschiedlichen Dateien ( > 1 MB) abdecken muss.

Und weiter gilt: Man muss ein OS auch booten können, wenn das Raid-System aus irgendeinem Grund mal ausfallen sollte. In meinem Test-System lege ich das Haupt-OS allein schon aus diesem Grund auf eine separate SSD und mache davon regelmäßige Backup-Abbilderper LVM-Snapshot auf ein Standard HDD-Raid10-System auf einem anderen Server. Das OS ist im Zweifel schnell aus einem Backup rekonstruiert. Mit einem "degraded Daten-Array" kann man sich dann kontrolliert von einem funktionierenden separaten OS aus befassen. Die Rekonstruktion eines defekten degraded Raid-Arrays aus einem auf dem Raid selbst liegenden OS heraus ist generell keine gute Idee. Eine von Haus aus schlechte Restaurierungs-Performance von Raid-5-Arrays würde dadurch noch schlechter.

Wann immer man mit Raid-Systemen operiert, gilt übrigens:

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. Nun aber zurück zum Einsatz eines iRST-Controllers.

Raid 10 aus 4 SSDs - sequentielle Performance mit dem 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

An dieser Stelle mögen die Daten des Test-Tools "gnome-disk" genügen. Ich zeige hier Daten für Lese/Schreib-Zugriffe für relativ große sog. "Meßwertgrößen" - was immer das genau bei dem Test intern bedeutet. Aus bestimmten Gründen glaube ich nicht, dass es sich um die Blocksize handelt, mit der die Datenmenge der "Meßwertgröße" geschrieben wird; das verträgt sich nicht mit Daten aus anderen Tests. Aber es kommt ja hier nur auf relative Verhältnisse an.

Die untersuchten Partitionen waren in beiden Fällen mit LVM erstellt worden, wenn nichts anders angegeben ist.

Differenziertere und genauere Tests, die ich später mit dem Tool "fio" durchgeführt habe, ändern nichts am Ergebnis des hier präsentierten Vergleichs des iRST-Raids gegenüber einem Standard SW-Linux Raid.

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 denn doch 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 schwer und entsprciht 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. Nachfolgend die Daten für ein besser eingestelltes SW-Raid-System, das dann mit dem iRST-Array vergleichbar wird.

Bei den nachfolgenden Abbildungen ist 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 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.

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

Die Antwort auf Frage ist 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 und Hyperthreading (i7 6700K) 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 3.12) multi-threaded.

Ist der iRST notwendig für Boot-Unterstützung und Grub2 auf einem reinen Linux-System?

Die Frage ist eigentlich nur für den Fall relevant, dass man das OS auf dem Raid-Array selbst installieren will. Was ich - wie oben erläutert - für keine gute Idee halte. Aber selbst dann ist die Antwort Nein.

Das Aufsetzen des Systems ist im Falle eines reinen SW-Raids nur ein wenig komplizierter - und es sind ein paar Regeln zu beachten:

  • Die efi-boot- Partition darf aber nicht Bestandteil einer Linux-LVM-Gruppe an Partitionen werden. Das erscheint logisch: Linux muss schon da sein, um LVM z.B. von einem initRAMFS aus zu nutzen. Die Grub und efi-Informationen werden aber vorab ausgewertet und müssen ohne LVM zugänglich sein.
  • Die efi-Boot-Partition darf nicht Bestandteil des reinen SW-Raid-Arrays sein. Es gilt eine analoge Begründung wie beim vorherigen Punkt.
  • Ein initramFS mit den notwendigen Treibermodulen ist erforderlich. Aber das wird von den meisten Linux-Installern sowieso ordentlich prepariert.

Das bedeutet in der Praxis, dass ihr die efi-Partition entweder auf eine andere Platte legt, die nicht am Raid-Verbund beteiligt ist. Oder ihr legt jeder der Platten, die man z.B. in einen SW-Raid 1- oder Raid 10-Verbund einbinden will, zunächst eine kleine, ca. 170 MB, efi-Partition an, die ihr mit FAT formatiert (aber später eben nicht in das SW-Raid-Array einbindet).

Um Ausfallsicherheit zu gewährleisten, kopiert man später die bei der Installation z.B. auf /dev/sda1 angelegte efi-Partition nach einigen wenigen Änderungen mittels des Kommandos dd auf die vorbereiteten efi-Partitionen der anderen am Raid-Verbund beteiligten Platten. Hinweise darauf, wie man hierbei im Prinzip 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
Grub2 in der efi-Variante schreibt die notwendigen Infos in die efi-Partition. Das muss allerdings so geschehen, dass die root-Partition auf dem Raid-Systen in neutraler Weise angesprochen wird.

Der iRST-Controller macht bzgl. der efi-Partition das Leben etwas einfacher: Da der iRST-Controller für UEFI-Systeme Boot-Unterstützung (Zwischenschicht) liefert, kann die efi-Boot-Partition dann auch auf einer Partition des vordefinierten Raid-Arrays eines imsm-Containers installiert werden.

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

Ein spezieller Fall ist der, dass man ggf. im Zuge einer OS-Installation auf dem iRST-Raid-System die Grub-Informationen von vornherein nicht auf eine spezifische neue Partition hat schreiben lassen - sondern einen Grub-Eintrag auf einer bereits existierenden efi-Partition (auf einer anderen Platte) mit den neuen Informationen überschrieben hat. Hat man dann keine weitere Partition mit einem gültigen grub-Eintrag mehr, so führt eine anschließende Auflösung des iRST-Raid-Containers offenbar ins Boot-Nirwana.

Selbst wenn man auf anderen Platten noch gültige Grub-Boot-Einträge haben sollte, so muss man 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 zurückzugreifen.

Also: Bevor man Experimente mit dem iRST-Raid macht, vorab einen gültigen Grub-Boot-Eintrag für ein anderes Linux OS auf einer anderen Platte erstellen lassen. Die entsprechende efi-Partition mit ihren Grub-Informationen bei den kommenden Experimenten NICHT überschreiben, sondern eine andere, vorbereitete efi-Partition verwenden. So kommt man wenigstens immer und auch nach Auflösung des RAID-Verbundes wieder in ein gültiges System.

Meine Ratschläge sind aber auch bei Einsatz eines reinen Linux-SW-Raids:

  • OS-Anlage außerhalb des Raids.
  • Wenn ihr dennoch unbedingt einen Raid-Verbund mit OS auf dem Raid betreibt, so sorgt dafür, dass ihr ein 2-tes 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 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.

Gegenargumente gegen den Einsatz des Intel RST Controllers auf reinen Linux-Systemen

Es gibt aus meiner Sicht folgende valide Gegenargumente gegen den Einsatz des iRST-Controllers:

  1. Im Kern handelt es sich auch nur um ein SW-Raid. Ich konnte bei entsprechenden Maßnahmen keine Performance-Vorteile erkennen.
  2. Reduzierte Flexibilität: Es geht einem im vergleich zu den Konfigurationsmöglichkeiten von SW-Raids viel, viel Flexibilität verloren. Das sollte man in der Praxis nicht unterschätzen. So lässt der iRST genau 2 Raid-Arrays (Volumes) per Container zu - und der zweite anzulegende Verband kann in seiner Kapazität aber nicht mehr begrenzt werden. Er wird den gesamten verbliebenen Platz der bereits einander zugeordneten Container Platten beanspruchen.

    "mdadm" unter Linux erlaubt dagegen die Erstellung beliebiger Arrays über gleiche oder unterschiedliche SSDs, genauer Partitionen, hinweg - und auch solche exotischen, aber performancesteigernden Dinge wie etwa ein Raid 10 über Partitionen von nur 2 SSDs! Die Kapazität eines jeden einzelnen Arrays darf dabei über den Platz der genutzten Rohpartitionen frei festgelegt werden.

  3. Die fehlenden Freiheiten bzgl. der Größenbegrenzung des zweiten Arras hat bei bestimmten Raid Levels, besonders aber im Fall von großen Raid-5- oder Raid-6-Arrays ergebliche Auswirkungen für evtl. Wiederherstellungsverfahren:
    Legt man wegen Punkt 1 zwangsweise ein iRST-Volume mit großer Kapazität an, so wird das Raid-Array 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 zwar, aber bei großen Arrays mit > 1 TB Kapazität zehrt das im Falle von Raid 5 trotzdem an den Nerven. Im Falle von RAID 5 wird dabei der Verschleiß der eingebundenen SSDs erheblich beschleunigt. Mehr dazu im nächsten Beitrag.
  4. Für Raid-5-Arrays unterstützt der aktuelle Z170-iRTS Controller (Version 14 der Firmware) nicht das Absetzen eines TRIM-Befehls [fstrim -v /MOUNT-VERZEICHNIS-EINES-FILESYSTEMS-DES-RAIDS]. Das wird nach einiger Zeit und im Besonderen auf kleineren Partitionen des Raid-Verbands zu Performance-Problemen führen. Das ist in der Praxis für viele SSD-Typen und auch die EVO 850 tatsächlich nachweisbar.
  5. Die Größe eines iRST-Raid-Arrays kann durch Hinzufügen von weiteren Partitionen im Nachhinein wohl nicht mehr verändert werden. Bei einem reinen SW-Raid unter Linux ist das über ein paar Schritte möglich (s. die mdadm-Literatur).
    Für einen imsm-Container ist mir das bislang mit Linux-Bordmitteln nicht gelungen. So war es mir u.a. nicht möglich, auf Platten, die bereits einem RTS-Verband im "imsm"-Format zugeordnet waren, neue Partitionen anzulegen, die ich einem bereits definierten imsm-Volume hätte zuordnen können.
  6. Bei einem Ausfall des iRST-Controllers oder des Mainboards benötigt man ein neues Mainboard-Board mit iRST-Funktionalität, um wieder an die Daten des Arrays zu kommen. Im Falle eines SW-Raids aktiviert man dagegen auf einem anderen Linux-System die md-Raid Module und hängt dann die SSD-Platten an die dort verfügbaren SATA-Controller. Und schon hat man wieder Zugriff.

Gegen den oben genannten Punkt 3 gibt es zwar begrenzte Mittel (sog. Bitmaps; siehe einen kommenden Beitrag) - aber die reduzieren nach meiner Erfahrung spürbar (!) die Write-Performance. Und Bitmaps helfen nur so lange, soweit noch alle Platten mit funktionierendem Filesystem vorhanden sind. Sie helfen nicht im Falle eines degraded Arrays, bei dem eine Platte ausgefallen ist.

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

Gibt es auch Gründe für den Einsatz des iRST?

Mir fallen dazu nur 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 Betriebsystem und/oder die efi-boot-Partition selbst auch unbedingt auf dem Raid installiert hat.
  • Auf Dual-Boot-Systemen bringt das Intel-spezifische "imsm"-Format Vorteile. Der Raid-Verbund selbst und entsprechend formatierte Partitionen können auch von Windows aus angesprochen werden.

Genug für heute. Im nächsten Artikel möchte ich begründen, warum ich iRST- oder SW-Raid-5-Arrays für SSDs unter Linux für gar keine gute Idee halte.

SSD Raid Arrays unter Linux – Optimiertes SW Raid oder Intel RST Fake Raid? – I

Ein neuer Test-PC für eine Kunden ist eine gute Gelegenheit, neue Technologie auszuprobieren. In diesem Falle einen SSD-Raid-Verbund. So etwas mache ich natürlich nicht zum eigenen Vergnügen. Ziel ist es, komplexe numerische Berechnungen für Kunden, die stark auf Daten einer oder mehrerer MySQL-Datenbanken mit Tabellen mit bis 100 Milionen Datensätzen zurückgreifen, für eine zumindest potentiell schnelle, aber begrenzte HW eines kleineren Servers zu optimieren. Oder umgekehrt - und nach meinen aktuellen Erfahrungen wohl ebenso wichtig - die Raid-Arrays auf ein bestimmtes Lastverhalten und andere Faktoren einzustellen.

Bzgl. SSDs hat sich in den letzten 2 Jahren ja viel getan; die aktuellen SSDs sind schneller, die preislich erschwingliche Kapazität ist größer geworden. Am wichtigsten ist aber, dass sich die Haltbarkeit verbessert hat. Das ist bei kleinen Unternehmen durchaus ein Punkt. Der Austausch von mehreren SSDs kostet ja nicht nur Geld für die HW, sondern auch Betriebsausfallzeiten und ggf. Aufwände externer Administratoren.

Mit einem Raid-Verbund aus SSDs besteht zumindest die Chance einer Performanceverbesserung auch von datenbankintensiven Anwendungen und höherer Ausfallsicherheit. Aber wie kann man SSD-Raid-Arrays unter Linux eigentlich kostengünstig nutzen - und auf was muss man dabei aufpassen ?

Arbeitet man sich in die Thematik ein, so merkt man schnell, dass das Thema eine Wissenschaft für sich ist. Und dann stößt man z.T. auf wirklich widersprüchliche Hinweise im Internet: Das schlimmste Beispiel sind Artikel zur sog. Chunk-Size eines Arrays. Da werden von Administratoren mal möglichst große Chunksizes im Bereich von 2 MB empfohlen, während andere möglichst kleine Size wischen 8 und 32 KB empfehlen. Jeweils natürlich mit unterschiedlichen Begründungen, die auf Anhieb nicht zur Deckung gebracht werden können und die Frage nach impliziten Vorurteilen bzgl. lastprofilen aufkommen lassen.

Ich habe nun mehrere Tage mit eigenen ersten Tests und viel Informationsbeschaffung verbracht - erst jetzt hat sich eine Entscheidung herauskristallisiert, wie ich im Moment vorgehen werde. Und ich werde mir dabei aus guten Gründen Reserven für weitere datenbankspezifische Experimente offen lassen. Auf dem Weg zu diesem Zwischenstand habe ich aber bereits mehrere Erkenntnisse gewonnen, die auch anderen helfen mögen, wenigstens ein paar essentielle Fehler und eine unkritische Übernahmen von Empfehlungen zu vermeiden. Der Leser sei gewarnt: Es kommen etliche Einflussfaktoren zum Tragen; das erfordert leider auch mehrere Posts.

Eigene frühere Raid-Erfahrungen und Vorurteile

Ich habe früher verschiedene 3ware HW-Controller (u.a. 9650SE) für Raid-Systeme mit gewöhnlichen Harddisks unter Linux eingesetzt. Insgesamt muss ich leider sagen, dass ich von den kleinen Controllern für 4 Harddisks nie wirklich überzeugt wurde. Weder beim Einsatz für Raid 1, Raid 10 oder Raid 5. 3ware bzw. später LSI-Controller waren dabei nicht gerade billig. Sie lieferten in Tests zwar gute Raten für das sequentielle Schreiben großer Files. Es gab aber in der Praxis immer wieder massive Einbrüche und manchmal unverständliche Verzögerungen, wenn viele kleine Schreiboperationen auftraten und dies ggf. von mehreren Prozessen gleichzeitig. Gerade auch beim Einsatz von Raid 1 und Raid 10. Siehe hierzu auch: http://forums.storagereview.com/index.php?/topic/25923-too-many-years-of-awful-3ware-performance/
Ich habe das mit ganz unterschiedlichen Standard HDD-Platten erlebt. Von daher hatte und habe ich innerlich ein Problem mit HW-Controllern und mit Raid 10; bei letzterem auch wegen des hohen Platzbedarfs. Die Konzentration von LSI auf Windows-Systeme hat dann ein Übriges getan, um mich für den Hausgebrauch von echten, aber erschwinglichen HW-Raid-Controllern abzuwenden. Jeder Euro, den ich damals in mehr Speicher investierte, war für mein Gefühl zumindest unter Linux deutlich besser investiert.

Konsequenterweise bin ich dann vor ca. 3 Jahren ergänzend auf einfache Linux SW Raid-Systeme umgestiegen - mit dem Ergebnis von mehr Flexibilität und einer besseren Performance auf Desktops für wenig Geld. Aber das Wiederherstellen eines "degraded Arrays" im Fall von Fehlern war z.T. nerviger als mit HW-Controller. Und bei TB-Platten dauerte das - auch bei Hochschrauben entsprechender Parameterwerte für mdadm (bzw. die Module md_mod und raid5) unter Linux.

Verfügbare Ressourcen auf dem neuen Test-System

Unser neues Testsystem hat folgende Ressourcen: i6700K-CPU, 64 GB RAM, 4 Raid10 HDDs mit HW-Controller, 1 rel. teure SSD 850 Pro, 4 relativ kostengünstige SSDs 850 EVO. Das Z170-Mainboard weist einen onboard Intel Z170-SATA3-Controller auf, der mit [Intel Rapid Storage Technologie - iRST] betrieben werden kann. Ich spreche nachfolgend kurz von iRST-Controller, wenn iRST aktiviert ist. Bei deaktiviertem iRST setze ich den SATA3-Controller in einen AHCI-Modus für einzelne SSDs. Mit iRST lassen sich relative bequem Raid-Container über die 4 850 EVO SSDs aufbauen. Vorhandene M2 Ports werden nicht benutzt.

Was ist das vorläufige Zwischenergebnis nach etlichen Tests?

Um den Leser einen Ausblick zu geben, hier ein paar Punkte und Entscheidungen:

  1. Ich habe eine klare Entscheidung für Linux SW-Raid getroffen. Weniger aus Performance-Gründen, als u.a. aus Gründen der Flexibilität. Wie wichtig die ist, lernt man beim Testen. Auf iRST werde ich ganz verzichten; die Platten werden BIOS-seitig im reinen AHCI-Modus angesprochen.
  2. Es werden Raid-10-Arrays und keine Raid-5-Arrays zum Einsatz kommen. Dies ist eine fundamental wichtige Entscheidung! Sie ist primär dadurch motiviert, die SSDs zu schonen. Raid 10 ist hinsichtlich Plattenplatz teuer - aber das erscheint mir im Vergleich zur Plattenabnutzung nach meinen Erfahrungen ein kleiner Preis zu sein.
  3. Ich werde das Betriebssystem (OS Suse 42.2 und alternativ Debian) nicht auf einer Partition des Raid-Systems selbst aufsetzen - und wenn doch, dann nur zu Testzwecken, aber nicht zum produktiven Arbeiten.
  4. Ich werde die Raid-Erstellung nicht halbautomatisch über YaST sondern manuell vornehmen. Hierfür gibt es einen guten Grund, den ich später erläutern werde.
  5. Bzgl. der Partitionierung und des Alignments werde ich dagegen nach vielen manuellen Checks Opensuses' YaST bzgl. des Partition-Alignments vertrauen.
  6. Insgesamt werde ich auf den SSDs ca. 12% Plattenplatz ungenutzt lassen. Das ist teuer, aber bzgl. des Verschleißes eine Vorsichtsmaßnahme.

  7. LVM wird zum Einsatz kommen; die logischen Volumes werden mit guten Reserven bzgl. des eigentlichen Platzbedarfes angelegt.
  8. Ich werde mir die Option für mehr als 2 Raid Arrays auf ein und demselben Plattenverbund offen lassen.
  9. Für kommende intensivere Applikations- und Datenbanktests werde ich mindestens 2 Raid-Arrays mit ganz unterschiedlichen Raid Chunk Sizes, nämlich 512KB vs. 32KB verwenden. Die Chunk Size ist ein essentieller Parameter für eine gute Performance. Bzgl. der endgültigen Wahl gibt es aber glcih mehrere Aspekte zu beachten - u.a. die Art der Last: Random I/O? Kleine Blocksizes? Viele parallele und konkurrierende Prozesse mit Plattenzugriff oder eher zeitlich getrennte Einzelprozesse mit hohen Last-Peaks? Viele separate Zugriffe? Applikationen mit Threading zur Lastverteilung? Auf einem Fileserver wüsste ich jetzt bereits die richtige Wahl; für unsere spezielle PHP/MySQL-Anwendung sind weitere Tests und ggf. sogar eine stärkere Parallelisierung des SW-Algorithemn für mehrere CPU-Cores erforderlich.

Eine wichtige Sache, die ich auch gelernt habe:

Man kann die potentiellen Probleme nicht allein mit einfachen Testtools wie "hdparm -tT", "dd" für das Lesen und Schreiben größerer Test-Datenmengen mit unterschiedlichen Blockgrößen oder grafischen Tools wie "gnome-disks" erfassen.

Ein Ergebnis wie

irst_raid_ssdroot_20mb_400_from_old_rux

für den iRST ist nicht wirklich aussagekräftig. Tools wie "fio", die eine differenzierter parametrierte Last erzeugen können, sind wesentlich hilfreicher.

Aber der Reihe nach - im nächsten Teil dieser Miniserie beschäftige ich mich zunächst mit dem Fake Raid Controller von Intel - und werde versuchen, plausibel zu machen, dass sich sein Einsatz für reine Linux-Systeme nicht lohnt. Die späteren Artikel befassen sich dann mit der Diskussion von Raid 5 vs. Raid 10 auf SSDs und der Optimierung von Raid 10.

Eclipse Neon 1 – Standard-JSDT mit Schwächen – zusätzliche Plugins

Im September 1016 wurde die neue Eclipse-Version NEON I veröffentlicht. Ich hatte mir zuvor im Sommer bereits die R-Version angesehen. Während das PDT-Plugin für PHP unter NEON gut aussieht und seine Dienste auch für PHP 7 in gewohnter Weise leistet, kam bei einem Blick in die JSDT-Ecke eher ein wenig Enttäuschung auf.

Zwar gilt:
Der neue JS-(Esprima)-Interpreter kann sehr gut mit "ECMAScript 6"-Syntax [ES6]. Auch der Outline-Bereich funktioniert z.B. für die Anzeige definierter Objekt-Methoden/Funktionen, die über die neue ES6-Syntax mit "calss"-Statements angelegt werden, perfekt. Die gesamte Hierarchie von Objekt-Methoden/Funktionen und -Variablen wird dabei angezeigt. Gut gefallen haben mir auch der Debugger, der Support von "node.js" und auch ein paar andere neue Features (siehe etwa https://www.youtube.com/watch?v=UxGwu2adzIc). Generell ist es begrüßenswert, dass engagierte Leute versuchen, JSDT auf ein neues, zeitgemäßes Niveau zu hieven !

Aber: Wer hat schon alle seine JS-Codes auf die ES6-Syntax umgestellt? Zumal nicht alle von Kunden genutzten Browser-Versionen ES6 unterstützen.

Und dann kommt beim originalen unmodifizierten JSDT von NEON ein wenig Frust auf:

Hat man seine Objekt-Methoden über die klassische Syntax und Definitionen in der Prototype-Chain festgelegt, wird die nächste Hierarchieebene "Objekt" => Funktionen und Variablen" für ein Objekt im Outline-Fenster leider nicht mehr angezeigt. Der Outline-View für Objekte endet dann auf der Ebene der Objektnennung - nur der oberste Level wird angezeigt, also das Objekt selbst, nicht aber seine Variablen oder Methoden/Prototype-Funktionen. Ich habe das gerade nochmal für ein frisch heruntergeladenes NEON I überprüft.

Das Outline-Tool liefert für ES(≤5)-Code also leider nicht mehr die Funktionalität, die man von Mars 2 und Vorgängerversionen gewohnt war. Ich weiß nicht, ob sich die Eclipse-JSDT-Entwickler darüber im Klaren sind, dass das fast einem KO-Kriterium für die Benutzung entspricht? Eine voll funktionierende Outline-Umgebung mit mindestens zwei funktionierenden Hierarchie-Ebenen ist für ein schnelles organisiertes Arbeiten bei komplexen Codes ein Muss.

Ein Test-Beispiel

Folgender simpler Testcode zeigt das Problem auf:

var z = 7; 
var GOCR = new GOCC();  

var xas = function() {
  var beta = GOCR.beta(); 	
	
  var yas = function () {
	  var loc_num = GOCR.alpha(); 	
	  var zzz = function() {
		  var fff = 'fff'; 
	  }; 
  };  
}; 

class UUC {
	constructor (x) {
		this.x = x; 
	}
	ucc_alpha() {
		this.y = 'yyyy'; 	
	}
}

function GOCC() {
	this.ax_str = 'ufo'; 
	this.vv_ay  = new Array('Enlarge'); 
}

	GOCC.prototype.alpha = function() {
		this.a_num = 7;  
	};
	
	GOCC.prototype.beta = function() {
		this.b_num = 8; 
		return this.bnum; 
	};

 
Mit dem unmodifiziertem JSDT von NEON I führt dies zu folgender Darstellung im Outliner:

not_expanding_object_prototype_functions

Man erkennt, dass zwar verschachtelte Funktionsstatements über mehrere Hierarchieebenen hinweg korrekt aufgelöst werden. Auch die Methoden der "UUC"-Klasse werden noch dargestellt. Die Funktionen aber, die einem Funktionsobjekt über dessen Prototype zugeordnet wurden, werden jedoch im Gegensatz zum JSDT von Eclipse Mars nicht im Outline-View angezeigt.

Workaround mittels "Webclipse JSjet" und "Tern"

Diejenigen, die nicht auf eine originäre Lösung im Rahmen der weiteren JSDT-Entwicklung warten wollen, können ggf. auf das Webclipse JSjet-Plugin zurückgreifen (Eclipse Repository: https://www.genuitec.com/updates/webclipse/ci/). JSjet greift intern auf Tern-Funktionalität zurück. Nach der Installation bietet der Outliner für Objekte bzw. Objekt-Konstruktor-Funktionen wenigstens zwei Ebenen an. Allerdings muss man sich dafür nach jedem Neustart von Eclipse mit etwas nerviger Werbung für Webclipse und die Fa. Genuitec auseinandersetzen - und mir persönlich sind die Lizenzbedingungen nicht vollständig klar. Ein Blick in diese Ecke lohnt sich aber durchaus.

Ich habe testweise auch die wichtigsten "tern"-Plugins aus dem aktuellen Repository "http://oss.opensagres.fr/tern.repository/1.2.0/" installiert. Insgesamt habe ich dadurch neben einer bzgl. Class und Prototype verbesserten Outline-Darstellung auch eine vernünftige Autocompletion-Unterstützung für jQuery erhalten. Dies ist umso wichtiger, als der Entwickler für das bisher bewährte JSDT-jQuery-Plugin nach eignen Ausführungen auf seiner Github-Seite Probleme mit Neon hat und um Unterstützung bittet.

In einer Testinstallation versammeln sich dann neben dem JSDT-Plugin u.a. folgende Plugins für die JS-Entwicklung:
tern_plugins

Mit dem Resultat kann man leben:
expanding_object_prototype_functions_with_tern
Ich verstehe nicht, dass das, was da geboten wird, nicht schon in den Standard übergegangen ist, da ja beim neuen JSDT-Team auch jemand von der Fa. Genuitec, die hinter Webclipse steckt, dabei zu sein scheint.

Fairerweise muss man sagen, dass die Auflösung über mehrere Ebenen hinweg unter dem Standard JSDT für verschachtelte Funktionen sogar besser funktioniert als mit JSjet und Tern. Leider aber nicht für Objekt-Konstruktoren und Prototype-Funktionen nach alter ECMA-Syntax.

Ich hoffe auf ein noch besseres JSDT in der Neon 2 Version.