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?
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.
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.
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.
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.
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.
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.
[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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.