Forum Discussion

cryosleep_29698's avatar
cryosleep_29698
Icon for Nimbostratus rankNimbostratus
Nov 04, 2016

Reset session on my Virtual Server when a specific pool member with high priority come UP

I need an iRule or a configuration to apply on my VR/Pool. I've a pool [mypool] with 2 pool members serverA and serverB all attach on a Virtual Server VR1. I've configure the Priority Group since that i want that all connection are redirect just to the pool member ServerA: * ServerA Priority Group 10 * ServerB Priority Group 1 * Priority Group Activation: Less Than 1 Available Member(s) Just when ServerA is down or marked down by your monitor the connection switch with the LB policy to the pool member ServerB. The question is that, when the member pool ServerA return back UP, i need that the all connections attached before to the pool member ServerB are disconnected or reset. How i perform this kind of action?

 

5 Replies

  • What service type are you providing (HTTP, other) and what monitor are you using?

     

    I ask you because depending on your response, I'll suggest a reverse monitor to test serverB. Regards.

     

  • Hi cjunior,

     

    i use for both pool member a standard icmp monitor (default for all node) and for mypool a "TCP-Half open" port monitor dedicated to the daemon port to monitor. The service is not http,but is an application that establish a connection via TCP socket.

     

    Thanks

     

  • Within pool, if you set "Reset" as an option for "Action on Service Down", does it help ?

     

  • Hi Cryosleep,

     

    the easiest way would be a setup using...

     

    1. Enable Priority Group Activation prefering ServerA
    2. Attaching a OneConnect Profile to your Virtual Server to enable LTM to rebalance existing TCP-Connections on a per HTTP-Request basis (requires HTTP Profile)
    3. Remove any Persistence Profile from your Virtual Server.

    By doing so, any existing connection to ServerA will failover to ServerB in the case ServerA is unhealthy. And any existing connection to ServerB will failback to to ServerA in the case ServerA is become healthy again.

     

    No iRule or scripting required... ;-)

     

    Cheers, Kai

     

  • Hi Cryosleep,

    you may try one of the iRules below, to rebalance active sessions for ServerB if ServerA comes back online...

    iRule 1: Using a per TCP-Packet

    CLIENT_DATA
    event for active connections to ServerB to lookup the availability of ServerA and then failover

    when RULE_INIT {
        set static::IP_ServerA "10.10.10.1%1"
        set static::IP_ServerB "10.10.10.2%1"
    }
    when SERVER_CONNECTED {
        if { [LB::server addr] equals $static::IP_ServerB } then {
            clientside {
                TCP::collect
            }
        }   
    }
    when CLIENT_DATA {
        if { [active_members -list [LB::server pool]] contains $static::IP_ServerA } then {
            LB::detach
            LB::reselect
            TCP::release
            return
        }
        TCP::release
        TCP::collect
    }
    

    iRule 2: Using a periodic TCL script on every active connections to ServerB to lookup the availability of ServerA and then failover.

    when RULE_INIT {
        set static::IP_ServerA "217.110.108.152%1"
        set static::IP_ServerB "217.110.108.152%1"
        set static::reject_interval 5000 ; msec
    }
    when SERVER_CONNECTED {
        if { [LB::server addr] equals $static::IP_ServerB } then {
            after $static::reject_interval { 
                if { [active_members -list [LB::server pool]] contains $static::IP_ServerA } then {
                    after cancel -current
                    LB::detach
                    LB::reselect
                }
            }
        }
    }
    

    Note: iRule 1 should be considered as very agressive for your CPU, since the status of ServerA is checked on each single TCP-Packet send from the client to ServerB (allows very fast failbacks). iRule 2 uses a once every X msec interval to check the status of ServerA for server side connection send to ServerB (less CPU hungry approach).

    Note2: Both iRule are designed to keep the client side TCP-Connection active by transparently reselecting the server side side connection from ServerB to ServerA. If this is a problem for your application, then report back and I'll rewrite the iRule, to reject the client side connection.

    Cheers, Kai