|
Home > Archive > WebSphere Edge Server > January 2004 > How to set an affinity with URI based Content rules ?
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 |
How to set an affinity with URI based Content rules ?
|
|
| Benoit MOREAU 2004-01-19, 3:02 pm |
| Hello,
I've been able to configure Network Dispatcher 4.0.21 to define a
cluster of servers and a set of "Content" rules to load-balance
request depending on the URI the user accesses.
But I don't find a means to configure an affinity, so that a user is
balanced to the same server during his WebSphere session. I used to do
this in ND3.6 by setting a Sticky time at the port level with the same
duration as the WebSphere session. But it seems I can't define URI
based content rules and use sticky time at the same time. I get the
error "Sticky time on port can not be set to 1800 because there is a
content rule configured on that port, or that port has rules using
rule affinity".
So, how can I have users balanced to the same server during a given
period of time and define URI based content rules ?
Any help is appreciated.
Thanks.
| |
|
| Benoit,
Certain things cannot be mixed in the Network Dispatcher product. A
particular port cannot support both port-based affinity (client IP for
example) and rule-based affinity (URI, passivecookie, etc). You can
only run one of the affinity types. This is because port-based affinity
has precedence over rules and rules will not be checked if the client IP
affinity matches. However, you should still be able to configure the
content rules (no affinity, no stickytime on rule) and still configure
the port-based IP affinity. In that scenario, the rules would fire for
the first request and send the client to a server based on the URI
match. After that, the port-based affinity would keep the client on
that same server as long as they continue coming back within the
stickytime interval on the port. Affinity would be based on the first
URI the client requests.
The alternative is to use the rule-based affinities. URI affinity is
intended to be used in front of caching proxies (i.e. if you request
same URI then you go to same server with that page cached). You could
pick either the passivecookie affinity (we watch for the designated
server generated cookie) or activecookie (ND creates our own cookie).
When the same rule fires for the client, then we would check that
rule-specific affinity setup and use the same server. If the client
requests a URI that causes a new rule to fire, then the client would
receive affinity specific to that rule.
Not sure which one you're trying for in your setup, but I hope that
helps some.
Jeff
| |
| Benoit MOREAU 2004-01-19, 3:02 pm |
| Hello,
Thank you for your valuable feedback.
In fact, we'd like to be able to mix WebSphere servers (also with other web
containers) behind the same cluster address without installing all
applications on all servers. Hence the need for something like CBR. But
sessions may not be lost between requests of course. Hence the need for an
affinity mechanism.
Rules without affinity and port-based IP affinity only doesn't seem to fit
our needs: this configuration would imply that all applications are
installed on all servers, since, once connected, the user is directed to the
same server for a period of time.
URI affinity isn't the solution either, as I can understand that it's not
appropriate for dynamic content.
We wouldn't like to use passive cookie, as it requires to modify existing
web servers to add a cookie in each response (and some applications with
built-in web servers do not allow such configuration).
We think Active cookie is what we need. But it's not available in Network
Dispatcher with CBR forwarding method (only in the CBR component).
Given our few constraints above, does this mean that we couldn't use
Dispatcher for such a purpose like addressing statefull web containers,
based on URLs ?
Thank you.
Benoit.
| |
|
| Hello Benoit,
I'm not an architect so you may want to run this past other people (IBM
Services perhaps); however, here are my thoughts on the setup. If the
AppServer requests have a distinctive part to their URL, such as
/servlet/ in the request, then you could make rules to do what you
want. For example, it might look like this :
ndcontrol rule add ::appserver type content pattern uri=*/servlet/*
ndcontrol rule uses ::appserver app1+app2+app3
ndcontrol rule add ::default type true
ndcontrol rule uses ::default web1+web2+web3
You should be able to use the AppServer and cookies fairly easy. Isn't
there a sessionid type of cookie already generated? I've seen customers
use that and add a marker to it (like ";s1") and then configure ND to
watch for JSESSIONID and value s1 (in the cookie) to mark app1 as the
target for affinity. Perhaps that was just their particular setup of
WAS though. Without that passivecookie, I'm not sure how you could get
the division you want and the appropriate affinity, without going to
Caching Proxy/CBR and using the activecookie affinity option.
Jeff
|
|
|
|
|