tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject Re: clustering iis with JK
Date Wed, 28 Nov 2007 11:02:24 GMT
Dmitry Beransky wrote:
> Hi,
> Is it possible to implement the following setup with JK/isapi_redirect?
>   1. Two clustered IIS instances
>   2. Two load-balanced Tomcat instances
>   3. Each IIS uses JK to forward requests to two load-balanced Tomcat instances
> I know how to do each individual item in isolation, but I can't
> figure, once I put all three together, how to ensure that requests
> belonging to the same session are consistently served to the
> appropriate Tomcat instance.  Any pointers?
> For IIS clustering I am considering NLB.  Since want IIS clustering
> for mostly for reliability rather than scalability, an easy way out
> would be to do a fail over setup, but this is plan B.

To isolate the layers:

- Load-balancing the web servers (IIS)
- Maybe stickyness already in the web layer, mainly in case you use SSL
- Load-balancing between IIS layer and the Tomcat layer using the isapi 
redirector, including stickyness
- Maybe session replication between the Tomcat instances to further 
increase transparency of nore failures

Simple setup would be:

- No session replication between Tomcat nodes (no Tomcat-Cluster).
   In case a node fails, the users with sessions on the nodes have to 
login again. OK, if sessions are cheap, i.e. not much work lost, not 
much information in the session, and failure rate is low (application, 
hardware, network relatively stable).
- Combined with sticky forwarding by the isapi redirector (uses URL 
encoded sessions or standard Java session cookie JSESSIONID combined 
with the jvmRoute setting in server.xml of the Tomcat backends; TC adds 
the jvmRoute to the session id, and isapi redirector sees this tag in 
the URL or cookie and maps it to the correct backend). Works very robust.
- Load-Balancing or high availability in the IIS layer would still be 
your job. Stickyness demand on the IIS layer itself depends on the fact, 
if the IIS layer is stateless (should be, apart from the SSL case, were 
you want to have a relatively good stickyness; don't need 100%, but the 
less sticky the LB to the IIS is, the more SSL handshakes you get).

More complex setup:

- Add session replication to the TC backends. Most likely nevertheles 
you want to keep stickyness with the isapi redirector, to reduce 
dependency on the rpelication during the time you actually didn't have a 
node failure.



> Thanks
> Dmitry

To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message