Storage considerations

For instances that require RWO volumes, Cloud Pak for Integration supports any storage provider that meets all of the following conditions:

• Is a block storage provider. In other words, you can't use any providers that have traditionally offered RWX storage (including NFS and GlusterFS) to provide RWO volumes.

• Provides storage that is formatted as ext4 or XFS, to ensure POSIX compliance.

• Supports dynamic volume provisioning and a volumeBindingMode value of WaitForFirstConsumer.

• The provider is not documented as being explicitly prohibited from use as a block provider. NFS and GlusterFS are currently prohibited as block providers.

The following storage providers are validated across all instance types in Cloud Pak for Integration.

• Cloud service for storage providers. For more information, see the applicable section: IBM Cloud, Amazon Web Services (AWS), or Microsoft Azure.

• IBM Storage Fusion

• IBM Storage Scale (for File RWX volumes only)

• IBM Storage Suite for IBM Cloud Paks. This suite of offerings includes: IBM Storage Scale; block storage from IBM Spectrum Virtualize, FlashSystem, or DS8K; object storage from IBM Cloud Object Storage or Red Hat Ceph; Red Hat® OpenShift® Data Foundation (ODF).

• Portworx Storage

• Red Hat OpenShift Data Foundation (ODF) as a stand-alone offering. Use the version selector on the linked page to get the supported version that you want to review.

  Tip: For OpenShift Data Foundation in a production environment, the optimal minimum deployment is 4 storage nodes, with 3 Object Storage Daemons (OSDs) on each node. This provides much greater data resiliency in the event of any OSD failures.

• RWO volumes from any storage provider that meets the Required RWO storage characteristics.

For the following instance types, the table provides the corresponding storage providers, access modes, and number of required volumes (HA and non-HA).

For instances that are deployed on cloud services, also see Storage providers for instances on cloud services.

Table 1: Compatible storage types and access modes, and required volumes

* None of the Cloud Pak for Integration components require raw block device storage. In Kubernetes terms, Volume mode in the Kubernetes documentation.

** Kubernetes access modes include Read Write Once (RWO), Read Write Many (RWX), and Read Only Many (ROX). For more information, see Access modes in the Kubernetes documentation.

*** The table includes the number of RWO volumes that are required by each instance in a typical configuration for a high availability (HA) or non-HA deployment. RWX volumes are excluded because they typically use network-attached storage patterns, and therefore are not directly attached to the node. For more information, see the section, Limits on number of persistent volumes for public cloud providers.

• IBM Cloud

• Amazon AWS

• Microsoft Azure

• Limits on number of persistent volumes for public cloud providers

Get the storage requirements for Cloud Pak for Integration on cloud services.

Software-defined storage (SDS) typically involves virtualized data storage that is independent of any underlying hardware. If you currently use an SDS provider or are considering using one, you should consider the tradeoffs of using SDS that has cross-AZ replication (such as ODF, Portworx, or IBM Storage Fusion) with instances in Cloud Pak for Integration that use RWO persistent volume storage.

Instances configured for high-availability in Cloud Pak for Integration that use RWO storage do not require cross-AZ replicated storage as they already provide their own cross-AZ replication.

The implications of using a storage provider with cross-AZ replication for RWO volumes include reduced performance (caused by unnecessary data replication), and increased costs for network data transfer between AZs (as in AWS) and operations personnel. This is why RWO storage that does not have cross-AZ replication may provide the best performance and most cost-effective solution.

The following diagram shows the cost and performance implications of using an SDS provider that has cross-AZ replicated storage, even though the instances already provide cross-AZ replication:

Performance

Instances that use RWO (such as Queue managers with Native HA, or API Connect clusters) already provide their own replication, which results in two copies of the data being sent to other replicas to ensure resilience. When that data is written to the local block storage volume under each instance, a storage provider that uses cross-AZ replication also copies that data to two other locations per volume, which results in a total of eight copies. Typically, the system must wait for each of these write operations to synchronously complete before returning control to the original caller, thus reducing runtime performance.

Network costs

Providers such as AWS charge for data transfer between AZs in a region. If the storage provider is running in your customer account, as is the case with SDS providers, there is a direct financial benefit to right-sizing (in other words, reducing, where possible) the amount of replication that is taking place.

Operational costs

SDS providers require additional hardware capacity (for example, Red Hat OpenShift worker nodes) inside the customer’s account to operate the storage layer. They are also self-managed by the customer, so they have an ongoing cost for the operations personnel that are required to manage and maintain the storage layer.

SDS and replicated storage providers do offer additional flexibility for failover scenarios. A replica of an instance can restart in one of the other AZs if there is an AZ failure. However it is important to make an informed choice about the benefits and drawbacks.

The following diagram shows an alternative approach (without cross-AZ replication), with a storage provider (such as IBM Cloud Block, EBS, or Azure disk) that relies on the built-in replication of instances in Cloud Pak for Integration to achieve cross-AZ replication:

Parent topic:

• Planning