Monthly Archives: November 2016

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

Posted on by

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.

 

SSD Raid Arrays unter Linux – II – Hardwarecontroller ?

Posted on by

Im ersten Artikel dieser Serie zu SSD-Raid-Arrays für kleinere Linux-Server

SSD Raid Arrays unter Linux – I – ein facettenreiches Thema

hatte ich auf die Vielschichtigkeit des Themas hingewiesen. Im aktuellen Beitrag gehe ich kurz auf meine begründeten “Vorurteile” gegenüber dem Einsatz von dedizierten HW-Controllern für Raid-Arrays ein. Nach meiner Erfahrung lohnt sich der Einsatz unter Linux eher selten.

Wohlgemerkt: Ich rede hier von kleineren einzelnen Linux-Servern für den semi-professionellen Bereich, kleinere Unternehmen oder eben Freelancer wie mich – nicht von großen Anlagen oder gar Rechenzentren; dort sprechen wir generell von anderen Anforderungen und anderen HW-Lösungen.

Eigene frühere Raid-Erfahrungen

Ich habe früher verschiedene 3ware Sata-II-HW-Controller (u.a. 9650SE) und für Raid-Systeme mit gewöhnlichen Harddisks unter Linux eingesetzt. Ferner habe ich auch ARECA-Controller getestet, allerdings nicht auf meinen eigenen Systemen.

Insgesamt muss ich leider sagen, dass ich von den kleinen Controllern für bis zu 4 Harddisks nie wirklich überzeugt wurde. Weder beim Einsatz für Raid 1, Raid 10 oder Raid 5.

3ware– bzw. LSI-Controller und auch ARECA-Controller waren in der Anschaffung für meine bescheidenen Verhältnisse relativ teuer (zw. 350 und 700 Euro). Hinzu kamen Zusatzkosten für die Anschaffung von Batteriepuffern zur Absicherung der Inhalte von Schreibcaches (bei Systemabstürzen, erforderlichen schnellen Shutdowns, etc.).

3ware/LSI-Contoller lieferten lt. Tests und Reviews zwar gute Raten für das sequentielle Schreiben großer Files. In der Praxis gab es aber immer wieder massive Performance-Einbrüche und manchmal unverständliche Verzögerungen, wenn viele kleine Schreiboperationen auftraten und dies ggf. von mehreren Prozessen gleichzeitig. Auch und gerade 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 SATA-II/III-HDD-Platten erlebt. Über 3 Jahre hinweg habe ich bei 3ware-/LSI-Controllern wirklich viel an Einstellungsmöglichkeiten durchprobiert. Glücklich wurde ich nie! Ein auf einem System eines Bekannten getesteter Areca-Controller verhielt sich nur z.T. besser.

Umstieg auf SW-Raid unter Linux

Seit dieser Zeit (2011 bis 2014) hatte und habe ich innerlich ein Problem mit HW-Controllern und mit Raid 1,5,10. Die Konzentration von LSI auf Windows-Systeme hat dann ein Übriges getan, um mich für den Hausgebrauch von echten HW-Raid-Controllern abzuwenden.

Jeder Euro, den ich damals zunächst in mehr Speicher investierte, war für mein Gefühl zumindest unter Linux deutlich besser investiert. Dann habe ich zudem meine Hemmschwelle gegenüber SW-Raid überwunden und mich da eingearbeitet. Tests zeigten dann, dass reine Linux-SW-Raid-Array für Konfigurationen mit bis zu 4 HDDs deutlich performanter oder zumindest gleich performant waren wie die Raid-Verbände teurer HW-Controller.

Konsequenterweise bin ich dann vor ca. 3 Jahren auf einfache SW-Raid-Systeme mit HDDs unter Linux umgestiegen – mit dem Ergebnis von deutlich mehr Flexibilität (!) und einer besseren Performance auf meinen Servern und Workstations. So war es plötzlich möglich, verschiedene Raid-Sysateme über die gleichen Platten hinweg aber mit unterschiedlicher Plattenzahl pro Raid-System zu nutzen.

Weiterer Vorteil: Eine deutliche Kostenersparnis!

Einzige potentielle Nachteile: Invest in Zeit und Wissensbeschaffung. Zudem empfand ich anfänglich die administrativen Schritte zur Wiederherstellung eines “degraded Arrays” im Fall
von Fehlern als etwas nerviger als bei einem HW-Controller. Das hat sich mit dem Einsatz von “mdadm” aber gegeben – und die Rekonstruktionszeiten für Raid-Arrays waren unter SW-Raid z.T. erheblich besser als bei BIOS-basierten Rekonstruktionsverfahren der HW-Controller.

Gelernt habe ich dabei auch, dass man immer ein funktionstüchtiges Linux-Mini-Betriebssystem auf einer HDD außerhalb des Raid-Arrays verfügbar haben sollte.

Übertragbarkeit auf SSDs?

Grundsätzlich bin ich der Meinung, dass meine Erfahrungen mit HW-Raid-Controllern und HDD-Arrays durchaus auf SSD-Raid-Systeme übertragbar sind. Hinzu kommt hier noch ein weiterer wichtiger Aspekt:

HW-Controller für Raids auf Basis von SSDs müssen dauerhaft einen extrem hohen Gesamt-Datendurchsatz verkraften! Einzelne gewöhnliche SSDs (nicht M2-Port fähige) erreichen ja bereits Durchsatzraten von 500 MByte/sec!

So ist es selbst bei nur vier gewöhnlichen SSDs (nicht M.2-SSDs) in einem Raid-5-Verbund überhaupt kein Problem, lokal Datendurchsatzraten von 1.4 GByte/sec zu erzeugen. Die Datendurchsatzrate steigt theoretisch bei noch mehr Platten weiter ca. linear an. Diese Datenraten müssen durch den HW-Raid-Controller verarbeitet und dann durch die (4 – 8) Lanes einer (!) PCIe-Schnittstelle transportiert werden. Das erfordert schnelle Prozessoren und für Daten-Caching auch schnelle Speicherbausteine (> DDR3) auf den Controller-Karten; das kann nicht billig sein!

Hier prüfe jeder unbedingt, bevor man sich an einen HW-Controller bindet!

Was ich jedenfalls mit Sicherheit sagen kann, ist, dass Z170 Onboard-Raid-Controller im AHCI-Modus und SW-Raid-Verbände mit 6 Standard-SSDs unter Linux 1.6 GByte/sec Durchsatz schaffen.

HW-Controller und das Thema Ausfallsicherheit

Hier kommen wir zu einem schwierigen Thema. Auch SW-Raid-Systeme erfordern ja zumindest einen SATA- oder SAS-Controller, unter dem die Platten angesteuert werden können. Nutzt man nun einen Onboard-Controller, so zieht ein Controller-Ausfall fast zwangsläufig einen Mainboard-Tausch nach sich.

Natürlich kann es in einem professionellen Umfeld, bei dem man lange Ausfallzeiten nicht verkraften kann, einfacher und schneller sein, einen dedizierten HW-Controller auf einem PCIe-Steckplatz auszutauschen. Aber ein Ersatz-Controller, oder gar eine zweites Cold-Standby-System und noch viel mehr ein HA-Cluster sind doch mit beträchtlichen Investitionen verbunden. Hier müssen eine Risiko-Analyse und eine Risikobewertung weiterhelfen, den tatsächlichen Bedarf an Ausfallsicherheit festzulegen. Das gilt natürlich vor allem für große Unternehmen – soweit die nicht sowieso mit dedizierten SAN-Systemen etc. operieren oder ihre Daten in der Cloud hosten lassen.

Blicken wir dagegen auf kleine mittelständische Betriebe mit eigenen kleineren Server-Systemen, so kann es u.U. kostengünstiger sein, einen Onboard-Controller für Raid-Systeme einzusetzen und für den Ernstfall ein zweites Mainboard oder ein StandBy-System vorrätig zu halten. Die Anschaffung zweier besserer HW-Raid-Controller, die SSDs hinreichend unterstützen, kosten vermutlich deutlich jenseits der 1000 Euro (einer davon wird für den Ernstfall vorrätig gehalten oder eben erst im Ernstfall beschafft). Ein Ersatz-Mainboard mit Onboard-Controllern ist aber oft günstiger zu haben als ein HW-Raid-Controller. Die Frage ist dann: Habe ich Zeit genug für einen Mainboard-Tausch?

In einem Notfall-Szenario mit vorgesehenem Mainboard-Tausch oder aber mit einem Wechsel auf ein StandBy-System, das im Schadensfall hochgefahren wird, wird es dann von entscheidender Bedeutung sein, dass man sein Raid-Array physikalisch verpflanzen und an den Controller des anderen/neuen Mainboards anschließen kann. Hier kommt nun unter Linux ein wichtiger Aspekt zum Tragen:

Ein auf einem Linux-System angelegtes SW-Raid-Array kann auch unter einem anderen Linux-System
angesprochen werden, wenn die Platten an einen dortigen Controller angeschlossen werden können und wenn unter dem anderen System mdraid-Module aktiviert werden.

Die Situation sieht bei Einsatz von dedizierten HW-Raid-Controllern u.U. ganz anders aus: Hier ist eine Abhängigkeit vom Controller-Hersteller im Falle eines Controller-Schadens eher die Regel! Fällt ein HW-Controller aus, muss man sich zur Rettung seiner Daten zwangsläufig einen neuen Controller der gleichen Bauart beschaffen. Daraus ergeben u.U. eben signifikante Kosten und eine sehr starke Hersteller-Bindung. Das galt u.a. auch für die von mir früher eingesetzten 3ware/LSI-Controller.

Diese Abhängigkeit hat beim Einsatz von Linux SW-Raids ein Ende. Gerade für kleinere Firmen stellt die daraus resultierende Flexibilität allein schon einen immensen Wert dar!

Fake-Raid-Controller?

Ein besonderes Thema sind Fake-Raid-Controller. Billige Raid-Controller und auch ins Mainboard integrierte Controller erfordern trotz Konfigurierbarkeit über BIOS-Funktionen oft die Mitarbeit der CPU und des System-RAMs sowie auf das Betriebssystem ausgerichteter Treiber.

Hiervon sind Intel’s iRST-Controller keine Ausnahme! Lohnt sich hier der Einsatz? Lest hierzu bitte den nächsten Artikel dieser Reihe:
SSD Raid Arrays unter Linux – III – SW- Raid oder Intel- RST-Raid – Performance?

SSD Raid Arrays unter Linux – I – ein facettenreiches Thema

Posted on by

Ein neues Test-System bietet eine gute Gelegenheit, neue Technologie unter Linux auszuprobieren. In diesem Fall einen SSD-Raid-Verbund. So etwas mache ich natürlich nicht nur zum Vergnügen. Mein eigentliches Ziel ist es, Berechnungen eines Kunden, die auf Daten einer oder mehrerer MySQL-Datenbanken mit Tabellen mit bis 20 Millionen Datensätzen zurückgreifen, für die HW eines kleineren Standalone-Servers zu optimieren. Dabei sollen die Raid-Arrays auf ein bestimmtes Lastverhalten und andere Faktoren hin optimiert werden. Ich habe dabei doch ein paar Überraschungen erlebt.

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

Diese Artikelserie ist für Leute gedacht, die sich dem Einsatz von SSD-Arrays im privaten Bereich oder aber in kleinen Unternehmen annähern wollen – und dabei sicher über einige grundlegende Fragen stolpern. Wir betrachten also SSD-Raid-Arrays in Linux-Workstations oder kleineren Linux-Servern. Dabei fassen wir auch den Einsatz von SATA3-Onboard-Controllern ins Auge – für Intel Chipsätze wie den Z170, dessen Sunrise-Point-Controller und Intels zugehörige, sog. “iRST”-Technologie.

In einem Linux-Blog ist vor allem auch der Einsatz von Linux-SW-Raid-Arrays von Interesse. Viele der in den kommenden Artikeln getroffenen Feststellungen zu Linux-SW-Raids gelten dabei ganz unabhängig von der Anlagengröße oder dem verwendeten SATA/SAS-Controller.

Raid mit SSDs – ein facettenreiches Thema

Warum will man überhaupt SSD-Raid-Arrays einsetzen? Typische Motive sind: Eine Verbesserung der Ausfallsicherheit und Performanceverbesserungen über das Leistungsvermögen einer einzelnen SSD hinaus.

Nach meiner Meinung sollte man diese Punkte jedoch gut hinterfragen, bevor man unbedarft Geld in die Beschaffung mehrerer SSDs steckt. Im Besonderen sollte man nicht auf Werbeversprechen, die mit sequentiellen Lese- und Schreibraten argumentieren, hereinfallen. Ferner gibt es (nicht nur unter Linux) einige weitere Punkte zu beachten:

  • Kann man für kleinere Server Mainboard-Sata-Controller nutzen? Oder ist ein Griff zu HW-Controllern schon aus Performancegründen unumgänglich?
  • Bietet der Einsatz spezieller Technologie (wie etwa Intels iRST; s.u.) für einfache Mainboard SATA3-Controller Vorteile gegenüber nativen SW-Raid-Verfahren unter Linux?
  • Will man das System aus einem Raid-Array heraus booten? Geht das überhaupt?
  • Wie sieht es mit dem Verschleiß der SSDs aus? Hat die Art des Raid-Systems darauf einen Einfluss? Lässt sich der fstrim-Befehl für Partitionen auf Raid-Arrays absetzen?
  • Von welchen Faktoren und Konfigurationsparametern hängt die Performance eines Linux-SW-Raid-Arrays ab?
  • Kann man den Standardeinstellungen vertrauen, die manche Linux-Installer für die Konfiguration von Raid-Arrays anbieten?

Arbeitet man sich in die Thematik ein, so merkt man schnell, dass das Thema “SSD-Arrays” eine Wissenschaft für sich ist. Und dann stößt man z.T. auch 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 Chunk-Sizes im Bereich von 2 MB empfohlen, während andere möglichst kleine “Chunk Size”-Größen zwischen 8 und 32 KB empfehlen. Jeweils natürlich mit unterschiedlichen Begründungen, die vom Leser
selten zur Deckung gebracht werden können. Es kommt dann die Frage auf, ob die jeweiligen Autoren nicht implizite Annahmen bzgl. bestimmter Lastprofilen gemacht haben …

Ich habe nun mehrere Tage mit eigenen Tests und Informationsbeschaffung verbracht – erst jetzt hat sich ein Vorgehensmodell herauskristallisiert. Ich werde mir dabei aus guten Gründen Reserven für weitere datenbankspezifische Experimente offen lassen. Inzwischen habe ich immerhin einige Erkenntnisse gewonnen, die auch anderen helfen können, wenigstens ein paar essentielle Fehler und eine unkritische Übernahmen von Empfehlungen zu vermeiden.

Verfügbare Ressourcen auf dem neuen Test-System

Mein 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 (Sunrise Point) auf, der mit Intel Rapid Storage Technologie [iRST] betrieben werden kann. Es handelt sich dabei um eine Lösung von Intel, die eine (Vor-) Konfiguration von Raid-Platten-Verbänden bereits im BIOS zulässt. Ich spreche in den kommenden Artikeln kurz vom “iRST-Controller”, wenn denn iRST im BIOS aktiviert ist.

Was ist das vorläufige Zwischenergebnis nach etlichen Tests?

Um den Leser einen Vorgeschmack zu geben, hier ein paar vorläufige Entscheidungen:

  1. Ich habe eine klare Entscheidung für Linux-SW-Raid getroffen und gegen den Einsatz von iRST getroffen. Weniger aus Performance-Gründen, als vor allem aus Gründen der Flexibilität. Auf iRST werde ich ganz verzichten; die Platten werden BIOS-seitig im reinen AHCI-Modus angesprochen.
  2. Es werden hauptsächlich 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 bisherigen Erfahrungen ein relativ 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 in einem kommenden Artikel erläutern werde.
  5. Bzgl. des Partition-Alignments werde ich dagegen nach vielen manuellen Checks Opensuses’ YaST bzgl. dessen Alignment-Algorithmen 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. Für echte Hochperformance-Aufgaben werde ich kleine Raid-5-Arrays weiter austesten.
  9. Für weitere intensivere Applikations- und Datenbanktests werde ich mindestens 2 Raid-Arrays mit ganz unterschiedlichen Raid Chunk Sizes, nämlich 512KB bzw. 32KB verwenden. Die Chunk Size hat sich als ein essentieller Parameter für eine gute Performance erwiesen.
  10. Bzgl. der endgültigen Wahl der Chunk Size gibt es gleich 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 halbwegs ausgelasteten 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-Algorithmen 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 – in den zunächst kommenden Teilen dieser Miniserie
SSD Raid Arrays unter Linux – II – HW-Controller?
gehe ich zunächst ein wenig auf das Thema HW-Controller ein. Lohnt sich deren Einsatz?

Es folgen dann ein paar Beiträge zum Einsatz von iRST im Vergleich zu nativen SW-Raids.

Danach werde ich mich mit Frage Raid-5 vs. Raid-10 auseinandersetzen. Ein weiterer Artikel zeigt dann, wie man Raid-10-Arrays unter Linux praktisch konfiguriert.

Schließlich werde ich Performance-Daten präsentieren und daraus Schlussfolgerungen bzgl. der Raid-Konfiguration ziehen.

Der eine oder andere praktisch veranlagte Leser wird sich im Gegensatz zu der von mir gewählten Themenfolge vielleicht als erstes auf das Thema einer Anlage und Konfiguration von SW-Raid-Arrays stürzen wollen. Bitte, kein Problem! Ich empfehle vorab eine intensive Auseinandersetzung mit dem “mdadm”-Kommando und seinen Optionen. Siehe zur Einführung etwa

https://raid.wiki.kernel.org/index.php/RAID_setup
https://www.thomas-krenn.com/de/wiki/Software_RAID_mit_MDADM_verwalten
https://www.digitalocean.com/community/tutorials/how-to-create-raid-arrays-with-mdadm-on-ubuntu-16-04
https://linux.die.net/man/8/mdadm
https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha.advdisk.html#sec.yast2.system.raid

Einen kleinen “Kurs” zu mdadm bietet die Seite
https://www.tecmint.com/understanding-raid-setup-in-linux/.