SSD Raid Arrays unter Linux – IX – Chunk Size und Performance eines md-Raid-10-Arrays

In früheren Blogbeiträgen hatte ich mich Ende 2016 ein wenig mit SSD-Raid-Arrays unter Linux auseinandergesetzt:

SSD Raid Arrays unter Linux – I – ein facettenreiches Thema
SSD Raid Arrays unter Linux – II – Hardwarecontroller ?
SSD Raid Arrays unter Linux – III – SW- Raid vs. Intel-iRST-Raid – Performance?
SSD Raid Arrays unter Linux – IV – OS und Daten auf einem Raid-Array?
SSD Raid Arrays unter Linux – V – SW-Raid vs. iRST-Raid – Boot-Unterstützung?
SSD Raid Arrays unter Linux – VI – SW-Raid vs. iRST-Raid – Flexibilität?
SSD Raid Arrays unter Linux – VII – problematische Aspekte von Raid-5-Arrays
SSD Raid Arrays unter Linux – VIII – Setup von Raid-10-Arrays mit mdadm

Ich möchte in diesem Blog-Beitrag einige Performance-Daten für ein Raid-10-Setup mit SSDs nachreichen. Wir betrachten dabei ein SW-Raid-Array (md-Raid), dass mit Hilfe von "mdadm" erstellt wurde. Die Daten, die auf einem Opensuse-System gewonnen wurden, unterstreichen den großen Einfluss der "Chunk-Size" auf einige Einsatzszenarien. Wichtigstes Ergebnis:

Man kann nicht grundsätzlich davon ausgehen, dass eine große Chunk-Size (≥ 512 KB) die beste Performance liefern wird.

Test-Voraussetzungen

Die Voraussetzungen für die nachfolgend ermittelten Daten waren:

Raid-Array:
Linux SW-Raid-10-Array aus 4 SSDs (Samsung EVO 850); Near N2-Layout. Verwendete Partitionsgrößen auf den SSDs: 40 GiB. Das Array wurde z.B. für eine Chunk Size von 32kiB z.B. erzeugt mit

 
mdadm --create --verbose /dev/md/d02 --level=raid10 --bitmap=none --chunk=32 
--layout=n2 --raid-devices=4 /dev/sda5 /dev/sdb5 /dev/sdc5 /dev/sdd5 

Eine "Bitmap" (s. hierzu den letzten Artikel) wurde also nicht angelegt. Für die "Chunk Size" wurden test-abhängig Werte von 8k, 16k, 32k, 512k verwendet. Vor jedem Einzeltest wurde ein fstrim-Befehl auf die zu testende Partition des Raid-Systems abgesetzt. Hinsichtlich der Schreibtests lagen also optimale Voraussetzungen vor. Es wurden LVM2 Logical Volumes verwendet, die mit einem "ext4"-Fielssystem versehen wurden. Der LVM- und Filesystem-Overhead gegenüber einem Schreiben mit dem Tool "fio" (s.u.) auf unformatierte Partitionen erwies sich als unerheblich.

OS und HW:
Opensuse Leap 42.1 mit Kernel 4.1; i7 6700K; Onboard Z170 Intel Raid-Controller (Kernel-Modul: pinctrl_sunrisepoint). Scheduler: Deadline.
Die Kernelversion ist leider wichtiger als man meinen möchte. Die nachfolgend ermittelten Daten lassen sich z.B. auf einem System mit Opensuse Leap 42.2 mit Kernelversion 4.4 nicht erzielen! Bei gleichem Setup, gleicher FIO-Version und identischem HW-Unterbau ist die Performance zum Teil deutlich schlechter. Für Einzelprozesse und Daten-Paket-Gößen unterhalb 1 MB waren auf derselben HW-Plattform Perfromance-Einbrüch von 25 bis zu 30 % zu verzeichnen. Unverständlicherweise! Im asymptotischen Bereich (große Daten-Pakete, die die Chunk Size weit übersteigen und/oder viele parallel arbeitende Jobs) werden aber die gleichen Werte wie unter einem 4.1 Kernel erreicht. Vorläufige Untersuchungen zeigen, dass die schlechtere Performance ein Effekt ist, der schon bei Einzel-SSDs auftritt und durch das Raid10-System nur noch verstärkt wird.

Test-SW und Datenstruktur:
Ich habe primär "fio" in der Version 2.2.10 und für sequentielles Lesen/Schreiben großer Datenpakete ergänzend auch "gnome-disks" eingesetzt. Es wurden Daten von insgesamt 500 MB Größe geschrieben. Unter "fio" galten dabei besondere Bedingungen: Die Nutzung des Linux-Caches wurde durch Optionen umgangen; wir wollen ja die tatsächliche Raid-Performance testen. Typische Einstellungen für die FIO-Jobs waren in etwa solche wie nachfolgend für einen "Random Write"-Job angegeben:

[global]
size=500m
direct=1
bs=64k
ioengine=sync

[write]
bs=64k
numjobs=1
rw=randwrite

Die fio-Blocksize "bs" wurde im Test zwischen 8k und 20000k variiert - damit wurde im Test abgefragt, wie das System auf unterschiedliche strukturiertes Datenaufkommen reagiert: Kleine einzelne Datenpakete (spike-artig) vs. größere Datenpakete (etwa größere Files).

Nur 1 Job liest oder schreibt auf das Array:
Von großer Bedeutung für die Testergebnisse ist die fio-Einstellung, dass nur genau ein (1) Job zu einem Zeitpunkt ein Datenpaket lesen oder schreiben soll. Die Ergebnisse würden sich drastisch ändern, wenn mehrere Jobs gleichzeitig auf das Raid-System zugreifen würden. Im Besonderen würde die Schreibperformance bei "Random Write"-Tests deutlich nach oben gehen. Damit wird sich ein kommender Artikel befassen.

Man kann in etwa sagen, dass eine zunehmende Zahl von Jobs einen ähnlichen Effekt hat wie eine deutliche Vergrößerung der Größe "bs": Es stehen zu einem Zeitpunkt immer viele Datenblöcke, die über Chunks möglichst parallel auf die Platten geschrieben werden. Die Chunksize wird dann einfach früher und trotz evtl. kleiner "bs"-Werte überschritten.

Schwankungsbandbreite
Die Ergebnisse zu den Transferraten haben eine Schwankungsbandbreite zwischen 8 und 25 MB/sec. Tendenziell ist die Schwankungsbreite bei kleinen Datenpaketgrößen höher. Das liegt u.a. auch an der sonstigen Auslastung des Testsystems. Ich habe versucht, so viele Prozesse wie möglich abzuschalten; ferner wurde jede der durchgeführten Messungen 3 mal wiederholt. Es wurde ein sinnvoller Mittelwert bei leichter Bevorzugung hoher Werte angegeben.

Daten

Die nachfolgende Tabelle ist wie folgt zu lesen:

Am Kopf der verschiedenen Testblöcke ist die Art des Lesen/Schreibens (Random vs. Sequential) angegeben.

  • Die Variation der "Chunk Size" entnimmt man der zweiten Spalte.
  • Es folgen pro Zeile mehrere Blöcke aus jeweils 2 (oder 3) zusammengehörigen Spalten mit der verwendeten fio-"bs" und dem zugehörigen Messwert für die Datentransferrate in MiB/s. Zu den mit "gdisk" bezeichneten Spalten s.u..
  • Die Zeilen mit SSD am Anfang zeigen Werte, die für eine einzelne SSD-Partition außerhalb des Raid-Verbunds gemessen wurden (Einzelzugriff auf eine SSD).
  • Die Spalten mit der Überschrift "gdisk" stehen für zusätzliche Werte, die mit dem Tool "gnome-disks" gewonnen wurden. Sie betreffen nur sequentielle Lese- und Schreibtests.

Grün markierte Werte markieren aus meiner Sicht akzeptable Werte; bei ihnen kommt auch die Performance-Verbesserung durch Einsatz eines Raid-vebrunds gegenüber einer Einzel-SSD voll zum Tragen. Werte für sequentiell Zugriffe und eine Chunk Size von 16K habe ich leider noch nicht erhoben; sorry.

500M

                                     

Random Read

                           

gdisk

   

gdisk

 

chunk

bs

MB/s

bs

MB/s

bs

MB/s

bs

MB/s

bs

MB/s

bs

MB/s

bs

MB/s

MB/s

bs

MB/s

MB/s

SSD

-

8

64

16

126

32

200

64

278

128

327

512

433

1024

460

 

20000

497

 

R10_0

16

8

66

16

149

32

235

64

448

128

604

512

753

1024

832

 

20000

851

 

R10_1

32

8

66

16

128

32

215

64

390

128

720

512

791

1024

868

 

20000

932

 

R10_2

512

8

64

16

128

32

209

64

277

128

318

512

436

1024

851

 

20000

976

 
                                       

Random Write

                                     
 

chunk

bs

MB/s

bs

MB/s

bs

MB/s

bs

MB/s

bs

MB/s

bs

MB/s

bs

MB/s

MB/s

bs

MB/s

MB/s

SSD

-

8

166

16

243

32

409

64

457

128

458

512

478

1024

492

 

20000

502

 

R10_0

16

8

158

16

285

32

484

64

615

128

680

512

730

1024

775

 

20000

790

 

R10_1

32

8

166

16

295

32

384

64

609

128

731

512

754

1024

816

 

20000

850

 

R10_2

512

8

130

16

299

32

347

64

430

128

464

512

463

1024

837

 

20000

873

 
                                       

500M

                                     

Seq Read

                                   
 

chunk

bs

MB/s

bs

MB/s

bs

MB/s

bs

MB/s

bs

MB/s

bs

MB/s

bs

MB/s

MB/s

bs

MB/s

MB/s

SSD

-

8

 

16

371

32

425

64

480

128

483

512

493

1024

506

 

20000

517

 

R10_0

16

8

 

16

 

32

 

64

 

128

 

512

 

1024

 

986

20000

   

R10_1

32

8

 

16

355

32

432

64

796

128

724

512

773

1024

883

950

20000

980

1030

R10_2

512

8

 

16

354

32

425

64

472

128

495

512

485

1024

950

998

20000

1010

1100

                                       

Seq Write

                                     
 

chunk

bs

MB/s

bs

MB/s

bs

MB/s

bs

MB/s

bs

MB/s

bs

MB/s

bs

MB/s

MB/s

bs

MB/s

MB/s

SSD

-

8

 

16

333

32

410

64

456

128

485

512

484

1024

490

 

20000

502

 

R10_0

16

8

 

16

 

32

 

64

 

128

 

512

 

1024

 

380

20000

   

R10_1

32

8

 

16

298

32

377

64

647

128

734

512

756

1024

812

399

20000

850

840

R10_2

512

8

 

16

301

32

370

64

423

128

450

512

464

1024

836

374

20000

886

841

                                       

 

Interpretation

Wir kommen zu folgenden Ergebnissen und möglichen Erklärungen des festgestellten Verhaltens:

Feststellung 1: Besonders das Lesen kleiner Datenpakete liegt den Samsung SSDs nicht.

Erklärungsansatz: Typischer SSD-Leistungseinbruch bei kleinen Datenpaketen
Wir sollten nicht allzu sehr überrascht sein, wenn wir bei kleinen Datenpaketen einen generellen Performance-Verlust der SSDs feststellen. Dieses Verhalten ist schon bei Einzel-SSDs gegeben - und übrigens auch bei klassischen Harddisks nicht anders. Viele Leute sind sich dessen aber nicht bewusst; in der Werbung geben die Hersteller ja meist nur die sequentiell erreichbaren Maximalraten an. Diese Werte spiegeln aber das tatsächliche, im Mittel deutlich kleinere Leistungsvermögen bei kleinen Einzeldatenpaketen überhaupt nicht wieder. Der Fairness sei auch gesagt, dass HDDs im Bereich kleiner Datenpakete sehr viel schlechtere Werte zeigen.

Erklärungsansatz: Erwartbar stärkerer Einbruch der Lese- als der Schreibperformance bei kleinen Datenpaket-Größen
Offenbar ist es ein verbreitetes Phänomen, dass bei vielen SSDs für geringe Datenpaketgrößen die Leseperformance hinter der Schreibperformance zurückfällt. Siehe hierzu:
http://www.anandtech.com/show/6935/seagate-600-ssd-review/5
Ich habe leider keine Ahnung, wie das technisch zu begründen ist. Besseres Caching zu schreibender Daten auf dem internen SSD-Controller? Jedenfalls zeigen meine Daten genau diesen Effekt - z.T. mit einer überraschend großen Diskrepanz zwischen Lese- und Schreibperformance.

Feststellung 2: Erst wenn die Datenpaketgröße die "Chunk Size" (deutlich) übersteigt, hebt sich auch die Performance des Raid-10-Arrays deutlich gegenüber der einer einzelnen SSD ab.

Feststellung 3: Unterhalb einer Datenpaketgröße von 1MB wird auch bei Überschreiten der Chunk Size keine Verdoppelung der Performance gegenüber einer Einzel SSD erreicht.

Erklärungsansatz: Fundamentale Bedeutung der Chunk Size
In den vorhergehenden Blogbeiträgen hatte ich bereits diskutiert, dass die Chunk Size eine Mindestgröße angibt, ab der parallele Zugriffe auf die 2 Stripeset-Komponenten des Raid-10-Arrays überhaupt erst ermöglicht werden. Deshalb würde man für Situationen, in denen der "bs"-Wert - also die Größe des zu verarbeitenden Datenpakets - die Chunk Size unterschreitet, einen deutlichen Einbruch der Performance erwarten. Da das Raid-System auch Overhead verursacht, würde man bei kleinen Datenpaketen ggf. sogar damit rechnen, dass die Performance des Raid-Arrays die einer Einzel-SSD (also außerhalb des Raid-Verbunds) unterschreitet. Statistisch geschieht das tatsächlich; in der Tabelle kommt das durch eine leichte Bevorzugung besserer Werte aber nicht zum Tragen.

Feststellung 3: Eine annähernde Verdoppelung der Leistung wird erst asymptotisch bei großen Datenpaketen erreicht. Das gilt für Random Read/Write wie für Sequential Read/Write. Im asymptotischen Bereich mit Datenpaketgrößen > 1MB sind auf einem Raid-10-Array mit Consumer-SSDs aber Schreibraten jenseits von 850 MB/sec und Leseraten jenseits von 1000 MB/sec möglich (SSD: EVO 850).

Erklärungsansatz: ???
Ehrlich gesagt, hier kann ich keine fundierte Erklärung liefern. Timing-Probleme des SSD-Controllers? Timing-Probleme zwischen Kernel, SW-Raid und dem Controller? Zusammenspiel interner SSD-Caches mit dem Test? Besonders erklärungsbedürftig scheint mir zu sein, dass beim sequentiellen Lesen sowie einer Chunk Sitze von 32 KB im Bereich von Datenpaket-Größen zwischen 64KB und 512 KB keine Systematik vorzuliegen scheint. Es wäre an dieser Stelle auch interessant zu sehen, wie sich eigentlich ein Raid-0-Array verhält.

Feststellung 4: Bei großen Datenpaketen nähern sich die Random-Raten den sequentiellen Raten an.

Erklärungsansatz: Asymptotik
Mit wachsender Größe der Datenpakete gibt man dem System die Möglichkeit, ein immer sequentielleres Verhalten zu erreichen.

Feststellung 5: gnome-disks liefert vor allem beim sequentiellen Schreiben von Datenpaketen mit 1MB Größe seltsame und gegenüber fio viel zu kleine Werte.

Erklärungsansatz: ???
Keine Ahnung. Hier stimmt jedenfalls irgendetwas nicht. Ich persönlich traue hier "gnome-disks" nicht.

Erstes Fazit

Auch wenn wir nicht alle Daten schlüssig erklären können, sind vier Befunde offenkundig:

  • Mit Hilfe eines Raid-10-Arrays kann man eine deutlich höhere Performance als mit Einzel-SSDs erreichen.
  • Eine theoretisch mögliche Verdoppelung von Datentransferraten wird nur asymptotisch für große Datenpakete und sequentielle Zugriffe erreicht.
  • Für Szenarien, in denen nur 1 Job zu einer Zeit Daten liest oder schreibt, hängt der mögliche Performance-Gewinn stark davon, ob die Größe der Datenpakete im Mittel die "Chunk Size" übersteigt oder nicht. Die richtige Wahl der "Chunk Size" ist vor allem dann wichtig, wenn regelmäßig einzelne kleine Datenpakete vom und zum Raid-10-Array transferiert werden müssen. Das kann z.B. für bestimmte Datenbank-Anwendungen relevant sein.
  • Eine Chunk Size von 32K stellt einen guten Kompromiss bzgl. der Unterstützung relativ kleiner Datenpaketgrößen und einer gleichzeitigen Performanceverbesserung gegenüber Einzel-SSDs dar.

Ausblick

Themen weiterer Artikel sollten Test für mehrere parallel lesende/schreibende Jobs, für andere Kernelversionen und auch für Raid-5-Arrays sein. Ich bitte diesbzgl. um etwas Geduld.

 

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

Wer für ein Desktop-System oder einen kleinen Server ein Raid-Array aufbauen will, kann dafür (nach einer Risiko-Analyse) ggf. den Onboard-SATA3-Controller des Mainboard-Chipsatzes nutzen. Auf Intel-Chipsätzen findet man dann Controller vor, die das Einrichten von Arrays mit Hilfe der iRST-Technologie erlauben. Darauf bin ich im früheren Beitrag

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

dieser Blog-Post-Serie bereits genauer eingegangen. Zusammen mit einem weiteren Artikel

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

hatte ich dann erläutert, dass wir unter einem aktuellen Linux-Betriebssystem auch gut ohne Intels iRST-Technologie für die Konfiguration von Raid-Arrays auskommen können.

Der Einsatz von iRST ist auf einem reinen Linux-System weder aus Performance-Gründe noch aus Gründen einer hinreichenden Boot-Unterstützung erforderlich. iRST ändert ferner nichts am Faktum, das z.B. eine Z170-Sunrise-Point-Controller von Intel letztlich als kostengünstiger Fake-Raid-Controller betrieben wird.

In diesem Artikel möchte ich einen weiteren Aspekt gegen den Einsatz von iRST unter Linux ins Spiel bringen - nämlich eine begrenzte Flexibilität. Daneben gibt es aus meiner Sicht noch ein paar weitere erwähnenswerte Nachteile.

CLI vs. "komfortable" BIOS-Funktionen?

Linux-SW-Raids werden in der Regel mit Hilfe von mdadm-Kommandos über die Command Line eingerichtet, iRST-Arrays dagegen über EFI-BIOS-Funktionen oder aber eben auch über "mdadm". Siehe: https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/rst-linux-paper.pdf.

Einige Betriebsysteme bieten für die Einrichtung von Arrays auch grafische Hilfsfunktionen an - unter Opensuse etwa dem YaST-Partitioner. Die Status-Überwachung beider Arrays erfolgt im laufenden Betrieb mit Hilfe von mdadm (mit bestimmten Optionen) und einen Blick ins Verzeichnis "/proc/mdstat"; für imsm-Metadatencontainer gibt es auch das CLI-Kommando "mdmon". Aber wer unbedingt grafisch arbeiten muss, der findet eine (begrenzte) mdadm-Unterstützung im Tool "webmin".

Manch einer mag ja das Anlegen und ggf. die Rekonstruktion von Raid-Arrays über BIOS-Funktionalitäten für bequem halten. Ich sehe das nur begrenzt so. Ein Linux-Admin wird sich durch den Einsatz der Kommandozeile nicht abschrecken lassen. Zumal mdadm ein feingranulareres Arbeiten ermöglicht. Einen kleinen "Kurs" zu mdadm bietet übrigens die Seite https://www.tecmint.com/understanding-raid-setup-in-linux/.

Zudem hilft einem im laufenden Betrieb das BIOS gar nichts. Ferner ist eine Raid-Rekonstruktion über BIOS-Funktionen typischerweise langsamer als über ein laufendes Betriebssystem. Hier kommt das zum Tragen, was ich bereits im Artikel

herausgearbeitet hatte: Im Schadensfall (degradiertes Raid-Array) benötigt man zur Reparatur und zur laufenden Überwachung ein funktionierendes OS auf einer separaten Platte! Der Rückgriff auf BIOS-Funktionalitäten ist dann überflüssig. Das gilt für imsm-Raid-Arrays wie für mdadm-Raid-Arrays!

mdadm bietet für Linux-SW-Raid-Arrays mehr Möglichkeiten als iRST für imsm-Container

Bei Einsatz von iRST und imsm-Containern geht einem im Vergleich zu den Konfigurationsmöglichkeiten von nativen SW-Raid-Arrays über "mdadm" viel Flexibilität verloren. Das sollte man in der Praxis nicht unterschätzen:

So lässt iRST nur genau 2 Raid-Arrays (Volumes) per Container zu - und der zweite anzulegende Verband kann dann in seiner Kapazität nicht mehr begrenzt werden. Er wird vielmehr den gesamten verbliebenen Platz der bereits einander zugeordneten Container Platten beanspruchen. Das ist eine massive Einschränkung.

"mdadm" unter Linux erlaubt dagegen die Erstellung beliebig vieler, in ihrer Größe definierbarer SW-Raid-Arrays über Partitionen gleicher oder unterschiedlicher SSDs hinweg. Dabei werden dann auch solche exotischen, aber performancesteigernden Dinge wie etwa ein Raid 10 über Partitionen von nur 2 SSDs möglich! Typ und Kapazität eines jeden einzelnen Arrays dürfen dabei im Rahmen der Größe der genutzten Rohpartitionen frei festgelegt werden.

Alle gängigen Typen an Raid-Konfigurationen werden dabei unterstützt. Gerade für Raid-10-Konfigurationen gibt es jedoch im Detail eine Vielzahl von verschiedenen Layout-Möglichkeiten für das Array, die es unter iRST nicht gibt. Diese Optionen erlauben einem eine weitere Optimierung für spezielle Einsatzszenarien. Siehe hierzu etwa:
http://www.ilsistemista.net/index.php/linux-a-unix/35-linux-software-raid-10-layouts-performance-near-far-and-offset-benchmark-analysis.html?start=1
Ich selbst komme darauf aber in einem weiteren Artikel zurück.

Potentielle Folgen von iRST-Einschränkungen bzgl. der Volume-Größe

Die fehlende Freiheit bzgl. der Größenbegrenzung des zweiten imsm-Volumes hat unter iRST bei bestimmten Raid Levels, besonders aber im Fall von großen Raid-5- oder Raid-6-Arrays erhebliche Auswirkungen für evtl. Wiederherstellungsverfahren:

Legt man zwangsweise ein zweites imsm-Volume mit großer Kapazität an, so wird das iRST-Raid-Volume bei irgendwelchen Problemen mit darauf aufgesetzten Filesystemen immer als Ganzes einer Resynchronisation unterworfen. Das passiert z.B. nach unsauberen Shutdowns, bei denen Filesysteme des Raid-Verbandes nicht mehr abschließend mit Caches synchronisiert werden konnten. Fällt gar eine Platte aus, wird der gesamte Container mit beiden Arrays rekonstruiert.

Das kostet bei allen Raid-Formen erhebliche Zeit - vor allem aber für Raid 5/6-Arrays. Die SSD-Geschwindigkeit hilft hier zwar, aber bei großen Arrays mit > 1 TB Kapazität zehrt das im Falle von Raid 5 trotzdem an den Nerven. Zudem wird im Falle von RAID 5 dabei der Verschleiß der eingebundenen SSDs erheblich beschleunigt. Mehr dazu im nächsten Beitrag.

Flexible Größenänderung angelegter Arrays?

Die Größe eines definierten iRST-Raid-Volumes kann im Nachhinein nach meiner Erfahrung weder durch Partitionsausweitung noch durch das Hinzufügen von weiteren Partitionen verändert werden. Bei einem reinen SW-Raid-Array unter Linux ist beides aber über ein paar Zwischenschritte möglich (s. hierzu die mdadm-Literatur; u.a. https://raid.wiki.kernel.org/index.php/Growing und https://www.howtoforge.com/how-to-resize-raid-partitions-shrink-and-grow-software-raid).

Für einen imsm-Container ist mir das bislang mit Linux-Bordmitteln dagegen nicht gelungen. So war es mir u.a. nicht möglich, auf Platten, die bereits einem iRTS-Verband im "imsm"-Format zugeordnet waren, neue Partitionen anzulegen, die ich einem bereits definierten imsm-Raid-5-Volume hätte zuordnen können.

Flexibilität bei Ausfall des Controllers?

Gerade beim Aufbau eines Server-Systems muss man sich fragen: Was geschieht eigentlich, wenn der Controller selbst ausfällt? Ein solcher Ausfall kann, muss aber nicht zum Austausch des gesamten Mainboards führen. Das ist in der Regel immer noch sehr viel billiger als ein HW_Raid-Controller. Eine Frage ist aber: Kann man in der Zwischenzeit die Raid-Platten zur Not auch an ein anderes Linux-System anschließen und die wichtigsten Daten auf andere System transferieren? Unter der Voraussetzung, dass das Array überhaupt noch lauffähig ist?

Nun, da bin ich im Fall von imsm-Containern unsicher. Im schlimmsten Fall benötigt man ein neues Mainboard-Board mit iRST-Funktionalität, um wieder an die Daten des Arrays zu kommen. Andererseits unterstützt mdadm ja auch imsm-Container ... Ich weiß es schlicht nicht - und habe ein solches Ausfallszenario mit iRST/imsm-Containern bislang nicht getestet. Was man aber mit Sicherheit sagen kann, ist Folgendes :

Im Falle eines Linux-SW-Raid-Arrays kann man ein funktionstüchtiges Array auch auf einem anderen Linux-System zum Laufen bringen, wenn die Platten denn physikalisch an einen dortigen Controller angeschlossen werden können. Man hängt die SSD-Platten an den dortigen SATA-Controller,l bootet, aktiviert die md-Raid Module und nutzt ein Plattenverwaltungssystem seiner Wahl - und schon hat man - ggf. nach einer Rekonstruktion des Arrays - wieder Zugriff auf seine Daten.

Zwischenfazit

Ich finde, allein die mangelnde Flexibilität von iRST bei der Definition mehrerer Raid-Arrays mit selbst festgelegter Größe ist ein guter Grund, auf den Einsatz von iRST unter Linux zu verzichten.

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

Verbleiben eigentlich noch Gründe für den Einsatz des iRST?

Mir fallen dazu nur noch folgende Punkte ein:

  • Die Restaurierung bzw. Resynchronisation eines defekten Raid-Verbunds mit einer Ersatz-SSD lässt sich zur Not auch unabhängig vom Betriebssystem - nämlich über BIOS-Funktionen - durchführen. Dies ist im Besonderen dann zu bedenken, wenn man das Betriebssystem selbst auf einem Raid-Array bzw. imsm-Volume und/oder die EFI-Boot-Partition in einem imsm-Container installiert hat.
  • Auf Dual-Boot-Systemen (mit Windows) bringt das Intel-spezifische "imsm"-Format Vorteile. Der Raid-Verbund selbst und entsprechend formatierte Partitionen können dann auch direkt unter MS Windows angesprochen werden.

Der letzte Punkt kann auf Dual-Boot-Systemen tatsächlich einige Bedeutung haben. Die eigentliche Frage ist hier jedoch: Braucht man zwingend eine Dual-Boot-System für den Einsatz von MS Windows? Nun, das wird meist wohl von Kundenwünschen abhängen. Für mich selbst gilt jedenfalls:

Wenn man als Linuxer schon in die Untiefen von MS Windows-Systemen abtauschen muss, dann über Virtualisierung. Etwa über VMware (wenn man unbedingt eine wenig 3D-Effekte unter MS Win sehen will), Virtualbox oder KVM. Und bzgl. Performance des Zugriffs auf virtualisierte "Platten" (bzw. entsprechende Container-Files) gilt dann:

Man kann das virtualisierte Windows ja gerade auf einer Partition eines Linux-SW-Raid-Arrays zum Laufen bringen, wenn man die Disk-Perfromance in die Höhe treiben muss. Das klappt nach meiner Erfahrung sehr gut! Ein Win 7-System, das unter VMware läuft, weist einen Leistungsindex mit 7.9 Punkten von 7.9 möglichen Punkten für seine virtualisierte Platte aus. Diese "Platte" besteht aus einem "vdmk"-Container-File, das auf einer ext4-Partition eines Linux-SW-Raid-Arrays mit SSDs untergebracht wurde. Die ext4-"Partition" wurde dabei auf einem LVM-Volume angelegt. Einen noch besseren Durchsatz würde ich für einen direkten Durchgriff auf eine NTFS-Partition auf dem Array erwarten.

Ausblick

Unsere Artikelserie zu SSD-Raid-Arrays hat bislang ergeben, dass wir uns für kleinere Linux-Systeme auf SW-Raid (unter mdadm) konzentrieren sollten. Will man einen Onboard-Controller von Intel benutzen, so kann und sollte man auf den Einsatz von iRST gut verzichten.

Eine weitere wichtige Frage ist nun: Welche Raid-Variante ist für SSD-Arrays sinnvoll? Nach meiner Einschätzung ist das vor allem eine Frage des Geldbeutels. Überraschenderweise spricht das ggf. gegen den Einsatz von Raid-5- oder Raid-6-Arrays. Das ist Gegenstand des nächsten Artikels dieser Serie:

SSD Raid Arrays unter Linux – VII – problematische Aspekte von Raid-5-Arrays

 

SSD Raid Arrays unter Linux – I – ein facettenreiches Thema

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/.