Flex-RAID anstatt RAID5?
- Ersteller Unlimited
- Erstellt am
Leute ich werde diese "neue" Datenschutz-Technologie demnächst mal ausprobieren und evtl mein RAID5 dadurch ersetzen.
Der enorme Vorteil von FlexRAID ist, dass es auf Datenbasis arbeitet und daher nicht mit 4 gleichen HDDs ausgestattet sein muss.
Nachteil ist, dass Zugriffe nicht beschleunigt werden, aber das lässt sich für ein Datengrab verschmerzen.
Wäre schön, wenn jemand, der schon Erfahrungen damit gesammelt hat, hier kurz was dazu posten könnte.
Z.B. Anfängerfehler vermeiden, gibt es bessere Konkurrenzsoftzware, etc...
Quellen:
http://en.wikipedia.org/wiki/FlexRAID
http://www.flexraid.com/
Forum (registrierung erforderlich)
http://www.openegg.org/forums/forums/list.page
Download:
http://wiki.flexraid.com/2011/04/05/flexraid-lastest-download-links/
Nachtrag: leider ist FlexRAID seit Anfang 2012 nicht mehr frei verfügbar.
Es gibt jedoch kostenlose Alternativen, hier eine Übersicht:
http://snapraid.sourceforge.net/compare.html
Der enorme Vorteil von FlexRAID ist, dass es auf Datenbasis arbeitet und daher nicht mit 4 gleichen HDDs ausgestattet sein muss.
Nachteil ist, dass Zugriffe nicht beschleunigt werden, aber das lässt sich für ein Datengrab verschmerzen.
Wäre schön, wenn jemand, der schon Erfahrungen damit gesammelt hat, hier kurz was dazu posten könnte.
Z.B. Anfängerfehler vermeiden, gibt es bessere Konkurrenzsoftzware, etc...
Quellen:
http://en.wikipedia.org/wiki/FlexRAID
http://www.flexraid.com/
Forum (registrierung erforderlich)
http://www.openegg.org/forums/forums/list.page
Download:
http://wiki.flexraid.com/2011/04/05/flexraid-lastest-download-links/
Nachtrag: leider ist FlexRAID seit Anfang 2012 nicht mehr frei verfügbar.
Es gibt jedoch kostenlose Alternativen, hier eine Übersicht:
http://snapraid.sourceforge.net/compare.html
Zuletzt bearbeitet:
Ich bin gerade selber dabei mich stück für stück einzuarbeiten:
FlexRAID funktioniert wie ein RAID5 oder RAID6 mit Paritydaten.
Der Unterschied ist: es ist ein SnapshotRAID, dass auf Datenebene funktioniert und daher die Daten nicht auf mehrere Platten striped.
Wenn das RAID zerschießt sind die Daten auf den einzelnen HDD's ohne Probleme in Rohform lesbar.
Die Paritydaten sind alle auf einem extra Parity-Laufwerk konzentriert und nicht auf alle Laufwerke verteilt.
Gleichzeitig sind auch die Rohdaten wie auf einem normalen Laufwerk in normal lesbarer Rohform auf den Platten vorhanden.
Dies ist für mich EINER der ganz großen Gründe bei FlexRAID einsteigen zu wollen.
Entgegen RAID5/6 benötigt FlexRAID nämlich WIRKLICH kein Backup mehr ...
[EDIT: OK, Nachtrag für alle, die jedes Wort auf die Goldwaage legen, hier die Langversion:
Ja doch, die WICHTIGSTEN Daten, sollte man natürlich immer zusätzlich backuppen!
Lustigerweise sind diese "wichtigsten" Daten im Privathaushalt meist nur ein Bruchteil der gesamten Datenmenge, paar Bildle, Email, etc... wenige GB... Andererseits: verschmerzbare potentielle Verlustdaten verbrauchen meist exorbitant viel PLatz! Da wäre z.B. die sicherheitskopierten CDs oder gar Bluerays... davon braucht man kein Backup mehr wegen mangelnder Risiko/Kosten/Aufwandverhältnis. Ich denke auch, man benötigte keine ganz so hohe Backupfrequenz mehr, Hauptsache das SnapshotRAID ist jeweils nach Hinzufügen wichtiger Daten geschwind gesynched...]
...allein schon, da die Daten nicht durch Stromausfall/Hardwarefail "verstriped" werden können.
Ein FlexRAID fügt, anders als jedes Striperaid, KEINE zusätzlichen Datenverlust-Risikofaktoren hinzu.
Vorteile FlexRAID:
=> Daten in Rohform lesbar (erhöhte Sicherheit!)
=> jederzeit erweiterbar
=> Laufwerke untersch. Größe effizient nutzbar
=> sehr billig, da freeware
Derzeit ist eine realtime-Variante in Entwicklung.
Begriffe:
=> DRU (Data Risk Unit): ganz normale Festplatte mit DATEN drauf
=> PPU (Parity Protection Unit): Festplatte auf der alle PARITYdaten des FlexRAID geschrieben werden
Ich plane folgende Kombi:
3x1TB als DRU
1x2TB als PPU
Flexraid errechnet aus den Daten auf den drei 1TB Platten einen Paritywert, den es auf der PPU speichert.
Es speichert diese Parityinformationen ganz normal als .flxr-Dateien in NTFS auf der PPU-Platte.
Man kann also einfach x-beliebige volle Platten mit einer Kapazität kleiner/gleich der PPU hernehmen und sofort ins RAID hängen.
Wenn also (in meiner Konfig) alle drei DRU's voll mit Daten sind, habe ich maximal 1TB Paritydaten auf meiner PPU-Platte.
Würde ich 6 oder unendlich viele DRU's mit je 1TB verwenden, würden die Paritydaten immernoch nur 1TB belegen.
Man kann mit FlexRAID recht effizient Daten absichern.
Auf der PPU wird genau so viel Speicherplatz belegt, wie auf der vollsten DRU.
Daher kann ich die verbleibenden 1TB auf der 2TB-Platte ganz normal für Datenspeicherung nutzen.
Diese Daten sind allerdings nicht gegen einen Ausfall geschützt, daher werd ich da hauptsächlich TMP-Daten draufhauen.
Sobald ich mehr Speicher benötige, hänge ich einfach eine weitere Daten-Platte mit max 2TB als DRU mit dran und lasse Flexraid die Parity neu berechnen.
Fertig.
Man kann auch mehrere kleine Platten poolen zu einer großen. Das werde ich allerdings nicht angehen, da große 2TB-Platten inzwischen so billig geworden sind, dass sich das null lohnt.
FlexRAID 2.0 hat eine HTML-Bedienoberfläche, die leicht verständlich ist.
Ausfall einer Platte:
Wenn die Parityplatte ausfällt ist, diese einfach austauschen und die Paritydaten neu berechnen lassen.
Wenn eine beliebige Datenplatte ausfällt, muss noch nichtmal eine neue Platte eingehängt werden: sofern genug Speicher auf den vorhandenen Festplatten existiert, gibt man FlexRAID einfach einen Ordner an, in dem die Daten der ausgefallenen Platte wiederhergestellt werden sollen. Natürlich kann man die Daten auch auf einer neuen Festplatte wiederherstellen lassen.
Flexraid berechnet dabei aus der Parity und den noch vorhandenen Daten auf den anderen DRU's die Daten der verlorenen Platte.
Wenn man 1PPU verwendet darf maximal 1HDD ausfallen.
Wenn man 2PPU verwendet dürfen max. 2HDD ausfallen, usw....
Fazit:
Also FlexRAID ist ein Sicherheits-Feature und kein Performance-Feature.
Für die Performance ist jetzt aber auch meine SSD zuständig.
Dieses Sicherheitsfeature ist erheblich zuverlässiger als RAID5/6 und genausogut wie ein Backup, nur dass es deutlich weniger Platz verbraucht.
Man kann die PPU-Platte ebenso wie eine normale Backupplatte sogar zwischen den Backups abstecken.
Nachteil von FlexRAID: genauso wie ein Backup funktioniert es (noch) nicht im laufenden Betrieb nebenher... man muss den ParitySync schedulen.
Im Gegensatz zu RAID5/6 ist es umsonst.
Ich würde mich sehr freuen, wenn ich einige User, die bislang mit RAID noch nichts am Hut hatten für FlexRAID begeistern konnte.
Noch mehr würd es mich freuen, wenn auch ein paar alte RAID-Hasen wie ich den Umstieg wagen würden...
.
EDIT :
.
Als Nachteil könnte sich eine lange Berechnungsdauer für die Parity bei großen Datenmengen erweisen, aber dazu kann ich leider noch nichts sagen.... das steht mir noch bevor.
Bin mal gespannt wie schnell ein Parityupdate von 2TB Daten dauert, wenn nur einige GB geändert wurden seit dem letzten ParitySync
FlexRAID funktioniert wie ein RAID5 oder RAID6 mit Paritydaten.
Der Unterschied ist: es ist ein SnapshotRAID, dass auf Datenebene funktioniert und daher die Daten nicht auf mehrere Platten striped.
Wenn das RAID zerschießt sind die Daten auf den einzelnen HDD's ohne Probleme in Rohform lesbar.
Die Paritydaten sind alle auf einem extra Parity-Laufwerk konzentriert und nicht auf alle Laufwerke verteilt.
Gleichzeitig sind auch die Rohdaten wie auf einem normalen Laufwerk in normal lesbarer Rohform auf den Platten vorhanden.
Dies ist für mich EINER der ganz großen Gründe bei FlexRAID einsteigen zu wollen.
Entgegen RAID5/6 benötigt FlexRAID nämlich WIRKLICH kein Backup mehr ...
[EDIT: OK, Nachtrag für alle, die jedes Wort auf die Goldwaage legen, hier die Langversion:
Ja doch, die WICHTIGSTEN Daten, sollte man natürlich immer zusätzlich backuppen!
Lustigerweise sind diese "wichtigsten" Daten im Privathaushalt meist nur ein Bruchteil der gesamten Datenmenge, paar Bildle, Email, etc... wenige GB... Andererseits: verschmerzbare potentielle Verlustdaten verbrauchen meist exorbitant viel PLatz! Da wäre z.B. die sicherheitskopierten CDs oder gar Bluerays... davon braucht man kein Backup mehr wegen mangelnder Risiko/Kosten/Aufwandverhältnis. Ich denke auch, man benötigte keine ganz so hohe Backupfrequenz mehr, Hauptsache das SnapshotRAID ist jeweils nach Hinzufügen wichtiger Daten geschwind gesynched...]...allein schon, da die Daten nicht durch Stromausfall/Hardwarefail "verstriped" werden können.
Ein FlexRAID fügt, anders als jedes Striperaid, KEINE zusätzlichen Datenverlust-Risikofaktoren hinzu.
Vorteile FlexRAID:
=> Daten in Rohform lesbar (erhöhte Sicherheit!)
=> jederzeit erweiterbar
=> Laufwerke untersch. Größe effizient nutzbar
=> sehr billig, da freeware
Derzeit ist eine realtime-Variante in Entwicklung.
Begriffe:
=> DRU (Data Risk Unit): ganz normale Festplatte mit DATEN drauf
=> PPU (Parity Protection Unit): Festplatte auf der alle PARITYdaten des FlexRAID geschrieben werden
Ich plane folgende Kombi:
3x1TB als DRU
1x2TB als PPU
Flexraid errechnet aus den Daten auf den drei 1TB Platten einen Paritywert, den es auf der PPU speichert.
Es speichert diese Parityinformationen ganz normal als .flxr-Dateien in NTFS auf der PPU-Platte.
Man kann also einfach x-beliebige volle Platten mit einer Kapazität kleiner/gleich der PPU hernehmen und sofort ins RAID hängen.
Wenn also (in meiner Konfig) alle drei DRU's voll mit Daten sind, habe ich maximal 1TB Paritydaten auf meiner PPU-Platte.
Würde ich 6 oder unendlich viele DRU's mit je 1TB verwenden, würden die Paritydaten immernoch nur 1TB belegen.
Man kann mit FlexRAID recht effizient Daten absichern.
Auf der PPU wird genau so viel Speicherplatz belegt, wie auf der vollsten DRU.
Daher kann ich die verbleibenden 1TB auf der 2TB-Platte ganz normal für Datenspeicherung nutzen.
Diese Daten sind allerdings nicht gegen einen Ausfall geschützt, daher werd ich da hauptsächlich TMP-Daten draufhauen.
Sobald ich mehr Speicher benötige, hänge ich einfach eine weitere Daten-Platte mit max 2TB als DRU mit dran und lasse Flexraid die Parity neu berechnen.
Fertig.
Man kann auch mehrere kleine Platten poolen zu einer großen. Das werde ich allerdings nicht angehen, da große 2TB-Platten inzwischen so billig geworden sind, dass sich das null lohnt.
FlexRAID 2.0 hat eine HTML-Bedienoberfläche, die leicht verständlich ist.
Ausfall einer Platte:
Wenn die Parityplatte ausfällt ist, diese einfach austauschen und die Paritydaten neu berechnen lassen.
Wenn eine beliebige Datenplatte ausfällt, muss noch nichtmal eine neue Platte eingehängt werden: sofern genug Speicher auf den vorhandenen Festplatten existiert, gibt man FlexRAID einfach einen Ordner an, in dem die Daten der ausgefallenen Platte wiederhergestellt werden sollen. Natürlich kann man die Daten auch auf einer neuen Festplatte wiederherstellen lassen.
Flexraid berechnet dabei aus der Parity und den noch vorhandenen Daten auf den anderen DRU's die Daten der verlorenen Platte.
Wenn man 1PPU verwendet darf maximal 1HDD ausfallen.
Wenn man 2PPU verwendet dürfen max. 2HDD ausfallen, usw....
Fazit:
Also FlexRAID ist ein Sicherheits-Feature und kein Performance-Feature.
Für die Performance ist jetzt aber auch meine SSD zuständig.
Dieses Sicherheitsfeature ist erheblich zuverlässiger als RAID5/6 und genausogut wie ein Backup, nur dass es deutlich weniger Platz verbraucht.
Man kann die PPU-Platte ebenso wie eine normale Backupplatte sogar zwischen den Backups abstecken.
Nachteil von FlexRAID: genauso wie ein Backup funktioniert es (noch) nicht im laufenden Betrieb nebenher... man muss den ParitySync schedulen.
Im Gegensatz zu RAID5/6 ist es umsonst.
Ich würde mich sehr freuen, wenn ich einige User, die bislang mit RAID noch nichts am Hut hatten für FlexRAID begeistern konnte.
Noch mehr würd es mich freuen, wenn auch ein paar alte RAID-Hasen wie ich den Umstieg wagen würden...
.
EDIT :
.
Als Nachteil könnte sich eine lange Berechnungsdauer für die Parity bei großen Datenmengen erweisen, aber dazu kann ich leider noch nichts sagen.... das steht mir noch bevor.
Bin mal gespannt wie schnell ein Parityupdate von 2TB Daten dauert, wenn nur einige GB geändert wurden seit dem letzten ParitySync
Zuletzt bearbeitet:
Dass man kein Backup mehr braucht ist aber ein Märchen.
Denn deine Daten zu zerballern geht nicht nur durch festplattenausfall.
Ein gut geschriebener, Bösartiger virus, Blitzeinschlag oder sonstwas und deine ganze maschine ist schrott, davor schützt dich auch kein RAID86
Denn deine Daten zu zerballern geht nicht nur durch festplattenausfall.
Ein gut geschriebener, Bösartiger virus, Blitzeinschlag oder sonstwas und deine ganze maschine ist schrott, davor schützt dich auch kein RAID86
Das ist zwar korrekt, die lebenswichtigen Daten wie private Bilder, Diplomarbeit, etc... sollte man immer zusätzlich backuppen.
Dennoch ist die Sicherheit von FlexRAID scheinbar deutlich höher als bei RAID5, da das RAID5 sich selbst der größte Feind ist.
Manchmal kommt es mir so vor: die meisten Daten gehen durch ein zerschossenes RAID verloren und nicht durch HDD-Defekte.
Und dann ist gleich alles weg...
Dennoch ist die Sicherheit von FlexRAID scheinbar deutlich höher als bei RAID5, da das RAID5 sich selbst der größte Feind ist.
Manchmal kommt es mir so vor: die meisten Daten gehen durch ein zerschossenes RAID verloren und nicht durch HDD-Defekte.
Und dann ist gleich alles weg...
JKuehl
Grand Admiral Special
Hört sich interessant an, halt uns auf dem laufenden!
Hier erstmal ein kleines Update.
Aktuell laufen bei mir 3 DRU's à 1TB und eine PPU1 mit 2TB.
Man kann quasi unendlich viele DRU's und PPU's verwenden.
Ich habe mich beim Verteilen der Daten auf die DRU's um eine möglichst ausgewogene Datenverteilung bemüht.
Aktuell lagert auf den DRU's jeweils 350-450GB, also insgesamt ca. 1,3TB "Nutzdaten".
Dementsprechend werden auf der PPU aktuell auch nur 450GB mit Paritydaten belegt, was ich für ein gutes Nutz-Waist-Verhältnis halte.
Sehr praktisch ist, dass ich nun auf der PPU (langsame Hitachi) zusätzlich ausreichend "unsicheren" Platz habe (1,3TB), wo meine TMP-Daten und sonstige Daten lagern, die nicht gebacken werden.
Zusätzlich verfüge ich noch über ein externes Einschub-Laufwerk mit 2TB als Datengrab, wo auch die WIRKLICH wichtigen Daten nochmals hin-und wieder draufgebackuppt werden.
M.E. ist das nur noch begrenzt nötig und beugt dem Totalausfall aller Platten gleichzeitig -etwa durch Blitzschlag, Netzteilversagen- vor.
Dieses GAU-Ereignis wird von zahlreichen Forenmitgliedern mal mehr mal weniger besserwisserisch millionenfach wiederholt wiederholt wiederholt, jedoch ist es scheinbar trotzdem ein extrem seltenes Ereignis.
Weder mir noch einem meiner Freunde/Bekannten/Verwandten ist soetwas jemals im Leben passiert.
Im Lotto gewonnen haben dagegen schon einige meiner Bekannten.
Meine "lebenswichtigen" Daten wie private Bilder und Filme werden zusätzlich einmal im Jahr auf eine Festplatte geschrieben und im Keller eingelagert.
Ich verwende dazu gerade die 250TB 1-platter-Laufwerke aus meinem RAID5 der vorletzten Generation.
Da diese als "letzte Datenbastion" hoffentlich nie wieder benutzt werden und zugleich ein Verkauf bei ebay nicht wirklich finanziell lohnt, erscheint mir diese Verwendung sehr angemessen.
Anwendungserfahrungen:
Positiv/Negativ:
Das Errechnen der Paritydaten aus ca. 1,3TB Nutzdaten ging überraschend flott vonstatten.
Was einen aber nicht mehr ganz so stark verwundert, wenn man bedenkt, dass bei der Parityberechnung immerhin von allen DRU's gleichzeitig gelesen wird und das Schreiben der Parity dann auf wieder einem anderen LW erfolgt.
Das man überhaupt Zeit zum Parityerrechnen benötigt ist natürlich dennoch ggü. klass. RAID5 ein Nachteil.
Wie lange es ging kann ich leider nicht genau sagen, da ich mit einer längeren Laufzeit gerechnet hatte: um 17:00 habe ich gestartet und um 20:30 wars fertig, wobei ich vorher nicht nachgeschaut habe, da ich unterwegs war.
Künftige Updates werden nochmals deutlich schneller gehen, abhängig davon, wie viele Änderungen an den Daten zu berücksichtigen sind.
Unpraktisch fand ich, dass es keine Fortschrittsanzeige gibt.
Nichts... einfach nur eine rotierende "ich bin nicht abgestürzt"- Anzeige.
Positiv:
Es wird immer nur das Laufwerk aus dem idle geholt, mit dem gearbeitet wird.
Hat man z.B. einen längeren Download am laufen, dann gehen alle LW ins idle bis auf eins.
Ggü. RAID5 eine Strom-/ Lärmersparnis und auf Dauer sehr LW-schonend bei 24/7-PC's.
Ich habe versucht es so einzurichten, dass meine PPU (green) für die Dauertätigkeiten verantwortlich ist.
So geht's weiter:
Meine wichtigen Daten organisiere ich gerade nach Jahren.
Quasi z.B. Ordner "Bildersammlung" mit Inhalt 2005, 2006, 2007, etc...
Diese Struktur ergibt Sinn im SNAPSHOT-flexRAID, da sich die Daten i.d. "alten Ordnern" nicht mehr verändern.
Für den Ordner mit wichtigem Inhalt, der sich regelmäßig ändert, also "2011",...
werde ich ein kleines zusätzliches REALTIME-flexRaid einrichten.
Darüber dann mehr, sobald es bei mir soweit ist...
Soviel vorweg:
das REALTIME-Raid wird sicherlich ein eher kleines Volumen umfassen.
Das hat einige weitere Vorteile!!
1. Die aktuellen Daten sind dann automatisch doppelt gesichert: einmal realtime und ZUSÄTZLICH noch im Snapshot in einer "alten Version"
2. Man kann einfach bestimmen welche EINZELNEN Ordner (Desktop, Email, etc..) oder Dateien Teil des REALTIME-RAID's werden sollen. Dann gibt man einen Ordner an, in dem die Parityinfo gespeichert werden sollen.
Das ist m.E. extrem fortschrittlich...
Ich weiß noch, wie umständlich immer ein Umzug meines RAID5 auf ein neues RAID5 im selben Rechner war. Da gabs immer keine andere Hoffnung, als alle Daten des alten R5 auf extra angeschafften GROßEN Platten und zahlreichen Kleinen zwischenzulagern, das alte R5 raus, neues R5 anlegen und die Daten wieder einspielen.
Das Gefrickel wirds künftig nicht mehr geben.
Aktuell laufen bei mir 3 DRU's à 1TB und eine PPU1 mit 2TB.
Man kann quasi unendlich viele DRU's und PPU's verwenden.
Ich habe mich beim Verteilen der Daten auf die DRU's um eine möglichst ausgewogene Datenverteilung bemüht.
Aktuell lagert auf den DRU's jeweils 350-450GB, also insgesamt ca. 1,3TB "Nutzdaten".
Dementsprechend werden auf der PPU aktuell auch nur 450GB mit Paritydaten belegt, was ich für ein gutes Nutz-Waist-Verhältnis halte.
Sehr praktisch ist, dass ich nun auf der PPU (langsame Hitachi) zusätzlich ausreichend "unsicheren" Platz habe (1,3TB), wo meine TMP-Daten und sonstige Daten lagern, die nicht gebacken werden.
Zusätzlich verfüge ich noch über ein externes Einschub-Laufwerk mit 2TB als Datengrab, wo auch die WIRKLICH wichtigen Daten nochmals hin-und wieder draufgebackuppt werden.
M.E. ist das nur noch begrenzt nötig und beugt dem Totalausfall aller Platten gleichzeitig -etwa durch Blitzschlag, Netzteilversagen- vor.
Dieses GAU-Ereignis wird von zahlreichen Forenmitgliedern mal mehr mal weniger besserwisserisch millionenfach wiederholt wiederholt wiederholt, jedoch ist es scheinbar trotzdem ein extrem seltenes Ereignis.
Weder mir noch einem meiner Freunde/Bekannten/Verwandten ist soetwas jemals im Leben passiert.
Im Lotto gewonnen haben dagegen schon einige meiner Bekannten.
Meine "lebenswichtigen" Daten wie private Bilder und Filme werden zusätzlich einmal im Jahr auf eine Festplatte geschrieben und im Keller eingelagert.
Ich verwende dazu gerade die 250TB 1-platter-Laufwerke aus meinem RAID5 der vorletzten Generation.
Da diese als "letzte Datenbastion" hoffentlich nie wieder benutzt werden und zugleich ein Verkauf bei ebay nicht wirklich finanziell lohnt, erscheint mir diese Verwendung sehr angemessen.
Anwendungserfahrungen:
Positiv/Negativ:
Das Errechnen der Paritydaten aus ca. 1,3TB Nutzdaten ging überraschend flott vonstatten.
Was einen aber nicht mehr ganz so stark verwundert, wenn man bedenkt, dass bei der Parityberechnung immerhin von allen DRU's gleichzeitig gelesen wird und das Schreiben der Parity dann auf wieder einem anderen LW erfolgt.
Das man überhaupt Zeit zum Parityerrechnen benötigt ist natürlich dennoch ggü. klass. RAID5 ein Nachteil.
Wie lange es ging kann ich leider nicht genau sagen, da ich mit einer längeren Laufzeit gerechnet hatte: um 17:00 habe ich gestartet und um 20:30 wars fertig, wobei ich vorher nicht nachgeschaut habe, da ich unterwegs war.
Künftige Updates werden nochmals deutlich schneller gehen, abhängig davon, wie viele Änderungen an den Daten zu berücksichtigen sind.
Unpraktisch fand ich, dass es keine Fortschrittsanzeige gibt.
Nichts... einfach nur eine rotierende "ich bin nicht abgestürzt"- Anzeige.
Positiv:
Es wird immer nur das Laufwerk aus dem idle geholt, mit dem gearbeitet wird.
Hat man z.B. einen längeren Download am laufen, dann gehen alle LW ins idle bis auf eins.
Ggü. RAID5 eine Strom-/ Lärmersparnis und auf Dauer sehr LW-schonend bei 24/7-PC's.
Ich habe versucht es so einzurichten, dass meine PPU (green) für die Dauertätigkeiten verantwortlich ist.
So geht's weiter:
Meine wichtigen Daten organisiere ich gerade nach Jahren.
Quasi z.B. Ordner "Bildersammlung" mit Inhalt 2005, 2006, 2007, etc...
Diese Struktur ergibt Sinn im SNAPSHOT-flexRAID, da sich die Daten i.d. "alten Ordnern" nicht mehr verändern.
Für den Ordner mit wichtigem Inhalt, der sich regelmäßig ändert, also "2011",...
werde ich ein kleines zusätzliches REALTIME-flexRaid einrichten.Darüber dann mehr, sobald es bei mir soweit ist...
Soviel vorweg:
das REALTIME-Raid wird sicherlich ein eher kleines Volumen umfassen.
Das hat einige weitere Vorteile!!
1. Die aktuellen Daten sind dann automatisch doppelt gesichert: einmal realtime und ZUSÄTZLICH noch im Snapshot in einer "alten Version"
2. Man kann einfach bestimmen welche EINZELNEN Ordner (Desktop, Email, etc..) oder Dateien Teil des REALTIME-RAID's werden sollen. Dann gibt man einen Ordner an, in dem die Parityinfo gespeichert werden sollen.
Das ist m.E. extrem fortschrittlich...
Ich weiß noch, wie umständlich immer ein Umzug meines RAID5 auf ein neues RAID5 im selben Rechner war. Da gabs immer keine andere Hoffnung, als alle Daten des alten R5 auf extra angeschafften GROßEN Platten und zahlreichen Kleinen zwischenzulagern, das alte R5 raus, neues R5 anlegen und die Daten wieder einspielen.
Das Gefrickel wirds künftig nicht mehr geben.
Zuletzt bearbeitet:
Stimmt,... ich vergleiche es mit RAID5.
Aber -wie du sagst- es ist eigendlich ähnlicher dem Raid 4.
Vermutlich weil es sich historisch so ergab, dass ich zuerst RAID5 verwendet habe und weil RAID5 m.E. auch "Konkurrent" des flexRAIDs ist.
Zumindest für normale Heimanwender.
In einem Firmenumfeld ist flexRAID vorerst sicherlich keine Alternative.
Ich bin mir nicht ganz sicher, welche Form von Benchmarks du gerne sehen würdest?
Das flexRAID ist ja nicht auf Performance optimiert.
Im Alltag arbeitet man mit normalen Einzelplatten, so würden dann auch die Schreib-/Lesewerte ausfallen.
Aber -wie du sagst- es ist eigendlich ähnlicher dem Raid 4.
Vermutlich weil es sich historisch so ergab, dass ich zuerst RAID5 verwendet habe und weil RAID5 m.E. auch "Konkurrent" des flexRAIDs ist.
Zumindest für normale Heimanwender.
In einem Firmenumfeld ist flexRAID vorerst sicherlich keine Alternative.
Ich bin mir nicht ganz sicher, welche Form von Benchmarks du gerne sehen würdest?
Das flexRAID ist ja nicht auf Performance optimiert.
Im Alltag arbeitet man mit normalen Einzelplatten, so würden dann auch die Schreib-/Lesewerte ausfallen.
Trotzdem wären Tests interessant wird der Speed einer Platte negativ beeinflusst, weil auf die Parity-Platte gewartet werden muss und wieviel CPU last erzeugt dies?!
JKuehl
Grand Admiral Special
Es wird nicht "auf Parity gewartet". Beim Lesen verhalten sich alle Platten als wären diese ohne Parity / Flexraid im Einsatz.
ghostadmin
Grand Admiral Special
Höchst unwahrscheinlich. In der Regel gehen nur ungeschriebene Daten aus dem Cache verloren, die noch nicht geschrieben wurden.
Flexraid wird aber auch nicht davor schützen wenn der Controller Mist auf alle Platten schreibt und das ist der Hauptgrund für Versagen bei anderen RAID Level.
Naja, das ist tatsächlich etwas weit heruas gewagt gewesen.
Ich mache auch weiterhin Backups von meinen Bildern.
Aber selbst die sind nicht sicher, weil es immer wieder vorkommt, dass das Original auf den Originalplatten korrumpiert vorliegt ohne dass man es bemerkt.
Das geht dann auch in die Richtung, die du jetzt vermutlich meintest?
Diese Daten werden dann eben auch korrumpiert gesichert.
Komplette Sicherheit hat man eben leider nicht.
Ich mache auch weiterhin Backups von meinen Bildern.
Aber selbst die sind nicht sicher, weil es immer wieder vorkommt, dass das Original auf den Originalplatten korrumpiert vorliegt ohne dass man es bemerkt.
Das geht dann auch in die Richtung, die du jetzt vermutlich meintest?
Diese Daten werden dann eben auch korrumpiert gesichert.
Komplette Sicherheit hat man eben leider nicht.
ghostadmin
Grand Admiral Special
Ja bei normalen RAID hat man immer die Unsicherheit das der Controller alle Daten schrotten kann, weil er das Dateisystem nicht kennt. Ich hatte da schon üble Korruption erlebt die schleichend erfolgte und dann irgendwann nach einem Reboot alles komplett weg war.
Deswegen präferiere ich auch ZFS, das von allen Files eine chksum hat und mir nicht alles vermurksen kann.
Deswegen präferiere ich auch ZFS, das von allen Files eine chksum hat und mir nicht alles vermurksen kann.
tomturbo
Technische Administration, Dinosaurier
Die checksum ändert am Vermurksen nichts, sie zeigt lediglich zunächst an, dass etwas passierte.
Es muss nicht sein, dass die Datei wiederhergestellt werden kann.
lg
__tom
ghostadmin
Grand Admiral Special
ZFS kennt den Normalzustand der Datei, RAID nicht.
Bei ZFS kannste sogar direkt auf eine einzelne Disk schreiben ohne das es was zerschiesst.
http://hub.opensolaris.org/bin/view/Community+Group+zfs/selfheal
2x habe ich RAID schon sterben gesehen. Einmal wars ein Controller der Murks auf alle Platten geschrieben hat und beim anderen mal war der Link bei Fibrechannel kurz weg, dass hat bereits ausgereicht.
Bei ZFS kannste sogar direkt auf eine einzelne Disk schreiben ohne das es was zerschiesst.
http://hub.opensolaris.org/bin/view/Community+Group+zfs/selfheal
2x habe ich RAID schon sterben gesehen. Einmal wars ein Controller der Murks auf alle Platten geschrieben hat und beim anderen mal war der Link bei Fibrechannel kurz weg, dass hat bereits ausgereicht.
Zuletzt bearbeitet:
tomturbo
Technische Administration, Dinosaurier
Alles schön und gut. Offenbar hast Du noch nie ein zerschossenes ZFS gehabt.
Ich sehr wohl.
Es bleibt bei dem Fakt, dass eine Checksumme nur eine Checksumme ist.
Sobald keine Redundanz da ist oder diese nicht verwendet werden kann, weil der Controller Unsinn machte, nutzt das ganze gar nichts.
"scrubben" kann man unter Linux übrigens auch und auch dort werden die Redundanzen für fehlerhafte Blöcke dann hergenommen um Blöcke wiederherzustellen.
Nutzt halt genauso nix wenn der Controller Unsinn macht.
Ich sehr wohl.
Es bleibt bei dem Fakt, dass eine Checksumme nur eine Checksumme ist.
Sobald keine Redundanz da ist oder diese nicht verwendet werden kann, weil der Controller Unsinn machte, nutzt das ganze gar nichts.
"scrubben" kann man unter Linux übrigens auch und auch dort werden die Redundanzen für fehlerhafte Blöcke dann hergenommen um Blöcke wiederherzustellen.
Nutzt halt genauso nix wenn der Controller Unsinn macht.
PuckPoltergeist
Grand Admiral Special
Ist auch ein Nachteil -> siehe RAID4. Das wurde auch zu RAID5 weiter entwickelt, um die ungleichmäßige Belastung der Platten zu verringern.
Wie du selber schon festgestellt hast, ist das schlicht falsch.
Das soll bitte wie funktionieren? So wie du das hier erklärst, hast du Informationsverlust. Da könnte ich genau so sagen, ich sichere meine Daten per Hashfunktion ab.
ghostadmin
Grand Admiral Special
Keine Dateiverwaltung ist perfekt aber wenn es Kenntnis von den darunterliegenden Dateien hat, ist es für mich einfach überlegende Technik. Netapp macht das so und Btfrs auch. Das ist einfach die nächste Generation an Filesystemen die das ganze noch sicherer machen.
Für neue Dateien mit einem korrupten Controller nutzen die Chksums natürlich nichts (obwohl man da auch schon Fehler sehen müsste) aber aber dafür werden die bestehenden Daten geschützt. Man bräuchte da ja nur einen Switch zu setzen das man keine neuen Files mehr annimmt wenn die Chksums nicht mehr stimmen.
tomturbo
Technische Administration, Dinosaurier
Den Checksummenfehler sehe ich aber auch bei ZFS leider erst wenn es zu spät ist, nämlich wenn die Datei angegriffen wird. Es bedeutet also keinen Mehrwert indem schlicht ein counter erhöht wird, denn die Datei wäre mit oder ohne Checksumme defekt gewesen. Scrubbing zum Erkennen von Fehlern geht wie gesagt auch ohne Checksumme auf Dateiebene. Und nur weil's alle machen bedeutet das nicht unbedingt eine Verbesserung.
Nach dem Motto: Milliarden Fliegen können nicht irren, Scheiße ist gut
Nach dem Motto: Milliarden Fliegen können nicht irren, Scheiße ist gut
PuckPoltergeist
Grand Admiral Special
Tun sie, es sei den der Fehler im Controller modifiziert auch die Checksummen derart, dass die Modifikation nicht auffällt. Die Wahrscheinlichkeit dafür ist sehr sehr gering.
Und Tom, Checksummen alleine bringen wenig Nutzen, das stimmt. Aber sie werden ja auch nicht alleine eingesetzt, sondern zusammen mit der Redundanz. Und da bringen sie dann sehr viel, weil sie Datenkorruption nicht nur sehr frühzeitig entdecken, sondern diese gleich beseitigt wird.
tomturbo
Technische Administration, Dinosaurier
Das ist mir klar.
Wie gesagt kann ich das durch aktives scrubben auch und dabei erkenne und beseitige ich Fehler gleich und nicht erst wenn ich die Datei angreife.
Ich halte damit sozusagen den Stall permanent sauber.
Was mir persönlich lieber ist.
Ob ich dabei auf Dateichecksummen zurückgreife oder Datenblockchecksummen ist eigentlich egal.
Wobei Dateichecksummen wahrscheinlich bei 4k Blöcken irgendwann ineffizienter, weil viel mehr, sind.
Ein mal pro Woche ein: 'echo "check" > /sys/block/md127/md/sync_action' und gut is.
lg
__tom
yourgreatestfear
Grand Admiral Special
Kann mir nicht helfen, aber der einzige Vorteil eines FlexRAID den ich erkennen kann, ist die Lesbarkeit der Rohdaten falls eine PPU verloren geht. Vielleicht mags auch noch in der Administration einfach sein, ansonsten seh ich eher Nachteile.
Erweiterbarkeit, Kombination von unterschiedlichen Laufwerkstypen, Datenintegrität, Snapshots, Robustheit gegen Ausfälle auch ohne BBU, Kosten, Checksums, Transformation, etc. ... all das ist bei einem LinuxRAID abgedeckt. Allein die Komplexität der Kombinationen (inkl etwaiger Featureredundanzen) aus RAID, Dateisystemen und LVM ist wahrscheinlich die Hürde, an der die meisten scheitern.
PS: Ein RAID5 bei Stromausfall verstripen? Das passiert in einem SoftwareRAID wirklich nur bei falscher Konfiguration oder veralteten Dateisystemen drauf.
PS2: Fehler durch einen korrupten Controller sind auch in der Vergangenheit, dass sollte ein POST-Commit abfangen, solang aktuelles Dateisystem eingesetzt wird.
Erweiterbarkeit, Kombination von unterschiedlichen Laufwerkstypen, Datenintegrität, Snapshots, Robustheit gegen Ausfälle auch ohne BBU, Kosten, Checksums, Transformation, etc. ... all das ist bei einem LinuxRAID abgedeckt. Allein die Komplexität der Kombinationen (inkl etwaiger Featureredundanzen) aus RAID, Dateisystemen und LVM ist wahrscheinlich die Hürde, an der die meisten scheitern.
PS: Ein RAID5 bei Stromausfall verstripen? Das passiert in einem SoftwareRAID wirklich nur bei falscher Konfiguration oder veralteten Dateisystemen drauf.
PS2: Fehler durch einen korrupten Controller sind auch in der Vergangenheit, dass sollte ein POST-Commit abfangen, solang aktuelles Dateisystem eingesetzt wird.
PuckPoltergeist
Grand Admiral Special
Kannst du doch bei ZFS auch. Und zusätzlich hast du den Vorteil, dass Fehler zwischen den Scrubb-Vorgängen auch noch erfasst werden. Verstehe jetzt deine Ablehnung nicht.
Und das erkennt jetzt wie, welches der korrekte Datenblock ist? MD-RAID stellt keine Datenintegrität sicher. Wird es nach Neil Brown auch nie, weil es nicht die Aufgabe ist.
ghostadmin
Grand Admiral Special
Dein RAID kennt aber eben nicht das Filesystem. Da braucht nur 1 Bit falsch sein und es würfelt dir alles munter zusammen.
http://www.zdnet.com/blog/storage/data-corruption-is-worse-than-you-know/191
In der Praxis fällt ein einzelnes Bit nicht so auf, aber wenn z.B. die MFT betroffen ist, kann das übel werden.
