Re: [OT] Performance von RAID und Dateisystem
Hallo Harald,
On 08/02/2012 04:42 PM, Harald Weidner wrote:
Aktuell läuft dort ein RAID1+0 (jetzt gerade 2 * 8 Platten im RAID0 und
ein RAID1 drüber) mit einer Stripe-Size von 512K.
Das RAID Setup klingt für mich suboptimal. Wenn eine Platte kaputt ist,
ist das gesamte RAID0 unbrauchbar, und es darf keine Platte aus dem
anderen RAID0 Verbund gleichzeitig ausfallen, ansonsten ist das System
unbrauchbar.
Wenn du ein RAID1+0 willst, würde ich eher 8x RAID1 bauen und darüber
stripen. Wenn dann eine Platte ausgefallen, darf eine aus 14 der 15
verbleibenden ebenfalls ausfallen, ohne dass das System unbrauchbar
wird.
das ist richtig. Ich wollte das Setup nur mal ausprobieren. Jetzt gerade
habe ich es umgestellt auf die von Dir beschriebene Variante mit einer
Chunksize von 64K (siehe auch die Antwort an Martin).
Allerdings frage ich mich, ob man sich hier mit RAID1+0 wirklich einen
Gefallen tut. Jede Festplatte sollte mindestens 60 MB/s schaffen, beim
Striping über 8 Platten also 480 MB/s. Die 3Gbit/s SAS Anbindung des
RAID Controllers an den Server schafft aber höchstens 375 MB/s.
Soweit ich gelesen habe, sollte ein RAID5 nicht mehr als 8 Datenplatten
haben. Daher würde nur ein RAID50 in Frage kommen. Ich erhoffe mir von
dem RAID10 im Gegensatz zu dem RAID50 eine höhere Zahl an IOPS.
Der Performanceverlust beim Wechsel auf ein RAID5 ist vermutlich kaum
messbar. Umgekehrt ermöglicht ein RAID5 aber ein größeres Filesystem
und damit ein geringeres Risiko für Fragmentierung. Beim RAID1+0 ist
das FS 8 TB groß, bei einem RAID5 mit Hotspare hättest du 14 TB zur
Verfügung. Eine Datenmenge von 6 TB wären also 75% Belegung beim
RAID1+0 oder 43% bei RAID5.
Der Punkt mit der Fragmentierung ist mir so noch garnicht in den Sinn
gekommen, danke dafür. Die Größe wäre natürlich ganz gut. Im Prinzip
geht es mir aber um die Performance beim Lesen.
Das Dateisystem ist
ext4 mit Standardoptionen. Installiert ist ein Debian Squeeze mit
2.6.32-5-openvz-amd64.
Ist OpenVZ auf dem Backupserver wirklich nötig? Ansonsten würde ich
den normalen amd64 Kernel nehmen. Das spart den Virtualisierungs-
Overhead (ca. 2-3%) und ermöglicht es außerdem, testweise einen
neueren Kernel einzusetzen, z.B. den 3.2 aus Wheezy.
Werde ich ausprobieren. OpenVZ habe ich verwendet, um MySQL sichern zu
können. Dabei habe ich für jeden MySQL-Server im Netz einen Slave mit
OpenVZ gebaut. Damit habe ich einiges an Bandbreite sparen können. Danke
mysqld-multi sollte das aber auch ohne OpenVZ zu schaffen sein.
Ich könnte mir vorstellen, dass XFS anstelle von ext4 hier noch
ein bisschen mehr Performance ermöglicht. Das Filesystem sollte mit
der Option noatime gemountet sein. Als I/O Scheduler würde ich deadline
oder noop wählen, anstelle des cfq, das per Default aktiv ist.
XFS höre ich immer wieder. Ich hatte 2005 einen alten IBM-Server mit
schönen SCSI-Festplatten. Darauf war auch XFS für Daten in Verwendung.
Nach einem Stromausfall hat es mir dann allerdings alle Daten
zerschossen - seitdem habe ich XFS nicht mehr benutzen wollen, denn mit
ext2/3 ist mir so etwas noch nie passiert. Es kann allerdings auch sein,
dass ich einfach zu wenig Erfahrung mit der Administration XFS habe und
deshalb nicht wusste wie man die Daten wieder repariert ;).
Einen erneuten Versuch würde ich jetzt nicht mehr grundsätzlich ablehnen
- vor allem nicht bei diesem System.
Mein Test mit dem aktuellen RAID-Level brachte weit weniger als 15MB/s.
Als mein Kollege den gleichen Test nur leicht abänderte und nur pv(1)
zwischen tar und /dev/null stellte, kam ich auf ~60MB/s. Was ist da los?
Durch die Pipe wird das Schreiben nach /dev/null in einen eigenen Prozess
ausgelagert. Das bewirkt aber höchstens Faktor 2.
Ist denn der Job auch wirklich in einem Viertel der Zeit fertig? Kann es
sein, dass dstat hier einfach zusätzlichen I/O für die Pipe dazugerechnet
hat? Was passiert, wenn du "pv" durch "cat" ersetzt?
Das werde ich definitiv testen.
--
Mit freundlichen Grüßen / Best Regards
Helmuth Gronewold
Teamleiter Systemtechnik
HR4YOU GmbH
Ulbarger Straße 52
D-26629 Großefehn
Tel: +49-4945-91590-26
Fax: +49-4945-91590-29
E-Mail: h.gronewold@hr4you.de
Internet: http://www.hr4you.de
Support: http://www.hr4you.de/home/de/content/Support
Hotline: +49-4945-91590-22 (09:00 - 17:00 Uhr, werktags außer Samstags)
Folgen Sie uns! Aktuelle News über Twitter oder in Facebook.
Geschäftsführer: Axel Rekemeyer, Ute Rekemeyer, Registergericht Aurich,
HRB 1235
---------------------------------------------------
Diese Nachricht enthält vertrauliche Informationen und ist
ausschließlich für den Nutzen des rechtmäßigen Adressaten bestimmt.
Jeder Gebrauch durch Dritte ist verboten. Falls Sie Daten irrtümlich
erhalten haben, nehmen Sie bitte Kontakt mit dem Absender auf und
löschen Sie die Daten auf jedem Computer und Datenträger. Der Absender
ist nicht verantwortlich für die ordnungsgemäße, vollständige oder
verzögerungsfreie Übertragung dieser Nachricht. Vielen Dank!
This e-mail may contains confidential and/or privileged information. If
you are not the intended recipient (or have received this e-mail in
error) please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden. Thank you!
Reply to: