For modern networks, sharing network resources is a primary requirement. Multi-tenancy allows communication service providers (CSPs) to compose different services for different customers from the same infrastructure. It is all about sharing the infrastructure in the data center to increase efficiency and flexibility.
A multi-tenant architecture is based on central administration and involves a common code application and operating common instance(s) of applications for multiple tenants. In addition, it also secures confidential data for each tenant from others.
Why is multi-tenancy important?
Multi-tenancy is important when we want to share network resources—like hardware (e.g., server, storage, networking), software or services—among parties.
What happens if we do not follow multi-tenant approach? If the CSP cannot maintain multiple infrastructure locations, there will be maintenance complexity (increased OPEX) and the CSPs end up spending too much on each tenant (increased CAPEX).
How does multi-tenancy work?
The picture below displays a virtualized server and a hypervisor that shares the CPU and memory with multiple customers. Virtual machines (VMs) from different customers are deployed on the hypervisor with proper orchestration. With this approach, the CSP achieves the optimum utilization of the server’s resources (i.e., CPU/RAM) and reduces the organization’s CAPEX and OPEX obligations.
Multi-tenancy for CSPs
So, how do CSPs manage the demand for resource isolation when it comes for network functions from different vendors? CSPs require a solution that isolates the resources in a shared environment.
In the below example, let us assume customer X and Customer Y are sharing the resources simultaneously and no two tenants can access each other’s infrastructure by default.
In this scenario, Customer X will use its VNF-Manager to deploy the network functions without intervention of the data center’s admin. Notice the VIM layer is in between VNF manager and SDDC–dictating how the network, compute and storage resources can be shared in the common environment. In this structure, multi-tenancy provides the flexibility and reliability to the users.
In another instance, let’s say Customer Y wants to isolate the resources between the network functions based on the demand of the network functions. In this case, the CSP can go with tenant creation as per the requirements of the network function.
Multi-Tenancy with VMware Cloud Director
Though we have multiple products and solutions to create multi-tenancy, let’s analyze how VMware Cloud Director assists multi-tenancy.
First, we need to understand the artifacts of VMware Cloud Director to realize the outcome. VMware Cloud Director provides multi-tenancy with the entity called “Organization” and represents a single logical security unit. A vCloud Director organization typically maps to a vendor or a VNF. Importantly, CSPs can use local accounts or distributed directory service accounts for user authentication via LDAP.
In the figure below, the physical resources are configured with two different clusters (one for each vendor) and the cluster settings are applied based on vendor requirements. Each cluster is prepared with VMware Cloud Director’s pVDC (Provider Virtual Data Center) and each pVDC is associated to respective tenants.
vCloud Director organization manages the authentication and authorization along with roles for the tenant users, so the users will access their tenant portal during network function lifecycle management.
When it comes to resource allocation, an organization can consist of one or more OrgVDCs (Organization Virtual Data Center), The resources for OrgVDC will be allocated from pVDC and the respective resources pool will be created on vCenter. As depicted in Figure 3 above, we highlight this end-to-end resources allocation.
Multi-Tenancy with VMware Integrated OpenStack
VMware Integrated OpenStack (open source version of VMware Telco Cloud Infrastructure) provides multi-tenancy with the entity called “Projects.” Projects in VMware Integrated OpenStack are equal to tenants in VMware Telco Cloud Infrastructure. A project is the administrative container where telco workloads are deployed and managed.
A Tenant VDC allows creation of virtual data centers for tenants under different compute nodes that offer specific SLA levels for each telco workload. While quotas on projects set limits on the OpenStack resources, Tenant VDCs provide resource guarantees for tenants and avoid noisy neighbor scenarios in a multi-tenant environment.
Figure 4 above illustrates how a fully integrated VMware Integrated OpenStack Compute Zone, Project and Tenant vDC, NSX-T segments, and Tier-1 gateways can be leveraged to provide a multi-tenant environment for deploying VNFs in VMware Integrated OpenStack.
Multi-Tenancy with NSX-T:
CSPs and their tenants are not only focused on resource allocation and authentication, but they are also concerned about network security and network resource utilization. To address this, NSX-T provides proper isolation for SDN (Software Defined Networking) solutions. Isolation of East – West tenant traffic, for instance, is done using the T1 routers in the NSX-T and North-South tenant traffic can be isolated with T0 routers using VRF-Lite feature.
Let’s analyze VRF-Lite a bit further. VRF-Lite provides multiple VRF gateways, with each tenant using the dedicated VRF. Additional benefits of VRF-Lite include isolation of tenants with a single Tier-0 and overcoming network overlapping.
In the below example, Tenant 1 will send East-West traffic through Edge Gateway (EGW) of vCD where it is connected to T1 (Blue) of NSX-T. Similarly, the other T1 router (purple) will be used for Tenant 2.
North-South traffic will be handled differently. T0 has the capability to host multiple VRF instances using VRF-Lite feature in NSX-T. Each VRF-Lite is dedicated to a tenant. In this way, a single T0 can be used for multiple tenants to provide traffic isolation in North – South scenarios.
Multi-Tenancy with vCD & VMware Telco Cloud Automation
The virtual infrastructure is the key component in Telco Cloud Automation to achieving multi-tenancy. vCD with multiple tenants will be integrated with Telco Cloud Automation’s control plane and virtual infrastructure will be created for each tenant in the TCA-Manager.
The above diagram illustrates how vCD integrates with TCA-CP (Telco Cloud Automation – Control Plane) using a system administrator account, and each tenant (VCD – Organization) is prepared as virtual infrastructure in TCA-Manager using the Organization Administrator account.
The user accounts for the NF operator are created in Telco Cloud Automation’s SSO and the roles will get assigned to their respective virtual end point (e.g., VCD-Customer-X and VCD-Customer-Y). In this scenario, each tenant’s users will access the TCA-Manager and execute NF lifecycle operation (i.e., onboard, instantiate, scale and terminate) within their virtual infrastructure (e.g., VCD-Customer-X & VCD-Customer-Y) and Telco Cloud Automation will perform the action (i.e., vAPP creation, modification and deletion) on vCD.
Conclusion
Multi tenancy is solving one of the major need of the Telco industry – i.e CAPEX. Where multiple vendors are using same resources with strict isolation on the hardware resource level. Hope this blog is helps to start the learnings on the multi tenancy and show the path to explore multiple options in multi tenancy.
