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.
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.
The system you use to run the installation no longer requires Docker and the Open Container CLI. The
oc CLI is convenient for certain steps during deployment. The CLI code and installation instructions can be accessed here from RedHat OpenShift.
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 Capability||CPU||Memory||Disk 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 cores||256 Mb||Not Required|
|Common Services: Required by the base product. This can increase dramatically with usage depending on the enabled management services||8 cores||32 Gb||40 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 requirements||12 cores||48 Gb||550 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 requirements||1 core||1 Gb||2 Gb|
|Event Streams: This capability is provided by deploying IBM Event Streams. For specific requirements regarding this capability, see the IBM Event Streams system requirements||16.2 cores||25.2 Gb||1.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 requirements||1 core||4 Gb||2.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 requirements||4 cores||4 Gb||Workload Dependent|
|Asset Repository: Optional asset management capability||4.25 cores||8.5 Gb||2 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 Capability||Storage Type||Access Mode||Performance|
|Common Services: Alert Manager||Block||RWO||Minimum 4 IOPS/GB Recommended 20 GB|
|Common Services: Elk Data Logging||Block||RWO||Minimum 4 IOPS/GB Recommended 30 GB|
|Common Services: Prometheus (Monitoring)||Block||RWO||Minimum 4 IOPS/GB Recommended 20 GB|
|Common Services: MongoDB (Default 3 instances)||Block||RWO||Minimum 4 IOPS/GB Recommended 20 GB (each instance)|
|Platform Navigator: Not persistent storage required||N/A||N/A||N/A|
|API Lifecycle and Management||Block||RWO||Minimum 4 IOPS/GB Recommend 10 IOPS/GB|
|Queue Manager||File||RWX||Affected 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/Block||RWO||Notes|
|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 apply||File||RWX||Affected by other limits applied to the file system|
|High Speed File Transfer||File||RWX||Not Specified|
|Asset Repository||File & Block||RWX + RWO||Not Specified|
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)||3||8 vCPU||32 GB||300 GB|
|Compute Nodes (Workers)||5||8 vCPU||32 GB||200 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.||3||8 vCPU||32 GB||200 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.||1||4 vCPU||16 GB||200 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 2||4 vCPU||8 GB||100 GB|