Kopieren via NFS - sehr langsam

Errorsmith

Errorsmith

Kompiliertier
Hi

Ich ziehe gerade eine Anzahl von HDD Images von einem Rechner auf den anderen um.
Dazu habe ich das Verzeichnis des Quellrechners auf dem Zielrechner via NFS eingehängt und rsync darauf losgelassen.
Das gesamte Konstrukt kopiert nun mit 10-12MB/sec. Das ist weit unter dem was das Netzwerk hergibt.
Damit ich irgendwann auch fertig werde, wüsste ich gern woran das liegt bzw würde es gern schneller bekommen.

Quellrechner:
Normaler PC, FreeBSD 9, i5 QuadCore, 32GB Speicher, 5x3TB zraid2 (SATA 600 Disks)
Angebunden mit einer Intel 1GBit Karte

Zielrechner:
Dell Poweredge R510, 2xXEON, 32GB Speicher, 5x3TB zraid2 (SATA 600 Disks) mit SSD Cache
Angebunden mit 2xBroadcom 1GBit als lagg

Netzwerk:
Die Rechner sind mit einem HP Procurve 1910 verbunden der sauber konfiguriert ist und nachweislich funktioniert wie er soll.

Bisher getestet:
- bonnie++ auf dem Quell- & Zielrechner -> akzeptable Werte
- Netzwerkdurchsatz -> Ich kann die Gbit Verbindung voll auslasten
Nicht getestet: ich habe aktuell nichts um die 2Gbit lagg Verbindung komplett auszulasten. GBit würde mir zum kopieren aber erstmal reichen. Scheinbar wirds also erst langsam wenn ich NFS ins Spiel bringe.
Wie kann ich das nun schneller bekommen bzw den Flaschenhals finden?

Grüße,
errorsmith
 
Ich meine mich zu erinnern, dass es mit NFS und ZFS da mal erhebliche Performanceprobleme gab. Hast du ein schnelles und ausreichend großes ZIL in deinem ZFS?
 
Hi
Im Quellrechner: Keines.
Im Zielrechner dieses:
Code: 
[root@billy ~]# zpool status vm
  pool: vm
 state: ONLINE
  scan: none requested
config:

        NAME             STATE     READ WRITE CKSUM
        vm               ONLINE       0     0     0
          raidz2-0       ONLINE       0     0     0
            gpt/vm-d0    ONLINE       0     0     0
            gpt/vm-d1    ONLINE       0     0     0
            gpt/vm-d2    ONLINE       0     0     0
            gpt/vm-d3    ONLINE       0     0     0
            gpt/vm-d4    ONLINE       0     0     0
        logs
          mirror-1       ONLINE       0     0     0
            gpt/vm-zil1  ONLINE       0     0     0
            gpt/vm-zil2  ONLINE       0     0     0
        cache                                                                                                                                                
          gpt/vm-arc1    ONLINE       0     0     0
          gpt/vm-arc2    ONLINE       0     0     0

errors: No known data errors
die vm-zil ist dabei 2x4GB auf 2 SSD, der arc 2x12GB auf 2 SSD

Grüße,
errorsmith
 
auf meinem alten FreeBSD NAS habe ich noch 7.4 laufen und da ist tatsächlich NFS nicht so super schnell, es macht immer wieder Denkpausen. Die schnellste Verbindung dort ist ftp und das ist ja auch ganz einfach einzurichten und zu benutzen. Vielleicht wäre das eine Alternative.
Ferner habe ich häufiger gelesen, dass es Unverträglichkeiten verschiedener NFS-Versionen gibt. Also etwa zwischen NFS3 und NFS4 und zwischen NFS von ZFS oder NFS aus dem System. Mehrfach habe ich gelesen, NFS3 zu benutzen, könnte helfen.
Man kann ausgiebige Versuche mit den diversen Mount-Optionen durchspielen und testen, ob das etwas bringt. Ich bringe immer wieder gern ein Beispiel mit einem busybox/Linux in meinem kleinen Netz, wo ich mit viel Versucherei so etwas wie dies als sehr viel besser herausgefunden habe, als es der Standard war: rw,v3,rsize=16384,wsize=16384,hard,udp,lock. rsize und wsize sind eher kleine Werte, das Gerät hat aber 10MB Netz und da hat das sich eben bewährt. Also, nicht als Geheimtip gedacht, sondern als Beispiel, wo man überall drehen und versuchen kann, etwas zu optimieren.
 
Hi

Ich hatte vergessen das zu erwähnen. Auf beiden Systemen läuft NFS3, die Verzeichnisse sind "auf die altmodische Art" über /etc/exports freigegeben. Zu den Experiemnten:
Ich kann/will zumindest den Quellrechner nicht einfach durchstarten da einerseits noch Dienste darauf laufen und andererseits ich nicht 100% sicher bin ob er danach wieder sauber hochkommt, was auch der Grund dafür ist das ich ihn auf 9 gelassen habe anstatt zu updaten. Gibt es irgendwelche Dinge mit denen ich NFS als definitve Ursache für mein Performance-Problem festnageln kann? Ich frage auch, da der ursprüngliche Plan vorsieht die Images vom ESXi via NFS einzubinden. Mit 10MB/sec wird das aber nicht allzuviel Spaß machen... :-(

Grüße,
errorsmith.
 
Nachtrag da ich meinen Beitrag nicht bearbeiten kann:
Mit scp komme ich auf 90MB/sec, was in etwa dem entspricht was ich erwarte...

Grüße,
errorsmith
 
Das Problem kenne ich noch vom Zugriff auf mein FreeNAS. Ich habe NFS schliesslich aufgegeben und nutzt nur noch CIFS.
 
Auf das CIFS kann aber der ESXi nicht zugreifen und es macht in einer reinen Linux/BSD Umgebung ohne Windows-Büchsen auch nur bedingt Sinn...
Für den ESXi könnte ich noch iSCSI testen, aber insgesamt hätte ich gern brauchbare Performance im NFS. Ich habe inzwischen eine Kiste mit Linux drangehängt - hier ist die Performance akzeptabel.

Grüße,
errorsmith
 
Errorsmith schrieb:
Im Quellrechner: Keines.
Zum Vergrößern anklicken....
Das ist das Problem. NFS ist ein synchrones Dateisystem, d.h. jede Schreiboperation, die auf dem Server ausgeführt wird, wird als persistent garantiert. Um das zu erreichen wird das zugrundeliegende Dateisystem nach jeder Operation zu einer Synchronisierung aller Caches gezwungen. Ohne dediziertes Log-Devices verhagelt das Performance. Mit CIFS ist die Performance lediglich besser, da es geringere Persistenzgarantien gibt. Als Würg-Around kannst du die ZIL auf dem NFS-Server abschalten. Da gab es ein Tuneable für, was in der loader.conf gesetzt wird. Aber das untergräbt ZFS Persistenzgarantien und sollte auf keinen Fall eine Dauerlösung sein.
 
Yamagi schrieb:
Das ist das Problem. NFS ist ein synchrones Dateisystem, d.h. jede Schreiboperation, die auf dem Server ausgeführt wird, wird als persistent garantiert. Um das zu erreichen wird das zugrundeliegende Dateisystem nach jeder Operation zu einer Synchronisierung aller Caches gezwungen. Ohne dediziertes Log-Devices verhagelt das Performance. Mit CIFS ist die Performance lediglich besser, da es geringere Persistenzgarantien gibt. Als Würg-Around kannst du die ZIL auf dem NFS-Server abschalten. Da gab es ein Tuneable für, was in der loader.conf gesetzt wird. Aber das untergräbt ZFS Persistenzgarantien und sollte auf keinen Fall eine Dauerlösung sein.
Zum Vergrößern anklicken....
Ist das auch ein Problem am Quellrechner? Der macht dabei doch kaum Schreiboperationen, oder?
 
Der Quellrechner war doch der NFS-Server, oder? Dann macht der auch bei lesenden Operationen dank atime bei jedem Block einen Cache-Flush. Da kann es aber tatsächlich Wunder wirken die Blocksize hochzudrehen. 'rsize' und 'wsize' sind die Mountoperationen von FreeBSDs NFS-Client. Sollte man beide gleich auf 32768 setzen.
 
Hi

@Yamagi:
Ja, Quellrechner war der NFS Server. Beim test mit SCP "Schiebt" der Quellrechner die Date auf das neue Storage.

Ein Workaround den ich nutze bis ich die Daten von der Kiste runter hab wäre akzeptabel. Vorzugsweise allerdings einer bei dem ich die Kiste nicht neustarten muss. SCP läuft bisher relativ gut. Ich hoffe das ich die VM's zu denen die Images gehören heute abend wieder hochfahren kann.

Ein anderes Problem ist dann allerdings die HD Images via NFS dem ESXi anzubieten. Bisher hatte ich ein NFS Share auf dem ESXi eingehöngt und dort die VM's angelegt. In ersten Tests mit dem alten Rechner (oben als Quellrechner bezeichnet) hat das auch funktioniert - ich habe allerdings keine Benchmarks durchgeführt. Im neuen Storage soll das dann "live" gehen und natürlich etwas mehr Durchsatz bringen als 10MB/sec.

Insgesamt sehe ich 3 Optionen:
- NFS Share im ESXi als Datastore mounten (das ist das aktuelle Setup) -> scheint langsam zu sein
- HD Images mit istgt als iSCSI target bereitstellen. -> hatte ich früher arge Probleme mit
- ein Dataset direkt via iSCSI bereitstellen -> noch nie versucht

Hat einer von euch mit den letzten beiden Optionen Erfahrung? Oder Tips zur Performance?
Auf dem alten Rechner habe ich iSCSI versucht, allerdings spricht der ESXi die targets in einer Weise an die mir den iSCSI Dienst regelmäßig gecrasht haben. Wenn ich den Dienst aus dem base genutzt habe sogar den ganzen Rechner. Daher bin ich auf das NFS share ausgewichen. Ich weiß allerdings nicht mehr genau was das Problem war, nur das er regelmäßig die Logs zugemüllt hat und das Ergebnis meiner Lösungsversuche dazu geführt hat das ich das Problem als unlösbar verbucht habe.

Wie funktioniert das mit dem Bereitstellen von ZFS Datasets via iSCSI? Der ESXi (oder jedes andere System) möchte ja gern ein anderes FS drauf formatieren. Und inwiefern verliere ich die Vorteile von ZFS wenn das Dataset nur noch ein Container ist bei dem es den Inhalt nicht kennt?

Grüße,
errorsmith
 
Ich will mich nicht zu weit rauslehnen, aber ich denke, dein alter Quellrechner, den du nun nicht mehr wieder starten willst, wird ja nach der cp-Aktion wohl entsorgt oder dann eben runderneuert. Dein neuer Rechner hat doch bessere HW. Er wird doch in Zukunft erst zum NFS-Server und er wird das dann besser hinbekommen. Oder verstehe ich falsch?
Es geht doch nun zunächst darum, die Images einigermaßen schnell rüber zu ziehen und dann erst darum, sie neu zu exportieren.

Du sagst, scp ist schnell genug im Vergleich zum Datentransfer über gemountete NFS-Shares. Da stellt sich mir die Frage sofort: warum nicht das gleich nehmen? rsync als die modernere und in meinen Augen auch bessere Alternative kopiert doch direkt von Rechner zu Rechner. Warum ich da nicht gleich drauf gekommen bin? Damit kannst du alle Images transferieren und dann erst sehen, wie du den neuen Rechner als Server aufmotzen kannst.
 
Hi

Im Prinzip hast du recht, mir reicht es erstmal die Images zügig von der alten Kiste weg zu bekommen, dazu reicht das scp (es sind nicht allzuviele). Auf dem neuen muß ich nicht wirklich etwas "aufmotzen" - der hat genug Leistung. Maximal ein wenig RAM könnt ich ihm noch spendieren. Der alte ist ein Skylake Intel Core i5 mit 32GB RAM und wird vermutlich ein Desktop Rechner werden.

Ich habe inzwischen mal istgt mit einem zvol getestet. Das habe ich via iSCSI auf dem ESXi eingebunden und bekomme aus dem Gast-OS heraus 120MB/sec sowohl lesend als auch schreibend. Vermutlich geht da noch deutlich mehr - hier war eindeutig das Netzwerk die "Bremse". Nach dem Umzug wird der ESXi mit 2 NIC's angebunden, das Storage hat bereits zwei. Das sollte dann für meine Zwecke mehr als ausreichend sein. Damit wäre die Frage nach dem Storage für den Virtualisierer geklärt. Ich muß nur die Images in zvols "konvertieren" (Also die Daten umkopieren)

Dennoch hätte ich natürlich auch gern aus FreeBSD heraus einigermaßen schnellen Zugriff via NFS und daher frage ich mich warum die Kombination FreeBSD <--NFS--> FreeBSD so langsam ist während Linux <---NFS--->FreeBSD (und umgekehrt) diese Probleme nicht hat. Das Storage soll noch einen zweiten zraid2 Pool für Daten bekommen (Home Verzeichnisse, Musik, Filme etc) der via NFS exportiert wird. Darauf wird von Linux und FreeBSD Clients zugegriffen - 10MB/sec sind nicht wirklich schön um mal einen Film zu schauen etc, auch die Home-Verzeichnisse hätt ich gern schneller.

Grüße,
errorsmith
 
ich habe auf Servern auch die Konfiguration FreeBSD <-> NFS/ZFS <-> FreeBSD und sehe keine so schlechten Werte... Wenn ich allerdings nur synchronisiere, nutze ich rsync - damit dann auch die Attribute erhalten bleiben...
VG Norbert
 
Hallo,

Desktop-PC: Intel Quadcore, 12 GB DDR3 Ram, FreeBSD 11 amd 64 mit zfs
NAS: AMD-Quadcore, 8 GB DDR3 Ram, FreeBSD 11 amd 64 mit zfs und NFS3 Shares

Kopieren von einer ca. 600 MB großen Datei vom PC auf das NAS: ca. 90 MB/s
Kopieren von einer ca. 600 MB großen Datei vom NAS auf den PC: ca. 85 MB/s

Allerdings gebe ich zu, etwas mit "dem Feuer" zu spielen, weil ich für die Daten-Sets die Option
Code: 
zfs set sync=disabled
gesetzt habe.
 
Errorsmith schrieb:
Nach dem Umzug wird der ESXi mit 2 NIC's angebunden, das Storage hat bereits zwei.
Zum Vergrößern anklicken....
Das wird nichts bringen ;-) Die zwei NICs bekommst du nur von zwei verschiedenen Rechnern (MAC Adressen) ausgelastet. Eine Verbindung zwischen zwei Hosts wird durch ein Bonding nicht schneller.
Errorsmith schrieb:
Dennoch hätte ich natürlich auch gern aus FreeBSD heraus einigermaßen schnellen Zugriff via NFS und daher frage ich mich warum die Kombination FreeBSD <--NFS--> FreeBSD so langsam ist während Linux <---NFS--->FreeBSD (und umgekehrt) diese Probleme nicht hat.
Zum Vergrößern anklicken....
Der @Yamagi hat es doch erklärt. Und in deinem neuen Host hast du doch auch ein Log Device, da hast du das Problem dann doch gar nicht mehr.
 
derOliver schrieb:
Das wird nichts bringen ;-) Die zwei NICs bekommst du nur von zwei verschiedenen Rechnern (MAC Adressen) ausgelastet. Eine Verbindung zwischen zwei Hosts wird durch ein Bonding nicht schneller.
Zum Vergrößern anklicken....
Das ist korrekt. https://www.freebsd.org/cgi/man.cgi?lagg(4) Theoretisch ist bei einer einzigen TCP Verbindung das RoundRobin Verfahren möglich. Praktisch hat man aber eher Einbußen als Gewinn. LACP kann nicht eine einzige NFS Verbindung beschleunigen. Ein zweiter SCP Vorgang hingegen ließe sich verteilen. Das moderne pNFS habe ich unter BSD noch nicht im Einsatz gesehen.
 
Jau, das Log-Device im neuen Server dürfte das Problem lösen. Gerade, wenn man die rsize und wsize Mountoptionen nutzt und sehr große Blöcke erzwingt. Das dürfte auch den Performance-Vorteil von Linux-Clients erklären. Viele Distros kommen schon in Standardeinstellung mit mindestens 16 Kilobyte Blöcken. Große Blöcke wirken übrigens noch besser, wenn man Jumbo-Frames nutzt, da der TCP- und IP-Overhead sinkt.
 
@holgerw Du bist nicht alleine, für die nicht wichtigen VMs (Lab/Tests) hab ich auch ein Dataset mit "sync=disabled".

@Yamagi Das SLog wird das Problem nicht lösen, aber mindern, meine letzte Messung mit SLog Device ergab bei "sync=enabled" irgendetwas um die 40-50 MB/s (schneller wird es bei mir einfach nicht).
 
Hi

Der eigentlich Umzug ist soweit durch, die Images sind auf dem Zielrechner angekommen. Aufgrund der Erfahrungen in den letzten Tagen, habe ich beschlossen die Images zu zvols zu "konvertieren" und diese via iSCSI anzubinden. Das sieht bisher gut aus. Die "normalen Daten" werden weiterhin als NFS share angebunden - da werde ich in den kommenden Tagen ein wenig herum experimentieren. Habe ich das richtig verstanden, das die relevanten Optionen nur beim Client zu setzen sind und nicht beim Server? Sync=disabled" möchte ich eigentlich nicht setzen. Gibt es bei den Jumboframes irgendwelche Nachteile die ich im Hinterkopf behalten sollte?

Eines noch zum lagg-device: Wie oben ja angedeutet, ist der Rechner "dual use": Einerseits nutze ich ihn als storage für einen ESXi, andererseits als normalen (NFS) Fileserver. Insofern sollten genug unterschiedliche Verbindungen zusammen kommen. Da das ganze "daheim" statt findet, sollten 2Gbit auch ausreichen. Auf das Storage sollen ohnehin nur VM die nicht viel I/O verursachen, sowie meine "Spielwiesen". Welche Option hätte ich eigentlich falls das nicht ausreicht? Würde Mutlipath iSCSI über zwei Netzwerkkarten helfen (und ist das mit FreeBSD umsetzbar)?

Grüße,
errorsmith
 
Errorsmith schrieb:
Habe ich das richtig verstanden, das die relevanten Optionen nur beim Client zu setzen sind
Zum Vergrößern anklicken....
sofern es die mount-Optionen angeht, ja.

Wenn man die mount-Optionen nicht setzt, sollte ein günstiges Verfahren ausgehandelt werden. Meiner Erfahrung nach bedeutet günstig dabei aber: Verbindung gelingt. Optimierte Verbindung spielt hier keine Rolle und muss dann manuell gesetzt, bzw ausprobiert werden.
Neben rsize und wsize gibt es weitere Möglichkeiten, die weniger Performance als Stabilität ausmachen. Du kannst in meinem Beispiel oben eine Ahnung bekommen, was man da noch so probieren kann. Wieder. mein Beispiel ist nicht für FreeBSD <-> FreeBSD optimiert, es betrifft einen ganz speziellen Cient-Type und eine ganz spezielle Aufgabe (es werden Filme als .ts Stream vom Client auf den Server aufgenommen). Gerade der Punkt UDP kann aber auch in Richtung Performance wirken.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben