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.
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.
- 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>
- Start all controllers that are enabled by the Dynamic Routing feature.
- 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.
- Copy the generated plugin-key.jks and plugin-cfg.xml
files to a temporary directory on the web server host.
- 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, see Conversion of the keystore to CMS format on z/OS.
- 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/.
- 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>
- Start the web server and begin routing to the application installed in the collective.
- 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>
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.