Diskussion:RAID
Letzter Kommentar: vor 15 Jahren von Nmoas in Abschnitt RAID 01
Diese Diskussionsseite dient dazu, Verbesserungen am Artikel „RAID“ zu besprechen. Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.
Füge neue Diskussionsthemen unten an:
Klicke auf , um ein neues Diskussionsthema zu beginnen.| Archiv |
| Wie wird ein Archiv angelegt? |
Werte in den Tabellen Zusammenfassung, RAID
RAID 10 und 0+1 "Übersicht über die Kombinations-RAIDs" Zusammenfassung nicht richtig:
Nettokapazität für RAID 10 bzw. analog RAID 1+0 ist nicht immer n/2:
i ... Anzahl der Festplatten in einem Leg j ... Anzahl der Legs n ... Anzahl der Festplatten ( i * j = n) Voraussetzung: i >= 2, j >=2 => Für RAID 10 und i > 2 gilt diese Aussage nicht => Für RAID 0+1 und j > 2 gilt diese Aussage nicht
richtig müsste sein (ohne Quelle/n):
=> RAID 10: j (da (i - 1) Festplatten pro Leg wegfallen => Nutzbarer Speicher: n - (i - 1) * j = j) => RAID 0+1: i (da alle Legs gespiegelt sind entspricht der gesamte Speicher der Anzahl von Platten in einem Leg)
-- Csae2414 15:07, 19. Aug. 2010 (CEST)
RAID DP
Im Abschnitt "5.7 RAID DP" wird die Berechnung der beiden Paritäten beschrieben - das kann so aber nicht stimmen.
Beispiel:
Wenn Festplatten A und C ausfallen, dann kann A2 und C2 rekonstruiert werden, aber nicht A1, A3, C1 und C3.
A1 kann nicht aus P1 rekonstruiert werden, da C1 nicht verfügbar ist.
A1 ist nicht in einer diagonalen Parität enthalten.
A3 kann nicht aus P3 rekonstruiert werden, da C3 nicht verfügbar ist.
A3 kann nicht aus Q2 rekonstruiert werden, da C1 nicht verfügbar ist.
C1 kann nicht aus P1 rekonstruiert werden, da A1 nicht verfügbar ist.
C1 kann nicht aus Q2 rekonstruiert werden, da A3 nicht verfügbar ist.
C3 kann nicht aus P3 rekonstruiert werden, da A3 nicht verfügbar ist.
C3 ist nicht in einer diagonalen Parität enthalten.
Gemäß der Beschreibung des Einzelnachweises [7] (http://www.usenix.org/publications/library/proceedings/fast04/tech/corbett/corbett.pdf) habe ich es mit 4 Festplatten und allen Ausfallkombinationen durchgespielt - damit ist alles rekonstruierbar.
Leider weiß ich nicht, ob man nur die diagonale Parität Q für 3+2 Festplatten anders berechnen muss oder ob man mindestens 4+2 Festplatten braucht. (nicht signierter Beitrag von 93.132.169.248 (Diskussion) 16:27, 24. Okt. 2010 (CEST))
RAID 01
Folgendes scheint mir falsch zu sein (Siehe RAID#Performance Absatz "IOPS und MB/s bei RAID 5" , ist auch nicht belegt):
- Im ungünstigen Fall muss bei RAID 01 (Anm. nmoas) mit erheblichen Leistungseinbußen und erhöhter Ausfallwahrscheinlichkeit gerechnet werden, da die Schreib-/Leseköpfe beim sequentiellen Schreiben permanent hin- und herspringen müssen.
- Das müssen Köpfe ja eigentlich immer, es kommt auf die Effizienz an. Die Effizienz der Kopfbewegungen entsprechen dem Verhältnis max. nutzbaren netto IOPS zu brutto möglichen IOPS also bei RAID 5 mit 3 Platten zwischen 25% bei kleinen Blöcken und 66% bei kompletten Stripesets (Siehe RAID#Performance Absatz "IOPS und MB/s bei RAID 5"); bei RAID 01 immer 50%[1] - was also effizienter beim schreiben ist - also die Mechanik besser schont - lässt sich pauschal nicht sagen.--Nmoas 04:51, 26. Okt. 2010 (CEST)
- Bei RAID 01 mit drei Festplatten hängt es davon ab, wie es realisiert wurde. Wenn es so gestaltet ist wie in der Skizze, dann würde das bedeuten, dass die Schreib-/Leseköpfe mit jeder Schreibakti--Björn König 15:05, 1. Nov. 2010 (CET)on wild über die Platte springen, wenn Anfang und Mitte der Festplatte physisch weit auseinander liegen. Meinetwegen muss das aber nicht gesagt werden, weil RAID-01 mit drei Festplatten sowieso ziemlich exotisch und daher in der Praxis kaum interessant ist. --Björn König 15:42, 29. Okt. 2010 (CEST)
- Das müssen Köpfe ja eigentlich immer, es kommt auf die Effizienz an. Die Effizienz der Kopfbewegungen entsprechen dem Verhältnis max. nutzbaren netto IOPS zu brutto möglichen IOPS also bei RAID 5 mit 3 Platten zwischen 25% bei kleinen Blöcken und 66% bei kompletten Stripesets (Siehe RAID#Performance Absatz "IOPS und MB/s bei RAID 5"); bei RAID 01 immer 50%[1] - was also effizienter beim schreiben ist - also die Mechanik besser schont - lässt sich pauschal nicht sagen.--Nmoas 04:51, 26. Okt. 2010 (CEST)
- Dadurch wird die Mechanik der Festplatten deutlich stärker belastet als bei RAID 5. Sofern es die sonstigen Umstände zulassen, sollte daher RAID 5 bevorzugt werden.
- Was nicht aufgezeigt wurde - Im Gegenteil: umfassen die Schreibzugriffe relativ kleine Blockgrößen (< Stripesize), dann geht die Kopf-Mechanik von Platten im RAID 5 etwa doppelt so schnell kaputt als bei RAID 10 Platten. [1] --Nmoas 04:51, 26. Okt. 2010 (CEST)
- Der Artikel geht von RAID 01 mit vier Festplatten aus und bringt bei der Klärung dieser Frage daher nicht weiter. --Björn König 15:46, 29. Okt. 2010 (CEST)
- Doch, er hilft - denn es ändert sich bei Raid 01 mit 3, 4 oder mehr Platten praktisch gar nichts (außer eben die Anzahl Laufwerke auf die sich die Schreib-Zugriffe verteilen - die Effizienz ändert sich hierbei nicht und liegt unter Last konstant bei 50%, also einen Block schreiben resultiert immer in 2 Blöcke schreiben bzw. 2 mal Positionieren). Besonders aber Raid 5 kann bei ungünstigen Blockgrößen eine echte Tortur für die Platten sein (Effizienz nur 25% bzw. 4 mal Positionieren - siehe Artikel)[1], das geht deutlich aus dem Artikel hervor. Über Raid 5 wird meines Erachtens viel mystifiziert, da liefert der Artikel erfrischend viel Klarheit und zeigt, dass die Eigenschaften und das Leistungsverhalten von Raid 5 von der Implementierung und vom Anwendungsfall abhängig ist - und einen günstigen und einen ungünstigen Fall kennt, für Raid 01 gilt das eben nicht, immer 50% ! --Nmoas 06:29, 1. Nov. 2010 (CET)
- ↑ a b c Yet another RAID-10 vs RAID-5 question Tom Treadway, Adaptec Storage Advisors, 17. April 2007
- Nein. Er hilft nicht, denn bei RAID 01 mit drei Festplatten ändert sich praktisch eine Menge, was in dem Artikel überhaupt nicht betrachtet wird. Nämlich - wie bereits gesagt - dass die Schreib-/Leseköpfe dort deutlich mehr bewegt werden müssen. Das bedeutet mehr Belastung und darum auch höhere Ausfallwahrscheinlichkeit. Es wird ebenfalls nicht darauf eingegangen, dass ein vernünftiger RAID-5-Controller die Blöcke im Cache behält, so dass insbesondere beim sequentiellen Schreiben nicht mit jedem zu schreibenden Block zwei gelesen und zwei geschrieben werden müssen, sondern nur zwei geschrieben werden müssen. Das entlastet die Festplattenmechanik deutlich. Das es in der Praxis anders ist als dort geschrieben steht, wird nur angedeutet: "(It’s a little more complicated than that, but this is a pretty good estimate.)" Dieser Artikel geht überhaupt kein Stück auf Zuverlässigkeit ein, sondern nur auf die Frage, was schneller ist. Aus der Anzahl der Schreib-/Lesezugriffe die Zuverlässigkeit abzuleiten, halte ich für sehr fragwürdig, da eben so etwas höchst Entscheidendes wie Ausmaß der Kopfbewegungen völlig ausgeblendet wird. Dabei sind die Kopfbewegung bei RAID 01 mit drei Festplatten der bedeutendste Unterschied zu RAID 01 mit vier Festplatten und RAID 5 mit drei Festplatten. --Björn König 15:05, 1. Nov. 2010 (CET)
- DOCH! Auch vom mehrfachen Behaupten wird nichts besser! Du behauptest, dass bei Raid 01 mehr Kopfbewegungen stattfinden würden als bei Raid 5, es wird aber nicht aufgezeigt oder belegt! Auch wird behauptet das bei Raid 01 mit 3 Platten mehr Kopfbewegungen nötig seien als mit 4 Platten, aber ebenfalls wird nichts aufgezeigt oder belegt! Bitte erkläre doch mal warum beim Schreiben von Blöcken (oder von Stripes) bei 3 Platten etwas anders passieren soll als bei 4 Platten im Raid 01 - spiele es doch mal durch - es wird dir nicht möglich sein - kein Artikel braucht daher auch den besonderen (und exotischeren) Fall mit 3 Platten extra zu beschreiben, auch nicht mit mehr Platten als 4 - da bleibt sich alles gleich, jedoch verteilt sich die Last auf die Anzahl Platten: Ein Block schreiben entspricht im ungünstigen (=günstigen) Fall 2 mal Positionieren, und 3 Blöcke schreiben ist 6 mal Positionieren im ungünstigen Fall (im günstigen Fall - wenn der erste Block und das Spiegelbild des 2. Blocks auf dem gleichen Zylinder/Spur liegen usw. - jedoch auch nur 3 mal positionieren bei drei Platten). --Nmoas 19:34, 3. Nov. 2010 (CET)
- Was soll ich denn machen um es aufzuzeigen? Einen wissenschaftlichen Testaufbau und von unabhängigen Laboren bestätigte Testergebnisse? Wie wäre es denn mal zur Abwechselung die Vorstellungskraft einzuschalten und versuchen zu verstehen, was ich schreibe? Also zum letzten Mal, nun ganz deutlich: In der Skizze gibt es zwei Bereiche. Einen für RAID 0 und einen für RAID 1. Diese liegen gemäß der logischen Geometrie weit auseinander und können physikalisch ebenso weit auseinander liegen. Zum Beispiel wenn wenn man eine Festplatte verwendet, bei der eine ungerade Anzahl von Plattern verwendet wird. Bei einer geraden Anzahl ist es wahrscheinlich, dass logisch weit auseinander liegende Bereiche physisch sich an der selben Stelle auf den Plattern befinden, nur eben auf verschiedenen Plattern oder Platterseiten. Liegen die Anfänge der Bereiche von RAID 0 und RAID 1 nun weit auseinander, dann springt der Schreib-/Lesekopf sehr eben viel hin und her. Nämlich pro Schreibvorgang einmal über die Hälfte der Oberfläche und beim sequentiellen Schreiben anschließend wieder zurück. Das ist eine enorme Belastung. Da der Artikel hier keine Unterscheidung zwischen RAID 01 mit drei Platten und RAID 01 mit vier Platten macht, kann man getrost davon ausgehen, dass der Artikel diesen Umstand nicht berücksicht. Denn Rest Ihres Diskussionsbetrags ausführlich zu kommentieren spare ich mir aus Zeitgründen mal, denn ich merke, dass wir gründlich aneinandervorbei Palavern. Ihren Ausführungen zum Cache-Verhalten brauche ich auch gar nicht widersprechen, weil sie nicht falsch sind. Sie hätten sich nicht die Mühe machen müssen so gründlich zu antworten, wenn Sie meinen Beitrag gelesen hätten, wo ich mich ausdrücklich und ausschließlich auf sequentielle Schreibvorgänge beziehe. Alles andere ist nicht Gegenstand der Diskussion. Schönes Leben noch. --Björn König 13:02, 8. Nov. 2010 (CET)
- Also, jetzt bemerke ich erstmals was da genau skizziert ist und verstehe absolut nicht warum dieses ziemlich unpraktische Layout gewählt wurde (es geht natürlich auch immer noch komplizierter - das müsste man aber auch mit einem ähnlich unsinnigen Raid 5 Layout vergleichen. ... Typ: Hauptsache der Kopf hüpft), aber einfacher ist doch sicher folgendes Layout für Raid 01 bzw. Stripes (wie Raid 0 - da werden z. B. drei Platten abwechselnd beschrieben - 1.Datenblock: Platte 1 Block 1; 2.Datenblock: Platte 2 Block 1; 3.Datenblock: Platte 3 Block 1; 4.Datenblock: Platte 1 Block 2; usw. - nicht SPAN/JBOD like wie in der Skizze!) kombiniert mit Mirroring (wie Raid 1), dann ist auch egal ob eine Platte gradzahlig oder ungradzahlig viele Blöcke hat:
- Der 1. Datenblock liegt auf Platte 1 und ist dort Block 1, sein Spiegelbild (Mirror) ist auf der 2. Platte der 1. Block. Der 2. Datenblock ist auf Platte 3 Block 1 dessen Mirror ist wieder auf Platte 1 der Block 2. Der 3. Datenblock (3.DB) ist auf 2. Platte 2. Block (2P2B), zugöriger Mirror ist 3P2B. 4.DB: 1P3B und 2P3B. 5.DB: 3P3B und 1P4B. 6.DB 2P4B und 3P4B und so weiter und so fort. Dieses Layout hat im Gegensatz zur Skizze und zur Zeichnung keine höhere Kopfbewegungsanzahl als jede andere Raid 1 oder Raid 01 Kombination. Ob ein Layout wie skizziert überhaupt irgendwo implementiert ist, wage ich zu bezweifeln, es ist einfach unnütz verkompliziert. (Man sollte daher die Skizze ändern) --Nmoas 15:23, 8. Nov. 2010 (CET)
- Was soll ich denn machen um es aufzuzeigen? Einen wissenschaftlichen Testaufbau und von unabhängigen Laboren bestätigte Testergebnisse? Wie wäre es denn mal zur Abwechselung die Vorstellungskraft einzuschalten und versuchen zu verstehen, was ich schreibe? Also zum letzten Mal, nun ganz deutlich: In der Skizze gibt es zwei Bereiche. Einen für RAID 0 und einen für RAID 1. Diese liegen gemäß der logischen Geometrie weit auseinander und können physikalisch ebenso weit auseinander liegen. Zum Beispiel wenn wenn man eine Festplatte verwendet, bei der eine ungerade Anzahl von Plattern verwendet wird. Bei einer geraden Anzahl ist es wahrscheinlich, dass logisch weit auseinander liegende Bereiche physisch sich an der selben Stelle auf den Plattern befinden, nur eben auf verschiedenen Plattern oder Platterseiten. Liegen die Anfänge der Bereiche von RAID 0 und RAID 1 nun weit auseinander, dann springt der Schreib-/Lesekopf sehr eben viel hin und her. Nämlich pro Schreibvorgang einmal über die Hälfte der Oberfläche und beim sequentiellen Schreiben anschließend wieder zurück. Das ist eine enorme Belastung. Da der Artikel hier keine Unterscheidung zwischen RAID 01 mit drei Platten und RAID 01 mit vier Platten macht, kann man getrost davon ausgehen, dass der Artikel diesen Umstand nicht berücksicht. Denn Rest Ihres Diskussionsbetrags ausführlich zu kommentieren spare ich mir aus Zeitgründen mal, denn ich merke, dass wir gründlich aneinandervorbei Palavern. Ihren Ausführungen zum Cache-Verhalten brauche ich auch gar nicht widersprechen, weil sie nicht falsch sind. Sie hätten sich nicht die Mühe machen müssen so gründlich zu antworten, wenn Sie meinen Beitrag gelesen hätten, wo ich mich ausdrücklich und ausschließlich auf sequentielle Schreibvorgänge beziehe. Alles andere ist nicht Gegenstand der Diskussion. Schönes Leben noch. --Björn König 13:02, 8. Nov. 2010 (CET)
- Die Frage ist Raid 01 oder Raid 5, da spielt Cache erst mal keine Rolle, Raid 5 fordert keinen Cache. Dennoch, wenn du jetzt noch mit Cache-Hits rechnen willst, ist das die optimistische Annahme eines günstigen Falls, dass da Raid 5 gut abschneidet ist ja gar nicht fraglich. Man kann aber Raid 5 nicht mit Cache-Hit gleichsetzen, weil 1. nicht alle Systeme/Controller Cache haben, 2. Cache häufig sehr klein ist (im Vergleich zum Plattenplatz bzw. Datendurchsatz) und daher der Cache nur für sehr kurze Zeit Blocks speichert und wiederum daher bei normalerweise gut ausgelasteten Systemen und dem Raid 5 Schreiben ein Cache-Miss die Regel ist (= weit häufiger). Auch werden bei ausgelasteten Systemen die Köpfe nicht nach dem Lesen warten bis das Schreib-Kommando endlich kommt (das ist ja zu diesem Zeitpunkt noch nicht mal in einer Command-Queue - und Warten würde ja die Systemleistung herabsetzen), sondern für andere Tasks die Command-Queue abarbeiten und weitere Blöcke ansteuern. Also: Im ungünstigen Fall - bei Cache-Miss und bei kleinen Blöcken - müssen erst 2 Blöcke gelesen werden, dann erfolgt die Parity-Berechnung und dann das Schreiben. 1 Block schreiben bedeutet 4 mal positionieren - der Typ von Adaptec kennt sich aus! (Ähnliches schreibt auch Sun in einem Raid/ZFS Paper, das mittlerweile scheinbar vom Orakel gefressen wurde ...) --Nmoas 19:34, 3. Nov. 2010 (CET)
- DOCH! Auch vom mehrfachen Behaupten wird nichts besser! Du behauptest, dass bei Raid 01 mehr Kopfbewegungen stattfinden würden als bei Raid 5, es wird aber nicht aufgezeigt oder belegt! Auch wird behauptet das bei Raid 01 mit 3 Platten mehr Kopfbewegungen nötig seien als mit 4 Platten, aber ebenfalls wird nichts aufgezeigt oder belegt! Bitte erkläre doch mal warum beim Schreiben von Blöcken (oder von Stripes) bei 3 Platten etwas anders passieren soll als bei 4 Platten im Raid 01 - spiele es doch mal durch - es wird dir nicht möglich sein - kein Artikel braucht daher auch den besonderen (und exotischeren) Fall mit 3 Platten extra zu beschreiben, auch nicht mit mehr Platten als 4 - da bleibt sich alles gleich, jedoch verteilt sich die Last auf die Anzahl Platten: Ein Block schreiben entspricht im ungünstigen (=günstigen) Fall 2 mal Positionieren, und 3 Blöcke schreiben ist 6 mal Positionieren im ungünstigen Fall (im günstigen Fall - wenn der erste Block und das Spiegelbild des 2. Blocks auf dem gleichen Zylinder/Spur liegen usw. - jedoch auch nur 3 mal positionieren bei drei Platten). --Nmoas 19:34, 3. Nov. 2010 (CET)
- Nein. Er hilft nicht, denn bei RAID 01 mit drei Festplatten ändert sich praktisch eine Menge, was in dem Artikel überhaupt nicht betrachtet wird. Nämlich - wie bereits gesagt - dass die Schreib-/Leseköpfe dort deutlich mehr bewegt werden müssen. Das bedeutet mehr Belastung und darum auch höhere Ausfallwahrscheinlichkeit. Es wird ebenfalls nicht darauf eingegangen, dass ein vernünftiger RAID-5-Controller die Blöcke im Cache behält, so dass insbesondere beim sequentiellen Schreiben nicht mit jedem zu schreibenden Block zwei gelesen und zwei geschrieben werden müssen, sondern nur zwei geschrieben werden müssen. Das entlastet die Festplattenmechanik deutlich. Das es in der Praxis anders ist als dort geschrieben steht, wird nur angedeutet: "(It’s a little more complicated than that, but this is a pretty good estimate.)" Dieser Artikel geht überhaupt kein Stück auf Zuverlässigkeit ein, sondern nur auf die Frage, was schneller ist. Aus der Anzahl der Schreib-/Lesezugriffe die Zuverlässigkeit abzuleiten, halte ich für sehr fragwürdig, da eben so etwas höchst Entscheidendes wie Ausmaß der Kopfbewegungen völlig ausgeblendet wird. Dabei sind die Kopfbewegung bei RAID 01 mit drei Festplatten der bedeutendste Unterschied zu RAID 01 mit vier Festplatten und RAID 5 mit drei Festplatten. --Björn König 15:05, 1. Nov. 2010 (CET)
- Der Artikel setzt zurecht (auch wenn es in der Realität mit unter komplizierter ist) Zugriffe mit dem Positionieren von Köpfen gleich, das ist a pretty good estimate solange man gleiche Platten hat und das sowohl bei Raid 01 als auch bei Raid 5 tut - das sollte keine Frage sein. --Nmoas 19:34, 3. Nov. 2010 (CET)
- Es geht im Absatz darum den ungünstigen Fall von Raid 5 mit Raid 01 (auch Raid 1) zu vergleichen und herauszuarbeiten dass Raid 5 unter Umständern nachteilhaft sein kann und Anwender enttäuscht/getäuscht werden. Die positiven Eigenschaften von Raid 5 werden in Marketing-Blättchen immer zur Genüge herausgearbeitet, aber das ist nur die halbe (Werbe-) Wahrheit. Merke: unter allen Umständen, auch unter Vollast arbeitet ein Raid 01 (auch Raid 1) immer mit einer Effizienz von 50% (oder wenn fortlaufende Blocks geschrieben werden auch noch besser), Raid 5 hingegen kommt bei 3 Platten unter ungünstigen Bedingungen nur auf 25% (1 Block schreiben = 4 mal Kopf bewegen) (Besser nur unter günstigen Bedingungen, wie dem Schreiben von großen zusammenhängenden Blöcken, dann immerhin auf 66% also: 2 Blöcke schreiben = 3 mal Kopf bewegen - und wenn fortlaufende Stripes geschrieben werden natürlich auch noch besser, eben wie bei Raid 01 auch)! --Nmoas 19:34, 3. Nov. 2010 (CET)