JSESSIONID Cookie failover

Have you had a look at this? http://devcentral.f5.com/Wiki/default.aspx/iRules/Weblogic_JSessionID_Persistence.html

 

 

-Matt

Matt,

 

 

I have an I-rule that I wrote to successfully persist on JSESSIONID. The issue I am having is that we mirror our weblogic sessions to a fallback server. In order to use this fallback feature while loadbalancing your bea servers with F5 is being able to write an i-rule to grab the JSESSIONID and split it into 3 values cookie, Primary Server, Secondary Server. The catch is that the Primary and Secondary Server Ip, Port is hashed. I'm not real sure that there is a way to decode this hash. So my next thought was to figure out what hash value goes with what IP and hardcode those ip's in the i-rule. The only problem with this is that the hash values change every time you restart the server so that is not a good solution.

 

 

My question is has anyone seen this, or have been down this road successfully or unsuccesfully.

 

 

Thanks,

 

 

 

Brett

Hi Brett,

 

 

Can you post a few examples of the cookie values and which primary and secondary server IP's/ports they correspond to?

 

 

You could potentially try to use a similar method as this example--just change the parsing of the value from the URI to the cookie and replace some of the regexp commands with string functions:

 

 

http://devcentral.f5.com/Default.aspx?tabid=53&forumid=5&tpage=1&view=topic&postid=18948

 

 

Thanks,

 

Aaron

Unfortunately I cannot provide that information being that I work on a restricted site. I have looked at the i-rule you are referencing and it would work if only I can decode the hash to Ip Addresses.

 

 

-Brett

Hi Brett,

 

 

If the ID's are true one way hashes, it actually wouldn't actually help to see examples.

 

 

I wonder if the server which sets the cookie always lists itself as the first node in the jsessionid cookie value? If so, you could keep a mapping of the current hashes and work out which server IP:port a secondary hash corresponds to once that server had set a cookie.

 

 

 

Load Balancers and the WebLogic Session Cookie

 

http://download.oracle.com/docs/cd/E11035_01/wls100/cluster/load_balancing.htmlwp1028843

 

 

The format of a session cookie is:

 

 

sessionid!primary_server_id!secondary_server_id

 

 

where:

 

 

* sessionid is a randomly generated identifier of the HTTP session. The length of the value is configured by the IDLength parameter in the element in the weblogic.xml file for an application. By default, the sessionid length is 52 bytes.

 

* primary_server_id and secondary_server_id are 10 character identifiers of the primary and secondary hosts for the session.

 

 

Note: For sessions using non-replicated memory, cookie, JDBC, or file-based session persistence, the secondary_server_id is not present. For sessions that use in-memory replication, if the secondary session does not exist, the secondary_server_id is “NONE”.

 

 

 

 

If that seems plausible, let me know and I'll try to come up with a rough version for you to try testing. Also, can you confirm which LTM version you're running?

 

 

Thanks,

 

Aaron

Aaron,

 

 

I like where you going with this. You are correct the server that sets the cookie is always the primary server. I am only concerned about one issue of your purposed solution and maybe that it's not an issue at all and I just am not fully understanding what you mean by mapping. I am assuming that you are meaning hard code the ip:port to a corresponding hash value in the i-rule. If this is the case for some reason if you reboot, restart or shutdown the bea services this hash value changes. Now why I'm not exactly sure, I would think that the hash would be the same as long as the value it's hashing does not change, but this is not the case.

 

 

If you could show me a rough draft that would be excellent.

 

 

Thank you for you support.

 

 

-Brett

Hi Brett,

 

 

Can you confirm which LTM version you're using? The options for session table entries vary between 9.x and 10.x.

 

 

Thanks,

 

Aaron

Aaron,

 

 

We are currently running 10.0.1 Build 354.0 HF2. But I am testing 10.1 currently and I'm hoping if all goes well to move to it soon.

 

 

Thanks again.

 

 

-Brett

Could you wait for 10.1 to implement the iRule using the table command (Click here)? In the meantime, you could use cookie insert persistence as a simple way to handle persistence to the primary node (which wouldn't support failover to the secondary pool member)?

 

 

If not, I can try a version using the session command in 10.x.

 

 

Aaron

Aaron,

 

 

10.1 will be fine, I'm running it on my NOE and plan to move it soon to the OE.

 

 

-Brett