Das deutsche Python-Forum

Hallo zusammen,

ich entwickle mit ein paar Freunden ein Webprojekt und bin jetzt auf der Suche nach einem für uns passenden, verteilten Dateisystem.
Es gibt natürlich eine Menge an verteilten Dateisystemen, ob GlusterFS, Lustre, Ceph, AFS, Coda usw. Diese Dateisysteme sind natürlich für den jeweiligen Einsatzzweck sicher super zu gebrauchen (mit GlusterFS habe ich auch schon positive Erfahrungen gesammelt), aber alle diese Dateisysteme haben den "Nachteil" das es "normale" Dateisysteme sind und sie sich nicht von einem ext4, ufs2 o.ä. unterscheiden, wenn sie ins System eingemountet wurden.
Für unser Projekt würden wir gern etwas verwenden, das sich ähnlich wie z.B. Amazons S3 verhält. Sprich ich verwende aus dem Programm heraus einen Client um Daten in das Dateisystem zu schreiben und ich erhalte nach erfolgreichem Upload eine ID zurück. Es gibt mit MogileFS bereits ein Dateisystem, das dem was wir uns wünschen sehr nahe kommt. "Unschön" ist an MogileFS jedoch die Tatsache, das es MySQL oder PostgreSQL zur Verwaltung der Metadaten verwendet und für ein Standardsetup 4 Nodes empfohlen werden. Eine weitere Alternative wäre noch GridFS, das die Daten (standardmäßig in 256K Blöcke) aufsplittet und direkt in der MongoDB speichert (soll aber nur mäßig performant sein).

Am tollsten wäre ein Dateisystem, das sich ähnlich wie Redis (nur mit Clusterfähigkeit) verhält. Sprich ich beginne mit einem Storage-Node, wird der Platz zu klein, füge ich (im laufenden Betrieb) einfach einen neuen Storage-Node hinzu usw.

Google hat leider dazu nichts passendes hergegeben.
Kennt ihr vielleicht ein entsprechendes Dateisystem?

Vielen Dank.

metty hat geschrieben:Für unser Projekt würden wir gern etwas verwenden, das sich ähnlich wie z.B. Amazons S3 verhält. Sprich ich verwende aus dem Programm heraus einen Client um Daten in das Dateisystem zu schreiben und ich erhalte nach erfolgreichem Upload eine ID zurück.

Ich kenne mich jetzt nicht mit S3 aus, aber wie unterscheidet sich das zu einem normalen Dateisystem, wo du nach dem ``close()`` davon ausgehen kannst, dass die Datei im Dateisystem auffindbar ist? Die "ID" ist dann der Dateipfad.

Leonidas hat geschrieben:Ich kenne mich jetzt nicht mit S3 aus, aber wie unterscheidet sich das zu einem normalen Dateisystem, wo du nach dem ``close()`` davon ausgehen kannst, dass die Datei im Dateisystem auffindbar ist? Die "ID" ist dann der Dateipfad.

Du hast schon Recht, so groß ist der Unterschied zwischen S3 und einem "normalen" Dateisystem nicht. Statt Ordner heißt das ganze bei S3 "Bucket" usw.
Der "Hauptunterschied" ist das Interface wie man S3 anspricht, denn es verfügt über ein http-Interface (naja, NFS-Shares über das Internet anzubieten wäre doch seeeehr lustig... ) wo man via PUT oder über SOAP seine Daten platzieren kann. Das der Dateipfad die "ID" ist, würde natürlich auch funktionieren. Im Endeffekt könnte ich mir sowas ähnliches wie S3 ganz einfach mit bottle, fapws/gevent und Redis als Backend selbstbauen, das ist aber nicht unser Problem.

Uns geht es bei dem verteilten Dateisystem hauptsächlich darum, einfach starten zu können aber beliebig erweiterbar zu bleiben. Sprich wir möchten nicht gleich mit 4 Maschinen starten müssen um das Dateisystem überhaupt ans laufen zu bekommen. Am besten wäre eine Lösung wo wir mit einem Storage-Node starten können. Wird der Platz zu knapp sollte es einfach möglich sein (am besten im laufenden Betrieb) ein weiteres Storage-Node hinzuzufügen usw. Bei den meisten verteilten Dateisystemen die ich mir angesehen habe, ist das leider nicht möglich, sondern benötigt eine Umkonfigurierung (zumeist aller Nodes). Zudem ist die Strategie wie Daten verteilt werden teilweise sehr fraglich. Bei GlusterFS ist z.B. der Client für die Replikation der Daten zuständig. Sowas gefällt mir leider überhaupt nicht.
Etwas ähnliches, aber leider kein Storagesystem wurde vor kurzem mit MemBase veröffentlicht. Das ganze ist im Endeffekt wie Redis ein Key Value Store, doch bei diesem kann man ganz einfach neue Nodes im laufenden Betrieb hinzufügen/entfernen. Wenns doch sowas nur als Storagelösung gäbe...

Nimm doch AFS, das sollte deine Anforderungen erfüllen. Grundsätzlich würde ich Dateisysteme die HTTP verwenden eher kritisch betrachten, HTTP ist dafür einfach nicht gemacht.

Btw, Eucalyptus scheint auch die S3-API nachgebildet zu haben, das kannst du dir auch mal ansehen.

Leonidas hat geschrieben:Btw, Eucalyptus scheint auch die S3-API nachgebildet zu haben, das kannst du dir auch mal ansehen.

Danke für den Typ, aber nur für die Datenspeicherung eine ganze Cloudlösung zu installieren ist IMO overkill.
Ich werde noch etwas weitergucken und wenn ich nichts passendes finde, werde ich vermtl. selbst etwas entsprechendes entwickeln.

Also etwas selbst entwickeln scheint mir im Vergleich zu "Software installieren" Overkill

Leonidas hat geschrieben:Also etwas selbst entwickeln scheint mir im Vergleich zu "Software installieren" Overkill

Ja da hast du schon recht, aber ich brauche ja auch eine Beschäftigung
Außerdem lernt man dabei auch was und es ist ja zum Glück nicht so, das ein Kunde darauf wartet und Druck macht.

Natürlich kann ich kein so komplexes "Dateisystem" entwickeln, wie die im Startthread genannten, aber Dinge wie Fault Tolerance, Replikation, im Endeffekt alles was "richtige" Cluster-Dateisysteme bieten, werden gar nicht benötigt (außer eine sichere Speicherung natürlich, aber das übernimmt das Betriebssystem + Raid & Co.).

Ich hab mal ein Storagesystem gesehen, das hat wie Lego-Steine ausgesehen (nicht das von LaCie). War der Speicher zu knapp, hat man einfach ein weiteres "Steinchen" reingedrückt. Leider finde ich kein Bild mehr dazu. Aber das würde unsere Anforderung am besten beschreiben