Planning your deployment

Red Hat OpenShift Container Storage 4.2

Important considerations when deploying RHOCS 4.2

Red Hat Storage Documentation Team


Read this document for important considerations when planning your Red Hat OpenShift Container Storage deployment.

Chapter 1. Introduction to Red Hat OpenShift Container Storage 4.2

Red Hat OpenShift Container Storage is software-defined storage that is optimised for container environments. It runs as an operator on OpenShift Container Platform to provide highly integrated and simplified persistent storage management for containers.

OpenShift Container Storage supports a variety of storage types, including:

  • Block storage for databases
  • Shared file storage for continuous integration, messaging, and data aggregation
  • Object storage for archival, backup, and media storage

Version 4.2 uses Red Hat Ceph Storage to provide the file, block, and object storage that backs persistent volumes, and to manage and orchestrate provisioning of persistent volumes and claims. NooBaa provides object storage, and its Multicloud Object Gateway enables object federation across multiple cloud environments. NooBaa’s enterprise version is named Red Hat Multicloud Object Gateway.


Technology Preview features provide early access to upcoming product innovations, enabling you to test functionality and provide feedback during the development process. However, these features are not fully supported under Red Hat Subscription Level Agreements, may not be functionally complete, and are not intended for production use. As Red Hat considers making future iterations of Technology Preview features generally available, we will attempt to resolve any issues that customers experience when using these features.

See Technology Preview Features Support Scope for more information.

Chapter 2. Architecture of OpenShift Container Storage

Red Hat OpenShift Container Storage uses Red Hat OpenShift Container Platform as a base. For information about the architecture and lifecycle of OpenShift Container Platform, see OpenShift Container Platform architecture.

Red Hat OpenShift Container Storage 4 is comprised of 3 main operators, which codify administrative tasks and custom resources so that task and resource characteristics can be more easily automated. Administrators define the desired end state of the cluster, and various operators work to ensure the cluster is either in that state, or approaching that state, with minimal administrator intervention.

OpenShift Container Storage uses the following operators:

The OpenShift Container Storage (OCS) operator
A meta-operator that codifies and enforces the recommendations and requirements of a supported Red Hat OpenShift Container Storage deployment by drawing on other operators in specific, tested ways. This operator provides the storage cluster resource that wraps resources provided by the Rook-Ceph and NooBaa operators.

OpenShift Container Storage architecture

OpenShift Container Storage architecture

The Rook-Ceph operator
This operator automates the packaging, deployment, management, upgrading, and scaling of persistent storage provided to container applications, and infrastructure services provided to OpenShift Container Platform. It provides the Ceph cluster resource, which manages the pods that host services such as the Object Storage Daemons (OSDs), monitors, and the metadata server for the Ceph file system.
The NooBaa operator
This operator provides the Multicloud Object Gateway, an S3 compatible object store service that allows resource access across multiple cloud environments.

Chapter 3. Supported workload types

Red Hat OpenShift Container Storage provides storage appropriate for a number of workload types.

Block storage is suitable for databases and other low-latency transactional workloads. Some examples of supported workloads are Red Hat OpenShift Container Platform logging and monitoring, and PostgreSQL.

Object storage is for video and audio files, compressed data archives, and the data used to train artificial intelligence or machine learning programs. In addition, object storage can be used for any application developed with a cloud-first approach.

File storage is for continuous integration and delivery, web application file storage, and artificial intelligence or machine learning data aggregation. Supported workloads include Red Hat OpenShift Container Platform registry and messaging using JBoss AMQ.

Chapter 4. Supported configurations

Red Hat OpenShift Container Storage 4.2 is deployed as a minimal cluster of 3 worker nodes. Spread the nodes across three different availability zones to ensure availability.

Each node in this initial cluster runs one 2 TiB disk, which replicate their contents to each other, providing a usable starting capacity of 2 TiB. The initial cluster will consist of 3 nodes, regardless of the number of nodes selected for storage nodes.

The initial cluster can later be expanded to a maximum of 9 nodes that support up to 9 disks for a 3 node cluster.


The distribution of the disks depends on OpenShift scheduling and available resources.

The following table shows the supported configurations for OpenShift Container Storage.

 Number of nodesDisksTotal capacityUsable storage capacity

Initial configuration

3 Nodes

1 disk of 2 TiB on each node

6 TiB

2 TiB

Possible expansion

Maximum of up to 9 nodes

3 disks of 2TiB on each node, which is a maximum of 27 disks of 2 TiB each

Maximum of 54 TiB

Maximum of 18 TiB

As of version 4.2 GA, installation is supported only on existing Red Hat OpenShift Container Platform nodes. See Deploying OpenShift Container Storage for more information.

Chapter 5. Supported Infrastructure and Platforms

Red Hat OpenShift Container Storage supports full stack automation and pre-existing infrastructure.

Full Stack Automation (Installer Provisioned Infrastructure)

With full stack automation, the installer controls all areas of the installation including infrastructure provisioning with an opinionated best practices deployment on Red Hat OpenShift Container Platform.

Red Hat OpenShift Container Storage supports full stack automation when Amazon Web Services is used as an infrastructure provider.

Pre-existing infrastructure (User Provisioned Infrastructure)

With pre-existing infrastructure deployments, administrators are responsible for creating and managing their own infrastructure allowing greater customization and operational flexibility.

Red Hat OpenShift Container Storage supports the following pre-existing infrastructure deployments on:

5.1. Node requirements

The following resources are required for exclusive use by Red Hat OpenShift Container Storage. Calculate the requirements of any non-storage workloads that co-reside with OpenShift Container Storage in addition to these requirements.

The three nodes that are initially installed require space for at least one Object Storage Daemon (OSD) and one Monitor daemon (MON).

Minimum requirements for each starting node (OSD+MON)

  • 16 CPUs
  • 64 GB memory
  • 2 TiB storage per disk (1 disk by default; scalable to 3 disks per node)
  • 10 GiB storage per MON (1 MON)

Subsequent nodes do not require space for MONs.

Requirements for each additional node (OSD only)

  • 16 CPUs
  • 64 GB memory
  • 2 TiB storage per disk (1 disk by default; scalable to 3 disks per node)

On Amazon AWS, the minimum instance type is m5.4xlarge.

5.2. Storage class requirements

Red Hat OpenShift Container Storage makes use of the OpenShift Container Platform default storage class, and expects a certain default storage class depending on your infrastructure provider.

These classes are configured on OpenShift Container Platform nodes automatically, but if your OpenShift Container Platform node uses a different storage class as the default, you must change the default storage class back to the appropriate storage class for your infrastructure provider.

  • On Amazon Web Services, the default storage class must be gp2.
  • On VMware vSphere, the default storage class must be thin.

Chapter 6. Sizing and scaling recommendations

Red Hat OpenShift Container Storage 4.2 supports a minimum of 3 nodes and a maximum of 9 nodes.

Expand the cluster in sets of three nodes to ensure that your storage is replicated, and to ensure you can use at least three availability zones.


Always ensure that you have plenty of storage capacity.

If storage ever fills completely, it is not possible to add capacity or to delete or migrate content away from the storage to free up space. Completely full storage is very difficult to recover.

Capacity alerts are issued when cluster storage capacity reaches 75% (near-full) and 85% (full) of total capacity. Always address capacity warnings promptly, and review your storage regularly to ensure that you do not run out of storage space.

If you do run out of storage space completely, contact Red Hat Customer Support.

Chapter 7. Software requirements

Red Hat OpenShift Container Storage 4.2 is supported on Red Hat OpenShift Container Platform 4.2.13 and later versions.

For more information, see Red Hat OpenShift Container Storage and Red Hat OpenShift Container Platform interoperability matrix.


OpenShift Container Platform must not be installed or running with Federal Information Processing Standards (FIPS) mode enabled.

Nodes that only run storage workloads only require a subscription for Red Hat OpenShift Container Storage.

Nodes that run other workloads in addition to storage workloads require both Red Hat OpenShift Container Storage and Red Hat OpenShift Container Platform subscriptions.

Chapter 8. Next steps

Go to Deploying OpenShift Container Storage to start deploying your container storage solution.