WebSphere Application Server - Seamless failover and WebSphere App Server 5

This is Interesting: Free IT Magazines  
Home > Archive > WebSphere Application Server > October 2004 > Seamless failover and WebSphere App Server 5





You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

Author Seamless failover and WebSphere App Server 5
Brent Friedman

2004-10-07, 5:49 pm

I am trying to set up a test environment to test seamless failover for a
Java application. I have looked over everything on WebSphere
clustering that I can find, but I still have a few questions.

Hopefully, someone here is a clustering/failover guru, and can answer
these questions in their sleep. ;)

1. I have looked at the HTTP plug-in, Network Dispatcher, and some
other methods of clustering WAS. It *seems* that the HTTP plug-in
provides session failover, but the user would have to re-authenticate to
get back to their session. Is this true?

2. Would Network Dispatcher provide seamless failover? (Specifically,
user A logs into an intranet site. They are authenticated, and routed
to WAS node 1. In the process of going through screens of the web app,
WAS node 1 loses connectivity. Will Network Dispatcher sense that Node
1 is down, and automatically re-route the user to node 2? Or, does the
user have to click back button in browser, reload page, and/or
re-authenticate?)

3. Would a Tivoli Webseal junction assist with re-authentication in
case of failure of a particular WAS instance?

4. What is the "typical" WebSphere component mix to enable seamless
failover?

Any suggestions, comments, etc., would be greatly appreciated!

Thanks,

Brent Friedman

Paul Ilechko

2004-10-07, 5:49 pm

Brent Friedman wrote:
> I am trying to set up a test environment to test seamless failover for a
> Java application. I have looked over everything on WebSphere
> clustering that I can find, but I still have a few questions.
>
> Hopefully, someone here is a clustering/failover guru, and can answer
> these questions in their sleep. ;)
>
> 1. I have looked at the HTTP plug-in, Network Dispatcher, and some
> other methods of clustering WAS. It *seems* that the HTTP plug-in
> provides session failover, but the user would have to re-authenticate to
> get back to their session. Is this true?


Not at all, no. If you wish to continue using the same session on a new
application server in a failover situation you would need to configure
some form of session persistence (either to a database or using the
publish/subscribe model). There would be no re-authentication required.

>
> 2. Would Network Dispatcher provide seamless failover? (Specifically,
> user A logs into an intranet site. They are authenticated, and routed
> to WAS node 1. In the process of going through screens of the web app,
> WAS node 1 loses connectivity. Will Network Dispatcher sense that Node
> 1 is down, and automatically re-route the user to node 2? Or, does the
> user have to click back button in browser, reload page, and/or
> re-authenticate?)


Don't use Network Dispatcher for this, the HTTP plug-in is the correct
solution. Use Network Dispatcher to spread load across your HTTP servers.

>
> 3. Would a Tivoli Webseal junction assist with re-authentication in
> case of failure of a particular WAS instance?


Not required

>
> 4. What is the "typical" WebSphere component mix to enable seamless
> failover?


Some form of IP sprayer such as Network Dispatcher, obviously with a hot
standby. This sprays to at least two HTTP servers. These send work using
the HTTP plugin to at least two appserver nodes. Recommend that you use
session affinity. You may also wish to use session persistence depending
on the need to recover in-flight sessions during failover.

Also think about dMgr failover - this is a potential single point of
failover, you need some solution for this.

paul_gover@uk.ibm.com

2004-10-09, 2:47 am

Further to point 1. A Network Deployment configuration uses LTPA, an
identity cookie which provides single-sign on, and therefore allows your
authentication to fail-over. It's independent of session handling, so you
could in fact get the opposite position, where there's no need to
reauthenticate, but you lose your sessions because you chose not to make
them persistent.
Sponsored Links






Free braindumps | Software forum | Database administration forum

Copyright 2003 - 2008 webservertalk.com