Johannes Truschnigg - SRE & DevOps


Zur Suche ▼Zum Archiv ▼

Eintrag von 2009-10-04

Mehr Durchsatz für Linux-md Software RAID5


RAID steht für Redundant Array of Independent Discs, und sorgt dank verschiedener Paritätsschemata in Industrie und Wissenschaft für hohe Verfügbarkeit von Daten. Wählt man das Schema, mit dem die Daten auf den einzelnen physikalischen Datenträgern landen, besonders klug und geschickt, kann man zusätzlich auch noch mehr Performance aus dem Storage-Backend kitzeln. Genau das versuche ich gerade für das RAID5 meines neuen Homeservers, der mir - bevor ich in den Produktivbetrieb übergehe - als Testbett für vielerlei spannende Technologien dienen soll.

Die für dieses Posting relevanten Daten der Plattform sind:

Hardware:

Software:

Die Festplatten sind vergleichsweise energiesparende Modelle, und bieten ein derzeit ungeschlagenes Preis/Leistungsverhältnis. Einzeln liest jede der Platten sequentiell am (schnelleren) Anfang der Platter ~100MiB/s, was als keinesfalls außergewöhnlich, aber doch ausreichend schnell bezeichnet werden darf. Die erste der vier Platten wurde via cfdisk so partitioniert, dass eine 1500GB fassende primäre Partition mit Kennung 0xfd darauf Platz findet. Dieses Setup habe ich mittels sfdisk auf die übrigen Platten geklont, und dort mithilfe von mdadm ein RAID5-Array eingerichichtet. Joe Nelson hat einen ziemlich guten Performance-Vergleich verschiedener RAID-Setups online gestellt, und gemäß seiner Resultate habe ich mich dazu entschieden, auf eine Chunk Size von 256k und left-symmetric Parity zu setzen. Der Superblock des Arrays ist im 0.90er Format gehalten, sodass automatisches Assembling durch den Kernel während des Bootvorgangs möglich ist. Nach dem Erstellen und Initialisieren des Arrays kam der Verbund (via dd mit verschiedenen Blockgrößen) in den ersten 100GiB auf magere rund 210MiB/s sequentiellen Lesetransfer. Mit dem RAID5-Array alleine war es natürlich auch noch nicht getan: Die Flexibilität und das Snapshotting des Logical Volume Managers (LVM) sind zwei gute Gründe, diesen in fast allen Lebenslagen einzusetzen. Allein, der Performance tat das gar nicht gut: Kaum war das RAID-Array als Physical Volume mit einer zugehörigen Volume Group nebst Logical Volume eingerichtet, sank die sequentielle Leseperformance des resultierenden (LV-)Blockgeräts auf gar nur mehr 160MiB/s. Das kann man sich natürlich nicht gefallen lassen, und so habe ich einige Optimierungsmaßnahmen gesetzt, die deutliche Verbesserungen gebracht haben. Auch wenn ich nicht mitnotiert habe, welcher Schritt welche Leistungssteigerung verursacht hat, kann die folgende Liste an Aktionen doch all jenen dienlich sein, die noch ein paar Prozent mehr Durchsatz aus ihrem md-RAID quetschen wollen:

Optimierungsschritte:

Resultate:

Nach dem Setzen dieser Maßnahmen hat sich die sequentielle Lesegeschwindigkeit des Arrays auf im Mittel knapp über 300MiB/s (fast 50% mehr) gesteigert, und auch der LVM-Penalty beträgt jetzt nicht mehr an die 25%, sondern nur noch rund 3% (von 300 auf 290MiB/s). Mit ext4 auf einem 3TiB großen Logical Volume vermindert sich die Leseperformance nicht weiter, und mit bis zu 270MiB/s sequentieller Schreibgeschwindigkeit braucht sich das Array auch hier vor Enterprise-RAID-Controllern nicht zu verstecken.

Anzumerken bleibt, dass ich ohne Rücksicht auf Verluste streng auf maximal schnellen, sequentiellen Transfer hin optimiert habe. Für meine Usage-Pattern eines Homeserver (hauptsächlich als "Datengrab" für große Mediendateien und Backups) ist das ideal, für andere (wie etwa einen Mailserver mit Maildirs in den Dateisystemen) ganz sicher nicht. Es gibt leider keine "goldene Regel" für das Einrichten eines RAID-Setups. Das beste was man tun kann ist, die beeinflussbaren Parameter so gut es geht auf die eigenen Bedürfnisse und die lokalen Gegebenheiten anzupassen.

In näherer Zukunft möchte ich mich vor allem mit dem NFSv4- und CIFS-Durchsatz auf diesem Host beschäftigen. Sollte es dazu meiner Meinung nach Interessantes zu berichten geben, werde ich es hier in meinem Blog sicher erwähnen.

direkter Link ▲

© 2007-2019 Johannes Truschnigg | valid xhmtl & css