A quick look at using Quota on the Oracle Cloud Machine

Introduction

On OCM racks prior to version 17.1.6 they have the option to place a quota limitation on their tenancies.  Without a quota the tenant is able to use compute resources up to the physical limits of the rack that has been subscribed to.  It may be appropriate to limit the resource that one tenancy can utilise, this can be achieved using the quota object which is assigned to each tenancy.

There are a number of resources that can be limited on a per-tenant basis, these are.

• Compute
• Instances
• Memory
• CPUs
• Instance Restrictions
• Storage
• Machine Image
• Number
• Megabytes
• Network
• IP reservations

Figure 1 shows an example listing of a quota that has been applied to a tenancy.   It shows both the quota limits set and what the current usage is so it becomes a fairly simple task to work out how close to the current quota the tenancy is getting.

# oc list quota -u /quota-test/administrator /quota-test -f json {  "list": [   {    "usage": {     "machineimage": {      "number": 1,      "megabytes": 2466     },     "vnet": {      "vnetreservations": 0     },     "compute": {      "instances": 7,      "ram": 24576,      "instance_restrictions": {},      "cpus": 6.0     },     "nds": {      "megabytes": 0     }    },    "uri": "https://api/quota/quota-test",    "description": "Default quota for \"quota-test\"",    "name": "/quota-test",    "allowance": {     "machineimage": {      "number": 2,      "megabytes": 4096     },     "vnet": {      "vnetreservations": 2     },     "compute": {      "instances": 8,      "ram": 41000,      "instance_restrictions": {},      "cpus": 6.0     },     "nds": {      "megabytes": 4096     }    }   }  ] }

Figure 1 - Example quota output

In general these are fairly self explanatory as to what each restriction will do but there are some subtlties.

Compute

The restrictions for compute are split into Instances, Memory, CPU and "Instance Restrictions."   The instances number in a quota directly relates to the number of  VM instances that have been created within the tenancy.  This quota is checked as soon as an orchestration attempts to start and if the quota is exceeded it will cause the orchestration to fail to startup until other instances (orchestrations) are stopped.  Note - Stopped rather than simply shutdown as a shutdown instance remains in existence.

Memory and CPU quota are very similar to instance restrictions.  The main difference is that a VM has to be actually running to consume the quota so if this limit is reached then existing VMs have to be shutdown to allow the new instance to startup but they do not have to be "stopped".

Figure 2 below shows the errors reported when the quota is exceeded in a couple of examples.

Error starting orchestration that exceeds the allowed number of instances      "status": "error",      "info": {       "errors": {        "0": "don05 is in error: {'/quota-test': u'Reservation exceeded quotas: instances exceeded by 1.0'}"       } Error starting orchestration that exceeds the allowed Memory      "status": "error",      "info": {       "errors": {        "0": "don06 is in error: {'/quota-test': u'Reservation exceeded quotas: ram exceeded by 3576.0'}" }

Figure 2 - Error message when exceeding quota for instance or memory

Instance Restrictions is a special tagging mechanism that would allow a machine image (template) to be tagged and it is then possible to restrict the number of instances created from that specific machine image.  This is currently not supported on the OCM so the instance_restrictions quota value should be left blank.

Storage

The storage figure given applies to additional storage volumes and not to the root disks.  i.e. If you need to restrict storage space used by the root disks then you need to apply a quota to the instances in the compute section.  If you hit the limit then it is necessary to actively stop any storage volumes to delete the storage and free up resource.

Machine Image

The machine image quota can be specified either in terms of the numbers of machine images held within the quota or by the storage volume space taken up.  Typically this would be used to limit the number of snapshots that a tenancy can use.  (Taking a snapshot of a VM will take a copy of the root disks at the time of snapshotting and create a new machine image.)

Network

When networks are defined for a tenancy there are several choices on their configuration which can be used as a limit in themselves.  For example if a tenant has a public or EoIB network assigned to them then the number of IP addresses the tenancy can use will be determined by the subnet and within the subnet further limited by the IP Range defined.  Private networks can also be created but again these have a defined size which cannot be exceeded.

However, in OCM releases prior to 17.1.6 the concept of a service network was available where a tenancy would be given access to a network and the same network could be handed out to other tenancies as well.  If a "vnetreservation" quota is setup then the system will prevent a tenancy using more than the quota value of IP addresses from these service networks.

An example failure to create a VM is shown in figure 3 when the tenancy has run out of IP addresses on a network.

"info": {       "errors": {        "0": "{u'/cloud/public/EoIB-OMS': u'1 IP(s) requested, but only 0 IP(s) available in the vnet.'}"       },

Figure 3 - No IP addresses available

Conclusion

If a customer has divided their rack into multiple tenancies to run different environments then the quota system is a powerful and useful mechanism to ensure that no users of the system hog the available compute resource.