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.
Regards,
Rainer
Thanks
Dmitry
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
