As part of the cell affinity function, in order for the
on demand router (ODR) to route to other cells, generic server clusters
must be defined to represent those cells. Defining generic server
clusters allows each ODR to recognize servers in remote cells.
About this task
Defining the generic server clusters provides a way for
the ODRs in one cell to send traffic to the servers in the another
cell. There are several reasons why this is important. First, if
all the application servers in a cell are unavailable, the ODRs in
that cell send the requests to the generic server clusters, representing
the servers in another cell). The ODRs in the other cell routes the
requests to application servers within their own cell, ensuring that
the requests are handled successfully. If a request which has session
data associated with an application server in a cell, Cell1,
is mistakenly sent to an ODR in another cell, Cell2,
the ODR in Cell2 must be able to forward the request
to an ODR in Cell1. Only the ODRs in Cell1 can
send the request to the appropriate application server (The ODRs in Cell2 cannot
send requests directly to an application server in Cell1).
The generic server cluster allows the ODR in Cell2 to
forward the request to an ODR in Cell1, which then
handles the request.
Procedure
- Configure trusted proxies. An ODR needs to include as trusted
proxies all other ODRs (including those in remote cells), and all
web server or IHS servers that send traffic to this ODR. For ODR configuration
instructions, read about proxy server settings. For further details,
read about configuring ODRs.
- From the administrative console, create a new generic server
cluster. Select .
- Provide a name, select a protocol, and click OK.
- Click the new generic server cluster, and click Ports.
- Click New, and specify the host
name and port number of the ODR as the member of the generic server
cluster.
When defining generic server clusters in which
more than one member (including members in different generic server
clusters) resides on the same node (i.e. has the same host name),
use the server=<uniqueServerName> custom property
to ensure that member names are unique in the on demand cluster. If
this custom property is not set, the host name is used as generic
server cluster member name. The host names are not unique if two members
reside on the same node. The host name duplication causes improper
routing.
The ODR calculates the cloneID for
a server from the host name and the non-SSL ODR port. The same mechanism
is used to calculate generic server cluster member cloneIDs.
Thus, when an ODR in one cell is represented by a generic server
cluster member in another cell, the cloneIDs automatically
match. However, an override mechanism is provided which allows the cloneID to
be specified manually. To do so, define a custom generic server cluster
member property named ODRCloneId with the value
set to the desired cloneID. This value must match
the calculated cloneID of the ODR in the remote
cell.
- Repeat step 5 for each ODR in the cell that the generic
server cluster represents.
- Repeat steps 1 through 5 for each cell in your topology.
- Save your configuration changes.
Results
Configuring the generic server cluster representations
of the ODRs in the remote cell allows incorrectly routed traffic to
be forwarded to the correct cell, maintaining cell affinity. If an
ODR has no available servers in its cell, the request is not serviced.
To enable the ODR to send the request to an application server in
a remote cell, in the case that no local servers are available, read
about configuring the on demand router for multi-cluster failover
and load balancing routing.