Benutzer:Meap/ClusterCacheFS

Die Bezeichnung deutet auf ein Dateisystem hin, welches zum einen geclustert und zum anderen gecached werden kann. Das hört sich sehr fantastisch an und soll es auch sein.

Da ich mir schon einige Dateisysteme (FS ~ FileSystem) angesehen habe und keines mir die entsprechenden Features bot (ggf. habe ich es aber auch nur nicht gefunden oder nicht verstanden), dachte ich mir, selber eins zu entwickeln.

Motivation

In einer Zeit der sinkenden Hardware-Preise, steigenden Datenvolumina und Speicherkapazitäten ist noch nicht klar, ob der Benutzer dabei nicht auf der Strecke bleibt, da er entweder seine Daten in dem gesamten Datenhaufen (ich habe bewußt nicht -müll gesagt) nicht wieder findet ~ und dies trotz massiver Software-Unterstützung (htdig/Spotlight/Google-Desktop/Windows-Desktop-Search/Beagle/...), oder aber aufgrund seiner Arbeitsweise auch die vorhandenen Resourcen nie ausreichen werden (CUT-COPY-PASTE im Dateisystem und gemeinsames Arbeiten an gemeinsamen Daten).

Eigentlich wäre es an der Zeit, das komplette Dateisystem in eine Datenbank zu verwandeln ~ aber da entwickeln die namhaften Hersteller noch dran und ob es dann bezahlbar ist, bleibt zu hoffen.

Aus beruflicher Erfahrung habe ich gelernt, dass es keinen generellen Ansatz geben kann, da zum einen viele Daten anfallen, die z.B. automatisch generiert oder von vielen Benutzern erzeugt werden. Desweiteren schweben Wörter wie versioniertes Dateisysteme und ganz altbackende Backup-Strategien im Raum, die auch bedient werden wollen.

Die verschiedenen Ansätze, den Benutzer Hilfestellungen bzgl. seines eigenen Datenchaoses an die hand zu geben, verringern weiter die Chancen, dass man den genauen Lagerort seiner Daten kennt bzw. kennen gelernt hat :-)

Somit kann die Welt auf noch einen Ansatz für ein Dateisystem hoffen, der seinen Weg in die OpenSource Gemeinde finden möchte. Dies ist sowohl von meiner Zeit als auch von den anderen Entwicklungen abhängig. Ich würde mich hier sehr über ein schon existierendes, benutzbares System freuen...

existierende Projekte

(gefunden von Tammo und mir)

http://en.wikipedia.org/wiki/List_of_file_systems

eine Gesamt-Übersicht über div. Dateisysteme

http://en.wikipedia.org/wiki/CacheFS

Kommentar-TODO

http://en.wikipedia.org/wiki/GlusterFS

Kommentar-TODO

http://people.redhat.com/~dhowells/cachefs/FS-Cache.pdf

Kommentar-TODO

http://ian.blenke.com/projects/cornfs/cornfs.html

Kommentar-TODO

http://wiki.digitalbazaar.com/en/Starfish_Distributed_Filesystem

Kommentar-TODO

http://www.moosefs.com

Kommentar-TODO

http://www.math.uni-bielefeld.de/~hkaelber/rbg/cachefs.pdf

Kommentar-TODO

Sprachgebrauch

VFS

virtual file system bezeichnet das virutalisierte Dateisystem

VFS-API

vfs-abstract programming interface beschreibt das Zugriffsmodel auf die Daten

cachePool

Speicherort für die CacheObjects, die readonly vorliegen und höchstens gelöscht oder ausgelagert werden können

CacheObject

ist ein Datensatz, der mittels eines Hashs den Inhalt eindeutig identifiziert und mittest definierter Pfadstruktur im CachePool abgelegt ist. (z.B. cacheHash=md5sum und als Pfad: $cachePool/${md5:0:2}/${md5:2:2}/$md5 ~ somit erhält man 65356 Verzeichnisse auf 2 Ebenen à 256 Verzeichnissen, in denen dann die CacheObjects liegen)

CacheHash

ein Schlüssel, der den Inhalt des CacheObjects eindeutig beschreibt und deutlich kürzer sein sollte, als der Datei-Inhalt

workingDir

das Arbeitsverzeichnis, in dem CacheObjects schreibend geöffnet werden können oder aber auch zum Lesen dekomprimiert werden. Die hier gespeicherten Daten sind flüchtig (ggf. besteht sie nur aus der globalen Verzeichnisstruktur des VFS, falls dies einen Performance-Gewinn darstellt)

Path

Datei-Pfad einer Datei. An diesen Pfad können spezielle Attribute geknüpft sein, wie z.B. die Art des Cachings (local/cache/backup/versioned)

File

eine Datei im globalen ClusterCacheFS mit eigenen Attributen, wie diverse Zeitstempel, Berechtigungen. Mehrere Dateien aus unterschiedlichen Verzeichnissen verweisen dabei ggf. auf ein und dasselbe CacheObject. Dies reduziert Speicherplatz bei CUT-COPY-PASTE-Vorgängen, wie sie Nutzer heutzutage gerne an den Tag legen.

Master Mx

ein Knoten im ClusterCacheFS, der neben dem eigentlichen Cache auch noch eine Datenbank besitzt, die alle Meta-Daten speichert, welche Datei wie mit welchem CacheObject in Verbindung steht und auf welchen anderen Knoten, welche anderen Dateien existieren.

CacheNode Cxy

ein reiner Dateicache ohne eigene Datenbank (wohl aber z.B. mit einem lokalen memcache, damit die DB-Anfragen reduziert werden können)

GarbageCollector

(kurz: GC) der Aufräum-Prozess (auch bekannt von anderen Programmiersprachen), der in regelm. Zeitabschnitten die Datenbestände begutachtet und ggf. löscht/komprimiert/verifiziert

Features

Dazu erstmal eine Skizzierung, watt dat Dingen so alles können sollte:

• einer oder mehrere Rechner stellen ihren ungenutzten Festplatten-Speicher dem ClusterCacheFS zur Verfügung
• die Daten sollten im FS nur einmal abgelegt sein (md5-sha-hash o.ä.)
• wenn ein Programm eine Datei anfordert, die noch nicht im Cache ist, aber global vorhanden, so wird diese in den Cache transferiert
• das Ablegen in komprimierter Form sollte möglich sein
• möglichst viele Dateiattribute sollten möglich sein (beliebige?)
• unterschiedliche Dateien mit unterschiedlichen Attributen zeigen auf dasselbe Cacheobjekt

zu speichernde Daten

es gibt mindestens zwei getrennte Bereiche der Datenspeicherung. Zum einen der Bereich des CachePools, wo Daten bzgl. des CacheObjects gespeichert werden und zum anderen den Bereich des workDirs, wo Daten bzgl. Berechtigungen/Änderungs-Zeiten gespeichert werden.

Als dritten Bereich gibt es eine Orte, die z.B. globale Konfigurationen, Archiv-Daten, Historien, etc. speichern.

• CachePool-Daten
  • hash (primärer Schlüssel)
  • priority (ein Wert, der sich aus div. Faktoren errechnet und aussagt, wann dieses Objekt durch den GC gelöscht werden kann)
  • mimeType (von welchem Type sind diese Daten)
  • size (Größe des CacheObjects)
  • creationTime (modification fällt aus, da es dann ein neues CacheObject wird)
  • accessTime
  • accessHost (als longInt-IPv4 kodierter Wert)
  • creationHost (als longInt-IPv4 kodierter Wert)
  • flags (Attribute, die potentiell jedes CacheObjekt besitzen kann)
  • extended (Feld für freie Belegung mit benutzerspez. Attributen)
• workDir-Daten
  • hash (1.Teil des primärer Schlüssel ~ md5sum des Pfads und des Dateinamens, da der komplette Dateiname zu lang ist)
  • host (2.Teil des primären Schlüssels ~ IP-Adresse als longInt des Rechners auf dem diese Objekt unter diesem Pfad liegt)
  • path (Pfad zu der Datei)
  • name (Dateiname ~ kann leer sein, dann bezieht sich dies nur auf das Verzeichnis und cache ist auch leer)
  • cache (Verweis auf aktuelles CacheObjekt)
  • perms (Zugriffs-Berechtigungen à la UNIX-Octet 3*4=12 Bits)
  • uid (BenutzerID, dieser kann ggf. noch rechnerspezifisch gemappt werden)
  • gid (GruppenID, welcher auch ggf. noch rechnerspezifisch gemappt werden kann)
  • ctime (Zeit der Erstellung)
  • mtime (Zeit der letzten Modifikation)
  • atime (Zeit des letzten lesenden Zugriffs)
  • flags (Attribute, die potentiell jede Datei besitzen kann ~ ggf. sind auch noch obige Dinge hier einzubringen)
  • extended (Feld für freie Belegung mit benutzerspez. Attributen)
• sonstiges
  • mapHost (Übersetzt longInt-IPv4 zu Rechnernamen ~ kann aber auch via DNS erledigt werden)
  • mapUid (Übersetzt Benutzer-IDs zu Namen ~ kann Rechnerabhängig sein und ggf. via NIS/AD gelöst werden)
  • mapGid (Übersetzt Gruppen-IDs zu Namen ~ es gilt das gleiche, wie bei mapUid)
  • syslog (Tablelle mit Logging-Informationen ~ ERROR/WARINING/NOTICE/INFO/DEBUG wären Meldeklassen, die hostIP und die Zeit sollten neben der Meldung gespeichert werden)
  • search (Indiziert die Datenquellen, so dass eine Volltextsuche möglich gemacht wird ~ à la Google-Desktop/htdig/...)

beachtenswertes

Schlüssel der Datenbank

da es sich in den erweiterten Ausbaustufen um eine Master->Master Replikation handelt, müssen die Primär-Schlüssel (soweit vorhanden) eindeutig sein und können z.B. nicht auf autoincrement-Werten aufbauen. Hier bieten sich z.B. md5-Hashes eher an. Diese Hashes bestehen aus 32-Zeichen, welche eine HEX-Zahl representieren. Würde man diese als Zahl abspeichern, sparte man 16 Zeichen, würde dies aber als binär-String ablegen müssen, wenn die Datenbank keine Zahlen bis zu einem Bereich von 2^256 unterstützt (2^256=4^128=8^64=16^32=8^16 => 32 Zeichen 0-9a-f oder 16 Zeichen 0-255).

DB-Entlastung

die Datenbank kann unter Zuhilfenahme von lokalen Memory-Caches, die auf reinen Key=Value-Verfahren aufsetzten, deutlich entlastet werden ~ die Anzahl der Anfragen erhöht sich aber entsprechend

mögliche Betriebsmodi

realisierbar mittels...

VFS-API

• fuse für das lokale cacheSystem auf einem beliebigen cacheNode
• samba-vfs-Modul zur netzwerkweiten Bereitstellung als Windows-Share
• Apache2-Modul zur readonly-Bereitstellung bzw. als webDAV-Modul für den read-write-Modus

DB-API

• Memcache für die lokale Zwischenspeicherung der Daten
• mySQL für die Datenbank ~ für single-Installation mag auch sqllight funktionieren ~ es sollte aber eine Möglichkeit der Master->Master-Replikation existieren

single Mode

einfachste Variante

multiple Cache Mode (singel DB)

mehrere Cache Server

multiple Mode

mehere Cache- & Datenbank-Server

complete Mode

Komplett-Ausbau