Configuring stickyness when using multiple pools with one virtual server

Hi Nirmal,

I think you are on the right track based on your explanation and that you for including your iRule - it does help us understand your thoughts and approaches.

Here is an iRule I quickly worked up based on your description.

I am assuming that the token information is provided to the client once the initial connection has been made by the defaultpool.

 
  when HTTP_REQUEST {  
  if { [HTTP::header exists "token"] } {  
  set key [HTTP::header "token"]   
  switch $key {  
  101 { pool pool1_1}  
  102 { pool pool1_2}  
  103 { pool pool1_3}   
  201 { pool pool2_1}  
  202 { pool pool2_2}  
  203 { pool pool2_3}  
  301 { pool pool3_1}  
  302 { pool pool3_2}  
  303 { pool pool3_3}  
  }  
    
  } else {  
  pool defaultpool  
  }  
  }  
    
  when LB_FAILED {  
  if {[HTTP::header exists "token"]} {  
  set key [HTTP::header "token"]  
  switch $key {  
  101 -  
  102 -  
  103 {  
          if {[active_members pool1] > 0 }{  
  LB::reselect pool pool1  
  }  
  201 -  
  202 -  
  203 {  
  if {[active_members pool2] > 0 }{  
  LB::reselect pool pool2  
  }  
  301 -  
  302 -  
  303 {  
  if {[active_members pool3] > 0 }{  
  LB::reselect pool pool3  
  }  
                          default {  
                                 LB::reselect pool defaultpool  
                              }  
  }  
  } else {  
       LB::reselect pool defaultpool  
      }  
  }  
   

This assumes:

- you have 9 pools each contains single node

- you have 3 pools contain a group of 3 nodes in each

- You have 1 pool containing all 9 nodes.

How the iRule works (at least based on my understand of your requirements):

The initial request will not contain any of header "token". It will be forwarded to the defaultpool (Containing 1 of the 9 nodes). Once selected, the client's header "token" will be created/updated by the selected node. Subsequent requests will then be forwarded to poolx_x which contains the node where it was given the token. If that node fails, it will then go to 1 of 3 pools that contains the similar token in the header. Once a new node is selected and client's header token will be updated so that the subsequent requests again go to the same node. if the entire pool down then it will go to the defaultpool where the entire process will restart again. If the client request loses it's token in the process of a node failure it will be sent to Defaultpool to restart the process.

Note: This has not be tested so I can guarantee what the results will exactly be - so expect adjustments made.

I hope this helps

Bhattman