Und was kann das Ding nun?

[RcRaCk2k]

Super! Man findet nicht einmal bei WIKIPEDIA Daten über dieses FS, noch bei ORACLE selbst. Was genau sind die Vorteile, wie skaliert die Software, verwaltet sich die Software vollautomatisch (Replizieren / Storage-Erweiterung), oder kann ich als Nutzer selbst definieren, in welchem Verhältnis Daten repliziert werden sollen?

Wenn ich 100 Rechner habe, mit jeweils 2x 1TB HDD im RAID 0 (Performance), kann ich dann sagen, dass die Daten mind. 2x verfügbar sein sollen? und der Rest als Storage-Erweiterung dienen soll? Also 100 TB mit einfacher Redundanz? oder 50 TB mit 4x Redundanz?

CEPH finde ich besser und einfacher dokumentiert.

[Googler]

Wie wärs hier:
www.lustre.org

[sotho]

Im "einfachsten" Fall hat man einen Metadaten Server (fuer Dateinamen, Berechtigungen, Position der Daten, etc) und einen oder mehrere "Objekt Server", auf denen die eigentlich Daten liegen. Die Daten werden i.d.R. ueber die Objekt Server verteilt (striping), wie bei einem raid0. Kann man aber glaub ich einstellen.

Wenn man entsprechend viele Objekt Server hat, wird das lesen aus einer (grossen) Datei schnell.

Redundanz erreicht man durch Hardware. Ich hab es so kennen gelernt: die Storage Arrays haengen an 2 Objekt Servern und beim Ausfall eines Servers uebernimmt der Kollege das Array. Mit reduzierter Performance dann.

Skaliert wird ueber die Anzahl der Objekt Server. Mehr Server sind dann mehr Datendurchsatz und mehr Platz.

Metadaten Server hat man einen (bzw. es gibt noch einen Backup Server). Also fuer viele kleine Dateien ist Lustre kaum besser als z.b. nfs.

Aber fuer grosse Dateien mit vielen Clients (deswegen auch Supercomputing!) wird es sehr schnell -- weit jenseits von dem was nfs (mit einem Server) schaffen kann.

Vom installieren/administrieren: OMG -- renn ;-)


Mfg

[U.]

Ceph hat auf der Haben-Seite dei automatische Datenreplikation, das kann Lustre derzeit nicht. Aber Lustre beherrscht RDMA und Infiniband-Unterstützung. Beides fehlt bei Ceph und macht es daher fürs Supercomputing uninteressant.

U.

[RcRaCk2k]

Vielen Dank an Euch Beide. Das sind Informationen, mit denen man etwas anfangen kann :-D

Leider sind die Informationen bei LUSTRE schlecht angesiedelt. Das WIKI scheint auch keins in dem Sinne zu sein, wie man sich ein WIKI vorstellt. Lediglich als Ablage für PDF Dokumente dient es... Außer ich habe den richtigen Weg ins WIKI noch nicht gefunden ;-)

Mir geht es darum, eine große Web-Application, die auf Cache-Files basiert in einem Cluster gut, schnell und performant betreiben zu können. Wenn es sich bei LUSTRE lediglich um ein STRIPE handelt, dann ist das für mich uninteressant. Im Netz müssen unter 100 Nodes alle Daten immer Redundant zur Verfügung stehen und nicht die Hardware, die die Daten besitzt. Das ist Aufgabe der Nodes.

Infiniband macht bei STRIPES natürlich aufgrund des hohen Datendurchsatzes sinn. CEPH und LUSTRE haben anscheinend nicht viel miteinander gemeinsam.

[sotho]

hmm,

das problem mit lustre und aehnlichen globalen dateisystemen: die metadaten performance skaliert nicht. d.h. gerade fuer deinen anwendungsfall sind die eher mist. bei ceph weiss ichs nicht so genau -- aber ceph ist ja auch noch nicht fertig.

was haelst du davon: ein nfs server mit den eigentlichen dateien. und die clients (die dann auch webserver sind) mounten das nfs und nutzen die lokale platte als cache (mittels cachefs). wenn die dateien sich nicht aendern, wird der nfs server kaum belastet. oder?

siehe: http://lwn.net/Articles/100321/