Forum Discussion
SivaYenduri
Cirrus
CirrusPriority Group Activation Failback with HTTP Cookie Insert
Hello All,
Can someone help me the below issue?
We have a pool with 3 members. 2 members have high priority (Round Robin) and 1 member has low priority.
When both the primary members go down, the low priority member should take over the traffic.
We have Cookie Insert persistence enabled on the virtual server. In Cookie persistence, "Expiration: Session Cookie" enabled.
When both the primary members were made down, the low priority member took over the traffic.
When both the primary members came back UP, the traffic continued to go to low priority backend member.
When the browser tab is closed and tried to access the URL in new tab, the traffic went to low priority backend member.
When the browser window is closed and tried to access the URL in new tab, the traffic still went to low priority backend member.
When the browser cookies were deleted and tried to access the URL in new tab, the traffic was taken over by the high priority members.
This behavior is not desired and we need to force the LB to use high priority backend members as soon as they come UP.
When user tries the connection from new browser or new tab, the traffic should go to high priority pool members.
Please let me know how i can achieve the desired behavior.
Regards
Simon_BlakelyEmployee
The overriding principle of persistence is that once a client has established a session to a pool member, it should stay there until the session expires. This is to prevent unexpected session failure due to changing pool member servers.
If a client has a session to the low priority server when the high priority servers are back up, the cookie persistence will keep returning the client to the low priority server until the cookie expires, so that the user sessions do not break.
If this behaviour is not desired, you will need to write an irule that looks at the load-balancing decision and the available members in the pool to determine whether the low priority pool member has been selected, whether any high priority pool members are available, and make a new load-balancing decision based on that information.
SivaYenduriI have written the below iRule. Could you please validate?
when LB_SELECTED {
if { [IP::addr [LB::server addr] equals "low-priority-ip"] } {
if {[LB::status pool pool_name member 1.1.1.1 8080 ] or [LB::status pool pool_name member 1.1.1.2 8080 ] equals "up"} {
LB::reselect
}
}
}
1.1.1.1 and 1.1.1.2 are the High priority IPs of the same pool "pool_name"
- Simon_Blakely
That looks OK from a logical perspective.
Rather than checking if the High Priority pool members are available individually, I would just check to see if the number of available pool members is greater than 1, and reselect in that case.
when LB_SELECTED { if { ([IP::addr [LB::server addr] equals "low-priority-ip"]) and ([active_members pool_name] > 1) } { LB::reselect } }Give that a test.
igorzhukAltostratus
But LB_Selected - its only ones in connections, how the event trigger in same connections?