Hallo Kollegen,
bitte fragt nicht nach dem Grund, aber ich habe Privat eine Menge Daten zu beherbergen. Derzeitige Größenordnung etwa 30TB.
Ich hatte bisher durch ein Konglomerat von 2TB / 3TB und 4TB Platten ein Software-RAID (raid 6) aufgebaut und darauf xfs. Früher hatte ich reiserfs auf meinen Systemen, bin dann aber später auf xfs bzw. ext4 gewandert. Auf diesen Dateisystemen habe ich also eine gewisse Erfahrung.
Zielstellung: ich habe derzeit 5 10TB Festplatten und möchte aus diesen einen Ersatz für mein System bauen (bei 5 Platten komme ich mit RAID 5 noch klar, kann aber auch RAID 6 nutzen). Nur suche und suche ich nach den besten Möglichkeiten und brauche ein paar neue Anreize.
Probleme in der Vergangenheit: Ich habe schnell merken müssen, dass wenn man die 16TB Grenze verlässt, man gewissen Einschränkungen hat. Vergrößern ist beispielsweise seitens ext4 meines Wissens nach nicht mehr möglich. Einmal eingerichtet steht die Größe. Ich hatte zwischenzeitlich auch schon mit FreeNAS und zfs geliebäugelt, aber die Tatsache, dass man einen Pool durch hinzufügen weiterer Platten nicht vergrößern kann, schreckt mich nun ab. Daher meine Frage an Euch: habt Ihr Ideen?
folgende Anforderungen: * RAID Funktionalität (RAID 5 / RAID 6 ggf. auch konvertierbar) * RAID Vergrößerung (hinzufügen einer weiteren Platte identischer Größe) sollte machbar sein * Dateisystem sollte online erweiterbar sein (hinzufügen einer Platte) * optional: Snapshot funktionalität
Ich hab jetzt BTRFS versucht, das sieht gar nicht so schlecht aus, aber ich habe die oben genannten Punkte noch nicht testen können. Aber die Aussagen über BTRFS scheinen vielversprechend (mit Ausnahme, dass RHEL btrfs aus seinem Repertoire genommen hat).
Jemand eine Idee?
Als absolutes Bonbon wäre noch, dass man, wie bei ZFS (unter Freenas) durch den Austausch der Festplatten von derzeit 10TB auf sagen wir 20TB Platten) das RAID ebenfalls vergrößern kann.
wie gesagt: nur Ideen.
mit freundlichen Grüßen Martin
Hi,
bitte fragt nicht nach dem Grund, aber ich habe Privat eine Menge Daten zu beherbergen. Derzeitige Größenordnung etwa 30TB.
Die wichtigste Fragen dabei sind: Wie katastrophal wäre Verlust, und wie katastrophal wäre UNBEMERKTE Veränderung? Ist der Datenbestand dahingehend homogen und anspruchslos, oder hast du mglw. einen kleinen Teil Daten, der dir sehr viel wichtiger ist als der Rest?
Ich selbst habe nur knapp 10TB Daten, davon ist aber von einem Teil im Zweifelsfall der Verlust verschmerzbar, von einem anderen Teil aber nicht, und von dem Teil möchte ich auch gaaaanz sicher sein, dass das nicht einfach unbemerkt kaputtgeht. Unbemerkte Fehler gibts nicht? Aber klar ;) Festplatten sind zwar vergleichsweise zuverlässig im Gegensatz zu USB-Sticks oder SD-Karten, daher ist es "eher unwahrscheinlich", gerade auch wegen der UBE-Raten, die meistens besser sind als angegeben - aber ich habe zum Spaß ein RAIDZ3 aus sieben USB-Sticks gebaut, und seither vertraue ich denen nichtmal so weit, wie ich sie werfen kann - Markenprodukt hin oder her.
Ich hatte zwischenzeitlich auch schon mit FreeNAS und zfs geliebäugelt, aber die Tatsache, dass man einen Pool durch hinzufügen weiterer Platten nicht vergrößern kann, schreckt mich nun ab.
Ich würde nicht die Luft anhalten bis zum Release, und es wird auch noch viele Jahre dauern, bis es nachgewiesen stabil läuft, aber ein nachträgliches Verändern von zpools wird irgendwann möglich werden. Ersatzen von Festplatten durch größere ist dagegen leicht möglich nutzbar, sobald ALLE Festplatten des zpools vergrößert wurden), hinzufügen weiterer zpools auch.
Ich hab jetzt BTRFS versucht, das sieht gar nicht so schlecht aus
Meine Meinung zu BTRFS halte ich in einer Linux-Liste besser etwas zurück. Die Entwicklung stammt m.E. aus dem Lizenz-Foo, der entsteht, wenn man ZFS und Linux verheiraten will, und ein bisschen not-invented-here.
Lizenztechnisch ist das insofern gelöst, als dass heutzutage der Quellcode einfach auf deinem System gebaut wird, das dauert etwas länger und kostet Platz, ja - aber es ist z.B. in Debian völlig vom Benutzer wegabstrahiert. Ob das vorkompiliert kommt oder lokal gebaut wird, merkst du nicht wirklich.
Zu BTRFS zu sagen ist, dass die einzigen Systeme von zig hundert VMs, mit denen wir auf Arbeit jemals großflächig Probleme hatten, waren solche mit BTRFS. Und wer im Raid-Code Bugs hat, die zu Datenverlust führen, kommt auch erstmal noch fünf Jahre auf die Schau-ich-mir-vielleicht-später-nochmal-an-Liste.
Als absolutes Bonbon wäre noch, dass man, wie bei ZFS (unter Freenas) durch den Austausch der Festplatten von derzeit 10TB auf sagen wir 20TB Platten) das RAID ebenfalls vergrößern kann.
Das kannst du vermutlich nicht nur mit ZFS. Und übrigens hat ZFS nix mit FreeNAS zu tun. Zum einen gibt es da noch NAS4free, wenn es schon eine Appliance sein muss anstatt z.B. einem nackten FreeBSD. Zum anderen gibt es ZFSonLinux, schon seit vielen Jahren und mittlerweile hinreichend stabil, und künftig möglicherweise der Hauptentwicklungszweig von ZFS.
Ich habe mich oben zurückzuhalten versucht, meine Bevorzugung von ZFS nicht zu laut werden zu lassen - ist vermutlich trotzdem jedem aufgefallen :D Das heißt nicht, dass es DAS Eierlegendewollmilchsaudateisystem wäre. Genau genommen kann es ziemlich teuer werden, wenn man Wert auf seine Daten legt und daher ZFS verwendet. Ich habe (trotz dass es rein technisch nicht zwingend erforderlich wäre) ein System mit ECC-RAM und SAS-Controller für den Tagesbetrieb - und ein weiteres mit ECC-RAM, SAS-Controller, externem HDD-Shelf inkl. SAS-Expander, und LTO4-Tabelibrary als Backup. Warum? Weil ich gern meine Daten langfristig behalten möchte, und dabei sicher sein will, dass das, was ich heute drauf schreibe, auch morgen noch zuverlässig gelesen werden kann. Und ich kann in meinen Daten zurückspulen, da ich täglich einen Snapshot aufhebe. "Luxux" - ja. Ist's mir wert.
Carsten
Hallo Freunde,
ich will Euch zunächst einmal für Eure ganzen Erfahrungen und Meinungen danken. Jede Meinung war ein weiteres Puzzleteil für mich und jeder hat seine Vor- und Nachteile.
Auch ein Kollege von mir hat mir seinen Ratschlag gegeben, kurz zusammen gefasst: Warum willst Du Snapshots machen? Das ist doch eh ein Datengrab, oder? Also nimm ext4, das sollte passen.
Ich habe mich jetzt für folgendes entschieden: * Software-Raid mit mdadm * Partitionierung mittels LVM (2 Volumes, eines für Medien, eines für Backups) * Dateisystem: ext4
Gründe meinerseits (stichpunktartig) * zu wenig Erfahrungen mit zfs / btrfs * Snapshots sind schon cool, aber das Argument meines Kollegen zieht * xfs hinterlässt bei Fehlern ein Datengrab, ext4 hingegen den Lost Ordner * meine Erfahrungen bzgl. Fehlern bei ext4 und Reparatur sind vorhanden * UND entgegen meiner letzten Erfahrunge kann ext4 nun auch resize2fs oberhalb von 16TB :-) * und ich mag es nicht, einer Technologie sowohl das RAID als auch das Dateisystem als Aufgabe zu übertragen
aber ich nehme Eure Meinungen und Hinweise dennoch gern an und danke Euch vielmals dafür.
mit freundlichen Grüßen Maddin
P.S.: bei der ganzen Kopier-Aktion habe ich noch 2x RAID 5 am Start (mit kleineren Platten, also 4TB und 3TB als RAID). Mit denen spiele ich nun mit den anderen Dateisystemen herum. Vielleicht komme ich ja auch nochmal auf einen anderen Geschmack.
Am 01.04.19 um 00:15 schrieb Carsten Weber:
Hi,
bitte fragt nicht nach dem Grund, aber ich habe Privat eine Menge Daten zu beherbergen. Derzeitige Größenordnung etwa 30TB.
Die wichtigste Fragen dabei sind: Wie katastrophal wäre Verlust, und wie katastrophal wäre UNBEMERKTE Veränderung? Ist der Datenbestand dahingehend homogen und anspruchslos, oder hast du mglw. einen kleinen Teil Daten, der dir sehr viel wichtiger ist als der Rest?
Ich selbst habe nur knapp 10TB Daten, davon ist aber von einem Teil im Zweifelsfall der Verlust verschmerzbar, von einem anderen Teil aber nicht, und von dem Teil möchte ich auch gaaaanz sicher sein, dass das nicht einfach unbemerkt kaputtgeht. Unbemerkte Fehler gibts nicht? Aber klar ;) Festplatten sind zwar vergleichsweise zuverlässig im Gegensatz zu USB-Sticks oder SD-Karten, daher ist es "eher unwahrscheinlich", gerade auch wegen der UBE-Raten, die meistens besser sind als angegeben
- aber ich habe zum Spaß ein RAIDZ3 aus sieben USB-Sticks gebaut, und
seither vertraue ich denen nichtmal so weit, wie ich sie werfen kann - Markenprodukt hin oder her.
Ich hatte zwischenzeitlich auch schon mit FreeNAS und zfs geliebäugelt, aber die Tatsache, dass man einen Pool durch hinzufügen weiterer Platten nicht vergrößern kann, schreckt mich nun ab.
Ich würde nicht die Luft anhalten bis zum Release, und es wird auch noch viele Jahre dauern, bis es nachgewiesen stabil läuft, aber ein nachträgliches Verändern von zpools wird irgendwann möglich werden. Ersatzen von Festplatten durch größere ist dagegen leicht möglich nutzbar, sobald ALLE Festplatten des zpools vergrößert wurden), hinzufügen weiterer zpools auch.
Ich hab jetzt BTRFS versucht, das sieht gar nicht so schlecht aus
Meine Meinung zu BTRFS halte ich in einer Linux-Liste besser etwas zurück. Die Entwicklung stammt m.E. aus dem Lizenz-Foo, der entsteht, wenn man ZFS und Linux verheiraten will, und ein bisschen not-invented-here.
Lizenztechnisch ist das insofern gelöst, als dass heutzutage der Quellcode einfach auf deinem System gebaut wird, das dauert etwas länger und kostet Platz, ja - aber es ist z.B. in Debian völlig vom Benutzer wegabstrahiert. Ob das vorkompiliert kommt oder lokal gebaut wird, merkst du nicht wirklich.
Zu BTRFS zu sagen ist, dass die einzigen Systeme von zig hundert VMs, mit denen wir auf Arbeit jemals großflächig Probleme hatten, waren solche mit BTRFS. Und wer im Raid-Code Bugs hat, die zu Datenverlust führen, kommt auch erstmal noch fünf Jahre auf die Schau-ich-mir-vielleicht-später-nochmal-an-Liste.
Als absolutes Bonbon wäre noch, dass man, wie bei ZFS (unter Freenas) durch den Austausch der Festplatten von derzeit 10TB auf sagen wir 20TB Platten) das RAID ebenfalls vergrößern kann.
Das kannst du vermutlich nicht nur mit ZFS. Und übrigens hat ZFS nix mit FreeNAS zu tun. Zum einen gibt es da noch NAS4free, wenn es schon eine Appliance sein muss anstatt z.B. einem nackten FreeBSD. Zum anderen gibt es ZFSonLinux, schon seit vielen Jahren und mittlerweile hinreichend stabil, und künftig möglicherweise der Hauptentwicklungszweig von ZFS.
Ich habe mich oben zurückzuhalten versucht, meine Bevorzugung von ZFS nicht zu laut werden zu lassen - ist vermutlich trotzdem jedem aufgefallen :D Das heißt nicht, dass es DAS Eierlegendewollmilchsaudateisystem wäre. Genau genommen kann es ziemlich teuer werden, wenn man Wert auf seine Daten legt und daher ZFS verwendet. Ich habe (trotz dass es rein technisch nicht zwingend erforderlich wäre) ein System mit ECC-RAM und SAS-Controller für den Tagesbetrieb - und ein weiteres mit ECC-RAM, SAS-Controller, externem HDD-Shelf inkl. SAS-Expander, und LTO4-Tabelibrary als Backup. Warum? Weil ich gern meine Daten langfristig behalten möchte, und dabei sicher sein will, dass das, was ich heute drauf schreibe, auch morgen noch zuverlässig gelesen werden kann. Und ich kann in meinen Daten zurückspulen, da ich täglich einen Snapshot aufhebe. "Luxux" - ja. Ist's mir wert.
Carsten
Martin Schuchardt kruemeltee@gmx.de writes:
Zielstellung: ich habe derzeit 5 10TB Festplatten und möchte aus diesen einen Ersatz für mein System bauen (bei 5 Platten komme ich mit RAID 5 noch klar, kann aber auch RAID 6 nutzen). Nur suche und suche ich nach den besten Möglichkeiten und brauche ein paar neue Anreize.
Probleme in der Vergangenheit: Ich habe schnell merken müssen, dass wenn man die 16TB Grenze verlässt, man gewissen Einschränkungen hat. Vergrößern ist beispielsweise seitens ext4 meines Wissens nach nicht mehr möglich. Einmal eingerichtet steht die Größe.
Es gab Probleme, ein ext4-Dateisystem kleiner 16TB auf eine Größe größer 16TB zu vergrößern. Inwiefern es diese Probleme noch gibt, weiß ich nicht.
Aber: Es ist kein Problem, ein Dateisystem, daß mit mke2fs neu eingerichtet bereits größer als 16 TB ist, anschließend weiter zu vergrößern. Mach ich ab und zu.
folgende Anforderungen:
- RAID Funktionalität (RAID 5 / RAID 6 ggf. auch konvertierbar)
- RAID Vergrößerung (hinzufügen einer weiteren Platte identischer Größe)
sollte machbar sein
- Dateisystem sollte online erweiterbar sein (hinzufügen einer Platte)
Bis hierher würde ich tatsächlich ext4 nehmen; mit XFS habe ich keine Erfahrung.
- optional: Snapshot funktionalität
Wenn das auch COW (Copy-on-Write) heißt, würde ich btrfs nehmen. Aber nicht BTRFS das RAID machen lassen, sondern darunter Linux-MD und wahlweise noch LVM. Habe ich auch so im Einsatz.
Als absolutes Bonbon wäre noch, dass man, wie bei ZFS (unter Freenas) durch den Austausch der Festplatten von derzeit 10TB auf sagen wir 20TB Platten) das RAID ebenfalls vergrößern kann.
Kann man doch mit Linux-MD-RAID auch (mdadm --grow --size max). Oder ich hab deine Anforderung falsch verstanden.
Sven
Hallo Martin,
zum ext4. Wenn Du das Dateisystem mit einem alten System erstellt hast, kannst Du es nur bis 16TB (44bit?) vergrößern. Bei neueren 64-bit-Systemen werden gleich 48 oder gar 64 bits reserviert. Wie das genau funktioniert kannst Du ja ergooglen. Ich bin vor einem Jahr genau in dieses Problem gelaufen. 4x 4TB (10,5 nutzbar) ersetzt durch 3x 10TB. Eine direkte Umstellung auf >16TB hat nicht geklappt. Mir blieb also auch nichts anderes übrig als Dateisystem neu anzulegen und die 4x 4TB erneut einzuspielen. Derzeit fahre ich mit 4x 10TB Raid 5 -> 28TB nutzbar. Die Erweiterung mit der vierten Platte war kein Thema - außer die Zeit (26h)...
VG Andi
Am 01.04.2019 um 18:10 schrieb Sven Schlittermann:
Martin Schuchardt kruemeltee@gmx.de writes:
Zielstellung: ich habe derzeit 5 10TB Festplatten und möchte aus diesen einen Ersatz für mein System bauen (bei 5 Platten komme ich mit RAID 5 noch klar, kann aber auch RAID 6 nutzen). Nur suche und suche ich nach den besten Möglichkeiten und brauche ein paar neue Anreize.
Probleme in der Vergangenheit: Ich habe schnell merken müssen, dass wenn man die 16TB Grenze verlässt, man gewissen Einschränkungen hat. Vergrößern ist beispielsweise seitens ext4 meines Wissens nach nicht mehr möglich. Einmal eingerichtet steht die Größe.
Es gab Probleme, ein ext4-Dateisystem kleiner 16TB auf eine Größe größer 16TB zu vergrößern. Inwiefern es diese Probleme noch gibt, weiß ich nicht.
Aber: Es ist kein Problem, ein Dateisystem, daß mit mke2fs neu eingerichtet bereits größer als 16 TB ist, anschließend weiter zu vergrößern. Mach ich ab und zu.
folgende Anforderungen:
- RAID Funktionalität (RAID 5 / RAID 6 ggf. auch konvertierbar)
- RAID Vergrößerung (hinzufügen einer weiteren Platte identischer Größe)
sollte machbar sein
- Dateisystem sollte online erweiterbar sein (hinzufügen einer Platte)
Bis hierher würde ich tatsächlich ext4 nehmen; mit XFS habe ich keine Erfahrung.
- optional: Snapshot funktionalität
Wenn das auch COW (Copy-on-Write) heißt, würde ich btrfs nehmen. Aber nicht BTRFS das RAID machen lassen, sondern darunter Linux-MD und wahlweise noch LVM. Habe ich auch so im Einsatz.
Als absolutes Bonbon wäre noch, dass man, wie bei ZFS (unter Freenas) durch den Austausch der Festplatten von derzeit 10TB auf sagen wir 20TB Platten) das RAID ebenfalls vergrößern kann.
Kann man doch mit Linux-MD-RAID auch (mdadm --grow --size max). Oder ich hab deine Anforderung falsch verstanden.
Sven
Hi!
TL;DR: A) RAID6 + XFS + regelmäßige Prüfung. B) ZFS. Beides erfüllt all' Deine Anforderungen.
Ich setze auf XFS auf einem md-RAID6+wöchentlicher Konsistenzprüfung: for i in /sys/block/md*/md/sync_action ; do echo repair > $i ; done
In das 16TB-"Loch" mit ext bin ich auch gerannt, es half nur das "Borgen" von Plattenplatz. Seitdem lasse ich die Finger von ext-Dateisystemen (außer "/boot": ext2 + sync-flag).
Vorteile von XFS: * flott, intern parallel, stabil, 30 Jahre Erfahrung (Werbeartikel: "https://en.wikipedia.org/wiki/XFS") * liest beim mount die "striping"-Metadaten des md-Treibers und passt sich an * Vergrößerung geschieht online (md-Platte dazu, xfs_growfs, fertig)
Nachteile: * Reparaturmöglichkeiten eines Dateisystems mit mangelhafter interner Konsistenz sind _SEHR_ begrenzt (80% Schaden in den internen Datenstrukturen oder ein "guter" Treffer: Totalverlust. Bei ext ist da noch was zu retten, da die internen Datenstrukturen an berechenbaren Plätzen stehen.) * XFS kann nur wachsen. Verkleinern des Dateisystems ist _NICHT_ möglich.
BTRFS (aka "betray-FS") habe ich nicht probiert, weil ich zu der Zeit, als die Möglichkeit dazu bestand, nur schlechtes gehört habe ("https://lwn.net/Articles/393144/"). Das Original ist ZFS. Sogar Debian liefert Pakete.
Viele Grüße Sebastian
Martin Schuchardt kruemeltee@gmx.de writes:
Zielstellung: ich habe derzeit 5 10TB Festplatten und möchte aus diesen einen Ersatz für mein System bauen (bei 5 Platten komme ich mit RAID 5 noch klar, kann aber auch RAID 6 nutzen). Nur suche und suche ich nach den besten Möglichkeiten und brauche ein paar neue Anreize.
Probleme in der Vergangenheit: Ich habe schnell merken müssen, dass wenn man die 16TB Grenze verlässt, man gewissen Einschränkungen hat. Vergrößern ist beispielsweise seitens ext4 meines Wissens nach nicht mehr möglich. Einmal eingerichtet steht die Größe.
Es gab Probleme, ein ext4-Dateisystem kleiner 16TB auf eine Größe größer 16TB zu vergrößern. Inwiefern es diese Probleme noch gibt, weiß ich nicht.
Aber: Es ist kein Problem, ein Dateisystem, daß mit mke2fs neu eingerichtet bereits größer als 16 TB ist, anschließend weiter zu vergrößern. Mach ich ab und zu.
folgende Anforderungen:
- RAID Funktionalität (RAID 5 / RAID 6 ggf. auch konvertierbar)
- RAID Vergrößerung (hinzufügen einer weiteren Platte identischer Größe)
sollte machbar sein
- Dateisystem sollte online erweiterbar sein (hinzufügen einer Platte)
Bis hierher würde ich tatsächlich ext4 nehmen; mit XFS habe ich keine Erfahrung.
- optional: Snapshot funktionalität
Wenn das auch COW (Copy-on-Write) heißt, würde ich btrfs nehmen. Aber nicht BTRFS das RAID machen lassen, sondern darunter Linux-MD und wahlweise noch LVM. Habe ich auch so im Einsatz.
Als absolutes Bonbon wäre noch, dass man, wie bei ZFS (unter Freenas) durch den Austausch der Festplatten von derzeit 10TB auf sagen wir 20TB Platten) das RAID ebenfalls vergrößern kann.
Kann man doch mit Linux-MD-RAID auch (mdadm --grow --size max). Oder ich hab deine Anforderung falsch verstanden.
Sven
lug-dd@mailman.schlittermann.de
-
Andi -
Carsten Weber -
Martin Schuchardt -
Sebastian Hegler -
Sven Schlittermann