sandman85
Anmeldungsdatum: 1. Januar 2018
Beiträge: Zähle...
|
Hallo zusammen! Ich bin aktuell dabei, für unseren Haushalt ein neues NAS System aufzubauen. Die Eckdaten sind wie folgt:
Hardware besteht aus M-ITX Board mit Pentium G4600 CPU und 8GB Ram 128GB SSD für das System 3x6TB als Datenpool sollen als Raid 5 konfiguriert werden Eine kleine USV ist vorhanden
Als System möchte ich Ubuntu einsetzen und nicht auf eine der gängigen NAS Distros setzen. Im Moment tendiere ich zu Ubuntu Server 16.04 LTS. Die Fragen, die ich mir stellen fangen nun beim Dateisystem an und ich hoffe, ihr könnt mir ein wenig weiterhelfen ☺
Ich würde für den Datenpool gerne BTRFS verwenden, da es als modernes Dateisystem ggü ext4 schon einige Vorteile bietet (CoW, Snapshots...). Ich habe mir das ganze mal vorab in einer virtuellen Maschine angesehen und folgende Konfigurationen untersucht:
Raid 5 aus 3 virtuellen Platten mittels mdadm erstellt und dann darauf eine Btrfs Partition erstellt
2. Integrierte Raid Funktionen von BTRFS verwendet um das Szenario von 1) abzubilden Dabei ist mir u.a. aufgefallen, dass die Schreibperformance bei Verwendung der integrierten Raid 5 Funktionen von BTRFS deutlich besser war und die CPU Auslastung dabei geringer war, als mit Szenario 1. Getestet habe ich das hauptsächlich mit großen Dateien. Jetzt ist es ja so, dass die Raid56 Funktionen von BTRFS als "unstable" deklariert sind (https://btrfs.wiki.kernel.org/index.php/RAID56), bzw. ab Kernel 4.12 wohl als "Mostly OK", was aber nach meinem Verständnis ausschließlich an dem Problem "Write-hole" bei Stromausfall o.ä. liegt. Ist es aber nicht so, dass es auch bei Verwendung der Kernel Raid Funktionen über mdadm bei einem Stromausfall zu einem Write Hole kommen kann?
Sprich, wie schätzt ihr die Verwendung der BTRFS Raid Funktionen bei Vorhandensein einer USV ein? Macht BTRFS überhaupt schon Sinn, oder lieber doch noch auf ext4 setzten? Viele Grüße
Sandman
|
encbladexp
Ehemaliger
Anmeldungsdatum: 16. Februar 2007
Beiträge: 17448
|
sandman85 schrieb: Ich würde für den Datenpool gerne BTRFS verwenden, da es als modernes Dateisystem ggü ext4 schon einige Vorteile bietet (CoW, Snapshots...). Ich habe mir das ganze mal vorab in einer virtuellen Maschine angesehen und folgende Konfigurationen untersucht:
Raid 5 aus 3 virtuellen Platten mittels mdadm erstellt und dann darauf eine Btrfs Partition erstellt
2. Integrierte Raid Funktionen von BTRFS verwendet um das Szenario von 1) abzubilden
Generell hast du bei 3x6TB diese Möglichkeiten:
RAID5 auf Basis von mdadm, also die "So wie früher Edition", größter Nachteil ist das bei Ausfall einer Platte die kompletten 6TB für eine Ersatzplatte unabhängig von der genutzten Kapazität gesynct werden müssen und das es keine Bit Rot Detection gibt. (Das Dateisystem oben drauf ignoriere ich jetzt mal gekonnt.) RAID5 auf Basis von btrfs, das ist "Geiler heißer scheiß", größter Nachteil ist das btrfs laut eigener Aussage noch nicht Stabil ist. RAID5 auf Basis von ZFS, nicht mehr ganz so frisch wie btrfs aber halt ein Fremdkörper unter Linux. Dafür recht stabil und viele Vorteile die auch btrfs bietet, dazu die Möglichkeit die SSD für Performanceprobleme mit zu integrieren in den Verbund.
Ist es aber nicht so, dass es auch bei Verwendung der Kernel Raid Funktionen über mdadm bei einem Stromausfall zu einem Write Hole kommen kann?
Korrekt, das ist ein generelles Problem einer normalen RAID Implementierung. Linux unterstützt aber ab Kernel 4.4 ein "Write Journal", so das auch hier das Problem nicht mehr vorhanden ist. Sieh dir hierzu mal die Manpage von md an, da steht drin was mittlerweile alles möglich ist.
Sprich, wie schätzt ihr die Verwendung der BTRFS Raid Funktionen bei Vorhandensein einer USV ein? Macht BTRFS überhaupt schon Sinn, oder lieber doch noch auf ext4 setzten?
Mein Homeserver, und auch meine ganzen Desktops, laufen schon seit >2 Jahren komplett auf btrfs. Wenn es wichtige Daten sind, dann hast du Backups, dann kannst du auch btrfs nehmen wenn du Spielen möchtest. ZFS ist in Ubuntu gut integriert, aber eben kein Standard unter Linux und somit ein Fremdkörper (IMHO, wenn auch gut funktionieren!). Das gute alte mdadm haut was Features, trotz der versteckten Möglichkeiten, niemanden mehr wirklich vom Hocker, ist dafür aber Stabil und von vielen für gut befunden. Der größte Vorteil von btrfs und/oder ZFS als RAID ist die Erkennung von Bit Rot, ein Thema für große Platten/Volumes, und die automatische Korrektur dieser. Als leckerli bekommst du bei beiden Snapshots und viele andere Features. Von was für Daten reden wir überhaupt? mfg Stefan
|
u1000
Anmeldungsdatum: 2. Oktober 2011
Beiträge: 1850
|
Noch ein Denkanstoss, Sandman: Entscheide dich für die Lösung, die du 100% verstehst und auch im Fehlerfall 100% beherrschst, um ggf. einen Fehler zu finden und zu beheben. Eine ganz einfache Lösung könnte auch bedeuten: du verwendest die drei 6TB einzeln + ganz normal mit ext4, kein RAID, kein BTRFS. Du machst selbst z.B. täglich Backups (voll/inkr/diff) von der 1. HD auf die 2. HD (beide intern), und verwendest die 3. HD (extern) nur einmal pro Woche fürs ausgelagerte Backup.
|
encbladexp
Ehemaliger
Anmeldungsdatum: 16. Februar 2007
Beiträge: 17448
|
u1000 schrieb: …Du machst selbst z.B. täglich Backups (voll/inkr/diff) von der 1. HD auf die 2. HD (beide intern), und verwendest die 3. HD (extern) nur einmal pro Woche fürs ausgelagerte Backup.
Mit der Konsequenz das er statt 12TB nutzbarem Platz (netto) nur noch 6TB nutzbaren Platz (netto) hat. mfg Stefan
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7657
|
sandman85 schrieb: Dabei ist mir u.a. aufgefallen, dass die Schreibperformance bei Verwendung der integrierten Raid 5 Funktionen von BTRFS deutlich besser war und die CPU Auslastung dabei geringer war, als mit Szenario 1.
Bei einem reinen NAS spielt Performanz, insb. Schreibperformanz meist nur zweite Geige, wenn überhaupt...
Sprich, wie schätzt ihr die Verwendung der BTRFS Raid Funktionen bei Vorhandensein einer USV ein? Macht BTRFS überhaupt schon Sinn, oder lieber doch noch auf ext4 setzten?
Das ist Geschmackssache. Ich fühle mich bei den traditionellen Dateisystemen gut aufgehoben und glaube nicht an Bitrot. Solange die Festplatte ordnungsgemäß Lesefehler meldet, kümmert sich das reguläre RAID darum (und Festplatten, die da auffällig sind, sollten ausgetauscht werden.)
Entscheide dich für die Lösung, die du 100% verstehst und auch im Fehlerfall 100% beherrschst, um ggf. einen Fehler zu finden und zu beheben.
Ansonsten lieber gleich fragen und nicht erst kommen wenn du das RAID totexperimentiert hast. Viele Blogs empfehlen mdadm --create zur Lösung von RAID-Problemen. Das klappt aber nur wenn man wirklich 140% verstanden hat was da passiert, ansonsten ist mdadm --create wie mkfs: hinterher sind keine Daten zu erwarten. Das wichtigste ist aber Smartmontools einrichten, regelmäßige Festplattenchecks durchführen, sonst bleiben Festplattenfehler jahrelang unentdeckt und brechen dir dann beim Rebuild das Genick. Und bei Problemen dann auch tatsächlich die Platten tauschen, nicht mit defekten Sektoren weiterlaufen lassen. Das Redundanzversprechen von RAID geht immer von 100% funktionstüchtigen Platten aus, was bei Reallokierten Sektoren usw. halt nicht mehr der Fall ist, das ist dann Glücksspiel.
|
sandman85
(Themenstarter)
Anmeldungsdatum: 1. Januar 2018
Beiträge: 13
|
Hallo zusammen, vielen Dank erstmal für den ganzen Input.
Der Typus der Daten, welche auf dem NAS gespeichert werden, ist etwas gemischt. Zum einen sind das Backups von diversen Rechnern, welche hier bei uns im Heimnetz so "rumhängen". Dabei sind durchaus wichtigere Daten dabei, wie Bank-, Arzt- und Versicherungsdokumente, Familienbilder etc.. Abgesehen davon würde ich mich selbst als ambitionierten Amateurfotograf bezeichnen und meine gesamten Bilder (und Videos) werden ebenfalls dort gespeichert werden. Auch diese sollten nach Möglichkeit nicht verloren gehen. Weiter wird das NAS noch als zentrale Sammelstelle für weitere Medien wie aufgenommene Fernsehsendungen, Kopien meiner Blu-Ray Sammlung usw. dienen. Diese Daten wären bei einem Ausfall größtenteils natürlich nicht unwiederbringlich, aber der Aufwand wäre schon relativ groß. Von daher sollen diese Daten auch auf einem Raid 5 liegen, um wenigsten mit hoher Wahrscheinlichkeit gegen Festplattenausfall geschützt zu sein... ZFS fand ich zunächst auch sehr interessant, bin aber zu dem Schluss gekommen, dass es für den Hausgebrauch einfach "Overkill" ist, und dadurch, dass ein bestehender Pool nicht erweitert werden kann, sind die Kosten für ein späteres Speicherupgrade einfach zu hoch. So bin ich dann eigentlich bei BTRFS hängen geblieben, da dieses ja ein ähnliches Featureset bietet. encbladexp schrieb: Generell hast du bei 3x6TB diese Möglichkeiten:
RAID5 auf Basis von mdadm, also die "So wie früher Edition", größter Nachteil ist das bei Ausfall einer Platte die kompletten 6TB für eine Ersatzplatte unabhängig von der genutzten Kapazität gesynct werden müssen und das es keine Bit Rot Detection gibt. (Das Dateisystem oben drauf ignoriere ich jetzt mal gekonnt.)
2. RAID5 auf Basis von btrfs, das ist "Geiler heißer scheiß", größter Nachteil ist das btrfs laut eigener Aussage noch nicht Stabil ist.
3. RAID5 auf Basis von ZFS, nicht mehr ganz so frisch wie btrfs aber halt ein Fremdkörper unter Linux. Dafür recht stabil und viele Vorteile die auch btrfs bietet, dazu die Möglichkeit die SSD für Performanceprobleme mit zu integrieren in den Verbund.
Ich denke, aktuell tendiere ich zu der Variante 1., in Kombination mit einem darauf aufgesetzten BTRFS. Damit hätte ich eigentlich alle Vorteile von BTRFS, oder? Übersehe ich signifikante Nachteile? encbladexp schrieb: Linux unterstützt aber ab Kernel 4.4 ein "Write Journal", so das auch hier das Problem nicht mehr vorhanden ist. Sieh dir hierzu mal die Manpage von md an, da steht drin was mittlerweile alles möglich ist.
Danke für den Hinweis. Da werde ich mich in den kommenden Tagen mal durchwälzen. Btw.: Bei der Geschichte mit dem Bit-Rot bin ich noch nicht ganz durchgestiegen. Allerdings setze ich bei meinem NAS kein ECC RAM ein. Von daher frage ich mich, ob ZFS oder BTRFS ihre Bit-Rot-Detection Möglichkeiten überhaupt ausspielen könnten? frostschutz schrieb: Das wichtigste ist aber Smartmontools einrichten, regelmäßige Festplattenchecks durchführen, sonst bleiben Festplattenfehler jahrelang unentdeckt und brechen dir dann beim Rebuild das Genick. Und bei Problemen dann auch tatsächlich die Platten tauschen, nicht mit defekten Sektoren weiterlaufen lassen. Das Redundanzversprechen von RAID geht immer von 100% funktionstüchtigen Platten aus, was bei Reallokierten Sektoren usw. halt nicht mehr der Fall ist, das ist dann Glücksspiel.
Super, danke für den Tipp 👍 Viele Grüße,
Sandman
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7657
|
sandman85 schrieb: Abgesehen davon würde ich mich selbst als ambitionierten Amateurfotograf bezeichnen und meine gesamten Bilder (und Videos) werden ebenfalls dort gespeichert werden. Auch diese sollten nach Möglichkeit nicht verloren gehen.
Was nicht verloren gehen soll, muss doppelt und dreifach gesichert werden. Also nicht nur auf dem NAS sondern auch noch auf weiteren Geräten/Speichermedien. Also z.B. auf dem PC, auf dem NAS und nochmal auf einer externen Platte. Aber gerade bei Fotos usw. empfehle ich auch - zusätzlich - die guten alten Rohlinge über die so gern die Nase gerümpft wird. Einmal geschossene Fotos werden nie mehr verändert - ideal zum runterbrennen. Bei optimaler Lagerung (geschützt vor Wasser, Licht und Luft, also in der Schuhschachtel im Schrank) halten die Dinger 10 Jahre, und überleben viel was Festplatten prinzipbedingt nicht überstehen können (ein durchgebranntes Netzteil / ein Blitzschlag - alle Festplatten auf einmal tot) und ist durch die Nicht-Wiederbeschreibbarkeit auch vor amoklaufender Software geschützt (die Fotoalbumsoftware, die alle Bilder auf einmal zersägt, hats leider auch schon gegeben).
Von daher sollen diese Daten auch auf einem Raid 5 liegen, um wenigsten mit hoher Wahrscheinlichkeit gegen Festplattenausfall geschützt zu sein...
Solange man die Festplatten ordentlich testet und bei Auffälligkeiten tatsächlich in den sauren Apfel beißt und die Platte frühzeitig tauscht, hast du diese hohe Wahrscheinlichkeit. Die meisten Leute die mit defekten RAID in Foren/Mailinglisten aufschlagen, haben das Ding jahrelang laufen lassen und nie danach geschaut. ( aktuell hier so ein Pechvogel https://forum.ubuntuusers.de/topic/raid1-synchronisierung-datenverlust/ ) Monitoring und Mailbenachrichtigung ist das A und O nicht nur bei RAID sondern eben bei allem was mit Festplatten zu tun hat. Die Dinger gehen nun mal schleichend kaputt.
Allerdings setze ich bei meinem NAS kein ECC RAM ein.
Macht auch sonst niemand im privaten Umfeld. Bei Consumer-Hardware ist ECC nun mal unüblich. Wenns anders wäre, gäbs seit Jahrzehnten gar keinen Nicht-ECC-RAM mehr. Wenn man eine neue Maschine in Betrieb nimmt, (und streng genommen auch bei jedem Umbau/jeder Konfigurationsänderung) gehört es dazu, einen memtest zu machen - auch bei ECC denn wenn ständig ECC Meldungen kommen, gehört das RAM Modul auch getauscht. Ein ECC Modul das nur dank EEC weiter funktioniert, ist genauso sinnlos wie ein RAID ohne Redundanz.
|
u1000
Anmeldungsdatum: 2. Oktober 2011
Beiträge: 1850
|
wie frostschutz schon erwähnt hat, ein RAID ersetzt kein Backup Plan!
Bei einem "Unfall" mit deinem NAS können alle 3 Platten zusammen kaputt gehen, auch ein Crypto-Dings kann dir alles zerstören (z.B. von einem Win Rechner im LAN) - in beiden Fällen hilft dir kein RAID sondern nur Backups.
|
encbladexp
Ehemaliger
Anmeldungsdatum: 16. Februar 2007
Beiträge: 17448
|
sandman85 schrieb: Von daher sollen diese Daten auch auf einem Raid 5 liegen, um wenigsten mit hoher Wahrscheinlichkeit gegen Festplattenausfall geschützt zu sein...
Wie man dir schon gesagt hat: Du brauchst funktionierende Backups deiner Daten, RAID ist nur eine Kompensation für den Ausfall einer Platte bei dem das System weiterhin Online verfügbar sein soll.
So bin ich dann eigentlich bei BTRFS hängen geblieben, da dieses ja ein ähnliches Featureset bietet.
Ja, btrfs ist hier sehr flexibel, aber teilweise eben noch beta. Bei btrfs würde ich auch eher zu Arch Linux oder Ubuntu mit einem aktuellen Kernel raten, denn es passiert viel 😉
Ich denke, aktuell tendiere ich zu der Variante 1., in Kombination mit einem darauf aufgesetzten BTRFS. Damit hätte ich eigentlich alle Vorteile von BTRFS, oder? Übersehe ich signifikante Nachteile?
Du hast ein btrfs das sich nicht selbst heilen kann, da die Daten ja nur einfach auf der Platte liegen. Es erkennt zwar Fehler wie Bit Rot, kann diese aber mangels funktionsfähiger Kopie der Daten nicht fixen. Technisch ist es aber auch möglich, es ist aber keine Win-Win Situation.
Von daher frage ich mich, ob ZFS oder BTRFS ihre Bit-Rot-Detection Möglichkeiten überhaupt ausspielen könnten?
Bit Rot ist ein statisches Spiel mit großen Zahlen bei großen Datenmengen. Die Idee bei ECC RAM ist kippende Bits im RAM zu vermeiden, das ergänzt ein taugliches Dateisystem passend, es ist aber nicht zwingend notwendig. Bit Rot oder kaputt gelesene Sektoren kann ein btrfs / ZFS fixen sofern hier genug Redundanz vorhanden ist. Moderne Platten haben aber auch schon sehr viel Fehlerkorrektur eingebaut, die Berichte wie schlimm Bit Rot als Problem überhaupt ist gehen stark auseinander. mfg Stefan
|