https redirection when node fails

Are you referring the BIG-IP as a "node", or servers in a pool.

 

 

If the latter, since you're terminating the SSL at the front door, you'd need to establish some form of (layer 7?) session persistence mechanism if one node had to take over for another. SSL wouldn't be a factor since the client isn't establishing an SSL session directly to the server.

 

 

If the former, there is no way (currently) to share the SSL session state (session key, private data) between BIG-IP peers. If a BIG-IP failed over, you could maintain server node persistence, and even application session state, but the user would have to start a new SSL session with the now active BIG-IP.

 

Hi Kevin , i am specifically referencing a pool member failure , can you kindly point me in the right direction on how to establish session persistence ? is this something that that the BIG-IP can do , or does this need to occur between the pool members directly ?

This depends entirely on the application. Take for example an application that requires authentication and then sets a session cookie that maps to some memory-resident data on the server for that user. Every subsequent request sends the cookie, which maps to the session data, which lets the server know who the user is from one request to another. If the node fails over, there must be a mechanism in place for both nodes to "share" that (application) session data. For many platforms that's a central server or database that stores the session data instead of in resident memory. That's also something you wouldn't want to do with the BIG-IP (you could, but you generally wouldn't want to). So then it depends on the general complexity of the application and how it interacts with the user. If the application is simpler than the one described above, then other options may exist. If something like Access Policy Manager (APM) is handling the authentication, then that information would/could be persisted across nodes.

Thanks Kevin , the inner workings of the application is not on my agenda ( yet) but at present i believe its just https ( Apache ) with a MySQL back-end , is it generally best practice for the https sessions to be persistent or for the user to just log in again as server failure should obviously not occur frequently

This is still a "depends", and depends on the session layer you're talking about. There are layer 3/4 sessions (IP/TCP). There are layer 6 sessions (SSL) that you generally cannot persist, and then layer 7 sessions (application) that are completely independent of the lower layers. You can persist a layer 7 session in the ways I described earlier. Layer 6 isn't possible because there are end-to-end encryption keys involved that would have to be shared with another device/node. The good news is that IP/TCP/SSL sessions usually don't matter. Assuming you're re-encrypting to the server, and the node fails, the BIG-IP will silently re-establish a new SSL session to the next node. How that node reacts to the request is dependent on the application.

 

Allow me to rephrase. In a proxy environment you can assume that client and server will both establish layer 4 connections with the proxy (not each other). There are mechanisms to persist layer 4 connections on the client side should the BIG-IP fail over to its peer, but generally an application server couldn't or wouldn't do this, so a node failover will always initiate a new layer 4 connection between the proxy and the new node.

 

 

If you do not terminate the SSL (tunnel the SSL) between the client and server, then a node failure will generally cause the client to initiate a new SSL session with the new node. If you do terminate (and re-encrypt) the SSL and a node fails, the BIG-IP will silently establish a new SSL session to the next node without seriously impacting the client side connect/session.

 

 

Your original request, if I understood it, was to allow the next node to "pick up where the previous node left off" in the event of a failure. TCP isn't really an issue on the server side of the proxy, and unless you're doing something with SSL (tunneling and passing client certificates), then that's not really relevant either. What you have left is application layer behavior. In other words, if the application sets some form of "state" with the client, it's imperative that you understand how that works to know if it's possible to replicate that state on another server. It may be something as simple as a cookie that carries all of the state information (rare), or something as complex as SharePoint for example, that mixes cookies, state tables, and view state form fields.

 

may be this is codable using the feature called : Action on Service Down

 

If this setting is enabled and the target pool member goes down, the BIG-IP system tries to choose another pool member and rebind the client connection to a new server connection. Possible values are None, Reject, Drop, and Reselect.

 

http://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm_configuration_guide_10_0_0/ltm_pools.html1215248

 

 

may be this is doable using the feature called : Action on Service Down

 

If this setting is enabled and the target pool member goes down, the BIG-IP system tries to choose another pool member and rebind the client connection to a new server connection. Possible values are None, Reject, Drop, and Reselect.

 

http://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm_configuration_guide_10_0_0/ltm_pools.html1215248