Teaming/Trunking oder Jumbo Frames

[lennier]

Hallo zusammen,

für ein aktuelles Projekt stehe ich vor der Frage ob Teaming oder Jumbo Frames die Technik der Wahl sind.

Die Anforderungen:

- da sind ein vSphere 5.1mit i350 dualport
- ein großes qnap NAS
- ein vcenterserver PC mit Realtek dualport

Das NAS spedet einen großen Teil seiner Kapazität als iSCSI an den vcenterserver, denn dort soll mittels veeam Backups der Virtuellen Maschinen abgelegt werden.

Ich möchte nun zwischen den drei Geräten den größtmöglichen Datendurchsatz erreichen und die beiden Technologien besser verstehen lernen.

Meine Fragen:
Erreiche ich durch Teaming tatsächlich annähernd 2Gbit oder funktioniert der Ansatz nur bei mehreren gleichzeitigen Verbindungen die zwischen den beiden Ports aufgeteilt werden?
Wenn ich Jumbo Frames verwende wie muss ich diese im ESX verwenden?
Der Host hat 1Gbit Ports, im Guest hab ich einen 10Gbit Adapter wer schnürt dann das Päckchen das extern auf die reise geht?

Ich hoffe das sich hier schon mehrere Gedanken über die Problematik gemacht haben und über die Materie viel mehr wissen als ich.

Vielen Dank!

[Dayworker]

Welche Geschwindigkeit dir im Gast-OS für die Netzwerkverbindung angezeigt wird, ist völlig belanglos. Selbst wenn du dort eine 1MBit-Karte einrichtest, wird deren Geschwindigkeit gegenüber einem externen Netzwerk-Gerät immer der im Host ensprechen und bei einer i350 sind das halt 1GBit.

Jumbo Frames müssen von allen Netzwerkteilnehmern unterstützt werden und von Teaming halte ich bei lediglich einer Netzwerk-Karte überhaupt nichts. Wenn die Karte ausfällt, stehen die Gäste auf dem ESXi ohne Netzwerkverbindung in die Aussenwelt da und von der Warte spielt es dann für mich auch keine Rolle mehr, ob du Karte in Dual- oder Quad-Ausführung vorliegt.

[mbreidenbach]

Ob Teaming was bringt hängt vom Loadbalancingalgorithmis ab. Worst case bringt es keine Performanceverbesserung da der Loadbalancingalgorithmus alles über eine Leitung schickt.

Beispiel: Hash nach IP Adresse. Eine Absender IP, eine Ziel IP - immer gleicher Hash Wert. Alles über eine Leitung. Da muß man dann mal verifizieren daß alle Uplinks auch benutzt werden.

Ob die Jumbos funktionieren kann man mit vmkping testen; hier die richtige Paketgröße angeben und die Options setzen daß Pakete nicht gesplittet werden dürfen.

http://kb.vmware.com/kb/1003728
http://kb.vmware.com/kb/1003712

[lennier]

Ich hab jetzt ein wenig getestet und festgestellt, das Jumboframes wertlos sind.
Die Datenübertragung ist anfangs kurz höher, bricht danach aber extrem ein und bleibt niedrig.
Um etwaige mängel des verwendeten switch auszuschließen habe ich die Tests auch mit direkt angeschlossenem Gerät durchgeführt und bin zu dem selben Ergebnis gekommen.

[Dayworker]

Wenn die Datenrate zu anfangs hoch ist und dann dauerhaft einbricht, laufen entweder Puffer in der Nic über und man sollte mal nur die 3- bis 4-fache Framenormalgrösse ausprobieren oder die Verkabelung und dort speziell die Stecker sind von unzureichender Qualität. Wenn die Stecker mies gekrimpt sind, hilft dir halt auch eine superduper Cat7-Strippe nicht weiter.

[continuum]

Wir haben letztes Jahr im Rahmen eines iSCSI-workshops Benchmarks zu der performance von Jumboframes gemacht : im besten Fall konnte man 3 -4 % Performancegewinn heraus holen. Mehr nicht !

[Dayworker]

Damit Jumbo-Frames was bringen, müßte man die Verbindung sättigen und das erreicht man wohl kaum mit den üblichen OS-Anfragen im 4KByte-Raster. Falls man also nicht gerade sequentielle Übertragungen im Dauerbetrieb hat, können Jumbo-Frames keinen Vorteil bringen. Netzwerke sind auf die Standard-MTU von 1518Byte (davon sind 18 Byte für den Overhead eines Ethernet-Frames ohne IEEE 802.1Q-Feld sprich VLan oder Priorisierung) optimiert, Jumbo-Frames bringen über ihr vergrössertes Nutzdatenvolumen meist nicht mehr sehr viel. Ein weiterer Nebeneffekt davon ist eine ansteigende CPU-Last, da die Framegrösse nicht unabhängig davon ist. Dies wird erst mit LSO (Large Segment Offload) und LRO (Large Receive Offload) der TOE (TCP Offload Engine) erreicht und diese ist von VMware nach wie vor nicht vollständig umgesetzt.
Dieser TOE-Zustand läßt sich am besten am KB-Eintrag VMware ESXi 5.x host experiences a purple diagnostic screen mentioning E1000PollRxRing and E1000DevRx (2059053) ablesen.

[~thc]

@Dayworker: Der Purple Screen wird laut VMWare durch einen Bug im Zusammenhang mit dem Receive Side Scaling (RSS) im Guest-OS (Server 2012) mit dem "E1000E"- und "E1000"-Treiber ausgelöst.

Offloading kann ESXi 5 eigentlich und sollte auch meist klaglos funktionieren (http://kb.vmware.com/kb/2052904). Mit

Code: Alles auswählen

ethtool -k vmnicX

kann man sich in der ESXI-Shell alle Offloading-Einstellungen ansehen. Bei einer vmnic, über die ein iSCSI-Software-Adapter läuft, sollten die Offloadings nach Möglichkeit nicht ausgeschaltet sein.

@continuum: Je nach Test-Szenario (Blockgröße) können Jumbo-Frames auch erheblicher beschleunigen: http://en.community.dell.com/cfs-file.ashx/__key/telligent-evolution-components-attachments/13-4491-00-00-20-43-81-71/BP1065_2D00_ESXiNICoptimizationAndBestPracticesWithEqualLogicSAN.pdf. Die Frage ist, was davon in der Praxis spürbar bleibt. Eine Verschlechterung sollte sich jedenfalls nicht einstellen.

[Dayworker]

@~thc
Ausgehend vom Thread von "gea" namens ESXi 5.5/5.1 + ZFS/OmniOS/napp-it All-IN-ONE VM, gibt es auch hier Problem, wenn die e1000-Nic verwendet wird. Wie im Thread erwähnt, bringen die Umstellung auf VMXnet3 oder wenn man bei der e1000 bleiben will, die Deaktivierung einiger TOE-Features in Omnios die Abhilfe.


Im verlinkten EqualLogicSAN-PDF wird ja extra die Aktivierung von Jumbo-Frames bevorzugt. Wenn du diese aber nutzt und dadurch die Payload vergrösserst, wozu brauchst du dann noch Offloading? Der Sinn dieses Offloading soll doch meiner Meinung gerade sein, die entstehende CPU-Last durch den bei Standard-MTU-Grösse normalerweise vorhandenen Overhead zu verringern. Mit der von Dell empfohlenen MTU-Grösse von 9,000 Byte verringerst du doch den Overhead bereits auf 1/6tel, denn statt alle 1500 Byte gibts den ACK immer erst nach 9000 Byte.
Ich hab irgendwie auch keine Info gefunden, wie sich die Sache verhält, wenn ein Jumbo-Frame mal nicht voll wird. Entweder schickt der Sender dann auch mal ein kleineres Paket auf die Reise oder wartet auf ein volles Frame. In letzterem Fall würde es dann unweigerlich zu Performance-Einbrüchen kommen.

[PeterDA]

Wir haben letztes Jahr im Rahmen eines iSCSI-workshops Benchmarks zu der performance von Jumboframes gemacht : im besten Fall konnte man 3 -4 % Performancegewinn heraus holen. Mehr nicht !

Dem kann ich nur zustimmen. Jumbos bringen wohl nur was wenn man auf allen Ebenen mit Vollgas Last hat. Und das dürften wohl die wenigsten von uns haben. Habe letztens irgendwo eine Analyse von VMware gelesen, man hat festgestellt, dass im Schnitt bei Jumbo Frames nur etwas über 1/3 mit Daten gefüllt ist.

Gruß Peter

[~thc]

@Dayworker:

KB2058692: E1000E, TCP segmentation offloading, Data corruption (slow performance)
KB2059053: E1000 und E1000E, Receive Side Scaling, Purple Screen

Das sind zwei verschiedene Fehler, die nur einen Workaround gemeinsam haben. Beim 2058692er z.B. darfst du als Workarnound auch den E1000 nehmen.

Jumbo Frames bringen "nur" eine Verringerung des Protocol Overheads. Bei minimaler TCP-Header-Größe (20 Bytes IP, 20 Bytes TCP) kann ein MTU-9000-Paket 8960 Bytes Nutzdaten befördern. Ein MTU-1500-Paket analog 1460 Bytes. Im Idealfall von 8960 Bytes Nutzdaten muss ein MTU-1500-Interface daraus 7 Pakete machen. Mit dem Ethernet-Overhead (38 Bytes) wird daraus vereinfacht gerechnet:

MTU 1500: 8960 Bytes Nutzdaten + 7 x 40 Bytes Protocol-Overhead + 7 x 38 Bytes Ethernet-Overhead = 9506 Bytes
MTU 9000: 8960 Bytes Nutzdaten + 40 Bytes Protocol-Overhead + 38 Bytes Ethernet-Overhead = 9038 Bytes

Es sind also im Idealfall rein rechnerisch knapp 5% mehr Datenaufkommen - das kommt also mit Euren Erfahrungen von 3-4% in der Praxis ganz gut hin.

Das Offloading dagegen lagert die Berechnung der Prüfsummen der übertragenen Pakete (TCP Rx checksum offloading, TCP Tx checksum offloading), die gesamte Segmentierung in kleinere Pakete (TCP segmentation offloading, UDP fragmentation offloading, generic segmentation offloading) oder sogar die Berechnung aller Protokoll-Header (ISCSI engine offloading, iSEO) in die Hardware der Netzwerkkarte aus, um die Host-CPU zu entlasten.

Eine 9000er MTU verringert also den Overhead, reduziert die Paketanzahl und die Anzahl der Segmentierungen. Das Offloading verringert die Belastung der Host-CPU durch die Protokolle. Es schließt sich nicht aus, sondern ergänzt sich.

[Der letzte Jumbo-Frame in einer Sequenz ist dann eben k(l)einer]