Comments on: NFS and IP-HASH loadbalancing

By: NFS and IP-Hash loadbalancing « My Blog, My Precious.

NFS and IP-Hash loadbalancing « My Blog, My Precious. — Tue, 10 Aug 2010 14:00:29 +0000

[...] Denneman wrote a great article on how VMware IP Hash and Loadbalancing actually [...]

By: Standby NICs in an “IP-Hash” configuration » Yellow Bricks

Standby NICs in an “IP-Hash” configuration » Yellow Bricks — Fri, 06 Aug 2010 13:14:07 +0000

[...] etherchannels a year ago but this is a slight different variant. Frank also wrote a more extensive article on it a while and I just want [...]

By: NFS and IP-HASH loadbalancing « Frank Denneman

NFS and IP-HASH loadbalancing « Frank Denneman — Tue, 09 Mar 2010 09:09:47 +0000

[...] Hi I have moved this blog to the new site frankdenneman.nl. The new home for this article is: http://frankdenneman.nl/2009/11/nfs-and-ip-hash-loadbalancing/. Apologies for the inconvenience! Possibly related posts: (automatically generated)ip [...]

By: Wrap-up 2009 « Frank Denneman

Wrap-up 2009 « Frank Denneman — Wed, 30 Dec 2009 16:26:05 +0000

[...] 1. Increasing the queue depth 2. Lefthand SAN – Lessons learned 3. HP Continuous Access and the use of LUN balancing scripts 4. Impact of memory reservations 5. NFS and IP-HASH Load-Balancing [...]

By: Ernst Lopes Cardozo

Ernst Lopes Cardozo — Fri, 20 Nov 2009 09:46:51 +0000

Complicated solutions to a non-problem?

Long ago, when EtherChannel and LACP were crafted, we had a very different network environment: multiple protocols, ranging from well behaved protocols like IP tot quick and dirty stuf that made all sorts of assumptions about the network. As a consequence, aggregating Ethernet links needed to insure that the sequence of network frames was maintained.

Parallel links can and will change the order of packets when a long packet is send of link A and a subsequent short packet is send of link B. The short packet arrives first and now leads the long packet.

Today, and especially in a dedicated storage network, we exclusively use IP, a protocol that incorporates fragmentation and reassembly at the IP-layer and has no problem dealing with out-of-order packets. iSCSI is wrapped in TCP, which has the same property: segments may arrive out of order without penalty.

The various algorithms used in load balancing exist solely to insure per-stream packet sequence, hence the use of source and destination (either MAC of IP) addresses. I doubt that this is a requirement in TCP/IP storage networks. As a consequence, load balancing parallel links can simply be based on shortest-queue-first, which is always optimal and deals nicely with broken links.

By: John Coke

John Coke — Fri, 13 Nov 2009 20:05:05 +0000

On Cisco switches you can use the "test" command to determine which link a particular src/dst will use. The syntax looks like: test etherchannel load-balance interface port-channel number {ip | l4port | mac} [source_ip_add | source_mac_add | source_l4_port] [dest_ip_add | dest_mac_add | dest_l4_port]

By: Frank Denneman

Frank Denneman — Fri, 13 Nov 2009 19:16:24 +0000

Thanks for the compliment Scott,

And thanks for posting the links, both articles are excellent and are a must-read!

By: Frank Denneman

Frank Denneman — Fri, 13 Nov 2009 19:14:09 +0000

Hi Craig,

I haven’t had the chance to read the NetApp documentation, could you post a link to the document?

By: craig

craig — Fri, 13 Nov 2009 17:28:48 +0000

You can also refer to the best practices guide release by Netapp for VMware deployment with NFS protocol.

By: Scott Lowe

Scott Lowe — Fri, 13 Nov 2009 16:49:59 +0000

How funny! I was preparing to write a piece on how VMware used the load balancing algorithms in the vSwitch to pick an uplink, but it looks like you’ve beat me to the punch! Good article, and helps reinforce the information I presented in some of my articles on using multiple NICs with IP-based storage:

http://blog.scottlowe.org/2008/10/08/more-on-vmware-esx-nic-utilization/
http://blog.scottlowe.org/2008/07/16/understanding-nic-utilization-in-vmware-esx/

Keep up the good work, Frank!