Using generic server clusters with cell affinity

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.

1. 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.
2. From the administrative console, create a new generic server cluster. Select Servers > Clusters > Generic server clusters > New.
3. Provide a name, select a protocol, and click OK.
4. Click the new generic server cluster, and click Ports.
5. 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.

6. Repeat step 5 for each ODR in the cell that the generic server cluster represents.
7. Repeat steps 1 through 5 for each cell in your topology.
8. 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.