DSM 2.2: Object Store Service (Tech Preview)

In DSM 2.2, we are partnering with MinIO to offer a technical preview of a new Object Storage service. This service allows DSM customers to provision Object Storage on their VMware Cloud Foundation (VCF) environments while enjoying all of the fleet management capabilities offered by DSM. There are a few steps to get the Object Store service configured. In this post, I will go through the setup and demonstrate how a small storage pool is deployed along with the Object Store control plane and Object Store database.

Prerequisites

  1. You will need to source a MinIO AIStor license, even for testing purposes. You will need to contact MinIO for this. This is not something that VMware by Broadcom provides.
  2. You will need to have DSM deployed, and build an appropriate infrastructure policy. A DSM admin permission should also be created and available for use. The infrastructure policy will need an appropriately sized IP pool (see next point).
  3. This Object Store solution that I am rolling out will deploy 10 virtual machines in total. There are 3 VMs deployed for the Object Storage database, another 3 VMs for the Object Store control plane and 4 VMs are deployed for the storage pool. This setup with require a total of 18 available IP addresses in the IP Pool associated with the infrastructure policy. The 3 node database will require 5, the 3 node control plane with require 5, and the 4 node storage pool consumes a further 8, 2 IP addresses per VM. If you decide to add additional storage pools, or use larger storage pools with more nodes, more IP addresses will of course be required.
  4. Since an Object Store requires a database, you will need to make sure that the Postgres database service is also enabled. In my testing, I observe a Postgres database running version 15.10 is deployed, so ensure that this version in enabled in the Version & Upgrade > Postgres section to that the Object Store is able to provision it.
  5. To adhere to MinIO licensing requirements (AGPL), we are unable to ship the MinIO images with DSM. Thus, customers will need to make the four MinIO AIStor images available to DSM. In this post, I will assume an air-gapped setup, so I will retrieve the 4 images required to deploy the object store an upload them to DSM. This will be covered in the first part of this blog post. Once the images are uploaded, the second part of the post will show how to deploy a MinIO Object Store onto vSphere infrastructure using DSM.

Part 1: Preparing the Object Storage images

There are 4 images to make available to DSM 2.2 before an Object Store can be created. These are:

quay.io/minio/aistor/minwall:RELEASE.2024-11-01T19-53-30Z
quay.io/minio/aistor/operator:RELEASE.2024-11-13T09-02-52Z
quay.io/minio/aistor/operator-sidecar:RELEASE.2024-11-12T19-47-18Z
quay.io/minio/aistor/minio:RELEASE.2024-12-13T13-42-41Z

If you look at the MinIO Version Management under the Version & Upgrade > MinIO view in the DSM UI, it will state that initially there are 0/4 required images available.

If the service is expanded, it will show that all of the required images are currently in a pending state.

There are various options to make these images available in DSM. A customer can add a MinIO repository from quay.io if their vSphere infrastructure has internet access. Navigate to the Version & Upgrade > Image Registries view and click ADD. Provide a name for the registry, set the endpoint to quay.io and set the repository to minio. The Auth Type can be left at None. The images should then become available in DSM.

For air-gapped customers that do not have access to the internet, but who do have their own local Image Registry (e.g. Harbor), these customers can download the images and upload them to their internal registry using the docker pull, docker tag and docker push commands. These customers can add their local Image Registry to DSM, using the same steps outlined previously. The images should then become available in DSM.

There is a third option for air-gapped customers. For customers that do not have a local image registry, and do not have internet access, they can upload the images to DSM manually as a tarball. Let’s take this approach here. To make the images available to DSM, we will implement the following steps:

  1. docker pull these images
  2. docker save these images to local .tar files
  3. upload the local .tar files to DSM via the DSM UI

Here is an example on how to use the docker CLI to pull and save the images as .tar files. The tag (RELEASE.dateTtime) for each of the images can be retrieved from the DSM UI as shown in the previous screenshot.

$ docker pull quay.io/minio/aistor/operator:RELEASE.2024-11-13T09-02-52Z
RELEASE.2024-11-13T09-02-52Z: Pulling from minio/aistor/operator
571c306529aa: Pull complete 
82ac497b3946: Pull complete 
cb2a94ec3603: Pull complete 
Digest: sha256:bb33483a6452e1df0aac018c6bdd5aeae31213e638ba1e3f6db9c3751043f381
Status: Downloaded newer image for quay.io/minio/aistor/operator:RELEASE.2024-11-13T09-02-52Z
quay.io/minio/aistor/operator:RELEASE.2024-11-13T09-02-52Z

$ docker save quay.io/minio/aistor/operator:RELEASE.2024-11-13T09-02-52Z > \
operator:RELEASE.2024-11-13T09-02-52.tar

Repeat this step for all four images. Once the images are available locally, the DSM UI can now be used to upload the images to DSM. Customers can browse and upload the images from Version & Upgrade > MinIO > Upload Images. Once an image has been uploaded, the UI should report similar to the following:

Once all 4 images have been uploaded, the Object Store service should now state that 4 / 4 of the required images are now available.

At this point, the Object Service is still in a state of CreateDisabled, so we need to enable it. This is done by selecting the MinIO version above (clicking the check-box) and clicking on the Enable link so that this version can be used for the creation of Object Stores.

MinIO Object Storage is now ready in tech preview mode. DSM is now ready to provision an Object Store onto vSphere infrastructure.

Part 2: Create a MinIO AIStor Object Storage using DSM

Begin this part by navigating to the Object Stores > MinIO (Preview) section of the UI. Then click on the “Create Object Store” button. This will launch the following wizard. In this part, note that it is already looking for a MinIO AIStor license key. As mentioned in the pre-requisites, you will need to contact MinIO directly for one of these keys.

With the license key added, continue to populate the remainder of the fields. Here you can optionally provide a description, as well as your own custom certificates for secure communication to the object store. There is only one version of MinIO as this is the initial release, so version is automatically populated when the images are available. You can also add an fully qualified domain name (FQDN) for the Object Store which will result in the creation of FQDNs for both the console and storage parts of the Object Store. Then you will need to select an infrastructure policy, noting that it will need an IP Pool with a sufficient number of IP addresses. If you are new to the concepts of Infrastructure Policy and IP Pool, check out these earlier blog posts on DSM fundamentals. Finally, add the storage pools. This is where the storage capacity for the object store comes from. You also get the option to choose a VM class for the storage pool nodes, as well as the disk size. Each storage pool node has a single disk to contribute towards the storage capacity. The storage pool is implemented as an N+1 configuration. With a small 4 node storage pool, the equivalent of one server’s capacity (25%) is dedicated to erasureCodeParity. With a medium 8 node storage pool, it is still the equivalent of one server’s capacity that is dedicated to erasureCodeparity, but in this case it is only 12.5% (1 out of 8 nodes). You can add multiple storage pools, up to a maximum of 4. Thus you could have a maximum of 32 nodes (4 pools x 8 nodes) backing the object store. Disk size can range between 20GB and 50TB. All storage pools must be built using the same infrastructure policy.

With an appropriate selection made, we can click on the ‘Create Object Store’ button. This will begin with the rollout of the first control plane node and the first database node. then you should observe the storage pool VMs begin to deploy, before finally seeing the second and third nodes deploy for both the control plane and the database. Here is the full list of VMs from my testing.

You may also notice tasks related to the provisioning of disks for the database nodes and the storage pool nodes. The control plane nodes do not get any additional disks added to them.

If everything has gone according to plan, and no issues are encountered, then the Object Store should appear online and ready.

And if we check the IP Pool of the infrastructure policy on the vSphere Client which is used to deploy this object store, the number of IP addresses consumed is visible. In this vanilla DSM environment, I do not have anything else deployed, so I can see that there are 18 IP addresses consumed just for this object store.

Back in the DSM UI, I can select the Object Store that was created and see quite a bit of information. As you would expect from DSM, there is plenty of detail about the infrastructure. Also visible is Portal and Service URLs and if you click on the information signpost, you will also get the IP addresses. The Monitoring tab will provide details about bucket activity, and you also have the log generation tab and operation auditing tabs available.


At the very top of the Summary window, there is a button to launch the Object Store Portal. Once launched, you can login as a DSM admin. There is also a new permission in DSM 2.2 called Object Store admin. Any user with this permission may also login to the Object Store Portal. After logging in to the Object Store Portal as either DSM admin or Object Store admin, the user can now begin creating S3 buckets. There is plenty of guidance in the UI on how to create buckets, how to add versioning and how to share access to buckets, or give access to bucket contents, along with how to use the API should it be needed. I may cover this in detail in a follow up blog post.

Summary

That completes the setup. Although there are a few steps around image management before you can create the Object Store deployment, these are one-off activities. Once the license and images are in place, you can deploy object stores repeatedly to your VMware Cloud Foundation (VCF) infrastructure. And of course, you can enjoy all of the other fleet management features that DSM offers. Thanks for reading this far. Please reach out if you have any questions.

One Reply to “DSM 2.2: Object Store Service (Tech Preview)”

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.