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?