schlechte NFS performance beim clonen oder kopieren

[motions]

In der Firma setzen wir vsphere 5.5 auf 6 Stück ESXi Hosts mit EMC VNX und Netapp Storages ein. Alle Datastores sind per NFS über 10GBEthernet verbunden und laufen gut.
Nun haben wir festgestellt, das die Performance beim clonen (oder manuellen 'cp' auf der ESXi console) weit unter den erwarteten Werten bleibt.
Mehr als 50MB/s kriegen wir nicht. Greife ich mit einem PC und 10GBE Karte auf die gleichen Systeme per CIFS zu, so bekomme ich locker 250MB/s.
Netzwerk-Probleme schliesse ich hier also mal aus.

Weitere Versuche haben wir gemacht mit anderen NFS Systemen (billige QNAP, Windows 7 mit NFS-Server [Hanewin nfs, FreeNFS], Freenas auf Desktop-PC mit 10GBE ... irgendwo nur zwischen 20 und 50MB/s erreichen wir. Beim Kopiervorgang ist zu beobachten, das die Netzwerkauslastung mehrere Sekunden lang Pausen macht. Also sind wir weit vom Linespeed entfernt.

Ich habe mir dann eine neue Testumgebung aufgebaut bestehend aus:
ESXi 6.0 Host mit 1GBE und lokaler SAS-Platte,
FreeNAS Host mit 1GBE und SSD

Performance auf FreeNas per CIFS liegt fast bei Linespeed: ca. 100MB/s -> das FreeNAS ist also schnell genug.
Kopierzeiten einer 530MB Datei:
vom PC per CIFS auf die Freenas: ca. 6Sek = 88,5MB/s
copy ESXi von Freenas auf lokale SAS Platte: 29s = 18MB/s
copy ESXi von/auf der lokalen Platte: 6s = 90MB/s (530MB lesen+530MB schreiben)
copy ESXi von/auf Freenas = 66s = 16MB/s (530MB lesen+530MB schreiben per NFS)

Also warum ist alles über NFS so lahm?
Läuft das auf dem ESXi Host mit niedriger Priorität?
Wie mache ich dem NFS Beine und und beschleunige das Ding?

vielen Dank für Eure Bemühungen..

[irix]

Lass die Finger von einem "cp" in der CMD eines ESXi. Wenn ihr benchmarken wollt dann nimmt IOmeter innerhalb einer VM.

Sowohl NetApp als auch EMC supporten VAAI was aber immer ein Stueckchen Software vom Hersteller erfordert. Das ist anders als wenn man Blockstorage verwendet.

Gruss
Joerg

[motions]

cp ist jetzt nur eine schnelle Lösung gewesen, um überhaupt reproduzierbar Dateien direkt zu verschieben.
Ich schaue mir bei Gelegenheit noch mal IOmeter an.
VAAI auf der EMC haben wir auch aktiv.

Momentan suche ich gerade nach einem Windows NFS Client, um darüber Performance Messungen zu machen. Sieht aber mau aus.
Also versuche ich gleich mal einen Transfertest aus einer Linux VM, die ich noch auf meinem PC habe....

[irix]

Wenn dann nimm vmkfstools anstelle von cp.

Bei NFS mountet der der ESXi das mit Parameter sync und aus diesem Grund kann man das nicht mit einem normalen Linux Mount oder auch CIFS vergleichen. Fuer NFS gibt immer auch das ein oder andere Bestpractice seitens der Hersteller und auch VMware hat da ein paar Parameter an denen man drehen kann.

Gruss
Joerg

[motions]

So, eben mal getestet:
ein Opensuse 13.2. in der Virtualbox-VM auf meinem PC hat auf dem FreeNAS
wieder mit der 530MB Datei:
Kopieren der Datei nach /dev/Null (530MB lesen): 7.1s = 75MB/s
Kopieren der Datei auf dem NFS Mount (530 MB lesen+schreiben) = 24,5s = 43MB/s

>Bei NFS mountet der der ESXi das mit Parameter sync
Interessanter Hinweis; das werde ich mal versuchen im non-ESXi System zu vergleichen.

>Fuer NFS gibt immer auch das ein oder andere Bestpractice seitens der Hersteller und auch VMware hat da ein paar Parameter an denen man drehen kann.
Ein Paar davon habe ich schon durch: net.tcpipheapsize, Min/MaxHeapsite etc. -> brachte genau 0,0% Verbesserung.

Hast Du Links auf gute Best Practices die sich mit diesem Thema beschäftigen? (Bei Google selbst habe ich schon die ersten zwei, drei Trefferseiten abgeklappert)

[motions]

Eben mal in meiner OS13.2 VM gemessen mit sync mount:
cp nach /dev/null = 9,6s = 55MB/s
cp 1.iso 2.iso (von/nach NFS) = 1min 23s = 83s = 12,8MB/s

hmmm... das scheinen ja Werte zu sein, die sich an die beobachteten langsamen Geschwindigkeiten annähern.

Ich glaube ich mach auf dem FreeNAS noch mal einen Versuch mit iSCSI ob da ein Unterschied besteht ...

[Whitemoon]

VAAI auf der EMC haben wir auch aktiv.

Und auf den ESXi-Hosts das Plugin installiert und aktiviert?

VMWare selbst stellt auch noch ein paar Anforderungen:
http://kb.vmware.com/selfservice/micros ... Id=2008822

Was hast für 10GBit - Switches (Hersteller, Modell) im Einsatz? Hast du Protokolle wie LACP im Einsatz?

[motions]

>Und auf den ESXi-Hosts das Plugin installiert und aktiviert?
Ja, aktiviert!
die NFS Performance zur EMC habe ich noch nicht getestet; zur Netapp ca. 50MB/s

Core-Switches: Cisco Nexus 5500 mit 10GBE Modulen, Dual 10GBE Anbindung der ESXi Hosts (6* HP Proliant DL360 Gen.9,je Dual Xeon 3.1Ghz, 10Kerner, 256GB RAM)
Ob da jetzt LACP oder ähnliches im Einsatz ist müßte ich erst erfragen.

Okay, der Link ist jetzt VAAI spezifisch.
Wir benötigen aber NFS Performance zum Datentransport (Seeding) von Filial-Standorten.
Mit einer QNAP hatten wir beim ersten Versuch nur 25MB/s. Das dauert bei 4TB Daten ...Tage....
Da brauchen wir eine schnellere Lösung.
Deshalb diese ganzen NFS Versuche hier.

Vielleicht haben wir auch noch ein anderes Problem auf der EMC (auch per NFS als Datastore angebunden)? Da laufen zwar momentan knapp 90 VM drauf und es gibt keine Beschwerden. Jetzt virtualisieren wir in zwei bis drei Wochen noch einen MSSQL Server. Auf der physikalischen Hardware sind das nur eine Datenbank von 120GB, VM mit 64GB RAM und 8vCPU, mit ca. 450 aktiven Clients drauf; davon Fertigungssystem die Antwortzeiten im Sekundenbereich benötigten. Der neue virtuelle Test-Server hat gute Performance und ich habe den gerade mit 10 Test-Clients unter Dauerfeuer. Auch dabei ist die Performance super. Nur mache ich jetzt einen Snapshot, so dauert der insgesamt 66 Minuten!!! Davon ca. 3 Minuten dann _ALLE_ Testclients eingefroren, allerdings auch _keine_ Programmabbrüche.
Das muss jetzt aber nichts mit meinem aktuellen NFS System zu tun haben....

[irix]

Auch dabei ist die Performance super. Nur mache ich jetzt einen Snapshot, so dauert der insgesamt 66 Minuten!!! Davon ca. 3 Minuten dann _ALLE_ Testclients eingefroren, allerdings auch _keine_ Programmabbrüche.
Das muss jetzt aber nichts mit meinem aktuellen NFS System zu tun haben....

Das waere aber erklaerbar sofern du den Memory mit im Snapshot hast (ist so der Default und in meinen Augen unsinning) und deinem aktu. Performance Problem. Weil dann muss du erstmal 64GB wegschreiben.

Wenn du IOmeter laufen laesst oder aber mit vmkfstools eine Datei "kopierst" lass mal in einer 2. Shell ein "esxtop" mitlaufen und zeige uns da was an Queue und Latency ausgegeben wird.

Gruss
Joerg

[motions]

okay, dann habe ich noch ein paar Hausaufgaben zu machen.
Ich gehe das Anfang der Woche mal an und werde berichten.

[rprengel]

okay, dann habe ich noch ein paar Hausaufgaben zu machen.
Ich gehe das Anfang der Woche mal an und werde berichten.

Nfs sync und async prüfen wie bereits geschrieben.
Gruss

[motions]

Kann ich denn die ESXi beeinflußen, ob und wann die NFS export mit sync oder nosync mounten ?

[rprengel]

Kann ich denn die ESXi beeinflußen, ob und wann die NFS export mit sync oder nosync mounten ?

Ist serveseiting einzustellen.
Gerne in /etc/exports direkt oder per Webobefläche pro share einzeln.
Schau dir aber vorher an was genau der Schalter bewirkt.
Gruss

[kastlr]

Hallo,

für die Anbindung einer VNX an eine ESX Umgebung stellt EMC² folgendes Tech Book bereit.
Using EMC VNX Storage with VMware vSphere

Gruß,
Ralf

[motions]

Der Speed der VNX scheint okay,
die NetApp ist durchwachsen ..
Heute habe ich mehrfach zwei VMs geclont und habe Geschwindigkeiten zwischen 60 und 260MB/s auf der NetApp gehabt. Selbst auf der selben VM und dem gleichen Datastore.

LACP haben wir übrigens nicht im Einsatz.

[motions]

VNX Speed scheint wirklich okay zu sein.
Bei besagter SQL Server Instanz habe ich noch mal ein Snapshot gezogen: Diesmal ohne Last durch Clients und _ohne_Memory. Da sieht der Snapshot gut aus: 4 Sekunden statt 66Minuten. Also den Specher bei 50% Serverlast und 64GB RAM wegzuschreiben ist wohl wirklich deutlich mehr Arbeit

zu meinem NFS Speedproblem:
Da komme ich erst am Wochenende wieder dazu.
Ich baue mir dazu eine neue Testumgebung auf:
-NAS z.B. unter OpenMediaVault
-DL380 G7 Server
-Gigabit Verbindung zwischen beiden Geräte
Bisherige Tests habe ich unter FreeNAS gemacht. Einigen Berichten zum Thema FreeNAS und ESXi berichten von problemen mit synchronen NFS und ZFS Zugriffen in dieser Zusammenstellung.

Mal sehen was dabei rauskommt; ich werde berichten.

[Dayworker]

Das Problem ist wirklich das durch den ESXi erzwungene Sync bei NFS. Ich habe dazu bis jetzt auch noch keinen Weg gefunden, dieses abzuschalten.
Die in einigen VMware-KBs genannten Parameter hinsichtlich NFS-Tuning (Net/TcpipHeapSize=32, Net/TcpipHeapMax=128, NFS/HeartbeatMaxFailures=10, NFS/HeartbeatFrequency=12, NFS/HeartbeatTimeout=5, NFS/MaxVolumes=25) sind meiner Meinung nach nicht zielführend oder hat hier jemand sehr viele NFS-Server dem ESXi präsentiert?

Meine Nappit-Appliance schleicht förmlich vor sich hin. Gut bzw eher nicht gut, hab ihr kein ZIL-Device zum beschleunigten Sync verpaßt. Inzwischen bin ich jedoch der Meinung, daß nicht der Sync selbst, hab ich per "Sync=disable" in der Appliance mal ausprobiert und kaum Veränderungen festgestellt, sondern das Flushen der Caches das eigentliche Problem darstellt. Nach jedem einzelnen NFS-Write schickt der ESXi eine Flush-Befehl mit auf die Reise und wartet die ACK-Meldung ab, bevor der nächste Write-IO losgeschickt wird. Die Performance muß dann ja logischerweise extrem einbrechen.

[rprengel]

Das Problem ist wirklich das durch den ESXi erzwungene Sync bei NFS. Ich habe dazu bis jetzt auch noch keinen Weg gefunden, dieses abzuschalten.
Die in einigen VMware-KBs genannten Parameter hinsichtlich NFS-Tuning (Net/TcpipHeapSize=32, Net/TcpipHeapMax=128, NFS/HeartbeatMaxFailures=10, NFS/HeartbeatFrequency=12, NFS/HeartbeatTimeout=5, NFS/MaxVolumes=25) sind meiner Meinung nach nicht zielführend oder hat hier jemand sehr viele NFS-Server dem ESXi präsentiert?

Hallo,
ohne überhaupt einen Vergleich mit Profilösungen anstreben zu wollen.
Meine Erfahrungen mit Openvault, Qnaps und Debian-Plain-NFS sind immer die das async die Performance bis zum Faktor 4 hoch zieht. Aus 20 MB/Sekunde werden dann schnell 80 bis 100 MB Sekunde auf z.B. HP Microservern Gen 8.
Mal ganz blöde gefragt:
Nach dem setzten der Schalter wurden die NFS Dienste wirklich sauber neu gestartet?
Gruss

[motions]

Nach dem ganzen Rumprobieren mit diversen NAS Distributionen habe ich jetzt einfach einen Ansatz mit Opensuse 13.2 auf EXT4 Volumes gemacht.
Da sieht die Performance SEEEER gut aus.
104MByte/s auf der 1GBE Leitung meiner Testinstallation.
Auf die schnelle habe ich NFS exports mit sync und async getestet und keinen Unterschied festgestellt.
Die nächsten Tage mache ich in der Firma auch mal eine Testinstallation und versuche dann 1GBE und 10GBE. Dort habe ich auch einen vCenter und kann richtiges Clonen testen.
stay tuned ...

[gea]

Das Problem ist wirklich das durch den ESXi erzwungene Sync bei NFS. Ich habe dazu bis jetzt auch noch keinen Weg gefunden, dieses abzuschalten.
Die in einigen VMware-KBs genannten Parameter hinsichtlich NFS-Tuning (Net/TcpipHeapSize=32, Net/TcpipHeapMax=128, NFS/HeartbeatMaxFailures=10, NFS/HeartbeatFrequency=12, NFS/HeartbeatTimeout=5, NFS/MaxVolumes=25) sind meiner Meinung nach nicht zielführend oder hat hier jemand sehr viele NFS-Server dem ESXi präsentiert?

Meine Nappit-Appliance schleicht förmlich vor sich hin. Gut bzw eher nicht gut, hab ihr kein ZIL-Device zum beschleunigten Sync verpaßt. Inzwischen bin ich jedoch der Meinung, daß nicht der Sync selbst, hab ich per "Sync=disable" in der Appliance mal ausprobiert und kaum Veränderungen festgestellt, sondern das Flushen der Caches das eigentliche Problem darstellt. Nach jedem einzelnen NFS-Write schickt der ESXi eine Flush-Befehl mit auf die Reise und wartet die ACK-Meldung ab, bevor der nächste Write-IO losgeschickt wird. Die Performance muß dann ja logischerweise extrem einbrechen.

Das Haupt-"problem" ist meist sync write. Das kann man aber wie beschrieben bei ZFS auf Ebene des Dateisystems ausschalten. Dadurch laufen auch alle ESXi Schreibvorgänge ausschliesslich über den ZFS Schreibcache der aus mehreren langsamen, kleinen und zufälligen Schreibvorgängen einen großen sequentiellen Schreibvorgang macht. Das bringt richtig Performance. Fällt aber beim Schreiben der Strom aus so hat das bei ZFS wegen CopyOnWrite keine Auswirkung auf das ZFS Dateisystem. Das bleibt konsistent. Ein darauf befindlichens "altes" Dateisystem ohne CopyOnWrite wie ext4 oder ntfs kann allerdings korrupt werden indem z.B. Daten aktualisiert wurden nicht jedoch die zugehörenden Metadaten. Sync sorgt nun dafür, dass ein bestätigter Schreibvorgang auch tatsächlich auf Platte ist, entweder auf Kosten der Geschwindigkeit oder des Geldbeutels indem man das mit einem ZFS Logdevice (Slog) beschleunigt. Dadurch findet auch das normale Schreiben über den Schreibcache statt, zusätzlich werden aber alle Schreibaktionen dazwischen protokolliert und bei einem Absturz beim nächsten Start nachgeholt. Das ZFS Zil hat damit eine ähnliche Funktion wie die Batterie + Cache eines Hardware Raidcontrollers arbeitet aber besser und schneller.

Daneben gibt es NFS Optimierungen. Das ist ja per default auf 1G Netzwerk, langsame CPU und wenig RAM optimiert. Bei einem All-In-One sollte man beispielsweise die Einstellungen der vmxnet3 vnic anpassen. Zusätzlich sollte man die NFS Einstellungen auf besseren Durchsatz trimmen. Immerhin gehen ja ESXi intern mehrere Gbit/s über den vswitch.

Vmxnet3s und NFS Tuning Optionen z.B. entsprechend http://www.napp-it.org/doc/downloads/napp-in-one.pdf
Seite 30 anpassen, entweder über das Tuning Panel oder manuell.

Ansonsten hilft nur rohe Gewalt, also ausreichend RAM für genügend Lesecache und eine Poolstruktur die viele iops liefert, also traditionell ein Raid-10 Konstrukt aus möglichst vielen Mirror Paaren oder neuerdings SSD only Pools. Da sollte man allerdings auf Enterprise SSDs mit hohem Overprovisioning und Powerloss Protection schauen.

[motions]

So, in der Firma habe ich jetzt mal Test mit einer Opensuse 13.2 installation als NFS Server gemacht:
async NFS Export; transferrate mit iftops gemessen:
1GBE -> 880Mbit/s <- na, das sieht doch gut aus
10GBE -> 990MBit/s, bei einigen Transfers bis 1200MBit/s <- hmmmm....gut, aber nicht so gut wie von 10GBE erwartet

Keine Unterschiede, ob der NFS Export auf einer SSD oder HDD liegt


dann mal ein Test mit sync NFS Exports: Katastrophe, 25MBit/s selbst über 10GBE

[motions]

Vmxnet3s und NFS Tuning Optionen z.B. entsprechend http://www.napp-it.org/doc/downloads/napp-in-one.pdf
Seite 30 anpassen, entweder über das Tuning Panel oder manuell.

Ansonsten hilft nur rohe Gewalt, also ausreichend RAM für genügend Lesecache und eine Poolstruktur die viele iops liefert, also traditionell ein Raid-10 Konstrukt aus möglichst vielen Mirror Paaren oder neuerdings SSD only Pools. Da sollte man allerdings auf Enterprise SSDs mit hohem Overprovisioning und Powerloss Protection schauen.

Schönes PDF, das werde ich mal durcharbeiten.
Insgesamt sind wir mit EMC VNX und Netapp Performance-Technisch gut aufgestellt.
Wir haben nur Standorte im Europäischen Ausland, für die wir jetzt Simplivity hyperconverged Systeme aufsetzen. Ein Spiegel läuft dann über WAN Leitungen in unseren Large Datacentern zusammen. Für das Seeding brauchen wir nun eine schnelle und zuverlässige Quelle, um die initialien Daten der Filiale in die Datacenter zu bringen. Den ersten haben wir mit einer QNAP 213+ gemacht. Schnarch ... kaum mehr als 20-25MByte/s. Da dauern die 8TB für das cloning der seeds aber etwas...fast 2 Tage. Zu viel Zeit um den Clone noch mit dem Handgepäck im Flieger mitzunehmen.
Wir suchen also einen schnellen, einfachen NFS Speicher, auf dem wir den Clone ablegen können.

[UrsDerBär]

NFS Performance bei so Storage-Lösungen inkl. Write-Sicherheit bringt vor allem eins: Write Latency. Ist die Latency tief und ohne grosse Ausreisser, fliegen die Storage-Pools im Software-RAID-Betrieb.

Bei meinen Pools mit DC3700 von Intel ist jedenfalls die CPU bzw. die virtuelle Netzwerkkarte der limitierende Faktor. Je mehr Cores für die Storage-VM, desto mehr Speed. Skaliert linear bis ans Maximum der SSD's. SSD's mit breiter Latency-Streung sind katastrophal weil eben immer eine im RAID grade ne schlechte Zeit hat. Magnet HDD's tummeln hier bei ca. 3.5 MB/s. Da hilft dann ein Controller.

ZFS finde ich zwar vom Prinzip her klasse, irgendwie habe ich da aber schon so extrem viele Negativmeldungen gehört dass ich mich nie dran gewagt habe. Zwar eher im Zusammenhang mit unprofessioneller Hardware, aber mit richtiger Hardware habe ich leider noch ned allzuviel von gehört. Weder positiv noch negativ.

[gea]

ZFS finde ich zwar vom Prinzip her klasse, irgendwie habe ich da aber schon so extrem viele Negativmeldungen gehört dass ich mich nie dran gewagt habe. Zwar eher im Zusammenhang mit unprofessioneller Hardware, aber mit richtiger Hardware habe ich leider noch ned allzuviel von gehört. Weder positiv noch negativ.

ZFS gibt es ja seit über 10 Jahren, Sun hat das mit OpenSolaris sogar frei gegeben. Vor 5 Jahren hätte aber NetApp das beinahe weggeklagt, da es zuviel Ähnlichkeit mit deren Dateisystem hat (manche meinen soger besser ist).

Insgesamt ist ZFS der erste und wichtigste Vertreter einer neuen Generation von Dateisystem. Bis in ein paar Jahren wird es im Wesentlichen nur noch Vertreter diese Gattung geben. Neben ZFS sind das die "Nachbauten" btrfs und ReFS.

ZFS ist angetreten um vor allem bei überragender Datensicherheit, High Capacity und High Performance zu punkten. Es ist zwar prinzipiell wegen der zusätzlichen Prüfsummen und der stärkeren Fragmentierung durch CopyOnWrite bei einer einzelnen Platte eher langsamer als ext4 oder ntfs, gleicht das durch ein excelenntes Cache-Management im RAM oder SSD mehr als aus. Daneben skaliert die ZFS Performance fast linear über die Anzahl der Platten oder der Raid Arrays (vdevs) aus denen ein Pool aufgebaut wird.

Unter Solaris oder dem freien Fork OmniOS erreiche ich mit 10G z.B. per Solaris SMB2 Server über 800 MB/s auf eine Intel NVMe Platte. NFS kann ähnliches, wurde ja auch wie ZFS von Sun entwickelt. Auch sicheres sync write geht mit ZFS in vernünftiger Geschwindigkeit durch das Konzept dedizierter SSD Logging-Devices.

Richtige Negativmeldungen über ZFS habe ich eigentlich seit vielen Jahren nicht gelesen. Man muss sich bei der Konzeption an ein paar Regel halten wie Nimm Intel Serverboards, Intel Netzwerkkarten und SSDs sowie LSI/Avago HBAs ohne Raid Funktionalität. Dazu ausreichend ECC RAM und es kann eigentlich nichts schiefgehen.

[rprengel]

okay, dann habe ich noch ein paar Hausaufgaben zu machen.
Ich gehe das Anfang der Woche mal an und werde berichten.

Nfs sync und async prüfen wie bereits geschrieben.
Gruss

Hallo
gerade gefunden:
https://mathias-kettner.de/check_mk_exc ... -1.0.1.mkp
Collects NFS mount performance data on clients
Habe dazu keine Info was es macht aber ggf. ja für den einen oder anderen hier von Interesse.

Gruss