SSD Raid Arrays unter Linux – III – negative Aspekte von Raid-5-Arrays

Im letzten Artikel dieser Serie

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

hatte ich am Beispiel des Intel Z170 RST Controllers ausgeführt, dass es auf einem reinen Linux-System für Raid-Setups nicht notwendig ist, einen Intel-Onboard-Fake-Raid-Controller zu bemühen. Man nimmt sich gegenüber einer SW-Raid-Variante Flexibilität; aber auch die erreichbare Performance ist kein Argument gegen einen reinen SW-Raid-Betrieb unter Linux. Bei Einsatz eines SW-Raid-Arrays für SSDs ist unter Linux allerdings ein wenig Umsicht angebracht. U.a. stellt sich die Frage nach der Wahl der Raid-Variante. In meinem Fall für 4 SSDs. Da liegen als grundsätzliche Alternativen etwa Raid-10 oder Raid-5 Arrays nahe.

In diesem Beitrag möchte ich zwei Argumente dafür anführen, dass die Wahl eines Raid-5-Arrays trotz des größeren verfügbaren (und teuren) SSD-Plattenplatz und guter Performance im sequentiellen Bereich nicht unbedingt die beste Entscheidung ist.

Was sprach im HD-Zeitalter gegen Raid-5- oder Raid-6-Arrays?

Zu nennen war hier aus meiner Sicht an erster Stelle der erhebliche Zeitbedarf zur Rekonstruktion eines degraded Raid-5- oder Raid-6-Arrays - z.B. aufgrund einer defekten Platte oder eines ernsten Fehlers im System (ja, letzteres kommt ab und zu auch unter Linux vor). Das galt im Besonderen, wenn man die Zeitanteile für Rekonstruktionsaufgaben im Raid-Controller oder in der Raid-SW zugunsten der produktiven Performance reduziert hatte.

Nun sind SSDs ja sehr viel rascher als konventionelle HDs. Aus diesem Grund sagten einige Sysadministratoren in Internet-Foren sogar eine Renaissance für Raid-5-Arrays im Kontext eines SSD-Einsatzes voraus. Das Argument ist auch in der Praxis nachvollziehbar. Setzt man die Priorität für eine Raid-5-Resynchronisierung auf Mittelwerte, so liegen die Zeiten für ein 1 TB-Array deutlich unter einer Stunde. Das ist aus meiner Sicht OK. Hinzu kommt die bessere Plattenplatznutzung im Vergleich zu einem Raid-10-System.

Das anderes Argument gegen Raid-5 war die meist schlechte Performance für Random I/O-Bereich und dies vor allem bei kleinen Größen der stückweise zu schreibenden Datenmengen. Write-Caches einiger echter HW-Raid-Controller haben hier geholfen; der Einsatz eines Schreibpuffers ist aber mit Risiken verbunden; Batteriepuffer der Controller waren meist obligatorisch. Um das Thema Performance Raid-5 gegenüber Raid-10 im Fall von SW-Raid unter Linux kümmere ich mich genauer in einem der kommenden Artikel. In diesem Artikel beleuchte ich zwei andere Aspekte - nämlich das Resynchronisationsverhalten bei degraded Arrays und dei Ausführung des FSTRIM-Befehls.

Raid 5 mit einem Intel Raid Fake Controller

In meiner grenzenlosen Naivität begann ich bei der Einrichtung meines SSD-Testsystem zunächst damit, mit Hilfe des onboard iRST-Controllers ein Raid 5-System zu etablieren, obwohl ja bekannt ist, dass eine gerade Anzahl von Platten und Raid 5 nicht sonderlich gut zueinander passen. Für Raid 5 sprachen aus meiner Sicht aber folgende Punkte:

  • Bessere Nutzung der (relativ teuren) Plattenkapazität als mit Raid 10.
  • Optimierung vieler (Fake-) Raid-Controller auf Raid 5.
  • Und nicht zuletzt verleiteten mich meine früheren relativ schlechten Erfahrungen mit Raid 10 auf 3ware-Controllern bei Random I/O zu einem Versuch, mal Raid 5 auszuprobieren.

Ich habe deshalb 4 x 500 GB-SSDs [Samsung EVO 850] zu einem Raid 5-Verbund zusammengeschaltet; dabei wurden ca. 460 GB pro Platte effektiv genutzt. Zum Aufsetzen nutzte ich die UEFI-BIOS-Bordmittel für den Intel-Controller (s. den vorhergehenden Post in diesem Blog). Die resultierende Performance war auch überzeugend:

Ein Read-Durchsatz im sequentiellen Bereich um die 1.45 GB/sec und hohe sequentielle Schreibraten im Bereich von 1.1 GB/sec ließen mich zunächst nicht an meinem Vorgehen zweifeln. Hinzu kam - im Vergleich zu Raid 10 - die relativ hohe verfügbare Plattenkapazität (> 1,36 GB bei 4 EVO 850 500GB SSDs).

Das Betriebssystem hatte ich im ersten Anlauf dummerweise auch im Raid-System selbst installiert. Das kostet, wie bereits im letzten Artikel festgestellt, ca. 10% an Performance. Ich habe die voreilige Entscheidung für Raid 5 dann aber aus einem anderen Grund als vordergründigen Performance-Einbußen bereut.

Resynchronisation des Raid-5-Systems nach Ausfall einer Platte

Dann geschah nämlich etwas, dass normalerweise nicht passieren sollte. Ich hatte ein SATA-Verbindungskabel nicht richtig gesteckt. Als das PC-Gehäuse dann mal bewegt wurde, löste sich das Kabel aus der SSD - mit dem Effekt, dass das Array beim nächsten Start in einen "degraded" Zustand überging. Kein Problem, dachte ich. Genau für solche Situationen hat man ja ein RAID-System. Ich ließ das Array danach wieder aufbauen - der Resynchronisierungsvorgang wurde mit der entsprechenden Funktionalität des Fake-Contorllers im BIOS gestartet und die eigentliche Ausführung dann im gestarteten Linux-System vorgenommen. Insgesamt dauerte das nicht so lange wie aufgrund vieler Internet-Artikel zu dieser Thematik und aufgrund eigener Erfahrungen mit Harddisks befürchtet. Ich habe die Zeit nicht gemessen, aber es dauerte, wie gesagt, sicher deutlich weniger als 1 Stunde.

Was mich dann allerdings schockte, war ein Blick auf den SSD-Zustand mit Hilfe des Kommandos smartctl. Ist Smart im Bios aktiviert, so ist eine Zustandsüberprüfung einzelner SSDs (zumindest auf meinem ASRock-Board) sowohl bei Einsatz eines SW-Raids als auch bei Einsatz des Fake-Raid-Controllers möglich.

Die durch den Ausfall betroffene SSD lief bei mir als Device "/dev/sdd". Die übrigen Devices des Raid-5-Arrays unter /dev/sda, /dev/sdb, /devsdc. Unter den vielen ausgewiesenen Smart-Daten stelle ich nachfolgend nur die Anzahl der "Total_LBAs_written" dar:

Total_LBAs_Written
sda : 604127952
sdb : 846533123
sdc : 603302987
sdd: 3763859973 !!

Nach vielen, vielen Testläufen und ca. 10 immer neuen initialen Raid10-Synchronisationen über 100 GB, 200 GB oder 400 GB-Raid-10-Arrays sieht das heute so aus:

Total_LBAs_Written
sda: 979783261
sdb: 1211867704
sdc: 995650995
sdd: 4121599736

Es ist offensichtlich, dass die eine Resync-Aktion für die Wiederherstellung des Raid-5(!)-Arrays über die gesamte Platte "/dev/sdd" hinweg geschrieben hat (Daten- und Paritätsinformationen). Gleichzeitig ging der Parameter "Wear_Leveling_Count" der vom Ausfall betroffenen Platte um 1 Prozentpunkt nach unten. Die Belastung der Platte durch den Raid-5-Resynchronisationsprozess ist also substanziell gewesen.

Die Wiederherstellung eines Raid10-Arrays erwies sich dagegen in Tests relativ harmlos. Dort werden lediglich abweichende, bereits genutzte Blöcke synchronisiert. Die Resynchronisation ist zudem erheblich schneller als bei Raid 5 abgeschlossen.

Wie ist das Schreiben für die Raid-5-Rekonstruktion im Vergleich zu normaler Plattenbelastung zu werten?

Zum Vergleich: Eine in einem anderen System seit 2 Jahren als Betriebssystemplatte mit virtuellen Maschinen im Dauereinsatz, aber nicht in einem Raid-Verbund befindliche Samsung EVO 840 Pro weist heute einen Wert von

Total_LBAs_Written
sdx: 7968906003

auf. Das ist also immer noch weniger als das Doppelte dessen, was mich eine einzige (!) Resync-Aktion einer Raid-5-SSD gekostet hat. Das liegt nun keineswegs am Einsatz des Fake-Raid-Controllers; die Steuerung und Datenverteilung erfolgt auch hier über Funktionen von Linux's SW-Raid-Verwaltungstools mdadm.

Wie oft muss man mit einem solchen Resync-Prozess rechnen? Erst vor kurzem hatte ich mal einen der zugegebenermaßen seltenen Hänger des KDE-Plasma-Desktops auf dem Testsystem. Das System hing danach vollkommen. Ich befürchtete schon das Schlimmste; der Filesystemzustand war zum Absturzzeitpunkt zwar fehlerhaft, der Plattenzustand über das Raid-Array hinweg aber konsistent. Aber dafür gibt es nun leider überhaupt keine Garantie - schon gar nicht im Falle eines Absturzes während eines intensiven Datentransfers (lesend und schreibend) zu einem Raid-5-System. Ein inkonsistenter Zustand der Platten im Raid-System nach einem ernsthaften Systemfehler ist aus meiner Sicht eher wahrscheinlich. Und dann würde zur Sicherheit vermutlich das gesamte Raid-5-System resynchronisiert werden.

Reichweite des TRIM-Befehls

Ein weiterer Punkt, der im Zusammenhang mit SSDs zu beachten ist, ist das Thema der sog. "Write Amplification" (s. https://en.wikipedia.org/wiki/Write_amplification). Flash-Speicher muss vor einem Neubeschreiben erst gelöscht werden; das führt u.U. zu Verschiebungen von Speicherinhalten und mehrfachen Schreiboperationen. Das reduziert potentiell sowohl die Performance als auch die Lebenszeit von SSDs.

Neben den reinen Nutzdaten müssen im Normalbetrieb auf allen Platten eines Raid 5/6-Verbunds Paritätsinformationen geschrieben werden. Write Amplification (durch Verlagerung von Blöcken auf SSDs) trägt also gerade im Fall von Paritäts-Raids zusätzlich zu einer stärkeren Abnutzung der SSDs bei - gerade in kleineren Arrays (< 8 disks). Theoretisch ist aber die Anzahl der insgesamt durchzuführenden Schreiboperationen auch bei Raid 10 ja nicht kleiner als bei Raid 5. Insofern erscheint mir das Thema der Write Amplification als solches allein noch kein Argument für oder gegen Raid 5 oder Raid 10 zu sein. Eine Konsequenz zur Aufrechterhaltung der Performance und zur Vermeidung von Zeitverlust durch Löschungen besetzter Blöcke bzw. Suchen nach freien Blöcken auf der Platte ist aber, dass die Information über freie Knoten mit dahinterliegenden direkt beschreibbaren Speicherelementen regelmäßig upgedated werden muss. Das Filesystem muss den SSD-Controller - gemeint ist hier der Controller auf der SSD und nicht der Fake-Raid-Controller - über freigewordene, ungenutzte Speicherelemente informieren. Der SSD-Controller muss mit den im Rahmen des (S)ATA-Protokolls übertragenen Information natürlich auch was anfangen können; letzteres ist heute weitgehend der Fall. Unter Linux erledigt das der "fstrim"-Befehl für gemountete Partitionen: einerseits erfolgt die Weitergabe der Information zu freien Knoten; andererseits werden dann von den SSD-Controllern sog. "discard"-Operationen für logisch freigegebene Speicherelemente durchführt. Fortschrittliche Controllers sehen zudem regelmäßige Lösch- und Speicher-Reorganisationsverfahren (SSD garbadge collection) auf den SSDs vor. Nun können Betriebssystem und Raid-(Controlling)-SW zwar in intelligenter Weise dazu beizutragen, um "Write Amplification" zu reduzieren. Hierfür sind meist Zwischenpufferungen von Operationen nötig. Siehe hierzu die interessanten Diskussionen unter http://www.webhostingtalk.com/showthread.php?t=1457939
http://cesg.tamu.edu/wp-content/uploads/2012/02/hotstorage13.pdf

Aber:
Das Thema der Speicherfreigabe und -reorganisation bleibt unabhängig von der Anzahl der Schreiboperationen für SSD-Raid-Arrays bestehen. Somit stellt sich für den Einsatz eines bestimmten Raid-Verfahrens für SSDs auch die Frage, ob der "FSTRIM"-Befehl für die verschiedenen Raid-Varianten eigentlich durch die potentiell betroffenen Layer

Linux-Filesystem (z.B. ext4) - Logical Volume einer LVM-Gruppe - Array über Raid-Partitionen - Partitionen verschiedener SSDs

zu den Controllern der beteiligten SSDs durchgereicht wird.

Leider ist das gerade für Raid-5- oder Raid-6-Arrays nicht der Fall - weder im Falle von SW-Raid noch im Falle des Einsatzes eines Intel Z170 Fake-Controllers. Ich erhalte bei entsprechenden Versuchen regelmäßig Meldungen, dass die zugrundeliegende Infrastruktur den fstrim-Befehl nicht unterstützen würde.

Auf meinen Test-Systemen konnte ich dagegen feststellen, dass der FSTRIM-Befehl an logische LVM-Volumes auf Raid-0-, Raid-1- und Raid-10-Arrays anstandslos durchgereicht wird - zumindest für ext4-Filesysteme. (Andere Filesysteme wie BTRFS habe ich nicht getestet; generell herrscht ja die begründete Meinung vor, dass EXT4 dem Verhalten von SSDs am besten entgegenkommt). Das gilt für reines SW-Raid unter mdadm wie auch den Einsatz des Onboard Fake Raid-Controllers von Intel. (Diese Aussagen kann ich genau genommen im Moment nur für Opensuse-Leap 42.1/42.2 (Kernel 4.4) und ein Debian Jessie-Test-Systeme mit Kernel 4.7 treffen.)

D.h. potentielle Einschränkungen der Performance sind zumindest bei ext4-Filesystemen auf Raid-5-Systemen vorprogrammiert, wenn nicht der Plattencontroller selbst die Garbage Collection und Speicherreorganisation übernimmt. Tatsächlich konnte ich für ext4-Partitionen nach Durchführung von Tests, bei denen mehr als 40 % eines Filesystems beschrieben wurden, regelmäßig Performanceverbesserungen nach Absetzen eines FSTRIM-Befehls feststellen. Zwar keine weltbewegenden Änderungen, aber doch im 10% - 20%-Bereich. Einschränkungen der Performance tauchen mit dem Auffüllen einer Partition also mit hoher Wahrscheinlichkeit auf.

Nun wird und wurde von SSD-Herstellern und Kommentatoren im Internet oft angeführt, dass gerade größere SSDs für den professionellen Einsatz selbst für eine regelmäßige Garbage Collection sorgen. Nun habe ich sowohl EVO 840 Pros und EVO 850 Pros mit 500GB Kapazität auf verschiedenen Systemen im Einsatz und setze ab und zu den fstrim-Befehl für eingerichtete Partitionen manuell ab. Die benötigten Zeiten zur Speicherreorganisation dauern für meine Gefühl relativ lange und betreffen manchmal etliche zig GB. Dabei werden offenbar auch echte Operationen auf den Disks durchgeführt. Das spricht aus meiner Sicht zumindest nicht für eine hohe Frequenz der automatischen Garbage Collection der SSD-Controller. Das mag bei anderen SSDs anders sein.

Aus meiner Sicht ist es daher empfehlenswert, vor dem produktiven Einsatz sicherzustellen, dass entweder die eingesetzten SSDs selbst eine Garbage Collection durchführen oder eben der FSTRIM Befehl im angestrebten Raid-Verbund funktioniert.

Warnung von Red Hat vor dem Einsatz von SW-Raid-5 mit SSDs

Eigentlich hätte man ja fast mit dem oben beschriebenen Resynchronisations-Verhalten nach einem Plattenausfall rechnen können: Wenn 1 Platte ausfällt, müssen auf der Ersatzplatte (in meinem Fall die ursprüngliche Platte) ja alle Dateninformationen untersucht, Paritätsinformationen neu berechnet und neu geschrieben werden. Es war naiv anzunehmen, dass man die Platte einfach wieder einhängen könne - und die meisten Informationen beim Resynchronisieren noch als valide erkannt werden würden.

Wie eine Recherche im Internet ergab, warnt Red Hat aus ähnlichen Gründen vor dem Einsatz u.a. von Raid 5 für SSDs; s.
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/ch-ssd.html
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Storage_Administration_Guide/ch-ssd.html
Zitat:

Red Hat also warns that software RAID levels 1, 4, 5, and 6 are not recommended for use on SSDs. During the initialization stage of these RAID levels, some RAID management utilities (such as mdadm) write to all of the blocks on the storage device to ensure that checksums operate properly. This will cause the performance of the SSD to degrade quickly.

Fazit

Legt man die obigen Erfahrungen zugrunde, so läuft die Entscheidung zwischen Raid 10 und Raid 6 im Normalbetrieb auf

  • eine Abwägung von Performance-Vor- und -Nachteilen,
  • eine Bewertung des effektiv verfügbaren Plattenplatzes
  • und eine Bewertung des SSD-Verschleißes, der im Fall der Resynchronisation eines Degraded Raid-5-Arrays auftritt,

hinaus.

Die Tatsache, dass alle Blöcke eines ausgefallenen Raid-5-Devices bei Resynchronisations-Prozessen neu geschrieben werden, ist für mich jedenfalls Grund genug, auf (SW-) Raid-5 zu verzichten. Das ist schlicht ein Kostenthema. Mag sein, dass neue SSDs länger halten als alte. Aber nach 3 Jahren bereut man es dann plötzlich, dass die Platten ggf. den hohen Belastungen in mehreren Synchronisations-Prozessen ausgesetzt waren. Mich beunruhigt es jedenfalls, wenn eine einzige Resynchronisation der Platte mehr abfordert als 1 bis 2 Jahre Normalbetrieb. Das Kostenargument betrifft aus meiner Sicht vor allem kleinere Unternehmen und Freelancer, die Linux-Arbeitsstationen und -Server einsetzen, deren finanzielle Ressourcen und Möglichkeiten zum Austausch ganzer SSD-Arrays begrenzt sind.

Hinzu kommen potentielle Performance-Einbußen durch ein fehlendes Weiterreichen des FSTRIM-Befehls an Filesysteme auf Raid-5-Arrays. Das relativiert die Performance-Vorteile beim Lesen, die ein Raid-5-System gegenüber einem Raid-10-System aufweist, etwas. Zudem gilt:

Wer aus irgendwelchen Gründen eine verbesserte Lese-Performance unter Raid 10 anstrebt, kann auch mal das Far- der ein Near/Far-Layout des Raid10-Arrays ausprobieren. Das Far-Layout geht allerdings zu Lasten der Schreibperformance - und dies besonderes für Random I/O. Aber Raid-5 ist gerade für häufigen Random I/O kleinerer zu schreibender Datenmengen wenig performant.

Ich komme auf Performance-Aspekte in weiteren Artikeln dieser Serie zurück.

Interessante Links

https://www.thomas-krenn.com/de/wiki/ATA_Trim
https://wiki.debian.org/SSDOptimization
http://cesg.tamu.edu/wp-content/uploads/2012/02/hotstorage13.pdf
https://en.wikipedia.org/wiki/Write_amplification
http://www.webhostingtalk.com/showthread.php?t=1457939
http://serverfault.com/questions/513909/what-are-the-main-points-to-avoid-raid5-with-ssd
https://lowendtalk.com/discussion/10000/don-t-build-ssd-in-raid5
https://www.reddit.com/r/sysadmin/comments/3m9req/how_would_you_configure_an_mdadm_raid_5_w_ssds/?st=ivpbg325&sh=a09d50fd
http://researchweb.watson.ibm.com/haifa/conferences/systor2011/present/session5_talk2_systor2011.pdf
http://superuser.com/questions/461506/intel-matrix-storage-manager-vs-linux-software-raid

Bzgl. der grundsätzlichen Einstellung von LVMs und des Absetzens von TRIM-Anweisungen im Kontext von LVM-Operationen siehe etwa:
http://blog.neutrino.es/2013/howto-properly-activate-trim-for-your-ssd-on-linux-fstrim-lvm-and-dmcrypt/

Near/Far-Layout füe Linux SW-Raid-10
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

Bitmaps
http://www.tutorialspoint.com/unix_commands/mdadm.htm

Schreibe einen Kommentar