+

Search Tips   |   Advanced Search

Operating Systems: AIX, HP-UX, Linux, Solaris, Windows, z/OS

 

Configure the on demand router for multi-cluster failover and load balancing routing


To configure the on demand router (ODR) to route requests to a different cluster, you can configure custom properties for configuring multi-cluster failover and load balancing routing policies. You might route requests to a cluster in another cell if your primary cluster fails, to balance the load in your environment between multiple clusters, or to direct the ODR to route requests to a specific cluster.

 

Before you begin

 

About this task

Use multi-cluster routing policies for failover and load balancing. With multi-cluster failover, you can specify a cluster to take over the workload when the primary cluster fails. With load balancing routing, you can balance the request loads between multiple clusters.

 

Procedure

  1. Create a custom property for the multi-cluster routing policy. In the administrative console, click Servers > On demand routers > ODR_name > On demand router properties > On demand router settings > Custom properties > New.

  2. Type a name for the multi-cluster routing policy in the Name field. The name must start with the token MCRP@ string. The syntax follows: The full syntax of the name field follows:
    MCRP@cell_name[$application_name[$web_module_name[$cluster_name]]]
    
    Table 1. Components of the name field syntax
    Option Description
    MCRP Specifies that the custom property is a multi-cluster routing policy (MCRP). This prefix must be specified in uppercase letters.
    @ Required symbol. This symbol is the separator between the policy name and the cell. In this configuration, it is generally used to separate a policy name attribute from a cell name.
    cell_name Name of the cell. This cell must be a valid cell that runs WebSphere® Application Server. The case and spelling must match the WebSphere Application Server configuration.
    $ Separates the WebSphere Application Server objects.
    application_name Specifies the application name without the file extension. For example, if the enterprise application name is StockTrade.ear, then specify StockTrade as the application_name value.
    web_module_name Name of the Web module without the .war file extension.
    cluster_name Name of the cluster in which the application is deployed.
    [ ] Indicates variables that are optional.

  3. Type a value in the Value field. The full syntax of the value field follows:
    policy_type@cell_name1$cluster_name1[,cell_name2$cluster_name2,...]
    
    Table 2. Components of the value field syntax
    Option Description
    policy_type

    The policy_type value is not case sensitive. The failover, wlor, or wrr values can be specified in uppercase or lowercase. Valid values:

    failover: When a request for the application Web module in the cell that is specified in the Name field fails, the request fails over to the cell and cluster that are specified in the Value field after the @ symbol. Requests route only to the configured cell and cluster when the primary cell is down. The cell status is indicated by an HTTP status code of 503, service unavailable.

    wlor: Specifies a weighted least outstanding request load balancing policy. This policy comes into effect when the ODR is active and reads its custom property configuration. This load balancing policy not only considers weights, but also how many outstanding HTTP requests exist in a cluster. This policy will more efficiently distribute requests to clusters that can handle them. Wlor is recommended over wrr.

    New weight values are obtained every 15 seconds from the dynamic workload manager (DWLM), which takes into account the application level response time. Use the mcrp.ui system property to set the new update time in seconds.

    wrr: Specifies a weighted round-robin load balancing policy. This policy comes into effect when the ODR is active and reads its custom property configuration. .

    New weight values are obtained every 15 seconds from the dynamic workload manager (DWLM), which takes into account the application level response time. Use the mcrp.ui system property to set the new update time in seconds

    cell_name Name of the cell. This cell must be a valid cell that runs WebSphere Application Server. The case and spelling must match the cell name in WebSphere Application Server.
    cluster_name

    The cluster names can be names of clusters or dynamic clusters in the local cell, a cluster that is in a cell that is bridged with the core group bridge service, or a generic server cluster.

    The cluster name value must be capitalized and spelled the same way that you specified the name when you created the cluster in the administrative console.

    , The comma (,) is used to separate a set of values in the list.

    All Java™ 2 Platform, Enterprise Edition (J2EE) artifact names such as cell_name, application_name, and cluster_name must be spelled the way that they were spelled in the WebSphere Application Server configuration.

    The cell_name and cluster_name values in the Name or Value field can be a wildcard (*). If you use the wildcard in place of a cell name, all the cells in the cell group are indicated. A cell group is defined by any cells that are bridged together with the core group bridge. If you use the wildcard in place of the cluster_name value, all of the clusters in a given cell are indicated. Using a wildcard value is only relevant when you are using multi-cluster load balancing routing.

    Examples for the value field follow: The following policy configures a failover policy. When a failure occurs, the requests can fail over to the myGSC1 generic server cluster in the thesaharaCell01 cell:

    failover@thesaharaCell01$myGSC1
    
    The following policy configures a weighted least outstanding request load balancing policy.
    wlor@thesaharaCell01$myCluster1,myCell2$myCluster2
    
    The following policy configures a weighted round robin policy.
    wrr@thesaharaCell01$myNYCGSC,cell_2$cluster_2
    
    The following value balances load across all of the cell and cluster combinations where the configured application is deployed.
    wrr@*$*
    

  4. Click Apply or OK to commit your new custom settings.

 

Results

The ODR routes to multiple clusters, as you configured in the multi-cluster routing policy.



Previous topic
Creating ODRs

 

Related concepts


Overview of request flow prioritization

 

Related tasks


Configure WebSphere Virtual Enterprise for cross-cell communication

 

Related reference


createodr.jacl script

Related information


Proxy server settings