18
Proxmox - NFS - Langsames Netzwerk
Hallo liebe Admins,
ich habe folgendes Szenario:
1 Proxmox-Cluster, bestehend aus 3 Nodes.
Jeder Node ist ein Dell R730 (32 Kerne, 128GB DDR4 RAM) Server mit jeweils Dual-Port-10Gbit-NICs, verbunden mit 2 DAC-Kabeln an einen Ubiquiti Pro Aggregation Switch. Jeder Node ist mit seinen 2 Ports als LACP Layer 3+4 sowohl an Proxmox als auch am Switch konfiguriert, und MTU ist auf 9000 gesetzt.
Der Storage Server (Dell R730 wie die Nodes) ist ein TrueNAS Scale mit 2x Dual-Port-25Gbit-NICs. Alle 4 Ports sind als Switch mit LACP Layer 3+4 eingestellt und MTU 9000.
4x 1TB NVMe (jeweils ca. 3.000MB/s Lesen / Schreiben - getestet) per Bifurcation als ZFS Stripe (Nur jetzt als Test! Nur um die maximale Geschwindigkeit zu testen) eingerichtet. Compression und Sync sind am Dataset ausgeschaltet, und die Blocksize von 128K auf 1M gesetzt.
Der Storage Server dient als NFS Share für die 3 Nodes. In der Theorie sollte ich ja schon so meine paar Gigabytes pro Sekunde über die Verbindung kopieren können, unabhängig davon, ob es VMs sind oder einfach nur ein normaler Kopiervorgang zwischen Node 1 und dem Storage Server ist. Meine maximale Geschwindigkeit liegt jedoch bei 6 Gb/s, also 6Gbit/s laut TrueNAS, und wenn ich einen Speedtest auf einer Windows Server 2022 VM mache, zeigt er mir sogar nur ca. 400MB/s an. Mir ist bewusst, dass ich durch die VMs deutlich weniger Speed über das Netzwerk haben werde; allerdings kommen mir diese Zahlen, sprich die 6Gbit, deutlich zu langsam vor.
Wenn ich eine 32GB RAW-Datei über NFS kopiere, dauert es von S1 / S2 oder S3 auf den Storage Server ca. 2min...
Ich habe als Test mal alle 3 Nodes die 32GB kopieren lassen, und allein durch das Stripe müsste ich ja theoretisch mindestens die vollen 25Gbit eines NIC-Ports ausreizen müssen... Leider war genau da die maximale Leistung bei den 6Gb/s.
Habe ich einen deutlichen Denkfehler und überschätze das Netzwerk komplett, oder liegt hier eine deutliche Bremse durch Fehlkonfiguration vor?
Ich danke euch für jeden hilfreichen Rat...
Euer WildDog
ich habe folgendes Szenario:
1 Proxmox-Cluster, bestehend aus 3 Nodes.
Jeder Node ist ein Dell R730 (32 Kerne, 128GB DDR4 RAM) Server mit jeweils Dual-Port-10Gbit-NICs, verbunden mit 2 DAC-Kabeln an einen Ubiquiti Pro Aggregation Switch. Jeder Node ist mit seinen 2 Ports als LACP Layer 3+4 sowohl an Proxmox als auch am Switch konfiguriert, und MTU ist auf 9000 gesetzt.
Der Storage Server (Dell R730 wie die Nodes) ist ein TrueNAS Scale mit 2x Dual-Port-25Gbit-NICs. Alle 4 Ports sind als Switch mit LACP Layer 3+4 eingestellt und MTU 9000.
4x 1TB NVMe (jeweils ca. 3.000MB/s Lesen / Schreiben - getestet) per Bifurcation als ZFS Stripe (Nur jetzt als Test! Nur um die maximale Geschwindigkeit zu testen) eingerichtet. Compression und Sync sind am Dataset ausgeschaltet, und die Blocksize von 128K auf 1M gesetzt.
Der Storage Server dient als NFS Share für die 3 Nodes. In der Theorie sollte ich ja schon so meine paar Gigabytes pro Sekunde über die Verbindung kopieren können, unabhängig davon, ob es VMs sind oder einfach nur ein normaler Kopiervorgang zwischen Node 1 und dem Storage Server ist. Meine maximale Geschwindigkeit liegt jedoch bei 6 Gb/s, also 6Gbit/s laut TrueNAS, und wenn ich einen Speedtest auf einer Windows Server 2022 VM mache, zeigt er mir sogar nur ca. 400MB/s an. Mir ist bewusst, dass ich durch die VMs deutlich weniger Speed über das Netzwerk haben werde; allerdings kommen mir diese Zahlen, sprich die 6Gbit, deutlich zu langsam vor.
Wenn ich eine 32GB RAW-Datei über NFS kopiere, dauert es von S1 / S2 oder S3 auf den Storage Server ca. 2min...
Ich habe als Test mal alle 3 Nodes die 32GB kopieren lassen, und allein durch das Stripe müsste ich ja theoretisch mindestens die vollen 25Gbit eines NIC-Ports ausreizen müssen... Leider war genau da die maximale Leistung bei den 6Gb/s.
Habe ich einen deutlichen Denkfehler und überschätze das Netzwerk komplett, oder liegt hier eine deutliche Bremse durch Fehlkonfiguration vor?
Ich danke euch für jeden hilfreichen Rat...
Euer WildDog
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 13900864509
Url: https://administrator.de/forum/proxmox-nfs-langsames-netzwerk-13900864509.html
Ausgedruckt am: 22.12.2024 um 05:12 Uhr
18 Kommentare
Neuester Kommentar
Wie immer lesenswert wenns um Winblows geht...
Wie man das Windows 10 und 11 TCP-Handling wieder desuboptimieren kann
Wie man das Windows 10 und 11 TCP-Handling wieder desuboptimieren kann
1
Hallo,
schon mal ein einfachen ipfer3 Test zwischen den Nodes und von den Nodes zum StorageServer gemacht?
Gruß
schon mal ein einfachen ipfer3 Test zwischen den Nodes und von den Nodes zum StorageServer gemacht?
Gruß
2
Hi, sorry das hab ich vergessen zu erwähnen…
iperf3 zeigt ohne MTU 9000 auch ca 8 Gbit/s an… mit MTU 9000 knackige 2,43 Mbit/s
Deutet halt schon an fehlerhaften Settings hin...
die Nodes untereinander kommen allerdings auch knackige 2,43 Mbit/s. Also wirklich alle zeigen die 2,43 an...
Nachtrag:
ich habe nun bei allen Nodes die MTU auf 1500 gesetzt und erreichen bei allen ca. 8.34 Transfer und 7,17 Bitrate
Egal welcher Node zum Storage liegen wir exakt bei den selben Werten.
iperf3 zeigt ohne MTU 9000 auch ca 8 Gbit/s an… mit MTU 9000 knackige 2,43 Mbit/s
Deutet halt schon an fehlerhaften Settings hin...
die Nodes untereinander kommen allerdings auch knackige 2,43 Mbit/s. Also wirklich alle zeigen die 2,43 an...
Nachtrag:
ich habe nun bei allen Nodes die MTU auf 1500 gesetzt und erreichen bei allen ca. 8.34 Transfer und 7,17 Bitrate
Egal welcher Node zum Storage liegen wir exakt bei den selben Werten.
Quote from @aqui:
Wie immer lesenswert wenns um Winblows geht...
Wie man das Windows 10 und 11 TCP-Handling wieder desuboptimieren kann
Wie immer lesenswert wenns um Winblows geht...
Wie man das Windows 10 und 11 TCP-Handling wieder desuboptimieren kann
Nur geht es hier ja gar nicht um Windows, die Nodes sind auch langsam.
/Thomas
1Nur geht es hier ja gar nicht um Windows
Zitat des TO: "wenn ich einen Speedtest auf einer Windows Server 2022 VM mache...". Ist wohl beides. Aber du hast letztlich Recht wenn das Fundament schon lahmt tut es das beim Obendrüber natürlich erst recht.mit MTU 9000 knackige 2,43 Mbit/s
Kann es sein das du hier ggf. Layer 2 (Jumbo Framing) mit der Layer 3 MTU verwechselt hast?? 
Bei nur aktiviertem Jumbo Framing sollte es keinesfalls zu solchen massiven Differenzen kommen. Bei IP MTU schon, denn damit erzwingst du Fragmentierung. Jumbo Framing greift nur im Layer 2.1
Hi @aqui...
Entschuldige die Frage aber da musst du mich bitte kurz abholen...
Layer 2 = MTU 9000 (korrekt?)
Layer 3 = MTU ?
Ich habe bei dem Proxmox Bonds die Option LACP und Layer 3+4 gewählt, dann die MTU 9000 hinzugefügt, was ja zu der geringen Datenrate führte. Das entfernen der MTU 9000 ergab die oben genannten 8,34 auf allen Nodes.
Kurz um mich nochmal zur Schule zu schicken: Wenn ich zwei 10Gbit Ports per LACP im Switch und am Host "verbinde", kann man dies doch ähnlich einer zweispurigen Autobahn vergleichen, richtig? Also mal grob Lesen = 10Gbit und Schreiben 10Gbit... Oder eben jeweils Anfrage von zwei Nodes parallel mit jeweils 10Gbit verarbeiten.
Es ist ja nicht so, dass es durch LACP direkt 20Gbit sind, sondern einfach zwei 10Gbit "Kanäle" zur zeitgleichen Bearbeitung.
Sofern ich hier richtig liege, dürfte iPerf3 pro Node auch nur maximal 9-10 Gbit anzeigen (wo wir mit den 8,34 Gbit/s nicht zu weit entfernt sind).
Doch die gesamte Transfergeschwindigkeit des Kopiervorganges sollte ja dennoch über 10 / 8,34 Gbit liegen, oder irre ich mich hier?
Gruß ^^
Entschuldige die Frage aber da musst du mich bitte kurz abholen...
Layer 2 = MTU 9000 (korrekt?)
Layer 3 = MTU ?
Ich habe bei dem Proxmox Bonds die Option LACP und Layer 3+4 gewählt, dann die MTU 9000 hinzugefügt, was ja zu der geringen Datenrate führte. Das entfernen der MTU 9000 ergab die oben genannten 8,34 auf allen Nodes.
Kurz um mich nochmal zur Schule zu schicken: Wenn ich zwei 10Gbit Ports per LACP im Switch und am Host "verbinde", kann man dies doch ähnlich einer zweispurigen Autobahn vergleichen, richtig? Also mal grob Lesen = 10Gbit und Schreiben 10Gbit... Oder eben jeweils Anfrage von zwei Nodes parallel mit jeweils 10Gbit verarbeiten.
Es ist ja nicht so, dass es durch LACP direkt 20Gbit sind, sondern einfach zwei 10Gbit "Kanäle" zur zeitgleichen Bearbeitung.
Sofern ich hier richtig liege, dürfte iPerf3 pro Node auch nur maximal 9-10 Gbit anzeigen (wo wir mit den 8,34 Gbit/s nicht zu weit entfernt sind).
Doch die gesamte Transfergeschwindigkeit des Kopiervorganges sollte ja dennoch über 10 / 8,34 Gbit liegen, oder irre ich mich hier?
Gruß ^^
Layer 3 = MTU ?
L3 MTU ist die IP MTU auf einem IP Interface: https://www.arubanetworks.com/techdocs/AOS-CX/10.07/HTML/5200-7834/Conte ...
Also mal grob Lesen = 10Gbit und Schreiben 10Gbit... Oder eben jeweils Anfrage von zwei Nodes parallel mit jeweils 10Gbit verarbeiten.
Die 10Gbit/s sind doch bereits Duplex....also 10Gbit/s senden und empfangen gleichzeitig.
Die weitere Ausführung ist korrekt, du könntest zu zwei Endpunkten je 10Gbit/s gleichzeitig lesen / senden.
1
Okay, dann verstehe ich jetzt nicht genau wo ich einen Fehler gemacht habe...
Liegt es nun daran das ich bei den Nodes Layer 3 + 4 aktiv habe und sollte es auf Layer 2 + MTU auf 9000 setzen?
Wenn ich Aqui nämlich richtig verstanden habe, bedeutet Layer 3 bereits die 9000, also die die vom Switch vorgegeben werden und da im Switch die 9000 (sogar 91xx) aktiv sind, sind diese durch Layer 3 auch beim Host.
Doch warum dann trotzdem die geringen Datenraten? Oder ist genau das wechseln auf Layer 2 + MTU 9000 bereits ein Ansatz der Lösung?
Liegt es nun daran das ich bei den Nodes Layer 3 + 4 aktiv habe und sollte es auf Layer 2 + MTU auf 9000 setzen?
Wenn ich Aqui nämlich richtig verstanden habe, bedeutet Layer 3 bereits die 9000, also die die vom Switch vorgegeben werden und da im Switch die 9000 (sogar 91xx) aktiv sind, sind diese durch Layer 3 auch beim Host.
Doch warum dann trotzdem die geringen Datenraten? Oder ist genau das wechseln auf Layer 2 + MTU 9000 bereits ein Ansatz der Lösung?
bedeutet Layer 3 bereits die 9000
Nope! Da hast du etwas gründlich falschverstanden! Die IP MTU darf niemals 1500 übersteigen sonst droht die Performance fressende Fragmentierung.Nicht aber die Layer 2 MTU die ja immer nur in einer L2 Boradcast Domain wirkt.
Relevant ist der iPerf3 Test in der L2 Domain!!
https://iperf.fr/iperf-download.php
Hallo @aqui, vielen Dank…
Wärst du bitte so nett und würdest mir sagen was ich nun tun kann oder sollte?
Alles auf Layer 2 umstellen und die MTU auf 9000 stellen?
Lieben Gruß
Wärst du bitte so nett und würdest mir sagen was ich nun tun kann oder sollte?
Alles auf Layer 2 umstellen und die MTU auf 9000 stellen?
Lieben Gruß
Einfach Jumbo Framing aktivieren was die L2 MTU dann setzt und fertisch. Die IP MTU fässt man keinesfalls an. Bei Cisco ist das ein Haken im Setup:
Okay, damit scheint es allerdings nicht getan zu sein.
Ich hab im Ubiquiti Switch die Jumbo Frames aktiviert, sowohl an den Nodes als auch am Storage Server alles bei MTU 1500 gelassen (weil so habe ich @aqui verstanden).
Und ich erreiche trotzdem nur 5,89 Gbit/s als Bitrate bei iperf3...
Bei den Nodes ist LACP Layer 2 eingestellt und in TrueNAS ebenso...
Irgendwo muss hier noch eine falsche Einstellung schlummern
Ich hab im Ubiquiti Switch die Jumbo Frames aktiviert, sowohl an den Nodes als auch am Storage Server alles bei MTU 1500 gelassen (weil so habe ich @aqui verstanden).
Und ich erreiche trotzdem nur 5,89 Gbit/s als Bitrate bei iperf3...
Bei den Nodes ist LACP Layer 2 eingestellt und in TrueNAS ebenso...
Irgendwo muss hier noch eine falsche Einstellung schlummern
sowohl an den Nodes als auch am Storage Server alles bei MTU 1500 gelassen
Das wäre dann sinnfrei weil Jumbos dann unwirksam sind. Ist ja auch klar, denn bei einer PMTU Discovery können sich die Endgeräte nicht auf eine größere L2 MTU einigen, da dann Storage oder Client als Max. MTU immer 1500 vorgeben. Da aber im gesamten L2 Pfad immer das kleinste, gemeinsame Vielfache ausschlaggebend ist für die L2 MTU bleibt es bei den 1500 und die Jumbos sind damit wirklungslos.Schaden kann es aber auch nix das anzulassen, es bringt nur in dem Falle dann nix.
Und ich erreiche trotzdem nur 5,89 Gbit/s als Bitrate bei iperf3...
Was das o.a. Ergebnis dann bestätigt. 
Bei den Nodes ist LACP Layer 2 eingestellt und in TrueNAS ebenso...
Hier darfst du keinen Denkfehler machen. Die Geschwindigkeit kann nie mehr als die eines memberlinks sein. LACP LAG basiert auf einem IP oder Mac Adress Hashing der Memberlinks. Es verdoppelt nicht die Bandbreite. Das wäre physisch unmöglich.Link Aggregation (LAG) im Netzwerk
Ich weiß jetzt nicht konkret wie das bei TrueNAS Scale ist, aber bei Proxmox würde ich bei den Netzwerkkarten per ETHtool erstmal prüfen ob die komplette TX-/RX-Buffers verwendet werden.
Als Beispiel:
Dann würde ich mal ausgiebig mit Iperf testen. Der limitierende Faktor ist heutzutage der Single-Core Performance. Lass mal mit Iperf2 drei oder vier gleichzeitige Threads laufen. Wenn du dann an die 25Gbit heran kommst, weißt du warum.
Ich habe es damals mit einem Epyc 7313P und einem Thread nicht mal hinbekommen 20Gbit auszulasten. Einfach nicht möglich. Danach würde ich mich an die Optimierung machen. Leider schreibst du nicht was du genau für eine CPU hast... bei AMD gibt es da eine ganze Latte an Schaltern im Bios die man unbedingt anfassen sollte, sonst bleibt Performance liegen. Das fängt an mit dem Deaktivieren der zu langsamen Cstates und hört auf mit Determinismus.
Währenddessen würde ich mit atop auf den Nodes nachsehen ob auch das ausgelastet wird, wie es soll und nicht einfach die Leistung irgendwo verpufft.
Als Beispiel:
ethtool -g eno1Dann würde ich mal ausgiebig mit Iperf testen. Der limitierende Faktor ist heutzutage der Single-Core Performance. Lass mal mit Iperf2 drei oder vier gleichzeitige Threads laufen. Wenn du dann an die 25Gbit heran kommst, weißt du warum.
Ich habe es damals mit einem Epyc 7313P und einem Thread nicht mal hinbekommen 20Gbit auszulasten. Einfach nicht möglich. Danach würde ich mich an die Optimierung machen. Leider schreibst du nicht was du genau für eine CPU hast... bei AMD gibt es da eine ganze Latte an Schaltern im Bios die man unbedingt anfassen sollte, sonst bleibt Performance liegen. Das fängt an mit dem Deaktivieren der zu langsamen Cstates und hört auf mit Determinismus.
Währenddessen würde ich mit atop auf den Nodes nachsehen ob auch das ausgelastet wird, wie es soll und nicht einfach die Leistung irgendwo verpufft.
2
Ich schätze deine Antworten sehr @aqui aber diesmal muss ich zugeben hast du mich ordentlich verwirrt...
Also ist es doch so:
Bei Nodes und Storage LACP Layer 2 einstellen und MTU 9000 aktivieren, fertig...?
Dann sollte iperf3 rund 8-9Gbit/s ausspucken und ein normaler File Transfer sollte die gewünschten 16-18 Gbit/s nutzen können, ja?
Also ist es doch so:
Bei Nodes und Storage LACP Layer 2 einstellen und MTU 9000 aktivieren, fertig...?
Dann sollte iperf3 rund 8-9Gbit/s ausspucken und ein normaler File Transfer sollte die gewünschten 16-18 Gbit/s nutzen können, ja?
Nein, denn bei LACP LAGs wird ja nur verteilt. Jede einzelne Session liegt auz einem einzigen Memberlink der mit seiner Geschwindigkeit die Geschwindigkeit zw. den Partnern bestimmt. Wenn der 10Gig ist dann solltest du 8-9Gbit/s problemlos erreichen aber niemals Vielfache davon. Das kann ein LACP LAG technisch prinzipbedingt nicht leisten. Ein simple Binsenweisheit die aber jeder Netzwerker kennt.
1
Guten Abend liebe Admins!
Erst einmal vielen lieben dank für eure Hilfe!
Nach @aqui seiner Lösung, läuft nun alles auf 9,43 Gbit/s (Screenshot im Anhang).
Mein Denkfehler lag klar in der Layer2 / Layer3+4 und MTU9000 Geschichte...
Leider war mein gehofftes Ziel, bei den 2x 10Gbit am Node und den 4x 25Gbit am Storage, die 20Gbit an Übertragungsrate von Node zum Storage zu ermöglichen, was auch wieder ein Denkfehler von mir war...
Ich hatte es so verstanden, dass die 10Gbit ähnlich wie Bahnen zu betrachten sind... Also der Node greigt mit seinen 2x 10 Bahnen auf die 25 des Storage Servers...
Dafür hab ich jetzt dank euch was gelernt ^^
Vielen Dank!
Erst einmal vielen lieben dank für eure Hilfe!
Nach @aqui seiner Lösung, läuft nun alles auf 9,43 Gbit/s (Screenshot im Anhang).
Mein Denkfehler lag klar in der Layer2 / Layer3+4 und MTU9000 Geschichte...
Leider war mein gehofftes Ziel, bei den 2x 10Gbit am Node und den 4x 25Gbit am Storage, die 20Gbit an Übertragungsrate von Node zum Storage zu ermöglichen, was auch wieder ein Denkfehler von mir war...
Ich hatte es so verstanden, dass die 10Gbit ähnlich wie Bahnen zu betrachten sind... Also der Node greigt mit seinen 2x 10 Bahnen auf die 25 des Storage Servers...
Dafür hab ich jetzt dank euch was gelernt ^^
Vielen Dank!
