elmeracmeee
Goto Top

Fragen zu JumboFrames Aktivierung

Hallo,
wir beschäftigen uns gerade mit der Aktivierung / Einführung von JumboFrames im SAN / iSCSI-Bereich.
Auf den Switchen ist dies nun soweit aktiviert.
Nächster Schritt wäre am SAN die MTU zu erhöhen. Dann auf den ESX und XEN Hosts.
Sofern dies die richtige Reihenfolge ist, stellen wir uns die Frage, was passiert wenn ein Host die MTU noch nicht angepasst hat.
Hat dies in dem Moment keine Auswirkung da der Host mit einer kleineren MTU "anfragt"?
Oder "schickt" das SAN die großen Pakete schon sobald diese dort konfiguriert werden?

Danke für eure Hilfe.
Gruß

Content-Key: 5028852918

Url: https://administrator.de/contentid/5028852918

Printed on: July 20, 2024 at 07:07 o'clock

Member: Coreknabe
Coreknabe Dec 20, 2022 at 09:19:49 (UTC)
Goto Top
Moin,

wenn eine kleinere MTU definiert ist, sollte das kein Problem sein. Ansonsten siehe hier unter "Fragmentierung".
https://www.msxfaq.de/netzwerk/grundlagen/mtu.htm

Gruß
Member: user217
user217 Dec 20, 2022 at 09:25:28 (UTC)
Goto Top
Moin,

ich kann aus meinen Erfahrung nur raten die Finger davon zu lassen, bei mir wurde das ganze sehr zähflüssig.
Bin mit 1492 rundum zufrieden, läuft zackig. Die 10% die man evtl. mehr rausholen kann sind zu vernachlässigen.
Member: Coreknabe
Coreknabe Dec 20, 2022 at 09:30:36 (UTC)
Goto Top
Zitat von @user217:

Moin,

ich kann aus meinen Erfahrung nur raten die Finger davon zu lassen, bei mir wurde das ganze sehr zähflüssig.
Bin mit 1492 rundum zufrieden, läuft zackig. Die 10% die man evtl. mehr rausholen kann sind zu vernachlässigen.

Kommt drauf an, was auf dem SAN läuft. Wenn sich da z.B. VMs tummeln, ist das aus meiner Sicht Best Practice.

Gruß
Member: aqui
aqui Dec 20, 2022 updated at 09:43:57 (UTC)
Goto Top
was passiert wenn ein Host die MTU noch nicht angepasst hat.
Stichwort: "Path MTU Discovery"
https://de.wikipedia.org/wiki/Path_MTU_Discovery
Mit anderen Worten: Es bleibt dann bei den klassischen 1500. Die Partner einigen sich bei der Discovery immer auf das kleinste gemeinsame Vielfache. Die Jumbo Frames der beteiligten Endgeräte sind ja auch in der Regel unterschiedlich und nie aufs Byte genau identisch.
Member: ElmerAcmeee
ElmerAcmeee Dec 20, 2022 at 09:55:45 (UTC)
Goto Top
Hallo,
der Hintergrund ist immer noch dieser hier:
Benchmark nicht valide oder VM Layer Bottleneck vorhanden
Wir erhoffen uns damit eine besserer Auslastung bei 8k Blöcken.
Und da es ja eh zum Best Practise gehört (und wir es bei der Inbetriebnahme nicht auf dem Schirm hatten) würden wir das nun umsetzen. Wenns nix bringt, ist der Punkt eben abgehakt.

Zitat von @Coreknabe:
wenn eine kleinere MTU definiert ist, sollte das kein Problem sein. Ansonsten siehe hier unter "Fragmentierung".
https://www.msxfaq.de/netzwerk/grundlagen/mtu.htm

Am Beispiel Exchange kann der Traffic sowohl von intern als auch von extern "initiert" werden.
Trifft das aber bei iSCSI, wo es um Initiator und Target geht, genauso zu?
Oder habe ich das komplett falsch verstanden?
Danke und Gruß
Member: ElmerAcmeee
ElmerAcmeee Dec 20, 2022 at 10:00:34 (UTC)
Goto Top
Hallo,
Zitat von @aqui:

was passiert wenn ein Host die MTU noch nicht angepasst hat.
Stichwort: "Path MTU Discovery"
https://de.wikipedia.org/wiki/Path_MTU_Discovery
Mit anderen Worten: Es bleibt dann bei den klassischen 1500. Die Partner einigen sich bei der Discovery immer auf das kleinste gemeinsame Vielfache. Die Jumbo Frames der beteiligten Endgeräte sind ja auch in der Regel unterschiedlich und nie aufs Byte genau identisch.

Würde dies nicht nur beschreiben wie das Paket runtergeregelt wird und dann trotzdem ankommt?
Ums komplizierter zu machen: Unser Storage verlangt dass nach jedem IO der nächste Pfad verwendet wird.
Würde das MTU Path discovery dann nicht bei jedem IO neu greifen und runter regeln?

Gruß
Member: aqui
aqui Dec 20, 2022 updated at 10:07:19 (UTC)
Goto Top
Von extern ist ja dann immer Routing involviert und das betrifft dann auch die IP MTU in den Routern!
Intern wird in den Storage Netzen in der Regel nicht geroutet und dann betrifft es dort lediglich die Layer 2 MTU.
L2 und L3 MTU sind 2 verschiedene Baustellen die du nicht verwechseln solltest auch wenn sie augenscheinlich gleiche Namen haben. face-wink
Du bist aber auf dem richtigen Weg denn bei Netzen mit 10G und höher sollte immer die L2 MTU auf die max. Framessize an allen beteiligten Komponenten gesetzt werden, sprich Jumbo Framing aktiviert werden.
wie das Paket runtergeregelt wird und dann trotzdem ankommt?
Ja, das ist der tiefere Sinn. Würde das nicht passieren scheitert eine L2 Verbindung grundsätzlich.
Was genau ist für dich "der nächste Pfad"?? Arbeitest du mit LAGs oder in einem Fabric basierten Storage Netz mit TRILL oder SPB mit multiplen (parallelen) Links?
Member: Coreknabe
Coreknabe Dec 20, 2022 at 10:06:55 (UTC)
Goto Top
Zitat von @Coreknabe:
wenn eine kleinere MTU definiert ist, sollte das kein Problem sein. Ansonsten siehe hier unter "Fragmentierung".
https://www.msxfaq.de/netzwerk/grundlagen/mtu.htm

Am Beispiel Exchange kann der Traffic sowohl von intern als auch von extern "initiert" werden.
Trifft das aber bei iSCSI, wo es um Initiator und Target geht, genauso zu?
Oder habe ich das komplett falsch verstanden?

Am Ende des Tages ist es ein Netzwerk, wer da funkt, ist unerheblich.

Gruß
Member: ElmerAcmeee
ElmerAcmeee Dec 20, 2022 at 10:29:43 (UTC)
Goto Top
Hallo,
Danke für die Erklärung. Ja es geht um ein 10G Netzwerk
Zitat von @aqui:

Was genau ist für dich "der nächste Pfad"?? Arbeitest du mit LAGs oder in einem Fabric basierten Storage Netz mit TRILL oder SPB mit multiplen (parallelen) Links?
Nein kein LACP (und der Rest sagt mir nix) face-sad
Jede Storage NIC (4x) und jede Host NIC (2x) haben eine IP im iSCSI Netz. Damit sind 8 Pfade active.
Die Storage Policy schickt jedes Paket RoundRobin über den nächsten Pfad.
Wenn das bedeutet, dass dieser Prozess jedesmal komplett durchlaufen wird, geht die Performance natürlich in die Knie.
Wenn dies nur einmalig bei aktivierung des Pfades stattfindet ist das zu vernachlässigen.

Ich denke, ich werde es einfach mal umsetzen und hören ob jemand schreit face-smile
Danke und Gruß
Member: aqui
aqui Dec 20, 2022 updated at 10:35:59 (UTC)
Goto Top
und der Rest sagt mir nix
Sollte es aber als guter Netzwerk Admin! face-wink
Das sind gängige Datacenter Switches die nicht mit Spanning Tree arbeiten sondern mit einer Fabric Technologie. Sowas wird wegen des per Paket Balancings und anderer Vorteile in vermaschten oder teilvermaschten Storage Netzen sehr häufig verwendet!
https://www.ip-insider.de/was-ist-trill-transparent-interconnection-of-l ...
https://en.wikipedia.org/wiki/TRILL_(computing)
https://de.wikipedia.org/wiki/IEEE_802.1aq
Die Frage bleibt weiterhin was du mit den ominösen "Pfaden" in einem simplen Layer 2 Netz was nur Mac Adressen kennt meinst?!

einfach mal umsetzen und hören ob jemand schreit
Vermutlich dann vor Freude weil alles doppelt so schnell rennt! 😉
Member: Coreknabe
Coreknabe Dec 20, 2022 at 10:43:22 (UTC)
Goto Top
Vermutlich dann vor Freude weil alles doppelt so schnell rennt! 😉

Nö, Verbesserungen bemerkt der Anwender grundsätzlich nicht face-wink
Member: user217
user217 Dec 20, 2022 updated at 12:32:09 (UTC)
Goto Top
Tipp: lass es und freu dich das alles flüssig läuft. Grüße vom Restartstress
Member: ElmerAcmeee
ElmerAcmeee Dec 20, 2022 updated at 12:54:29 (UTC)
Goto Top
Hallo
Zitat von @Coreknabe:

Vermutlich dann vor Freude weil alles doppelt so schnell rennt! 😉

Nö, Verbesserungen bemerkt der Anwender grundsätzlich nicht face-wink
Ja, so ist das leider in unserem Job...


Zitat von @aqui:

Sollte es aber als guter Netzwerk Admin! face-wink
Dazu fällt mir keine Ausrede ein face-smile

Die Frage bleibt weiterhin was du mit den ominösen "Pfaden" in einem simplen Layer 2 Netz was nur Mac Adressen kennt meinst?!

Bestimmt verstehe ich das einfach nur falsch... (L2 zu L3)
Den Pfad den ich meine ist der iSCSI-Pfad vom Host zum Storage. Der ESX hat 2 iSCSI IPs und das Storage 4 IPs. Jede IP ist auch eine eigene NIC. Damit 8 iSCSI Pfade. Jedes IO wandert immer über den nächsten Pfad (So ist eben die Konfiguration). Wenn nun bei jedem IO das MTU Dicovery läuft, wäre das suboptimal für uns. Würde es nur einmalig bei der Pfadaushandlung stattfinden, können wir das ignorieren.


Zitat von @user217:

Tipp: lass es und freu dich das alles flüssig läuft. Grüße vom Restartstress
Leider gibt's ja ein Problem weshalb wir schauen müssen, ob JumboFrames das beheben.

Gruß
Member: LordGurke
LordGurke Dec 20, 2022 at 12:51:21 (UTC)
Goto Top
Zitat von @user217:
Bin mit 1492 rundum zufrieden, läuft zackig. Die 10% die man evtl. mehr rausholen kann sind zu vernachlässigen.

1492 Bytes sind die Standard-MTU für PPP-Internetverbindungen. Davon reden wir aber nicht, wir reden von Storage-Netzwerken.
Da arbeitest du optimalerweise mit 9k oder 10k großen Frames, weil du üblicherweise fast jede Anfrage oder Antwort auf viele Pakete aufteilen musst.
Das erzeugt mit jedem Paket Overhead für Ethernet-, IP- und TCP-Header.
Mit Jumbo-Frames versendest du mehr Payload pro Paket und dementsprechend weniger Pakete und dementsprechend weniger Overhead.
Das bringt in einem Storage-Netzwerk nicht nur 10% sondern eher 50% mehr Leistung. Das lohnt sich definitv.
Member: user217
user217 Dec 20, 2022 at 13:03:17 (UTC)
Goto Top
Zitat von @LordGurke:

Zitat von @user217:
Bin mit 1492 rundum zufrieden, läuft zackig. Die 10% die man evtl. mehr rausholen kann sind zu vernachlässigen.

1492 Bytes sind die Standard-MTU für PPP-Internetverbindungen. Davon reden wir aber nicht, wir reden von Storage-Netzwerken.
Da arbeitest du optimalerweise mit 9k oder 10k großen Frames, weil du üblicherweise fast jede Anfrage oder Antwort auf viele Pakete aufteilen musst.
Das erzeugt mit jedem Paket Overhead für Ethernet-, IP- und TCP-Header.
Mit Jumbo-Frames versendest du mehr Payload pro Paket und dementsprechend weniger Pakete und dementsprechend weniger Overhead.
Das bringt in einem Storage-Netzwerk nicht nur 10% sondern eher 50% mehr Leistung. Das lohnt sich definitv.

da hast du wohl mal was aufgeschnappt und falsch interpretiert. Ich habe mich mit dem Thema eingehend in der praxis beschäftigt und konnte keine signifikate verbesserung feststellen. Eher das Gegenteil war der Fall, da die Pakete halt länger brauchen, der Headeranteil an eine TCP Paket ist marginal einzuschätzen. max. 10% ich bleibe dabei und das rentiert sich nur wenn man ausschließlich große Pakete überträgt. Sprich Backupjobs..
@ElmerAcmeee: ich wette 100:1 das es daran nicht liegt. Schau besser die Switch config an oder tausch einfach mal ein paar Kabel/NIC Treiber. Es muss ja einen Zeitpunkt geben seit dem das grottig läuft, was wurde da geändert? Der Ansatz ist sicherlich Zielführender. Oder läuft das SAN überhaupt performant? gibt es benachmarks die das "SOLL" belegen?
Member: LordGurke
LordGurke Dec 20, 2022 at 13:20:48 (UTC)
Goto Top
Zitat von @user217:
da hast du wohl mal was aufgeschnappt und falsch interpretiert. Ich habe mich mit dem Thema eingehend in der praxis beschäftigt und konnte keine signifikate verbesserung feststellen. Eher das Gegenteil war der Fall, da die Pakete halt länger brauchen, der Headeranteil an eine TCP Paket ist marginal einzuschätzen. max. 10% ich bleibe dabei und das rentiert sich nur wenn man ausschließlich große Pakete überträgt. Sprich Backupjobs..

Vielen Dank. Ich schreibe diesen Text, nachdem ich mich gerade, vor Lachen quiekend, auf der Auslegeware gewälzt habe.
Ich nehme dir das nicht übel, du kannst mich ja nicht kennen, ich kann dir aber versichern, dass ich auch aus praktischer Erfahrung berichte und nicht nur "etwas aufgeschnappt" habe face-wink
Ich administriere eine Storage-Umgebung mit Ceph und ISCSI, welche über mehrere Rechenzentren verteilt steht und wo Ceph-Hosts teilweise aufgrund der schieren Entfernung 2-3ms Latenz untereinander haben.
Ohne Jumbo-Frames (bei uns 10k) hätten wir nur etwa 40% der Performance. Das haben wir aufwendig gemessen.
Natürlich spielt da auch ein wenig die Latenz mit rein, aber primär haben die Soft-Interrupts zur Verarbeitung der Ethernet-Frames die Systeme belastet.
Im normalen Tagesgeschäft hat jeder Host mindestens 60kpps zu verarbeiten. Grob mit 6 multipliziert wäre die Paketrate ohne Jumbo-Frames — also knapp 360.000 Pakete pro Sekunde.
Das Betriebssystem muss dann die Pakete prüfen, sortieren und zusammensetzen. Bei größeren, dafür weniger Paketen läuft das um welten Effizienter. Das siehst du an der CPU-Auslastung!
Bevor der Einwand kommt, dass das bestimmt an den Netzwerkkarten (Intel XL710) oder den Kabeln (ist eh alles Glasfaser) liegt: Das können wir wohl sicher ausschließen face-wink

Bei Gigabit merkst du davon vielleicht nicht sooo riesige Unterschiede. Bei 10G und höher ist das aber schon deutlich bemerkbar.
Member: aqui
aqui Dec 20, 2022 at 13:27:38 (UTC)
Goto Top
nachdem ich mich gerade, vor Lachen quiekend, auf der Auslegeware gewälzt habe.
Nicht nur du!!! 🤣
Soviel zum Thema "eingehend in der Praxis beschäftigt"
Member: user217
user217 Dec 20, 2022 at 13:35:29 (UTC)
Goto Top
Schön das ich deinen Nachmittag etwas aufhellen konnte ;)
Ich kann aus der praxis sagen das sowohl mit als auch ohne 9k die gemonitorte geschwindigkeit im 10G Netz auf maximal 6G ansteigt und die durchschnittliche bandbreite (veeam) max 10% abweicht. (sowohl zeitlich als auch datendruchsatzmäßig)
Vielleicht hängt dein eindruck noch von anderen Parametern ab.
Im 100G Netz kann ich deinen Eindruck bestätigen, hier konnte ich im Benachmark abweichungen von mehr als 10% beobachten. Aber lassen wir die Kirche im Dorf, ein Benchmark mit genormten Paketgrößen etc. spiegelt nicht die praxis wieder.
Member: user217
user217 Dec 20, 2022 at 13:58:23 (UTC)
Goto Top
Nachdem Gurke und Aqui ausgiebig gegrunzt und gequiekt haben wenden wir uns wieder dem Problem zu.
Wie ist es mit der Übertragungsoptimierung zwischen Host und Storage?

z.B.:
Delayed ACK: Deaktiviert
I/O-Warteschlangentiefe: 128
VAAI-Funktionen
uvm.
Member: ElmerAcmeee
ElmerAcmeee Dec 21, 2022 at 06:02:37 (UTC)
Goto Top
Moin,
Cool bleiben Jungs und Mädels face-smile
Die Kurzfassung: Wir haben ein synchrones Fullflash Array mit 14 ESX Host und ca 300 VMs. Dazu ne VDI Umgbung mit ca. 14 XEN Host und 250 VMs. Für uns läuft alles flüssig und schnell und hatten auch keinen Grund zur Sorge. Bei nem Neustart einer VM gehen 2 Pings verloren. Backup ziehen wir mit 2 GByte/s direkt vom SAN. Soweit so gut.
Nun wird gerade ein neues ERP System mit einer OpenEdge/Progress Umgebung eingeführt.
(Hierzu auch der andere Thread den ich oben schon verlinkt habe.)
Laut deren Benchmarks müssen wir Faktor 3 schneller werden. Ich erwarte nicht dass wir das per JumboFrames schaffen, es steht aber auf der Optimierungsliste.
Die Aufgabe wäre, mit einer SingleThread Anwendung bei 8K Blöcken und einer Queue Depth von 4, 20.000 IOPs zu erreichen. Die 8k Blöcke sollten dann in ein JumboFrame passen.
So die Theorie und Hoffnung.
Ich habe keine Erfahrung damit und taste mich hiermit an das Thema ran. Spielwiese habe ich auch keine, daher die entsprechenden Rückfragen zur Vorsorge.
Aktueller Stand: Switche sind vorbereitet mit einer MTU von 9216, iSCSI Ports des SAN stehen auf 9000 und ein Hardware Windows Server hat auf einem NIC Teaming im iSCSI Netz auch die 9K MTU.
Trotzdem wird aktuell ein Ping größer 8972 fragmentiert > warum nicht erst ab größer 9000?
Der Tag ist noch jung. Die Suche beginnt.
Gruß und Danke!
Member: aqui
aqui Dec 21, 2022 at 10:16:13 (UTC)
Goto Top
Wie Kollege @LordGurke oben schon sagt wirst du mit der Aktivierung der Jumbo Frames einen deutlichen Performance Zuwachs in der Layer 2 Übertragung sehen.
Member: ElmerAcmeee
ElmerAcmeee Dec 21, 2022 at 12:02:40 (UTC)
Goto Top
Hallo,
meine Tests bzw die Config war irgendwie Fehlerhaft.
Da ich erst im neuen Jahr wieder weitermachen kann, habe ich alles wieder auf den Standard zurück gedreht.
Melde mich wenns weiter geht.
Danke und guten Rutsch...
Member: LordGurke
LordGurke Dec 21, 2022 at 14:38:46 (UTC)
Goto Top
Zitat von @ElmerAcmeee:
Trotzdem wird aktuell ein Ping größer 8972 fragmentiert > warum nicht erst ab größer 9000?

Ich nehme an, du pingst mit IPv4?
Du gibst bei der "Ping-Größe" die Größe des Payload an. Du hast aber dazu noch die 20 Bytes IPv4-Header + 8 Bytes ICMP-Header - deshalb kannst du bei der MTU von 9000 Bytes bei Ping nur 8972 Bytes Payload transportieren face-wink
Member: aqui
aqui Jan 04, 2023 at 12:20:51 (UTC)
Goto Top
Wenn es das denn nun war bitte dann auch nicht vergessen deinen Thread als erledigt zu markieren!
Member: ElmerAcmeee
ElmerAcmeee Jan 04, 2023 at 12:36:32 (UTC)
Goto Top
Moin und frohes Neues,
ich werde wahrscheinlich morgen mit dem Thema weitermachen und gebe dann Feedback
Zitat von @LordGurke:

Ich nehme an, du pingst mit IPv4?
Ja
Du gibst bei der "Ping-Größe" die Größe des Payload an. Du hast aber dazu noch die 20 Bytes IPv4-Header + 8 Bytes ICMP-Header - deshalb kannst du bei der MTU von 9000 Bytes bei Ping nur 8972 Bytes Payload transportieren face-wink

Okay, macht Sinn.
Bei der Switch steht die MTU auf 9216. Was steckt in den 216 Bytes noch drin? VLAN Tagging u.Ä.?

Gruß
Member: aqui
aqui Jan 04, 2023 updated at 12:44:36 (UTC)
Goto Top
"Der" Switch ist ein Mann: https://de.wiktionary.org/wiki/Switch 😉
Was steckt in den 216 Bytes noch drin?
Nichts. Die Layer 2 max. MTU ist nicht im IEEE 802.3 Ethernet Standard spezifiziert und deshalb immer Hersteller spezifisch und variiert.
https://www.packetcoders.io/mtu-jumbo-mss/
Mitglied: 3063370895
3063370895 Jan 04, 2023 at 12:42:42 (UTC)
Goto Top
Zitat von @aqui:

"Der" Switch ist ein Mann: https://de.wiktionary.org/wiki/Switch 😉

Weiter unten auf der Seite:

Ähnliche Wörter (Deutsch):

Anagramme: wichst

Sorry, packe mein inneres Kind wieder weg face-smile
Member: aqui
aqui Jan 04, 2023 updated at 12:46:37 (UTC)
Goto Top
...wie peinlich!! Bleibt zu hoffen das der Switch das nicht im Featureset hat...?! 🤣
Member: ElmerAcmeee
ElmerAcmeee Jan 05, 2023 at 12:39:56 (UTC)
Goto Top
Hallo,
der, die das, Testsysteme*innen face-smile habe ich auf Jumboframes umstellen können.
Leider ist das Ergebnis nicht wie erhofft.
Bei kleinen Blöcken bis 32k ist kaum ein Unterschied feststellbar. Danach steigert es sich langsam. Bei 64MB Blöcken haben wir nun 100% mehr IOPs.
Ich werde nun den Rest der Landschaft auch noch anpassen. Damit erfüllen wir dann auch die Best Practices.
Das Ursprüngliche Problemchen bleibt jedoch bestehen.

In den nächsten Tagen sollte ich auch Benchmarks von anderen Kunden, welche diese Software einsetzen, erhalten.
Ich bleib am Thema dran

Danke für die Hilfe
Member: aqui
aqui Feb 02, 2023 at 10:54:38 (UTC)
Goto Top
Wenn es das denn nun war bitte nicht vergessen deinen Thread hier dann auch als erledigt zu schliessen!