Red Hat OpenShift Container Storage is software-defined storage integrated with and optimized for Red Hat OpenShift Container Platform. OpenShift Container Storage 4.2 is built on Red Hat Ceph® Storage, Rook, and NooBaa to provide container native storage services that support block, file, and object services. For the initial 4.2 release, OpenShift Container Storage will be supported on OpenShift platforms deployed on Amazon Web Services and VMware. It will deploy anywhere OpenShift does: on-premise or in the public cloud.
Red Hat OpenShift Container Storage supports a variety of traditional and cloud-native workloads including:
- Block storage for databases and messaging.
- Shared file storage for continuous integration and data aggregation.
- Object storage for archival, backup, and media storage.
With OpenShift 4.x, Red Hat has rearchitected OpenShift to bring the power of Kubernetes Operators to transform our enterprise-grade Kubernetes distribution with automating complex workflows, i.e. deployment, bootstrapping, configuration, provisioning, scaling, upgrading, monitoring and resource management. In conjunction, OpenShift Container Storage 4.2 transforms the cloud storage customer experience by making it easier for Red Hat customers to install, upgrade and manage storage on OpenShift.
Focusing on Customer Experience
With OpenShift Container Storage 4.2, we focused on the customer experience from the ground up with the goal of making it easier and accessible to all OpenShift administrators — whether they are new to storage or are already ninja-level storage gurus — so anyone can install, upgrade and manage the storage in a public cloud-like experience.
We focused on the most common tasks, from deployment through to day-to-day operations, while emphasizing greater scalability and deeper integration with OpenShift to:
- Deploy storage services.
- Expand storage.
- Provide out-of-the-box dashboards in OpenShift Administrator Console to indicate health and status of the storage.
- Alert users when there’s a storage issue.
Leveraging the Kubernetes Operator framework, OpenShift Container Storage (OCS) automates a lot of the complexity involved in providing cloud native storage for OpenShift. OCS integrates deeply into cloud native environments by providing a seamless experience for scheduling, lifecycle management, resource management, security, monitoring, and user experience of the storage resources.
To deploy OpenShift Container Storage, the administrator can go to the OpenShift Administrator Console and navigate to the OperatorHub to find the OpenShift Container Storage Operator:
Once you have the OpenShift Container Storage operator, follow the instructions to install and subscribe to the operator. Once the operator has been installed, navigate to the installed OpenShift Container Storage Operator, where you’ll see the capabilities offered by it.
To create the storage service, click “Create instance” of the “Storage Cluster“ tile.
You will be prompted to select the nodes that will be used to setup the storage cluster. Once the nodes selection is made and submitted, the OpenShift Container Storage operator will begin setting up an OCS storage cluster, provisioning the underlying storage subsystem, deploying necessary drivers, and finally setting up the storage classes to allow your OpenShift users to easily provision and consume storage services that have just been deployed.
Integrated Monitoring and Management
One of the key capabilities provided is the integrated monitoring and management when you deploy OpenShift Container Storage. Specifically, dashboards, monitoring and alerting are provided out-of-the-box. Administrators can easily manage not just their compute but also their storage infrastructure.
If the storage services are impacted, the OpenShift Container Storage Operator will actively perform healing and recovery as needed to ensure data is resilient and available to users. There is no longer a need for the Administrator to have to act upon healing operations, setting up jobs to rebalance or redistribute the data or even upgrade the storage services. Let the OpenShift Container Storage operator handle all of this for you! For administrators concerned with automatic upgrades, the OpenShift Container Storage Operator can be configured to be manually upgraded to meet organizational maintenance policies or considerations.
Expansion Made Simple
Gone are the days when expanding a storage cluster required the expertise of a storage specialist. With a simple click on the “Add Capacity” action, the administrator can quickly grow the OCS storage cluster whenever additional capacity is needed.
The administrator can then specify how much additional capacity he/she wishes to add to the storage cluster without having to know all the details about how to provision the underlying storage devices.
Consuming Storage Services
OpenShift Container Storage may be used to provide storage for a number of workloads:
- Block storage for application development and testing environments that include databases, document stores, and messaging systems.
- File storage for CI/CD build environments, web application storage, and for ingest and aggregation of datasets for machine learning.
- Multi-cloud object storage for CI/CD build artifacts, origin storage, data archives, and pre-trained machine learning models that are ready for serving.
To enable user provisioning of storage, OCS provides storage classes that are ready-to-use when OCS is deployed.
Users and/or developers can request dynamically provisioned storage by including the storage class in their PersistentVolumeClaim requests for their applications.
In addition to block and file-based storage classes, OCS introduces native object storage services for Kubernetes. To provide support for object buckets, OCS introduces the Object Bucket Claims (OBC) and Object Buckets (OB) concept, which takes inspiration from Persistent Volume Claims (PVC) and Persistent Volumes (PV).
A generic, dynamic bucket provisioning API similar to Persistent Volumes and Persistent Volume Claims is introduced, so that users familiar with the PVC/PV model would see bucket provisioning as having a similar pattern. As a result, oc will be easy to use to create, list, and delete object bucket claims and object buckets.
Applications that require an object bucket will create an Object Bucket Claim (OBC) and refer to the object storage class name -- just as you would request a Persistent Volume Claim with a Storage Class name. Let’s see how to create the Object Bucket Claim (OBC) using the following
The object bucket permissions are scoped to the namespace. This means that all the OBCs from the same namespace will receive credentials that have permission to use any other bucket provisioned in the namespace.
You can use
oc to create the Object Bucket Claim (OBC):
$ oc create -f my-bucket-claim.yaml
oc to confirm the OB and accompanying OBC is created:
$ oc get objectbucket
NAME STORAGE-CLASS CLAIM-NAMESPACE CLAIM-NAME RECLAIM-POLICY PHASE AGE
obc-bucket-my-bucket-claim openshift-storage.noobaa.io bucket my-bucket-claim Delete Bound 80s
After creating the OBC, the following Kubernetes resources would be created:
- An ObjectBucket (OB) which contains the bucket endpoint information, a reference to the OBC, and a reference to the storage class.
- A ConfigMap in the same namespace as the OBC, which contains endpoint which applications connect to in order to consume the object interface
- A Secret in the same namespace as the OBC, which contains the key-pairs needed to access the bucket.
The OBC can, in turn, be attached to a deployment or connected to by referencing its endpoint.
Resources and Feedback
To find out more about OpenShift Container Storage or to take a test drive, visit https://www.openshift.com/products/container-storage/.
If you would like to learn more about what the OpenShift Container Storage team is up to or provide feedback on any of the new 4.2 features, take this brief 3-minute survey.