RAID-5 oder RAID-6?

[Thunderbyte]

Ein Punkt, der für ein Raid6 spricht: wenn ein Raid5 nach HD Ausfall rebuildet, ist es in maximaler Beanspruchung bei gleichzeitig fehlender Redundanz. Sollte beim Rebuild (stundenlang) eine weitere Platte ausfallen, ist das Raid im Eimer. Mit dem Raid6 fehlt sich auch beim Rebuild nichts und man verliert eigentlich nie die Redundanz.

Was anderes als Raid 1 oder 10 macht man eigentlich dann, wenn man weniger als 50% des physischen Plattenplatzes opfern will. Das kann ich im vorliegenden Fall auf jeden Fall nachvollziehen.

Sofern ein Backup vorhanden ist (Raid schützt eh vor Backup nicht), wäre m.E. auch ein Raid 5 durchaus statthaft, wenn die Ausfallzeit (mehrere Stunden bis Tage) geschultert werden kann und der Platzgewinn für die Anwendung vorteilhaft ist.

Ich würde bei derartigen Speichermengen auch NUR einen Hardware Raid Controller verwenden, allein schon um der besseren Schreibperformance bei Raid5 und 6 willen.

 

[s24!]

Software Raid in einem Fileserver? Macht man im prof. Umfeld normalerweise nicht.

Was man theoretisch wie in welchem Umfeld macht, ändert nichts daran, dass hier kein Hardware-RAID zur Verfügung steht.

Für die Replikation ist da hoffentlich eine zweite NIC eingebaut? Somit wäre auch ein Desaster-Recovery kein Thema.

Leider nein. Ich sag ja, ein Restore wäre ungünstig. =)

darf ich fragen, wie zufrieden du mit dem MogileFS bist und warum du dich für das System entschieden hast?

Das würde jetzt hier den Rahmen sprengen - ich muss aber vorab sagen, dass ich mich gar nicht dafür entschieden habe. Das von mir administrierte Projekt existiert seit über sechs Jahren, wird aber erst seit einem halben Jahr von mir betreut. Das MogileFS war schon vor mir da.


Um mal auf den Speed zurückzukommen: Der RAID-Build ist durch und ich habe ein wenig getestet. Und obgleich die Mountoptionen noch zu 100% auf den Defaults stehen, halte ich die Ergebnisse für schlecht:

root@filer2 ~ # dd if=/dev/zero of=test bs=1M count=1024 oflag=sync
1073741824 bytes (1.1 GB) copied, 30.3195 s, 35.4 MB/s

root@filer2 ~ # dd if=/dev/zero of=test bs=4M count=1024 oflag=sync
4294967296 bytes (4.3 GB) copied, 56.0912 s, 76.6 MB/s

root@filer2 ~ # dd if=/dev/zero of=test bs=8M count=1024 oflag=sync
8589934592 bytes (8.6 GB) copied, 90.5399 s, 94.9 MB/s

root@filer2 ~ # dd if=/dev/zero of=test bs=512k count=1024 oflag=sync
536870912 bytes (537 MB) copied, 27.0132 s, 19.9 MB/s

root@filer2 ~ # dd if=/dev/zero of=test bs=2048k count=1024 oflag=sync
2147483648 bytes (2.1 GB) copied, 33.7953 s, 63.5 MB/s

root@filer2 ~ # dd if=/dev/zero of=test bs=3584k count=1024 oflag=sync
3758096384 bytes (3.8 GB) copied, 46.318 s, 81.1 MB/s

Folgendes konnte ich Wikipedia entnehmen:

Einfluss auf die Write-Performance

Im Unterschied zur Read-Performance ist das Ermitteln der Write-Performance bei RAID 5 deutlich komplizierter und hängt sowohl von der zu schreibenden Datenmenge, als auch von der Anzahl der Platten ab.[2] Ausgehend von Festplatten mit weniger als 2TB Plattenplatz, ist die atomare Blockgröße (auch Sektorgröße genannt) der Platten häufig 512 Byte (siehe Festplatte: Speichern und Lesen von Daten). Geht man weiter von einem RAID-5-Verbund mit 5 Platten (4/5 Daten und 1/5 Parität) aus, so ergibt sich folgendes Szenario: Will eine Anwendung 2048 Byte schreiben, wird in diesem günstigen Fall auf alle 5 Platten genau je ein Block zu 512 Byte geschrieben, wobei einer dieser Blöcke keine Nutzdaten enthält. Im Vergleich zu RAID 0 mit 5 Platten ergibt sich daraus eine Effizienz von 80 % (bei RAID 5 mit 3 Platten wären es 66 %). Möchte eine Anwendung nur einen Block von 512 Byte schreiben, so ergibt sich ein ungünstigerer Fall, es müssen zuerst der abzuändernde Block und der Paritätsblock eingelesen werden, danach wird der neue Paritätsblock berechnet und erst dann können beide 512-Byte-Blöcke geschrieben werden. Das bedeutet einen Aufwand von 2 Lesezugriffen und 2 Schreibzugriffen, um einen Block zu speichern. Geht man vereinfacht davon aus, dass Lesen und Schreiben gleich lange dauern, so beträgt die Effizienz in diesem ungünstigsten Fall, dem sogenannten RAID 5 write Penalty, noch 25 %. In der Praxis wird dieser Worst-Case-Fall bei einem RAID 5 mit 5 Platten aber kaum eintreten, denn Dateisysteme haben häufig Blockgrößen von 2 kB, 4 kB und mehr und zeigen daher praktisch ausschließlich das Well-Case-Schreibverhalten. Gleiches gilt analog für RAID 5 mit 3 Platten. Unterschiedlich verhält sich hingegen etwa ein RAID-5-System mit 4 Platten (3/4 Daten und 1/4 Parität), soll hier ein Block von 2048 Byte geschrieben werden, sind zwei Schreibvorgänge notwendig, es werden dann einmal 1536 Byte mit Well-Case-Performance geschrieben und noch einmal 512 Byte mit Worst-Case-Verhalten. Diesem Worst-Case-Verhalten wirken zwar Cache-Strategien entgegen, aber dennoch ergibt sich hieraus, dass bei RAID 5 möglichst ein Verhältnis von zwei, vier oder auch acht Platten für Nutzdaten plus einer Platte für Paritätsdaten eingehalten werden sollte. Daher haben RAID-5-Systeme mit 3, 5 oder 9 Platten ein besonders günstiges Performanceverhalten.

Zwar ist das hier ein RAID-6, aber grundsätzlich sollte sich der Text doch auch hierauf anwenden lassen, oder? Entsprechend besonders "bewusst" durchgeführt wurden daher die Tests mit 512, 2048 und 3584k - bei letzterem wird mit die höchste Performance erzielt, aber die Durchschnittsdatei hat < 1 MB (meine ich - werde ich noch nachsehen) - und auch im "Well Case" erscheint mir das Ganze zu langsam, wobei das okay wäre.

Habe hier nach wie vor zwei Sachen im Verdacht:

md2 : active raid6 sda3[0] sdg3[6] sdf3[5] sde3[4] sdd3[3] sdc3[2] sdb3[1]
      14638208000 blocks super 1.2 level 6, [B]512k chunk[/B], [B]algorithm 2[/B] [7/7] [UUUUUUU]

Dateisystem-Info dazu:

root@filer2 ~ # dumpe2fs /dev/md2 | grep -i "block size"
Block size:               4096

Festplatten laut parted:

Sector size (logical/physical): 512B/4096B

RAID laut parted:

Sector size (logical/physical): 512B/4096B

Was meint ihr?



Grüße
Tim

 

[Thunderbyte]

Ich würde meinen, Du hast das typische Verhalten einer oder mehrerer Festplatten (im Gegensatz zu SSDs) bei kleineren Dateien und Software Raid gebenchmarkt.

Ich würde meinen, dass ein Hardware Raid mit vernünftiger eigener CPU und Cache Speicher hier deutlich bessere Ergebnisse hinzaubert. Zumindest tuts das in meinem Raid6 mit Hot Spare Server. ;-)

Ich glaube, dass die von Dir geposteten Parameter allesamt nicht DIE Auswirkung haben, die Dir einen riesigen Sprung an Performance bringt. Sei zufrieden mit den Werten oder hol Dir einen HW Raid Controller. Dazwischen gibts m.E. nicht viel.

 

[virtual2]

Was man theoretisch wie in welchem Umfeld macht, ändert nichts daran, dass hier kein Hardware-RAID zur Verfügung steht.

Das ist dann natürlich wieder eine andere Sache.

 

[Firewire2002]

Man muss aber auch dazu sagen, dass Hetzner in der Produktreihe auch ein größeres Produkt anbietet. Mit 15 (statt 7) Platten und einem 16 Port HW-Raid Controller (statt SW-RAID) für rund das doppelte Geld. Insgesamt also ein wesentlich besseres Preis/Leistungsverhältnis.
Wenn du eh mehrere Storage-Server betreibst, wäre das vielleicht die sinnvollere Alternative gewesen und stattdessen weniger Server hinzustellen.

 

[remote_mind]

Wenn ich noch was für den Fall dass Du LVM benutzt einwerfen dürfte...

Mach mal ein

pvs -o +pe_start

und schau dir an was bei '1st PE' für dein PV steht.

Bei mir (LSI-HW-Raid mit 256k chunk size) macht LVM nämlich default-mäßig das Falsche:

  /dev/sda5  leia      lvm2 a-   73,76g 12,65g 192,00k

D.h. meine Daten haben einen 192k-Offset, was bei 256k stripes eher blöd ist.

Habe es aber noch gemerkt, man kann das mit

pvcreate --dataalignment 512k <pv-device>

beeinflussen. 512k würde für 64k,128k,265k und 512k stripe size passen. Ich frage mich wieso hier der Default nicht gleich auf 512k gesetzt wird, die paar Bytes pro PV...

Bei einen RAID mit Parität kann das, je nach Anwendungsfall, ganz schön weh tun.

schöne Grüße,
Nils

 

[s24!]

Ich würde meinen, Du hast das typische Verhalten einer oder mehrerer Festplatten (im Gegensatz zu SSDs) bei kleineren Dateien und Software Raid gebenchmarkt.

Dieses "Phänomen" ist mir bekannt - aber genau dem sollte ich doch mit einer besser angepassten Chunksize entgegenwirken können. Bei einer Chunksize von 512k habe ich, wenn ich 512k schreibe, doch den "Worst Case" und wäre mit einer Chunksize von 64-128k deutlich besser bedient - oder?

Sei zufrieden mit den Werten oder hol Dir einen HW Raid Controller.

Ist immer noch nicht mein Projekt. Und somit auch nicht mein Geld.

Man muss aber auch dazu sagen, dass Hetzner in der Produktreihe auch ein größeres Produkt anbietet. Mit 15 (statt 7) Platten und einem 16 Port HW-Raid Controller (statt SW-RAID) für rund das doppelte Geld. Insgesamt also ein wesentlich besseres Preis/Leistungsverhältnis.
Wenn du eh mehrere Storage-Server betreibst, wäre das vielleicht die sinnvollere Alternative gewesen und stattdessen weniger Server hinzustellen.

Es ist nur ein Storage bei Hetzner. Der andere steht in einem anderen RZ für den Fall einer totalen Katastrophe. Der "große" Storage-Server von Hetzner wäre hier - bei aller Leistung - zu viel. Sowohl preislich als auch was den Speicher betrifft.

Wenn ich noch was für den Fall dass Du LVM benutzt einwerfen dürfte...
[..] meine Daten haben einen 192k-Offset, was bei 256k stripes eher blöd ist.
[..] Bei einen RAID mit Parität kann das, je nach Anwendungsfall, ganz schön weh tun.

Von dieser Sache habe ich auch gehört, allerdings unabhängig von LVM (kommt hier auch nicht zum Einsatz). Irgendwas mit dem Partition Alignment - aber auch hier bin ich etwas überfragt bzw. neu im Thema. Was muss hier beachtet werden?


Eine Sache noch, die meine Verwirrung perfekt macht:
Oben spreche ich von der Chunksize des RAID-Arrays und davon, dass man diese optimieren könnte. Habe dann den gestern verlinkten Wikipedia-Artikel noch mal gelesen:

In der Praxis wird dieser Worst-Case-Fall bei einem RAID 5 mit 5 Platten aber kaum eintreten, denn Dateisysteme haben häufig Blockgrößen von 2 kB, 4 kB und mehr und zeigen daher praktisch ausschließlich das Well-Case-Schreibverhalten.

Ich bin verwirrt, weil... Wenn das Dateisystem sämtliche Requests ans RAID ohnehin mit "seiner" Blockgröße durchreicht, wäre eine Optimierung der Chunksize auf das Anwendungsszenario* doch völlig nutzlos, oder?
Außerdem verwirrt mich, dass in dem Artikel von der physikalischen Blockgröße der Festplatte die Rede ist - von einer Chunksize des RAIDs und deren Einflüssen ist dort gar nicht die Rede. Also eigentlich versteh ich jetzt gar nichts mehr.

* Die Dateien der letzten zwölf Monate sind durchschnittlich 600 KB groß. Bei fünf Festplatten, auf die ich effektiv mit Nutzdaten schreiben kann, wäre meinem Verständnis nach eine Chunksize von 600/5 = 120 (bzw. 128) KB ideal.

Aber wie gesagt: Mir ist unklar, was es jetzt auch noch mit der Blockgröße des Dateisystems (also 4 KB in meinem Fall) auf sich hat. Und überhaupt verwirrt mich das alles. ^^


Noch was am Rande: Was meint parted mit "logical" und "physical"? Letzteres klingt nach der tatsächlichen Blockgröße auf der Platte, aber was soll dann "logical" (die 512 Bytes kann ich mir besser als 4 KB als tatsächliche Blockgröße vorstellen) sein?


Viele Grüße
Tim

 

[Thunderbyte]

Lass Dich doch von alledem nicht beeinflussen. Du kannst an den von Dir genannten Parametern gar nicht so viel herumschrauben, dass Du Zahlen in völlig anderer Größenordnung (und die willst Du ja offensichtlich haben) bekommst. Es ist - für Deinen Anwendungszweck - m.E. völlig egal, wie groß die Chunksize beim Raid ist.

Die Blockgrößen des Dateisystems wirken sich so aus (ein Block kann nur als ganzes belegt werden):

- kleine Blockgrößen
VORTEIL: bei kleinen Dateien wird wenig Platz verschwendet, wenn das "Ende" einer Datei den Block nicht ganz ausfüllt
NACHTEIL: das Volume fragmentiert leichter und wird dadurch langsamer

- größere Blockgrößen
VORTEIL: für größere Dateien besser, da weniger Aufwand für die Verwaltung, das Blockresteproblem fällt hier im Vergleich zur Gesamtgröße der Datei nicht so ins Gewicht

Linux gleicht mit den ext Dateisystemen das Fragmentierungsproblem etwas aus, hierzu siehe auch http://de.wikipedia.org/wiki/Fragmentierung_(Dateisystem) .

Nochmal: lebe mit den Werten, mach Raid10 (und verlier dabei einen noch deutlich größeren Anteil des Gesamtspeicherplatzes) oder überzeuge die Auftraggeber von einem Hardwarecontroller.

 

[s24!]

Lass Dich doch von alledem nicht beeinflussen. Du kannst an den von Dir genannten Parametern gar nicht so viel herumschrauben, dass Du Zahlen in völlig anderer Größenordnung (und die willst Du ja offensichtlich haben) bekommst.

Nein, will ich wirklich nicht. Mein Ziel ist lediglich, hier möglichst viel rauszuholen - die Maschine wird keiner Extremlast ausgesetzt sein, aber ich optimiere halt gerne und möchte lieber jetzt mögliche Flaschhälse beseitigen, als irgendwann ein Problem zu haben. Außerdem finde ich die ganze Thematik sehr interessant und konnte mich bisher mangels Notwendigkeit nie mit RAID-5 oder RAID-6 befassen.

Es ist - für Deinen Anwendungszweck - m.E. völlig egal, wie groß die Chunksize beim Raid ist.

Warum?

Die Blockgrößen des Dateisystems wirken sich so aus (ein Block kann nur als ganzes belegt werden): [..]

Danke, das hat für etwas Klarheit gesorgt, nachdem mich die Thematik als Ganzes total verwirrt hatte. Hier werde ich mich vermutlich für eine (dem Standard gegenüber) erhöhte Blockgröße von 16 KB entscheiden (es geht um einen Imagehoster; weiß nicht, ob das erwähnt wurde):

- Die Bilder an sich sind durchschnittlich 600 KB groß, aber eine solche Blockgröße wäre Platzverschwendung, denn...
- die Thumbnails (es gibt zwei Stück pro Bild) sind durchschnittlich 40-60 KB groß
- und die Miniaturen (eins pro Bild) sind durchschnittlich 14 KB groß.

Ich denke, dass schon eine Blockgröße von 32 KB Verschwendung wäre: Die Miniaturen sind de facto niemals größer als 16 KB, sie würden hier also schon doppelten Speicher belegen. Gleichzeitig habe ich so I/O-Verschwendung beim Abruf von Thumbnails, die irgendwas zwischen 32 und 40 KB groß sind (32 KB reichen nicht, 64 sind zu viel).


Folgender Artikel hat mir noch mal geholfen:
http://www.blazilla.de/index.php?/archives/311-Die-richtige-Chunksize.html

Normalerweise ist das zwar schön, wenn sich viele Platten um I/Os kümmern... aber nicht, wenn sich zwei Platten um einen I/O kümmern. Wenn es dann auch noch ein RAID 5 ist, dann sackt die ganze Performance zusammen.
[..] Große oder kleine Chunksize? [..] Wenn man viele kleine I/Os hat [..] sollte man eine große Chunksize wählen. Damit ist sichergestellt, dass sich nur genau eine Platte mit einem I/O beschäftigt und die anderen Platten können andere I/Os bearbeiten. Wenn man MB/s will, dann sollte man eine kleine Chunksize wählen.

Das ist insofern interessant, als das mein Ansatz demnach unsinnig war: Ich brauche keinen immensen Durchsatz, sondern in erster Linie tatsächlich viele IOPS. Und die erreiche ich mit meiner Chunksize von 512 KB wohl durchaus, da die meisten einzelnen I/O-Zugriffe da "reinpassen" und das RAID-Array somit möglichst viele solcher Zugriffe gleichzeitig bearbeiten bzw. auf viele Platten verteilen kann.

Was mir jetzt aber nicht klar ist: Verschwende ich mit der Chunksize keinen Speicher? Da versteh ich die Zusammenhänge noch nicht ganz. ^^

Auch ein beruhigender Ausschnitt aus dem verlinkten Artikel:

Welchen Zusammenhang gibt es denn nun zwischen der Blockgröße des Dateisystems und der Chunksize? [..] Es gibt keinen Zusammenhang und es ist auch total egal.

=)


Grüße
Tim

 

[Thunderbyte]

Die Chunksize gibt nur an, in welchen Häppchen das Raid Volume über die Platten verteilt ist. Platz verschwenden kann man nur mit der Blocksize. Und da würde ich für solch kleine Dateien sogar eine noch kleinere Blocksize nehmen. 4 kB wären m.E. gerade richtig.

 

[s24!]

Warum? Die meisten Dateien sind ja deutlich größer.

// Edit
Besser gesagt: Die kleinsten Dateien sind 14 KB groß - warum dann nicht auch was in dieser Größenordnung als Blocksize wählen?

 

[Thunderbyte]

Wenn eine (kleine) Datei 17 kB groß ist, verbraucht sie mit 16 kB Blocksize 32 kB, statt 20 kB mit 4kB Blocksize. Und hab davon mal ein paar tausend, dann läppert sich das sehr schnell zu einer riesigen Platzverschwendung zusammen.

Mit "bei größeren Dateien fällt eine größere Blocksize nicht so ins Gewicht" meinte ich eher Dateien > 10 Mb oder noch deutlich größer.

 

[s24!]

Das ist mir durchaus klar - aber die Miniaturen sind ja nur ein kleiner Teil. Thumbnails und die Bilder an sich sind deutlich größer. Und die Miniaturen sind fast alle unter 16 KB groß...

 

[Thunderbyte]

Die Menge an Dateien machts. Angenommen Du hast 1.000.000 Dateien, die bei 16kB Blocksize im Schnitt 8kB verschwenden, dann hast Du alleine durch Deine Blocksize Wahl schon 8 GB verschwendet.

 

[s24!]

Danke. Das ist aber wirklich egal. Dieser Server wird jeden Tag ca. 15 GB an Bildern dazubekommen. Da sind die 8 GB auf 1.000.000 Miniaturen echt nicht relevant. =)

 

[Thunderbyte]

Warum eigentlich nicht? 15 GB an Bildern dürfte bei einer durchschnittlichen Bildergröße von 5 Mbyte (bitte korrigiere mich) rund 3000 Dateien bedeuten. Mit 16 kB Blockgröße verschwendest Du also jeden Tag völlig unnötigerweise 24 Mbyte, denn einen Vorteil ziehst Du von 16 kB dann nicht.

Weißt Du was, warum einigen wir uns denn nicht auf 8kB Blockgröße, wenn sie unbedingt schon so groß sein muss.

 

[s24!]

Das durchschnittliche Bild ist 600 KB groß.

Edit: Bei den Miniaturen verschwende ich ja nur in "Ausnahmefällen" Speicher. Die durchschnittliche Miniatur ist wie gesagt 14 KB groß; bei den Blockgröße 4 (4*4), 8 (8*2) oder 16 (16*1) KB "verschwende" ich genau gleich viel im Normalfall. Allerdings spare ich mit den 16 KB Blockgröße Fragmentierung (ein wenig) und Requests ans Dateisystem.

 

[s24!]

Ich verzweifle:

root@h19 ~ # mkfs.ext4 -b 16384 /dev/md2 
Warning: blocksize 16384 not usable on most systems.
mke2fs 1.41.12 (17-May-2010)
mkfs.ext4: 16384-byte blocks too big for system (max 4096)
Proceed anyway? (y,n) y
Warning: 16384-byte blocks too big for system (max 4096), forced to continue

Das Ergebnis lässt sich natürlich nicht mounten.

Was hat er und wie kann ich ihn zwingen? ^^

Via Google habe ich spontan nur Leute gefunden, die zwar die Warnung, aber keinen tatsächlichen Fehler gekriegt haben.


Grüße
Tim

Edit: Ist natürlich ein 64-bit-System.

 

[Thunderbyte]

Warum sollte man eindringliche Warnungen ignorieren? Mach 4096 und gut ists.

 

[s24!]

Es geht ja um die Frage, warum das nicht geht.

Edit: Meine weitere Recherche besagt, dass diese Limitierung von den Eigenschaften der CPU ausgeht und somit nicht geändert werden kann. Kann das jemand bestätigen oder widerlegen? :/