Forum Discussion
Brian_11882
Nimbostratus
NimbostratusLB 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
- The_BhattmanHi 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_11882Yes, 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.
