mikrocontroller.net

Forum: PC Hard- und Software Suche verteiltes FUSE basiertes readonly Dateisystem


Autor: DPA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bevor ich sowas selbst programmiere, wollte ich nachfragen, ob es sowas 
schon gibt.

Konkret habe ich folgendes:
 * Einen Linux Haupserver, auf dem das zu sharende Dateisystem ist
 * Später womöglich mal einen oder mehrere sekundäre Server für Failover
 * Mehrere Linux Systeme, die auf das readonly Share zugreifen sollen
 * Alle Systeme mit 100Mbit verbunden (ist etwas langsam, aber die Kabel 
sind, was sie sind. Das längste ist ausgerechnet zwischen dem Server und 
dem Rest, geht von ganz oben nach ganz unten und wieder zurück.)

Folgende zusätzlichen Anforderungen gibt es:
  1) Ich will es als readonly rootfs für die Linux Clients verwenden. 
Ich brauche folgende Betriebsmodi:
    a) Standalone: holt alles übers Netzwerk, braucht keinen lokalen 
Datenspeicher, cached aber möglicherweise einiges im RAM. Für spontanes 
Netzwerkbooten von neuen Rechnern.
    b) Spiegelnd: Alle Daten werden auf eine lokale Partition 
gespiegelt. Von dieser kann dann später auch gebooted werden. Das FUSE 
Dateisystem soll dabei trotzdem dazwischen liegen, und wenn der Server 
wieder auftaucht, den Client wieder auf den selben Stand bringen wie den 
Server und mit dem restlichen Cluster verbinden. Keine Synchronisation 
vom Client zum Server.
    c) Cachend: Das System ist immer im lokalen Netzwerk, und bootet von 
diesem. Daten werden auf der Festplatte abgelegt, sobald auf diese 
zugegriffen wird. Die Clients sollen über Änderungen vom Server 
informiert werden, und nur von zeit zu zeit mal nachprüfen, ob alles 
noch aktuell ist.
  2) Die Clients im Cluster können Daten von allen Teilnehmern holen. 
Die Checksummen müssen aber mit einem der Server gegengeprüft werden. 
Die Integritätsprüfung mit dem Server muss sicher sein. Verschlüsseln 
der übertragenen Daten ist nicht gewünscht, nur signieren. Idealerweise 
sollten die Dateien von den Clients mit der niedrigsten Latenz geholt 
werden.
  4) Wenn nur ein Rechner Dateien braucht, sollte TCP verwendet werden. 
Bei UDP hab ich in meinem Netzwerk einfach zu viele verlorene Packete 
(alle paar Minuten mal ein zwei), und nichts funktioniert da besser als 
TCP.

Ziele sind:
 * Skalierbare und Schnelle Netzwerkbootlösung
 * Niedrige Netzwerkauslastung
 * Niedrige Latenz beim Laden von Dateien
 * Sicher und Readonly

Irrelevant sind:
 * Sofortige Erkennung von Änderungen an Dateien

Nicht gewünscht sind:
 * Schreibzugriff der Clients
 * File lockig
 * Cloud lösungen und zeug das nach hause telefoniert

Optional:
 * Ändern des Dateisystemzustands Snapshotweise (Ein aktiver Snapshot 
des Dateisystems. Bei aktiv setzen eines anderen Snapshot beim Server 
müssen alle Clients prüfen, was noch Aktuell ist, und den Rest löschen 
oder als veraltet markieren, und währenddessen sollen Zugriffe 
blockieren. Neue Clients prüfen als aller erstes, ob eine neue 
Snapshotversion da ist, bevor auf irgendwas zugegriffen werden kann. 
Dadurch soll das FS aus sicht der Anwendungen quasi atomar aktualisiert 
werden, also immer ein konsistenter Gesamtzustand innerhalb eines 
Client.)
 * Multicast Unterstützung, damit nicht alles mehrfach gesendet werden 
muss falls es sich vermeiden lässt.

Das ganze ist eigentlich nur eine Spielerei. Die NFS Lösung, die ich im 
Moment habe, ist einfach viel zu langsam.

Kennt jemand zufällig ein Netzwerk/Cluster Dateisystem, das darauf 
passt?

Autor: Blubb (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ZFS über iSCSI?

Autor: Kellerkind (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht kann man da was mit Ceph basteln.

DPA schrieb:
> 4) Wenn nur ein Rechner Dateien braucht, sollte TCP verwendet werden.
> Bei UDP hab ich in meinem Netzwerk einfach zu viele verlorene Packete
> (alle paar Minuten mal ein zwei), und nichts funktioniert da besser als
> TCP.

UDP sollte, in diesem Fall, GAR NICHT verwendet werden, da es by Design 
ein nicht-zuverlässiges Protokoll ist. Es ist nicht sichergestellt, ob 
Datenpakete ankommen.

Autor: olibert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
DPA schrieb:
> Wenn nur ein Rechner Dateien braucht, sollte TCP verwendet werden.
> Bei UDP hab ich in meinem Netzwerk einfach zu viele verlorene Packete
> (alle paar Minuten mal ein zwei), und nichts funktioniert da besser als
> TCP.

Das ist kein Problem, wenn hoehere Protokollschichten dafuer sorgen, 
dass alle Datenpakete ankommen: Siehe NFS v2

DPA schrieb:
> Kennt jemand zufällig ein Netzwerk/Cluster Dateisystem, das darauf
> passt?

Schau dir GlusterFS an.

Autor: Daniel A. (daniel-a)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
olibert schrieb:
> DPA schrieb:
>> Wenn nur ein Rechner Dateien braucht, sollte TCP verwendet werden.
>> Bei UDP hab ich in meinem Netzwerk einfach zu viele verlorene Packete
>> (alle paar Minuten mal ein zwei), und nichts funktioniert da besser als
>> TCP.
>
> Das ist kein Problem, wenn hoehere Protokollschichten dafuer sorgen,
> dass alle Datenpakete ankommen: Siehe NFS v2

Ich weiss, aber das ist erst die halbe miete. Ohne congestion control, 
sobald da mal etwas Auslastung ist, schiessen die Verluste in die Höhe, 
die resends steigen rapide an und dann ist alles dicht. Klar auch dass 
kann man begrenzt im nächsten Layer lösen. Aber wirklich gut 
funktioniert das selten. Bei TCP kann das zeug jeder Router, und man 
weiss, dass der Algorithmus anständig läuft. Bei UDP sachen ist es immer 
eine Wundertüte, mit viel Glück kann es vielleicht mal was anständiges 
sein, aber meistens ist es nichts, und Router können auch nicht 
mithelfen.

Blubb schrieb:
> iSCSI

block-level access -> für mehrere Clients unbrauchbar.

olibert schrieb:
> GlusterFS

Von Wikipedia:
> GlusterFS aggregates various storage servers over Ethernet or Infiniband > RDMA 
interconnect into one large parallel network file system
> The clients themselves are stateless, do not communicate with each other

Abgesehen davon, das es Caching kann, passt das also überhaupt nicht zu 
meinem use-case. Die Möglichkeit mehrerer Server kann zwar später 
nützlich werden, im Moment hab ich aber erst einen, und dann kann ich 
den Teil immernoch anderweitig lösen, nützt mir also vorerst nichts. Als 
Speicher backend für Container und VMs ist es sicher grossartig, aber 
für meinen Einsatzzweck ist es einfach nicht geeignet, und erfüllt keine 
meiner Anforderungen oder Ziele.

Kellerkind schrieb:
> Ceph

Ist das nicht das gleiche Problem wie bei GlusterFS?


Nochmal, nur der Hauprserver darf schreib zugriff haben, und die Clients 
sollen versuchen untereinander als Loadbalancer zu Fungieren. Die 
Verbindung zum Server ist mein grösstes Bottleneck.

Trotzdem danke für die Vorschläge.

Autor: Reinhard S. (rezz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel A. schrieb:
> Nochmal, nur der Hauprserver darf schreib zugriff haben, und die Clients
> sollen versuchen untereinander als Loadbalancer zu Fungieren. Die
> Verbindung zum Server ist mein grösstes Bottleneck.

Wäre es da nicht vielleicht auch eine (einfachere?) Lösung, die 
Verbindung zum Server eben aufzubohren/neu zu verlegen oder einen 
zweiten mit besserer Anbindung an die Clients einzurichten?

Stell ich mir einfacher und schneller vor, als sowas zu programmieren.

Autor: olibert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel A. schrieb:
>> Das ist kein Problem, wenn hoehere Protokollschichten dafuer sorgen,
>> dass alle Datenpakete ankommen: Siehe NFS v2
>
> Ich weiss, aber das ist erst die halbe miete. Ohne congestion control,
> sobald da mal etwas Auslastung ist, schiessen die Verluste in die Höhe,
> die resends steigen rapide an und dann ist alles dicht.

Aha, NFS v2 hat deiner Meinung nicht funktioniert. Sun Microsystems und 
eine Menge Kunden waren in den 90ern komischerweise anderer Ansicht.


> Blubb schrieb:
>> iSCSI
>
> block-level access -> für mehrere Clients unbrauchbar.
>
> olibert schrieb:
>> GlusterFS
> Abgesehen davon, das es Caching kann, passt das also überhaupt nicht zu
> meinem use-case.

>> Ceph
>
> Ist das nicht das gleiche Problem wie bei GlusterFS?

Liegt das vielleicht nicht eher an der Liste deiner merkwürdigen 
Anforderungen das so ueberhaupt nichts passt?

Was immer du vor hast klingt viel zu kompliziert und wuerde in jeder IT 
Abteilung im Papierkorb landen.

Autor: Daniel A. (daniel-a)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
olibert schrieb:
> Aha, NFS v2 hat deiner Meinung nicht funktioniert.

Das habe ich nicht behauptet. Ich bezog mich auf udp, und dass man dort 
halt nie weiss, was man bekommt.

olibert schrieb:
> Liegt das vielleicht nicht eher an der Liste deiner merkwürdigen
> Anforderungen das so ueberhaupt nichts passt?

Es mag nicht der default use-case für cluster Dateisysteme sein, aber 
ist es denn so ungewöhnlich, möglichst schnell Netzwerkbooten zu wollen, 
und dabei den Server möglichst stark zu entlasten?

Die liste ist zwar Ausführlich, aber wird si dadurch wirklich 
kompliziert?

Reinhard S. schrieb:
> Wäre es da nicht vielleicht auch eine (einfachere?) Lösung, die
> Verbindung zum Server eben aufzubohren/neu zu verlegen oder einen
> zweiten mit besserer Anbindung an die Clients einzurichten?

Ja, das wäre eigentlich der richtige weg hier. Aber die Kabel gehen 
durchs ganze Haus, das wäre nicht so billig, und für eine blosse 
Spielerei... Wenn ich mal für irgendwas mehr Internetbandbreite brauche 
oder aus anderen gründen bekomme, Überlege ich mir das vielleicht 
nochmal.

> Stell ich mir einfacher und schneller vor, als sowas zu programmieren.

Ja, das stimmt. (Eigentlich habe ich schon viel zu viele Projekte 
angefangen, die ich fertig machen müsste.) Aber so ein Dateisystem ist 
jetzt auch keine Raketenwissenschaft. Ist auch nicht mein erstes Fuse 
Dateisystem. Ich mag die Dinger irgendwie.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
[Ungetestet] Alle Netzwerkshares mounten, auf jedem ist die selbe große 
Image-Datei, mit losetup je ein Loop-Gerät für jede Imagedatei erzeugen, 
dann mit mdadm ein RAID 1 über alle Loop-Geräte aufziehen, dann das md 
Gerät partitionieren, formatieren, mounten und benutzen ;-)

Quelle:
https://www.mylinuxplace.com/building-raid-over-network-share/

: Bearbeitet durch User

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.