The concept of vCenter Server multitenancy is self-explanatory. In its simplest form, multitenancy is the architectural model that optimizes resource sharing, while providing sufficient levels of isolation to the individual tenants, maintaining the agreed upon Quality of Service (QoS) throughout the shared environment.

While most in the industry understand the basic economics of providing a secure multitenancy environment using VMware products, increases in compliance and security requirements are driving service providers and tenants to require more than isolation as a prerequisite for doing business. However, to take advantage of the shared vCenter Server model, illustrated in the following figure, service providers must be able to support multiple tenants within the same physical infrastructure without the tenant being aware of any co-resident. The separation between tenants must be comprehensive, complete, and provide mechanisms for management, reporting, and alerting.

This vCenter Server model (illustrated here) uses a layered approach with security controls, isolation mechanisms, and monitoring controls embedded in the network, compute, and storage layers of the service stack. This layered approach provides secure access to the hosts, guarantees resources to tenants, and provides abstraction to the physical components. The VMware software-defined solutions at different layers allow the infrastructure to provide isolation of resources without dedicating a vCenter Server management platform on a per-tenant basis.

This design example uses three tenants. All tenants share the same vCenter Server system, while each tenant has its own virtual compute, network, and storage resources. Resources are allocated for each tenant based on their business model, requirements, and priorities. Traffic between tenants is restricted, separated, and protected through the design of the environment.

The flexibility offered by these vCenter Server based service offerings helps address the challenges facing service providers, including rapidly changing IT landscapes, cost reduction pressures, and focus on time to market.

This type of service offering (shown in the preceding figure) can often be delivered through an IT as a service (ITaaS) model. The ITaaS cloud-computing models, which have been developed by many VMware Cloud Providers to address particular customer use cases, offer a new level of automation and security to successfully achieve application stack autonomy and customer business objectives. ITaaS offers compute resources, operating systems, networking, and storage to client environments. With ITaaS, tenants are typically responsible for all operations and administration, and for configuration of their environment beyond the baseline deployment.

In addition, many VMware Cloud Providers are developing cloud service offerings for public and internal tenant applications, regardless of whether the focus is on public or private cloud services. Typically, these pursuits focus on the following objectives:

Achieving these goals can have a profound, positive impact on profitability, productivity, and product quality. However, leveraging a shared vCenter Server system or shared infrastructure model in a cloud services architecture introduces additional challenges, hindering widespread adoption where end tenants demand a securely isolated application or environment and require a highly flexible management platform.

vSphere with vCenter Server provides secure separation through the inherent security of its own internal software architecture and the capabilities it provides to logically segment tenant assets and resources through its management interfaces. In the shared vCenter Server model, sharing vSphere hosts among tenants is inherently challenging at a number of different levels. If the service provider’s end goal is to maximize resource utilization through the sharing of host resources across tenants, VMware vCloud Director® for Service Providers is the primary design option. vCloud Director and the additional layer of abstraction it offers to facilitate the sharing of host resources while achieving secure multitenancy is described in Section 8, VMware vCloud Director for Service Providers.

In the architecture illustrated in Figure 7, the construct most commonly adopted VMware Cloud Providers, for the sharing of a vCenter Server platform, is the use of the logical data center object within the vCenter Server inventory. For the segmentation and isolation of tenants, this is the primary design choice for a number of reasons.

Unlike a folder, which is used to organize a specific object type, the data center object is an aggregation of all the different types of objects needed to do work in the virtual infrastructure: hosts, virtual machines, networks, and datastores. The data center defines the namespace for networks and datastores, and the names for these objects must be unique within a data center. For example, you cannot have two datastores with the same name within a single data center, but you can have two datastores with the same name in two different data centers. Virtual machines, templates, and clusters need not be unique within the data center, but must be unique within their folder. In addition, the data center object in vCenter Server creates artificial limits on the operational abilities of the tenants.

There are also several other reasons to use the data center object in a shared vCenter Server design over folders. For instance, while a folder object can contain sub-objects, because the physical hosts are dedicated to the tenant, these sub-objects are best placed within a data center object. The reason for this is, if you switch views in the vSphere Web Client to the Storage View, you will see datastores and datastore clusters contained within the data center. You can create folders in vCenter Server, but they are restricted to that view. Likewise, if you switch to the Networking View, data centers are the containers used for VMware vSphere Distributed Switch™ instances and port groups.

The preference for the data center object over the use of folders becomes obvious when you understand where the network and storage boundaries are (and by association, host boundaries). If you elect to only use folders, the design must include far more complex operational processes to prevent problems, and verify that secure multitenancy is maintained. Therefore, the design recommendation is to use the data center objects for tenant isolation purposes.

As a result of this key design factor, a shared vCenter Server model requires a number of characteristics and design specifications, which are outlined as follows: