About Tenants
A tenant can represent an organization, department, or project. Tenants are used to isolate the work of a particular user or group from the work of everyone else in the cluster. Tenants effectively divide a cluster into smaller clusters. A tenant contains both resources and users. The users that belong to a tenant may only access the resources that belong to that tenant.
Example scenario
An administrator creates a tenant named "Research Labs" and assigns two nodes to it: blade01 and blade02. The administrator also assigns the user Shakespeare to "Research Labs". Whenever Shakespeare creates a service, Moab Web Services ensures that service only runs on node blade01 or blade02. Moab Web Services does not allow that service to run on any other node. Also, if a user that does not belong to "Research Labs" creates a service, Moab Web Services prevents that service from running on blade01 or blade02.
There are only certain types of resources that can be assigned to a tenant:
- Nodes
- Services
- Service templates
All other resource types (such as reservations, images, and policies) are global. Global resources cannot be assigned to individual tenants and instead are shared or ignored by all tenants. In addition, permissions, roles, principals, and even tenants themselves are considered global resources. Global resources are managed outside of tenants by administrators who have been given permission via global roles. Only an administrator with the correct role(s) can access, create, modify, or delete global resources.
|
Image 4-2: Tenant-owned resources |
|
|
Click to enlarge |
Most use cases will not require more than one tenant. By default, upon installation or upgrade, Moab Web Services creates a placeholder tenant named "Organization". This tenant can be renamed and modified to suit the needs of single-tenant systems. Users and resources can be added to it.
Adaptive Computing recommends that those customers running Moab HPC Suite should not create more than a single tenant. To isolate the work of a particular user or group, first consider using administrative reservations.
Considerations for Using or Not Using Multi-Tenancy
Why use multi-tenancy?
Multi-tenancy isolates each tenant's services, jobs, and virtual machines from other tenants, which makes it impossible for a given tenant's work to run on the same nodes as other tenants' work.
Why not use multi-tenancy?
The following points out consequences of choosing multi-tenancy and alternatives to multi-tenancy:
- There are good alternatives. Administrative reservations isolate work. Another option is to create a physically separate cluster, which does require additional administration overhead, but it absolutely guarantees that work from the isolated department or project will not intermix.
- Multi-tenancy essentially divides a node cluster into two or more mini-clusters, which may impact scheduling efficiency.
- Adding multiple tenants makes it more difficult for an administrator to manage the cluster. Reproducing and debugging problems are thus more challenging, and role and user management are more complicated.
Next Steps
If you decide you don't need more than one tenant, please read the section on how to set up users and roles. If you decide you need more than one tenant, please see Modeling Your Organization with Tenants.
RBAC how-toRelated Topics