Skip to main contentIBM Cloud Pak Playbook


Files to download

You will need one of the following downloads to perform the Cloud Pak installation

  • CC644EN - IBM Cloud Pak For Integration 2020.1.1 On Openshift For Linux English
  • CC645EN - IBM Cloud Pak For Integration 2020.1.1 On Openshift For Linux English Online Installer
  • IBM Cloud Pak for Integration 2020.2.x there is nothing required to download.

CLI configuration

The system you use to run the installation requires both Docker and the Open Container CLI. Docker provides very intuitive instructions for installation. The oc CLI code and installation instructions can be accessed here from RedHat OpenShift.

Workload Requirements

General cluster sizing guidance is provided lower down in this page. Avoid installing minimal environments. Keep in mind that a realistic cluster running the Cloud Pak for Integration will contain multiple workloads from the below chart. Your cluster will likely host other Cloud Pak workload or be shared with other non-Cloud Pak workload. Of course, licensing for Cloud Paks only covers the exact equivalent licenses for the underlying OCP. You can find discussion from this section in the Requirements Knowledge Center article and for the Cloud Pak for Integration (choose the correct version).

Integration CapabilityCPUMemoryDisk space
Platform Navigator: A component product that provides easy access to deployed capabilities and their UIs. For versions prior to v2020.2 can be easily used to deploy Cloud Pak for Integrations capabilities.25 cores256 MBNot Required
Common Services: Required by the base product. This can increase dramatically with usage depending on the enabled management services8 cores32 GB40 GB
API Lifecycle and Management: This capability is provided by deploying IBM API Connect. For specific requirements regarding this capability, see the IBM API Connect system requirements12 cores48 GB550 GB
Queue Manager: This capability is provided by deploying IBM MQ. The values given are a general default assuming a single instance of this capability. Generally, when sizing a larger modernization effort, the modernized workload will be roughly equivalent to the traditional workload. For specific requirements see the IBM MQ system requirements1 core1 GB2 GB
Event Streams: This capability is provided by deploying IBM Event Streams. For specific requirements regarding this capability, see the IBM Event Streams system requirements16.2 cores25.2 GB1.5 GB
Application Integration: This capability is provided by deploying IBM App Connect. The values given here are for default settings for a default flow example. You should adjust the resource requirements for your flow after observing its behavior under usage. To plan capacity for modernizing a large set of workload, assume that the modernize and traditional workload would use roughly the same amount of compute and memory. App Connect workload does use a considerable amount of container storage. For specific requirements regarding this capability, see the IBM App Connect system requirements1 core4 GB2.3 GB
High Speed File Transfer: This capability is provided by deploying IBM Aspera. For specific requirements regarding this capability, see the IBM Aspera system requirements4 cores4 GBWorkload Dependent
Asset Repository: Optional asset management capability4.25 cores8.5 GB2 GB

Most of the capabilities provided by the Cloud Pak for Integration have state and thus require Persistent Storage. Your persistent storage provider will depend largely on the cloud environment you are deploying to. Each public cloud provider has their own storage services that can (and should) be used for your workload’s persistent storage. These providers will easily match to the requirements in the chart below. Take time to understand fully each column.

There currently are more decisions to make when the solution is deployed into private (on-premise) infrastructure. OpenShift now has the industry leading solution for providing container storage called Red Hat OpenShift Container Storage (OCS). See this document for a detailed explanation. This solution is based upon Rook / Ceph and runs via operator. It can be used without license in your lower environments without support. At the time of this article being written OCS licensing for support etc. is not included with Cloud Pak licenses and must be purchased separately. IBM Storage also has a hardware / software available for purchase to provide first-class persistent storage to your private cloud stateful containers. Outside of these solutions using your enterprise NFS provides a decent option for providing File storage and Rook / Ceph provide adequate support for most Block Storage requirements. For production workloads please consider the resilience of the persistent storage provider you chose. In the near future OCS will be the preferred solution for production workload that require resilient on-premise storage.

With this guidance in mind, use the following table to help make your persistent storage decisions and create the required storage classes prior to deployment.

Integration CapabilityStorage TypeAccess ModePerformance
Common Services: Alert ManagerBlockRWOMinimum 4 IOPS/GB Recommended 20 GB
Common Services: Elk Data LoggingBlockRWOMinimum 4 IOPS/GB Recommended 30 GB
Common Services: Prometheus (Monitoring)BlockRWOMinimum 4 IOPS/GB Recommended 20 GB
Common Services: MongoDB (Default 3 instances)BlockRWOMinimum 4 IOPS/GB Recommended 20 GB (each instance)
Platform Navigator: Not persistent storage requiredN/AN/AN/A
API Lifecycle and ManagementBlockRWOMinimum 4 IOPS/GB Recommend 10 IOPS/GB
Queue ManagerFileRWXAffected by other limits applied to the file system
Event Messaging: See the IBM Event Streams storage documentation There are three core components with their own requirements. Kafka and Zookeeper will require Block for non-ephemeral deployments.File/BlockRWONotes
Application Integration: When deployed without including MQ capability no persistent volume is required. This is the recommendation. Whenever possible separate MQ into its own pods. If MQ is included, the values here applyFileRWXAffected by other limits applied to the file system
High Speed File TransferFileRWXNot Specified
Asset RepositoryFile & BlockRWX + RWONot Specified

OCP Cluster Configuration Best-Practices

This playbook contains a section that offers general OpenShift Cloud Platform configuration and installation procedures. For environments that require resilience, the below is the best practice recommendation for hosting Cloud Pak for Integration on OCP 4.2 or 4.3. You can configure smaller environments, but this is the getting-started suggestion. Also, this cluster has a large enough control plane to grow in order to support a larger number of compute nodes for hosting additional workload.

Control Plane Nodes (Masters)38 vCPU32 GB300 GB
Compute Nodes (Workers)58 vCPU32 GB200 GB
Compute & Storage Nodes: For use on primarily on-premise cluster to host OCS or Rook / Ceph storage. These can run both storage and general workload.38 vCPU32 GB200 GB & 500 GB 2nd Disk
Install Node: This component is no longer used for v2020.2 and newer. For offline installations of the Cloud Pak. See your specific OCP version and deployment mode for specifics. Note that the offline Pak installation for Integration requires this larger disk.14 vCPU16 GB200 GB
Load Balancer(s): If you do not have enterprise load balancing available you can optionally install HA Proxy load balancers for managing internal and external load balancing. Consider the resiliency you require. You can accomplish this using a single load balancer, but your architecture may require further diligence.1 or 24 vCPU8 GB100 GB