vSAN offers a storage layer for multitenanted environments, and is fully capable of offering shared storage to tenants. In this shared storage model, service providers can allow tenants to reside workloads across shared storage resources. The exact location of the tenants’ data on the vSAN enabled cluster cannot be specified with this model, because vSAN provides common storage resources within the Provider VDC only.

As a result of this architecture, in any multi-tenanted environment, where various different business entities are storing data across a common vSAN enabled cluster, tenant data is highly likely to be shared across all disk groups, with no way of creating tenant isolation. However, this does not differ significantly from the storage model employed with legacy shared storage systems. In the past it has not been uncommon for service providers to deliver dedicated storage to vCloud consumers by provisioning LUNs on a customer-by-customer basis. However, even in this model, it is highly likely that the actual tenant data is striped or mirrored across a common set of physical disks, as illustrated in the following figure.

 

However, in a vCloud Director environment, data being striped or mirrored across a common set of physical disks is not typically of concern to tenants or vCloud administrators. The reason for this is while a vSphere administrator can see the physical storage systems, including a vSAN datastore, these datastores are created through vCenter Server, which requires specific rights, rights that are not required by a vCloud administrator or vApp owner.

Therefore, even if the vCloud Director cell is configured with a user with rights to create new datastores, that privilege is not exposed to the provider system administrator or organization users. Instead, system administrators enable datastores, disable datastores, and assign datastores to organizations.

In addition, organization users, who create and upload vApps, simply store the VM VMDKs on the vSAN datastores assigned to the VDC, without any visibility of the back end disk system providing the resource.

For this reason, virtual machines can never see any storage outside of their VMDKs, unless they have network connectivity to other storage systems (such as NFS shares or CIFS). While this is not recommended; a service provider could give access to external storage for vApps as a network service, but it must be separate from the vSAN datastore assigned to the vSphere hosts backing the vCloud Director platform.

Likewise, vCloud users only see the storage policies backed by one or more of the vSAN datastores assigned to them, but even that view is limited to the vCloud Director abstraction layer, and they are therefore unable to browse the datastore. They only see what is published in catalogs or that which exists within vApps they manage.

Therefore, VMware Cloud Providers can only achieve storage resource isolation when employing vSAN in a vCloud Director environment by assigning dedicated PVDC resources per-tenant, which is not typically an efficient approach to resource management.

However, this approach does enable service providers to eliminate any risk of resource contention across tenant applications, while simultaneously providing the secure separation of user data. This approach might also provide advantages to service providers where performance and capacity requirements from the tenant are dynamic and encompass a wide range of application types.