Modeling Your Organization with Tenants
The contents of this page apply to Cloud and CSA environments only; this content is not useful for modeling an HPC environment with tenants.
Context
The multi-tenancy model allows you to discretely control who has access to which resources. Usage of tenants is designed to subdivide your data center for such things as security and hardware ownership purposes. With tenants, you can allocate workload (services and VMs) and nodes that are available only to users assigned to a tenant.
The steps on this page explain how to organize your system of tenants and permissions.
|
Image 4-3: Multi-tenant model |
|
|
Click to enlarge |
Creating subsections of nodes within a data center can have an impact on performance. The more tenants that are created, the greater the likelihood of impacting performance expectations.
To model your organization with tenants
- Identify the tenants needed in your system. Tenants are groups of people collaborating across a common set of resources. They can represent a project, organization, or other type of group.
Tenant resources are not shared, but users can belong to multiple tenants.
- Identify the principals for each tenant and which roles will apply to those principals. Principals are one or more users—authenticated via LDAP and mapped to an LDAP user, group, or OU—who obtain access to the tenant's resources by being assigned one or more roles. In a cloud environment, the standard roles are Administrator, PowerUser, and User. Principals with the Administrator role have global privileges and access to all resources regardless of which tenants they belong to. Principals with the PowerUser and User roles have tenant privileges and can only access their assigned tenants' resources. A principal must be assigned to a single tenant, but a user or group may be assigned to multiple principals. This allows users to be assigned to multiple tenants, if desired. For more information about default and custom roles in cloud, HPC, and CSA environments, see About Role-Based Access Control.
Fewer roles with minimal role overlap among principals is recommended.
- Identify the nodes that each tenant will own, noting that a node can only be assigned to one tenant. Services created by a tenant's principals will run exclusively on nodes assigned to that tenant. Principals attached to the tenant that have the appropriate privileges may view and manage the nodes assigned to the tenant.
Nodes are not required to be assigned to a tenant. Nodes that are not owned by a tenant are considered "tenantless" and can only be managed by principals with the Administrator role who therefore have global privileges. Unassigned nodes will not be used for placing or migrating services. In a single-tenant model, nodes are automatically assigned to the tenant.
- Optionally (if applicable) identify services that should be migrated to the new tenant. Existing services may be re-assigned to the new tenant. Any container service can be migrated to any tenant if the current user has either the update service privilege for both the old and new tenants or the global update service privilege. Migrating a container service moves the service, its child services, and any associated jobs, VMs, and PMs to the new tenant. Once it has been migrated, only users from that tenant and users with global rights will be able to access the service, its child services, and the associated jobs, VMs, or PMs.
Services can be migrated to any tenant regardless of whether the new tenant has the necessary resources for running the service and its associated jobs. If the new tenant does not have the necessary resources, the service and associated jobs update to show they are moved, but the jobs, VMs, and PMs do not actually migrate and continue running on the old tenant's node(s). In such a case, Moab raises an event to alert the administrator.
- Optionally (if applicable) identify service templates that should be copied to the new tenant. Service templates may be copied from tenant to tenant, and copying a container service template recursively copies all included service templates.
Related Topics