@stfischr/Newubunti: Den "Beleg" für die These "RAID5 nicht anfassen, während rebuild" kannst du rein auf statistische Weise führen. Die Hersteller "garantieren" dir für deine Platten mehrere Rahmenparameter (zb hier Datenblatt Serverplatte): interessant ist der Wert der die IO Operationen bis zum ersten "nicht Korrigierbaren" Fehler angibt. Bei guten Platten sind das 1/10^15 normal sind 10^14 oder 10^13. Jetzt kommt es auf deinen Raid an. In meinem Fall sind währen das 5 Platten a 1 GB. Beim Rebuild ohne die 5 Parity-Disk heißt das folgendes: Zum Auslesen der kompletten Platte braucht es 10^12 Operation (10^12/10^15 => 1/10^3). Du hast pro Platte eine Wahrscheinlichkeit von 1/10^3 (oder schlechter in Abhängigkeit von Platte und alter der Platte). Da alle 4 Platten keinen Lesefehler haben dürfen wirds nun interessant. Einfache Rechnung: Wahrscheinlichkeit für keinen Fehler = 1-10^-3. Für alle Platten gilt dann (1-10^-3)^(4). Die Wahrscheinlichkeit dass der Raid wieder hergestellt wird sind 99,6%. Dieser Wert wird schlechter jeh weniger "Luft" man bei den "fehlerlosen" Bits hat. Greifst man nun noch auf den RAID zu, reduziert sich diese "Luft". Jeh nach dem welche Platten eingesetzt worden und wie alt diese sind, kann man das riskieren.

Was bringt einem RAID5 in der Realität nun wirklich? Es rettet einem durch die erste Badewannenkurve. Festplatten haben eine Ausfallkurve in Badewannen-Form. Es steigen gehäuft sehr viele Platten am beginn ihrer Dienstzeit und am Ende ihrer Dienstzeit aus. Hat eine Platte die ersten Wochen überstanden hält sie meist bis zum Ende durch. Richtet man sich nun einen RAID aus n niegelnagel neuen Platten (am besten noch gleiche Linie) ein, sichert der RAID5 den betrieb beim Ausfall einer neuen Platte. Erwischt es einem am Ende der Lebenszeit, ist die Wahrscheinlichkeit sehr hoch, dass während des Rebuilds weitere Platten den Geist aufgeben.

In der aktuellen iX gibt es zum Thema Raid ein sehr interessante Betrachtung. Kurzfazit: RAIDs erhöhen die Datensicherheit nur bei korrekter Bedienung und Problem-Verständnis. (40% der Totalausfälle würden wohl auf Fehlbedinung/Planung zurückzuführen sein)

So betreibe ich meinen RAID:

• Ich hab ein RAID6 am laufen (2 Platten können ausfallen).

• Ich tausch im Jahrestakt (oder bei Bedarf) die Platten durch.

• Der RAID-Controler warnt mich bei Lesefehlern nutzt die Platte aber weiterhin als Parity.

• Ich mach monatlich einen abgleich/check der Raidinformationen (RAID-Verify)

• Der RAID Controler drosselt beim Rebuild den User-IO um das Rebuild zu beschleunigen.

• Zusätzlich hab ich eine Platte als HotSpare stecken.

Zusätzlich halte ich mich an Regel 1 der Datensicherheit: Ich hab ein Backup, welches unabhängig vom RAID wieder hergestellt werden kann.

PS: Ich weiß nicht wie ihr euren RAID5 Betreibt aber bei mir ist ein RAID5 (auch RAID6) wesentlich schneller als ein RAID0 (sowohl lesend als auch schreibend).

Raptor 2101 schrieb:

... Einfache Rechnung: Wahrscheinlichkeit für keinen Fehler = 1-10^-3. Für alle Platten gilt dann (1-10^-3)^(4). Die Wahrscheinlichkeit dass der Raid wieder hergestellt wird sind 99,6%. Dieser Wert wird schlechter jeh weniger "Luft" man bei den "fehlerlosen" Bits hat. Greifst man nun noch auf den RAID zu, reduziert sich diese "Luft". Jeh nach dem welche Platten eingesetzt worden und wie alt diese sind, kann man das riskieren.

Glaube keiner Statistik, die du nicht selbst gefälscht hast. MTBF ist der durchschnittliche Abstand zwischen 2 Fehlern, wenn heute, morgen, übermorgen und in 20 Jahren ein Fehler auftritt ist der MTBF trotzdem riesengroß. Wie du aber von einem statistischen Versprechen auf die Wahrscheinlichkeit für den Ausfall in einer bestimmten Zeitspanne kommst ist geradezu abenteuerlich.

In der aktuellen iX gibt es zum Thema Raid ein sehr interessante Betrachtung.

Und komischerweise erwähnt da niemand, dass man das Raid stoppen müsste für den Rebuild ... Dabei ist das doch so ein essentieller Fehler das Raid laufen zu lassen, daher bestimmt die 40% Bedienfehler.

Tut mir leid für diese Spitzen, aber hat das schonmal irgendwer in der Praxis bei einem halbwegs großen Provider/Rechenfram/Whatever gesehen (Raid stoppen für den Rebuild)?

• Ich tausch im Jahrestakt (oder bei Bedarf) die Platten durch.

Boah, geil, das ist natürlich schön, dass du so reich bist.

PS: Ich weiß nicht wie ihr euren RAID5 Betreibt aber bei mir ist ein RAID5 (auch RAID6) wesentlich schneller als ein RAID0 (sowohl lesend als auch schreibend).

Da frage ich mich, was du bei deinem Raid0 falsch machst.

Wenn ich den Server für den Rebuild vom Netz nehmen muss hat das RAID seine Funktion verfehlt. Da könnte ich auch einfach Backups machen und diese Zurücksichern, aber das ist wohl altmodisch.

Und die MTBF ist ein Durchschnitt, mehr nicht. Du kannst bei deiner Platte alle 2 Sekunden einen Fehler haben, eine andere in 100 Jahren keinen, und trotzdem passt die MTBF

mfg Betz Stefan

stfischr schrieb:

Raptor 2101 schrieb: Glaube keiner Statistik, die du nicht selbst gefälscht hast. MTBF ist der durchschnittliche Abstand zwischen 2 Fehlern, wenn heute, morgen, übermorgen und in 20 Jahren ein Fehler auftritt ist der MTBF trotzdem riesengroß. Wie du aber von einem statistischen Versprechen auf die Wahrscheinlichkeit für den Ausfall in einer bestimmten Zeitspanne kommst ist geradezu abenteuerlich.

deswegen rede ich auch nicht von der MTBF sonder von den IO-Opts bis zum ersten Fehler.

In der aktuellen iX gibt es zum Thema Raid ein sehr interessante Betrachtung.

Und komischerweise erwähnt da niemand, dass man das Raid stoppen müsste für den Rebuild ... Dabei ist das doch so ein essentieller Fehler das Raid laufen zu lassen, daher bestimmt die 40% Bedienfehler.

Tut mir leid für diese Spitzen, aber hat das schonmal irgendwer in der Praxis bei einem halbwegs großen Provider/Rechenfram/Whatever gesehen (Raid stoppen für den Rebuild)?

ich hab auch nicht gesagt, dass man den Raid stoppen soll bzw unmounten. Nur die Logik dahinter erläutert. Beruflich betreue ich fast ausschließlich Anlagen bei den RAID 11 gefahren wird. RAID 1 über 2 redundate RaidControler in einem StorageContainer. Diesen Container ebenfalls Redunant ausgelegt und am Zielsystem zu einem Raid 1 zusammengeschaltet. Und die zahlen für ne 300G platte dreistellige Summen.

• Ich tausch im Jahrestakt (oder bei Bedarf) die Platten durch.

Boah, geil, das ist natürlich schön, dass du so reich bist.

wieso "reich" wir reden hier von einer 1 Platten (100€)/Jahr um eine entsprechende Verteilung zu bekommen.

Da frage ich mich, was du bei deinem Raid0 falsch machst.

8 Platten an meinen Controller anschließen, Raid0, XFS auf StripeSize einstellen, bonnie++ anwerfen gleiches Spiel bei RAID6.

Raptor 2101 schrieb:

deswegen rede ich auch nicht von der MTBF sonder von den IO-Opts bis zum ersten Fehler.

Das macht die Rechnung aber eher noch falscher.

wieso "reich" wir reden hier von einer 1 Platten (100€)/Jahr um eine entsprechende Verteilung zu bekommen.

Ah ok, ich hatte das so interpretiert, das du jedes Jahr alle Platten auswechselst.

8 Platten an meinen Controller anschließen, Raid0, XFS auf StripeSize einstellen, bonnie++ anwerfen gleiches Spiel bei RAID6.

Dann hast du wohl nen schlechten Controller oder die Bandbreite wird begrenzt. Bei Softraid kann man das wunderschön vergleichen (jede Platte an einen extra SATA/SAS-Kanal)

stfischr schrieb:

Raptor 2101 schrieb:

deswegen rede ich auch nicht von der MTBF sonder von den IO-Opts bis zum ersten Fehler.

Das macht die Rechnung aber eher noch falscher.

eher nicht und es ist nicht meine Rechnung. Die Betrachtung kam in unterschiedlichen Artikel vor:

• ZDNET

• Techrepublic

• Wiki: Statistische Fehlerrate bei großen Festplatten

Es gibt dazu zwei unterschiedliche Betrachtungsweisen. Entweder wendest du die URE über den gesamten RAID an (zb 4 TB rebuilden mit einer fehlerrate von 1/10^14) oder du betrachtest die URE pro Platte (Rechnung von oben). Kurzfazit: jeh mehr Platte mit geringem Abstand zur URE, desto unsicherer wird RAIDN.

Ah ok, ich hatte das so interpretiert, das du jedes Jahr alle Platten auswechselst.

Das währe in der Tat Irrsinn

Dann hast du wohl nen schlechten Controller oder die Bandbreite wird begrenzt. Bei Softraid kann man das wunderschön vergleichen (jede Platte an einen extra SATA/SAS-Kanal)

Kurz OT (wenn wir das näher Ausführen wollen pm oder email): Die Theorie gibt dir recht RAID0 liefert die maximale Datenrate (n * langsamste Platte im Verbund). Das hab ich in der Praxis so aber noch nicht erlebt. Hast du das wirklich mal mit 8 Platten und aktivierten SchreibCache durchgespielt? Bei meinem letzten RAID0-Test sank der Leistungsgewinn pro Platte mit jeder gesteckten Platte. Mit einem 8 Platten/Raid 6 kamm ich auf eine Schreibrate von guten 500MByte und Read lag bei ca 650. Der RAID0 hatte gerade so 600MByte Write (eher weniger) im Read blieb er unter den 650MByte. (was ich auf zwei langsamere Hitachi Platte zurückführen konnte, der RAID6 konnte die fürs lesen ignorieren und auf die schnelleren Platten zurückgreifen). Im normalen Hausgebrauch (Datenbank/Datengrab mehrere Simultane Lese/Schreib-operationen) wurde der Abstand dann deutlicher. Das Schiebe ich mal auf die "Optimierung" die der Controler mit dem WriteCache macht. Schalte ich den ab, ist RAID0 in allen belangen uneinholbar schneller.

Raptor 2101 schrieb:

Es gibt dazu zwei unterschiedliche Betrachtungsweisen. Entweder wendest du die URE über den gesamten RAID an (zb 4 TB rebuilden mit einer fehlerrate von 1/10^14) oder du betrachtest die URE pro Platte (Rechnung von oben). Kurzfazit: jeh mehr Platte mit geringem Abstand zur URE, desto unsicherer wird RAIDN.

Klar, du hattest aber die Wahrscheinlichkeit eines Ausfalls während des Rebuilds errechnet. Also für eine gewisse Zeitspanne von ca 10 Stunden. Diese Rechnung fand ich jetzt nicht in den Artikeln, eventuell ein entsprechendes Zitat?

Die Theorie gibt dir recht RAID0 liefert die maximale Datenrate (n * langsamste Platte im Verbund). Das hab ich in der Praxis so aber noch nicht erlebt. Hast du das wirklich mal mit 8 Platten und aktivierten SchreibCache durchgespielt? Bei meinem letzten RAID0-Test sank der Leistungsgewinn pro Platte mit jeder gesteckten Platte. Mit einem 8 Platten/Raid 6 kamm ich auf eine Schreibrate von guten 500MByte und Read lag bei ca 650. Der RAID0 hatte gerade so 600MByte Write (eher weniger) im Read blieb er unter den 650MByte. (was ich auf zwei langsamere Hitachi Platte zurückführen konnte, der RAID6 konnte die fürs lesen ignorieren und auf die schnelleren Platten zurückgreifen). Im normalen Hausgebrauch (Datenbank/Datengrab mehrere Simultane Lese/Schreib-operationen) wurde der Abstand dann deutlicher. Das Schiebe ich mal auf die "Optimierung" die der Controler mit dem WriteCache macht. Schalte ich den ab, ist RAID0 in allen belangen uneinholbar schneller.

In der Firma kann ich leider nicht mit den Raids herumspielen und zuhause habe ich nur 4 Platten im Softraid. Da steigt bei Raid 0 die Leistung annähernd linear mit jeder hinzugefügten Platte. Bei Raid 6 ist besonders die Schreibleistung deutlich schwächer. (ext4 mit nobarrier)

stfischr schrieb:

Raptor 2101 schrieb: Klar, du hattest aber die Wahrscheinlichkeit eines Ausfalls während des Rebuilds errechnet. Also für eine gewisse Zeitspanne von ca 10 Stunden. Diese Rechnung fand ich jetzt nicht in den Artikeln, eventuell ein entsprechendes Zitat?

Google:

• http://www.raidtips.com/raid5-ure.aspx

• http://storagemojo.com/2010/02/27/does-raid-6-stops-working-in-2019/

Du argumentierst über die Zeit. Das Problem das ich meine geht über die Anzahl der gelesenen Bits. Jede Platte hat eine Wahrscheinlichkeit , dass es bei, lesen/schreiben eines Bits zu einem (nicht korrigierbaren) Fehler kommt (URE, UBE wird unterschiedlich benannt). Diese (1-Wahrscheinlichkeit) * Anzahl der Leseoperationen zum Wiederherstellern des Raides ergibt die Wahrscheinlichkeit keines Lesefehlers.

In der Firma kann ich leider nicht mit den Raids herumspielen und zuhause habe ich nur 4 Platten im Softraid. Da steigt bei Raid 0 die Leistung annähernd linear mit jeder hinzugefügten Platte. Bei Raid 6 ist besonders die Schreibleistung deutlich schwächer. (ext4 mit nobarrier)

Der Softraid dürfte mit der Parity von RAID6 massive Performance Einbußen haben. Aber mal anders gefragt, hast du in deiner Beruflichen Praxis schon produktiv RAID0 über mehr als 2 Platten (oder gar 4) gesehen?

Raptor 2101 schrieb:

• http://www.raidtips.com/raid5-ure.aspx

Ah ok, das erklärt es super, war also nur ein Denkfehler auf meiner Seite. Allerdings heißt es da auch, das das ganze sehr theoretisch ist. Wir haben hier z.B. ein 16TB Raid5 mit SATA-Platten (!) und da wurden mit Sicherheit schon weit über 12TB von gelesen. Bisher noch kein einziger Ausfall. Klar, kann auch Glück sein, mal sehen wie der erste Rebuild verläuft.

Der Softraid dürfte mit der Parity von RAID6 massive Performance Einbußen haben. Aber mal anders gefragt, hast du in deiner Beruflichen Praxis schon produktiv RAID0 über mehr als 2 Platten (oder gar 4) gesehen?

Nein, würde ja auch keinen Sinn machen. Dann lieber eine oder 2 SSDs.

stfischr schrieb:

Raptor 2101 schrieb:

• http://www.raidtips.com/raid5-ure.aspx

Ah ok, das erklärt es super, war also nur ein Denkfehler auf meiner Seite. Allerdings heißt es da auch, das das ganze sehr theoretisch ist. Wir haben hier z.B. ein 16TB Raid5 mit SATA-Platten (!) und da wurden mit Sicherheit schon weit über 12TB von gelesen. Bisher noch kein einziger Ausfall. Klar, kann auch Glück sein, mal sehen wie der erste Rebuild verläuft.

Ich denk mal ihr habt für den Notfall ein Backup .

Ich für meinen Fall hab schon beides erlebt.Ein niegelnagel neuer RAID aus Wartungsgründen runter gefahren und nach 2 Stunden wieder angefahren. Eine Platte komplett tod, eine weitere Meldete Lesefehler wie blöd.

Auf der anderen Seite wurde letzte Woche einer "unserer" Server in CO2 gebadet, der RAID-Controler gab auf Grund derTemperatur den Geist auf. Nach einer passenden Temperierung und einem Neustart liefen alle Platten ohne Probleme wieder an und das obwohl sie eine Dienstzeit von weit über 5 Jahren haben

Raptor 2101 schrieb:

@stfischr/Newubunti: Den "Beleg" für die These "RAID5 nicht anfassen, während rebuild" kannst du rein auf statistische Weise führen. Die Hersteller "garantieren" dir für deine Platten mehrere Rahmenparameter

...womit sich Rechenmöglichkeiten für die Planung ergeben und sich damit bei der Planung berücksichtigen lassen.

Einfache Rechnung: Wahrscheinlichkeit für keinen Fehler = 1-10^-3. Für alle Platten gilt dann (1-10^-3)^(4). Die Wahrscheinlichkeit dass der Raid wieder hergestellt wird sind 99,6%. Dieser Wert wird schlechter jeh weniger "Luft" man bei den "fehlerlosen" Bits hat. Greifst man nun noch auf den RAID zu, reduziert sich diese "Luft". Jeh nach dem welche Platten eingesetzt worden und wie alt diese sind, kann man das riskieren.

Richtet man sich nun einen RAID aus n niegelnagel neuen Platten (am besten noch gleiche Linie) ein, sichert der RAID5 den betrieb beim Ausfall einer neuen Platte. Erwischt es einem am Ende der Lebenszeit, ist die Wahrscheinlichkeit sehr hoch, dass während des Rebuilds weitere Platten den Geist aufgeben.

= Planungsfehler, dazu auch meiner aller erster Beitrag:

Newubunti schrieb:

Da es hier - soweit ich es verstanden habe - ja um Vorüberlegungen geht:

Da RAID 5 den Ausfall genau einer Platte verkraftet, man im Heimbereich eher weniger spezielle Raid-Festplatten einsetzt und die Platten womöglich in einem Block von einem Hersteller bezogen hat und damit die Wahrscheinlichkeit, dass sie aus einer Charge sind recht hoch ist, würde ich - sofern dies nicht automatisch selbst geschieht, zunächst mal den Gesundheitszustand der verbleibenden Platten überprüfen.

Dass man ein aktuelles Backup hat, setze ich jetzt mal voraus, wenn nicht wäre auch das der letzte mögliche Zeitpunkt, um schleunigst eines anzulegen - dann noch vor dem Health-Check.

Raptor 2101 schrieb:

So betreibe ich meinen RAID:

• Ich hab ein RAID6 am laufen (2 Platten können ausfallen).

• Ich tausch im Jahrestakt (oder bei Bedarf) die Platten durch.

• Der RAID-Controler warnt mich bei Lesefehlern nutzt die Platte aber weiterhin als Parity.

• Ich mach monatlich einen abgleich/check der Raidinformationen (RAID-Verify)

• Der RAID Controler drosselt beim Rebuild den User-IO um das Rebuild zu beschleunigen.

• Zusätzlich hab ich eine Platte als HotSpare stecken.

Zusätzlich halte ich mich an Regel 1 der Datensicherheit: Ich hab ein Backup, welches unabhängig vom RAID wieder hergestellt werden kann.

Eben. Damit planst Du Dein RAID bzw. dessen Datensicherheit so gut wie möglich. Und es scheint mir eben auch der Rebuild-Prozess selbst mit eingeplant. Dass Du den User-IO während der Zeit noch runterfährst, macht ja noch Sinn ein kompletter Block desselben würde kein Sinn machen und wäre dann wieder Fehlplanung.

Für mich ist der Rebuild bei einem RAID keine Sondernutzung des selben, sondern im Gegenteil eine bewusst einkalkulierte Normalnutzung. Und die muss neben den normalen Schreib-Lese-Operationen stattfinden können, sonst braucht man den eingesetzten RAID-Level nicht - zumindest nicht der Verfügbarkeit willen.

Restrisiken wird es bei jeder sorgfältigen Planung geben, - und die im übrigen nicht nur beim Rebuild des RAID sondern auch bei dessen Betrieb - weshalb man unbedingt ein Backup braucht.

Das was Du beschreibst ist nicht, dass der Rebuild an sich das Risiko erhöht, sondern ein Rebuild auf einem falsch geplanten System.

Gruß, Martin

Newubunti schrieb:

...Planungsfehler...

Du hast damit absolut recht. Jemand der seinen Raid vernünftig durchplant und ein Backup hat, ärgert sich bei einem fehlgeschlagenen Rebuild maximal über die Downtime. Der "gemeine Homeserver-Administrator" al'a "wozu brauch ich ein Backup ich hab doch'n RAID" dürfte selbigen Szenario jedoch kritischer gegen überstehen. Diese Leute lernen dann im schlimmsten Fall aus schmerzen, das nächste mal besser zu planen