Linux-Dateisystemoptionen für gemeinsam genutzten iSCSI-Speicher

Ich versuche, meine beste Wahl für ein Dateisystem zu ermitteln, das für ein gemeinsam genutztes Speichergerät verwendet werden soll, das über iSCSI auf einer unbestimmten Anzahl von Servern bereitgestellt wird.

Installieren:

• 27 TB Synology RS2212 + -Array, iSCSI-LUN / Ziel, das mehrere Sitzungen ermöglicht
• 10-20 CentOS-basierte Linux-Boxen, hauptsächlich Webserver
• Der gemeinsam genutzte Speicher hostet statische Webinhalte (Medien, hauptsächlich Bilder).

Im Wesentlichen muss ich in der Lage sein, dieses große gemeinsam genutzte Volume auf vielen Webservern bereitzustellen, und die Anzahl wird hoffentlich im Laufe der Zeit weiter zunehmen. Wir haben in der Vergangenheit NFS verwendet, aber Leistungsprobleme zwingen uns, andere Methoden zu untersuchen. (Lesen Sie: NFS-Tuning fühlt sich manchmal wie schwarze Magie an, besonders wenn es um Millionen kleiner Bilder geht).

Normalerweise sollte es kein Problem mit Schreibkollisionen auf dem Gerät geben, da es nur wenige zentrale Computer gibt, die den Inhalt ändern können, aber ich weiß, dass wir eine Methode benötigen, wenn wir sie als solche bereitstellen Sperren Sie die Datei, während Sie damit arbeiten, damit es nicht zu Beschädigungen kommt. In der Vergangenheit haben wir uns auf NFS verlassen, um dies zu handhaben. Jetzt schaue ich mir clusterfähige Dateisysteme an (es sei denn, mir fehlt etwas, daher dieser Beitrag).

Bisher habe ich zwei Hauptoptionen dafür gefunden, aber ich bin nicht sicher, ob sie gut zusammenpassen:

RHEL Clustering und GFS2 - scheinen die natürliche Passform für meine Umgebung zu sein, aber es macht mich ein bisschen vorsichtig, mich auf diese Weise in eine Distribution eingeschlossen zu fühlen. Würde mich zwingen, später andere Optionen zu finden, wenn ich Server mit einer anderen Variante hinzufügen muss. Kein Show-Stopper, aber in meinen Gedanken. Die größte Sorge ist das wiederholte Lesen aus RHEL-Dokumenten, dass ihr Cluster nur 16 Knoten unterstützt. Wenn das der Fall ist, wird es für mich definitiv nicht gut genug skalieren. Ist das richtig oder lese ich es falsch?

OCFS - Das Cluster-Dateisystem von Oracle erhält auch viel Aufmerksamkeit, wenn ich google, aber ich weiß nicht viel darüber. Der problematischste Aspekt dabei ist, dass ich den Unbreakable Enterprise Kernel ausführen müsste, was zu einer großen Störung beim Verschieben aller meiner Server führen würde. Auch hier kein Show-Stopper, aber ich brauche überzeugende Beweise, um diesen Weg zu gehen, insbesondere wenn ich diese Methodik ausprobiere.

Vermisse ich etwas Gibt es einen besseren Ansatz, den ich verwenden sollte? Ich habe sogar überlegt, die Architektur vollständig zu ändern, damit einige "Front-End" -Server die iSCSI-Partition bereitstellen und dann nach Bedarf NFS-Freigabe von ihnen durchführen und / oder einen Nginx-Reverse-Proxy verwenden können, um die Medien an die Webserver zu verteilen .

Haben Sie clevere Ideen, denen SIE in diesem Szenario vertrauen würden?

Für Ihren Fall würde ich mich immer noch an ein Netzwerk-Dateisystem halten. Sie sind bereits auf Skalierungsprobleme mit NFS gestoßen, daher ist es Zeit, sich etwas anderes anzuschauen. Es gibt ein paar gute Möglichkeiten:

• Glanz . Es handelt sich um ein RH-Projekt, das unter CentOS sehr gut unterstützt wird und auf "Way Lots" skaliert werden kann. Hunderttausende von Clients sind vollständig machbar, insbesondere in einer Umgebung mit vielen Lesevorgängen, in der Sie sich anscheinend befinden. Ich verwende sie derzeit mit Ubuntu, daher gibt es Unterstützung im Debian-Land.
• Ceph . Wie Gluster ist es ein Netzwerk-Dateisystem der nächsten Generation, das auch eine Direktmontagefunktion bietet. Auch für die Skalierung von "Way Lots" konzipiert. Es ist nicht wie Gluster an Red Hat gebunden.

Beide werden derzeit in der Cloud-Infrastruktur verwendet.

Direkt gemountete Dateisysteme wie gfs2 und ocfs haben wirklich, wirklich Skalierungsengpässe. Das systemübergreifende Problem der Dateisperrung, ganz zu schweigen von der hostübergreifenden Cache-Kohärenz, ist ziemlich schwer zu lösen und das Hauptproblem bei der Skalierung. Andere Cluster-Dateisysteme wie VMware's VMFS haben aus dem gleichen Grund ebenfalls "kleine Zehner" maximale Mount-Einschränkungen.

Netzwerk-Dateisysteme, die kein NFS sind, wurden für die Skalierung auf sehr große Parallelitäten entwickelt. Die oben genannten Optionen bieten sowohl Unterstützung für Duplikate als auch für verteilte Volumes, um Single-Point-of-Failure zu vermeiden.

Sie können eine flexible und starke Lösung verwenden, die Clustering, Multipathing, Multi Plex und Cache wie VXFS (Veritas Storage Fundation) mit SF-CACHE unterstützt. Wenn Sie Schreibkollisionen oder fs-Beschädigungen verbessern, können Sie das Dateisystem mit den Redologs von VXFS neu erstellen und eine zerkratzte Datenträgergruppe neu erstellen, wenn Hardware-Lun-Fehler auftreten.

PS: + OCFS wurde für Oracle Cluster DATABASE entwickelt, nicht für Webapps!