Forum Discussion
ChrisJackel_103
Nimbostratus
NimbostratusPersistence 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.
ChrisJackel_103At 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
}
}
hoolioCirrostratus
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_103Thanks 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. - hoolioWhen 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 - hoolioAfter 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