Hardware requirements and recommendations for foundational services
Before you install IBM Cloud Pak for Integration, review the system requirements for installing the foundational services.
Some services have dependency on other services. You must consider the service and its dependencies when you estimate the hardware requirements. For more information about the service dependencies, see Dependencies of the IBM Cloud Pak foundational services. For any high availability (HA) configuration that is required for a service, see Configuring high availability for foundational services.
Sizing for foundational services
Based on your cluster requirements, you can pick a deployment profile and enable it during installation. IBM Cloud Pak foundational services provides starterset, starter, large, production, medium, and small deployment profiles. For more information about these profiles, see Table 1. Deployment profiles.
You can set the profile during installation or upgrade.
The default profile is
starterset. Before you install foundational services, you can change the profile to
large, as required. You
can scale up a profile anytime after installation. However, scaling down a profile can be done only if no other Cloud Pak has requested for a larger size. For example, if you install with a
medium profile and another Cloud Pak specifies
large profile, and then you attempt to scale down to size
small, the profile remains as
medium. You would be able to scale down to
small only if there is no other Cloud
If you are upgrading your cluster from a previous release, the default profile setting is
as-is, which retains the previous hardware settings. If required, you can change the profile to
If your cluster supported production workloads in the previous release, it can continue the support with the
For each profile, the total CPU and memory requirements for all services together is provided in Table 2. Hardware requirements.
Note: While the default profile is
starterset profile is not recommended for production usage.
|Profile||Description||Scaling||Minimum number of worker nodes|
|Starterset or Starter||For environments that are used by a single department with only few users. This profile is for first-time users and useful for proof of concept (POC).||- Supports up to 10 users simultaneously accessing an application
- Does not provide HA and failover
|Small||For environments that are used by a single department with a small number of users; useful for application development.||- Supports up to 10 users simultaneously accessing an application
- Supports failover
- StatefulSet provides HA
|Medium||For environments that are used by a single department and by limited users.||- Supports up to 100 users simultaneously accessing an application
- Supports HA and failover
- Provides at least two replicas of most services, if configuring failover
|Large or Production||For environments that are shared by multiple departments and users.||- Supports more than 100 users simultaneously accessing an application
- Supports HA and failover
- Provides three or more replicas of each service, depending upon the workload
Considerations for a small profile
In the small profile, Kubernetes provides a failover capability to the stateless services. The Kubernetes scheduler reschedules pods if required: for example, if the node on which the pod was scheduled goes down. If the Kubernetes scheduler impacts any service pod that was already scheduled, you can manually schedule the pod in another node or restart the impacted service.
If you choose a small profile as your production environment, consider these implications when a service pod is rescheduled:
- You cannot establish new console connections until the IAM service pods are rescheduled.
- You cannot run command-line tools until the platform API service pods are rescheduled.
- You cannot access the Administration Hub or establish a new login session until the common UI service pods and the ingress service pods are rescheduled.
- You might see interruptions while you access the console when a capability is added to the solutions: for example, installing a new service in a new namespace.
- You cannot access the License Service Reporter console until the License Service Reporter pod is rescheduled. The License Service is not impacted even when the License Service pod is rescheduled: the service picks up tracking from where it stopped.
- You cannot create or refresh certificates until the
cert-managerservice pod is rescheduled.
Table 2. Hardware requirements provides the total hardware requirements of the profiles across all worker nodes in your cluster. For capacity planning, consider the CPU request and memory limit.
The CPU request is the minimum number of cores that must be available when a service is created. The memory request is the minimum amount of memory that must be available when a service is created. The CPU limit is the maximum number of cores that a service can consume. The memory limit is the maximum amount of memory available for a service to consume. For more information, see Requests and limits .
You can use templates to update the hardware requirements of the services that you are installing.
|Platform||Profile||CPU Request (cores)||CPU Limit (cores)||Memory Request (GB)||Memory Limit (GB)|
|Linux on Power (ppc64le)||Large||13||67||41||69|
|Linux on Power (ppc64le)||Medium||8||47||24||43|
|Linux on Power (ppc64le)||Small||5||28||11||21|
|Linux on IBM Z and LinuxONE||Large||13||61||42||58|
|Linux on IBM Z and LinuxONE||Medium||7||42||24||34|
|Linux on IBM Z and LinuxONE||Small||5||24||11||15|
Important: For Linux on Power (ppc64le) clusters, see the following notes:
- The numbers that are provided in Table 2 are based on Linux on Power (ppc64le) clusters with SMT level 4 configured.
- To get an estimate of the physical hardware needed to meet the application requirements mentioned in Table 2, see Cores versus vCPUs and hyperthreading.
Hardware requirements of individual services including the hardware requirements of their dependencies is provided in the following topics:
Platform UI framework hardware requirements
If you are planning to install the Platform UI framework (
ibm-zen-operator), there are additional minimum hardware requirements.
The following table shows the minimum requirements for the Platform UI framework:
|Platform UI||4 Gi||1.7|
Db2 Operator hardware requirements
If you are planning to install the Db2 Operator (
ibm-db2u-operator), there are additional minimum hardware requirements.
The following table shows the minimum requirements for the software and operators that are installed with the Db2 Operator:
Events service hardware requirements
If you are planning to install the Events Operator (
ibm-events-operator) for the Events service, there are additional minimum hardware requirements.
The following table shows the minimum requirements for the software and operators that are installed with the Events Operator:
|Kafka (per replica)||1 Gi||1|
|Zookeeper (per replica)||1 Gi||1|
|Cluster Operator||1 Gi||1|
|Entity Operator - Topic Operator||1 Gi||1|
|Entity Operator - User Operator||1 Gi||1|
|Entity Operator - Transport Layer Security (TLS) Sidecar||128 Mi||0.5|
User Data Services (UDS) Operator hardware requirements
If you are planning to install the User Data Services Operator (
ibm-user-data-srvices-operator), there are additional minimum hardware requirements.
The following table shows the minimum requirements (non-HA) for the software and operators that are installed with the User Data Services Operator:
|Pod name||CPU Request (MilliCores)||CPU Limit (MilliCores)||RAM Request (MiB)||RAM Limit (MiB)|
Business Teams Service (BTS) hardware requirements
If you are planning to install the Business Teams Service (
ibm-bts-operator), the following table shows the minimum hardware requirements:
|Business Teams Service||4 Gi on each node||