Dmitry Beransky wrote:
Hi Rainer,
It's the item #3 on your Simple Setup list that I'm basically asking
about (I already have #1 set up and working, and parts of #2).
Here's where my problem with #3 lies:
Let's say we have two load-balanced (clustered) web/IIS servers: W1
and W2, each configured with sticky forwarding by isapi_redirectors
JK1 & JK2 to Tomcat servers T1 & T2.
Let's follow this scenario
1. Request (R1) comes to the web cluster (C) and gets dispatched to
W1. R1 is a new request, so it's gets arbitrarily sent to T2, where
it's assigned a new session (S1)
2. Request R2 from session S1 comes to C. Let's say it gets
dispatched to W1 again (C wouldn't know anything about S1). Since JK1
knows about S1, R2(S1) will be forwarded to T2, which started S1 ---
everything is fine.
3. Request R3 from session S1 comes to C. And since C doesn't know
anything about S1, R3(S1) is load-balanced to W2. JK2 at this point
doesn't know anything about S1. To it, it's a new session, so it may
forward it either to T1 or T2. If R3(S1) gets sent to T2, we are
good. If not - our app is in trouble.
The stickyness feature of the isapi redirector is stateless, i.e. it has
no idea, which sessions are on node T1 or T2. The nodes T1 and T2
themselves add their names (jvmRoute) to the sesiond ID, and the session
ID from there on is part of any further request, because it either is
included by URL rewriting (this has to be done by the webapp developer)
or by the session cookie (automatically resend by the browser, assuming
it supports cookies).
So with every request belonging to S1 the browser will send a session
id, and at the end of the session id the isapi redirector sees the name
of the correct tomcat node and sends the request there. Even if it never
saw any request for the same session before.
Does that answer your question?
I'm new to all this, so I might be missing something basic. I do
realize that Tomcat session replication (your more complex setup)
makes this problem moot. But, let's say, I do not take the session
relication route, can I still make sure that #3 from above does not
happen?
Thanks
Dmitry
Regards,
Rainer
On Nov 28, 2007 3:02 AM, Rainer Jung <[EMAIL PROTECTED]> wrote:
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
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
