Introducing Multi-Cloud Object Gateway for OpenShift

The Multi-Cloud Object Gateway is a new data federation service introduced in OpenShift Container Storage 4.2. The technology is based on the NooBaa project, which was acquired by Red Hat in November 2018, and open sourced recently. More information can be found here https://github.com/noobaa/noobaa-operator.

The Multi-Cloud Object Gateway has an object interface with an S3 compatible API. The service is deployed automatically as part of OpenShift Container Storage 4.2 and provides the same functionality regardless of its hosting environment.

Simplicity, Single experience anywhere

In its default deployment, the Multi-Cloud Object Gateway provides a local object service backed by using local storage or cloud-native storage, if hosted in the cloud.
Every data bucket on the Multi-Cloud Object Gateway is backed, by default, by using local storage or cloud-native storage, if hosted in the cloud. No additional configuration is required.
The Multi-Cloud Object Gateway’s object service API is always an S3 API, which means a single experience on-premise and in the cloud, for any cloud provider. This translates to a zero learning curve when moving to, or adding a new cloud vendor. That translates into greater agility for your teams.

Elasticity

The administrator can add multiple backing stores and apply mirroring policies to create hybrid data buckets and multi-cloud data buckets, using cloud-native storage providers and/or on-prem storage providers. Each bucket can have its own data placement policy and can be changed over time, to support the changing needs of applications and environments.

Integrated Monitoring and Management

The Multi-Cloud Object Gateway leverages the power of Kubernetes Operators to automate complex workflows, i.e. deployment, bootstrapping, configuration, provisioning, scaling, upgrading, monitoring and resource management. It is integrated into the OpenShift storage dashboard to provide an instant view of the current object usage, alerts and resource allocations.

If object services are impacted, the Multi-Cloud Object Gateway Operator will actively perform healing and recovery as needed to ensure data is resilient and available to users. There is no need for the Administrator to enable healing operations, set up jobs to rebalance or redistribute the data, or even upgrade the storage services. 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, as well.

Object Provisioning Made Easy

OpenShift Container Storage supports persistent volume claims for block and file-based storage. In addition, it 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 can handle bucket provisioning with a similar pattern.

Applications that require an object bucket will create an Object Bucket Claim (OBC) and refer to the object storage class name.
Example:

You can use oc to create the Object Bucket Claim:

$ oc create -f obc-test.yaml

objectbucketclaim.objectbucket.io/obc-test created

Use oc to confirm the Object Bucket and accompanying Object Bucket Claim is created:

$ oc get objectbucket

NAME STORAGE-CLASS CLAIM-NAMESPACE CLAIM-NAME RECLAIM-POLICY PHASE AGE

obc-test-obc-test openshift-storage.noobaa.io obc-test Delete Bound 80s

After creating the Object Bucket Claim, the following Kubernetes resources would be created:

• An Object Bucket which contains the bucket endpoint information, a reference to the Object Bucket Claim and a reference to the storage class.
• A ConfigMap in the same namespace as the Object Bucket Claim, which contains connection information such as the endpoint host, port and bucket name, to be used by applications in order to consume the object service
• A Secret in the same namespace as the OBC, which contains the access key and secret key needed to access the bucket.

This information can be used with environment variables. The following YAML is an example of a job using Object Bucket Claim and reading the information from the config map and secret into the environment variables:

apiVersion: objectbucket.io/v1alpha1

kind: ObjectBucketClaim

metadata:

  name: "obc-test"

spec:

  generateBucketName: "obc-test-noobaa"

  storageClassName: openshift-storage.noobaa.io

---

apiVersion: batch/v1

kind: Job

metadata:

  name: obc-test

spec:

  template:

    spec:

      restartPolicy: OnFailure

      containers:

        - image: quay.io/etamir/training:latest

          name: obc-test

          env:

            - name: BUCKET_NAME

              valueFrom:

                configMapKeyRef:

                  name: obc-test

                  key: BUCKET_NAME

            - name: BUCKET_HOST

              valueFrom:

                configMapKeyRef:

                  name: obc-test

                  key: BUCKET_HOST

            - name: BUCKET_PORT

              valueFrom:

                configMapKeyRef:

                  name: obc-test

                  key: BUCKET_PORT

            - name: AWS_ACCESS_KEY_ID

              valueFrom:

                secretKeyRef:

                  name: obc-test

                  key: AWS_ACCESS_KEY_ID

            - name: AWS_SECRET_ACCESS_KEY

              valueFrom:

                secretKeyRef:

                  name: obc-test

                  key: AWS_SECRET_ACCESS_KEY

            - name: AWS_DEFAULT_REGION

              value: "us-east-1"

          volumeMounts:

            - name: training-persistent-storage

              mountPath: /data

      volumes:

      - name: training-persistent-storage

        emptyDir: {}

Security First

The Multi-Cloud Object Gateway provides multiple solutions for security concerns out of the box.

1.  
   1. Data encryption by default - every write operation chunked into multiple chunks and encrypted with a new key.
   2. Key management separation from data - all the keys are managed in a centralized location, separated from the encrypted chunks of data, regardless of the data location which can be in the cloud, on prem or a mixture for hybrid and multi-cloud deployments.
   3. Data isolation - every object bucket claim creates a new account, with new credentials permitted to access a new single bucket and create new buckets accessible only to this account, by default.

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.