The recommended or ideal topology for setting up Decision Server and Decision Center is to isolate in different configurations the stages of the lifecycle of a decision service, and provide high availability & scalability through balanced clusters.
Clusters for isolating lifecycle stages
Create independent clusters containing Decision Server to provide isolation for the different stages of the decision service lifecycle.
The production cluster also contains a Decision Center to author the business rules and deploy the executable decision service.
With this topology, two deployment strategies can co-exist:
With this topology of one Decision Center, note the following cases:
-
The Decision Center repository supports one rule model. If you have rule projects that have a customized rule model, you will need to add other Decision Centers to your topology.
-
When upgrading from one version of Operational Decision Manager to another, you can setup a temporary cluster for the duration of the migration (see Rolling update of Operational Decision Manager).
Clusters for load balancing and failover support
In a cluster, several Decision Servers or Decision Centers are configured identically on different nodes. A load-balancing system can be used to distribute the requests to the different cluster members. Also, if one node fails, another one can be used.
Some stages of the decision service lifecycle, should use clustering typically Production.
The following diagram shows a cluster containing:
-
The cluster is based on the Liberty collective feature.
-
A Decision Server Runtime cluster with two members. By default the runtime is HTDS. An application with Rule Execution Server embedded should be deployed as HTDS.
-
A Decision Server console that is in stand-alone or in Active/Passive mode
-
A Decision Center cluster with two members
-
A Decision Runner cluster with two members
There are two databases one for Decision Center (Authoring) and one for Decision Server Runtime.
In this schema every ODM components are in the same cluster (collective). You could create separate collective to manage Decision Center only, or Decision Server only.
You could have clusters with Decision Server Runtime and console to build stages dedicated to development, integration, Pre-production…
Protocols used and routing.
The protocols used by the clients are HTTP or HTTPS.
Internally the Decision Server Runtime is connected to the Decision Server Console using TCPIP port 1883 by default.
The notification in Liberty cluster is based on TCPIP notification mode instead of JMX in tWAS cluster.
On Liberty if you use JMX, the notification and management of the console is limited to a single Liberty server.
The routing to the Decision Server Runtime should be Round Robin.
The routing to The Decision Center should be Source to get a Sticky Session.
The routing to the Decision Server Console should be routed to the active console.
Rule Execution Server console
The recommended topology includes a single Rule Execution Server console. The Rule Execution Server console notifies the Decision Server cluster of any updates to decision services.
Note: If you need failover support for the Rule Execution Server console, note that executable decision services deployed from one console will not be visible to the other consoles until you re-synchronize the consoles. See the following technotes before implementing failover support :
Liberty Collective useful documentation