Re: [OT] Performance von RAID und Dateisystem
Am Donnerstag, 2. August 2012 schrieb Helmuth Gronewold:
> Hallo Liste,
Hi Helmuth,
> aktuell suche ich noch der richtigen Konfiguration für einen Backup-
> Server. Dabei teste ich verschiedene RAID-Konfigurationen (Stripe-Size,
> RAID10 / RAID50) und Dateisystemoptionen. Das Hardware-Setup sieht wie
> folgt aus:
Etwas, was auf RAID 5 basiert empfiehlt sich nur, wenn langsame Schreibperformance tolerierbar ist.
Und selbst dann: Wenn während eines langwierigen und aufwendigen Recoveries eine weitere Platte ausfällt oder nur zeitweise Probleme hat, dann ist das bei RAID 5 blöd. Weitere Infos:
Battle Against Any Raid Five
http://www.baarf.com/
Ein Beispiel dafür:
http://www.miracleas.com/BAARF/RAID5_versus_RAID10.txt
Kann sinnvoll sein, da mal durchzuschmökern und dann sich noch mal die Frage zu stellen: Will ich irgendein RAID 5 (or 6) wirklich?
> 16 * 1TB SATA2 (WD Raid Edition 3 und 4, 7,2krpm) in einem Infortrend
> A16S-G2130, verbunden mit einem HP DL360g6 über SAS, 3Gbit. Der DL360
> hat 8GB RAM und einen Xeon 5506 mit 4 Cores. Das Betriebssystem hat
> extra nochmal 2 SAS-Platten im RAID1 Der SAS-Connector zum Infortrend
> ist ein LSI Logic / Symbios Logic SAS1068E PCI-Express Fusion-MPT SAS
> (rev 08), laut lspci. Weiterhin ist eine kleine Tape-Library (LTO5) von
> HP angeschlossen.
Hört sich doch erstmal ganz nett an.
> 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 Dateisystem ist
> ext4 mit Standardoptionen. Installiert ist ein Debian Squeeze mit
> 2.6.32-5-openvz-amd64.
Ein 3.2er-Backport-Kernel kann die Geschwindigkeit und Latenz schonmal verbessern. Zwischen 2.6.32 und 3.2 liegen mehrere Runden großer Umbauten am Block Layer.
Die Stripe Size des Dateisystem ist an die Stripe Size des RAID-Controllers anzupassen. Alleine diese Änderung kann einen deutlichen Unterschied machen.
> Die Dateien, die später auf dem Backup-Server liegen sind eher klein
> (~1MB im Durchschnitt, wie auf Webhosting-Systemen mit sehr vielen
> Dateien < 500KB). Das Volumen beträgt ca. 3,5 TB. Die Daten kommen aus
> zwei Rechenzentren, werden jede Nacht via rsync geholt und liegen dann
> dort bereit um sie auf Bänder zu sichern.
> Das ganze Setup war vorher etwas kleiner (8 * 1TB im RAID5), was gerade
> im 3/4 vollem Zustand eine Lese-Performance von < 10MB im Durchschnitt
> gebracht hat. Mit den weiteren Platten und dem richtigen RAID-Level und
> Dateisystem möchte ich so viel heraus kitzeln wie möglich.
Bei Ext4 dürfte die Metadaten-Performance – Anlegen, Löschen vieler kleiner Dateien – immer noch etwas schneller sein. Zumindest auf einer einzelnen Harddisk. XFS mit delaylog und einer optimierten Anzahl an Allocation Groups kann jedoch gerade in einem Setup mit vielen Platten zu einer ausgeglicheneren Performance führen.
Dann ist eine Kernfrage: Hat der Controller einen batteriegepufferten Cache und sind da auch Akkus in gutem Zustand drin?
Wenn ja, dann empfehle ich:
1) Akku-gepufferter Schreib-Cache an.
2) Write Caches auf den Festplatten aus. (Sind nicht akkugepuffert, es sei denn ihr habt eine unterbrechungsfreie Stromversorgung).
3) Write Barriers / Cache Flushes aus.
Sich freuen über eine Teils erheblich höhere Performance.
> Um einen initialen Test zu machen, benutze ich dstat für die Anzeige
> des aktuellen Durchsatzes und der erreichten Zahl IOPS, ~600GB echte
> Daten (nichts generiertes für den Test) und tar nach /dev/null, wobei
> ich vorher den Buffer-Cache leere:
>
> echo 3 > /proc/sys/vm/drop_caches
> tar cf - /srv/data > /dev/null
>
> 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?
>
> echo 3 > /proc/sys/vm/drop_caches
> tar cf - . | pv > /dev/null
>
> Warum hebt ein pv die Geschwindigkeit um das vierfache an?
Keine Ahnung. Vielleicht nimmt es standardmäßig größere Puffergrößen?
> Gibt es ein Tool für die Kommandozeile, mit dem ich die wirklichen
> Werte, zum Beispiel die Größenverteilung der Dateien, ermitteln kann?
Was immer für dich wirkliche Werte sind.
Ich denke, es gibt was, das die Größenverteilung von Dateien in einem Verzeichnisbaum ermittelt. Läßt sich aber auch selber schnell zusammenskripten.
Dann gibts noch so Sachen wie
- bonnie++ (das sich nur mit wirklich sinnvollen Parametern empfiehlt, Manpage lesen)
- fio
- evtl. filebench, wobei ich da die gelieferten Werte meinen Erwartungen nicht ganz entsprachen und ich daher da noch etwas skeptisch bin
Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Reply to: