Das Forum wurde aktualisiert. Wurde höchste Zeit. Wenn etwas nicht funktioniert, bitte gerne hier jederzeit melden.

Viele, viele Pakete verarbeiten mit VMXNET3/Linux

Alles zum Thema vSphere 6.5, ESXi 6.5 und vCenter Server.

Moderatoren: Dayworker, continuum, Tschoergez, irix

Member
Beiträge: 8
Registriert: 25.06.2018, 02:46

Viele, viele Pakete verarbeiten mit VMXNET3/Linux

Beitragvon GhostTyper » 25.06.2018, 16:44

Hallo.

Netzwerkverbindungen mit 10 GBE und größer müssen sehr viele Frames (und somit auch Pakete) verarbeiten können. Ordentliche Netzwerkkarten unterstützen deshalb eine Möglichkeit mehrere Puffer für Daten, die empfangen werden. Dadurch können Netzwerk-Pakete auf mehreren Cores entgegen genommen und somit auch verarbeitet werden, was den gesamten Durchsatz an Paketen, die verarbeitet werden können erhöht.

ESXi verwendet das bei entsprechenden Netzwerkkarten, die das unterstützen. Verwendet man nun VMXNET3 müssen alle Pakete die eine bestimmte VM erreichen sollen in einen gemeinsamen Puffer kopiert werden.

Normalerweise ist das kein Problem, da regulärer Traffic bei großen Bandbreiten auch große Pakete verwendet (z.B. Downloads, etc.)

Erfährt ein System nun viele kleine Pakete (weil es VoIP routet oder unter einem (D)DoS-Angriff steht oder...) gibt es hier aber ein Bottleneck:

Möchte man Routing-Entscheidungen (oder (D/S)NAT-Entscheidungen) mit iptables oder nftables treffen oder einfach nur kleine UDP-Pakete mit diversen iptables-Regeln unter Linux verwerfen kommt das Problem auf, dass die netfilter-Hooks auf dem Core verarbeitet werden, auf dem Pakete ankommen.

Mit VMXNET3 besteht also das Problem, dass mit "realtiv geringer" Paket-Anzahl (64 Bytes Größe, weniger als ein GBit/s auf einem aktuellen Xeon > 3.1 GHz) eine nicht all zu große Firewall-Konfiguration unter Linux (~60 Regeln) den Core, welcher die Pakete von VMXNET3 entgegen nimmt voll ausgelastet ist.

Ist es möglich VMXNET3 so zu konfigurieren, dass es mehrere Puffer verwendet? Habe ich bei Linux eine Kernel-Konfiguration übersehen, welche die netfilter-Verarbeitung auf andere Cores offloaden kann?

Danke für Eure Antworten.

Experte
Beiträge: 1890
Registriert: 23.02.2012, 12:26

Re: Viele, viele Pakete verarbeiten mit VMXNET3/Linux

Beitragvon ~thc » 25.06.2018, 17:45

Hmm. (Calculator angeworfen) 1 GBit/s mit 64-Byte-Paketen sind ca. 2,1 Millionen Pakete pro Sekunde.
Sorry, aber das ist für mich das Einsatzgebiet von physischen Firewalls.

Member
Beiträge: 8
Registriert: 25.06.2018, 02:46

Re: Viele, viele Pakete verarbeiten mit VMXNET3/Linux

Beitragvon GhostTyper » 25.06.2018, 17:57

Effektiv sind es c.A. 1,85 Mio Pakete pro Sekunde.

Mir ist bewusst, dass Hardware-Firewalls prädestiniert für diesen Fall sind. Diese kosten aber m.M. nach für das Preis-/Leistungs-Verhältnis durch die Bank weg viel zu viel. (Es handelt sich um ein 10 GBit Netzwerk, also noch viel mehr Pakete!)

Ordentliche Server-Hardware für die man dann selbst auch noch Software schreiben kann, kann das schon handeln.

Jetzt ist also nur noch die Frage, ob ich eine VM (und die Infrastruktur d'rum herum) so optimieren kann, dass diese hier auch möglichst gut performed.

Vielleicht gibt es auch noch andere Möglichkeiten, an die ich nicht gedacht habe?

King of the Hill
Beiträge: 12302
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Re: Viele, viele Pakete verarbeiten mit VMXNET3/Linux

Beitragvon Dayworker » 25.06.2018, 18:36

Schau mal nach, ob die vmxnet3 auch TOE (TCP Offload Engine) und vor allem RSS (Receive Side Scaling) unterstützt. Wenn du Intel-10GE im Host hast, sollte es eigentlich beide Menupunkte im Gast-OS geben.

Member
Beiträge: 8
Registriert: 25.06.2018, 02:46

Re: Viele, viele Pakete verarbeiten mit VMXNET3/Linux

Beitragvon GhostTyper » 25.06.2018, 21:53

Ich habe hier einen Test-Server mit I350 Karten und diese unterstützen 8 Kanäle RSS. Also habe ich in dem Linux nachgeguckt und in der Tat: Es werden 4 RX-Queues (die VM hat 4 Cores) angezeigt.

Es scheint aber trotzdem nur ein RSS-Kanal benutzt zu werden, auch wenn ich diese im Gast an dedizierte Cores binde.

Kurzes nachlesen bringt die Lösung: Ich teste mit kleinen UDP-Paketen, aber RSS funktioniert mit UDP nicht. Allerdings werden die eingehenden Pakete auch nicht verteilt, wenn ich TCP-Ströme mit kleinen Paketen von unterschiedlichen IP-Adressen simuliere.

Kann man in ESXi den RSS-Algorithmus, wie der Hash gebildet wird (und die Entscheidung für eine bestimmte RX-Queue fällt) konfigurieren?

Member
Beiträge: 8
Registriert: 25.06.2018, 02:46

Re: Viele, viele Pakete verarbeiten mit VMXNET3/Linux

Beitragvon GhostTyper » 26.06.2018, 10:14

Also, ich hab' jetzt folgendes herausgefunden:

Echtes RSS, auch in VMs unterstützt ESXi tatsächlich nur für Intel 82599EB und Mellanox MT27500 Netzwerkkarten. Dieses muss zudem extra im System aktiviert werden:

Code: Alles auswählen

vmkload_mod ixgbe RSS="4"


Bei anderer physikalischer Hardware wird RSS in VMXNET3 trotzdem aktiviert, es hat aber keinen wirklichen Effekt, da in kurzen Zeitscheiben (oder bei viel Traffic in längeren) dann einfach nur die Cores (und RX Queues) gewechselt werden, die Daten empfangen.

Auch RPS im Linux-Kernel löst dieses Problem nicht. Damit kann ich zwar die netfilter-Auswertung auf bestimmte Cores zwingen, dann aber mit einem enormen Overhead durch Cache-Misses, etc. (20 iptables-Regeln, die einfach Pakete verwerfen führen bei 1 GBit/s voller kleiner Pakete statt zu 10% CPU-Auslastung zu über 50% CPU-Auslastung.) Zudem geht mir dabei trotzdem die Dynamik verloren, weil ich ja alle Cores benutzen möchte und der Linux-Kernel mir diese dann sowieso nur auf den Core legt, mit der er das Paket via RSS empfangen hat.

Wenn ich eine Testumgebung mit einer kompatiblen Netzwerkkarte habe schreibe ich evtl. nochmal um mitzuteilen, wie gut das dann funktioniert.

Experte
Beiträge: 1890
Registriert: 23.02.2012, 12:26

Re: Viele, viele Pakete verarbeiten mit VMXNET3/Linux

Beitragvon ~thc » 26.06.2018, 13:13

Der Parameter für das ESXi-Modul ermöglicht das ja dann nur für die physische Karte (vmnicX).

In diesem Artkel
https://www.paloaltonetworks.com/documentation/80/virtualization/virtualization/set-up-a-vm-series-firewall-on-an-esxi-server/performance-tuning-of-the-vm-series-for-esxi/enable-multi-queue-support-for-nics-on-esxi
steht, dass man der VM sagen muss, die Fähigkeiten der pNIC auch zu nutzen.

Experte
Beiträge: 1296
Registriert: 30.03.2009, 17:13

Re: Viele, viele Pakete verarbeiten mit VMXNET3/Linux

Beitragvon UrsDerBär » 26.06.2018, 18:09

Bin da auch gespannt auf weitere Infos. Noch lieber wäre mir ja irgend eine Form von Offload für den Hostinternen Traffic.
Da wird bei Datenübertragungen bei entsprechender Hardware die CPU ziemlich schnell das Nadelöhr.

Member
Beiträge: 8
Registriert: 25.06.2018, 02:46

Re: Viele, viele Pakete verarbeiten mit VMXNET3/Linux

Beitragvon GhostTyper » 27.06.2018, 03:02

@~thc: Das wusste ich bereits. Aber Angeblich wird RSS nur bei den zwei von mir genannten Modulen unterstützt und da habe ich gerade wie gesagt kein kompatibles Test-Setup. RSS nur in der VM zu aktivieren bringt keine Lösung, da ESXi nur mehr Kanäle benutzt, wenn der Host diese bereits via RSS empfängt.

Ist die Änderung nach Deiner Anleitung dann permanent?

@UrsDerBär: Ich habe irgendwo gelesen, dass man bei RSS zwischen VMs ziemlich viel Ressourcen verbrät und man dem System einzelne CPU Cores als sparse(?) CPUs zuweisen muss und diese dann dem VSwitch zuweisen muss? (Aus dem Gedächtnis geschrieben.)

Experte
Beiträge: 1890
Registriert: 23.02.2012, 12:26

Re: Viele, viele Pakete verarbeiten mit VMXNET3/Linux

Beitragvon ~thc » 27.06.2018, 07:47

Wenn du mit permanent den Befehl für das ixgbe-Modul meinst: Nein, das ist einer der Nachteile eines RAMDisk-OS wie ESXi.

Experte
Beiträge: 1296
Registriert: 30.03.2009, 17:13

Re: Viele, viele Pakete verarbeiten mit VMXNET3/Linux

Beitragvon UrsDerBär » 27.06.2018, 08:56

@GhostTyper: Die CPU-Zyklen sind bei hohen Transferraten in der Tat ein Problem. Ob das mit RSS anders ist, kann ich nicht beurteilen. Ist auch mit Standard-Settings so. RSS dürfte wohl nur bei externer Kommunikation hilfreich sein. Host-Intern werden einfach bei beiden beteiligten VM's die Zyklen verbratet. Hier wäre eine Offload an einen dedizierten Chip wohl hilfreich.

Auf alle Fälle skaliert es ziemlich linear mit der GHZ-Leistung und fast linear mit der anzahl Core's. So meine Erfahrung. Sprich willst mehr Power, brauchst auch mehr Cores. Am besten dann dediziert auf dem gleichen Sockel.

Member
Beiträge: 8
Registriert: 25.06.2018, 02:46

Re: Viele, viele Pakete verarbeiten mit VMXNET3/Linux

Beitragvon GhostTyper » 28.06.2018, 14:19

@~thc: Ob das ein "RAMDisk-OS" ist (was es nicht ist nur weil es primär von einer initrd lädt) gibt ja keine Auskunft darüber ob es Daten speichern kann. Ich kann ja auch Konfigurationsänderungen bei ESXi vornehmen, die dann persistent sind. Mir war im Prinzip schon klar, dass ein neuladen des Moduls nicht dauerhaft ist. Das war also eher die versteckte Frage danach, wie man das dauerhaft machen kann.

@UrsDerBär: Bei meinem Scenario wäre RSS zwischen VMs mit viel Traffic auch nicht schlecht. Ich werde das auf jedenfall testen, wenn ich die Zeit dafür finde. (Kann also etwas dauern.)

Experte
Beiträge: 1890
Registriert: 23.02.2012, 12:26

Re: Viele, viele Pakete verarbeiten mit VMXNET3/Linux

Beitragvon ~thc » 28.06.2018, 14:48

GhostTyper hat geschrieben:Ob das ein "RAMDisk-OS" ist (was es nicht ist nur weil es primär von einer initrd lädt) gibt ja keine Auskunft darüber ob es Daten speichern kann.

Dann schreib doch mal in der ESXi-Shell in das Root-Dateisystem eine Datei (/etc/ichwarhier) und schau nach einem Neustart nach, ob sie noch da ist.

GhostTyper hat geschrieben:Ich kann ja auch Konfigurationsänderungen bei ESXi vornehmen, die dann persistent sind.

Weil die beteiligten ESXi-Dienste das in die Datei "state.tgz" in die jeweilige Bootbank schreiben, wo es beim nächsten Start dann wieder geladen wird.

GhostTyper hat geschrieben:Mir war im Prinzip schon klar, dass ein neuladen des Moduls nicht dauerhaft ist. Das war also eher die versteckte Frage danach, wie man das dauerhaft machen kann.

Du muss im Prinzip ein eigenes Modul (VIB) schreiben und installieren.

Member
Beiträge: 8
Registriert: 25.06.2018, 02:46

Re: Viele, viele Pakete verarbeiten mit VMXNET3/Linux

Beitragvon GhostTyper » 01.07.2018, 07:35

AHA, AHA! Interessantes "Argument". Aber was würdest Du sagen, wenn ich mit vi eine bestehende Datei (/etc/resolv.conf) auf gültige Weise ändern kann und diese Änderung dann über den Neustart, ja sogar über ein Update von ESXi 5.5 auf 6.5 hinaus persistent ist? Hat dann die RAMDisk ein Loch oder ist das einfach kein gültiges Argument?

Jetzt Mal ohne Spaß: Es könnte natürlich sein, dass ein Kommando dazu führt, dass (was auch immer) zurück geschrieben wird.

Ich würde diese Konfiguration später nur auf einem Host machen. Dafür eine VIB zu machen und sich anzueignen, wie das "ordentlich" geht ist viel zu viel Aufwand.

Experte
Beiträge: 1890
Registriert: 23.02.2012, 12:26

Re: Viele, viele Pakete verarbeiten mit VMXNET3/Linux

Beitragvon ~thc » 02.07.2018, 08:19

GhostTyper hat geschrieben:Aber was würdest Du sagen, wenn ich mit vi eine bestehende Datei (/etc/resolv.conf) auf gültige Weise ändern kann und diese Änderung dann über den Neustart, ja sogar über ein Update von ESXi 5.5 auf 6.5 hinaus persistent ist? Hat dann die RAMDisk ein Loch oder ist das einfach kein gültiges Argument?

Ich würde dazu sagen, dass du aus dem richtigen Fakt, dass Änderungen in der /etc/resolv.conf erhalten bleiben, voreilig den Schluss gezogen hast, dass ESXi nicht RAMDisk-basiert ist. Warum die Ingenieure bei VMWare das für sinnvoll halten, kann ich dir nicht sagen, aber bestimmte Dateien (/etc/resolv.conf gehört dazu) werden beim regulären Herunterfahren/Neustarten auch mit in die "state.tgz" geschrieben. Du kannst das überprüfen, in dem du dort etwas änderst und einen Hardreset des ESXi durchführst.

Member
Beiträge: 8
Registriert: 25.06.2018, 02:46

Re: Viele, viele Pakete verarbeiten mit VMXNET3/Linux

Beitragvon GhostTyper » 05.07.2018, 12:04

Und ich würde sagen, dass es genau deswegen irrelevant ist, ob ESXi ein "RAMDisk-OS" ist.

Für die anderen, die den Anschluss verloren haben: Ich werde das mit dem RSS (auch zwischen Maschinen) testen, wenn ich entsprechende Hardware habe und dann auch Messungen machen, wie gut viele kleine Pakete dann von einem Linux-Gast verarbeitet werden können und mich dann hier wieder melden.


Zurück zu „vSphere 6.5“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast