For distributed platformsFor z/OS platforms

Setting up dynamic routing for a single Liberty collective

You can configure the Dynamic Routing feature to route HTTP requests to members of Liberty collectives without having to regenerate the WebSphere plug-in configuration file when the environment changes.

Before you begin

Complete the product installation steps in Setting up dynamic routing for Liberty collectives.

About this task

To use Intelligent Management to route HTTP requests to a Liberty collective, you must enable the dynamicRouting-1.0 feature on one or more collective controllers in a collective. The feature provides the Dynamic Routing service, which dynamically retrieves routing information from the collective repository and delivers this information to the WebSphere® plug-in. The feature also provides the dynamicRouting command. Use its setup, genPluginCfg, and genKeystore command actions together to generate the keystores that are needed for secure communication between the plug-in and the Dynamic Routing service, and a plug-in configuration file that enables Intelligent Management in the WebSphere plug-in.

[17.0.0.1 and later]The routing rules capability enables incoming requests to the WebSphere plug-in to be routed to a specified set of servers. Additionally, requests can selectively be rejected or redirected. Selection of whether a rule applies to an incoming request is done through matching of attributes of the incoming request.

Procedure

  1. Enable Dynamic Routing in a controller by adding the following code to the featureManager tag in the server.xml of the controller.
    <feature>dynamicRouting-1.0</feature>
  2. Start all controllers that are enabled by the Dynamic Routing feature.
  3. Run the dynamicRouting setup command on one of the controllers to generate the keystore and plug-in configuration files. For example:
    ./dynamicRouting setup --port=9444 --host=controller1.acme.com --user=admin --password=passw0rd --keystorePassword=webAS --pluginInstallRoot=/opt/HTTPServer_Plugins/ --webServerNames=webserver1
    Note: Ensure a specified value of the --user argument exists in a user registry and is assigned an administrative role.

    For more information, see Dynamic routing command.

  4. Copy the generated plugin-key.jks and plugin-cfg.xml files to a temporary directory on the web server host.
  5. On the web server host, run gskcmd (included in the IHS package) to convert the keystore to CMS format and to set personal certificate as the default. CMS format is the supported format of the WebSphere Plug-in. For example:
    gskcmd -keydb -convert -pw webAS -db /tmp/plugin-key.jks -old_format jks -target /tmp/plugin-key.kdb -new_format cms -stash
    gskcmd -cert -setdefault -pw <<password>> -db /tmp/plugin-key.kdb -label default

    For z/OS platformsFor z/OS, see Conversion of the keystore to CMS format on z/OS.

  6. Copy the plugin-key.kdb, plugin-key.rdb, and plugin-key.sth files that are created by gskcmd from the temporary directory to the directory --pluginInstallRootargument_value/config/web_server_name/.
  7. Copy the plugin-cfg.xml to the directory specified in the WebSpherePluginConfig directive in the web server httpd.conf file. The plugin-cfg.xml is generated with the <IntelligentManagement> stanza. When Dynamic Routing is enabled in a collective, one <Connector> stanza exists for each collective controller.
    For example:
    <IntelligentManagement>
     <Property name="webserverName" value="webServer1"/>
     <ConnectorCluster enabled="true" maxRetries="-1" name="default" retryInterval="60">
      <Property name="uri" value="/ibm/api/dynamicRouting"/>
      <Connector host="controller1.acme.com" port="9444" protocol="https">
      <Property name="keyring" value="/opt/HTTPServer_Plugins/config/webserver1/plugin-key.kdb"/>
     </Connector>
     </ConnectorCluster>
    </IntelligentManagement>
  8. Start the web server and begin routing to the application installed in the collective.
  9. Optional: Add the <dynamicRouting> element to the controller server.xml to specify properties for dynamic routing.

    The connectorClusterName property specifies the name that dynamic routing associates with the collective. If the connectorClusterName property is not specified, the name of the collective is used. The retryInterval property specifies how long to wait before a reconnection to a controller if a connection fails. The maxRetries property specifies the number of times to try to reconnect to a failed collective controller.

    For example:
    <dynamicRouting maxRetries="4" retryInterval="20" connectorClusterName="collective1"/>
     <TraceSpecification name="default" specification=":DEBUG"/>
    </dynamicRouting>
    The generated plugin-cfg.xml has the <ConnectorCluster> properties:
    <IntelligentManagement>
     <TraceSpecification name="default" specification=":DEBUG"/>
      <Property name="webserverName" value="webServer1"/>
      <ConnectorCluster enabled="true" maxRetries="4" name="collective1" retryInterval="20">
      <Property name="uri" value="/ibm/api/dynamicRouting"/>
      <Connector host="controller1.acme.com" port="9444" protocol="https">
      <Property name="keyring" value="/opt/HTTPServer_Plugins/config/webServer1/plugin-key.kdb"/>
      </Connector>
     </ConnectorCluster>
    </IntelligentManagement>
  10. [17.0.0.1 and later]Optional: Create routing rules to specify how particular requests are handled.

    Routing rules can specify to:

    • Reject specific requests.
    • Redirect specific requests.
    • Allow specific requests to go to a subset of the available servers.
    • Failover specific requests from one set of servers to another set of servers.

    See Routing rules for Liberty dynamic routing and Configuring routing rules for Liberty dynamic routing.

Results

With the dynamicRouting-1.0 feature enabled, Intelligent Management can now dynamically route HTTP requests to Liberty collectives.


Icon that indicates the type of topic Task topic

File name: twlp_wve_enabledynrout_single.html