ESXi LACP load balancing

[zonderbloem]

Mijn server heeft 4x een NIC verbonden met een Dell switch. Op de server draai ik ESXi-6.5u1. Ik heb de vier NICs binnen vmware ESXi verbonden met een vSwitch0 en NIC Teaming staat ingesteld op Route based on originating port ID. Op de Synology NAS heb ik ook vier uplinks, ik heb hier 802.3ad(LACP) aggregation ingeschakeld en op de switch heb ik een channel-group mode active geconfigureerd. Synology geeft aan 4Gbit ter beschikking te hebben.

Ik merk als de back-up wegschrijft naar de NAS dat dit toch gebeurt over 1 NIC, andere sessies worden dan wel verdeeld naar de tweede NIC maar ik heb maar 1Gbit uplink naar de NAS ter beschikking. Op de vSwitch heb ik geprobeerd om load balancing over te zetten naar "Route based on IP hash" en op mijn switch heb ik de channel-group mode active gebruikt. Na het instellen verliest de ESXi host zijn volledige netwerk connectie totdat ik de switch channel-group configuratie weer weghaal.

Mijn vraag(en): Hoe kan ik er voor zorgen dat ik 4Gbit netwerkconnectie naar mijn NAS heb? Aan de NAS configuratie ligt het volgensmij niet. En hoe zit dit als je bijvoorbeeld 1 uplink uit je server trekt, verliest deze zijn netwerkconnectie?

[Zenix]

vSwitch doet geen LACP. Alleen maar static LAG. dvSwitch kan wel LACP. Misschien gaat het daar fout.

[DukeBox]

Dat kan alleen met mpio.

[zonderbloem]

Zenix schreef op zaterdag 14 april 2018 @ 11:54:
vSwitch doet geen LACP. Alleen maar static LAG. dvSwitch kan wel LACP. Misschien gaat het daar fout.

Dus ipv channel-group nummer mode active (LACP), channel-group nummer mode on (LAG)
Dat zag ik op de Dell pagina

[zonderbloem]

DukeBox schreef op zaterdag 14 april 2018 @ 11:56:
Dat kan alleen met mpio.

Kun je me een beetje op weg helpen hoe dat in te stellen is?

[Zenix]

zonderbloem schreef op zaterdag 14 april 2018 @ 11:59:
[...]


Dus ipv channel-group nummer mode active (LACP), channel-group nummer mode on (LAG)
Dat zag ik op de Dell pagina

Ja

[DukeBox]

zonderbloem schreef op zaterdag 14 april 2018 @ 12:03:
Kun je me een beetje op weg helpen hoe dat in te stellen is?

Had je best zelf kunnen googlen:
https://www.synology.com/...er_with_Multipath_Support

[Predator]

Het is een wijdverspreid misverstand dat 4x1G in LACP leidt tot 4G.
LACP heeft een verdeel algoritme. Dan kan bv source/destination ip zijn. Hierbij zal communicatie tussen 2 dezelfde hosts altijd over 1 link gaan. Want de hash geeft altijd dezelfde poort. 2 andere hosts kunnen wel op een andere poort uitkomen. Sommige hosts of switches kunnen de tcp/udp poort meenemen in de hash. Maar 1 tcp/udp connectie zal nog steeds maar 1 link gebruiken. Dit is ook deels om out-of-order packets tegen te gaan. Het algoritme hoeft niet hetzelfde te zijn langs beide kanten (en dat is vaak ook niet zo).
Hoe meer flows/hosts, hoe beter de verdeling.
Je bent inderdaad meer met MPIO.


Ps: mode active of mode on maakt niets uit. Bij mode on doe je gewoon port bundling zonder mgmt protocol (lacp)

[zonderbloem]

Predator schreef op zondag 15 april 2018 @ 08:41:
Het is een wijdverspreid misverstand dat 4x1G in LACP leidt tot 4G.
LACP heeft een verdeel algoritme. Dan kan bv source/destination ip zijn. Hierbij zal communicatie tussen 2 dezelfde hosts altijd over 1 link gaan. Want de hash geeft altijd dezelfde poort. 2 andere hosts kunnen wel op ......

Bedankt voor je uitleg, ik was altijd in de veronderstelling dat een channel-group zelf load-balancing toepast. Dat communicatie tussen twee clients toch maar over 1 NIC gaat, dat was juist de situatie die ik dacht op te lossen met LACP. Is dit een beperking van de ESXi of werkt LACP altijd op deze wijze?

Kun je mij vertellen wat het verschil/voordeel van onderstaande situaties is?
- 4x NIC en in ESXi - Load balancing Route based on originating port ID zonder LACP ingeschakeld
- 4x NIC en in ESXi - Route based on IP hash met LACP ingeschakeld

Ik zat de documentatie van vmware door te nemen. Het betreft een NFS share naar een NAS toe. Volgens de documentatie werkt MPIO niet met NFS. Alleen met iSCI of zie ik dat verkeerd?

[Predator]

zonderbloem schreef op maandag 16 april 2018 @ 09:59:


Bedankt voor je uitleg, ik was altijd in de veronderstelling dat een channel-group zelf load-balancing toepast. Dat communicatie tussen twee clients toch maar over 1 NIC gaat, dat was juist de situatie die ik dacht op te lossen met LACP. Is dit een beperking van de ESXi of werkt LACP altijd op deze wijze?

Dat is load-balancing. Load balancing werkt (bijna) altijd met een verdeelsleutel.
LACP werkt altijd zo, alleen is het algoritme per kant (server tov switch) vaak anders. Dat maakt ook niet uit.

Kun je mij vertellen wat het verschil/voordeel van onderstaande situaties is?
- 4x NIC en in ESXi - Load balancing Route based on originating port ID zonder LACP ingeschakeld

Hier heb je geen port bundle, maar zal uitgaand verkeer per VM port ID worden gemapt op 1 van de fysieke NIC's in de groep. Je hebt echter geen LACP/etherchannel support nodig op je switches.
Nadeel is dat de verdeling slechter is.

- 4x NIC en in ESXi - Route based on IP hash met LACP ingeschakeld

Hier draait LACP als management protocol (er wordt LACP gepraat met de switch.
De verdeler is een IP hash (dus packets tussen 2 dezelfde ip's gaan nog altijd over dezelfde poort).

Ik zat de documentatie van vmware door te nemen. Het betreft een NFS share naar een NAS toe. Volgens de documentatie werkt MPIO niet met NFS. Alleen met iSCI of zie ik dat verkeerd?

Dat zou kunnen, maar als je echt meer single connectie performance wilt, dan is er eigenlijk maar 1 oplossing. Overgaan naar 2x10Gb (of 4x) ipv 4x1G.
LACP is vooral een redundantie mechanisme, en kan vermijden dat 1 flow de hele link op 100% zet.
Maar voor echte bandbreedte upscaling moet je de NIC's upscalen.

PS: met 10G Twinax DAC kabels is 10G zelf goedkoper dan 1G SFP's (in een 1/10G SFP+ poort).

[bigfoot1942]

zonderbloem schreef op maandag 16 april 2018 @ 09:59:
[...]

Ik zat de documentatie van vmware door te nemen. Het betreft een NFS share naar een NAS toe. Volgens de documentatie werkt MPIO niet met NFS. Alleen met iSCI of zie ik dat verkeerd?

Klopt, met iSCSI werkt het wel, voor NFS is het magertjes:
docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.storage.doc