Forum Discussion
sathish_126179
Nimbostratus
NimbostratusPool member reselection - not working
Hi,
We are using BIG IP LTM 11.3.0. We have a requirement that in case a pool member fails immediately after a health checkup and LB doesn't know the until the next checkup. During this interval the connections that gets hit to the failed pool member should get routed to the next available pool member.
I tried the below iRule as mentioned in the article: http://support.f5.com/kb/en-us/solutions/public/10000/600/sol10640.html, but no luck. when LB_FAILED { if { [active_members [LB::server pool]] > 0 } { catch { LB::down } LB::mode rr LB::reselect } }
I even created an "inband" monitor (with default values) and associated with the pool (in addition to the https monitor). Apart from this, the "Reselect tries" option was set to "3" at the pool. Inspite of configuring these settings, the website doesn't loads from new member when LB contacts the failed pool member. Am I missing anything? Can someone help on this?
Thanks Sathish
Cory_50405Noctilucent
Can you please post your pool config? Sanitize if needed.
sathish_126179Thanks Cory for your reply. Here is the pool config. Both https & inband pool are using the default values.
ltm pool /Common/testpool { load-balancing-mode least-connections-member members { /Common/192.168.1.2:443 { address 192.168.1.2 } /Common/192.168.1.3:443 { address 192.168.1.3 } } monitor /Common/inband_test and /Common/https reselect-tries 3 service-down-action reselect }
- Cory_50405
Is your LTM properly directing traffic to another pool member if it detects that the current one isn't responsive? Wondering if this is not an issue with your LTM doing what it's supposed to do, but rather that the backend servers are not recognizing an existing connection from another server.
- sathish_126179
Yes, LTM is redirecting the traffic if a pool member isn't responsive. Also, We had enabled the "Action on Service Down" to "Reselect" for redirecting the request to the next available pool member.
- Cory_50405
So when you say that the website doesn't load when the connection is sent to another pool member, could that be because the other pool member has no state for the client connection and won't continue the connection? It's possible that the LTM is doing what it's supposed to do, but the backend server you're sending the communications to after the selected pool member fails isn't picking up the connection as you expect.
Grabbing packet captures on your LTM or on the backend servers would be a good way to identify if this is the case.
dragonflymrCirrostratus
Hi, What do you mean here "failed pool member" - if you mean member not replying to http traffic then I am pretty sure both Reselect Tries and Inband monitor will not be a solution. I mean situation when only http service is down but node is not. Inband is working only for L4 so it's monitoring problems with connection at the TCP level not application level, the same is true for Reselect Tries. Of course if http is not respoding at all it will work, but if it's responding even with wrong content or error code both inband and Reselect Tries will not be triggered (as well as iRule). So your http monitor can mark member down because it is not returning correct response as defined in Receive String, but member is still replying to http requests in some way. That is first think to verify when node monitor is green but member monitor is red. Piotr