Why do SSL connections to IE browsers periodically timeoutYou have an application deployed on two webserver boxes. Clients access this application over SSL. Once a client has started using this web application, it needs to ensure that client's requests get sent to the exactly the same machine for the lifetime of the user's session. You have enabled 'SSL stickiness' in the Zeus Load Balancer, which configures the load balancer to use the SSL session information to pin an individual user to a particular back end machine. This solves the traffic routing issue for requests issued within a short duration, however stickyness may be lost due to IE renegotiating the SSL connection after certain periods of time. This problem is documented in a number of places. NetworkComputing, a well regarded periodical, has an article describing the SSL handshake: http://www.networkcomputing.com/1212/1212f415.html, and they describe the problem: With Microsoft Internet Explorer (IE) 5.0 and later, SSL sessions are set to time out every two minutes, requiring renegotiation of the session -- and a new SSL handshake. SSL handshaking is incredibly expensive in terms of resources for the Web server, and the renegotiation caused by IE 5.x adds unprecedented burdens to SSL-enabled Web servers. SSL accelerators can alleviate much of this burden, but users of IE 5.x need to be aware of this and should visit Microsoft's Web site: http://support.microsoft.com/support/kb/articles/Q265/3/69.ASP to find out how to fix this problem. Cisco document exactly the same problem for their load balancing products: http://www.cisco.com/warp/public/117/local_director/locdirfaq.pdf (see the question "What is the workaround for the problem with SSL sticky and Internet Explorer 5.0?)". Finally Microsoft admit to the presence of the problem, documenting it http://support.microsoft.com/default.aspx?scid=KB;en-us;q265369 Reason?Your configuration may look similar to this:
As can be seen by the diagram, in the current configuration, the traffic flowing through the load balancer is encrypted, with the web servers doing the SSL decryption. Because the information is encrypted, the load balancer cannot 'look into' the HTTP request, but passes onto the encrypted traffic to the back-end web servers. However, each SSL encrypted request is prefixed with a 'SSL session id', which is negotiated between the client and server upon their first session, and is reused for subsequent requests, and is unique to the individual. Zeus Load Balancer, in similarity with other load-balancing devices, can be configured to use this unique SSL session id information to 'pin' requests from an individual to a particular back-end machine. This SSL session id is reused in subsequent requests to prevent a full RSA key exchange on every request (which is very CPU intensive and slow). As IE sometime prematurely exipires SSL connections, for longer term persistence, SSL session ids cannot be used. SolutionsThere are three possible methods to approach the problem 1) Perform session persistance based on the source IP address, rather than the SSL session. This is the most popular solution proposed by other load balancer vendors. Put the following in your global.cfg:
... and restart the load balancer after modifying global.cfg. This will ensure, as far as possible, that the Load Balancer will sendrequests from the same source IP address to the same back-end machine, ifthe balancer sees a new SSL session id. 2) Modify your application so that login state is shared between each backend machine, so that if a user is transferred to a different back-end, it can recognise his login and not ask him to reauthenticate himself. Depending on the nature of your application, this may be trivial, or very complex. 3) A third solution is to use HTTP Cookies. Cookies are information that can be sent back form the web server to an individual alongside the normal web response. This cookie information is then sent by the client to the server in all subsequent requests. The cookie can also be configured to be persistent, so if a client restarts their web browser, or reboots their machine, they will resend the same cookie information to the server upon their subsequent requests. The cookie should not however be persistant for login information. By returning a unique cookie to a web request, individuals can be identified and mapped onto a particular back-end machine for the lifetime of the cookie. Zeus Load Balancer has unique functionality, called Session Affinity (see section 6.2.1 of the Zeus Load Balancer User Guide), which can be configured to inject these cookies into the request/response stream, and use their cookies to direct the back-end server selection to allow pinning of users. If a backend application already sets a cookie, ZLB can cache and balance on that. Other means of session persistance are available whereby if a backend application sets a cookie, Zeus Load Balancer can cache and balance upon it. It is important to note however that these caches are not shared accross front-end Zeus Load Balancer pairs. However, in order to setup these configurations, the Zeus Load Balancer needs to be able to read, and manipulate the request response stream. In the current configuration this is not possible, because the traffic is encrypted right up to the IIS servers, preventing the Load Balancer from deploying session affinity. Thus, a proposed solution is to move the SSL decryption layer in front of the web server, so that the Zeus Load Balancer can manipulate the HTTP stream and perform session affinity before sending the request onto the back-end IIS servers. The Zeus Web Server product can be configured to do this HTTPS<->HTTP gateway, by using its 'Gateway functionality' that comes as part of the standard product. (See the Zeus Web Server User Guide, section 8.3) A sample network diagram would then look like:
Here, the webserver boxes are configured to accept HTTP responses. SSL is now the responsibility of the Zeus machine infront of the load balancer Implementation detailsIt is possible to install the Zeus Webserver on the same box as the load Balancer. It will however be neccessary to install a separate Zeus Administration Server to control the new ZWS rather than by using the existing Admin Server on the load balancer. This is because the default behaviour of a shared Admin Server is to configure the Load Balancer to divert traffic to the webserver. The order of operations would look something like this:
|
Recently...
Other Resources
|
