Table of Contents
What is Multi-tenancy?
Multi-tenancy is an architecture in which a single software application instance serves multiple customers, each called a tenant. A multi-tenant architecture allows several instances of an application to function in a shared environment. This design works because each tenant is physically integrated but logically independent. This means that a single instance of the software will run on one server and then serve multiple tenants.
Multi-tenancy in VMware NSX
Although Multi-tenancy was first introduced in NSX 4.0.1, it has been available at the data plane layer for several years. VMware NSX uses multi-tiered routing model with logical separation between the different gateways (tier-0 & tier-1) to provide networking connectivity, and these gateways, when deployed as per a specific design, provide isolation to user apps from each other.
For e.g, features like VRF, that allows for having a separate routing domain per tenant, or deploying Tier-1 gateways per application/environment (dev/test/prod) to achieve segmentation. But these features don’t cover every use case and have scalability limitations, it is not considered a true multi-tenancy solution.
Multi-tenancy feature in NSX 4.0.1 overcomes these challenges and offers networking and security services to multiple tenants that are completely isolated from each other. Access to networking constructs (t1 gateways, segments, etc) is controlled via RBAC policies and limits are enforced by assigning quotas to the objects that can be created inside a tenant.
Multi-tenancy and NSX Projects
Before the introduction of projects, the NSX platform had a single space known as the default space, where the NSX Enterprise Administrator owned all networking and security configurations. With the introduction of multi-tenancy, the Enterprise Admin (Provider) segments the NSX platform into defined spaces called Projects, where each project represents a logical container of network and security resources (tenant).
Each project has its own set of users, assigned privileges and quotas. The Enterprise Admin configures and manages security and networking settings for each project and ensures that each tenant has its own distinct network and security settings. The Enterprise Admin can also share logical resources from the default space to all tenants or a subset of tenants.
Each tenant has only access to the objects that they create in their project and those shared from the default space. Objects created by one tenant cannot be accessed by users in a different tenant.
NSX Multi-tenancy Architecture
Let’s understand NSX multi-tenancy architecture with the help of the below image.
NSX Multi-tenancy uses a two-tier data model under the hood, where the first tier is called Infra tier, which is referred to as the Default space. This is a provider-controlled space that contains non-isolated objects such as the tier-0 gateway, services, etc. The Enterprise Admin is the owner of this space. The Default space contains NSX objects that do not belong to any project, however, the provider can share objects from the default space to the tenants.
The second tier is referred to as the Org model under which tenants provision their resources. The objects are provisioned under a logical construct called project. The project admin user can assign resources to one or more users within a project.
And that’s it for this post. In the next post of this series, I will discuss the deployment models available in NSX Multitenancy. Stay Tuned!!!
I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing.
Pingback: NSX 4.2 Multitenancy Series – Part 2: Design Models
Pingback: NSX 4.2 Multitenancy Series – Part 6: NSX VPC Networking
Pingback: NSX 4.2 Multitenancy Series – Part 5: NSX Virtual Private Cloud (VPC) Overview
Pingback: NSX 4.2 Multitenancy Series – Part 7: Creating NSX VPC’s
Pingback: NSX 4.2 Multitenancy Series – Part 3: NSX Projects
Pingback: NSX 4.2 Multitenancy Series – Part 8: Resource Sharing in NSX VPC