Storage considerations

Edit online

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 following table provides storage requirements for FileNet® Content Manager container environment and runtime. Kubernetes access modes include Read Write Once (RWO), Read Write Many (RWX) and Read Only Many (ROX).

Table 1. Storage requirements
Capability or runtime Storage type Disk space Access mode Number of persistent volumes for non-HA/HA Posix compliance
FileNet Content Manager File

Component logs and configuration information: 500MB each component

Temporary working space: Workload dependent minimum 1GB each component

Content Platform Engine and Content Search Services content and index stores: Size of the content elements your users store/index with growth over time

 RWX
  • 6 for CPE
  • 5 for CSS
  • 2 for GraphQL
  • 3 for Task Manager (TM)
  • 2 for CMIS
  • 2 for ExtShare
 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 container environment and allow workloads to access storage. Access modes describe how the nodes access the storage. Note some default storage classes support ReadWriteOnce (RWO). FileNet Content Manager 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. You can attach endurance storage with gid storage classes.
  • ibmc-file-bronze-gid
  • ibmc-file-silver-gid
  • ibmc-file-gold-gid

The YAML files to create these storage classes are provided in the descriptors folder.

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 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.

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.

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 container 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 container-samples/descriptors folder. For more information about downloading container-samples, see Preparing a client to connect to the cluster.

Note: You can get the existing storage classes in the environment by running the following command: 
oc get storageclass

Take note of the storage classes that you want to use for your deployment.

Important: External databases can be used by many of the container components to persist data. You must provision the database instances and make sure that they are accessible from the cluster, or reuse existing database instances. To improve performance, reduce as much as possible the latency between the applications or containers and the database server.