For additional configuration flexibility, isolation, and the delegation of ADC administration, NSX Advanced Load Balancer supports the creation of a cloud inside a tenant.

Tenant-scoped clouds feature is currently restricted to Azure, Linux Server Clouds, and no-orchestrator clouds. Attempts to choose other cloud types result in an error code.

Refer to Orchestrator Access Modes for more information on no-orchestrator (no-access clouds), in which adding, removing, or modifying properties of a Service Engine requires an administrator’s manual intervention.

Features

  • Configuration Flexibility — Users with access as defined by the Tenant-Admin role can create/read/update/delete (CRUD) cloud infrastructure (VRF contexts, SE groups, and SEs) within their very own tenant, i.e., the one to which the cloud is scoped. In addition, tenant administrators can access and use the infrastructure of clouds in the admin tenant, based on tenant settings, as before. That is to say, if the infrastructure in an admin-tenant cloud is configured in provider mode, tenant administrators can use it. Their use of it is in addition to, and independent of any tenant-scoped clouds under their direct control.

    • Provider Mode — It is a configuration in which Service Engines are shared across tenants. In provider mode, all the cloud’s network resources remain in the admin tenant and cannot be moved. To configure VRF contexts and move port groups into them, the NSX Advanced Load Balancer user must have write privileges for the admin tenant.

  • Isolation — The tenant-scoped cloud and its associated objects (i.e., VRF context, SEs, SE groups) are only visible in the cloud’s tenant. They are not visible in other tenants or the admin tenant.

  • Administration — The admin user is authorized and responsible to perform the highest-level configuration operations, such as user creation and authorization, tenant creation, and all infrastructure associated with the admin tenant. However, the admin user may — and likely prefers to — delegate to tenant administrators the creation of clouds scoped to their respective tenants.

When creating a tenant-scoped cloud, NSX Advanced Load Balancer automatically:

  1. Creates two VRF contexts for the cloud in the particular tenant. One is assigned data-plane traffic and the other control-plane (management) traffic.

  2. Creates the first SE group for the cloud in this tenant (it will be named Default-Group).

  3. Changes default permissions to enable the user having the Tenant-Admin role to create and manage tenant-scoped clouds and associated objects.

NSX Advanced Load Balancer UI Tenant-Scoped Cloud Creation

  • The admin user logged in, clicked the icon in the top right of the toolbar to display the complete list of defined tenants, and selected app_tenant_1 from that list. The purpose of the administrator is to switch context to that tenant.

  • The new tenant context is displayed by the text admin (app_tenant_1) to the left of the icon in the top right of the toolbar. Note, the admin user is still logged in; only the tenant context has changed.

  • After navigating to Infrastructure > Clouds, the admin user clicked the green Create button. Subsequently, a click on the Microsoft Azure button indicates that the user intends to create the descriptively named cloud admin-created-azure-cloud-for-tenant-1 on behalf of its users.

Note:

The admin user doesn't need to create the cloud within the tenant. This example has been given merely to show that such a courtesy may be offered.

  • From this point forward, cloud creation can proceed as normal. What follows is the more typical scenario. User appl1, the tenant administrator of app_tenant_1 has logged in. As expected,no other tenants will be listed when appl1 clicks on the icon in the upper right corner of the screen. Being restricted to one tenant is what is normally desired.

  • The appl1 user can opt to create a Linux server cloud with the app_tenant_1 tenant.

Note:

As before, the steps to create a cloud are no different from clouds that are not a tenant-scoped. It all depends on the tenant context of the user.