Forum Discussion

Jamie_Cravens's avatar
Jamie_Cravens
Icon for Nimbostratus rankNimbostratus
Feb 28, 2007

point to different Pools w/ different persistence

I have the following iRule configured, but each pool needs to use a different Persistence Profile. How can I accomplish this?

 

 

when HTTP_REQUEST {

 

if {[HTTP::uri] starts_with "/member"}

 

{ pool POOL_A }

 

else { pool POOL_B }

 

}

 

 

Thank you!
application delivery
dev
devops
iRules
  • JRahm's avatar
    JRahm
    Icon for Admin rankAdmin
    Mar 01, 2007
    
when HTTP_REQUEST {
  if { [HTTP::uri] starts_with "/member" } {
    pool POOL_A
    persist xxx
 } else { 
    pool POOL_B
    persist yyy
    }
}
  • Greg_Burch's avatar
    Greg_Burch
    Icon for Nimbostratus rankNimbostratus
    Mar 05, 2007
    I'm attempting to do the same thing, but it doesn't seem to be working reliably at all. The following iRule is specified within a persistence profile that is assigned as the Default Persistence Profile of a virtual server (logging statements were added for debugging purposes):

     

     

    when HTTP_REQUEST {

     

    if {[string tolower [HTTP::uri]] contains "tcgiservlet" } {

     

    persist source_addr 255.255.255.255 120

     

    log local0. " [IP::client_addr] - [HTTP::uri] - SOURCE persistence selected "

     

    } else {

     

    persist none

     

    log local0. " [IP::client_addr] - [HTTP::uri] - NO persistence selected"

     

    }

     

    }

     

     

    when LB_SELECTED {

     

    log local0. " [IP::client_addr] - [HTTP::uri] - to node [LB::server]"

     

    }

     

     

    ______________________________________

     

    A sample of the logging that is produced is as follows:

     

     

    Feb 22 14:07:38 tmm tmm[1036]: Rule XXXXXXXX_PERSIST : y.y.y.y - /live/servlet/GetLeastLoadedComponent?xxxxxx - NO persistence selected

     

    Feb 22 14:07:38 tmm tmm[1036]: Rule XXXXXXXX_PERSIST : y.y.y.y - /live/servlet/GetLeastLoadedComponent?xxxxxx - to node POOLNAME-80 z.z.z.z 80

     

    Feb 22 14:07:38 tmm tmm[1036]: Rule XXXXXXXX_PERSIST : y.y.y.y - /live/servlet/tcgiServlet - SOURCE persistence selected

     

    Feb 22 14:07:38 tmm tmm[1036]: Rule XXXXXXXX_PERSIST : y.y.y.y - /live/servlet/tcgiServlet - SOURCE persistence selected

     

    Feb 22 14:07:39 tmm tmm[1036]: Rule XXXXXXXX_PERSIST : y.y.y.y - /live/servlet/tcgiServlet - SOURCE persistence selected

     

    Feb 22 14:07:39 tmm tmm[1036]: Rule XXXXXXXX_PERSIST : y.y.y.y - /live/servlet/tcgiServlet - to node POOLNAME-80 167.z.z.z 80

     

     

    The problem is that the persistence doesn't seem to be taking effect immediately, as there will be several requests to one back-end node, and then all subsequent requests will go to the other back-end node. One thing I especially don't understand is the LB_SELECTED event only seems to trigger sporadically, and there doesn't seem to be any rhyme or reason to it. It doesn't occur for every request, but it occurs much more often than 120 seconds, which is the timeout value of the persistence.

     

     

    Has anyone seen behavior like this or shed any light on what might be happening?

     

  • unRuleY_95363's avatar
    unRuleY_95363
    Historic F5 Account
    Mar 05, 2007
    That's classic non-OneConnect behavior. The LB_SELECTED event is only fired when a load-balancing decision is made. And of course, persistence only plays a factor when the load-balancing decision is made.

     

     

    As a side effect of OneConnect, load-balancing will occur on every request. However, without OneConnect, load-balancing only occurs when the pool changes. Any subsequent requests that happen to go to the same pool will stay connected to the last pool member.

     

     

    So, you have two ways you can change this behavior: 1) Add OneConnect; 2) at the beginning of HTTP_REQUEST call LB::detach.

     

     

    HTH