ONTAP Discussions

Why has LIF rebalancing been deprecated!?

schmitz_peter
2,868 Views

Hi all,

 

we are currently discussing how to balance heavy NFS v3 loads on our 4-node cluster.

 

It seems to boil down to using off-box DNS balancing to distribute the NFS-traffic to the least used node, but only works works for new connections.

 

What I found really interesting is the now deprecated feature of LIF rebalancing.

 

Can anyone tell me why it has been deprecated as per ONTAP 9.3 release:

 

"The automatic LIF rebalancing feature, which allowed LIFs to automatically migrate to a less-used port based on the load balancing weights assigned to the LIFs, is deprecated from ONTAP 9."

 

 

 

The only downside I can see in LIF rebalancing is the fact that LIFs might not be home anymore which could be confusing.

 

What am I missing here?

 

Thanks for any insight.

 

Peter

1 ACCEPTED SOLUTION

AlexDawson
2,777 Views

The LIF rebalancing feature is indeed deprecated. It was only used by a very (very) small number of customers, and it only worked for NFSv3 - not CIFS, not NFSv4 - It was disabled if any of those protocols were enabled on a LIF.

 

Any traffic to a LIF on a different node to the aggregate hosting the volume would result in indirect access, and thus cluster interconnect traffic, and thus, in the end, CPU and disk load on the source node anyway, so it didn't give much of a benefit. 

 

Depending on your data layout and use-case, using flexgroup scale-out volumes across multiple nodes may be a better solution, along with LACP for interface distribution on those nodes

View solution in original post

2 REPLIES 2

AlexDawson
2,778 Views

The LIF rebalancing feature is indeed deprecated. It was only used by a very (very) small number of customers, and it only worked for NFSv3 - not CIFS, not NFSv4 - It was disabled if any of those protocols were enabled on a LIF.

 

Any traffic to a LIF on a different node to the aggregate hosting the volume would result in indirect access, and thus cluster interconnect traffic, and thus, in the end, CPU and disk load on the source node anyway, so it didn't give much of a benefit. 

 

Depending on your data layout and use-case, using flexgroup scale-out volumes across multiple nodes may be a better solution, along with LACP for interface distribution on those nodes

schmitz_peter
2,748 Views

Hi Alex,

 

thanks for the -- very plausible -- explanation.

 

I will have a good look at flexgroups, then.

 

Cheers

 

Peter

Public