Wir haben ein Monster geschaffen!

Inspiriert durch Isotopps Artikel Ich habe ein Monster geschaffen! gibt es hier auch mal wieder einen techniklastigen Artikel von mir.

Unser bisheriger Backup-Server im Datacenter war ein betagter Proliant DL380 G3 und sollte durch etwas aktuelleres ersetzt werden, vorzugsweise mit mehr Plattenplatz als nur 6x 300GB im RAID10.

Aus wirtschaftlichen Gründen (es ist “nur” ein Backupserver) haben wir uns gegen einen Server von HP entschieden, nicht zuletzt weil die 1TB SATA-Platten von HP mit 299€/Stück einfach jenseits von gut und böse liegen im Vergleich zu aktuellen Preisen für nicht-HP SATA-Platten im regulären Handel.

Bei der Wahl des Chassis hatten sich mein Azubi und ich relativ schnell für das Chieftec UNC-410F-B entschieden – 4U, 10 5,25″-Einschübe und damit genug Platz für Platten. Außen an das Gehäuse kommt eine Schiene RSR-260 zwecks Rackmontage und fertig ist das Chassis.

Den Saft für den Server liefert das redundant ausgelegte 500W-Netzteil MRG-6500P, das mit seinen 8 Molex- und 2 SATA-Steckern vorläufig genug Anschlüsse liefert.

Beim Mainboard haben wir uns an das von Kris verbaute Asus P5Q Premium gehalten, mussten aber leider während der Testphase feststellen, dass von den 10 SATA-Ports nur 8 sinnvoll nutzbar sind und haben deshalb auch noch eine Adaptec 1430SA nachgekauft.

Auf dem Mainboard findet anschließend eine Intel Core2Quad Q9550 Boxed (C1) CPU, 4x 2GB RAM und eine beliebige Grafikkarte Platz.

Bei der Suche nach passenden Backplanes wurden wir bereits auf der Zubehörseite des Chassis fündig: 3 Backplanes SST-2131SAS verstauen insgesamt 9 Western Digital Caviar WD15EARS.

2 Backplanes bilden mit ihren je 3 Platten ein Software-RAID5 auf dem dann LVM mit einem striped Logical Volume aufsetzt – quasi ein RAID50, durch LVM aber komfortabler zu managen.

Debian Lenny 64-bit ist per PXE-Boot, USB-Stick oder USB-CDROM innerhalb von 10 Minuten installiert, anschließend installieren wir BackupPC und übernehmen die Config-Files vom alten Server.

Beim Partitionieren der Platten sollte man die Sektorgröße von 4kB beachten – “normales” Partitionieren, so wie es der Linux-Sysadmin gewohnt ist, lässt die Schreibperformance auf diese Partitionen auf wenige MByte/s einbrechen.

Wie man es richtig macht findet man im Wiki von brain4free: WD “Advanced Format” HD mit LINUX.

Mittels pvs -o+pe_start stellt man sicher, dass die Nutzdaten des LVM-Layers auf einem Vielfachen der Chunksize des RAID5 beginnen:

PV         VG     Fmt  Attr PSize PFree 1st PE
/dev/md1   debian lvm2 a-   1.36T 1.36T 192.00K
/dev/md2   data   lvm2 a-   2.73T    0  192.00K
/dev/md3   data   lvm2 a-   2.73T    0  192.00K

Da meine Chunksize 64kB beträgt, passt der Beginn der Daten an Stelle 192kB also:

md2 : active raid5 sdd1[0] sdf1[2] sde1[1]
2930152704 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]

md3 : active raid5 sdg1[0] sdi1[2] sdh1[1]
2930152704 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]

lvs -o+stripes,stripesize,devices

LV       VG     Attr   LSize #Str Stripe Devices
backuppc data   -wi-ao 5.46T    2 64.00K /dev/md2(0),/dev/md3(0)

Wer an dieser Stelle stutzig wird, hat offenbar schon mehrfach mit Software-RAID zu tun gehabt:

Bei einem RAID5 aus 3 Platten mit einer Chunksize von 64kB müsste die optimale Stripesize für das darüberliegende Logical Volume 128kB sein. Verschiedene Benchmarks haben aber zu meiner Verwunderung ergeben, dass die Write-Performance mit der 64kB Stripesize um 10-15 MByte/s höher lag als bei der rechnerisch optimalen Stripesize von 128kB.

Das auf dem LV liegende ext3 FS sollte ebenfalls passend angelegt werden: Mit dem mkfs.ext3 RAID stride calculator ergibt sich bei einem RAID0 über 2 “Platten” mit einer Stripesize von 64kB und einer FS-Blocksize von 4kB folgendes mkfs-Command:

mkfs.ext3 -b 4096 -E stride=16,stripe-width=32 /dev/data/backuppc

Damit erfolgen Schreiboperationen auf das Dateisystem nun in optimaler Weise.

Weitere Stellschrauben:

Das Optimieren der stripe-cache-size der 2 RAID5-Bricks von default 256kB auf 4096kB hat bei uns die lineare Writeperformance auf das LV von 180 MByte/s auf 300 MByte/s gesteigert; recht beachtlich, wie ich finde.

Update: ext3- und xfs-Benchmarks mit bonnie++ auf dem LV.

Update: Smart-Werte (sda+sdb = System, sdc = Spare, sdd-sdi = Daten)

Comments ( 9 )

  1. Marco
    Das Gehäuse oder ein sehr ähnliches von Chieftec kleidet auch unseren Backup Server. Mit persönlich gefällt es aber so gar nicht. Viele viele schräubchen ;-) Gruß Marco
  2. Marcel
    Das ist wohl wahr. Alleine das Befestigen der Schienen im Rack und am Server ist mit Werkzeug- und Zeiteinsatz verbunden - bei HP dauert die Montage keine Minute. Für alle anderen Server kaufen wir auch weiterhin HP, da es doch sehr ausgereifte Technik ist - redundante hotplugfähige Lüfter, iLo, aussagekräftige Info _welches_ Bauteil bei einem Defekt betroffen ist (das Ausklapp-Display ist toll) und vieles mehr. Aber bei dem Backup-Server ging das halt preislich doch arg auseinander... Gruß, Marcel.
  3. Willi
    Wie sieht das ganze aus der Kaufmännischen Perspektive aus? Kosten für die Hardware bzw. die Arbeitsstunden für den Bau und Einrichtung der Komponenten und Software?
  4. Alexander
    Hast du schonmal bonnie++ o.Ä. drüberlaufen lassen? Mich würde mal interessieren, wieviel Durchsatz so ein komplett auf Software basierendes RAID 50 schafft. Ich selber hatte mit dem mdraid unter Linux leider schon ein paar kleine Probleme (RAID 1 - eine Festplatte geht kaputt und das System friert komplett ein), dass ich dem momentan nicht mehr so ganz traue - aber das ist mittlerweile auch 2 Jahre her und ich lasse mich da gerne eines besseren belehren :) Grüße, Alexander
  5. Marcel
    @Alexander Wir hatten mit bonnie++ ein paar Tests gemacht, sowohl mit xfs als auch ext3. Habe die Ergebnisse im Artikel verlinkt. Gruß, Marcel.
  6. Matthias
    >hier auch mal wieder einen techniklastigen Artikel von mir. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Klingt wichtig... weiß ich ja, wen ich meinen Webserver optimieren lassen kann. ;-)
  7. Nicolai
    Verhalten sich die wd15ears genauso problematisch , wie die EADS Serie (meine hohe load_cycle_count nach kurzer zeit usw.? Was spricht smartctl bei dir ? Gruß aus Berlin,
  8. Marcel
    @Nicolai Siehe oben im Artikel. Bei den 2 Platten mit dem Betriebssystem drauf ist der Load_Cycle_Count in der Tat relativ hoch. Ich werde das mal beobachten und vielleicht mit wdidle3 versuchen Abhilfe zu schaffen. Andere Vorschläge?
  9. adminblogger.de
    Load_Cycle_Count / WD Caviar Green... Wie von Nicolai in den Kommentaren zu Wir haben ein Monster geschaffen! angemerkt, sind die SMART-Werte für Load_Cycle_Count bei den Western Digital WD15EARS-Platten bedenklich: Um Strom zu sparen, wird der Schreib-/Lesekopf nach 8 Sekunden Inaktivit....