In order for the on demand router (ODR) to route to other
cells, generic server clusters must be defined to represent those
cells. The purpose of defining generic server clusters is to allow
each ODR to recognize the other ODRs that are 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 ODRs in the other 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
need to send requests somewhere. They will send the requests to the
GSC (representing the ODRs in the other cell). The ODRs in the other
cell will then route the requests to application servers in their
own cell, ensuring that the requests are handled successfully. Second,
if a request which has session data associated with an application
server in Cell1 is mistakenly sent to an ODR in Cell2, the ODR in
Cell2 needs to be able to forward the request to an ODR in Cell1,
as 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 GSC will again be used to
allow the ODR in Cell2 to forward the request to an ODR in Cell1 which
will then handle the request.
Procedure
- Configure trusted proxies. All ODRs need to include as
trusted proxies all other ODRS (including those in remote cells),
and all WebServer/IHS Servers that will send traffic to this ODR.
Follow the WebSphere Network Deployment instructions in the Proxy server settings topic for most of the
instructions to configure ODRs. See Configuring ODRs
for WebSphere® Virtual
Enterprise specific fields.
- From the administrative console, create a new generic server
cluster. Select Servers > Generic Server Clusters > New.
- Provide a name, select a protocol, and click OK.
- Click the newly-created 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 GSC members in which more than one GSC member (including
members in different GSCs) resides on the same node (i.e. has the
same host name), you must define the server=<uniqueServerName> custom
property on the GSC member definition in order to ensure uniqueness
of the GSC member names in the ODC. Without this custom property,
the GSC member name will be based on the host name configured, which
will not be unique for two members on the same node and will result
in improper routing. With this property, the GSC member name will
be the value provided in the custom property.
The ODR normally
calculates the cloneID for a server from the host name and the non-SSL
ODR port. This same mechanism is used to calculate GSC member cloneIDs.
Thus, when an ODR in one cell is represented by a GSC 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 GSC 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.
- Click Save to save your configuration changes.
Results
Configuring the GSC representations of the ODRs in the
remote cell allows traffic which was misrouted to one cell to be forwarded
to the correct cell, maintaining cell affinity. It does not enable
failover, meaning that if an ODR has no available servers in its cell,
it will be unable to service the request. 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, see Configuring the on demand router for multi-cluster failover
and load balancing routing
.