An additional design factor in the shared vCenter Server model is a scenario where the tenants are controlling their own IP addressing for their VMs, and therefore there is a chance that the tenants’ IP address ranges are going to overlap one another. If two tenants happen to use the same IP addressing to support this scenario, Network Address Translation (NAT) must be performed on each tenant’s ESG to translate the tenants’ IP addresses to uniquely accessible IP addresses.

In the following figure, each tenant has been assigned a unique IP address by the service provider within the range of its ESG’s uplink to ESG-AGGREGATION: Tenant1: 80.80.80.0/28 and Tenant2: 80.80.80.16/28.

If these are the publicly accessible IP addresses assigned to each tenant, which can be reached by its client on the internet, then the tenant will use this IP address range to publish its services to its client on the internet. As illustrated in the following graphic, each of the tenants has a web application running on the WEB VM that needs to be accessed by its client.

NAT must be performed by each tenant ESG. The NAT is essentially a DNAT (Destination NAT) that translates the destination IP address of incoming traffic to IP addresses of the WEB VM.

The orange portions of the following figure illustrate the DNAT on ESG-Tenant1 and the traffic flow when a client is accessing Tenant1’s web application.

The red portions of the graphic illustrate the DNAT on ESG-Tenant2 and the traffic flow when a client is accessing Tenant2’s web application.

Each tenant has its own ESG. Each ESG is predominantly employed to furnish north-south routing and provide a perimeter firewall for each tenant. Of course, other network services, such as load balancing, can also be activated on the ESG when needed by the tenants. Finally, each VM is fronted with a firewall at its vNIC. This firewall is provided by the distributed firewall (DFW) feature in NSX.

Network multitenancy through the use of NSX can be achieved in the design of your virtual network, within the shared vCenter Server architecture. The use of a distributed logical router (stand-alone or HA) and an NSX Edge gateway per tenant, together with the creation of a backbone network where the tenant network connects to an aggregation edge cluster (HA or ECMP) that then connects back to the outside network, can provide the network and network services isolation required for a multitenant vCenter Server architecture. In this example, the network policies reside on the edge gateway and the distributed logical router per tenant, giving tenants full control over their own network.

However, limitations in the role-based access control provided by NSX means that service design is critical, and the demarcation line of actions performed by the provider and tenant needs to be examined as part of the service design and delivery model.

A final consideration on the topic of NSX in a shared vCenter Server design is that these functions are enabled out-of-the-box when architecting a multitenant environment with vCloud Director for Service Providers, simplifying the architecture and operations and reducing time to market.