A job that waits on data still holds the accelerators your tenant is paying for. Genesis Grid gives you block, object and file as three distinct services — Ceph RBD, Ceph RGW and VAST — behind one API, one identity model and one meter. Your tenants see one storage product; you operate three engines that are each good at their own job.
Tenant separation in storage is namespaces in Ceph and VAST, with per-tenant credentials and per-tenant quotas. That is the mechanism and it is the whole mechanism: there is no per-tenant encryption key and no wipe on release, and your security team should hear that from us rather than find it later.
Capacity, throughput and IOPS ceilings are enforced per tenant. One tenant's checkpoint storm cannot eat the headroom the others contracted for, which is what lets you sell a number instead of a hope.
Every volume, bucket and share belongs to the cluster it was created in. There is no cross-site pool and no background replication, so a copy into another jurisdiction is an explicit, logged operation your tenant asked for.
Your licence does not grow because a tenant moved a dataset. The meter records every byte per tenant and per direction, so you decide whether egress is billed, capped, or the thing that wins you the deal.
Throughput is measured on your arrays and your fabric before it enters a service level, because it depends on both. One of these is history rather than a promise: the VAST estate Genesis integrated while it was still the operator.
of VAST Genesis integrated behind this interface on the estate it ran
aggregate read throughput from the storage layer to one training cluster
control plane, portal and metering downtime during a platform upgrade
Three systems. Ceph RBD serves block, Ceph RGW serves S3-compatible object, VAST serves POSIX file. They share an API, an identity model and a meter, not a pool of drives. Anyone who offers you one pool that serves all three well has not operated one.
.svg){kind=small}
Namespaces in Ceph and VAST, per-tenant credentials, per-tenant quotas. Nothing beyond that: data is not encrypted with a key bound to the tenant, and capacity is not wiped on release. If a buyer of yours requires either, that is a hardware and key-management answer you provide, not a claim we make for the stack.
Not for block and object — Ceph runs across the drives in the nodes you already bought. File is the exception: the POSIX service is VAST, so if you intend to sell high-throughput shared file, that hardware is a real dependency and belongs in your build budget.
You do. You run the services and you hold the pager; Genesis carries escalation when the fault is in the stack.
It runs through the same meter. Every tenant's block, object and file usage lands in the same rating and billing export as their accelerator hours, so you issue one invoice and reconcile one set of records.
