Forum Discussion

Brian_11882's avatar
Brian_11882
Icon for Nimbostratus rankNimbostratus
Mar 17, 2011

LB on hash key with onloading and offloading

Hi,

 

 

I'm a complete newbie for F5, so I hope my question makes sense. We would like to load balance on a pre-hashed cookie value. The value is hashed using a proprietary (i.e. Oracle) hashing algorithm. We can store the hashed value as a cookie, and we'd like to select a server from that cookie value without further hashing.

 

 

Furthermore, we'd like to be able to implement multiple states for a member for gracefully rolling down and up servers during application redeployment. The four states we would like to specify for a server are:

 

 

Up: The server receives all requests designated to it by the pre-hashed cookie value.

 

Down: The server does not receive any requests

 

Starting: The server only receives connections from new http sessions (i.e. no JSESSIONID) designated to it by the pre-hashed cookie value, and subsequent connections from the same session.

 

Stopping: The server only receives connections from existing sessions that were previously designated to the member.

 

 

Do I need to use iRules to implement this type of strategy? Any tips on what it would look like?

 

 

Brian

 

 

application delivery
dev
devops
iRules
  • The_Bhattman's avatar
    The_Bhattman
    Icon for Nimbostratus rankNimbostratus
    Mar 18, 2011
    Hi Brian,

     

    Can you describe in this forum the logic of what you want the LTM to accomplish.

     

     

    For example:

     

    1. Client goes to VIP

     

    2. VIP selects server based on default load balancing configuration and forwards the request to server

     

    3. Server then responds and assigns a pre-hashed cookie value

     

    4. Client receives the cookie and responds back with the same cookie value

     

    5. F5 then checks the pre-hashed cookie value and then based on the value sends the information to a specific server?

     

    etc.

     

     

    The short answer is that it is possible for the iRule to read cookie values, store in a variable where it can be evaluated to process it into the states you defined. However, not exactly sure how the last 2 states (starting/Stopping) can be accomplished without learning the logic of what you want the flow to look like

     

     

    Bhattman

     

     

  • Brian_11882's avatar
    Brian_11882
    Icon for Nimbostratus rankNimbostratus
    Mar 18, 2011
    Yes, that's the basic flow. LB:status has states "session_enabled" and "session_disabled", but I don't see how these are used in the default LB algorithms. They may simplify what I need. I'll use my starting/stopping states to show the behavior I'm looking for even though they don't seem to exists. I'm assuming that a node can respond with a state for LB:status to indicate its ability to accept connections. 

     
when HTTP_REQUEST {
if([HTTP:cookie exists oraclePartition]) {
 Map node id to IP and port found in a class
 Entries should be strings of the form
   
                set node_data [findclass [HTTP:cookie oraclePartition] $::my_nodes " "]
set node_ip [getfield $node_data " " 1]
set node_port [getfield $node_data " " 2]
if([LB:status pool my_pool member $node_id $node_port up]) {
pool my_pool member $node_ip $node_port
} else if([HTTP:cookie exists JSESSIONID] and [LB:status pool my_pool member $node_id $node_port stopping]) {
// continue on the designated node
pool my_pool member $node_ip $node_port
} else if([HTTP:cookie not exists JSESSIONID] and [LB:status pool my_pool member $node_id $node_port starting]) {
// Allow on the starting node
pool my_pool member $node_ip $node_port
}

}
}

    I'd like the starting state to mean "only accept new sessions" and the stopping state to mean "continue with existing sessions, but do not accept connection from new sessions" as in the example above. In the example, I assume that when a connection is assigned to a member, by default it will stick for the remainder of the session unless the node is not up.