HPE StoreVirtual Storage / LeftHand
cancel
Showing results for 
Search instead for 
Did you mean: 

Weird behaviour regarding to cluster VIP

RemyZ
Advisor

Weird behaviour regarding to cluster VIP

I am doing some tests to figure out how ALB-bonds work in respect to IP-numbers and MAC-addresses. I wrote a little script on a Linux host which pings the VIP of a small Lefthand cluster and then finds the MAC-address corresponding to the VIP IP-number. The cluster consist of 6 nodes: node_01 through node_06.

The CMC shows node_01 as holder of the VIP. So I would expect that after I ping the VIP, the MAC address of node_01 will show up in the ARP table. And that indeed is true.

The weird thing is though, that in a number of occasions, the ARP table shows the VIP address in combination with the MAC address of node_06. The CMC still shows node_01 as the VIP holder.

This puzzles me. Is this expected behaviour?

-Remy

 

--------------------------------------
Remy Zandwijk
VU University Amsterdam
2 REPLIES
Fred Blum
Regular Advisor

Re: Weird behaviour regarding to cluster VIP

Hi Remy,

 

Is this not logical? I would expect it with VIP as it does load balancing and the NIC/MAC responding is not necessarly the VIP holder.  Or they should have programmed the SAN to distinguish ping traffic from ordinary "load" traffic and always respond with the VIP holder for some reason and I do not know if that is the case.

 

Fred

RemyZ
Advisor

Re: Weird behaviour regarding to cluster VIP

Hi Fred,

 

no, I don't think this is logical. I investigated this issue a bit more.

 

For every node in the cluster, I took a look at the hist.config log file. A node has multiple interfaces: eth0, eth1 and bond0 (in case you use a bond like ALB). The node which holds the VIP has another interface, bond0:254, which is an alias interface of bond0.

 

It turned out that I had TWO nodes in the cluster with an bond0:254 interface (at the same time), which where up and running with the VIP address. No matter what, an IP-address should only appear once in a network. Apperantly, I had two...

 

I found the VIP to be active on node_01 and node_06. Since the CMC reported node_01 to be the VIP holder, I decided to reboot node_06. Much to my surprise node_04 became the VIP holder during/after the reboot. Both node_01 and node_06 didn't have the bond0:254 interface anymore. Conclusion: the CMC falsely reported node_01 to be the VIP holder, it was node_06 and node_01 was the one messing things up, although we did not experience any issues like performance degration.

 

To be sure, I checked all other clusters (10) to see if there was a cluster with more than 1 node having the bond0:254 interface and I could not find one. So my conclusion is that what I saw was not ordinairy. I probably should open a case with HP.

 

-Remy

 

--------------------------------------
Remy Zandwijk
VU University Amsterdam