Forum Discussion

ChrisJackel_103's avatar
ChrisJackel_103
Icon for Nimbostratus rankNimbostratus
Nov 30, 2007

Persistence problem with multiple pools under one VIP

We have one VIP with two separate applications under it, with traffic segregated with an iRule like the following:

 

 

when HTTP_REQUEST {

 

if {[matchclass [string tolower [HTTP::uri]] starts_with $::myURL] } {

 

pool app1_http

 

} else {

 

pool app2_http

 

}

 

}

 

 

App1 is a set of Apache servers with no state information. App2 is dotNET and maintains state with the ASP state service, so persistence is less of an issue.

 

 

The persistence profile on the VIP is cookie insert.

 

 

Previously, there was very little crossover between the two applications. However, they do occasionally call objects from each other and when they do the BigIP cookie is overwritten. This is expected, the session information is a connection between the client and a node, and I can't see an easy way to maintain a session to two different nodes under the same VIP.

 

 

My understanding is that the 'match across virtual servers' and 'match across pools' wouldn't really apply in this case, since it is the same VIP throughout.

 

 

However, this is causing problems for app1, where it loses state as soon as it calls an image (or anything) that resides on a path under app2. They next time a request is made for app1 it establishes a new session and bad things happen.

 

 

It would take months of dev work to get the two applications into separate namespace and different VIPs. Any suggestions how I can maintain persistence within the same VIP to two applications at once?

 

 

We are running 9.3.1. Thanks in advance.

 

application delivery
dev
devops
iRules

5 Replies

Sort By
  • ChrisJackel_103's avatar
    ChrisJackel_103
    Icon for Nimbostratus rankNimbostratus
    Nov 30, 2007
    At what point is persistence evaluated? Would this work?

     

     

     

    when HTTP_REQUEST {

     

    if {[matchclass [string tolower [HTTP::uri]] starts_with $::myURL] } {

     

    pool app1_http

     

    persist Profile1

     

    } else {

     

    pool app2_http

     

    persist Profile2

     

    }

     

    }
  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Nov 30, 2007
    Using two different persistence profile instances should work well.

     

     

    If you're using cookie persistence, make sure to either not set the cookie name in either profile (the default cookie name includes the pool name used), or set it to something different in both.

     

     

    Aaron
  • ChrisJackel_103's avatar
    ChrisJackel_103
    Icon for Nimbostratus rankNimbostratus
    Nov 30, 2007
    Thanks for the response.

     

     

    Something unexpected happens why trying to specify the profile.

     

     

    The wiki suggests this is a valid option for persist:

     

     

    persist

     

     

    But when I try it I get an error if I don't explicitly specify 'persist cookie insert cookie_a2'. If I try to reference the profile name I get the error below.

     

     

    when HTTP_REQUEST {

     

    if {[matchclass [string tolower [HTTP::uri]] starts_with $::myURL] } {

     

    pool app2

     

    persist cookie_a2

     

    } else {

     

    pool app1

     

    persist cookie insert cookie_a1

     

    }

     

    }

     

     

    01070151:3: Rule [myrule_persist_test] error:

     

    line 4: [invalid option "cookie_a2" must be: cookie none source_addr simple dest_addr sticky msrdp ssl uie universal hash add lookup delete] [cookie_a2]

     

     

    So the first clause fails, but the other clauses work. cookie_a2 is a valid persistence profile. That error message doesn't seem to indicate that is an option.
  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Dec 03, 2007
    When using a custom persistence profile, I've had to specify the persistence type and the name, as you did with cookie_a1. I think you can leave off the name if you want to use the default profile for that type of persistence.

     

     

    Aaron
  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Jan 16, 2008
    After testing this again for another customer, I realized that when specifying a "name" for the command 'persist cookie insert ', name isn't the name of the cookie persistence profile you want to use--it's the name of the cookie you want to insert. When I tested this originally, I was using same name for the cookie persist profile and the cookie name in that profile, so I got confused.

     

     

    This makes sense when you consider that the only options you can specify in the cookie insert persistence profile are a name and expiration... You aren't actually specifying a new profile to add to the VIP, you're just modifying the existing profile already attached to the VIP.

     

     

    Aaron