An organization is a group of consumers with a common business purpose — for example, your development group, or one of your customers. Organizations, the fundamental building blocks of Commander multi-tenancy, enable you to:
- Segregate and secure data for your consumer groups.
- Delegate administrative tasks to consumers.
- Set up distinct cloud automation configurations for your consumer groups.
- Generate reports for each organization.
Whether you're a service provider or an enterprise with multiple stakeholders, you need to segregate data for the various groups of users that consume your IT services. Data segregation provides enhanced security, easier management and cost savings. In the multi-tenant Commander model, the entire service request process is unique to each organization.
Quotas allow you to limit the compute resources or limit the daily costs for an organization so that you can assign available resources to your consumer groups based on their business requirements.
You can configure one of the following types of quota for each organization:
- Resource-based quota, which enables you to limit the number of vCPUs, the amount of RAM and the amount of storage. You can set both global and per-tier storage quota, as shown in the image below.
- Cost-based quota, which enables you to limit the total daily cost of VMs.
- Per-destination quota, which enables you to configure distinct quota limits for each deployment destination available to a user or organization. For more information about deployment destinations, see Configure Automated Deployment for Approved Service Requests.
When configuring an organization, administrators can select the currency for all cost quotas for the organization. Admin Portal users will see quota information in the currency that was selected when the organization was configured.
Users in a Service Portal role with Manage Organization permission can manage this organization by adding and editing user's quotas for this organization. When managing quotas, they’ll see the currency selected for the organization. All Service Portal users will see Quota Usage on the Dashboard and quota warnings in their preferred currency.
Design considerations
How many organizations do you need? Think about your requirements for data segregation, reporting by organization, controlling the visibility of the service catalog and request forms, and delegating administrative tasks.
Before you configure quotas, you have a few decisions to make:
- Will you set a global quota for the entire organization, or will you set limits for each destination where an organization can deploy services? You can configure a different type of quota for each destination. This is useful when you have different costs and resource constraints for different workload types, such as development compared with production.
- Will you set a resource quota or a cost quota? Resource-based quotas allow you to limit the number of vCPUs, the amount of RAM and the amount of storage. Cost-based quotas allow you to limit the total daily cost of VMs. When you choose per-destination quota, you can configure a different type of quota for each destination.
- If you're setting a resource quota, will you set quota limits for individual storage tiers?
- Will you set quota limits for the organization as a whole, individual members, or both?
- Do you need a quota-based approval process?
Best practices
Your team structure and the layout of your cloud infrastructure will determine how assets such as service catalog entries and deployment destinations are exposed to users.
If you're a service provider, you likely sell a block of resources to each customer; you can configure quota limits to alert your sales team that an organization requires additional resources. For enterprise customers, enable your development team to achieve rapid provisioning without an approval process, while ensuring that they stay within their quota limit.
Examples
If you want to limit the resources for an organization to 20 CPUs, 80 GB of memory and 200 GB of storage, and if your organization currently has four members, you can:
- Set identical quotas for each member. Each member is limited to 5 CPUs, 20 GB of memory and 50 GB of storage.
- Set individual quotas for each member. One member is allowed up to 8 CPUs, and the other 3 are limited to 4 CPUs each.
- Allow each member to consume up to the maximum available quota for the organization, by not setting member quotas. If two members have used up all 20 CPUs, the other members won't have available quota.
As another example, if you use one storage tier for swap space, you can exclude this tier from storage quota calculations, while setting per-tier quota limits for your other storage tiers.
If you're using per-destination quota, for a single organization, you can set distinct resource quota limits for each destination. Or, you can set a cost quota for the Production destination, a resource quota for Staging and Development, and no quota limit for Lab.
Per-destination quotas can be useful for such scenarios as cloud-bursting: if an organization exceeds its quota on its private cloud destinations, then Commander can deploy to a public cloud destination instead. See Configure Placement Attributes to learn how to configure this type of scenario.
