Etherchannel/aggregated Ethernet werkt enkel in 1 richting

[sprankel]

Switch: Juniper EX4550-32F
Doel: Synolgy NAS
bron: ESXi host

LACP is geen optie, daar heb ik een distributed vswitch voor nodig maar de ESXi licentie laat dit niet toe.

Nas is gekopeld via NFS4.1 met multipath op 2 verschillende IP adressen. (langs de switch kant zijn dit 2 gewone poorten die niet gelinkt zijn)
Gezien ESXi enkel NFS multipath server side ondersteund kan ik niet hetlzefde doen daar.


Voor ESXi heb ik een vswitch met teaming actief op Route based on IP hash met daaraan 2 uplinks met 1 IP adres.
Langs de switch zijn kant zijn die 2 poorten gekoppeld aan elkaar met LACP op none.

De NAS gebruikt zijn 2 links voor zowel send als recieve.
De ESXi gebruikt enkel zijn 2 links voor transmit (en verdeeld de load perfect) maar bij recieve komt alles via 1 link binnen.
Is dit de switch die zijn werk niet doet of zie ik iets over het hoofd?

[Vorkie]

Voor ESXi heb ik een vswitch met teaming actief op Route based on IP hash met daaraan 2 uplinks met 1 IP adres

Als ik het zo lees heb je geen multipath aanstaan? Je VMKernel interfaces voor NFS moeten elk een eigen IP adres hebben uit het desbetreffende VLAN en zo heb je 2 actieve paden naar je datastore.

1 in VLAN DATA 1 en 1 in VLAN data 2.

[ Voor 19% gewijzigd door Vorkie op 07-10-2019 11:18 ]

[sprankel]

De NAS heeft 2 verschillende IP adressen in hetzelfde subnet. ESXi host heeft 1 vmkernel IP aan een vswitch met 2 uplinks. ESXi benaderd de NAS via NFS4.1 met multipath actief.


Uit de documentatie van vmware.com

"NFS 4.1 provides multipathing for servers that support the session trunking. When the trunking is available, you can use multiple IP addresses to access a single NFS volume. Client ID trunking is not supported."

Multipath werkt dus enkel server side maar niet client side, had het reeds geprobeerd overigens.

[Hero of Time]

Wat @Vorkie hierboven laat zien is wat ik op kantoor ook heb ingericht voor onze Synology NAS. Ik heb op de servers twee van de vier NICs gereserveerd voor twee aparte VLANs, elke poort z'n eigen VLAN. Op de Synology heb ik ook twee poorten ingericht met dezelfde opzet en dat werkt prima. Ene NIC connect over het ene VLAN naar de NAS, de andere NIC over de andere. Beide doen send/receive.

Hierdoor kan ik met een enkele VM één NIC vol gebruiken als disk performance. Een tweede VM op dezelfde host zal de andere NIC gebruiken. Zodra er meer dan twee VMs op een enkele host de volle bandbreedte willen gebruiken, zal dit logischerwijs beperkt worden.

Je denkfout hier is dat je VMware machine maar 1 IP adres heeft. Het kan heel leuk twee verbindingen met je NAS leggen, waardoor je de ene kant op netjes multipath doet. Maar de andere kant op, van je NAS naar VMware zal maar 1 verbinding zijn, want het gaat terug naar een enkel IP adres. Het maakt dan niet uit hoeveel netwerkpoorten je hebt. Zolang er 1 IP adres is, zal het een 1-op-1 verbinding zijn.

[sprankel]

Het doel was om echt een 20Gb link te krijgen, ook als slechts 1 VM dit vraagt. Wat je hier voorstelt is 2 aparte 10Gb links te leggen.

ESXi heeft idd maar 1 IP met 2 uplinks. Echter die 2 poorten zijn gelinkt in de (fysieke) switch.

In de huidige setup, getest met 1 VM heb ik wel een 20Gb uplink maar geen down.

ESXi stuurt verkeer naar 2 IP's over een aggregated link en gebruikt daar zijn 2 links voor.
De Nas krijgt dat verkeer binnen op 2 gescheiden NICS en verstuurd zijn data terug via zijn 2 gescheiden NICS en dus ook afkomstig van 2 verschillende IP adressen.
De switch heeft dus verkeer van 2 IP's (NAS) voor 1 IP (ESXi) maar het bijhorende mac adres is gekend onder 2 aggregated poorten. De switch moet dus wel kiezen welke poort hij neemt, gezien de traffic van 2 verschillende sources komt zou ik verwachten dat hij die verdeeld over de 2 poorten, en daar zit mijn probleem.

[Hero of Time]

Wat je wilt is alleen mogelijk (vziw) als je LACP gebruikt. En dat heb je niet. Je zit dan vast aan de 'beperkingen' van het TCP/IP protocol. Je maakt een connectie van een bepaald IP adres naar een ander bepaald IP adres. Daar gaat je data overheen. Een VM zal dus hoe dan ook max 10 Gbps kunnen krijgen voor z'n disk. Ook als je met twee aparte IP adressen verbinding zou maken met je NAS.

Ik heb hier een paar maanden geleden al lange tijd aan besteed om iets vergelijkbaars te krijgen, maar het zit er gewoon niet in zonder LACP.

[sprankel]

Hero of Time schreef op maandag 7 oktober 2019 @ 19:06:
Wat je wilt is alleen mogelijk (vziw) als je LACP gebruikt. En dat heb je niet. Je zit dan vast aan de 'beperkingen' van het TCP/IP protocol. Je maakt een connectie van een bepaald IP adres naar een ander bepaald IP adres. Daar gaat je data overheen. Een VM zal dus hoe dan ook max 10 Gbps kunnen krijgen voor z'n disk. Ook als je met twee aparte IP adressen verbinding zou maken met je NAS.

Ik heb hier een paar maanden geleden al lange tijd aan besteed om iets vergelijkbaars te krijgen, maar het zit er gewoon niet in zonder LACP.

Dan moet je nog is achter je hoofd krabben want ik heb het opgelost gekregen. De Juniper switch wou plots geen verkeer meer routeren en is zo net vervangen door een Dell switch. Gewoon de poorten gelinkt in de switch en 5 minuten later draait de boel zonder probleem, straks even met de hamer de Juniper bewerken.

Ik bevestig dus dat ik 1 VM heb die een 20Gb/sec link heeft naar een storage zonder gebruik te maken van LACP.

Ik snap je reactie dat je LACP nodig hebt omdat je voor gewone aggregated link (of ethernetchannel of hoe men het ook wilt noemen) je 2 IP's nodig hebt om de 2 links te kunnen gebruiken, anders verdeeld hij de traffic niet, echter dat mag zowel bij source als bij destination zijn. Gezien de NAS van 2 IP's praat door middel van NFS4.1 multicast is aan die voorwaarde voldaan. Mocht mijn NAS ook op een gewone aggregated link zitten dan was het 10Gb/sec, immers source & dest IP zijn altijd gelijk en dan gaat hij alles over 1 link sturen en is het zuiver fail over.

[Hero of Time]

@sprankel, zou je dan wat uitgebreider je opzet kunnen delen? Ik ben namelijk erg benieuwd hoe dit te doen is in mijn omgeving. Daar heb ik HP switches en ben dus benieuwd of wat jij hebt ook mogelijk is bij mij.

Als mijn uplink 10 Gbps was, had ik er niet veel aandacht aan besteed, maar helaas hebben m'n servers dat niet (de NAS wel) en zit ik aan 1 Gbps uplinks. Dan is het wat prettiger als ik er 2 Gbps van kan maken. Helaas draait het allemaal al in productie, dus kan niet 'eventjes' de config omgooien om te testen.

[PcDealer]

Het zou fijn zijn als @sprankel de verschillen tussen de switches hier openbaart of op zijn minst het type Dell switch zodat we zelf kunnen gaan zoeken naar de verschillen en waarom het dan wel zou werken.

[Vorkie]

De VMWare machine heeft dus 2 Mac adressen en 1 ip adres en de Synology heeft 2 Mac adressen en 2 ip adressen.

Vanuit ESX verbind je dus naar de 2 ip adressen van Synology waarbij ESX op basis van round Robin verbinding maakt.

Ik ben inderdaad ook nieuwsgierig hoe je dit allemaal hebt geconfigureerd, liefste met wat plaatjes :-)

[jvanhambelgium]

Vergeet niet dat dit een oplossing op applicatie-laag en niets meer met "networking" te maken heeft.
pNFS (parallel NFS) werkt over een aantal IP-links, zelf zoals hier aangegeven met verschillende IP's (of over verschillende VLAN's)

Het betreft hier dus een specieke NFS-client (in dit geval de ESX) , aanpassingen in de kernel alsook op de NFS-server kant (Synology) om dit mogelijk te maken. pNFS werkt compleet verschillende dan klassiek NFS vanwege de "split" tussen alle meta-data (files/folder indices,...) en de eigenlijk I/O-streams om de data te fetchen (dat gaat parallel en over verschillende paden of zelfs compleet verschillende storage servers)


Dit truukje werkt enkel voor NFS-storage, terwijl een oplossing op netwerk-vlak (LACP) natuurlijk transparant zou zijn voor bovenliggende applicaties en voor alle soort verkeer zal werken.

[sprankel]

@Hero of Time Zou toch eerst in een test omgeving een test opzetten

@Vorkie Bijna juist echter ESXI heeft maar 1 mac adres gekend (vergeet even die vcenter), de switch heeft poort A & B gekend onder hetzelfde IP en hetzelfde MAC, mocht de switch niet ingesteld staan hiervoor zou die niet gelukkig zijn.

@jvanhambelgium Klopt helemaal,dit trucje werkt zuiver omdat met het multipath verhaal, als mijn VM iets anders zou willen benaderen zal het 10GB/s zijn. Zuiver applicatie is het ook niet gezien de link aggregation langs de ESxi kant wel het netwerk aanpast tussen host en switch.

De nieuwe switch is een Dell x4012 maar met de Juniper had het ook moeten werken echter is die blijkbaar defect.

Heb geen screens van de switchen maar voor de Dell heb ik maar 1 iets van zijn factory settings aangepast, static LAG op 2 poorten van waar de esxi op toekomt.

Voor de Juniper, een aggregated interface op de 2 poorten met LACP op none. (Dit werkte half voordat de switch er volledig mee stopte)

https://www.juniper.net/d...nk-aggregation-j-web.html

Voor HP vond ik niet meteen een manual maar wel screenshots waar je in de GUI hetzelfde doet als bij Dell, link aggregation op static en dus met LACP op disabled.


Netwerk NAS:



Netwerk ESXI



NFS 4.1 actief




Storage is mounted als NFS41 met 2 IP's



Netwerk gebruik wanneer 1 VM (zelfs Vcenter staat uit) een benchmark begint te doen op zijn disk



Netwerk gebruik op de NAS



edit: Overigens presteert de raid 10 niet zoals hij moet maar dat heeft niets met bovenstaand te maken gezien hij met een vm op de NAS ook prestaties geeft die met moeite beter zijn dan een single disk. Dat gedeelte ben ik nog aan het bekijken.

[ Voor 7% gewijzigd door sprankel op 09-10-2019 12:25 ]

[Vorkie]

@sprankel Dank je wel voor je antwoord, ik zal dit eens testen hier, maar voor mij zie ik geen verschil in opzet.

Betreft mac adressen:
92 0050.5662.3xxx DYNAMIC Po20

Er is inderdaad maar 1 mac adres bekend, deze is van management interface ESX.

Zoals ik verder de opzet zie in de printscreens zie ik dat op ESX niveau er inderdaad load balancing wordt gedaan, maar dat is niet anders dan dat er in mijn print screens wordt gedaan, ook al zijn het 2 subnets en aparte NIC's. Het verschil is alleen dat je perse een port-channel moet creëren op je switch. Je VM zelf doet namelijk geen connectie maken met je datastore, dat doet de ESX host en deze verbind in essentie nog steeds naar 2 IP adressen, alleen nu vanuit 1 management Kernel Interface i.p.v. 2. (maar alsnog met 2 NIC's)

Ik denk als @Hero of Time in zijn traffic logs kijkt dat deze ook beide gelijk lopen op de Synology en ESX host, net zoals ik zie in VMWare en Synology.

Het is ook eerder, zoals @jvanhambelgium aangeeft, het NFS41 Multipath verhaal dat de snelheid doet gebruiken i.p.v. de netwerklaag zelf.

De VM zelf doet niets met de datastore.

[Hero of Time]

Vorkie schreef op zaterdag 12 oktober 2019 @ 11:25:
Ik denk als @Hero of Time in zijn traffic logs kijkt dat deze ook beide gelijk lopen op de Synology en ESX host, net zoals ik zie in VMWare en Synology.

Dat had ik al eens getest met dd. Ik krijg 1 NIC vol. M'n datastore performance voor een enkele VM is dus 1 Gbps. Ga ik met twee VMs die op dezelfde host draaien zo'n benchmark doen, dan doen beide VMs exact hetzelfde qua performance als wanneer ik er maar 1 test. Zou ik het met 3 VMs doen, dan zal er een normaal zijn, de andere twee delen de performance en zullen samen hetzelfde zijn als de ene losse.

Ik ben daarom wel benieuwd of @sprankel ook echt beide NICs vol kan trekken met een enkele VM.

[jvanhambelgium]

Hero of Time schreef op zaterdag 12 oktober 2019 @ 12:50:
[...]
Ik ben daarom wel benieuwd of @sprankel ook echt beide NICs vol kan trekken met een enkele VM.

Ik denk het wel aangezien het ESX is met z'n NFS 4.1 client met tweaks (om de datastore(s) en VMDK's te benaderen over NFS) die dus echt wel "multipath"-style gewoon z'n ding gaat doen.
Zolang je geen andere bottlenecks hebt zoals CPU/MEM van je VM en je doet maar genoeg I/O's krijg je dat wel vol zelfs met 1 VM.

** EDIT : En natuurlijk moet de NAS/Storage kant OOK kunnen volgen natuurlijk ;-)

[ Voor 7% gewijzigd door jvanhambelgium op 12-10-2019 17:01 ]

[Hero of Time]

jvanhambelgium schreef op zaterdag 12 oktober 2019 @ 15:00:
[...]

Ik denk het wel aangezien het ESX is met z'n NFS 4.1 client met tweaks (om de datastore(s) en VMDK's te benaderen over NFS) die dus echt wel "multipath"-style gewoon z'n ding gaat doen.
Zolang je geen andere bottlenecks hebt zoals CPU/MEM van je VM en je doet maar genoeg I/O's krijg je dat wel vol zelfs met 1 VM.

Ik betwijfel het enorm. De plaatjes die gepost zijn, trekken niet eens een enkele 10 Gbps uplink van 'm dicht. Dat is nog steeds geen enkel bewijs dat verkeer van een enkele verbinding ook echt over beide NICs gaan.

Ik heb een half jaar geleden met hulp van anderen hier, o.a. ook @Vorkie, mijn huidige setup voor elkaar en het is toch echt maar een enkele verbinding per virtuele schijf naar de storage. En dus effectief de bandbreedte van een enkele NIC, niet beide.


Hm, net even wat teruggelezen en ik schijn met een VM zo'n 255 MB/s te kunnen halen. Werkt dus prima bij mij.

[Vorkie]

Het lijkt er inderdaad op dat Synology dit i.s.m. VMWare volledig werkend heeft.

Eerlijk gezegd nooit zo op gelet, beide scenario's (zoals ik het heb en zoals TS) geven de verwachte doorvoersnelheid van de interfaces bij elkaar op geteld. Vooral handig als je gewoon wilt inprikken zonder trunking etc..

[sprankel]

Vorkie schreef op zaterdag 12 oktober 2019 @ 11:25:
@sprankel Dank je wel voor je antwoord, ik zal dit eens testen hier, maar voor mij zie ik geen verschil in opzet.

…

Het verschil is alleen dat je perse een port-channel moet creëren op je switch. Je VM zelf doet namelijk geen connectie maken met je datastore, dat doet de ESX host en deze verbind in essentie nog steeds naar 2 IP adressen, alleen nu vanuit 1 management Kernel Interface i.p.v. 2. (maar alsnog met 2 NIC's)

Dat verschil is net het punt, ESXi ondersteund enkel server side multipath. ESXi zal dus een vraag om storage verzenden van 1 IP naar 2 IP's en de server zal antwoorden naar 1 IP.
Mocht ESXi client side multipath ondersteunen (wat het dus niet doet) dan maak je gewoon 2 IP's op ESXi en 2 op je NFS server en je hebt 20 Gb/s.

Dat probleem dat ESXi geen client side multipath heeft los ik op door het 1 IP te geven en een link aggregation te maken op de switch. Daardoor gaan zowel ESXi en de switch verkeer load balancen afhankelijk van welk IP naar welk IP. Gezien het verkeer is van en naar 2 IP's (door multipath server side) gaat link aggregation dat load balancen met als gevolg dat ik een 20 Gb/sec link krijg.

Stel dat ik toch 2 IP's aanmaak op Esxi en de link aggregation laat vallen, dan gaat ESXi versturen van NIC A naar 2 IP's en de NAS gaat enkel sturen naar IP van Nic A. Tenzij je een 2de VM laat lopen en ESXi besluit om van NIC B te gaan sturen.

@Hero of Time

De storage is te traag om 10 Gb/s vol te krijgen, daar loopt een ticket bij Synology voor die het al geëscaleerd heeft naar hun ontwikkelteam. De raid10 zou met gemak over de 10 moeten gaan maar met een VM op de NAS zelf haalt hij dezelfde veel te trage snelheid (het ligt dus niet aan NSF en netwerk)

[ Voor 9% gewijzigd door sprankel op 12-10-2019 20:36 ]

[Vorkie]

@sprankel Verklaard niet waarom ik en @Hero of Time op basis van mijn configuratie met 1 enkele VM boven de enkele link speed komen?

/edit
Dit heeft te maken met Session Trunking van het NFS4.1 protocol.

https://packetpushers.net/multipathing-nfs4-1-kvm/

NFS4.1 detect session trunking and aggregate the new connection on the eth2 to the existing session initialized by the first connection on eth1.

Gezien de Synology dit ondersteund en VMWare ook wordt er dus, ongeacht of je nou port-channels gebruikt of gescheiden interfaces, een session Trunk opgebouwd en zo doende beide lijnen gebruikt voor het lezen/schrijven van bestanden.

NFS 4.1, by contrast, provides multipathing for servers that support the session trunking. With session trunking, servers maintain the states per session. We can have multiple connections associated with a session. When the session trunking is available, we can use multiple IP addresses to access a single NFS volume.

https://vspherecentral.vm...ation-and-best-practices/

Het is dus niet perse noodzakelijk om een port-channel op te bouwen.

Als we dan het document van VMware er nog eens bij pakken geven ze eigenlijk aan dat je beter juist gescheiden netwerken kan gebruiken, inclusief failover (dus 4 lijnen) voor redundantie.

Paths in different Subnets
With different subnets we can configure multiple vmkernel portgroups to communicate with IP address in the respective subnets. This configuration provides independent connections from each vmkernel portgroup and provides better redundancy and bandwidth utilization than paths in the same subnet.

[ Voor 97% gewijzigd door Vorkie op 12-10-2019 21:09 ]

[Hero of Time]

sprankel schreef op zaterdag 12 oktober 2019 @ 20:33:
@Hero of Time

De storage is te traag om 10 Gb/s vol te krijgen, daar loopt een ticket bij Synology voor die het al geëscaleerd heeft naar hun ontwikkelteam. De raid10 zou met gemak over de 10 moeten gaan maar met een VM op de NAS zelf haalt hij dezelfde veel te trage snelheid (het ligt dus niet aan NSF en netwerk)

Dat klinkt meer als dat je de verkeerde schijven erin hebt zitten of onvoldoende aantal. RAID10 met 4 HDDs gaat 'm nooit worden. Je hebt nooit aangegeven wat je NAS configuratie is, anders dan het RAID niveau.

[sprankel]

Hero of Time schreef op zaterdag 12 oktober 2019 @ 20:57:
[...]

Dat klinkt meer als dat je de verkeerde schijven erin hebt zitten of onvoldoende aantal. RAID10 met 4 HDDs gaat 'm nooit worden. Je hebt nooit aangegeven wat je NAS configuratie is, anders dan het RAID niveau.

Momenteel 6 Crucials MX500 1 TB
Single disk performance buiten nas: 510 read 430 write
Single disk performance binnen nas: 300 read, 400 write
Single disk performance binnen nas met write cache uitgeschakeld: 300 read 90 write
Raid 10 performance: 760 read 980 write

IOP's performance is vergelijkbaar single disk als in raid 10.

[Hero of Time]

Die 300 read klinkt als SATA2. Weet je zeker dat de juist controller erin zit en je niet onnodig een ticket hebt aangemaakt bij Synology?

[sprankel]

Vorkie schreef op zaterdag 12 oktober 2019 @ 20:41:
@sprankel Verklaard niet waarom ik en @Hero of Time op basis van mijn configuratie met 1 enkele VM boven de enkele link speed komen?

@Hero of Time geraakt niet boven single link speed met 1 VM maar zou dat graag kunnen.
Voor ik op het idee kwam om link aggregaten en multipath te combineren heb ik jou systeem getest maar ik kreeg single link speed en dan kwam ik een document van VMware tegen dat ze enkel server side multipath zouden doen.

Ik heb wel beide IP's in hetzelfde subnet gehouden.

@Hero of Time

Betreft een RS3617xs+ uitgebreid naar 32GB met 2 maal RX1217 uitbreiding. Rotterende disks zitten in de uitbreiding, SSD's op de RS3617xs+ zelf. Niet iets waar ik een sata2 controller in verwacht

Overigens heeft Synology via hun ingebakken remote assistance tool zelf ingelogd op de NAS om het te bekijken.

[Hero of Time]

Je hebt hetzelfde apparaat als wij. Overigens, je hebt niet m'n laatste reacties goed gelezen, ik krijg wel degelijk twee NICs aan doorvoer. Anders zou je 255 MB/s niet kunnen verklaren als je 1 Gbps per link hebt.

[sprankel]

Hero of Time schreef op zondag 13 oktober 2019 @ 00:02:
Je hebt hetzelfde apparaat als wij. Overigens, je hebt niet m'n laatste reacties goed gelezen, ik krijg wel degelijk twee NICs aan doorvoer. Anders zou je 255 MB/s niet kunnen verklaren als je 1 Gbps per link hebt.

Als ik het goed begrepen heb krijg je wel je 2 NIC's aan doorvoer maar met 2 ipv 1 VM of ben ik nu zo in de war?

[Hero of Time]

sprankel schreef op zondag 13 oktober 2019 @ 00:05:
[...]

Als ik het goed begrepen heb krijg je wel je 2 NIC's aan doorvoer maar met 2 ipv 1 VM of ben ik nu zo in de war?

Ik was in 't begin in de war. Totdat ik de DM die ik met KRGT heb terug las. Die 255 MB/s is met 1 VM.

[jvanhambelgium]

https://vspherecentral.vm...ation-and-best-practices/

Hier staat het toch gewoon beschreven om tot een werkende oplossing te komen ?
Met 1 VMKernel-portgroup gebruikt je ESX 6 altijd 1 source-IP richting de 2 IP's van de datastores die je ingegeven hebt, maar het is net de NFS.4.1 session trunking die hier de oplossing brengt, Langs de ESX kan dan nog 2 NIC's gewoon in teaming/LB brengen want je moet natuurlijk genoeg fysieke doorvoer hebben.
Optie om in 2 subnetten te werken kan precies ook...

Zelf geen praktische ervaring mee, maar zoals het hier beschreven staat zou je denken...

[Hero of Time]

Dat is dezelfde link die KRGT al plaatste met Vorkie in "Etherchannel/aggregated Ethernet werkt enkel in 1 richting"