VAST Data
Secure Multitenancy
IntermediateMulti-tenancy is VAST's signature strength: run many fully-isolated tenants on ONE shared-everything cluster, with no stranded capacity and no noisy neighbors. It's the capability that turns 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. Multi-tenancy is what makes that sharing safe. It lands differently for each audience:
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.
Why it matters for CSPs & Neoclouds
- Rent one cluster to many customers at high tenant density with hard isolation.
- Metered billing and per-tenant SLAs turn shared infrastructure into a product.
Why it matters for End users
- Your data, identity, and keys are private by construction - invisible to neighbors.
- A noisy tenant can't steal your performance; your SLA holds.
One shared pool, dial-able isolation
Legacy partitioned storage forces a choice: carve the system into fixed per-customer slices (stranding capacity and capping each tenant's ceiling), or share it and accept contention. VAST's disaggregated shared-everything architecture removes the dilemma. The data always lives on one global flash pool that every compute node can reach; isolation is enforced in software - and you can dial it up from fully shared to dedicated compute to per-tenant crypto. A cluster scales to 10,240 tenants (raised from 4,096 in v5.4.0).
The isolation spectrum - one shared pool, dial-able isolation
VAST doesn't force a choice between “shared” and “isolated.” On one shared-everything pool you dial how much of the serving path and crypto boundary a tenant gets. Slide through the levels.
Serving path — CNodes
Data — one shared-everything pool (DNodes, NVMe-oF)
always sharedEvery tenant's bytes live here, globally accessible to every CNode. You dial the serving path and crypto — never the data layer.
Isolation
Logical (namespace, identity, network, QoS)
Elasticity
Full — bursts across every CNode in the cluster
- Tenant served by ALL CNodes; isolation enforced in software.
- Separate Element Store root, identity provider, VIP pool, quotas, QoS.
- No stranded capacity — every tenant can reach full cluster performance.
Who picks this: Most tenants, especially many small ones — maximum utilization and elastic burst.
The key insight: dedicating CNodes pins who serves a tenant, not where its bytes live. Even a “physically isolated” tenant still draws from the same efficient global pool - so a CSP can offer premium isolation without standing up a separate cluster.
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 - identical names, separate roots
Every tenant has its own root in the Element Store, so all three can use the exact same view names with zero collision. Identity is separate too: user1 is a different principal in each tenant.
Tenant A
own root/ (tenant root)
└ /home
└ /projects
└ /scratch
user1 → Active Directory, AKIA·A1B2…7F
VIP pool · VLAN 120 · 10.10.0.0/16
encryption group eg-tenant-a
Tenant B
own root/ (tenant root)
└ /home
└ /projects
└ /scratch
user1 → LDAP, AKIA·B9C0…3D
VIP pool · VLAN 220 · 10.20.0.0/16
encryption group eg-tenant-b
Tenant C
own root/ (tenant root)
└ /home
└ /projects
└ /scratch
user1 → local provider, AKIA·C4D5…9A
VIP pool · VLAN 320 · 10.30.0.0/16
encryption group eg-tenant-c
All three have a /projects view - unique within a tenant, freely reused across tenants. In a single global namespace you'd be forced into /tenantA/projects naming and risk collisions; per-tenant roots let every customer keep a clean, identical layout.
Try an access request
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.
Own namespace
A separate directory hierarchy (root) in the Element Store - identical view names coexist across tenants.
Own identity
Per-tenant AD / LDAP / NIS / Kerberos - overlapping usernames never collide.
Own network
VIP pools (optionally pinned to specific CNodes) + VLAN tags segregate the data path.
Own keys
≥1 encryption group per tenant gives a distinct AES-XTS-256 key and tenant-scoped crypto-erase.
Own performance
QoS min/max + quotas govern each tenant's share of the shared cluster.
Own administration
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 realms (Events, Hardware, Logical, Monitoring, Security, Settings, Support) that can be scoped to one tenant - so a Tenant Admin manages their own tenant and nothing else, while Tenant Privacy Mode can hide a tenant's internals even from the cluster admin.
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 QoS 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. Crank Tenant B's demand, then toggle QoS. Without it, B steals throughput and starves its neighbors. With it, B's max cap contains it and A & C keep their guaranteed min floor.
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 since 5.0) 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.
Encryption at rest
AES-XTS-256, transparent. A data key (DEK) under a key-encryption key (KEK); internal or external KMS (KMIP / Vault).
Per-tenant keys
Encryption groups scoped per tenant. Honest trade-off: data reduction runs within a group, so per-tenant keys reduce cross-tenant dedup; one external KMS per cluster today.
Indestructible snapshots
Immutable, ransomware-proof snapshots whose deletion needs multi-factor challenge-response tokens from VAST Support - defeats rogue admins.
Audit per tenant
An AuditDB (built on VAST Database, queryable by SQL) plus per-CNode JSON for SIEM; tenant managers query their own records.
Some details (e.g. crypto-erase aligned to NIST SP 800-88) are vendor-stated; key rotation/revocation is a cluster-admin operation today.
Where this shows up
This is why VAST has become the storage of choice for 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 rare combination that makes shared AI infrastructure both safe and economical.