30
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ß
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ß
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 5028852918
Url: https://administrator.de/contentid/5028852918
Printed on: May 2, 2024 at 07:05 o'clock
30 Comments
Latest comment
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ß
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ß
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.
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.
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.
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ß
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.
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.
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ß
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
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ß
Hallo,
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ß
Zitat von @aqui:
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.
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ß
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.
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.
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?
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.
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?
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
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ß
1
Hallo,
Danke für die Erklärung. Ja es geht um ein 10G Netzwerk
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
Danke und Gruß
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) 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?
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
Danke und Gruß
und der Rest sagt mir nix
Sollte es aber als guter Netzwerk Admin! 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! 😉Vermutlich dann vor Freude weil alles doppelt so schnell rennt! 😉
Nö, Verbesserungen bemerkt der Anwender grundsätzlich nicht
2
Tipp: lass es und freu dich das alles flüssig läuft. Grüße vom Restartstress
Hallo
Dazu fällt mir keine Ausrede ein
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.
Leider gibt's ja ein Problem weshalb wir schauen müssen, ob JumboFrames das beheben.
Gruß
Zitat von @Coreknabe:
Nö, Verbesserungen bemerkt der Anwender grundsätzlich nicht
Ja, so ist das leider in unserem Job...Vermutlich dann vor Freude weil alles doppelt so schnell rennt! 😉
Nö, Verbesserungen bemerkt der Anwender grundsätzlich nicht
Dazu fällt mir keine Ausrede ein
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.
Leider gibt's ja ein Problem weshalb wir schauen müssen, ob JumboFrames das beheben.
Gruß
Zitat von @user217:
Bin mit 1492 rundum zufrieden, läuft zackig. Die 10% die man evtl. mehr rausholen kann sind zu vernachlässigen.
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.
1Zitat von @LordGurke:
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.
Zitat von @user217:
Bin mit 1492 rundum zufrieden, läuft zackig. Die 10% die man evtl. mehr rausholen kann sind zu vernachlässigen.
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?
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..
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
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
Bei Gigabit merkst du davon vielleicht nicht sooo riesige Unterschiede. Bei 10G und höher ist das aber schon deutlich bemerkbar.
2nachdem ich mich gerade, vor Lachen quiekend, auf der Auslegeware gewälzt habe.
Nicht nur du!!! 🤣Soviel zum Thema "eingehend in der Praxis beschäftigt"
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.
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.
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.
Wie ist es mit der Übertragungsoptimierung zwischen Host und Storage?
z.B.:
Delayed ACK: Deaktiviert
I/O-Warteschlangentiefe: 128
VAAI-Funktionen
uvm.
Moin,
Cool bleiben Jungs und Mädels
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!
Cool bleiben Jungs und Mädels
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!
Wie Kollege @LordGurke oben schon sagt wirst du mit der Aktivierung der Jumbo Frames einen deutlichen Performance Zuwachs in der Layer 2 Übertragung sehen.
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...
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...
Zitat von @ElmerAcmeee:
Trotzdem wird aktuell ein Ping größer 8972 fragmentiert > warum nicht erst ab größer 9000?
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
2
Wenn es das denn nun war bitte dann auch nicht vergessen deinen Thread als erledigt zu markieren!
Moin und frohes Neues,
ich werde wahrscheinlich morgen mit dem Thema weitermachen und gebe dann Feedback
Ja
Okay, macht Sinn.
Bei der Switch steht die MTU auf 9216. Was steckt in den 216 Bytes noch drin? VLAN Tagging u.Ä.?
Gruß
ich werde wahrscheinlich morgen mit dem Thema weitermachen und gebe dann Feedback
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
Okay, macht Sinn.
Bei der Switch steht die MTU auf 9216. Was steckt in den 216 Bytes noch drin? VLAN Tagging u.Ä.?
Gruß
"Der" Switch ist ein Mann: https://de.wiktionary.org/wiki/Switch 😉
https://www.packetcoders.io/mtu-jumbo-mss/
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/
Weiter unten auf der Seite:
Ähnliche Wörter (Deutsch):
Anagramme: wichst
Sorry, packe mein inneres Kind wieder weg
...wie peinlich!! Bleibt zu hoffen das der Switch das nicht im Featureset hat...?! 🤣
Hallo,
der, die das, Testsysteme*innen 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
der, die das, Testsysteme*innen
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
Wenn es das denn nun war bitte nicht vergessen deinen Thread hier dann auch als erledigt zu schliessen!
