Welches Netzwerk-File-Sharing-Protokoll bietet die beste Leistung und Zuverlässigkeit? [geschlossen]

Wir haben ein Setup mit ein paar Webservern, die auf Last verteilt sind. Wir möchten eine Art freigegebenen Netzwerkspeicher, auf den alle Webserver zugreifen können. Es wird als Speicherort für von Benutzern hochgeladene Dateien verwendet. Alles läuft unter Linux.

Sollen wir NFS, CIFS, SMB, Fuse + SFTP, Fuse + FTP verwenden? Es gibt so viele Möglichkeiten für Netzwerk-File-Sharing-Protokolle, dass es sehr schwierig ist, eine auszuwählen. Grundsätzlich möchten wir diese eine Freigabe nur dauerhaft auf mehreren Computern bereitstellen. Sicherheitsfunktionen sind weniger bedenklich, da nur die Server, auf denen sie installiert sind, auf das Netzwerk zugreifen können. Wir wollen nur, dass es zuverlässig und schnell funktioniert.

Welches sollten wir verwenden?

Ich stimme für NFS.

NFSv4.1 hat die parallele NFS-pNFS-Funktion hinzugefügt, die den parallelen Datenzugriff ermöglicht. Ich frage mich, welche Art von Clients den Speicher verwenden, wenn nur Unix-artig, dann würde ich mich basierend auf den Leistungsdaten für NFS entscheiden.

Die kurze Antwort lautet use NFS. Nach dieser Schießerei und meiner eigenen Erfahrung ist es schneller.

Aber Sie haben mehr Möglichkeiten! Sie sollten einen Cluster-FS wie GFS in Betracht ziehen, bei dem es sich um ein Dateisystem handelt, auf das mehrere Computer gleichzeitig zugreifen können. Grundsätzlich teilen Sie ein Blockgerät über iSCSI, das ein GFS-Dateisystem ist. Alle Clients (Initiatoren im iSCSI-Sprachgebrauch) können lesen und darauf schreiben. Redhat hat ein Whitepaper . Sie können auch das Cluster-FS- OCFS von Oracle verwenden , um dasselbe zu verwalten.

Das RedHat-Paper leistet gute Arbeit, indem es die Vor- und Nachteile eines FS-Clusters im Vergleich zu NFS auflistet. Grundsätzlich ist GFS die Mühe wert, wenn Sie viel Platz für die Skalierung benötigen. Im GFS-Beispiel wird auch ein Fibre-Channel-SAN als Beispiel verwendet. Dies kann jedoch auch ein RAID-, DAS- oder iSCSI-SAN sein.

Stellen Sie schließlich sicher, dass Sie sich mit Jumbo-Frames befassen. Wenn die Datenintegrität kritisch ist, verwenden Sie CRC32-Prüfsummen, wenn Sie iSCSI mit Jumbo-Frames verwenden.

Wir haben einen 2 Server Load-Blanacing-Webcluster. Wir haben die folgenden Methoden zum Synchronisieren von Inhalten zwischen den Servern ausprobiert:

• Lokale Laufwerke auf jedem Server werden alle 10 Minuten mit RSYNC synchronisiert
• Eine zentrale CIFS-Freigabe (SAMBA) für beide Server
• Eine zentrale NFS- Freigabe für beide Server
• Auf einem freigegebenen SAN-Laufwerk, auf dem OCFS2 ausgeführt wird , wurden beide Server bereitgestellt

Die RSYNC- Lösung war die einfachste, aber es dauerte 10 Minuten, bis Änderungen angezeigt wurden, und RSYNC belastete die Server so sehr, dass wir sie mit benutzerdefinierten Skripts drosseln mussten, um sie jede Sekunde anzuhalten. Wir beschränkten uns auch darauf, nur auf das Quelllaufwerk zu schreiben.

Das freigegebene Laufwerk mit der schnellsten Leistung war das OCFS2- Cluster-Laufwerk, bis es verrückt wurde und den Cluster zum Absturz brachte. Wir konnten mit OCFS2 keine Stabilität aufrechterhalten. Sobald mehr als ein Server auf die gleichen Dateien zugreift, steigt die Last über das Dach und die Server starten neu. Dies kann ein Trainingsfehler unsererseits sein.

Das nächstbeste war NFS . Es war extrem stabil und fehlertolerant. Dies ist unser aktuelles Setup.

SMB (CIFS) hatte einige Sperrprobleme. Insbesondere wurden Änderungen an Dateien auf dem SMB-Server von den Webservern nicht gesehen. SMB blieb auch hängen, wenn ein Failover über den SMB-Server ausgeführt wurde

Unsere Schlussfolgerung war, dass OCFS2 das größte Potenzial besitzt, jedoch eine Menge Analyse erfordert, bevor es in der Produktion eingesetzt wird. Wenn Sie etwas unkompliziertes und zuverlässiges wünschen, würde ich einen NFS-Server-Cluster mit Heartbeat für das Failover empfehlen.

Ich schlage vor, Sie POHMELFS - es ist von dem russischen Programmierer Evgeniy Polyakov erstellt und es ist wirklich sehr, sehr schnell.

In Bezug auf Zuverlässigkeit und Sicherheit scheint CIFS (auch bekannt als Samba), aber NFS "viel leichter" zu sein, und bei sorgfältiger Konfiguration ist es möglich, Ihre wertvollen Daten nicht vollständig jedem anderen Computer im Netzwerk auszusetzen ;-)

Keine Beleidigung für das FUSE-Zeug, aber es scheint immer noch ... frisch zu sein, wenn Sie wissen, was ich meine. Ich weiß noch nicht, ob ich dem vertraue, aber das könnte nur daran liegen, dass ich ein alter Nebelfleck bin, aber alter Nebelfleck ist manchmal gerechtfertigt, wenn es um wertvolle Unternehmensdaten geht.

Wenn Sie eine Freigabe dauerhaft auf mehreren Rechnern bereitstellen möchten und mit etwas Seltsamem (meistens UID / GID-Probleme) spielen können, verwenden Sie NFS. Ich benutze es und habe es seit vielen Jahren.

NFS. Es hat sich bewährt, und Sie können ein absolut solides Setup haben. Die GFS-Leistung ist im Allgemeinen schlecht, insbesondere auf Dateisystemen mit einer großen Anzahl kleiner Dateien. Ich habe kein OCFS verwendet, aber ich schätze das Konzept des Cluster-Dateisystems generell nicht ein. Dann gibt es Lustre, aber das ist eine andere Dose Würmer ...

Ich würde von NFS abraten. Einfach ausgedrückt: Wir hatten eine Webserverfarm, in der JBoss, Apache, Tomcat und Oracle NFS-Freigaben für gemeinsame Konfigurationsdateien und die Protokollierung verwendeten.

Als die NFS-Freigabe verschwand (zugegebenermaßen ein seltenes Ereignis), brach das Ganze gerade zusammen (wirklich vorhersehbar, und ich riet den 'Entwicklern' von dieser Abkürzung der Konfigurationszeit ab).

Es scheint ein Problem mit der von uns verwendeten NFS-Version zu geben, dass der Client, wenn das Ziel während eines Schreibvorgangs verschwindet, in eine unendliche Warteschleife gerät und darauf wartet, dass das NFS-Ziel zurückkommt. Auch wenn die NFS-Box wieder angeschlossen wurde, wurde die Schleife immer noch nicht beendet.

Wir haben eine Mischung aus RHEL 3,4,5 verwendet. Der Speicher war auf RHEL4, die Server auf RHEL5, das Speichernetzwerk war ein separates LAN und lief nicht auf VLANs.

Wenn ein Front-End mit Lastenausgleich vorhanden ist und der einzelne Speicher überprüft wird - würde dies nicht zu einem Engpass für Ihr System führen?

Haben Sie eine schreibgeschützte iSCSI-Verbindung zu Ihrem Speicher mit einem ereignisgesteuerten Skript in Betracht gezogen, um die hochgeladene Datei beim Hochladen einer Datei über ftp / scp in den Speicher zu verschieben?

Das einzige Mal, dass ich einen erfolgreichen zentralen Speicher für mehrere Leseköpfe implementiert habe, war ein EMC-Speicherarray ... Alle anderen kostengünstigen Versuche hatten ihre Nachteile.

Betrachtet man GFS? GFS ist ein Cluster-Dateisystem und meiner Erfahrung nach ziemlich zuverlässig. Es kann mehr als ein Tagebuch haben, es skaliert ziemlich gut

Sie müssten jedoch einige Clusterdienste installieren, und GFS ist nicht genau für seine Schnelligkeit bekannt. Otoh, es war immer schnell genug für mich, aber ymmv.

Sie haben keine Lust, einen verteilten FS wie GFS in Betracht zu ziehen, und iSCSI ist übertrieben.

Wenn Sie einfach wollen, gehen Sie mit NFS. Es ist einfach und schnell und mit weichen Halterungen ziemlich robust. Deaktivieren Sie auch den dazugehörigen Sperrmüll. Ich habe Linux-Desktops, die alle ihre Home-Verzeichnisse und Anwendungen von NFS abrufen, es funktioniert gut.

Wenn Sie eine unerhörte Geschwindigkeit wünschen, sollten Sie Lustre wählen, das erheblich einfacher einzurichten ist als GFS und dem RAID NFS sehr ähnlich ist. Wir verwenden Lustre für unsere Cluster.

Ich bin vielleicht etwas spät dran. Wir verwenden einen MD3220-Dell-Speicher mit Cluster-Dual-Port. Unser Gerät verfügt über 2 Controller, wenn einer ausfällt, läuft er weiter, bis wir das Problem behoben haben. Da HDD, Lüfter, Netzteil und Controller alle Hotswaps sind, tauschen wir Teile ein und aus. Ab Format verwenden wir NFS.

Wenn Sie bereits überall Webserver haben und gut damit umgehen können, ziehen Sie WebDAV in Betracht.

Einfache Antwort +1 für NFS. Ich habe NFS-Freigaben, die seit Jahren ohne Ausgabe hintereinander eingehängt wurden.

Wenn Sie auf der Suche nach höchster Zuverlässigkeit sind, sollten Sie DRBD auch für ein verteiltes NFS-Dateisystem mit automatischem Failover in Betracht ziehen.

Die einzige andere Option (mit der ich vertraut bin) ist iSCSI, aber die Konfiguration kann schwierig sein ...

Sie haben eine Reihe von Optionen mit einer Vielzahl von Kosten. Shared SAN mit FC, iSCSI oder einer der neueren Erweiterungen. In jedem Fall kann die Einrichtung teuer sein, und Sie müssen weiterhin ein clusterfähiges Dateisystem ausführen. Cluster-Dateisysteme sind eine Welt voller Schmerzen. Für jede Hoffnung auf Erfolg benötigen Sie separate Netzwerke mit hoher Geschwindigkeit und geringer Latenz für die Cluster-Kommunikation und -Daten. Trotzdem kann es zu Störungen kommen, die dazu führen, dass ein Knoten eingezäunt und getötet wird.

Das einzige Cluster-Dateisystem, auf das ich gestoßen bin, das problemlos funktioniert, ist VMFS. Aber das ist so spezialisiert, dass es keinen Nutzen hätte, selbst wenn es für den allgemeinen Gebrauch verfügbar wäre.

NFS ist wahrscheinlich der richtige Weg für Ihr Setup. Wenn Sie sich Sorgen über die Ausfallsicherheit machen, benötigen Sie eine ordnungsgemäße NFS-Cluster-Box. Sie können ein Homebrew-Setup durchführen, würden aber das obige Problem lösen. Beste Wette (wenn Sie das Geld haben), ist geclusterte NetApp-Filer. Es ist eine teure Option, aber das Clustering funktioniert problemlos. Nicht nur das, sie sind sehr schnell.

Ich würde die Warnung wiederholen, die einige gegen NFS gegeben haben - obwohl NFS wahrscheinlich die beste Wahl ist (so seltsam das klingt).

Ich hatte einen NFS-Client, den ich vom AC trennen musste, um mich auszuschalten, da der NFS-Server verschwunden war und der Client (im Kernel) das Entsperren oder Herunterfahren verweigerte, weil der NFS-Server weg war.

Um es richtig zu machen, würde ich durchgehend auf NFSv4 bestehen, mich an TCP-Verbindungen halten, Jumbo-Frames verwenden und einen NFS-Cluster verwenden. Sie können es sich nicht leisten, Ihren NFS-Server verschwinden zu lassen.

GFS ist ein ernsthaft schwarzer Voodoo. Der Arbeitsaufwand, der erforderlich ist, um einen einfachen Cluster mit zwei Clients zum Laufen zu bringen, ist im Vergleich zu den Alternativen umwerfend. OCFS2 ist viel einfacher zu implementieren, aber in Bezug auf die Kernelmodulversionen auf allen angeschlossenen Servern sehr wählerisch - und das ist erst der Anfang.

Sofern Sie nicht wirklich die Art von Low-Level-Zugriff benötigen, die ein Cluster-Dateisystem bietet, ist NFS oder CIFS wahrscheinlich alles, was Sie benötigen.

In einer großen Serverfarm hatten wir mehrere Millionen HTML-Seiten, die von Benutzern erstellt wurden. NFS hat nicht so gut funktioniert, also haben wir sie in eine MySQL-Tabelle eingefügt. Der Aufwand im Vergleich zum Durchsuchen eines Verzeichnisbaums war ungefähr gleich.

Ich habe SFTP verwendet und es hat für meine Zwecke gut funktioniert - NFS war mein erstes Mittel, aber die Unkonventionalität der Benutzer- / Gruppen-IDs hat mich dazu gebracht, es ziemlich schnell fallen zu lassen.

Richten Sie einfach publickey auth ein und Sie werden weitgehend eingestellt sein. Möglicherweise ist der CPU-Aufwand für die SSH-Verschlüsselung etwas höher, aber auf der positiven Seite habe ich noch nie Probleme mit der Datenbeschädigung festgestellt.

FTP könnte jedoch gut zu Ihren Zwecken passen, da es leichter ist. Vermutlich möchten Sie, dass Ihre Webserver das Web-Serving und nicht die SSH-Arbeit übernehmen.