Chapter 7. Infrastructure requirements
7.1. Platform requirements
Red Hat OpenShift Container Storage can be combined with an OpenShift Container Platform release that is one minor release behind or ahead of the OpenShift Container Storage version.
OpenShift Container Storage 4.6 can run on:
- OpenShift Container Platform 4.5 (one version behind)
- OpenShift Container Platform 4.6 (same version)
- OpenShift Container Platform 4.7 (one version ahead)
For OpenShift Container Storage 4.6 on IBM Power Systems, IBM Z and LinuxONE infrastructure, only OpenShift Container Platform 4.6 or later is supported.
For external cluster subscription requirements, see this Red Hat Knowledgebase article.
For a complete list of supported platform versions, see the Red Hat OpenShift Container Storage and Red Hat OpenShift Container Platform interoperability matrix.
7.1.1. Amazon EC2
Supports internal Red Hat Openshift Container Storage clusters only.
An Internal cluster must both meet storage device requirements and have a storage class providing either
- EBS storage via the aws-ebs provisioner
- Instance storage via the Local Storage Operator
7.1.2. Bare Metal
Supports internal clusters and consuming external clusters.
An Internal cluster must both meet storage device requirements and have a storage class providing local SSD (NVMe/SATA/SAS, SAN) via the Local Storage Operator.
7.1.3. VMware vSphere
Supports internal clusters and consuming external clusters.
Recommended version: vSphere 6.7, Update 2
See VMware vSphere infrastructure requirements for details.
Additionally, an Internal cluster must both meet storage device requirements and have a storage class providing either
- vSAN or VMFS datastore via the vsphere-volume provisioner
- VMDK, RDM, or DirectPath storage devices via the Local Storage Operator.
7.1.4. Microsoft Azure
Supports internal Red Hat Openshift Container Storage clusters only.
An Internal cluster must both meet storage device requirements and have a storage class providing
- Azure disk via the azure-disk provisioner
7.1.5. Google Cloud [Technology Preview]
Supports internal Red Hat Openshift Container Storage clusters only.
An Internal cluster must both meet storage device requirements and have a storage class providing
- GCE Persistent Disk via the gce-pd provisioner
7.1.6. Red Hat Virtualization Platform [Technology Preview]
Supports internal Red Hat Openshift Container Storage clusters only.
An Internal cluster must both meet storage device requirements and have a storage class providing local SSD (NVMe/SATA/SAS, SAN) via the Local Storage Operator.
7.1.7. Red Hat OpenStack Platform [Technology Preview]
Supports internal Red Hat Openshift Container Storage clusters and consuming external clusters.
An Internal cluster must both meet storage device requirements and have a storage class providing
- standard disk via the Cinder provisioner
7.1.8. IBM Power Systems
Supports internal Red Hat Openshift Container Storage clusters only.
An Internal cluster must both meet storage device requirements and have a storage class providing local SSD (NVMe/SATA/SAS, SAN) via the Local Storage Operator.
7.1.9. IBM Z and LinuxONE
Supports internal Red Hat Openshift Container Storage clusters only.
An Internal cluster must both meet storage device requirements and have a storage class providing local SSD (NVMe/SATA/SAS, SAN) via the Local Storage Operator.
7.2. External mode requirement
7.2.1. Red Hat Ceph Storage
Red Hat Ceph Storage (RHCS) version 4.2z1 or later is required. For more information on versions supported, see this knowledge base article on Red Hat Ceph Storage releases and corresponding Ceph package versions.
For instructions regarding how to install a RHCS 4 cluster, see Installation guide.
External mode is not applicable for IBM Power Systems architecture.
7.3. Resource requirements
OpenShift Container Storage services consist of an initial set of base services, and can be extended with additional device sets. All of these OpenShift Container Storage services pods are scheduled by kubernetes on OpenShift Container Platform nodes according to resource requirements. Expanding the cluster in multiples of three, one node in each failure domain, is an easy way to satisfy pod placement rules.
Deployment Mode | Base services | Additional device Set |
---|---|---|
Internal |
|
|
External |
| Not applicable |
Example: For a 3 node cluster in an internal mode deployment with a single device set, a minimum of 3 x 10 = 30 units of CPU are required.
For more information, see Chapter 6, Subscriptions and CPU units.
CPU units
In this section, 1 CPU Unit maps to the Kubernetes concept of 1 CPU unit.
- 1 unit of CPU is equivalent to 1 core for non-hyperthreaded CPUs.
- 2 units of CPU are equivalent to 1 core for hyperthreaded CPUs.
- OpenShift Container Storage core-based subscriptions always come in pairs (2 cores).
For additional guidance with designing your OpenShift Container Storage cluster, see the OCS Sizing Tool.
7.3.1. Minimum deployment resource requirements [Technology Preview]
An OpenShift Container Storage cluster will be deployed with minimum configuration when the standard deployment resource requirement is not met.
Deployment Mode | Base services |
---|---|
Internal |
|
If you want to add additional device sets, we recommend converting your minimum deployment to standard deployment.
Deployment of OpenShift Container Storage with minimum configuration is a Technology Preview feature. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.
For more information, see Technology Preview Features Support Scope.
7.3.2. Compact deployment resource requirements [Technology Preview]
OpenShift Container Storage can now be installed on a three-node OpenShift compact bare metal cluster, where all the workloads run on three strong master nodes. There are no worker or storage nodes.
Deployment Mode | Base services | Additional device Set |
---|---|---|
Internal |
|
|
To configure OpenShift Container Platform on a compact bare metal cluster, see Configuring a three-node cluster and Delivering a Three-node Architecture for Edge Deployments.
Deployment of OpenShift Container Storage on a three-node compact cluster is a Technology Preview feature. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.
For more information, see Technology Preview Features Support Scope.
7.4. Pod placement rules
Kubernetes is responsible for pod placement based on declarative placement rules. The OpenShift Container Storage base service placement rules for Internal cluster can be summarized as follows:
-
Nodes are labeled with the
cluster.ocs.openshift.io/openshift-storage
key - Nodes are sorted into pseudo failure domains if none exist
- Components requiring high availability are spread across failure domains
- A storage device must be accessible in each failure domain
This leads to the requirement that there be at least three nodes, and that nodes be in three distinct rack or zone failure domains in the case of pre-existing topology labels.
For additional device sets, there must be a storage device, and sufficient resources for the pod consuming it, in each of the three failure domains. Manual placement rules can be used to override default placement rules, but generally this approach is only suitable for bare metal deployments.
7.5. Storage device requirements
Use this section to understand the different storage capacity requirements that you can consider when planning internal mode deployments and upgrades. We generally recommend 9 devices or less per node. This recommendation ensures both that nodes stay below cloud provider dynamic storage device attachment limits, and to limit the recovery time after node failures with local storage devices. Expanding the cluster in multiples of three, one node in each failure domain, is an easy way to satisfy pod placement rules.
You can expand the storage capacity only in the increment of the capacity selected at the time of installation.
7.5.1. Dynamic storage devices
Red Hat OpenShift Container Storage permits the selection of either 0.5 TiB, 2 TiB or 4 TiB capacities as the request size for dynamic storage device sizes. The number of dynamic storage devices that can run per node is a function of the node size, underlying provisioner limits and resource requirements.
OpenShift Container Storage 4.6 on IBM Power Systems does not support dynamic storage devices.
7.5.2. Local storage devices
For local storage deployment, any disk size of 4 TiB or less can be used, and all disks should be of the same size and type. The number of local storage devices that can run per node is a function of the node size and resource requirements. Expanding the cluster in multiples of three, one node in each failure domain, is an easy way to satisfy pod placement rules.
7.5.3. Capacity planning
Always ensure that available storage capacity stays ahead of consumption. Recovery is difficult if available storage capacity is completely exhausted, and requires more intervention than simply adding capacity or deleting or migrating content.
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.
The following tables show example node configurations for Red Hat OpenShift Container Storage with dynamic storage devices.
Storage Device size | Storage Devices per node | Total capacity | Usable storage capacity |
---|---|---|---|
0.5 TiB | 1 | 1.5 TiB | 0.5 TiB |
2 TiB | 1 | 6 TiB | 2 TiB |
4 TiB | 1 | 12 TiB | 4 TiB |
Storage Device size (D) | Storage Devices per node (M) | Total capacity (D * M * N) | Usable storage capacity (D*M*N/3) |
---|---|---|---|
0.5 TiB | 3 | 45 TiB | 15 TiB |
2 TiB | 6 | 360 TiB | 120 TiB |
4 TiB | 9 | 1080 TiB | 360 TiB |