Forum Discussion

Gauthier_Delac1's avatar
Gauthier_Delac1
Icon for Nimbostratus rankNimbostratus
Apr 06, 2009

Selective universal persistence

Hello,

I have an irule that selects a pool depending on the URI (actually, a pool contains cache servers and the second one contains web servers).

I need universal persistence based on JSESSIONID only for requests going to the web pool (Because I want to keep a good balance between cache servers)

So I've included these lines in my irule :

 
 when HTTP_REQUEST { 
  
   [...Pool selection...] 
  
   pool $Current_Pool 
  
   if { $Current_Pool equals $Pool_NoCache } { 
     if { [HTTP::cookie exists "JSESSIONID"] } { 
       persist uie [HTTP::cookie "JSESSIONID"] 60 
     } 
   } 
 } 
  
 when HTTP_RESPONSE { 
   if { $Current_Pool equals $Pool_NoCache } { 
     if { [HTTP::cookie exists "JSESSIONID"] } { 
       persist add uie [HTTP::cookie "JSESSIONID"] 60 
     } 
   } 
 } 
 

The [...Pool selection...] just contains stuff like

"if { [HTTP::uri] starts_with "/foobar" } { set Current_Pool $Pool_Cache }"

Persistence entries are fixed to 60 seconds for testing.

My problem is that this irule creates multiple persistence entries (for the same JSESSIONID, same VS and same pool) and, sometimes, going to different pool members ! (this is the real problem)

In consequence, a big majority of the requests comes from the same server, but some of them comes from the other one (the web pool contains 2 web servers)).

Here is a screenshot of my persistance table :

http://img7.imageshack.us/img7/5989/persist.jpg

And here is some log I've collected, showing IP::server_addr and HTTP::path

...: XXX.XXX.151.201 <= /VAD/HTML/Ressources/fr_FR/css/Header.jsp

...: XXX.XXX.151.202 <= /VAD/OubliMdp

...: XXX.XXX.151.201 <= /VAD/HTML/00-Header/minishopcart_nb_produit_panier.jsp

...: XXX.XXX.151.201 <= /VAD/HTML/00-Header/login.jsp

...: XXX.XXX.151.202 <= /VAD/ArticlesDejaVus

...: XXX.XXX.151.202 <= /VAD/HTML/00-MiniShopCart/MiniSC.jsp

...: XXX.XXX.151.201 <= /VAD/MiniShopCart

I think it's necessary to specify that my VS has a 255.255.255.255 oneconnect profile and this irule is affected to VS through universal persistence profile (I need Override Connection Limit feature).

The website contains some AJAX : this explains the presence of multiple JSP requests at the same time.

Does anyone see what's wrong into this ? I've searched a long time in the forum before posting but I haven't seen someone having the same problem...

Thanks a lot !

3 Replies

  • I think I have found the origin of my problem.

     

     

    Just look at the full version of my logs:

     

     

    tmm tmm[27593]: Rule OKAIDI-Cache_and_Persist : 193.238.151.201 <= /rc/CHANGELOG

     

    tmm3 tmm3[27643]: Rule OKAIDI-Cache_and_Persist : 193.238.151.201 <= /email/CHANGELOG

     

    tmm2 tmm2[27751]: Rule OKAIDI-Cache_and_Persist : 193.238.151.201 <= /mail2/CHANGELOG

     

    tmm2 tmm2[27751]: Rule OKAIDI-Cache_and_Persist : 193.238.151.202 <= /Webmail/CHANGELOG

     

    tmm tmm[27593]: Rule OKAIDI-Cache_and_Persist : 193.238.151.201 <= /components/com_roundcube/CHANGELOG

     

    tmm2 tmm2[27751]: Rule OKAIDI-Cache_and_Persist : 193.238.151.201 <= /squirrelmail/CHANGELOG

     

    tmm tmm[27593]: Rule OKAIDI-Cache_and_Persist : 193.238.151.202 <= /vhcs2/tools/webmail/CHANGELOG

     

    tmm tmm[27593]: Rule OKAIDI-Cache_and_Persist : 193.238.151.201 <= /round/CHANGELOG

     

    tmm2 tmm2[27751]: Rule OKAIDI-Cache_and_Persist : 193.238.151.202 <= /VAD/HTML/Ressources/fr_FR/css/Header.jsp

     

    tmm2 tmm2[27751]: Rule OKAIDI-Cache_and_Persist : 193.238.151.202 <= /VAD/OubliMdp

     

    tmm2 tmm2[27751]: Rule OKAIDI-Cache_and_Persist : 193.238.151.202 <= /VAD/HTML/00-Header/minishopcart_nb_produit_panier.jsp

     

    tmm2 tmm2[27751]: Rule OKAIDI-Cache_and_Persist : 193.238.151.202 <= /VAD/ArticlesDejaVus

     

    tmm2 tmm2[27751]: Rule OKAIDI-Cache_and_Persist : 193.238.151.202 <= /VAD/HTML/00-MiniShopCart/MiniSC.jsp

     

    tmm tmm[27593]: Rule OKAIDI-Cache_and_Persist : 193.238.151.202 <= /VAD/HTML/00-Header/login.jsp

     

    tmm tmm[27593]: Rule OKAIDI-Cache_and_Persist : 193.238.151.202 <= /VAD/MiniShopCart

     

     

    You can see each time the source address changes, the tmm thread changes too !

     

     

    I'm using a Big-IP 8800, with 4 TMM threads, and I think the persistence table is not shared between threads ! (That's why I have 4 persistance entries as you can see in my screenshot in my first post).

     

     

    Does anyone have the same problem ?

     

     

    How can I fix that ?

     

     

    I'll probably call support about that but they generally don't like troubleshooting irules issues....

     

     

    Thanks !

     

  • There was a similar thread about this same issue recently but I'm having trouble finding it. In any case, you can try disabling CMP for that virtual server and see if that helps.

     
     bigpipe virtual x.x.x.x cmp disable 
     

    Denny
  • I've just found a topic explaining this solution : http://devcentral.f5.com/Default.aspx?tabid=53&view=topic&postid=32006

    I have tried but it didn't change anything : requests were still handled by different tmm.

    The user in this topic solved the problem by rebooting the bigip... :o( my bigip is in production so I don't want to reboot it for testing...

    So I have found another solution (yes, my problem is solved !!) :

     
      bigpipe virtual [virtual server name] cmp disable   
      bigpipe save  
     

    => At this step, it didn't work. So, I removed my VS definition from bigip.conf and then :

      
      bigpipe verify load (mandatory !!!)  
      bigpipe load 
     

    => And then reinserted the definition into bigip.conf (check that "cmp disable" line is present in VS definition) and again :

     
      bigpipe verify load  
      bigpipe load 
     

    => Now all requests for that VS are handled by unique TMM thread and I have only one persistence entry per client !

    I presume that changing the name of the VS into bigip.conf should be enough to make this VS considered as "new" by the bigip...and then really disable CMP but I haven't tested yet.

    Just one last interesting thin I have seen here : https://support.f5.com/kb/en-us/solutions/public/7000/700/sol7751.html :

    "The BIG-IP VIPRION introduced CMP Persistence in version 9.6. CMP Persistence adds support for session persistence mirroring when TMM is running in CMP mode"

    => Knowing that new v10 is unified for bigip and viprion....does v10 bigips support CMP Persistence ??? (which should be better than limiting VIP to only one tmm...)

    Thanks !