qianhangwei@gmail.com wrote:

>> If it's HTTP from a browser, you *need* a web server tier between
>> the switch and WAS. The switch can't do any kind of intelligent
>> load balancing as it doesn't understand the clustering.
>
> The switch do have the load balancing capacity and it also can
> accomplish session affinity. But it does not understand the
> failover(that is,when the owner of the session fails,requests are
> forwarded to other real servers that need to get the knowledge of the
> session from session backup),which websphere cluster does.

That doesn't matter. They don't know which servers are members of which
clusters, so they don't understand which apps are deployed on which
servers if you have multiple clusters, and they certainly don't know how
you've configured session replication. This is why you need real
webservers in your architecture.

>
>> As I've told you before, cluster members do not know about each
>> other.
>
>
> It is http request in browser: http://IP:9080/HitCount.jsp If cluster
> members do not know each other, then I get confused: In a
> memory-to-memory session replication, if deployment manager is
> down,How can the session backup information transfered to other
> cluster members? Is web server necessary? Because,as my understand,in
> memory-to-memory replication, session is backed up on other cluster
> members.

Not necessarily, no. The WAS plugin will automatically fail over
requests for a down server to some other server in the same cluster.
It's up to you to configure session persistence so that the session is
available to any other server in the cluster. You can use peer
clustering or client server clustering, as described here:

http://publib.boulder.ibm.com/infoce...ry2memory.html


> In my case, I think WAS also has web server in it so that I can visit
> it with http requests. But each WAS has a web server in it and they
> are combined without any configuration needed and is different from
> the case you mentioned,where one web server lies between switch and
> WAS. I do create a cluster with each real servers as cluster
> members.Do you think in my case I can get the benefit of session
> persistence?

WAS has a port that understands HTTP, so you can loosely call it a web
server. That's not what I'm talking about. You need a real HTTP server
farm that can use the WAS plugin to do load balancing and failover to
the WAS servers.

> The switch do have the load balancing capacity and it also can accomplish
> session affinity. But it does not understand the failover(that is,when the
> owner of the session fails,requests are forwarded to other real servers
> that need to get the knowledge of the session from session backup),which
> websphere cluster does.

So, if you have a decent HTTP load-balancer, it should have features to
detect errors and fail-over automatically.

It can detect failures by firing an HTTP request every so often (sanity
check).

Or it can watch for the HTTP status code in the reply or a specific keyword
in the answer.

Depends on your L-B.

However, use of such intelligent L-B is not so encouraged because it
competes with the capabilities of the WebSphere web server plug-in, which
already has decent load-balancing and fail-over features bult-in. So, it
overlaps and can sometimes make it conter-productive to use a dedicated L-B.

> qianhangwei@gmail.com wrote:
>
> >> If it's HTTP from a browser, you *need* a web
> server tier between
> >> the switch and WAS. The switch can't do any kind
> of intelligent
> >> load balancing as it doesn't understand the
> clustering.
> >
> > The switch do have the load balancing capacity and
> it also can
> > accomplish session affinity. But it does not
> understand the
> > failover(that is,when the owner of the session
> fails,requests are
> > forwarded to other real servers that need to get
> the knowledge of the
> > session from session backup),which websphere
> cluster does.
>
> That doesn't matter. They don't know which servers
> are members of which
> clusters, so they don't understand which apps are
> deployed on which
> servers if you have multiple clusters, and they
> certainly don't know how
> you've configured session replication. This is why
> you need real
> webservers in your architecture.
>
> >
> >> As I've told you before, cluster members do not
> know about each
> >> other.
> >
> >
> > It is http request in browser:
> http://IP:9080/HitCount.jsp If cluster
> > members do not know each other, then I get
> confused: In a
> > memory-to-memory session replication, if deployment
> manager is
> > down,How can the session backup information
> transfered to other
> > cluster members? Is web server necessary?
> Because,as my understand,in
> > memory-to-memory replication, session is backed up
> on other cluster
> > members.
>
> Not necessarily, no. The WAS plugin will
> automatically fail over
> requests for a down server to some other server in
> the same cluster.
> It's up to you to configure session persistence so
> that the session is
> available to any other server in the cluster. You can
> use peer
> clustering or client server clustering, as described
> here:
>
> http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/
> index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/c
> prs_memory2memory.html
>
>
> > In my case, I think WAS also has web server in it
> so that I can visit
> > it with http requests. But each WAS has a web
> server in it and they
> > are combined without any configuration needed and
> is different from
> > the case you mentioned,where one web server lies
> between switch and
> > WAS. I do create a cluster with each real servers
> as cluster
> > members.Do you think in my case I can get the
> benefit of session
> > persistence?
>
> WAS has a port that understands HTTP, so you can
> loosely call it a web
> server. That's not what I'm talking about. You need a
> real HTTP server
> farm that can use the WAS plugin to do load balancing
> and failover to
> the WAS servers.


Thank you so much Paul, it is more clear to me now.
But still I am not very clear about the process of session backup. Following is my guess:
As you said, cluster members do not know each other. So only web server and plugin know all the cluster members. When web server receives a new requests, it will forward it to a cluster member WAS. For the session backup(I use memory-to-memory replication and only one replica is used), the web server or the plugin will choose another cluster member WAS and copy and update the session state to that cluster member at the same time.
When the owner of the session is down, the web server will forward requests belonging to that session to the a new cluster member. If the new cluster member is the backup cluster member,then it already have the knowledge of the session;
if not, then the new cluster member will ask the web server or the plugin to get the information of the session back up cluster member and finally get the session knowledge from that backup cluster member.

Am I right?

qianhangwei@gmail.com wrote:

>
> Thank you so much Paul, it is more clear to me now. But still I am
> not very clear about the process of session backup. Following is my
> guess: As you said, cluster members do not know each other. So only
> web server and plugin know all the cluster members. When web server
> receives a new requests, it will forward it to a cluster member WAS.

> For the session backup(I use memory-to-memory replication and only
> one replica is used), the web server or the plugin will choose
> another cluster member WAS and copy and update the session state to
> that cluster member at the same time.

No, session replication is not done by the plugin, that is done the data
replication service.

> When the owner of the session
> is down, the web server will forward requests belonging to that
> session to the a new cluster member.

Yes

> If the new cluster member is the
> backup cluster member,then it already have the knowledge of the
> session; if not, then the new cluster member will ask the web server
> or the plugin to get the information of the session back up cluster
> member and finally get the session knowledge from that backup cluster
> member.

No, it will use DRS to get it from the appropriate replica in the
replication domain.

qianhangwei@gmail.com wrote:
> Hi Ben, thank you for your message. The switch can receive http
> requests and load balance between the real servers and can detect the
> failures of the real servers like you said. Also, it can accomplish
> the session affinity, making sure that the requests belonging to a
> session are forwarded to the real server that is the owner of the
> session as long as the owner if alive.
>
> However, it do not know how to deal with the failover. Firstly it do
> not backup session among the real servers. Also when the owner fails
> and the requests belonging to that session are forwarded to a new
> real server, that new real server do not know how to get the
> knowledge of that session.


Then you have not correctly configured a replication domain. Read the
infocenter on this topic.

> I know websphere cluster understands failover. That's why I make a
> cluster with the real servers as the cluster members. Ideally, in my
> environment, I want the switch to deal with the load balance and
> session affinity and use websphere cluster to accomplish the
> failover(session replication and retrieval).
>
> Any ideas?

1. Pay close attention to what you are told
2. Do a lot more reading

Hi Ben, thank you for your message.
The switch can receive http requests and load balance between the real servers and can detect the failures of the real servers like you said. Also, it can accomplish the session affinity, making sure that the requests belonging to a session are forwarded to the real server that is the owner of the session as long as the owner if alive.

However, it do not know how to deal with the failover. Firstly it do not backup session among the real servers. Also when the owner fails and the requests belonging to that session are forwarded to a new real server, that new real server do not know how to get the knowledge of that session.

I know websphere cluster understands failover. That's why I make a cluster with the real servers as the cluster members. Ideally, in my environment, I want the switch to deal with the load balance and session affinity and use websphere cluster to accomplish the failover(session replication and retrieval).

Any ideas?

> qianhangwei@gmail.com wrote:
>
> >
> > Thank you so much Paul, it is more clear to me now.
> But still I am
> > not very clear about the process of session backup.
> Following is my
> > guess: As you said, cluster members do not know
> each other. So only
> > web server and plugin know all the cluster members.
> When web server
> > receives a new requests, it will forward it to a
> cluster member WAS.
>
> > For the session backup(I use memory-to-memory
> replication and only
> > one replica is used), the web server or the plugin
> will choose
> > another cluster member WAS and copy and update the
> session state to
> > that cluster member at the same time.
>
> No, session replication is not done by the plugin,
> that is done the data
> replication service.

S


> > When the owner of the session
> > is down, the web server will forward requests
> belonging to that
> > session to the a new cluster member.
>
> Yes
>
> > If the new cluster member is the
> > backup cluster member,then it already have the
> knowledge of the
> > session; if not, then the new cluster member will
> ask the web server
> > or the plugin to get the information of the session
> back up cluster
> > member and finally get the session knowledge from
> that backup cluster
> > member.
>
> No, it will use DRS to get it from the appropriate
> replica in the
> replication domain.

That makes some sense.
So where does the back up session data lies, in the memory of the web server where the plugin resides in, or in the memory of the cluster member WAS which is chosen as the backup server?
And who decide where to backup the session data, web server,plugin or the owner of the session?
Also How does this new cluster member know where the backup session data lie before it can use DRS to get the backup session data?

Thank you so much

qianhangwei@gmail.com wrote:

>
> That makes some sense. So where does the back up session data lies,
> in the memory of the web server where the plugin resides in, or in
> the memory of the cluster member WAS which is chosen as the backup
> server?

The latter.

> And who decide where to backup the session data, web
> server,plugin or the owner of the session?

You do, when you configure a backup domain. And it has nothing to do
with the plugin. The owner of the session calls DRS to persist the
session based on how you set up session management.

> Also How does this new
> cluster member know where the backup session data lie before it can
> use DRS to get the backup session data?

It doesn't need to know. That's transparent, DRS uses data maintained by
the HA manager. If you use M->M replication, all cluster members must
have HA enabled, and of course must be in the same core group.

The load-balancer does its part of the fail-over when it identifies the
back-end server failed and stops to forward traffic to that server.

WebSphere does its part of the fail-over with the DRS, when it makes session
*data* available to another cluster member.

As prevously indicated if you read more on HAManager, Data Replication
Service, Work Load Management, web
server plug-in, etc in the InfoCenter it should become clearer.

There is also the High-Availability Redbook
(http://www.redbooks.ibm.com/abstracts/sg246688.html).

> The load-balancer does its part of the fail-over when
> it identifies the
> back-end server failed and stops to forward traffic
> to that server.
>
> WebSphere does its part of the fail-over with the
> DRS, when it makes session
> *data* available to another cluster member.
>
> As prevously indicated if you read more on HAManager,
> Data Replication
> Service, Work Load Management, web
> server plug-in, etc in the InfoCenter it should
> become clearer.
>
> There is also the High-Availability Redbook
> (http://www.redbooks.ibm.com/abstracts/sg246688.html).
>


Hi Ben, thank you for the High-Availability Red book you recommended. It is more clear now. And ideally, I think it is feasible to use my hardware switch for the load balance and session affinity and use the DRS in the cluster for the failover.
I have created a cluster with real servers behind the switch as the cluster member and also created a replication domain and configured memory-to-memory replication of each cluster member(all members have the the replication domain and use both client and server) But when I test the failover,it does not work.

what might be the problems? And is it feasible in my environment?

Thanks a lot!

be certain with tcpdump.


On Jul 6, 10:41 pm, wrote:
> Hi all,
> In websphere 6 ND, what is communication mode between the deployment manager and node agent? The deployment manager send message to node agent actively or node agent send message to deployment manager actively?
> Also, there should be time interval for these communication, for example, the deployment manager would send message to to node agent to check if it is still alive every 30 seconds. So how can I adjust this time interval?
> Please provide some documents addressing this issue if possible
>
> Any comments will be appreciated a lot!
>
> Best wishes,
> -Qian

When "it does not work", one can hardly help.

You need to search further and refine the diagnostic.

Simplify your test case if necessary.

Search for troubleshooting guides or instructions on IBM Support Site and in
the InfoCenter.

Don't trust yourself, double-check everything is well configured.