Regelmäßige Abbrüche der Netzwerkverbindung (e1qexpress)

[testperson 1.682]

Also VMWare ist so einer der Hersteller, der nahezu für alles Best Practices hat:

 

http://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/support/landing-pages/virtual-support-day-best-practices-virtual-networking-june-2012.pdf

https://www.vmware.com/pdf/Perf_Best_Practices_vSphere5.5.pdf

 

https://pubs.vmware.com/vsphere-55/topic/com.vmware.ICbase/PDF/vsphere-esxi-vcenter-server-55-networking-guide.pdf

[magheinz 110]

Wir stellen unter vsphere 6 grade auf vmxnet3 um.

Da geht dann tatsächlich durch was der Host kann und nicht nur 1GBit. Bisher läuft es stabil mit allen VMs (Windows, Debian, redhat)

der Treiber wir mit den VMwaretools installiert. Per powershell kann man den Kartentyp wechseln ohne das sich die MAC ändert!

[zahni 554]

@Weingeist, mit  E1000 gab es bei 5.1 auch auch ein paar Bugs...

[Weingeist 159]

@Weingeist, mit  E1000 gab es bei 5.1 auch auch ein paar Bugs...

Ich meine das war ziemlich Host abhängig. Andere Leute berichteten es genau anders rum. Auf manchen lief das eine besser auf dem anderen jenes. Auf meinen Hosts (Fujitsu und Supermicro) hatte ich mit E1000 nie wirkliche Probleme unter 5.1, nur ne Menge Log-Einträge. Tat aber der Performance oder Stabilität der Verbindung keinen Abbruch.

 

Wie auch immer, VMXNET3 kann und sollte aktuell wohl generell verwendet werden. Funzt am besten.

 

@magheinz: Die Übertragungsrate ist vor allem auch CPU-abhängig. Die Rate skaliert mit VMXNET3 linear hoch wenn mehr CPU-Kerne verfügbar sind. Höhere Takrate bringt dagegen mehr als nur linear etwas. Immer vorausgesetzt, dass das Storage auch die notwendigen IOPS bereitstellt. Davon bin ich auf meiner SAN weit entfernt aber auf meinen hostinternen Storages komme ich bei Recovery oder Backup bis fast an die Herstellerspezifischen Angaben der SSD's in RAID10 ran. Skaliert dann ebenso nahtlos wenn mehr SSD's im selben Stripe sind. Braucht dann aber auch ein paar 3GHZ Kerne in der Quelle und im Ziel.

 

@Ulupus: Vorher vergessen, Treiber für VMXNET3 sind Bestandteil der VmWare Tools

[testperson 1.682]

Bei vernünftigen NICs, entsprechender Konfig, aktuellen Treibern / Firmwareständen (und passendem Guest OS) sollten die CPUs eigentlich wenig mit dem "Netzwerk-Overhead" zu tun haben.

Bei 5.0 oder 5.1 gab es AFAIK mal die Empfehlung TSO / LRO auf dem Host zu deaktivieren (in Verbindung mit VMXnet?). Kann aber auch sein, dass es da nur spezielle Fälle betraf.

[Weingeist 159]

@testperson: Das kommt ganz auf die Übertragungsrate an. Die virtuelle Netzwerkkarte ist immer direkt abhängig von der CPU solange nicht Direct Path I/O genutzt wird. Nur fällt das normalerweise gar nicht auf, weil man in einer einzelnen VM meistens eh ned soviel Leistung abruft bzw. abrufen kann.

Ich erreiche die CPU-Limitierung auch nur Hostintern auf den SSD-Primär- und Sekundärspeichern, da läuft nichts via externer Netzwerkkarte ab sondern nur hostinern im Netzwerk-Stack. Da muss aber ohne Direct IO alles drüber. Extern habe ich kein Storage welches diese IO-Leistung auch nur Ansatzweise verarbeiten könnte geschweige denn die entsprechende FC oder oder sonstige Lösung ;)

Habe das auch nur Testweise gemacht zum sehen wo tatsächlich ende ist, wollte produktiv ned so viele Kerne der Storage App "opfern"

bearbeitet 11. Oktober 2016 von Weingeist

[magheinz 110]

Ich hab direkt den durchsatz von VM zu VM gemessen. Storage hat da keine Rolle gespielt. Zwei VMs auf einem Host: 22MBit/sek. Zwei VMs auf verschiedenen Hosts: Knappe 10GBit/sek. Mit e1000 logischerweise nie mehr als 1GBit/sek.

bearbeitet 11. Oktober 2016 von magheinz

[ULupus 10]

Vielen Dank an alle! Ich werde berichten (wird aber noch dauern.) Ulrich