Cloud-Native Object Storage Architectures: Single-Tenant vs Multi-Tenant

Software-defined object storage is a horizontal software play and, as a result, MinIO has customers across industries and workloads. No two deployments are the same. Customers have different requirements depending on the location (public cloud, private cloud, edge) and the use case (backup, AI/ML, data lake, IoT, analytics, artifactory).

One of the architectural questions our customers and community face is the nature of the deployment. Is MinIO going to support a single application such as Veeam backup or replace a storage appliance in order to support cloud native apps? Or is MinIO going to support a more dynamic environment with multiple applications, such as Object Storage as a Service or a Cloud Native AI/ML initiative?

Software-defined MinIO, with its flexibility and rich set of cloud-native integrations, can be deployed in single or multi-tenant modes, and this post is designed to help you determine the appropriate architecture for your deployment.

Single-Application, Single-Tenant

A relatively straightforward rule of thumb is that if you are running a single application, you can opt for a single-tenant, multi-user architecture. For example, in the aforementioned Veeam backup use case, we would recommend running a single MinIO tenant. In this case, your single-tenant could be on bare metal, virtual machines, or Kubernetes. MinIO is flexible and its efficient binary provides the best object storage performance that the underlying hardware supports.  

Replacing a NAS appliance is another example of a single application with multiple users. We always recommend that you begin your migration by exporting all the home directories from an existing NAS appliance into a single bucket on a single MinIO tenant. Then, update login scripts to mount that bucket with drive mappings, while configuring MinIO IAM and PBAC to set and enforce permissions. This result is that no one can access anyone else’s data without explicit permission, and you’ve eliminated the silo of a NAS appliance and the burden of complexity caused by the NAS home directory structure.

The key to a single-tenant, multi-user scenario is to focus on data access and file-sharing rather than on establishing and applying controls based on file and directory structure. A better way is to protect data with bucket-specific S3 access policy.

Object Storage as a Service — The Foundational Multi-Tenant Use Case

MinIO is more frequently deployed as multiple tenants on Kubernetes. This architecture provides complete isolation between tenants and efficiently scales with the number of users and applications and the amount of data stored in MinIO.

One common use case is Object Storage as a Service, providing a self-service portal for developers, DevOps, and data science teams. The mind-boggling hurdle of complexity required to build and maintain such an environment on your own is overcome by the operational efficiency of deploying the MinIO plugin and MinIO Operator on Kubernetes. MinIO Operator works on any Kubernetes distribution — Red Hat OpenShift 4.7+, VMware vSphere 7.0u1, SUSE Rancher or stock upstream. Further, MinIO will work on any public cloud provider such as Amazon Elastic Kubernetes Service, Google Kubernetes Engine, or Azure Kubernetes Service.  

Running multiple MinIO tenants is extremely efficient in a containerized architecture that is orchestrated by Kubernetes. This architecture is frequently deployed because it can be operated efficiently at scale. Massive numbers of users and applications accessing multi-petabyte object storage stretch resources — both systems and the humans who run them — to their limit. Achieving cloud-native hyperscale requires separating functions and scaling them independently as needed, and this includes object storage.

MinIO is designed for hyperscale operations, which require simplicity. Simple is predictable — when things fail you know exactly what failed and can troubleshoot it. From the beginning, enterprise cloud architects must isolate workloads, yet take a whole system approach so they know how the system should behave and how components should interact.

It is simple to create tenants either by command line or by graphical user interface. But there’s way more to object storage as a service than creating tenants. Each MinIO tenant has the full feature set available to it, is fully isolated, and separately configured. Multi-tenant with MinIO Operator is easy, repeatable, declarative, and can be updated without disruption while running each tenant in a separate namespace for security isolation. Now you have the power of hyperscale at your fingertips: Kubernetes manages the operations and configurations non-disruptively, with the tenant as the unit of scale.

Integration with other cloud-native applications and services further simplifies operations to enable object storage as a service. It couldn’t be easier to secure MinIO tenants with an external identity provider such as LDAP/Active Directory or an OpenID provider. MinIO integrates into existing infrastructure for monitoring and alerting such as Prometheus and Grafana. Tiering can be accomplished declaratively by using Kubernetes StorageClasses to allocate sets of HDD and NVMe drives depending on each tenant’s performance requirements.

Application First

As a general rule, when planning MinIO deployments, it’s more important to create buckets and security policies around applications than it is to design them around users. Each application works with its own bucket. For multiple groups and users, we recommend using an external Identity and Access Management (IAM) solution and relying on bucket-specific S3 access policy.

Single or Multi-Tenant: The Choice is Yours

The cloud-native way is to focus on microservices, applications, and frameworks. In order to be successful, you need to maintain that focus when selecting and deploying object storage. Software-defined MinIO can be deployed anywhere in single or multi-tenant configurations. Integration with external IAM and S3 access policies round out the enterprise equation.

Do you have questions about deploying MinIO to meet your requirements? Ask on Slack or send us an email at hello@min.io.