Introduction

Quota service while allowing for scalability will make sure that the cloud is not exploited by attacks, careless use and program errors. To address this problem, we propose to employ a quota-enforcement service that allows resource usage within certain bounds as defined by policies and available quotas for various entities. 

Quota service extends the functionality of usage server to provide a measurement for the resources used by the accounts and domains using a common unit referred to as cloud currency in this document. It can be configured to ensure that your usage won’t exceed the budget allocated to accounts/domain in cloud currency.

It will let user know how much of the cloud resources he is using. It will help the cloud admins, if they want, to ensure that a user does not go beyond his allocated quota. Per usage cycle if a account is found to be exceeding its quota then it is locked. Locking an account means that it will not be able to initiat

e a new resource allocation request, whether it is more storage or an additional ip. Needless to say quota service as well as any action on the account is configurable.

Use Cases

1. Mapping of cloud resources to a single unit of cloud currency.
2. Assigning of quotas in terms of cloud currency to the accounts.
3. View by domain/account of the use in cloud currency.
4. To block new demands based on  reaching 100% of the quota assigned in terms of cloud currency 
1.  On exhausting the credits the account or all the accounts in a domain will be locked so that no new request for resources can be made.
2.  A method to add more credits and unlock account/domain
3.  A method to remove credits and disable accounts 
5. To send an alert by e-mail to the domain administrator/consumption account of the budget, e.g.: 80% and 90%; and issue monthly expenses report in terms of cloud currency.

Design Description

 The implementation will be using usage server as the one providing the measurement. In addition to measurement (as done by usage server) mapping to cloud currency, generation of statement in terms of a cloud currency( common denominator) and control will be added by the quota service. Quota service will also provide configuration of cloud currency symbols so that the statements are more readable. 

1. This section describes the parameters that will be used to configure the quota service. Some of these parameters are already there. All these usage/quota related variables can be listed as a group and selected under the Global Settings page.
1.  Already existing global variables to configure usage server
1.  enable.usage.server: existing: Whether the usage server is active
2.  usage.stats.job.exec.time: existing: Time when the usage server processing will start
3.  usage.execution.timezone : existing: Timezone for usage.stats.job.exec.time
4.  usage.stats.job.aggregation.range: existing: time zone for usage records
2.  Additional global parameters to configure the quota service
1. quota.enable.service: Enable quota service by default all of this functionality is disabled. 
2. quota.period.type : Quota period type: 1 for every x days, 2 for certain day of the month, 3 for yearly on activation day - default usage reporting cycle. [ Unimplemented: period type is calendar month ]
3.  quota.period.config : The value for the above quota period type  [ Unimplemented: period type is calendar month ]
4. quota.period.type : Values correspond to bimonthly=1, monthly=2, quarterly=3, half yearly=4 and annually=5.
5.  quota.activity.generate : Set “Y” to enable a detailed log of the quota usage, rating and billing activity, on daily basis. Valid values (“Y”, “N”); [ Unimplemented: Can be part of next set of changes ]
6.  quota.email.outgoing.record: Boolean, yes means all the emails sent out will be stored in local DB, by default it is no. [ Unimplemented: Can be part of next set of changes, nice to have the records. ]
7.  quota.enable.enforcement :  Enable the usage quota enforcement, i.e. on true exceeding quota the respective account will be locked.
8.  quota.currency.symbol :  The symbol for the currency in use to measure usage.
9.  quota.limit.critical:  A percentage limit for quota when it is reached user is sent and alert. [ Unimplemented: The functionality to provide critical limit is per account ]
10.  quota.limit.incremental:  A percentage incremental limit that is added to criticalLimit in this increments, when breached a email is send to the user with details. [ Unimplemented: The functionality to provide critical limit is per account ]
3.  Variables for setting up auto emailer 
1.  quota.usage.smtp.host : SMTP host for sending emails
2.  quota.usage.smtp.connection.timeout: SMTP server timeout
3.  quota.usage.smtp.user: 
4.  quota.usage.smtp.password
5.  quota.usage.smtp.port
6.  quota.usage.smtp.useAuth
2.  This section describes the quota related policies in terms of fair use and limits. Most of this configuration already exists. 
1.  Global limits, these already exists in cloudstack and are measured per account by usage server. These will form the foundation of resources that quota service will manage. APPENDIX A.
2. APPENDIX B list down various limits that are set at various levels to ensure fair usage of resources across accounts. These settings already exists.
3.  In section 1. and 2. we described the basic configuration and policy guidelines for resource usage. To enforce a quota for accounts and domains we should be able to map various resource usage to a common cloud currency, so that it is easier to manage the quotas for various accounts. In cloudstack each resource comes with a unit of its own like a running vm resource is measured in terms of time while the storage is measured in terms of space measure in MB or GB. This API will let the operator map the resource usage unit to a common currency. We will refer this currency to cloud currency. Configure the mapping for resource, units and price

1.  Following resources are measured by usage server and managed by quota service

   Usage Type	Usage generated In	Predefined Scales	Descriminator	Cloud Currency	Description
   RUNNING_VM	Compute-Hours	Compute-Days	HA Enabled Guest OS ISO Image	x1	Tracks the total running time of a VM per usage record period.
   ALLOCATED_VM	Compute-Hours	Compute-Days	HA Enabled Guest OS ISO Image	x2	Tracks the total time the VM has been created to the time when it has been destroyed.
   IP_ADDRESS	IP-Hours	IP-Days IP-Months		x3	Tracks the public IP address owned by the account.
   NETWORK_BYTES_SENT	Bytes	GB TB	Redundant Router VLAN Enabled Network Type	x4	Tracks the total number of bytes sent by all the VMs for an account.
   NETWORK_BYTES_RECEIVED	Bytes	GB TB	Redundant Router VLAN Enabled Network Type	x4	Tracks the total number of bytes received by all the VMs for an account.
   VOLUME	Byte-Hours	GB-Months TB-Months GB-Days RB-Days	Pool Type Volume Tag	x6	Tracks the total time a disk volume has been created to the time when it has been destroyed.
   TEMPLATE	Byte-Hours	GB-Months TB-Months GB-Days RB-Days		x7	Tracks the total time a template (either created from a snapshot or uploaded to the cloud) has been created to the time it has been destroyed. The size of the template is also returned.
   ISO	Byte-Hours	GB-Months TB-Months GB-Days RB-Days		x8	Tracks the total time an ISO has been uploaded to the time it has been removed from the cloud. The size of the ISO is also returned.
   SNAPSHOT	Byte-Hours	GB-Months TB-Months GB-Days RB-Days		x9	Tracks the total time from when a snapshot has been created to the time it have been destroyed.
   LOAD_BALANCER_POLICY	Policy-Hours	Rule-Hours Rule-Months		x10	Tracks the total time a load balancer policy has been created to the time it has been removed.
   PORT_FORWARDING_RULE	Policy-Hours	Rule-Hours Rule-Months		x11	Tracks the time from when a port forwarding rule was created until the time it was removed.
   NETWORK_OFFERING	Policy-Hours	Policy-DAYS Policy-MONTHS		x12	The time from when a network offering was assigned to a VM until it is removed.
   VPN_USERS	VPN-Hours	VPN-Days VPN-Months		x13	The time from when a VPN user is created until it is removed.

2.  Price is provided in Cloud currency. The scale and ratios are defined by the operator. The operator can decide how much a single GB of secondary storage costs in terms of cloud currency. Compared to how much an ip will cost in the same currency.
3.  A new method is added to cloudstack API to map the resource scale and corresponding currency costs. This method is called quotaMapResourcesToCurrency().
4. A configuration for cloud currency representation will be provided so that the quota statements are readable. 
   1. quota.currency.symbol: This variable will point to the index of selected currency of the quota_currency_symbols table.
5. A new account state "nocredit" is introduced that signals that there is no quota for an account. The login for the account is disabled and appropriate message is flagged to the user. Cloudstack as of now has not API classification that classify a resource request vs a plain operation request. This is the reason locking account due to "nocredit" is the most feasible option. There is still a bit of discrepancy where in the sense a "nocredit" account will still be consuming resources in terms of a running VM or stored snapshots. He can though send an email to admin requesting more credits or removal of his account. Deletion of an account is already provided by cloudstack.
4.  API to get statement:  quotaStatement(startData, endDate, resourceName, accountId, domainId). This will return a map that contains
1.  Usage of given or all resource for a given period
2.  Remaining Cloud currency credits available 
3. The UI should let user browse thru his past quota statements
5.  An admin API to Credit/Debit Cloud currency to a account
1.  Credit and enable the account if disabled due to lack of credits
2.  Debit Cloud currency and disable the account if no Cloud currency is available
6.  An API to customise various email templates that are available in with the quota service.
1.  Email template to update/alert user when the quota usage reaches a critical limit and then when it hits incremental limits.
2.  A Email to alert that the account has exceeded the quota and will is not locked.
3. Billing email for billing period
7. The tariff changes can be scheduled in future.

Quota Plugin 

Database changes

1. quota_configuration : This is the global mapping of currency to the resources identified in section 3.
2. quota_consumption : table to define quotas for various users. This table will be updated on adding or using up the quotas.  This table will also keep a record of accounts that are locked and have run out of their allocated quotas
3. quota_email_templates: A list of customisable email templates used to send emails
4. quota_email_sent: A record of emails that is sent to the users.
5. quota_currency_symbols: List of various real currencies that are there.

UI Changes

  The quota UI is representational, will be implemented as a UI plugin.

1.  Global Settings for configuring quota service

 image

 2.  Global settings for quota mapping for various usage items

 image

Third column above (label.quota.value) mapping to the cloud currency. The root admin can edit these values. By default it will be 0 for all mappings.

3. For each account and domain there will be an additional UI to see the current quotas and to get the current quota statement. This will become part of account and domain UI.

  a. Quota button on accounts tab:

        image

  b. Sample Quota Statement

       image

4. A locked account due to quota

 image

APPENDIX A

Global limits, these already exists in cloudstack and are measured per account by usage server. These will form the foundation of resources that quota service will manage.

1.  max.account.public.ips: Number of public IP addresses that can be owned by an account
2.  max.account.snapshots: Number of snapshots that can exist for an account
3.  max.account.templates: Number of templates that can exist for an account
4.  max.account.user.vms: Number of virtual machine instances that can exist for an account
5.  max.account.volumes: Number of disk volumes that can exist for an account
6.  max.template.iso.size: Maximum size for a downloaded template or ISO in GB
7.  max.volume.size.gb: Maximum size for a volume in GB
8.  network.throttling.rate: Default data transfer rate in megabits per second allowed per user (supported on XenServer)
9.  snapshot.max.hourly: Maximum recurring hourly snapshots to be retained for a volume. If the limit is reached, early snapshots from the start of the hour are deleted so that newer ones can be saved. This limit does not apply to manual snapshots. If set to 0, recurring hourly snapshots can not be scheduled
10.  snapshot.max.daily: Maximum recurring daily snapshots to be retained for a volume. If the limit is reached, snapshots from the start of the day are deleted so that newer ones can be saved. This limit does not apply to manual snapshots. If set to 0, recurring daily snapshots can not be scheduled
11.  snapshot.max.weekly: Maximum recurring weekly snapshots to be retained for a volume. If the limit is reached, snapshots from the beginning of the week are deleted so that newer ones can be saved. This limit does not apply to manual snapshots. If set to 0, recurring weekly snapshots can not be scheduled
12.  snapshot.max.monthly: Maximum recurring monthly snapshots to be retained for a volume. If the limit is reached, snapshots from the beginning of the month are deleted so that newer ones can be saved. This limit does not apply to manual snapshots. If set to 0, recurring monthly snapshots can not be scheduled.

APPENDIX B

  Following are various limits specified at various level to keep resource usage in check:

1.  Limit resource usage
1.  max.account.cpus :   Maximum number of CPU cores that can be used for an account. Default is 40.
2.  max.account.ram:  Maximum RAM that can be used for an account. Default is 40960MB
3.  max.account.primary.storage: Maximum primary storage space that can be used for an account. Default is 200GB.
4.  max.account.secondary.storage: Maximum secondary storage space that can be used for an account. Default is 400GB.
5.  max.project.cpus: Maximum number of CPU cores that can be used for an account. Default is 40.
6.  max.project.ram: Maximum RAM that can be used for an account. Default is 40960MB.
7.  max.project.primary.storage : Maximum primary storage space that can be used for an account. Default is 200GB.
8.  max.project.secondary.storage: Maximum secondary storage space that can be used for an account. Default is 400GB.
2.  Some of these limits can additionally be configured at account level
1.  Instance limits: Default 20
2.  Public ip limit: 20
3.  Volume limits: 20
4.  Snapshot limits: 20
5.  Template limits: 20
6.  VPC limits: 20
7.  CPU limits: 40
8.  Memory limits: 40960 MB
9.  PS limits: 200GB
10.  SS limits: 400GB
3.  Domain level configurable limits
1.  Instance limits: 
2.  Public ip limit: 
3.  Volume limits: 
4.  Snapshot limits: 
5.  Template limits: 
6.  VPC limits:
7.  CPU limits:
8.  Memory limits:
9.  PS limits: 
10.  SS limits:

REF: Usage: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Usage+and+Usage+Events

Accounts: https://kb.leaseweb.com/display/KB/Accounts%3A+CloudStack

Domains: https://kb.leaseweb.com/display/KB/Domains%3A+CloudStack

Projects: https://kb.leaseweb.com/display/KB/Projects%3A+CloudStack

Usage limits: http://cloudstack-administration.readthedocs.org/en/latest/usage.html