LSI Raid Controller - Raid5 mit mehr als 3 Platten extrem langsam

[xvzf (Gast)]

Hallo,

Ich baue mir aktuell einen Backup Server mit einer 3ware 9650se. 
Folgendes Phaenomen: Wenn ich 12 Platten in 4 Raid5 arrays mit je 3 HDDs 
zerlege, habe ich eine gute schreib performance (ca. 100-120MB/s). 
Schliesse ich jedoch mindestens 4 in einem Raid5 Verbund zusammen, geht 
die Datenrate runter auf bis zu 8MB/s

Da stimmt also etwas nicht... hat jemand eine Idee?

[Georg A. (georga)]

Oje, 3ware... Waren zwar zuverlässig (hatte selber 6 Jahre einen 8506 
mit 10 Platten im Raid5), aber beim Schreiben im Raid5-Mode 
schnarchlahm. Das ist bei den späteren 9er-Versionen mit PCIe nicht 
signifikant besser geworden. Das Web ist voll mit allen möglichen Tips, 
die aber das eigentliche Problem nicht lösen (können). AFAIR war das 
wichtigste das Anschalten des Write-Caches, der ohne Battery-Pack nicht 
automatisch an ist. Dann gabs noch (unter Linux) ein paar 
/proc/sys/*-Tricks, aber über 30-40MB/s bei wirklich grossen Files bin 
ich nie gekommen. Falls das Linux ist, wäre ein Soft-Raid 
überlegenswert, die "kleinen" HW-Raid-Controller ala Areca oder LSI 
(Dell, ...) haben IMO inzwischen keine wirklichen Vorteile mehr und fast 
nur noch Nachteile.

[Lukey S. (lukey3332)]

Zu den /proc/sys/vm Tricks:
Ich hab in meiner rc.local z.b. folgendes stehen

# Komprimierte Ramdisk für Swap anlegen
modprobe zram num_devices=4
sleep 0.1
echo 1 > /sys/block/zram0/reset
sleep 0.1
echo $((1024*1024*2048)) > /sys/block/zram0/disksize
# Unkomprimierte Größe der Disk (bei mir 2Gb)

sleep 0.2
mkswap /dev/zram0
swapon /dev/zram0 -p 10

echo 95 > /proc/sys/vm/dirty_background_ratio 
# Wieviel % Des Freien Arbeitsspeichers dürfen insgessamt als 
# write Cache genutzt werden, bevor (vom Kernel) angefangen Wird die Daten auf die FP zu schreiben?

echo 90 > /proc/sys/vm/dirty_ratio 
# Wieviel % Des Freien Arbeitsspeichers dürfen von einem Einzelnen Programm als 
# write Cache genutzt werden, bevor es bei jedem schreiben direkt auf die FP schreibt?

echo 95 > /proc/sys/vm/swappiness 
# Swappe ungenutzte Programm(teile) oft 
# (bei 100 wären es immer, bei 0 niemals) aus, um platz für den Cache zu schaffen.

echo $((100*60*60)) > /proc/sys/vm/dirty_expire_centisecs 
# Daten können bis zu 1 Stunde lang ungeschrieben im Cache liegen.
 
echo $((100*60*10)) > /proc/sys/vm/dirty_writeback_centisecs 
# Alle 10 Minuten wird geprüft, ob zu alte Daten geschrieben werden müssen.

Beachtet werden muss, dass bei enem Absturz Extrem viele Daten verloren 
gehen können.
Mehr Details gibts hier: 
https://www.kernel.org/doc/Documentation/sysctl/vm.txt

[xvzf (Gast)]

So,

Ich habe meinen Baseclock auf 100Mhz zurueck genommen - jetzt habe ich 
fast 300MB/s schreiben - damit kann ich Leben!

Trotzdem Danke fuer die Hilfe! :)

[_Gast (Gast)]

Hm,


Backup und Hardware Raid?

Was machst du wenn der Raid Controller das zeitliche segnet...


Nimm lieber Softraid, das kannst du bei Linux einfach in ein neues 
System einbinden und fertig. (Sollte halt nichts exotisches sein.)


Habe hier einen Proliant mit 3x3 Platten im Raid Z1, der schreibt auch 
alles was G-Bit LAN hergibt und ich kann die Raid Stapel jederzeit in 
eine andere Maschine einbinden. (NAS4Free mit ZFS Dateisystem, Vorsicht 
ZFS verfrühstückt Arbeitsspeicher und CPU Leistung ohne Probleme)


Ganz wichtig, bevor du deinen Backup Daten anvertraust, testen, was 
passiert, wenn mal eine Platte ausfällt. (Also Platte wechseln und 
Rebuild starten?) und was passiert, wenn der Rechner ausfällt (Kannst du 
den Raid Verband in einen anderen Rechner einbinden?)


mfg
Gast

[(prx) A. K. (prx)]

_Gast schrieb:
> (NAS4Free mit ZFS Dateisystem

Alternativ btrfs.

Vergleich ZFS/btrfs/ext4/XFS: "The results from the Fileserver profile 
in the Filebench experiment is showing that Btrfs has consistently the 
highest performance for all the disk setups whereas ZFS is showing the 
lowest performance."
https://www.diva-portal.org/smash/get/diva2:822493/FULLTEXT01.pdf

Bisher keine Probleme damit (debian, RAID 1).

[Axel S. (a-za-z0-9)]

A. K. schrieb:
> _Gast schrieb:
>> (NAS4Free mit ZFS Dateisystem
>
> Alternativ btrfs.

Das ist alles noch viel zu wenig abgehangen. Vor allem die Tools zur 
Reparatur (sofern überhaupt existent). Meine MD RAIDs habe ich bis jetzt 
immer noch repariert gekriegt. Wobei es meist darauf hinauslief, dem 
MD-Treiber zu verklickern daß er auch die Platten mitbenutzen soll, die 
geringfügig zu alt sind.

Als Filesystem empfehle ich xfs oder ext4.

[(prx) A. K. (prx)]

Axel S. schrieb:
> Meine MD RAIDs habe ich bis jetzt immer noch repariert gekriegt.

Wobei ich es vorziehe, sie nicht erst kaputt zu machen. ;-)

Einen (unfreiwillig) simulierten Plattenausfall habe ich hinter mir, den 
hat btrfs gut überstanden.

Ich habe zudem ein gewisses Grundvertrauen in das 
transaktionsorientierte Arbeitsprinzip von COW Filesystemen. Weil die 
bestehende Daten grundsätzlich nicht überschreiben, sondern anderswo neu 
schreiben und (dem Prinzip nach) nur konsistente Zustände finalisieren.

Filesysteme alten Stils benötigen zwingend Reparaturtools, fsck oder 
Journalling, weil sie diese Eigenschaft nicht besitzen und daher bei 
crash/powerdown einen inkonsistenten Zustand hinterlassen.

[Georg A. (georga)]

> Ich habe zudem ein gewisses Grundvertrauen in das
> transaktionsorientierte Arbeitsprinzip von COW Filesystemen. Weil die
> bestehende Daten grundsätzlich nicht überschreiben, sondern anderswo neu
> schreiben und (dem Prinzip nach) konsistente Zustände finalisieren.

Wobei ich jetzt mit ext3 und ext4 auch keine besonderen Probleme hatte. 
jfs dagegen hatte nach einem unerwartetem Abschalten auf einmal 
Binär-Müll in ein paar /etc/-Config-Dateien, die ganz sicher nicht 
beschrieben wurden... Da nehm ich dann lieber noch FAT ;)

[(prx) A. K. (prx)]

Georg A. schrieb:
> Wobei ich jetzt mit ext3 und ext4 auch keine besonderen Probleme hatte.

Wobei diese Filesysteme (wie auch NTFS) sehr die Geduld vieler Leute 
strapazieren können, wenn das Filesystem recht viele Files enthält und 
das System mal eben weg war. Privat ist das weniger problematisch, aber 
ein sehr länglicher fsck beim Powerup kommt @biz immer zum falschen 
Zeitpunkt.

> jfs dagegen hatte nach einem unerwartetem Abschalten auf einmal
> Binär-Müll in ein paar /etc/-Config-Dateien, die ganz sicher nicht
> beschrieben wurden... Da nehm ich dann lieber noch FAT ;)

JFS ist kein transaktionsorientiertes Filesystem. Wobei ich mit JFS/JFS2 
unter AIX bisher nur gute Erfahrungen gemacht hatte. Reparatur war kaum 
jemals nötig.

[Axel S. (a-za-z0-9)]

A. K. schrieb:
> Ich habe zudem ein gewisses Grundvertrauen in das
> transaktionsorientierte Arbeitsprinzip von COW Filesystemen.
...

> Filesysteme alten Stils benötigen zwingend Reparaturtools, fsck oder
> Journalling, weil sie diese Eigenschaft nicht besitzen und daher bei
> crash/powerdown einen inkonsistenten Zustand hinterlassen.

Es ist ein verhängnisvoller Irrtum, anzunehmen BTRFS oder ZFS bräuchten 
keine Reparaturtools, weil sie COW machen. Das ist nur knapp vor "ich 
brauche kein Backup, ich hab ja ein RAID".

Insbesondere zu diesen beiden Kandidaten möchte ich noch auf 
https://blog.fefe.de/?ts=a9f560e2 verweisen ...

[(prx) A. K. (prx)]

Axel S. schrieb:
> Es ist ein verhängnisvoller Irrtum, anzunehmen BTRFS oder ZFS bräuchten
> keine Reparaturtools, weil sie COW machen.

Habe ich auch nicht behauptet. Es ist nur so, dass dabei anders als in 
klassischen Filesystemen vom Arbeitsprinzip her keine inkonsistenten 
Zustände auftreten. Inkonsistenzen sind damit eine Fehlfunktion, während 
sie in klassischen Filesystemen inhärent sind und durch Reparatur oder 
Journaling abgefangen werden müssen.

> Das ist nur knapp vor "ich
> brauche kein Backup, ich hab ja ein RAID".

Mir gefällt der besser: "Ich brauche kein Backup, ich hab ja fsck". ;-)

[Georg A. (georga)]

A. K. schrieb:
> Georg A. schrieb:
>> Wobei ich jetzt mit ext3 und ext4 auch keine besonderen Probleme hatte.
>
> Wobei diese Filesysteme (wie auch NTFS) sehr die Geduld vieler Leute
> strapazieren können, wenn das Filesystem recht viele Files enthält und
> das System mal eben weg war. Privat ist das weniger problematisch, aber
> ein sehr länglicher fsck beim Powerup kommt @biz immer zum falschen
> Zeitpunkt.

Hm, bei "mal eben weg" gibts eigentlich so gut wie nie einen fsck. 
Ausser man hat vergessen, max-mount-count/time passend zu verstellen. 
Oder das FS hat schon vorher was übles festgestellt... Bei uns gurken so 
200TB rum, von denen Radio/TV läuft, da würden längere Wartezeiten auch 
etwas betriebshinderlich sein ;)