#vSphere Networking performance

1 messages · Page 1 of 1 (latest)

cinder yoke
#

Hi all, hope everyone is doing well today.

Currently building out a new NFS AFF-A150 for a vSphere datastore and trying to wrap my head around my options as far as the networking, would appreciate any input. Previously my predecessor had configured two NFS data LIFS, one for each of the two nodes each going over a 2-port ifgrp to our data switch, however the datastore was only mounting to one IP as that's how datastores had worked. With the recent release of nConnect (I think it's pretty new?), this would allow me to create multiple TCP connections over the same physical connection increasing throughput. This all got me to thinking, what would be the best way to check/benchmark if I even need more throughput/performance? Additionally, our switch guy suggested turning those 2-port ifgroups into singular 10gb connections unless we needed the extra throughput, and I'm honestly unsure how to tell if we do or don't.

As far as I can tell we don't have any issues with our ESXi hosts accessing data at current speeds but trying to determine if knocking that ifgrp down to a singular 10gb connection would be okay or not. I'm not sure if "run -node ifstat" is the best source of answering this question, or if this would be something I should look into on the switch or ESXi client side?

vast star
#

Honestly LACP adds redundancy but you do have LIF failover in the ONTAP side. An A150 isn't going to have much horsepower to really take advantage of more than 10 GbE as it's an entry-level system.

#

I can't really see how this would help, and given it's a new technology from VMware I'd be more inclined to wait a little while to let it stabilize.

half sinew
#

I always use LACP for VMware whenever I can for customers. It is generally simple enough to do, provide automatic link failover and distribution. nconnect can help especially if you have a large enough number of VMs that cause the ONTAP "inflight" warnings in the event log.

cinder yoke
#

hmm, is the redundancy factor of LACP ifgrps really necessary if we have LIF failover on the ONTAP side? trying to honestly see a reason why we would need the extra throughput of the ifgrp too - if the AFF-A150 isn't even really strong enough to make use of that extra GB/S

half sinew
#

"and distribution"

#

agreed, that the link failover can be accomplished without ifgrp, but setting distribution method to port usually yields very good distribution across multiple links

cinder yoke
#

that makes sense. I always figured IP based made the most sense - now seeing that best practice recommendation is port based on the ifgrp page 😲

#

well, i suppose no sense in trying to reinvent the wheel. I will tell our switch admin that we're keeping those interfaces for performance reasons

half sinew
#

the switch side should also have its distribution set to src-dst-port also!

on a nexus, that would be:
port-channel load-balance src-dst l4port

cinder yoke
#

we use nexus switches so you just made my day

austere osprey
#

Hello everyone,
we also use a setup with LACP on VMware and NetApp side.
Can you tell me which loadbalacing mechanism is recommended on the VMware side? Currently we always use "Route based on IP hash"
On the NetApp side we currently use loadbalacing mechanism "ip"

Thanks and best regards
Dennis

half sinew
#

I cannot remember the last time I did any LACP on the VMware side. Since you are building the virtual switches (standard switch doesn’t support LACP or distributed which do) you can assign multiple nics to the switch. VMware does a rather nice job of distributing between the links and if a link fails it redirects traffic.

I’ve really seen no need to do it at esxi side.

tough flicker