raid profis hier?

raid profis hier? (67 Beiträge, 849 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

hey!

hab ein problem mit meinem raid 5. hab laut laut hdtune zwar im schnitt 350 mb/s leserate, jedoch sind die schreibewerte katastrophal.. bei längeren transfers zwischen 5 und 10 mb..

hab jetzt schon ewig lang gesucht, scheinbar haben mehrere leute probs. mit raid 5 schreibchache wurde aktiviert und bringt nur geringe besserung.. scheinbar ist der raid 5 sehr happig bei der zuordnung der sektorgrößen, stripegrößen und alignment ist und das ganze zusammenpassen muss..

ist mein erster raid und trotz stundenlanger recherche komm ich nicht weiter welche einstellung denn nun die richtige für mich wäre..

vl kann mir ja jemand weiterhelfen und mir noob-mäßig erklären wie ich was umzustellen hab, damit die performance endlich passt..

schätz dass ich nicht drum herumkomm den raid wieder zu zerlegen und neu aufzubauen.. da käme ne umstellung auf raid 10 auch in frage -> sinnvoll?

zur hardware:
bord: http://geizhals.at/522654
hdds: 4 x http://geizhals.at/506309

lg und danke schonmal für alle die mir helfen können

LC4 @ 9000 rpm - The Power to Surprise

lieber mit 55 PS wheelen als mit 200 km/h in den Tunnelblick schielen

Soweit ich weiß sind die Mainboard-RAID-Controller nur wenig mehr als Software-treiber. Ich würde mal bei den Treibern schauen. Vielleicht nicht die allerneueste, sondern eine Version zurückgehen?

Save the Earth... it's the only planet with chocolate.
Sind Sie dämlich oder tun Sie nur so?

okay werd ich mal probieren.. danke

LC4 @ 9000 rpm - The Power to Surprise

lieber mit 55 PS wheelen als mit 200 km/h in den Tunnelblick schielen

http://de.wikipedia.org/wiki/RAID#RAID_5:_Leistung_.2B_Parit.C3.A4t.2C_Block-Level_Striping_mit_verteilter_Parit.C3.A4tsinformation ist nicht schlecht für den Anfang zum einlesen. Raid 5 mit 4 Platten ist nicht super, entweder 3 oder 5. Wenn du 4 Platten hast, ist raid 10 das Beste. Ich weiss zwar nicht für was du das Raid brauchst, aber Raid 10 ist auf jeden Fall schmerzloser zu betreiben.

thx.. werd mich mal einlesen!

ah okay, hab immer nur gelesen raid 5 meistens zwischen 3 und 5 platten und dacht mir mit 4 bin ich gut unterwegs ^^

raid 10 ist eh meine exitstrategie im hinterkopf .. sollte ich dabei irgendetwas beachten beim einrichten?

wo siehst du die vorteile zum 5er wenn man fragen darf?

LC4 @ 9000 rpm - The Power to Surprise

lieber mit 55 PS wheelen als mit 200 km/h in den Tunnelblick schielen

Hatte auch, aber nur ganz kurz, ein RAID 5 mit 4 Platten in Betrieb (fix fertiges Kastl voll bestückt). Im Endeffekt sind durch die ungünstige Paritätsverteilung die Schreibwerte signifikant nach unten gegangen (rund um 50%) bei den 3TB von Western Digital.

3, 5 oder 9 ist eine ideale Anzahl für RAID 5, ansonsten muss man entweder mit den "Einbrüchen" leben oder zu anderen RAID-Formen greifen.

06.08.2012, 13:10 Uhr - Editiert von Paradoxon, alte Version: hier

Wenn man sich die Benchmarks anschaut, dann ist RAID10 ungefähr 2x so schnell wie eine Platte, bei Raid 5 kommst drauf an. Das ist aber nur so eine Gefühlssache, wenns dir Benchmark anschaust, kommt wie immer drauf an, ob random read/write oder sequenziell. Wenn du dir die Diskussionen anschaust im Netz, wirst Empfehlungen für Beides finden. RAID5 hat halt den Vorteil, das du nicht soviel Festplattenplatz verlierst wie bei RAID10. Beide vertragen 1 Platte Ausfall, RAID10 mit Glück 2 (wenns die richtigen Zwei sind).
Hab hier noch mal eine kleine Zusammenfassung gefunden: http://www.tomshardware.co.uk/forum/244377-14-raid-raid-raid wie das so ausschaut mit den einzelnen RAIDs.
Insgesamt kann man sagen der Trend geht eindeutig zu RAID10, weil Festplattenplatz nix mehr kostet und weils weniger komplex ist. Bei SSD raids hab ich bis jetzt nur RAID10 gesehn. Das Pendel schwingt jedoch in die andere Richtung wennst einen richtig guten Controller hast, dann kann RAID5 wieder Sinn machen.

Insgesamt kann man sagen der Trend geht eindeutig zu RAID10, weil
Festplattenplatz nix mehr kostet

Ich weiß nicht wo du einen "Trend" bei RAID Typen beobachten willst, aber das Klischee des "Festplattenplatzes, der nix mehr kostet" hat sich seit der Preisexplosion durch die Flutkatastrophe letzten Jahres erledigt. Zwar haben sich die Preise wieder ein bisschen beruhigt, sind aber noch lange nicht auf dem niedrigen Niveau von vorher. Da kann man ruhig bisschen nachrechnen:

Wenn eine 2 TB Festplatte ca. € 100,- kostet, kosten 4 TB nutzbarer Festplattenplatz
mit RAID 10 -> 4 x 100,- = € 400,-
mit RAID 5 -> 3 x 100,- = € 300,-

Wollen wir noch mehr Platz, wirds noch deutlicher. Sagen wir 8 TB, das wären
mit RAID 10 -> 8 x 100,- = € 800,-
mit RAID 5 -> 5 x 100,- = € 500,-
Für € 300,- Preisunterschied brauch ich schon nicht mehr auf Ebay schauen, um das Geld kriege ich langsam eine ladenneue 8-port Hardware-RAID Controllerkarte.

Natürlich für daheim, aber im Serverbereich sind 300 € nix für Platten im Vergleich wenn was schiefgeht und du dann anfängst, Arbeitszeit zu rechnen.

Sorry, kein zulässiges Argument, weil im Serverbereich fragens dich: "Bitte was willst machen? Software-RAID? Kennen wir nicht, was soll das sein?"

??? Wo hab ich was von Softwareraids geschrieben???

M.M.n. impliziert RAID 0/1/01/10 dass von Software-RAID die Rede ist, weil wenn ich einen echten Hardware RAID Controller habe, warum soll ich mich dann mit RAID 0/1/01/10 abgeben?

abenteuerliche theorie...
#--
Hail Freedonia.

Wir fahren auf unsere Server hauptsächlich RAID 1(+0).
Im Storagebereich variiert es.

Gerade RAID 0 mit 3 oder mehr Platten sind für wirklich Durchsatz mit Contoller, und RAID5 oder höher sind nicht für alle Fälle der Weisheit letzter Schluss.

Klar. E stellt sich für jeden die Frage, was er will/braucht: höchsten Datendurchsatz (mit ein bisserl Reiz des Risikos

) oder Verfügbarkeit der Daten.

etzt mal ganz abgesehen vom notwendigen Backup.

Und noch etwas: Nicht jeder Controller bringt mit jeder Plattenzahl gleiche/bessere Performance. Untere Preisklassen sind bald mal mit dem Overhead überfordert und brechen dann auch mal ein. Fast alle Controller kommen aber mit 3-4 HDDs gutb zurecht, wenn auch der Datendurchsatz nicht linear steigt.

Euer CWsoft
Unser zweites Buch ist fertig: http://weinzettl.info/content/page/canyons.html
Galerien auf http://weinzettl.info
Foto-Workshops auf http://warp2search.at

07.08.2012, 15:18 Uhr - Editiert von CWsoft, alte Version: hier

Geb dir völlig Recht.

Untere Preisklassen sind bald mal mit dem Overhead überfordert und brechen
dann auch mal ein.

Das sind ja meistens die selben Chips drauf wie auf den Mainboards.

Die allermeisten Mainboards haben keine eigene XOR-Login in ihrem aufgeloeteten "RAID-Controller". Das ist (zumindest bei allen Consumer-Boards) ein handelsueblicher SATA-Controller; alles andere uebernimmt die Host-CPU.

Und keinen Hauptspeicher und/oder Cache, was auch noch einiges bringt.

Ich wundere mich auch nicht.

Euer CWsoft
Unser zweites Buch ist fertig: http://weinzettl.info/content/page/canyons.html
Galerien auf http://weinzettl.info
Foto-Workshops auf http://warp2search.at

Ich sehe keinen technischen Grund fuer irgendeine Art Bottleneck im RAID5-Betrieb. Die Komplexitaet von XOR steigt linear mit dem Umfang der Eingabedaten, und jede Pimperl-CPU, die man heute entweder in einem Controller oder einem Standalone-Embedded-System findet, hat was das angeht genuegend Rechenleistung, um auch wirklich schon unvernuenftig viele Spindeln in einem RAID5 mit maximalem Durchsatz zu befeuern.

Nur so als Beispiel:

root@tpx200:~ # modprobe raid5
root@tpx200:~ # dmesg
[172422.751539] async_tx: api initialized (async)
[172422.753430] xor: automatically using best checksumming function:
[172422.792017]    generic_sse:  2970.000 MB/sec
(Thinkpad X200; Core 2 Duo @ 2.26GHz)

root@vault[ssh]:~ # modprobe raid5
root@vault[ssh]:~ # dmesg
[7530514.461729] async_tx: api initialized (async)
[7530514.474026] xor: measuring software checksum speed
[7530514.525662]    arm4regs  :  1084.800 MB/sec
[7530514.575659]    8regs     :   804.400 MB/sec
[7530514.625660]    32regs    :   900.800 MB/sec
[7530514.630032] xor: using function: arm4regs (1084.800 MB/sec)
(Sheevaplug Reference Board; Feroceon @ 1.2GHz)

Es ist quasi unmoeglich, irgendeine Art von zu XOR befaehigtem IC innerhalb eines RAID-Controller ernsthaft ins Schwitzen zu bringen. Mit RAID6 oder anderen n-Parity-Schemata sieht es etwas anders aus, aber auch das kann man mit der richtigen Wahl der Embedded-CPU fuer die Controllerlogik sehr einfach in den Griff kriegen.

Untere Preisklassen sind bald mal mit dem Overhead überfordert

Wieso sollte der Overhead steigen, wenn die Anzahl der Platten zunimmt???

*PUSH*

08.08.2012, 16:36 Uhr - Editiert von kombipaket, alte Version: hier

Wieso sollte der Overhead steigen, wenn die Anzahl der Platten zunimmt???

Er steigt, weil die Platte sozusagen gleichzeitig bedient werden müssen bzw. der Controller mehr Platten zu Verteilung der Daten verwalten muss.

Das ist jetzt keine Vermutung, das sind Fakten, solange bis jemand die Physik neu erfindet.

Euer CWsoft
Unser zweites Buch ist fertig: http://weinzettl.info/content/page/canyons.html
Galerien auf http://weinzettl.info
Foto-Workshops auf http://warp2search.at

bzw. der Controller mehr Platten zu Verteilung der Daten verwalten muss.

Sorry, aber der Controller hat da ziemlich 0 Hacke.

Beim Ermitteln der Platte Rechner er ja zB bei 3 Platten [Parity mal aussen vor]:

Zu beschreibende Platte := (BlockNr_aus_Sicht_FS / Anzahl_der_Blöcke_pro_Chunk) % Plattenanzahl.
Zu beschreibender Block der Platte := (BlockNr_aus_Sicht_FS / Plattenanzahl )

Die Anzahl der Platten bedeutet keine Mehrlast - Es gilt O(1).

Er steigt, weil die Platte sozusagen gleichzeitig bedient werden müssen

Im allerschlimmsten Fall wäre jeder I/O synchron. Irgendwann hätte der Controller seinen maximalen Durchsatz erreicht - dann würde die TransferPerformance am Maximum gleichbleiben. Die Gesamtperformance muss aber weiter steigen, weil mehr Platten = durchschnittlich weniger Seektime.

Diese Aussage ist Unsinn. Irgendjemanden mit md (dem Software-RAID des Linux-Kernels) wirst du in jedem Rechenzentrum finden. GH ist da keine Ausnahme. Solaris-User z. B. wirst du auch schwer von ihrem RAID-Z/RAID-Z2 (konzeptuell nah mit Software-RAID5 bzw. -RAID6 verwandt) trennen koennen - die haben ihre auf der Host-CPU realisierten ZFS-Features mittlerweile auch sehr liebgewonnen.

Ich hab keine Ahnung von Linux, in sofern kannst mir jedes Märchen erzählen, dass LinuxRAID5 zehnmal schneller wäre als jedes HardwareRAID5 und nebenbei Krebs heilt und das Ozonloch stopft ... dass ichs dir nicht glaub ist wieder ein anderes Thema.

ah okay, hab immer nur gelesen raid 5 meistens zwischen 3 und 5 platten und
dacht mir mit 4 bin ich gut unterwegs ^^

Bist ohnehin. Denn die vierte Platte sollte als Hot Spare (http://de.wikipedia.org/wiki/Hot-Spare ) mitlaufen, damit es bei einem Plattenausfall keinen Daten-Ausfall kommt.

Bedenke: Wenn deine Platten aud einer gleichen oder ähnlichen Charge kommen, geht nach der ersten Platte oft auch eine zweite ein.

Und du brauchst Zeit zum Rebuild - viel Zeit, in der keine weitere Platte mehr "Auf Wiedersehen!" sagen darf.

Ein Hot Spare springt, auch wenn du den Plattenausfall nicht gleich bemerkst, sofort ein und beginnt bereits mit dem Rebuild. Die kritische Zeit wird so verkürzt. Du läuftst derweil ganz schnell zum nächsten Händler und besorgst dir eine neue Platte, die dann wieder als Hot Spare dienen kann. Wenn deine defekte Platte vom Service kommt, hältst du sie in Reserve; wenn wieder eine Platte eingeht, hast du gleich eine neue Hot Spare HDD.

Euer CWsoft
Unser zweites Buch ist fertig: http://weinzettl.info/content/page/canyons.html
Galerien auf http://weinzettl.info
Foto-Workshops auf http://warp2search.at

Ein Rebuild dauert bei heutigen Plattenkapazitaeten und -geschwindigkeiten allenfalls ein paar Stunden (wenn viel auf das Array geschrieben wird, waehrend es degraded ist, evtl. auch empfindlich laenger). Wenn du dir berechtigterweise Sorgen machst, dass innerhalb dieser Zeit eine zweite Platte aus deinem Array - aus welchen Gruenden auch immer - eingeht, und du deswegen eine Hot-Spare-Platte anstatt eines manuellen Tauschs als zwingend erachtest, machst du eindeutig etwas falsch (vermutlich beim Einkauf der Platten, ganz sicher aber (auch) bei der Wahl des RAID-Levels).

"Plattenausfall nicht gleich bemerken" kann ich eigentlich gar nicht wirklich ernstnehmen: Ohne entsprechendes Monitoring kann man all diese feinen RAID-Luftschlossideen gleich wieder abschreiben. Mit einem RAID will man Datenverfuegbarkeit garantieren bzw. diese verbessern. Das hat ohnehin nur in einem Umfeld etwas verloren, wo das ein wichtiger Faktor ist. Und wenn man da nicht die Zeit hat, eine Platte innerhalb von ein paar Stunden zu tauschen, ist irgendwas im Argen - oder aber die Praemisse einfach die falsche, und man braucht in Wahrheit gar kein RAID.

Mein Rat fuer privat: Einfach oefters mal ein Backup ziehen.

Wenn man davon ausgeht, dass man sich ein RAID für ein Backup aufbaut.
Allerdings ist hier schon der Grundgedanke falsch, denn ein RAID ist kein Backup.
Backupstrategien muss man trotzdem erarbeiten.

In der vernetzten Welt, möchte man von jeden Gerät aus auf seine Daten zugreifen.
Und Daten sollen nicht gleich weg sein, wenn ne Platte das zeitliche segnet.
Ich denke, dass man per se RAID für zuhause nicht ausschließen kann.

Ein Rebuild dauert bei heutigen Plattenkapazitaeten und -geschwindigkeiten
allenfalls ein paar Stunden (wenn viel auf das Array geschrieben wird,
waehrend es degraded ist, evtl. auch empfindlich laenger). Wenn du dir
berechtigterweise Sorgen machst, dass innerhalb dieser Zeit eine zweite Platte
aus deinem Array - aus welchen Gruenden auch immer - eingeht, und du deswegen
eine Hot-Spare-Platte anstatt eines manuellen Tauschs als zwingend erachtest,
machst du eindeutig etwas falsch (vermutlich beim Einkauf der Platten, ganz
sicher aber (auch) bei der Wahl des RAID-Levels).

Danke für die Belehrung!

Ich muss dir allerdings sagen, dass ich doch ein paar Jahrzehnte Erfahrung mit RAID Controllern und Laufwerken im professionellen Einsatzbereich vorweisen kann. So nebenbei habe ich seinerzeit auch die ersten Arecas für Eure Server geliefert.

Und ich habe das Chargensterben schon einige Male bei verschiedenen Kunden erlebt. Und auch, dass bei einigen Kunden (abseitiger Serverraum und Wochenende) das Entdecken des Schadens*) erst sehr spät erfolgte.

Nachdem du aber heute schon zu wissen scheinst, dass ein Kunde in solchen Fällen bereits beim Einkauf hätte wissen müssen, dass er die falschen Laufwerke kauft, erbitte ich von dir die richtigen Lottozahlen der KW52 für 2012. Denn es ist ALLEN relevanten Herstellern von Serverplatten schon gelungen, (Material/Konstruktion-)Fehler "einzubauen", die sich erst nach einem Jahr oder später ausgewirkt haben.

Die Hersteller wussten bis zu den erste Meldungen nichts von den Fehlern - du schon?

Ich habe daraus gelernt und verwende in kritischen Umgebungen, in denen RAID-RAID-Arrays nicht machbar sind oder sich aus wirtschaftlichen Gründen verbieten, manchmal Platten verschiedener Hersteller (nähere Ausführungen erspar ich mir), denn solche Fehler sind auch in Zukunft nicht auszuschließen.

*) Und was das Monitoring betrifft: Ich mache das für mich, meine Kunden machen das für sich - oder eben auch nicht. Auch in Riesenfirmen kommt es manchmal dazu, dass Menschen schlampfen - und so selten ist das nicht. Sollen auch in großen Firmen (da reden wir dann schon auch von ganz großen Global Players, nicht nur von für östrereichische Verhältnisse großen Unternehmen) bereits notwendige Backups gefehlt haben, warum sollen das Überwachungsfehler nicht passieren können? Bist du fehlerfrei?

Euer CWsoft
Unser zweites Buch ist fertig: http://weinzettl.info/content/page/canyons.html
Galerien auf http://weinzettl.info
Foto-Workshops auf http://warp2search.at

Klassisches Strohmann-Argument: ich habe mit keinem Wort die Entscheidung oder Empfehlung angekreidet, bei den Platten fuer das Array eine gewisse Streuung ueber Chargen oder auch Hersteller absichtlich herbeizufuehren. Das aendert nichts daran, dass die Hotspare-Idee ein Bloedsinn ist - dann nehme ich halt gleich RAID6, hab damit unter'm Strich bessere Verfuegbarkeit und sogar noch brauchbare Schreibperformance, wenn eine der Platten des Arrays ausgefallen ist.

Zu deiner "Beruhigung: Ich persönlich empfehle auch RAID 6, allerdings auch hier mit einem Hot Spare. Und ich persönlich verwende in meiner Workstation auch nur RAID 6 - tja, eben auch mit einem Hot Spare.

Paranoia kannst du nicht wegargumentieren. Ich habe schon zu viel erlebt in den letzten dreißig Jahren.

Euer CWsoft
Unser zweites Buch ist fertig: http://weinzettl.info/content/page/canyons.html
Galerien auf http://weinzettl.info
Foto-Workshops auf http://warp2search.at

08.08.2012, 17:15 Uhr - Editiert von CWsoft, alte Version: hier

Raid6 mit Hot Spare... Wieviele Platten? Wäre da nicht Raid55 schon besser? Insbesondere wenn Du so paranoid bist?

Raid6 mit Hot Spare... Wieviele Platten?

5.

Euer CWsoft
Unser zweites Buch ist fertig: http://weinzettl.info/content/page/canyons.html
Galerien auf http://weinzettl.info
Foto-Workshops auf http://warp2search.at

Und ich persönlich verwende in meiner Workstation auch nur RAID 6 - tja, eben
auch mit einem Hot Spare.

sitzt du da mit gehörschutz vor der kiste?

Überhaupt nicht. Wir haben früher extrem leise Server geliefert. Alles habe ich zwischenzeitlich nicht verlernt.

Euer CWsoft
Unser zweites Buch ist fertig: http://weinzettl.info/content/page/canyons.html
Galerien auf http://weinzettl.info
Foto-Workshops auf http://warp2search.at

"Plattenausfall nicht gleich bemerken" kann ich eigentlich gar nicht wirklich
ernstnehmen: Ohne entsprechendes Monitoring kann man all diese feinen
RAID-Luftschlossideen gleich wieder abschreiben.

Das hilft dir bei so Platten mit Serienfehlern recht wenig. Ich habe erst vor ca. 1,5 Jahren ein RAID-5 vom Backup rekonstruiren dürfen, weil in einer Nacht Zwei Platten am selben Serienfehler verstorben sind. Habe dann recherchiert, dass der Hersteller eh gewarnt hat, und ein BIOS-Update zur Verfügung gestellt hat... .
--
Der einzige Weg, wahre Liebe für Geld zu kaufen, ist, sich einen Hund anzuschaffen.

Ich schwörs dir Ernst: Ich hab dein posting vorher noch nicht gelesen!

https://forum.geizhals.at/t801376,6865162.html#6865162

Und ich schwöre, ich habe auch dein Posting erst jetzt gelesen - und trotzdem auch in anderer Hinsicht gerade zuvor in dieselbe Kerbe geschlagen.

Nett, wieder was von dir zu hören/zu lesen!

Euer CWsoft
Unser zweites Buch ist fertig: http://weinzettl.info/content/page/canyons.html
Galerien auf http://weinzettl.info
Foto-Workshops auf http://warp2search.at

Prinzipiell steigt die theoretisch zu erwartende (sequenzielle) Schreibleistung eines RAID5-Arrays mit jeder zusaetzlichen Komponente. Vier Platten sind ganz sicher nicht schlechter oder prinzipbedingt langsamer als drei oder fuenf. Natuerlich hat man - gerade bei RAID5 - immer noch genuegend Moeglichkeiten, sich den Durchsatz durch ungeschickte Wahl gewisser Parameter (Chunksize vor allem) zu verderben. Kurz zusammengefasst: ein RAID (vor allem Parity-RAID) kann man nur auf bestmoegliche Performance unter einer gewissen, zu erwartenden und definierten Workload optimieren. "One size fits all" gibt es nicht.

so in etwa hab ichs mir schon gedacht.. meine frage nun, könnt ihr mir (als anfänger) dabei helfen das optimum aus dem bestehenden raid herauszuholen, oder soll ich gleich auf raid 10 setzen?

ich weiss.. hier um hilfe betteln wenn man die basics eigentlich nicht versteht wird nicht gerne gesehen, aber ich muss das sys heute abend fertigstellen.. und dass ich mich bis dahin zu nem raid pro einlese den gedanken hab ich bereits aufgeben

LC4 @ 9000 rpm - The Power to Surprise

lieber mit 55 PS wheelen als mit 200 km/h in den Tunnelblick schielen

MEINE Meinung (die von anderen hier abweicht):

1.) RAID5 ist IMHO der beste Kompromiss Thema Sicherheit, Performance und Preis.
2.) Je mehr Platten, desto effizienter ist dein RAID5 - weil die Platten dann mehr und mehr Chancen bekommen, unabhängig voneinander Requests zu beantworten. Aus Performancesicht sind da mehrere kleinere Platten (obwohl einzeln langsamer) durchaus wenigen großen Platten vorzuziehen.
3.) Chunk-Size: Wähle sie so, dass ein Durchschnittlicher I/O nur eine Platte beschäftigt.
4.) Persönlich bevorzuge ich Software-Raid - wobei das eine religiöse Debatte ist

.
5.) Wenn Du eine höher performante Lösung als RAID5 willst - würde ich mir RAID50 ansehen... Immer noch günstiger als RAID10 - braucht aber mindestens 6 Platten.

ah okay, hab immer nur gelesen raid 5 meistens zwischen 3 und 5 platten und
dacht mir mit 4 bin ich gut unterwegs ^^

hi!
nun, schlecht ist es nicht - sofern die vierte lediglich als hot-standby-platte drinnen ist. so kann dein raid gleich auf die reserveplatte ausweichen und muss nicht ev. wertvolle zeit verstreichen lassen, bist du 1. die platte hast und 2. vorort bist und zeit hast diese auszutauschen

bei raid5 - wie zu vermutlich schon bemerkt hast, dauert das einrichten "etwas" länger - das kann schon mal den unterschied zwischen totalausfall oder "es ist eigentlich nix gewesen" machen.
ich habe gerne 3-4 unterschiedliche platten mit gleicher leistung im system - denn die ausfallwahrscheinlichkeit mehrerer platten ist so geringer, als wenn du 3,4 oder 5 platte hast die genau aus derselben charge kommen und du ev. 1-2 tage nicht da bist was auch immer, und dann nochmal 1-2 tage fürs raid aufbauen draufgehen...

. Raid 5 mit 4 Platten ist nicht super, entweder 3 oder 5.

Das halte ich für ein Gschichtl...

Die Argumentation ist im Wiki-Artikel ja wie folgt:
Angenommen, ich habe eine Chunk-Size von 512 Bytes und will 2K schreiben.
Dann brauche ich bei 4 Platten eben einen Schreibzugriff auf alle 4 (3Daten+1 Parity) - und einen Lese/Schreibzugriff auf eine der 4 Platten (Parity+Daten Lesen + Schreiben).

Was hier völlig vergessen wird ist, dass [fast] niemand eine Chunk-Size = Sektor-Size nimmt - sie hat ja fast nur Nachteile. Idealerweise entspricht die Chunk-Size einem durchschnittlichen IO.

Beispiel wieder RAID5 mit 4 Platten, Chunksize sei 256 KB, Gespeichert wird ein Word-Doc mit 200KB.

2 von den 4 Platten sind dann beschäftigt (Lesen+Schreiben). Die anderen 2 Platten sind _unbenutzt_ zu diesem Zeitpunkt - und können bequem parallel beispielsweise zum Lesen verwendet werden. Wenn parallel ein dritter Datenblock aus diesem Stripe verändert wurde - kann i.d.R. die Parity gleich mit berechnet werden (weil vom Block Layer ja i.d.R. verzögert auf Platte geschrieben wird). Wenn nicht - ist sie immerhin im Cache und kann auch ohne weiteren IO in die Parity-Berechnung einfließen.

Wenn die Chunk-Size gleich der Sektor-Size ist, kann man sich die Schreib/Leseköpfe der Spindeln starr verbunden vorstellen - weil die Masse der Dateien größer 512 Bytes ist. Das ist genau das, was Du nicht willst - um mehr I/O zu deinem Plattensubsystem zu ermöglichen.

Raid 5 Berechnung für optimale Plattenzahl: 2^n+1, das kommt daher weil du Binär alles mit 2^ irgendwas ist, also kannst du deinen Chunk immer optimal aufteilen, auf 2,4,8 (6 lass ich mal aus, da hast dann trotzdem Überhang wie bei 3) Platten, respektive sollte dein Chunk=Sektor X 2,4,8 Platten sein, die +1 Platte speichert dann den Parity. Natürlich hast Recht mit Chunk=/=Sektor, mit meiner Formel kannst dann nochmal 2^irgendwas draufmulitiplizieren, um den optimalen Chunk für deine typischen Transfergrößen zu bekommen. Wenn meine Rechnung stimmt, musst du bei 3+1 Platten Sektorgrößex12=Chunk nehmen, um nicht einen Überhang zu bekommen (sind dann bei 1 Chunk 4 Schreibvorgänge auf jeder Platte).
Ob das mit den nicht beschäftigten Platten so funktioniert, wie du es schreibst (was ich glaube dass es solche Strategien gibt), hast noch immer das Problem, dass durch die unterschiedliche Schreib/Lesezeiten du bei mehreren aufeinanderfolgenden Zyklen Totzeiten reinbringen wirst, wo Platten nix machen werden.
Wo ich mir nicht sicher bin, ob nicht immer alle Platten schreiben bzw. lesen an einem Chunk, ist ja die kleinste ansprechbare Einheit im Raid, ich meine damit das wenn du eine kleinere Datenmenge als einen Chunk schreibst, muss ja zuerst den Chunk, wohinein du es schreiben willst, einlesen, modifizieren, und dann wieder schreiben und zwar auf allen Platten mit Daten + das Parity dann.
https://raid.wiki.kernel.org/index.php/RAID_setup#RAID-5 erklärt ja, dass du um die Parity zu berechen alle TeilChunks brauchst auch die die du nicht modifizierst. Du ersparst dir dann das erneute Schreiben der unmodifierten TeilChunks (wenn der Controller das so macht was ich glaube).
Das selbe Problem haben ja auch SSDs (in Bezug auf kleine Schreiboperationen).
Und mit Cache kannst einiges kompensieren, aber nur wennst einen Controller hast, der das auch macht^^.

, also kannst du deinen Chunk immer optimal aufteilen,

Ein Chunk ist hier die Speichermenge, die auf eine Platte kommt.
Sinngemäß:
Byte 0 bis chunksize-1: Platte 1
Byte Chunksize bis 2*chunksize-1: Platte 2
...
Der Chunk wird also nicht "aufgeteilt".

Wenn meine Rechnung stimmt, musst du bei 3+1 Platten Sektorgrößex12=Chunk
nehmen, um nicht einen Überhang zu bekommen (sind dann bei 1 Chunk 4
Schreibvorgänge auf jeder Platte).

Ohne es mir genau zu überlegen: Die Idee ist ja, dass Du _nie_ einen Überhang generierst... Und immer möglichst wenig Platten beschäftigst, weil die SEEK-TIME Dir ja weh tut... Dein Vorschlag "Sektorgröße x 12=Chunk" - würde je nachdem 6KB oder 48KB bedeuten. Da ich nie ein RAID für "normale Usage" unter 128KB anlege (meist 256KB) würde ich deine Bedingung jedenfalls erfüllen

hast noch immer das Problem, dass durch die unterschiedliche
Schreib/Lesezeiten du bei mehreren aufeinanderfolgenden Zyklen Totzeiten
reinbringen wirst, wo Platten nix machen werden.

Hier kann ich Dir nicht folgen. Wenn Platten nichts tun - sind sie nicht der Engpaß

Wo ich mir nicht sicher bin, ob nicht immer alle Platten schreiben bzw. lesen an einem Chunk, ist ja die kleinste ansprechbare Einheit im Raid, i

Begriffsverwirrung (s.o.): Ein Chunk ist auf einer Platte, nicht die "horizontale" über alle Platten.

ich meine damit das wenn du eine kleinere Datenmenge als einen Chunk schreibst, muss ja zuerst den Chunk, wohinein du es schreiben willst, einlesen, modifizieren, und dann wieder schreiben und zwar auf allen Platten mit Daten + das Parity dann.

Ich glaube, Du hast da was falsch verstanden. Einmal schreiben bedeutet im schlimmsten Fall:
- Je einen Block von 2 Platten einlesen
- Genau an diesen Block (kurzes Seek) auf denselben Platten schreiben.
Keinesfalls musst alle Platten angreifen.

erklärt ja, dass du um die Parity zu berechen alle TeilChunks brauchst auch
die die du nicht modifizierst.

Genau das steht nicht da. Lies es nochmals. Es gibt 2 Wege. Nur einer der beiden braucht alle Teilchunks. Es wird aber immer der schnellere genommen.

Hier kann ich Dir nicht folgen. Wenn Platten nichts tun - sind sie nicht der
Engpaß

Doch, anders herum, sie sollten ja was machen, müssen aber auf die anderen Platten warten, bis sie fertig sind. Readahead funktioniert ja nur bis zu einer Gewissen Queuesize und Nebenläufigkeit
.

Begriffsverwirrung (s.o.): Ein Chunk ist auf einer Platte, nicht die
"horizontale" über alle Platten.

Chunk und Stripe sind nicht das Selbe, war ich nicht genau genug^^.

Genau das steht nicht da. Lies es nochmals. Es gibt 2 Wege. Nur einer der
beiden braucht alle Teilchunks. Es wird aber immer der schnellere genommen.

Zitat:If the writes are small and scattered all over the array, the RAID layer will almost always need to read in all the untouched chunks from each stripe that is written to, in order to calculate the parity chunk. Aber du hast Recht, wenn du die Parity aus dem Unterschied von alten Daten, neuen Daten und alter Parity berechnest, kann aber anscheinend nicht jeder Controller so. Bei 4+1 Platten kannst wennst nur einen Chunk schreibst, mit 2 Les und 2 Schreib den Stripe aktualisieren anstatt 3 Les und 2 Schreib (es sind ja n-2 Lesezugriffe, weil du Parity und alten Chunk,denn du ja schreiben willst, nicht lesen musst, davon ausgehen, dass du vorher ja die Daten die du schreiben willst, gelesen hast und modifierst hast in irgendeiner Form) sonst bist bei 4 Lesezugriffe wenn du keinen Cache hast oder wie oben du ständig random kleines Zeug machst, dass du den alten Chunk auch noch mitlesen musst. Der Unterschied wird natürlich mit der Anzahl an Platten größer. Bin mir jedoch nicht ganz sicher, warum die schreiben, dass sie trotzdem dann immer alle einlesen müssen und nicht die andere kürzere Methode nehmen.

Dein Vorschlag "Sektorgröße x 12=Chunk" - würde je nachdem 6KB oder 48KB
bedeuten. Da ich nie ein RAID für "normale Usage" unter 128KB anlege (meist
256KB) würde ich deine Bedingung jedenfalls erfüllen

Genau da liegt das Problem, 6Kb und 48 Kb gibts ja nicht es sind immer 2^n Blockgröße, dass heisst deine Chunkgröße ist nicht gleichverteilt auf die Platten, geht ja gar nicht. Wenn du Chunksize 128Kb anlegst, musst du sie durch 3 teilen, 42 kB, was nicht wirklich gut ansprechbar auf der Festplatte ist (82 Blöcke, 64 Blöcke optimal)
Zitat: A study showed that with 4 drives (even-number-of-drives might make a difference) that large chunk sizes of 512-2048 kB gave superior results.
2048kB/3=674kB dass durch die Blocksize der Platte ergibt 1317 (1024 optimal) Blöcke pro Chunk
512kB/3=170kB 333 Blöcke (256 optimal)
Aus dem wikiartikel: Unterschiedlich verhält sich hingegen z. B. 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.

Doch, anders herum, sie sollten ja was machen, müssen aber auf die anderen
Platten warten, bis sie fertig sind. Readahead funktioniert ja nur bis zu
einer Gewissen Queuesize und Nebenläufigkeit

Hmm.. Da passt was nicht. Du meinst, dass auf Platte 1 geschrieben werden soll, dies aber nicht klappt, weil Platte 2 noch beschäftigt ist? Das ist kein Problem. Natürlich kann auf Platte 1 geschrieben - und auf Platte 2 hinterher. Im schlimmsten Fall fliegt der Strom während auf Platte 1 geschrieben wird - dann ist das Raid beim Hochfahren Dirty und kann reconstructed werden.

Wenn du Chunksize 128Kb anlegst, musst du sie durch 3 teilen, 42 kB,

Denkfehler. Wenn meine Chunksize 128Kb ist, werden 128Kb auf die erste Platte geschrieben, 128kB auf die nächste, ... Wenn ich also 4 Platten habe - werden 384kbB Daten +128Kb Parity geschrieben, um die 4 Platten voll zu beschäftigen.

Dadurch, dass die Chunksize pro Disk - und nicht pro Stripe - greift, hast so auch implizit deine 2er-Potenzen-Forderung erfüllt (die ja _so_ auch Sinn macht).

Das Wiki-Beispiel ist übrigens _voller_ Schrott, Imho "Theoriefindung" - und drum auch ohne Quellen. Dass das Beispiel voller Schrott ist erkennst schon daran, dass dem Autor der Unterschied zwischen Sektor Size, Chunk Size und Filestem Block Size nicht bekannt ist.

08.08.2012, 16:38 Uhr - Editiert von kombipaket, alte Version: hier

Denkfehler. Wenn meine Chunksize 128Kb ist, werden 128Kb auf die erste Platte
geschrieben, 128kB auf die nächste, ... Wenn ich also 4 Platten habe - werden
384kbB Daten +128Kb Parity geschrieben, um die 4 Platten voll zu beschäftigen.

Arg, natürlich. Jetzt ist nur mehr dir Frage, ob sich die 384kB gut verwalten lassen.

Du meinst, dass auf Platte 1 geschrieben werden soll, dies aber nicht klappt,
weil Platte 2 noch beschäftigt ist? Das ist kein Problem. Natürlich kann auf
Platte 1 geschrieben - und auf Platte 2 hinterher.

Sagen wir, wir haben jetzt unsere 4 Platten, die haben doppelt so schnelle Lese wie Schreibgeschwindigkeit. Du willst 4 Chunks schreiben, 2 auf der 1. Platte, 1 jeweils auf den anderen, auf der einen nix. Du brauchst 2 Les und 2 Schreib pro Chunk.

              2 Chunk  1 Chunk             1 Chunk
1Platte:  2 L 2 S     1L 1 S(parity)
2Platte:                  1L 1 S                1 L 1 S (Parity)
3Platte:                                            1 L 1 S
4Platte: 2 L 2 S (parity)

Also haben alle 2 L und 2 S ausser die erste, die kann ihren Rückstand erst aufholen, wenns die Platte 2 und 3 beschäftigst. Wenn nicht geräts weiter ins hintertreffen, vor allem wenns blöd läuft, und du auf einmal 2 oder 3 Chunks (alle Festplatten machen was) schreiben willst, kannst den Rückstand nicht mehr aufholen. Es muss einfach irgendwann gewartet werden, du kannst ja nur eine gewissen Anzahl an Schreiboperationen aufschieben.
Darum machts ja fürs Lesen alleine keinen Unterschied.
Bei 4+1 Platten hast das Problem ja nicht in dem Ausmaß.
Aus der Sicht von Platte 1 hat sie ja nur eine 25% Change, das der Chunk, der geschrieben wird, sie den Paritychunk machen muss und eine 20% Change, dass der nächste Chunk ihrer ist, bei 3+1 hat sie eine Change von 33% Parity und 25% Change nextChunk, 2+1 sinds 50% Parity und 33% nextChunk.

Arg, natürlich. Jetzt ist nur mehr dir Frage, ob sich die 384kB gut verwalten
lassen.

Was meinst Du mit "Gut verwalten lassen" ??? Alles, was Du brauchst ist dementsprechendes Ram... bei 128KB Chunksize und 4 Platten halt mindestens 1/2 MB

. Mehr Ram bringt jedenfalls auch für die XOR-Berechnungsbuffer viel (nonanet).

Sorry, aus deiner Tabelle wurde ich übrigens nicht ganz schlau.
Natürlich kann es sein, dass temporär eine Platte zum Hotspot wird - und sich die I/O-Requests schon stauen (falls Du das gemeint hast). Das ist ausser Streit.

Mein Punkt ist nun, dass die I/Os sich umsobesser auf die Spindeln verteilen, je mehr Spindeln Du hast - völlig unbenommen, ob das eine gerade oder ungerade Anzahl an Platten ist. 4 Platten sind in einem RAID-5 auf jeden Fall besser als 3 Platten (bei sonst identen Bedingungen). Ideal wären aus der Sicht ein paar Bazillionen Platten pro Raid5. Blöd nur, dass dann die Ausfallwahrscheinlichkeit auf zumindest einige Fantastillionen ansteigt.

aber Raid 10 ist auf jeden Fall schmerzloser zu betreiben.

Nur was bitte soll daran für einen Heimanwender interessant sein wenn er 50% Kapazität nicht nutzen kann.

Sein Problem ist der Onboard "Controller" der Müll ist.

Mord, Erpressung & Raub since 800 b.C
f.u
...und klicken sie

wenn sie ein Honk sind!

09.08.2012, 01:51 Uhr - Editiert von john-cord, alte Version: hier

da du keinen reinen RAID-Controller vewendest tipp ich mal jetzt drauf dass das problem vom raid-treiber kommt - welche treiber hast du aktuell installiert?

Vom grundgedanken eines RAID 5 ist halt eine Konfig mit 4 Platten auch nicht wirklich die beste - da würdest mit 3 platten definitiv besser fahren wenn du das raid5 erhalten wirst!

ansonsten neu setup und auf raid 10 gehen wenn du die 4 platten behalten willst!
____________________________________________________________________

Only the Dead have seen the end of the War

(Plato)

Vom grundgedanken eines RAID 5 ist halt eine Konfig mit 4 Platten auch nicht
wirklich die beste - da würdest mit 3 platten definitiv besser fahren wenn du
das raid5 erhalten wirst!

Wie kommst Du bitte auf das? Ich sehe kein einziges Argument, warum ein RAID5 auf weniger Platten besser sein soll als auf mehr...

Wie kommst Du bitte auf das? Ich sehe kein einziges Argument, warum ein RAID5 auf weniger Platten besser sein soll als auf mehr...

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 z. B. 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.

http://de.wikipedia.org/wiki/RAID#RAID_5:_Leistung_.2B_Parit.C3.A4t.2C_Block-Level_Striping_mit_verteilter_Parit.C3.A4tsinformation

08.08.2012, 17:11 Uhr - Editiert von hellbringer, alte Version: hier

Dieser Beitrag ist ziemlicher Unsinn - findet sich schon hier im Thread.

Ich sehe kein einziges Argument, warum ein RAID5 auf weniger Platten besser
sein soll als auf mehr...

Wo schreibst du mir 0815 Controllern im Raid5 schneller? in einem Array mit 3 oder 4 platten?
____________________________________________________________________

Only the Dead have seen the end of the War

(Plato)

Ich habe keine Ahnung, was ein 0815-Controller bei Dir ist.

Ich verwende beruflich und privat ausschließlich
- Linux Software Raid
- "Spielzeug"storage wie NetApp
- "richtigen" Storage

in allen 3 Fällen (und damit 100% der mir bekannten

) hängt die Anzahl der Spindeln direkt mit der Parallelität und damit der realen Gesamtperformance zusammen... Ich würde mich daher wetten trauen, dass selbst der dümmste RaidController mit 4 Platten mehr IOPS bietet als mit 3. Man müsste ja sonst extra was programmieren, das ihn langsamer macht

- "Spielzeug"storage wie NetApp
- "richtigen" Storage

das musst mir jetzt erklären - wenn NetApp für dich ein Spielzeug ist was ist dann richtige SAN-Storage?

0815-Controller bei Dir ist.

so ziemlich alle onBoard RAID-Controller und diese sind gerade bei RAID 5 sehr stark von der Platten-Bestückung abhängig - aus Erfahrungswerten kann ich dir sagen das gerade Intel onBoard RAID-Controller die "höchste" Performance im RAID5 Verbund mit 3 Platten bieten!
____________________________________________________________________

Only the Dead have seen the end of the War

(Plato)

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung