Storage considerations
To run stateful applications, developers need to store the persistent data in a managed storage that is backed by some physical storage. Volumes allow a state to persist across pods.
About this task
The supported storage providers for a production deployment of Cloud Pak for Business Automation include the IBM Storage Suite for IBM Cloud Paks. For more information, see IBM Documentation and Why IBM Storage Suite for IBM Cloud Paks. The following storage options are the most suited from the IBM Storage Suite.
The following table lists the capabilities disk space requirements for production deployments. Ranges are for small to large environments.
The following table provides storage requirements for the included capabilities and runtimes. Kubernetes access modes include Read Write Once (RWO), Read Write Many (RWX) and Read Only Many (ROX).
Capability or runtime | Storage type | Disk space | Access mode | Number of persistent volumes for non-HA/HA | Posix compliance |
---|---|---|---|---|---|
Automation Decision Services | [optional] mongo_embedded: File or Block [optional] runtime storage: File |
50 GB | RWO RWX |
1 (non-HA) 1 (shared) |
Posix compliance needed Posix compliance not needed |
Automation Document Processing | File Block (for mongo) |
64 GB | RWX |
|
Posix compliance needed |
Automation Workstream Services | File | 42 GB | RWX |
|
Posix compliance not needed |
Business Automation Application | File | Application Engine: 50 MB | RWX | 1 | Posix compliance not needed |
Business Automation Insights | File | Flink: 20 GB
Sizing depends on the size of the projects.
|
RWX | Posix compliance not needed | |
Business Automation Navigator | File | RWX | 6 for BAN | Posix compliance not needed | |
Business Automation Studio | File File |
2 - 6 GB | RWO RWX |
|
Posix compliance not needed |
Business Automation Workflow with or without Automation Workstream Services | File File |
72 GB | RWO RWX |
Runtime
Authoring
|
Posix compliance not needed |
FileNet Content Manager | File | Content Platform Engine Object Store: 2 GB Content Platform Engine GCD: 256 MB |
RWX |
|
Posix compliance not needed |
Operational Decision Manager | [optional] File For product customization [optional] DB support to retrieve jdbc driver |
10 - 100 GB If the database is outside the cluster, the size of internal storage is reduced to 1 GB. |
RWX RWX |
1 (non-HA) 1 (non-HA) |
Posix compliance not needed Posix compliance not needed |
Resource Registry | File | Resource Registry: 5 - 16 GB | RWX | 1 | Posix compliance not needed |
Workflow Process Server | File | RWO or RWX | 2 (data, dump) + postgres + elasticsearch (optional) | Posix compliance not needed |
Persistent storage can be defined as static persistent volumes or dynamic storage classes. The storage classes and persistent volumes describe the type of storage to use, which is then configured for an application by users of the cluster.
- Persistent volumes
- A cluster administrator defines and creates a persistent volume (PV) by providing the cloud
infrastructure with the details of the implementation of the storage. That storage can be a number
of different types, including a Network File System (NFS) or a cloud-specific storage system.
For more information, see Persistent volumes.
File system security permissions are needed to secure the Kubernetes environment for the Cloud Pak and allow workloads to access storage. Access modes describe how the nodes access the storage. Note some default storage classes support
ReadWriteOnce
(RWO). Cloud Pak for Business Automation needsReadWriteMany
(RWX) for volume access. - Storage classes
- A
StorageClass
object describes and classifies dynamically provisioned storage that can be requested on demand. The objects can also be used to manage and control access to the storage. Cluster administrators define and create the objects that users can request without needing to know all of the details about the underlying storage sources.Installation needs two storage class names. One that is associated with the dynamic storage you plan to use for file-based
ReadWriteMany
(RWX), and another for block storage forReadWriteOnce
(RWO). Your storage must have sufficient space for the deployment. For more information, see Storage Classes.Storage classes must be POSIX-compliant, such as when used with NFS or a Common Internet File System (CIFS).
For more information about storage class parameters, see Product Documentation for Red Hat OpenShift Container Storage. For example, to allow a deployment to be deleted and redeployed without losing the data and files that are created by a deployment use reclaimPolicy: Retain. For cloud platforms where a file system group owner is needed, use gidAllocate: "true" to request one.
On IBM Cloud (ROKS), you can use thegid
storage classes: ibmc-file-bronze-gid, ibmc-file-silver-gid, and ibmc-file-gold-gid. For more information about gold, silver, and bronze storage, see Storage class reference.Note: From 21.0.3-IF008, the cp4a-clusteradmin-setup.sh script no longer creates the 3 storage classes: cp4a-file-retain-bronze-gid, cp4a-file-retain-silver-gid, and cp4a-file-retain-gold-gid.Important: If you plan to use Portworx storage on ROKS in a multi-zone region (MZR), use the portworx-shared-sc storage class. You cannot use the portworx-db-sc storage class. Task Manager and Aspera integration with Business Automation Navigator does not work with Portworx storage in an MZR as it might take up to an hour to have the applications available again if one zone of the MZR is down.
To use a persistent volume or a pool of storage that is defined by a storage class, a persistent volume claim (PVC) is needed to consume the storage resources. A PVC is a claim for storage by a user that can include requests for a specific size and access modes.
- If static provisioning is used, the PV and PVC must be created in the cluster and the PVC name
is specified in the custom resource.
You can create a pool of volumes that can be used by many different workloads. Leave it up to persistent volume claim to bind to one from the pool. You can create different pools of storage by using PV labels and PVC selectors.
- If dynamic provisioning is used, three storage classes are needed to meet the "slow", "medium",
and "fast" storage for the Cloud Pak components. The PVC names that are specified in the custom
resource are used when the claim is created.
The deployment script on a private OpenShift (OCP) cluster needs a storage class name that the installer can use. The administrator must make a note of the class to use, and provide this name to the user who runs the deployment script. If you do not have three storage classes or you do not want to create them, you can use the same one for "slow", "medium", and "fast".
Note: When dynamic provisioning is used, it does not support labels and selectors. PV is automatically bound to the PVC.
Example YAML files to create storage classes on Red Hat OpenShift Kubernetes Service (ROKS) are provided in the cert-kubernetes/descriptors folder. For more information about downloading cert-kubernetes, see Preparing a client to connect to the cluster.
oc get storageclass
Take note of the storage classes that you want to use for your deployment.