System requirements

Before you install Operational Decision Manager on Certified Kubernetes, make sure that you install the necessary software and prepare your cluster.

All the Operational Decision Manager on Certified Kubernetes containers are based on Red Hat® Universal Base Images (UBI), and they are Red Hat and IBM® certified. To use these images, the administrator must ensure that the target Kubernetes cluster has the capacity for all the capabilities that you plan to install.

For each stage in your operations (a minimum of three stages is expected: development, preproduction, and production), you must allocate a cluster of nodes before you install Operational Decision Manager on Certified Kubernetes. Development, preproduction, and production are stages that are best run on different computational nodes. To achieve resource isolation, each namespace is a virtual cluster within the physical cluster and an Operational Decision Manager on Certified Kubernetes deployment is scoped to a single namespace. High-level resource objects are scoped within namespaces. Low-level resources, such as nodes and persistent volumes, are not in namespaces.

Note: The Detailed system requirements External link opens a new window or tab page provides a guideline on cluster requirements for Operational Decision Manager. For example, to find information on the supported versions of the OpenShift® Container Platform, open the rendered report for Operational Decision Manager 9.6.0 and go to the Containers tab.

The minimum cluster configuration and physical resources that are needed to run Operational Decision Manager on Certified Kubernetes include the following elements:

  • Hardware architecture: Intel (amd64 or x86_64 the 64-bit edition for Linux®® x86) on all platforms, Linux on IBM Z®, or Linux on Power®.

  • Node counts: Dual compute nodes for nonproduction and production clusters. A minimum of three nodes is needed for medium and large production environments and large test environments. Any cluster configuration needs to adapt to the size of the project and the workload that is expected.

Licensed pods

The following table lists all the components that are licensed in production deployments.

Capability component Licensed for production/nonproduction Pod name
Decision Center Yes <releasename>-odm-decisioncenter
Decision Runner Yes <releasename>-odm-decisionrunner
Decision Server Runtime Yes <releasename>-odm-decisionserverruntime
Decision Server Console No <releasename>-odm-decisionserverconsole
Note: Decision Runner is deployed with a nonproduction license that can be changed to a production license. See the parameter decisionRunner.deployForProduction in Production configuration parameters.

Deployment profiles

This section serves as a guide to help you select the appropriate deployment profile for installing Operational Decision Manager on Certified Kubernetes, based on your specific needs. Each profile detailed below is designed to cater to varying scales of operational demands and user volumes. For further insights into topologies and certified Kubernetes environments related to these profiles, you can refer to this detailed article on ODM Topologies on Certified Kubernetes External link opens a new window or tab.

Note: The values in the hardware requirements tables were derived under specific operating and environment conditions. The information is accurate under specific conditions, but results that are obtained in your operating environments might vary significantly. Therefore, IBM cannot provide any representations, assurances, guarantees, or warranties regarding the performance of the profiles in your environment.

The following table describes each deployment profile.

The following table lists deployment profiles and their estimated workloads:

Profile Description Scaling (per 8-hour day) Minimum number of worker nodes
Small For environments that are used by 10 developers and 5 Decision Center users. For environments that are used by a single department with a few users; useful for application development.

  • Processes 1,000 transactions per second (TPS) max without event emission

  • Supports failover

 3
Medium For environments that are used by 20 developers and 20 Decision Center users. For environments that are used by a single department and by limited users.

  • Processes 5,000 TPS max without event emission

  • Supports high availability (HA) and failover

  • Provides at least two replicas of most services, if configuring failover

 4
Large For environments that are used by 50 developers and 50 Decision Center users. For environments that are shared by multiple departments and users.

  • Processes 9,000 TPS max without event emission

  • Supports HA and failover

  • Provides at least two replicas of most services, if configuring failover

 6

You can use custom resource templates to update the hardware requirements of the services that you want to install.

When you deploy your Operational Decision Manager release with the helm chart, you can customize the CPU and Memory Requests and Limits per container (decisionCenter, decisionRunner, decisionServerRuntime, decisionServerConsole) by using the parameters:

  • <containerName>.replicaCount (except for decisionServerConsole, which can only be 1)

  • <containerName>.resources.limits.cpu

  • <containerName>.resources.limits.memory

  • <containerName>.resources.requests.cpu

  • <containerName>.resources.requests.memory

The parameters can be found in Production configuration parameters.

Tip: For stability, it is recommended that you define the request limit values equally, especially for the Decision Server runtime.

Here is a sample values.yaml code for the small profile:

decisionCenter:
  replicaCount: 1
  resources:
    requests:
      cpu: 1
      memory: 4G
      ephemeral-storage: 1G
    limits:
      cpu: 1
      memory: 4G
      ephemeral-storage: 2G
decisionRunner:
  replicaCount: 1
  resources:
    requests:
      cpu: 500m
      memory: 1G
      ephemeral-storage: 200Mi
    limits:
      cpu: 2
      memory: 2G
      ephemeral-storage: 1G
decisionServerConsole:
  resources:
    requests:
      cpu: 500m
      memory: 512Mi
      ephemeral-storage: 200Mi
    limits:
      cpu: 500m
      memory: 1G
      ephemeral-storage: 1G
decisionServerRuntime:
  replicaCount: 1
  resources:
    requests:
      cpu: 500m
      memory: 2G
      ephemeral-storage: 200Mi
    limits:
      cpu: 1
      memory: 2G
      ephemeral-storage: 1G

The tables below list the recommended resource allocations required by the Operational Decision Manager components for each profile.

Note: The system requirements for small, medium, and large profiles are derived under specific operating and environmental conditions. Due to the differences in hardware, networking, and storage, the resources vary for each workload in different environments. It is important that you run a performance test with peaked workload in a test or user acceptance testing (UAT) environment. Monitor the resource usage, for example, CPU and memory, to determine the resource usage for each component. Based on the resource usage, make changes to CPU request, CPU limit, memory request, and memory limit in the custom resource for each component.

Table for the small profile:

Component CPU Request (m) CPU Limit (m) Memory Request (Mi) Memory Limit (Mi) Ephemeral Storage Request (Mi) Ephemeral Storage Limit (Mi) Number of replicas Pods are licensed for production/non-production
Decision Center 1000 1000 4096 4096 1024 2048 1 Yes
Decision Runner 500 500 1024 2048 200 1024 1 Yes (Non-prod)
Decision Server Runtime 500 1000 2048 2048 200 1024 1 Yes
Decision Server Console 500 500 512 1024 200 1024 1 No
Total 2.5 CPU 3 CPU 7,5 G 9 G 1,6 G 5 G    
                 

Table for the production profile:

Component CPU Request (m) CPU Limit (m) Memory Request (Mi) Memory Limit (Mi) Ephemeral Storage Request (Mi) Ephemeral Storage Limit (Mi) Number of replicas Pods are licensed for production/non-production
Decision Center 1000 1000 4096 8192 1024 2048 4 2 Yes
Decision Runner 500 2000 2048 2048 200 1024 2 2 Yes (Non-Prod)
Decision Server Runtime 2000 2000 2048 2048 200 1024 3 3 Yes
Decision Server Console 500 2000 512 2048 200 1024 1 No
Total 9,5 CPU 14 CPU 18,5 G 28 G 1.9 G 10 G    

Table for the high availability production profile:

Component CPU Request (m) CPU Limit (m) Memory Request (Mi) Memory Limit (Mi) Ephemeral Storage Request (Mi) Ephemeral Storage Limit (Mi) Number of replicas Pods are licensed for production/non-production
Decision Center 2000 2000 4096 16384 1024 2048 2 Yes
Decision Runner 500 4000 2048 2048 200 1024 2 Yes (Non-Prod)
Decision Server Runtime 2000 2000 4096 4096 200 1024 6 Yes
Decision Server Console 500 2000 512 4096 200 1024 1 No
Total 17,5 CPU 26 CPU 36,5 G 64 G 14,6 G 13 G