Verteiltes, paralleles, fehlertolerantes Dateisystem

Eigentlich glaube ich nicht, dass es so viele realistische Optionen gibt. In der Reihenfolge der Präferenzen wäre meine Auswahl:

1. Amazon S3. Erfüllt alle Ihre Anforderungen und auch Ihre optionalen Qualitäten. Hat eine sehr gute Erfolgsbilanz in Bezug auf Verfügbarkeit und Support. Es ist nicht hausintern; aber ist das wirklich keine Anforderung, die Sie umgehen könnten, z. über VPN-Zugriff oder einfach nur das gute alte HTTPS ... S3 wäre wirklich meine erste Wahl, wenn die WAN-Latenz und die Preisgestaltung von Amazon für Sie funktionieren. Und wenn die Preisgestaltung für Sie nicht funktioniert, nun, ich bezweifle, dass eine DYI-Lösung am Ende wirklich deutlich billiger sein wird ...
2. MogileFS scheint perfekt zu Ihren Anforderungen zu passen. Es gibt nicht so viel Aktivität rund um MogileFS, aber das liegt hauptsächlich daran, dass es für seine (relativ wenigen) Benutzer wie beabsichtigt funktioniert.
3. Lustre hat wirklich großartige Technologie dahinter, ist ein reguläres lokales POSIX-Dateisystem (wenn das für Sie von Vorteil ist) und wurde im Laufe der Jahre kontinuierlich aktualisiert. Die große Frage ist, ob sich die ganze Sun-Oracle-Fusion auf Lustre auswirken wird. Langfristig, wenn Sun seine Karten richtig spielt, könnte es zu sehr netten Dingen führen, ZFS und Lustre unter einem Dach zu haben ... Im Moment denke ich, dass Lustre hauptsächlich in akademischen und kommerziellen HPC-Initiativen und nicht in Internetanwendungen verwendet wird -- das mag nicht wahr sein, aber wenn Lustre in Internetanwendungen gut abschneidet, dann werden sie diese Tatsache sicher nicht gut vermarkten...

Hadoop Distributed File System (HDFS) würde meiner Meinung nach nicht Ihren Anforderungen entsprechen. HDFS ist großartig, aber sein Bigtable-ähnlicher Ansatz bedeutet, dass es weniger zugänglich ist als die oben genannten Dateisysteme. Wenn Sie wirklich nach massiver Skalierbarkeit und einer langfristigen Perspektive suchen, ist HDFS möglicherweise genau das Richtige – da Yahoo, Facebook und andere in das Wachstum von Hadoop investiert haben.

Ein Kommentar, die meisten der oben genannten Systeme kopieren die gesamte Datei auf 2-3 Knoten, um Redundanz zu erreichen. Dies nimmt mcuh mehr Platz ein als Paritätscodierung / RAID-Schemata, aber es ist im Maßstab handhabbar und scheint die Lösung zu sein, die jeder genommen hat. Sie werden also nicht die von Ihnen erwähnte Effizienz von 75 % erreichen...

Wenn ich es wäre, würde ich GlusterFS verwenden. Die aktuelle Version ist ziemlich solide und ich kenne Leute bei einigen sehr großen Installationen sowohl im HPC- als auch im Internetbereich, die sich in ihren Produktionssystemen darauf verlassen. Sie können es grundsätzlich an Ihre Bedürfnisse anpassen, indem Sie die Komponenten so auslegen, wie Sie sie benötigen. Im Gegensatz zu Lustre gibt es keine dedizierten Metadatenserver, sodass zentrale Fehlerquellen minimiert werden und die Einrichtung einfacher skaliert werden kann.

Leider glaube ich nicht, dass es eine einfache Möglichkeit gibt, Ihre 75 %-Kriterien zu erfüllen, ohne die Leistung den Bach runter zu werfen.

Es läuft zwar auf handelsüblicher Hardware, aber die Leistung glänzt wirklich, wenn man Infiniband Interconnect verwendet. Glücklicherweise ist der Preis von IB heutzutage sehr niedrig.

Vielleicht möchten Sie sich die Jungs von Scalable Informatics und ihre Jackrabbit-Produkte als Lösung ansehen. Sie unterstützen GlusterFS auf ihrer Hardware, und der Preis ihrer Lösung konkurriert sicherlich mit den Kosten, um etwas von Grund auf neu zusammenzustellen.