Gejointes Fillesystem?

[Bohnenhans]

Ich weiss leider nicht ganz genau wie ich suchen soll ob es dazu schon einen Thread gibt.....

Ich habe mir ein zweites "Live" Backupsystem bestellt Der Server ist RAIDZ2, das Backupsystem ist auch RAIDZ2 und die wichtigen Daten sind extern noch mehrfach gesichert.

Der Focus ist also nicht mehr so stark auf Backup sondern mehr auf Verfügbarkeit.

Das System kommt mit 5x22 TByte die ich "linear" nutzen will aber doch so dass der Ausfall einer HDD kein Komplettverlust ist.

Die erste Idee war das mit links oder mount --bind zu machen, aber das wird halt mit der Zeit ne "Sauerei" xD durch automatisiertes Syncen mit Löschen dazukopieren in manchen Verzeichnissen etc.

Gibt es dafür irgendeine "intelligente" Lösung? Also so eine Art "automatisch sinnvoll verwursteltes System aus Einzel nutzbaren HDDs"

 

[madmax2010]

Da du schon zfs nutzt.. https://docs.oracle.com/cd/E24841_01/html/820-2313/gaypa.html
ist es das was du suchst?
und schau mal nach zrepl

 

[andy_m4]

Was für ein Dateisystem kommt denn zum Einsatz? Bei ZFS kann man ja recht easy Replication machen.
Ansonsten könnte man halt mit rsync was bauen (was dann auch nicht ganz so abhängig vom verwendeten Dateisystem ist).

 

[gaym0r]

Was für ein Dateisystem kommt denn zum Einsatz?

Es steht 2x RAIDZ2 im Text.

 

[andy_m4]

Da sagst Du natürlich was. :-)

 

[0x8100]

Gibt es dafür irgendeine "intelligente" Lösung? Also so eine Art "automatisch sinnvoll verwursteltes System aus Einzel nutzbaren HDDs"

https://github.com/trapexit/mergerfs

 

[HisN]

Unraid macht sowas, wenn Du da Deine Laufwerke einfügen kannst.

 

[snaxilian]

Gibt es dafür irgendeine "intelligente" Lösung? Also so eine Art "automatisch sinnvoll verwursteltes System aus Einzel nutzbaren HDDs"

Ja, so etwas gibt es und nennt sich "union mount" oder auch "union filesystem".
Bekannte Beispiele sind das schon erwähnte mergerfs oder eben auch unionfs, aufs, overlayfs oder wenn man es über mehrere Server verteilen will dann eben Glusterfs.

Wenn du auf einem einzelnen System dann noch extra Paritäten möchtest, kannst einen Blick auf Snapraid werfen oder eben das was unraid macht.

 

[Bohnenhans]

Ui Danke, da gibt es ja doch einiges mehr als ich dachte, was ich mir mal anschauen kann

 

[Bohnenhans]

Da du schon zfs nutzt.. https://docs.oracle.com/cd/E24841_01/html/820-2313/gaypa.html
ist es das was du suchst?
und schau mal nach zrepl

Das sind ja nur "subvolumes" eines zfs sets dazu müsste ich ja dann trotzdem ein raidz über die ganzen laufwerke machen und könnte die nicht einzeln unabhängig ansprechen. Das nutze ich crypt / noncrypt Bereiche

Ich hab mal mergerfs im Testlauf, denke das könnte ganz gut passen.

Unraid ist mir glaub zu "vollständig", da ich meist halt viel dran rumwerkle z.b. für Heimautomatisierungsintegration und da dann auch mal hier und da irgenddwo im System was umbiegen will xD

 

[andy_m4]

Das sind ja nur "subvolumes" eines zfs sets dazu müsste ich ja dann trotzdem ein raidz über die ganzen laufwerke machen und könnte die nicht einzeln unabhängig ansprechen.

Vielleicht verstehe ich ja Dein Problem/Setting nicht. Aber was spricht denn jetzt dagegen auf jede Platte einen einzelnen Pool zu machen und das ganze dann normal via Mountpoints zusammenzusetzen und die Pools dann via ZFS-Replication aufs Backupsystem zu "spiegeln" ?

 

[Bohnenhans]

Naja dass wenn dann ein Verzeichnis beim Kopieren "überläuft" der Überlauf halt nicht erst mal automatisch auf eine andere HDD kommt. Beim reinen Linken würde der dann halt einfach sagen "Platz" voll wenn die eine HDD mit dem Verzeichnis voll wäre, auch wenn auf den anderen zusammen noch 40 TByte frei sind.

 

[andy_m4]

Da hast Du natürlich Recht.

 

[Bohnenhans]

Und man kann ja dann sozusagen trotzdem manuell "balancen" bei mergerfs indem man dann ein Verzeichnis auf den echten Einzel HDDs verschiebt. Glaube so weit ich das getestet habe wird das dann so genutzt.

Also wenn man \ABC\ von Disk 2 auf Disk 1 moved landen alles files von \ABC\* zukünftig auf Disk 1, bis die HDD voll ist erst dann wird wieder Disk 2 genutzt und da ein neues \ABC\ erstellt und gemerged.

 

[andy_m4]

Und man kann ja dann sozusagen trotzdem manuell "balancen" bei mergerfs indem man dann ein Verzeichnis auf den echten Einzel HDDs verschiebt.

Mir ist nur noch nicht so 100%ig klar, warum man das unbedingt so haben wollen würde. Ja. Es hat den Charme, das man Platten auch einzeln verwenden kann (was bei einem RAID-Verbund ja eher nicht geht). Man verliert aber auch einiges. Zum Beispiel die Effizienz eines RAIDs. Oder die Tatsache, das man Datasets individuelle Attribute zuweisen kann (was ja nicht mehr so einfach geht, wenn gar nicht mehr klar ist auf welchem Pool/Dataset eine Datei letztlich landet). Um das Verfügbarkeitsfeature im Falle eines Plattenausfalls eines RAID vorzuhalten muss man umständlich/aufwendig ein weiteres Backup-System bereitstellen.

Gut. Auch RAID hat natürlich ein paar Nachteile. Neben dem "einzelne Platte nicht lesen können" hast Du in der Regel auch ne feste Plattenstruktur. Du kannst nicht mal eben beliebig Platten dazu nehmen/entfernen und schon gar nicht, wenn unterschiedliche Plattengrößen zum Einsatz kommen. Außerdem fällt die RAID-ReBuild-Time weg.

 

[Bohnenhans]

Der "Hauptserver" hat wie gesagt RAIDZ2 der 1:1 Backupserver davon hat auch RAIDZ2 - der jetzt zusätzliche "Backupserver vom Backupserver" braucht das dann nicht mehr - zumindest aktuell

Aktuell müssen mindestens 6 HDDs gleichzeitig ausfallen bevor es Datenverlust gibt. Das schon relativ unwahrscheinlich - da reicht dann das System ohne Raid zusätzlich.

Und wie gesagt Kerndaten sind sowieso noch mehrfach gesichert.

 

[Bohnenhans]

Nun ist das ne Weile am Kopieren mergerfs verteilt die Daten tatsächlich fileweise unabhängig von der Verzeichnisstruktur so dass die HDDs komplett gleichmässig gefüllt werden, hat halt den Nachteil dass damit keine vollständigen Verzeichnisse vorhanden sind wenn eine HDD ausfällt

Übergangsweise ist das schon ok... aber denke werde noch 1 HDD nachrüsten und dann doch auch da ein RAIDZ drausmachen - 1 SATA Port auf dem Board ist noch frei

root@i7-804-88tb:~# df -h
Filesystem      Size  Used Avail Use% Mounted on
tmpfs           785M  3,1M  782M   1% /run
/dev/sda2       476G  4,7G  470G   1% /
tmpfs           3,9G     0  3,9G   0% /dev/shm
tmpfs           5,0M     0  5,0M   0% /run/lock
/dev/sda1       1,1G  6,1M  1,1G   1% /boot/efi
hdd1             13T  128K   13T   1% /mnt/hdd1
hdd3             13T  128K   13T   1% /mnt/hdd3
hdd2             13T  128K   13T   1% /mnt/hdd2
hdd4             13T  128K   13T   1% /mnt/hdd4
tmpfs           785M  4,0K  785M   1% /run/user/0
1:2:3:4          50T  512K   50T   1% /tank
hdd1/crypted     20T  7,5T   13T  38% /mnt/hdd1/crypted
hdd2/crypted     20T  7,5T   13T  38% /mnt/hdd2/crypted
hdd3/crypted     20T  7,5T   13T  38% /mnt/hdd3/crypted
hdd4/crypted     20T  7,5T   13T  38% /mnt/hdd4/crypted

 

[0x8100]

hat halt den Nachteil dass damit keine vollständigen Verzeichnisse vorhanden sind wenn eine HDD ausfällt

siehe "path preservation" auf https://github.com/trapexit/mergerfs - wenn du auf einer hdd einen bestimmten pfad erstellst, dann landen mit den ep* policies die daten auch nur auf der hdd mit dem pfad. existiert der pfad auf mehreren hdds oder du erstellst den pfad erst auf dem mergerfs (so dass er auf allen hdd erstellt wird), dann werden die dateien gemäss der policy auf mehrere hdd auf geteilt.

ich habe z.b. ein mergerfs aus sdd+hdd. (nur) die hdds haben z.b. ein "video" verzeichnis, so dass dateien da drin auf die hdds aufgeteilt werden, aber nicht auf die ssds geschrieben werden. würde ich z.b. noch video/misc nur auf einer bestimmten hdd erstellen, so würden dateien da drin auch nur auf dieser hdd landen. andere verzeichnisse wie z.b. "audio", "dokumente" usw. dagegen gibt es nur auf den ssds, also werden daten da drin nicht auf die hdds geschrieben.

 

[Bohnenhans]

oh das hab ich wohl übersehen