Storage considerations

The following table lists the disk space requirements for production deployments. Ranges are for small to large environments.

To pull all of the images from the IBM® Entitled Registry, you need 30 - 50 GB of disk space. The actual size does depend on the registry type that you are using because some registries require more storage than other types of registry.

The following table provides storage requirements for the Decision Intelligence Client Managed Software and runtimes. Kubernetes access modes include Read Write Once (RWO), Read Write Many (RWX), and Read Only Many (ROX).

Table 1. Storage requirements

Product	Storage type	Disk space	Access mode	Number of persistent volumes for non-HA/HA	Posix compliance
Foundational services	For information about sizing and storage options for the foundational services, see the foundational services and Platform UI columns in Table 1 in Storage options .

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 Decision Intelligence and allow workloads to access storage. Access modes describe how the nodes access the storage. Note some default storage classes support ReadWriteOnce (RWO). Decision Intelligence needs ReadWriteMany (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 for ReadWriteOnce (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® Data Foundation . 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.

The foundational services use the cluster default storage class that is expected to be a block storage class.

Platform UI (Zen) needs a block storage class. It supports to use some file storage classes. For more information, see Storage options .

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, the PVC names that are specified in the custom resource are used when the claim is created.

kubectl get storageclass