Persistent volumes for your FTM offering
Decide which type of storage provisioning to use for your FTM offering.
- Network storage
- The FTM offerings use network-storage-based persistent volumes that are shared with FTM users. These persistent volumes are used to load data, such as user exits. They need to be created manually.
- Block storage
- Block storage persistent volumes are created by the dynamic persistent volume provisioning storage class, which is automatically handled by the FTM offering operators. These persistent volumes are internal and are shared with single container or pod. For example, a persistent volume that is created to store the IBM® MQ or IBM App Connect Enterprise log files.
StorageClass resource objects can be used by a cluster administrator to describe the classes of storage that the cluster offers. The cluster administrator can use any StorageClass resource object that they want. For example, NFS V4 for network storage and rook-ceph for block storage.
Static storage provisioning
In static storage provisioning, cluster administrators need to create the required persistent volumes (PV) and the corresponding persistent volume claims (PVC) for FTM consumption. The cluster administrator also needs to assign an appropriate storage size, which is based on the storage needs of your FTM offering. To enable static storage provisioning, both the storage.storage_class_rwx and storage.storage_class_rwo operator configuration parameters for your FTM offering must be empty.
Dynamic storage provisioning
The FTM operator supports dynamically created volumes by using StorageClass resource objects, which enables FTM to support many different storage solutions. For more information about storage classes, see Kubernetes storage classes documentation.
- storage.storage_class_rwx
- storage.storage_class_rwo
FTM operator configuration parameters for storage provisioning
| Parameter name | Description |
|---|---|
| storage.storage_class_rwx | Storage class name for the persistent volumes with rwx access. For example,
managed-nfs-storage. For dynamic provisioning, this parameter must have a value. For static provisioning, this parameter must be empty. |
| storage.storage_class_rwo | Storage class name for the persistent volume with rwo access. For example,
managed-nfs-storage.For dynamic provisioning, this parameter must have a value. For static provisioning, this parameter must be empty. |
| storage.storage_capacity | Storage capacity for the persistent volume claim. For example, 16 Gi. This parameter is used for dynamic provisioning only. |
If the storage_class_rwx and storage_class_rwo parameters exist and are not empty, the FTM operator uses the dynamic storage provisioning scenario. It uses the static storage provisioning scenario if both these parameters are either empty or not available.
Folder creation by the operator
The FTM operator is responsible for creating folders in both storage provisioning scenarios. In static provisioning, if some folders are already created, the operator does not create the folders because it assumes that the user already created all the folders.
Persistent volume cleanup
Both statically and dynamically provisioned persistent volumes (PV) must be monitored to ensure that the storage capacity on each volume is not exceeded. A periodic cleanup of the unused files on the persistent volumes is needed to avoid problems.
For example, the debug data persistent volume is used to store any core memory dump files that the application or system generates. Some system error or failure might cause repeated core memory dumps to be generated, which causes the debug data persistent volume to fill up. Therefore, the debug data PV needs to be monitored and the core memory dump files need to be periodically cleaned up or moved.
Persistent volume best practices
- Use a separate volume or drive for each persistent volume
- To help avoid problems, create and mount an individual volume or drive for each persistent volume.