Dm-cache oder Bcache sinnvoll?


    Hey Leute,

    momentan habe ich an meinem privaten DSL ein Raspberry hängen auf dem ich alle wichtigen Dinge meines Lebens hoste, unter anderem eine Nextcloud und Mattermost.
    Ich spiele momentan mit dem Gedanken zum Beispiel die Nextcloud auf einen Root-Server von Netcup umzuziehen.
    Allerdings habe ich bei mir 2 5TB Festplatten im RAID Verbund laufen und würde ungern genau so viel Storage bei Netcup anmieten müssen.

    Meine Idee war nun folgende:
    Ich nehme einen normalen Root-Server mit SSD , anschließend richte ich per DM-Cache oder Bcache eine Cache-Partition auf dem Server ein (~20GB). Nun binde ich meine 5TB Festplatten zu Hause per NFS ein und lasse diese auf die schnelle SSD cachen.

    Wenn ich mich nicht irre hätte ich damit die Verfügbarkeit und Schnelligkeit des Root-Servers mit der großen Kapazität meines Heim-Servers.
    Außerdem wären dann hoffentlich die ganzen kleineren Sachen wie Kalender,Kontakte, kleine Textdateien gecached und ich hätte noch eine funktionierende Cloud selbst wenn mein DSL zu hause wieder mal nicht erreichbar ist.

    Mein größtes Anliegen ist eigentlich, dass alle kleineren Sachen auf der SSD liegen und die Cloud so gut wie voll funktionsfähig bleibt, selbst wenn mein DSL zu hause spinnt und somit nur die größeren Dinge wie Backups und Filme nicht abrufbar sind


    Habt ihr Ideen, Vorschläge oder ne Meinung zu diesem Aufbau? Übersehe ich dabei etwas oder sonstiges?

    Was genau ist denn dein Ziel? Greifst du momentan von außerhalb auf deinen Pi Zuhause zu und dir ist das zu langsam? Bei dem geplanten Setup wirst du immer noch (je nach was du für eine Leitung hast) ziemlich von deinem Upload beschänkt sein, zumindest für den ersten Download. Da stellt sich dann aber die Frage wie oft du auf die selbe Datei zugreifst, dass sich ein Cache lohnt?


    Oder willst du dir damit überhaupt erst ermöglichen von überall darauf zugreifen zu können?


    Prinzipiell finde ich deine Idee voll cool, aber mir erschließt sich dein eigentliches Ziel noch nicht ^^


    EDIT: Irgendwie habe ich den vorletzten Absatz nicht ganz wahrgenommen. Fällt dein DSL Zuhause so oft aus? Vielleicht wäre es einfacher die bestimmten kleinen Dateien per rsync zu synchronisieren oder ähnliches.

    Du hast nicht wirklich viel Kontrolle darüber, was gecached wird.

    Und auch die Verfügbarkeit des Caches vs. Verfügbarkeit der eigentlichen Daten führt unweigerlich zu Konsistenzproblemen.


    Ich würde dir hier empfehlen zwei getrennte Nextcloud Installationen zu betreiben. Eine für deine Filme und großen Files, und eine für deine kleinen Dateien.

    Die Netcup SSDs haben nicht viele Vorteile gegenüber den SAS Platten, abgesehen von IOPS, die bei einem Dateiserver mit wenigen Nutzern eher nicht ins Gewicht fallen. Zudem hast du unter Linux bereits einen richtig guten Cache: den RAM. Und die SAS Platten geben dir auch etwas mehr Platz zum Jonglieren.


    Wenn du doch nicht von dem Gedanken ablassen kannst: hier würde sich ein GlusterFS mit Shards anbieten. Für das übergreifende locking von Dateien in der Nextcloud bräuchtest du dann eine Redis Datenbank, damit du dann die großen Dateien lokal mit einem Geschwindigkeitsbonus ausspielen kannst.


    Ansonsten nehmen die einmal den Umweg über das Internet.

    Jede Lösung dazwischen führt beim Schreiben von Dateien zu defekten Dateien. Wenn du sinnvoll zwei Nextclouds mit der gleichen Datenbasis anbieten willst, musst du ein Locking in der höchsten Protokollebene sicher stellen.

    Hey Leute,


    danke schon mal für eure Antworten!

    Zitat von Valkyrie

    Was genau ist denn dein Ziel?

    Oder willst du dir damit überhaupt erst ermöglichen von überall darauf zugreifen zu können?

    EDIT: Irgendwie habe ich den vorletzten Absatz nicht ganz wahrgenommen. Fällt dein DSL Zuhause so oft aus? Vielleicht wäre es einfacher die bestimmten kleinen Dateien per rsync zu synchronisieren oder ähnliches.

    Mein Ziel ist es eine Nextcloud Instanz mit sehr hoher Verfügbarkeit und relativ hoher Geschwindigkeit zu haben.
    Theoretisch lief es bei mir lokal auch ganz gut, aber:

    - Die SD-Karte meines Raspberrys hat den Geist aufgegeben
    - Der USB/Sata Adapter fürs Raspberry war defekt bzw nicht kompatibel zu Linux und somit hing meine SSD regelmäßig
    - Mein raspberry hat irgendwann angefangen einfach zu hängen und nicht mehr erreichbar zu sein

    - Vor 2 Tagen haben irgendwelche Menschen entschieden sie wollen gegen ein Forschungsinstitut, dass neben meinem Haus liegt, demonstrieren und haben einfach mal einen Kabelschacht in Brand gesetzt und jetzt habe ich wahrscheinlich mehrere Wochen kein Internet mehr.

    In Summe: Ich kann mich mit Ausfällen abfinden und repariere gerne alles, aber es nervt gewaltig wenn dann meine kompletten IT-Systeme nicht mehr funktionieren, da sie auf Nextcloud basieren.
    Daher wäre es für mich enorm wichtig, dass ein gewisser Prozentsatz meiner Daten bzw die Nextcloud mit den Basics (Kontakte, Kalender,Keepassfile etc etc ) noch funktioniert und im schlimmsten Fall einige Daten vorübergehend nicht synchronisiert werden können.



    Zitat von H6G

    Du hast nicht wirklich viel Kontrolle darüber, was gecached wird.

    Und auch die Verfügbarkeit des Caches vs. Verfügbarkeit der eigentlichen Daten führt unweigerlich zu Konsistenzproblemen.


    Danke für deinen Input.

    Ich dachte nicht, dass das zu Konsistenzproblemen führt, sondern genau für dieses Use-Case geschaffen wäre und die Daten dann nur vorübergehend nicht aktualisiert werden.
    Werde mich da noch mal etwas genauer einlesen ob man sowas vermeiden könnte.

    Zitat von H6G

    Ich würde dir hier empfehlen zwei getrennte Nextcloud Installationen zu betreiben. Eine für deine Filme und großen Files, und eine für deine kleinen Dateien.

    Die Netcup SSDs haben nicht viele Vorteile gegenüber den SAS Platten, abgesehen von IOPS, die bei einem Dateiserver mit wenigen Nutzern eher nicht ins Gewicht fallen. Zudem hast du unter Linux bereits einen richtig guten Cache: den RAM. Und die SAS Platten geben dir auch etwas mehr Platz zum Jonglieren.

    Das ist eine echt gute Idee. Ich werde das mal im Kopf durchspielen in wie weit das alle Kriterien erfüllt die ich bräuchte.
    Eine andere Option die mir gerade eingefallen ist ist, dass ich alle kleineren Daten in die Nextcloud Instanz auf dem Root-Server schiebe und die restlichen großen Daten auf der Festplatte einfach als "Externer Speicher" einbinde. Somit wäre im worst case maximal mein extern eingebundener Speicher nicht erreichbar.

    Zitat von H6G

    Wenn du doch nicht von dem Gedanken ablassen kannst: hier würde sich ein GlusterFS mit Shards anbieten. Für das übergreifende locking von Dateien in der Nextcloud bräuchtest du dann eine Redis Datenbank, damit du dann die großen Dateien lokal mit einem Geschwindigkeitsbonus ausspielen kannst.


    Ansonsten nehmen die einmal den Umweg über das Internet.

    Jede Lösung dazwischen führt beim Schreiben von Dateien zu defekten Dateien. Wenn du sinnvoll zwei Nextclouds mit der gleichen Datenbasis anbieten willst, musst du ein Locking in der höchsten Protokollebene sicher stellen.

    Tatsächlich ne sehr interessante Option und kommt auch auf meine ToDo-Liste, aber wäre momentan glaube ich absoluter Overkill.

    Wird aber trotzdem evtl mal in Angriff genommen allein um es mal getestet zu haben!

    Zitat von Peter Lustig

    Ich dachte nicht, dass das zu Konsistenzproblemen führt, sondern genau für dieses Use-Case geschaffen wäre und die Daten dann nur vorübergehend nicht aktualisiert werden.

    Beide Systeme beziehen sich auf lokale Blockdevices. Du strebst aber ein verteiltes System an - und das interessiert den Linux Kernel nicht. Daher musst du hier auf Garantien des verteilten Systems zurück greifen.


    In verteilten Systemen gelten eigene Regeln. Eine davon ist Brewers CAP-Theorem.


    Im CAP Theorem werden drei Anforderungen an verteilte Systeme beschrieben:

    C - Consistency

    A - Availability (des Produktes / Dienstes / Gesamtsystems)

    P - Partition tolerance (verkraftet der Dienst, dass sich die Systeme nicht mehr untereinander sehen, weil ein System offline ist)


    Brewer sagt aus: aus diesen drei Anforderungen kannst du nur zwei Anforderungen garantieren, die dritte ist dann dein Problem.

    Deine Anforderung war: Availability & Partition tolerance und damit ist die Datenkonsistenz nicht mehr gewährleistet.


    Ob du mit Bcache & DM-cache überhaupt ein AP System betreiben kannst, steht dabei auf dem anderen Blatt.

    IdR sind die verteilten Systeme nämlich anhand dieser Garantien programmiert. Willst du andere Garantien, benutzt du ein anderes Produkt.

    Zitat von Peter Lustig

    Eine andere Option die mir gerade eingefallen ist ist, dass ich alle kleineren Daten in die Nextcloud Instanz auf dem Root-Server schiebe und die restlichen großen Daten auf der Festplatte einfach als "Externer Speicher" einbinde. Somit wäre im worst case maximal mein extern eingebundener Speicher nicht erreichbar.

    Da würde ich auch vom Aufwand her dazu raten - einfach deine Platten als SMB Share via s2s Wireguard o.Ä. dranhängen und dann in Nextcloud den Spaß einbinden. Doku dazu ;)


    So hast du allen wichtigen Kleinkram auf dem Server und auf Abruf kriegst du dann den großen, extravarganten Kram. :)

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber