tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <rainer.j...@kippdata.de>
Subject Re: clustering iis with JK
Date Wed, 28 Nov 2007 16:41:46 GMT
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 <rainer.jung@kippdata.de> 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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message