Hardware requirements and recommendations for foundational services

Before you install your product, review the system requirements for installing the foundational services.

Some services have dependency on other services. 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), medium, and large (production) 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 (starter). Before you install foundational services, you can change the profile to small, medium, or large (production) 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 (production) size. For example, if you install with a medium profile and another Cloud Pak specifies a medium or large (production) 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 Pak with medium or large (production) size. You would be able to scale down to starterset (starter) profile with 3 MongoDB replicasets.

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 small, medium, or large (production). If your cluster supported production workloads in the previous release, it can continue the support with the as-is profile.

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 (starter), the starterset (starter) profile is not recommended for production usage.

Deployment profiles

Table 1. Deployment profiles
Profile Description Scaling Minimum number of worker nodes
Starterset (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
1
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
1
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
3
Large (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
5

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:

Hardware requirements

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 Opens in a new tab.

You can use templates to update the hardware requirements of the services that you are installing.

Table 2. Hardware requirements
Platform Profile CPU Request (cores) CPU Limit (cores) Memory Request (GB) Memory Limit (GB)
Linux x86_64 Large 8 23 15 24
Linux x86_64 Medium 6 16 10 17
Linux x86_64 Small 4 9 5 7
Linux on Power (ppc64le) Large 8 29 16 24
Linux on Power (ppc64le) Medium 5 19 11 23
Linux on Power (ppc64le) Small 3 9 5 7
Linux on IBM Z and LinuxONE Large 8 26 16 21
Linux on IBM Z and LinuxONE Medium 5 17 11 15
Linux on IBM Z and LinuxONE Small 3 10 5 7

Important: For Linux on Power (ppc64le) clusters, see the following notes:

Hardware requirements of individual services including the hardware requirements of their dependencies is provided in the following topics:

Certificate Manager Operator hardware requirements

If you plan to install the IBM Cert Manager (ibm-cert-manager), there are additional minimum hardware requirements.

The following table shows the minimum requirements for the IBM Cert Manager:

Table 3. Certificate Manager Operator hardware requirements
Component Memory CPU (cores)
Certificate manager 1.8 Gi 1.6

Licensing Operator hardware requirements

If you plan to install the IBM Licensing Operator (ibm-licensing), there are additional minimum hardware requirements.

The following table shows the minimum requirements for the IBM Licensing Operator:

Table 4. Licensing Operator hardware requirements
Component Memory CPU (cores)
ibm-licensing 700Mi 3.1

License Service Reporter hardware requirements

If you plan to install the IBM License Service Reporter (IBMLicenseServiceReporter), there are additional minimum hardware requirements.

The following table shows the minimum requirements for the IBM License Service Reporter

Table 5. License Service Reporter hardware requirements
Component CPU Request (MilliCores) CPU Limit (MilliCores) Memory Request (MiB) Memory Limit (MiB)
ibm-license-service-reporter 700m 1000m 818Mi 1034Mi

Platform UI framework hardware requirements

If you are planning to install the Platform UI framework (ibm-platformui-operator), there are additional minimum hardware requirements.

The following table shows the minimum requirements for the Platform UI framework:

Table 6. Platform UI framework hardware requirements
Component Memory CPU (cores)
Platform UI 4 Gi 1.7

EDB Operator hardware requirements

If you are planning to install the EDB Operator (cloud-native-postgresql), there are additional minimum hardware requirements.

The following table shows the minimum requirements for the software and operators that are installed with the EDB Operator:

Table 7. EDB Operator hardware requirements
Pod name CPU Request (MilliCores) CPU Limit (MilliCores) RAM Request (MiB) RAM Limit (MiB)
EDB 500m 1100m 200Mi 1000Mi

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:

Table 8. Events Operator hardware requirements
Component Memory CPU (cores)
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

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:

Table 10. EDB Operator hardware requirements
Pod name CPU Request (MilliCores) CPU Limit (MilliCores) RAM Request (MiB) RAM Limit (MiB)
BTS 150m 500m 256Mi 512Mi
PostgreSQL 50m 100m 768Mi 1Gi