Forum Discussion

adharkrader's avatar
adharkrader
Icon for Nimbostratus rankNimbostratus
Jul 17, 2009

One VS, 2 pools, separate persistence?

Our primary web site is serving different content from two server farms... like www.foo.com/abc and www.foo.com/xyz. But there's SSO, forms, etc that require that you stay stuck to one server in each pool... so I don't want to re-roll the dice every time you jump between abc & xyz.

 

 

What's the best approach? It seems like cookie insert is adequate -- I'll have one cookie for each pool and both will be offered by the browser since it's a single web site. Is it that simple? I feel like there's got to be some wrinkle waiting to bite me...

 

 

Thanks - Al
application delivery
dev
devops
iRules

4 Replies

Sort By
  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Jul 17, 2009
    Hi Al,

    If you use cookie insert persistence, you would want to specify the cookie name each time you select a pool. The cookie persistence will be specific to the pool used. Here is an untested example:

    The persist wiki page has details on the perist command (Click here). 

     
 when HTTP_REQUEST { 
  
    log local0. "[IP::client_addr][TCP::client_port]: New HTTP request to [HTTP::host][HTTP::uri]" 
     Select pool and persistence based on URI 
    switch -glob [HTTP::uri] { 
        app1 
       "/abc*" { 
           Select abc pool and abc session cookie persistence 
          pool abc_pool 
  persist cookie insert abc_cookie 0 
          log local0. "[IP::client_addr][TCP::client_port]: abc request" 
       } 
        app2 
       "/xyz*" { 
           Select abc pool and abc session cookie persistence 
          pool xyz_pool 
  persist cookie insert xyz_cookie 0 
          log local0. "[IP::client_addr][TCP::client_port]: abc request" 
       } 
        default case 
       default { 
           take some default action? 
          log local0. "[IP::client_addr][TCP::client_port]: no match for [HTTP::host][HTTP::uri]" 
       } 
    } 
 }

    Aaron
  • spark_86682's avatar
    spark_86682
    Historic F5 Account
    Jul 17, 2009
    A cookie insert profile will give out cookies per-pool if you use the default cookie name, so you shouldn't need an iRule in this case. Since both pools are on the same hostname, the clients should send both cookies to the BIG-IP. I don't see any reason why it wouldn't Just Work. This all assumes independent server selection for the two pools is OK (i.e. clients can have a different server for /abc than they do for /xyz).
  • adharkrader's avatar
    adharkrader
    Icon for Nimbostratus rankNimbostratus
    Jul 20, 2009
    So, an iRule on event HTTP::request to send them to the correct pool but the cookie insert in the persistence profile will keep them straight within each pool, correct?

     

     

    I have this feeling that I'm missing something... it's just too simple.
  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Jul 21, 2009
    It is that simple. LTM will check the persistence profile after HTTP_REQUEST is triggered and then look for the persistence cookie for the currently selected pool. The client may have a persistence cookie from both pools, but only the one for the selected pool will be used for that request.

     

     

    Aaron