We're using a hardware load balancer in front of our Resin servers. To
try and find a way to uniquely identify each browser in an SSL and NAT
world, we're utilizing the session ID on the SSL handshake.
Since NAT routers will consolidate IP addys, and cookies may be hidden
behind the SSL encryption, the SSL Session ID is in the clear and
appears in the headers before the SSL encrypted package.
Now, I'm not sure of Resin has an easy way to get at this value, but it
can serve to identify unique SSL visitors.
Mitch Wallace wrote:
> Our current environment has multiple physical servers behind a load
> balancer. Each server is running resin 3.1.1 where a java servlet
> handles requests. We have tested two different load balancer
> configurations with session stickiness, but encountered the following
> Config 1 - IP hash, session stickiness
> This ends up routing a huge portion of the traffic to a single server
> due to NAT'ed IP addresses. Not going to work long term as we will
> eventually hit server capacity.
> Configuration 2 - Round Robin, session stickiness
> Initially, this appeared to work. However, after some more detailed
> testing, we found that certain parts of the session were floating across
> servers. More detailed investigation showed that even though requests
> were being sent from the same browser window, they were actually viewed
> as separate sessions on the server side. As an example, an initial page
> the server to return detail records or to call a search function. These
> requests include a "close connection".
> Since our application caches user/profile info in memory (no user data
> is stored on the server), we require server affinity by user session.
> Once a user logs in, we would like all requests to go to a single server
> in the pool until that person logs out or the session times out. Upon
> next login, it should load balance to whatever server is next in the
> load balanced pool. One option considered is to use an SSL load
> balancer with SSL acceleration that we can configure in cookie insert
> mode. However, my concern is that because the additional posts include
> a close connection, we may end up with the same problem encountered in
> Configuration 2 above.
> Questions -
> - Can anyone suggest a way to configure resin to handle this type of
> load balancing? Remember, the key is to load balance by user session.
> - Does anyone have a similar configuration and if so, how did you solve
> the problem?
> - This may be a stupid question, but more for short term testing, is it
> possible to configure a web tier and app tier using the same servers?
> For example, server A, server B, and server C. A and B are clustered as
> a web tier, balancing traffic to A,B, and C as the app tier.
> Any suggestions are welcome and thanks in advance for any help.
> resin-interest mailing list
resin-interest mailing list