Configuring storage for the content services environment

Storage is required that is external to the containers in the content services environment. You set up or configure storage to prepare for the container configuration and deployment.

About this task

Each component container requires shared persistent storage to manage configuration information, application working space, and logs. Additionally, you can decide to set up file store areas to store document content and index areas to build full text indexes.

Data storage in a Kubernetes cluster is handled by using volumes. For Kubernetes, a PersistentVolume (PV) is a piece of networked storage in a cluster that is provisioned by an administrator. A PersistentVolumeClaim (PVC) is a request for storage that is made by a user.

The storage classes and persistent volumes carry the details of the real storage, which is then made available for use by cluster users without having any knowledge of the underlying infrastructure. A cluster administrator defines and creates a persistent volume by providing the cloud infrastructure with the details of the implementation of the storage. That storage can be a number of different types including NFS or a cloud-provider-specific storage system.

You can configure storage for your container environment in the following ways:
Manually create storage volumes and volume claims
This method is required in versions 20.0.1 and earlier. Before deploying the content services containers, you must create a set of persistent volumes (PV) and persistent volume claims (PVC) to use with the deployment of each container. Persistent volumes are provisioned in a static way. A cluster administrator creates a number of persistent volumes. The persistent volumes carry the details of the real storage, which is then made available for use by cluster users.
 New in 20.0.2  Dynamically provision storage through the operator functions

The StorageClass resource object describes and classifies storage that can be requested, as well as provides a means for passing parameters for dynamically provisioned storage on demand. StorageClass objects can also serve as a management mechanism for controlling different levels of storage and access to the storage. Cluster administrators define and create the StorageClass objects that users can request without needing any intimate knowledge about the underlying storage volume sources.

The persistent volume framework provided by the cloud platform enables both these functionalities and allows administrators to provision a cluster with persistent storage.

For specifics related to the cloud platform you are deploying into, refer to the documentation given by the your cloud provider or cloud platform.

If dynamic provisioning is used, the deployment can optionally utilize three storage classes to meet the "slow", "medium", and "fast" storage for the Cloud Pak components. You provide the names of these storage classes using these parameters in the custom resource YAML file:
sc_slow_file_storage_classname: 
sc_medium_file_storage_classname: 
sc_fast_file_storage_classname:

To avoid complexity, you can use the same storage class for "slow", "medium", and "fast". However to avoid potential performance issues, that single storage class should target fast storage.

 New in 20.0.2  Combine manually created storage and dynamically provisioned storage
Storage can be provisioned using a mixture of static and dynamic. The operator uses the persistent volume claim names, of the default values, to determine if a claim already exists.
  • If the claim does not exist, dynamic provisioning is used. The persistent volume claim names provided in the custom resource YAML are used when the claim is created.
  • If the claim does exist, that claim is used when deploying.
  • If static provisioning is used, the persistent volumes and persistent volume claims must be pre-created and the persistent volume claim name provided in the CR.
For the content services containers, the persistent volume claims fall into four general categories:
  • Configuration information shared by all container instances, or replicas, for a particular component. This storage experiences minimal accesses or changes. For that reason, a low quality of service (QoS) type of disk is acceptable. The operator will provision a PVC from the sc_slow_file_storage_classname.
  • Logs with a potentially high number of writes and dynamic disk space requirements, where system performance benefits from disk with a higher quality of service. The operator will provision a PVC from the sc_medium_file_storage_classname.
  • Application working space for a particular component. This storage, under certain workloads, experiences high rates of access. System performance benefits from disk with a higher quality of service. The operator will provision a PVC from the sc_fast_file_storage_classname.
  • Data where the disk subsystem must meet a set of requirements for I/Os per second, space, backup power supplies, and so on, and have a long life expectancy. These disk subsystems might also be configured to meet high availability and recoverability requirements as needed by the organization. The operator will provision a PVC from the sc_fast_file_storage_classname.
The storage volumes and storage classes that you create must specify the appropriate reclaim policy and access modes:
  • accessModes: - ReadWriteMany
  • persistentVolumeReclaimPolicy: Retain

When you prepare your environment, record the settings so that these values are available to enter into the custom resource YAML file for deployment and configuration. For lists of the parameters that you need to collect, see the following information: Content services parameters.