Cookie balancing between services

If there's no application logic to handle that then I'm not sure LTM is going to be able to do anything for you there. Can you define a little more what you mean by the Pool 2 session needing to access the Pool 1 session? Are you wanting the server in Pool 2 to initiate a connection to another load-balanced virtual server on the LTM and have it maintain session state? Universal persistence via an iRule may be able to help that connection be sent to the same server as the user's Pool 1 session by doing some sort of cookie comparison, but if the app doesn't already know how to handle that connection then I'm not sure what that's going to do for you.

 

 

I guess what I'm trying to figure out is how does this session access function if there is only 1 server in each "Pool" and LTM is not involved (ie no server load balancing).

 

 

Denny

"the server in Pool 2 to initiate a connection to another load-balanced virtual server on the LTM and have it maintain session state?"

 

 

Indeed. The application that lives on Pool2:AllNodes knows that it will want to connect to Pool1, and it will need to connect to the Node:Session that the user has previously initiated.

 

 

My understanding is that once the user connects to Pool1, the returned header will include a cookie from the LB, detailing the pool:node combo, and when the user submits that cookie back to the LB, the user will then be directed to the same node of the pool, but the cookie will not leave the LB (the application on Node1 never sees the cookie).

 

 

I guess what I'm trying to figure out is how does this session access function if there is only 1 server in each "Pool" and LTM is not involved (ie no server load balancing).

 

 

 

Nodes A & B are both members of Pool1, Nodes Y & Z are both members of Pool2, so both pools are load balanced. I apologize if the diagram didn't make that clear.

Posted By miketheman on 08/19/2008 8:00 AM

 

 

 

My understanding is that once the user connects to Pool1, the returned header will include a cookie from the LB, detailing the pool:node combo, and when the user submits that cookie back to the LB, the user will then be directed to the same node of the pool, but the cookie will not leave the LB (the application on Node1 never sees the cookie).

 

 

 

That's basically correct (it's a hash of the IP:port combo along with virtual server info), although the cookie is actually passed on to the server as well (it most likely just ignores it).

 

 

 

I guess what I'm trying to figure out is how does this session access function if there is only 1 server in each "Pool" and LTM is not involved (ie no server load balancing).

 

 

 

Nodes A & B are both members of Pool1, Nodes Y & Z are both members of Pool2, so both pools are load balanced. I apologize if the diagram didn't make that clear.

 

 

 

No I understood that, the diagram is fine, I'm just asking how would the application maintain the user session if you only had Node A and Node Y, and Node Y initiated a connection to Node A directly? That is the behavior you're going to have to get LTM to emulate via some iRule logic, I believe. Without knowing the underlying behavior I'm not sure how to go about building that logic though.

 

 

Denny