VAST Data
Secure Multitenancy
IntermediateHow many teams or customers can share one cluster safely - without stranding capacity or trading away isolation? Multitenancy runs many isolated tenants on one shared-everything cluster, turning a fast storage system into a platform you can safely share.
Why multitenancy matters
Shared AI infrastructure only pays off when many teams - or many customers - can safely run on it at once. is what makes that sharing safe. It lands differently for each audience:
One cluster, many tenants
Give every team or customer its own cluster and capacity strands in the quiet ones while the busy one hits its ceiling. Share one cluster and everyone draws on the same pool. Switch the lens to see what each audience gets from it.
Why it matters for Enterprises: Consolidate every business unit and AI team onto one platform instead of silos.
Governance, chargeback, and audit per department - with no stranded capacity.
True data isolation, by construction
Each tenant gets its own root structure in the Element Store. View names must be unique within a tenant but can be reused freely across tenants - so every customer can use the same clean layout (/home, /projects) inside their own private root. Paired with per-tenant identity (a view binds via tenant_id + path; user1@TenantA ≠ user1@TenantB), there is simply no path from one tenant's data to another's.
True data isolation - one Element Store, separate roots
Every tenant has its own root inside the one Element Store, so all three use the exact same view names with zero collision. A request must clear three independent gates to reach a view - pick one and watch it.
All three have a /projects view - unique within a tenant, freely reused across tenants. VLANs and subnets are example values.
1 · Network
VIP pool / VLAN
2 · Identity
tenant's IdP
3 · Root
tenant's root
user1@TenantA sends a request for /projects.
Why it matters - a CSP onboards hundreds of customers with clean, identical layouts, and each customer's data and identity stay private by construction.
Six walls around every tenant
A VAST tenant (vastdata_tenant) bundles a full set of independent isolation primitives - not a single permission check.
Six walls, one tenant
Each wall is an independent isolation primitive - get past one and the others still stand. Walk inward from administration to the keys, or tap any wall.
Own administration1/6
Delegated Tenant Admins via tenant-scoped realms; Tenant Privacy Mode hides internals even from cluster admins.
Identity, RBAC & delegated admin
Within a tenant, a single “VAST ID” maps each user across protocols (SMB SIDs, NFS UID/GID, S3 access keys), and S3 identity & bucket policies (an AWS-IAM-compatible subset) are defined per tenant. Administration is delegated through (Events, Hardware, Logical, Monitoring, Security, Settings, Support) that can be scoped to one tenant - so a manages their own tenant and nothing else, while Tenant Privacy Mode can hide a tenant's internals even from the cluster admin.
Who can reach what - nested admin scopes
A Cluster Admin's scope is the whole cluster; a Tenant Admin's realm stops at the edge of one tenant. Pick a role, then hover or tap a capability to see where it acts.
Cluster Admin scopewhole cluster
Tenants - each gets a capacity & QoS envelope
Tenant ATenant Admin realm
Tenant A's admin sees and manages Tenant A only - everything outside its realm is locked.
Why it matters - a CSP hands each customer a real admin console scoped to just their tenant, with zero risk of touching anyone else's data or the cluster.
Performance isolation - no noisy neighbors
Because every tenant can burst across the whole cluster, the job of is to keep one tenant from monopolizing it. A vastdata_qos_policy sets max caps (containment) and min guarantees (a protected floor), static or scaled to capacity, per tenant / view / S3 bucket / user. Watch what happens when a neighbor goes rogue.
Noisy-neighbor containment - QoS on a shared cluster
Three tenants share one cluster and Tenant B bursts. Without QoS, B steals throughput and starves its neighbors. With it, B's max cap contains it and A & C keep their guaranteed min floor. Flip QoS mid-burst to watch the recovery.
Unprotected: a single noisy tenant drags everyone down.
VAST enforces QoS by injecting tiny I/O delays in 0.1-second windows when a tenant exceeds budget. Policies (per tenant, view, S3 bucket, or user) set max caps and min guarantees, changeable live in ~1 second.Why it matters - an end user's SLA is protected no matter what their cluster-mates do.
Encryption, keys & audit
Isolation extends to data-at-rest and the audit trail - the controls a regulated enterprise or sovereign cloud has to prove.
Keys, snapshots and the audit trail
Four controls a regulated tenant has to prove, on one picture. Step through them or pick one.
Keys
Shared pool - AES-XTS-256 at rest
Every block is encrypted transparently - tenants and apps see plain data.
Indestructible snapshots
Audit trail
Tenant A's manager queries:
Encryption at rest
AES-XTS-256, transparent. A data key (DEK) under a key-encryption key (KEK); internal or external KMS (KMIP / Vault).
Block layout and audit rows are schematic examples.
VAST states that crypto-erase aligns with NIST SP 800-88; key rotation and revocation are a cluster-admin operation today.
Where this shows up
Common deployments include neoclouds and GPU-as-a-service providers renting one cluster to many customers, for sovereign AI clouds that must keep governance and audit with the data, and for enterprise “AI factory” platforms where every business unit is a tenant. One shared pool, hard isolation, full efficiency - the combination that makes shared AI infrastructure both safe and economical.
Key takeaways
In one line
Multitenancy on VAST is a dial-able spectrum of isolation - namespace, identity, network, QoS, and encryption - all on one shared-everything cluster, not fixed partitions.
Key points
- A cluster scales to 10,240 tenants, each with its own root, identity provider, VIP pool, and QoS policy.
- Isolation is a dial: tenants can share CNodes fully, get dedicated CNodes plus VLAN, or add a per-tenant encryption group - data stays on one shared NVMe pool.
- QoS max caps and min guarantees contain a noisy tenant and protect neighbors' performance floor, changeable live in about 1 second.
- Per-tenant AES-XTS-256 encryption, immutable snapshots, and a per-tenant, SQL-queryable audit trail (AuditDB) round out the controls.
Questions to explore
- 01How many teams or customers sit on separate storage silos today only because you can't isolate them on one shared pool?
- 02Could any current tenant become a noisy neighbor, and do QoS floors protect the rest?
- 03Do compliance or sovereignty requirements call for per-tenant encryption keys and a per-tenant audit trail?
Common questions
- Doesn't dedicating CNodes to one tenant create stranded capacity like old partitioned storage?
- No - dedicating CNodes pins who serves a tenant, not where its bytes live. The tenant's data still draws from the same shared flash pool, so a provider can offer premium isolation without a separate cluster.
- Does per-tenant encryption hurt storage efficiency?
- Partially - data reduction runs within an encryption group, so per-tenant keys reduce cross-tenant dedup. It's an explicit tradeoff for tenant-scoped crypto-erase.
- Can a cluster admin see into a tenant's data?
- Tenant Privacy Mode can hide a tenant's internals even from the cluster admin, though cluster admins still create tenants, VIP pools, and identity providers - capabilities Tenant Admins don't have.