Forum Discussion
Maria_Ramirez_5
Nimbostratus
Nimbostratusweblogic persistenca does not works
Good morning,
I have a problem with iRules.
I have a pool with two weblogic servers. I want to maintain persistence based on cookies.
I create a virtual server for the pool of the two weblogic servers and I associate the iRules to the virtual server. But the persistence does not work. The traffic is always loadbalanced between the two nodes. Please can you help me? The iRules are:
* Servidor Web
when HTTP_REQUEST {
if { [HTTP::cookie exists WEBSRV] } {
persist uie [HTTP::cookie WEBSRV];
}
}
when HTTP_RESPONSE {
if { not [HTTP::cookie exists WEBSRV ] } {
set ip_srv [IP::server_addr];
set valor [ string range $ip_srv [ expr [string last . $ip_srv ] + 1] 15];
set val_cookie "WEBSRV=$valor; path=/"
HTTP::header insert Set-Cookie $val_cookie;
persist add uie $valor;
}
}
* Weblogic
when HTTP_REQUEST {
if { [HTTP::cookie exists WLSRV] } {
persist uie [HTTP::cookie WLSRV];
}
}
when HTTP_RESPONSE {
if { not [HTTP::cookie exists WLSRV ] } {
set ip_srv [IP::server_addr];
set valor [ string range $ip_srv [ expr [string last . $ip_srv ] + 1] 15];
set val_cookie "WLSRV=$valor; path=/"
HTTP::header insert Set-Cookie $val_cookie;
persist add uie $valor;
}
}
Thanks and regards
Charles_HarrisAre your WLS nodes clustered?
Wes_98712If you want to persist based on a specific cookie that has been programmed into the application, I would suggest you get the name and the length and simply use a cookie hash profile, this is the most efficient that I have found rather than trying to control it via an iRule.
If you are dealing with a weblogic cluster, or any other J2EE/JEE cluster you have to be careful with persistence, if the application is stateless than you shouldn't need persistence, if it is a stateful application, then persistence is pretty much implied, as such you need to start looking at either the embedded application cookie which probably contains the users session information, or in the case of Weblogic and most other J2EE/JEE containers/servlet engines, look at the JSESSIONID, and hash that.
I went through this a few times and found that simply using the cookie has profile with LTM is far more efficient than trying to set a bunch of irule logic to handle the cookie.
The other thing you are doing is trying to create your cookie on the fly, to correspond to the IP address and seemingly the root of URI path, if I am reading that right. The real question it seems is what are you trying to accomplish and if it is simply persisting to the same server with a cookie, then either hash the jsessionID or the internal cookie from the application, or use active cookie insert and set it to the timeout of the application.
iRules are very powerful, but they can be your worst enemy if you don't do them right, in this case it looks like you are trying to accomplish something that a persistence profile will handle a whole lot easier, and it's less administrative overhead.
-Wes
Maria_Ramirez_5Hello Wes
Thanks for the answer. SO, you recommend me to use the COOKIE HASH PROFILE. I will try it and let´s see what are the results.
I have never configured this type of persistence. I have read that when you use it, you have to map a defined cookie value to a node. When the client returns to the site, the LTM uses the information of the cookie to give client the correct node. It is mandatory that the server generates a cookie. I will verify that the server generates the cookies correctly.
I have two questions:
1. What information should I specify in order to insert it into the cookie of the server?
2. In case that we are using WEBLOGIC CLUSTER, we have to hash the JSESSIONID, how could I do it...?
Thanks in advance,
María- Maria_Ramirez_5Hi again,
We are not using CLUSTERING in the weblogic servers. I mean: the WEBLOGIC SERVERS are working as independent sservers (not clusteres). So, any idea about how to create the hash cookies persistence?
Thanks in advance.
Regards
María - Wes_98712Sorry this is so late, must have missed the alert, hopefully you found it, if not you simply need to create a cookie profile using a hash, for the cookie name use JSESSIONID. The cluster does not determine whether or not you use a JSESSIONID, most containers use them, unless turned off, which no one should do unless they are storing the session information in a different cookie.
Create the cookie hash profile, specify the JSESSIONID as the cookie name, if there is a specific length that the cookie has you can specify that in the length value, I usually just leave them offset and length set to the defaults, works better that way, so if the cookie entropy ever changes you don't have to change the profile.
Apply the new persistence profile to your VIP, if you want a timeout value for the cookie, make sure you set that in the profile as well.
The F5 will look in the header for the JSESSIONID as a cookie, if it is not there it will send the request to the server, inspect the server header response, find the JSESSIONID cookie, and hash it and store the value in a persistence table which it will lookup to see which cookie came from which server, very cool stuff.
If the header has the cookie it will look in the persistence table for it, if it's not there, it's probably a stale session, so it will send it to the next server in the LB pool and if the ID changes, hash that in the persistence table, if it stays the same, it...guess? Yes of course, hashes that as well. ;-)
Let me know how it went/goes.