MitHadoopUndCouchDBÜberall in Blogs und verwandten Nachrichten wird darüber gesprochen, was ein verteilter, fehlertoleranter Speicher (Engine) ist, der tatsächlich funktioniert.
- CouchDB hat eigentlich keine integrierten Verteilungsfunktionen, meines Wissens fehlt einfach der Klebstoff zum automatischen Verteilen von Einträgen oder sogar ganzen Datenbanken.
- Hadoop scheint sehr weit verbreitet zu sein – zumindest bekommt es gute Presse, hat aber immer noch einen einzigen Schwachpunkt: den NameNode. Außerdem ist es nur über FUSE einhängbar, ich verstehe, dass das HDFS nicht wirklich das Hauptziel von Hadoop ist.
- GlusterFShat ein Shared Nothing-Konzept, aber in letzter Zeit habe ich mehrere Beiträge gelesen, die mich zu der Meinung führen, dass es nicht ganz so stabil ist
- Lüsterhat auch einen Single Point Failure, da es einen dedizierten Metadatenserver verwendet
- Cephscheint der Player der Wahl zu sein, aber auf der Homepage heißt es, dass es sich noch im Alpha-Stadium befindet.
Die Frage ist also, welches verteilte Dateisystem über den folgenden Funktionsumfang verfügt (keine bestimmte Reihenfolge):
- POSIX-kompatibel
- einfaches Hinzufügen/Entfernen von Knoten
- Shared-Nothing-Konzept
- läuft auf billiger Hardware (AMD Geode oder VIA Eden Klasse Prozessoren)
- Authentifizierung/Autorisierung integriert
- ein Netzwerkdateisystem (ich möchte es gleichzeitig auf verschiedenen Hosts mounten können)
Schön zu haben:
- lokal zugängliche Dateien: Ich kann einen Knoten herunterfahren und die Partition mit einem standardmäßigen lokalen Dateisystem (ext3/xfs/was auch immer...) mounten und trotzdem auf die Dateien zugreifen
Ich binnichtIch bin auf der Suche nach gehosteten Anwendungen, oder eher nach etwas, das es mir ermöglicht, beispielsweise 10 GB von jeder unserer Hardware-Boxen zu nehmen und diesen Speicher in unserem Netzwerk verfügbar zu haben, sodass er problemlos auf einer Vielzahl von Hosts bereitgestellt werden kann.
Antwort1
Ich denke, Sie müssen die POSIX-Anforderung aufgeben, da nur sehr wenige Systeme diese implementieren – tatsächlich tut dies nicht einmal NFS (denken Sie an Sperren usw.) und das hat keine Redundanz.
Jedes System, das synchrone Replikation verwendet, wird furchtbar langsam sein; jedes System mit asynchroner Replikation (oder „Eventual Consistency“) wird die POSIX-Regeln verletzen und sich nicht wie ein „herkömmliches“ Dateisystem verhalten.
Antwort2
Zum Rest kann ich nichts sagen, aber Sie scheinen eine „verteilte Speicher-Engine“ und ein „verteiltes Dateisystem“ zu verwechseln. Das ist nicht dasselbe, man sollte sie nicht für dasselbe halten und sie werden nie dasselbe sein. Ein Dateisystem ist eine Möglichkeit, den Überblick darüber zu behalten, wo sich Dinge auf einer Festplatte befinden. Eine Speicher-Engine wie Hadoop ist eine Möglichkeit, einen durch einen Schlüssel identifizierten Datenblock zu verfolgen. Konzeptionell gibt es keinen großen Unterschied. Das Problem ist, dass ein Dateisystem eine Abhängigkeit einer Speicher-Engine ist … schließlich braucht es eine Möglichkeit, auf ein Blockgerät zu schreiben, oder nicht?
Abgesehen davon, ichdürfensprechen Sie über die Verwendung von ocfs2 als verteiltes Dateisystem in einer Produktionsumgebung. Wenn Sie die Einzelheiten nicht wissen möchten, hören Sie nach dieser Zeile auf zu lesen: Es ist irgendwie cool, aber es kann mehr Ausfallzeiten bedeuten, als Sie denken.
Wir haben OCFs2 in den letzten Jahren in einer Produktionsumgebung ausgeführt. Es ist OK, aber für viele Anwendungen nicht optimal. Sie sollten sich Ihre Anforderungen wirklich ansehen und herausfinden, was sie sind – Sie werden vielleicht feststellen, dass Sie viel mehr Spielraum für Fehler haben, als Sie dachten.
Beispielsweise verfügt ocfs2 über ein Journal für jede Maschine im Cluster, die die Partition mounten wird. Nehmen wir also an, Sie haben vier Web-Maschinen und wenn Sie diese Partition mit mkfs.ocfs2 erstellen, geben Sie an, dass es insgesamt sechs Maschinen sein werden, um sich etwas Spielraum für Wachstum zu geben. Jedes dieser Journale nimmt Speicherplatz ein, was die Datenmenge reduziert, die Sie auf den Festplatten speichern können. Nehmen wir nun an, Sie müssen auf sieben Maschinen skalieren. In dieser Situation müssen Sie diegesamteCluster (d. h. alle ocfs2-Partitionen unmounten) und mit dem Dienstprogramm tunefs.ocfs2 ein zusätzliches Journal erstellen, sofern Speicherplatz verfügbar ist. Erst dann können Sie die siebte Maschine zum Cluster hinzufügen (wofür Sie eine Textdatei an den Rest des Clusters verteilen müssen, sofern Sie kein Dienstprogramm verwenden), alles wiederherstellen und dann die Partition auf allen sieben Maschinen mounten.
Verstehen Sie, was ich meine? Es soll hochverfügbar sein, was „immer online“ bedeuten soll, aber genau dort haben Sie eine Menge Ausfallzeiten ... und Gott bewahre, dass Sie zu wenig Speicherplatz haben. Sie möchten NICHT sehen, was passiert, wenn Sie ocfs2 überlasten.
Bedenken Sie, dass EVMs, das früher die „bevorzugte“ Methode zur Verwaltung von OCFs2-Clustern war, zugunsten von ClVMd und LVM2 den Weg des Dodos gegangen ist. (Und auf Nimmerwiedersehen, EVMs.) Außerdem wird Heartbeat zugunsten des OpenAIS/Pacemaker-Stacks schnell zu einem Zombieprojekt. (Abgesehen davon: Wenn Sie die anfängliche Clusterkonfiguration für OCFs2 vornehmen, können Sie „PCMK“ anstelle von Heartbeat als Cluster-Engine angeben. Nein, das ist nicht dokumentiert.)
Wir sind jedenfalls zu einem von Pacemaker verwalteten NFS zurückgekehrt, da die wenigen Sekunden Ausfallzeit oder ein paar verlorene TCP-Pakete, wenn Pacemaker eine NFS-Freigabe auf eine andere Maschine migriert, im Vergleich zu der Ausfallzeit, die wir bei grundlegenden gemeinsam genutzten Speichervorgängen, wie dem Hinzufügen von Maschinen bei Verwendung von OCFs2, festgestellt haben, unbedeutend sind.
Antwort3
Ich verstehe Ihre Anforderungen vielleicht falsch, aber haben Sie sich angesehenhttp://en.wikipedia.org/wiki/Liste_der_Dateisysteme#Verteilte_Dateisysteme
Antwort4
Schauen Sie sich chirp anhttp://www.cse.nd.edu/~ccl/software/chirp/und Papageihttp://www.cse.nd.edu/~ccl/software/parrot/