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


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

Sollten wir NFS, CIFS, SMB, Sicherung + SFTP, Sicherung + FTP verwenden? Es gibt so viele Möglichkeiten für Netzwerk-File-Sharing-Protokolle, es ist sehr schwer, einen auszuwählen. Im Grunde wollen wir diese eine Freigabe nur auf mehreren Rechnern dauerhaft installieren. Sicherheitsmerkmale sind weniger von Bedeutung, da sie von keinem anderen als dem Server aus zugänglich sind, auf dem sie installiert ist. Wir wollen nur, dass es zuverlässig und schnell funktioniert.

Welchen sollten wir verwenden?


34
2018-05-29 14:03


Ursprung


Das Leben ist viel einfacher, wenn Sie einen Beschleuniger vor Ihrer Website hinzufügen, z. Tintenfischbeschleuniger oder cloudflare. Als nächstes wird der geänderte Inhalt in Memcache oder Datenbank anstelle von Dateien geschrieben. Freigegebene Verzeichnisse sind nicht für größere Sites. - anttiR


Antworten:


Ich stimme für NFS.

NFSv4.1 hat die Funktion Parallel NFS pNFS hinzugefügt, die einen parallelen Datenzugriff ermöglicht. Ich frage mich, welche Art von Clients den Speicher verwenden, wenn nur Unix-wie dann würde ich für NFS auf der Grundlage der Leistungszahlen gehen.


28
2018-05-29 14:15



+1 für die Info zu Parallelem NFS - Ophidian


Die kurze Antwort ist NFS verwenden. Demzufolge Schießerei und meine eigene Erfahrung ist schneller.

Aber du hast mehr Möglichkeiten! Sie sollten einen Cluster-FS wie GFS in Betracht ziehen, ein Dateisystem, 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 darauf lesen und schreiben. Redhat hat eine weißes Papier . Sie können auch den Oracle Cluster FS verwenden OCFS um das Gleiche zu schaffen.

Das redhat-Papier macht einen guten Job, indem es die Vor- und Nachteile eines Clusters FS vs NFS auflistet. Grundsätzlich, wenn Sie viel Platz zum Skalieren möchten, ist GFS wahrscheinlich die Mühe wert. Das GFS-Beispiel verwendet ebenfalls ein Fibre-Channel-SAN als Beispiel, das könnte aber auch ein RAID-, DAS- oder iSCSI-SAN sein.

Zu guter Letzt sollten Sie sich Jumbo-Frames ansehen, und wenn die Datenintegrität kritisch ist, verwenden Sie CRC32-Checksummen, wenn Sie iSCSI mit Jumbo-Frames verwenden.


21
2018-05-29 14:25



einige Zahlen hier drüben: forum.neurostechnology.com/index.php?topic=9263.0 - naught101
und hier: wdtvforum.com/main/index.php?topic=5393.0 - naught101
Whitepaper-Link funktioniert nicht mehr - meffect


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

  • Lokale Laufwerke auf jedem Server, mit dem synchronisiert wurde RSYNC alle 10 Minuten
  • Eine zentrale CIFS (SAMBA) Freigabe für beide Server
  • Eine zentrale NFS Freigabe für beide Server
  • Ein freigegebenes SAN-Laufwerk wird ausgeführt OCFS2 hat beide Server gemountet

Das RSYNC Die Lösung war die einfachste, aber es dauerte 10 Minuten, bis Änderungen auftraten und RSYNC die Server so stark belastete, dass wir sie mit einem benutzerdefinierten Skript drosseln mussten, um es jede Sekunde anzuhalten. Wir waren auch darauf beschränkt, nur auf das Quelllaufwerk zu schreiben.

Die schnellste gemeinsame Festplatte war die OCFS2 Clustered Drive bis es verrückt wurde und den Cluster abgestürzt. Mit OCFS2 konnten wir keine Stabilität erreichen. Sobald mehr als ein Server auf dieselben Dateien zugreift, laden Sie sich durch 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 derzeitiges Setup.

SMB (CIFS) hatte einige Sperrprobleme. Insbesondere Änderungen an Dateien auf dem SMB-Server wurden von den Webservern nicht gesehen. SMB tendierte auch dazu, zu hängen, wenn der SMB-Server fehlschlug

Unser Fazit war, dass OCFS2 das größte Potenzial hat, aber viel Analyse benötigt, bevor es in der Produktion verwendet wird. Wenn Sie etwas geradliniges und zuverlässiges wollen, würde ich einen NFS-Server-Cluster mit Heartbeat für Failover empfehlen.


17
2018-05-29 14:48



Wir hatten die gleiche Erfahrung mit OCFS2: es ist großartig ... bis es abstürzt. - MiniQuark


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


5
2018-05-29 14:41





In Bezug auf Zuverlässigkeit und Sicherheit, wahrscheinlich CIFS (alias Samba), aber NFS "scheint" viel leichter, und mit sorgfältiger Konfiguration ist es möglich, Ihre wertvollen Daten nicht vollständig jedem anderen Rechner im Netzwerk auszusetzen ;-)

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

Wenn Sie eine Freigabe dauerhaft auf mehreren Rechnern mounten möchten und Sie einige der Seltsamkeiten (meistens UID / GID-Probleme) mitspielen können, dann verwenden Sie NFS. Ich benutze es und habe seit vielen Jahren.


3
2018-05-29 14:08



FUSE selbst ist nicht so neu, also würde ich darauf vertrauen, aber einige der Dateisysteme darauf gebaut sind neu und definitiv einige gesunde Skepsis. Was übersetzt in der realen Welt zu mehr Tests mindestens übersetzt :) - pjz


NFS. Es ist erprobt und wahr, und Sie können eine solide Grundlage haben. GFS-Leistung ist im Allgemeinen schrecklich, besonders auf Dateisystemen mit vielen kleinen Dateien. Ich habe OCFS nicht verwendet, aber ich verachte generell das Cluster-Dateisystem-Konzept. Dann gibt es Lustre, aber das ist eine andere Dose Würmer ...


2
2018-05-29 14:32





Ich würde von NFS abraten. Einfach gesagt - wir hatten eine Webserver-Farm, mit JBoss, Apache, Tomcat und Oracle, die alle NFS-Freigaben für gemeinsame Konfigurationsdateien und Protokollierung verwenden.

Als die NFS-Freigabe verschwand (zugegebenermaßen ein seltenes Vorkommnis), brach das Ganze einfach zusammen (vorhersehbar, und ich riet den 'Entwicklern' gegen diese Konfigurationszeitverknüpfung).

Es scheint ein Problem mit der von uns verwendeten Version von NFS zu geben. Wenn das Ziel während eines Schreibvorgangs verschwand, würde der Client in eine nie endende Warteschleife fallen und darauf warten, dass das NFS-Ziel zurückkommt. Selbst wenn die NFS-Box wieder angeschlossen wurde - die Schleife wurde immer noch nicht beendet.

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

Wenn ein Frontend mit Lastausgleich vorhanden ist und ein einzelner Speicher überprüft wird - würde dies Ihr System nicht zu einem Engpass führen?

Haben Sie eine schreibgeschützte iSCSI-Verbindung zu Ihrem Speicher in Betracht gezogen, mit einem ereignisgesteuerten Skript, um die hochgeladene Datei per FTP / scp in den Speicher zu verschieben, wenn eine Datei hochgeladen wird?

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


1
2018-05-29 14:26