The following resources are currently included in Nirin Cloud usage charge calculations:
| Resource | Description |
|---|---|
| vCPUs | Virtual CPUs allocated to instances |
| Memory | Virtual RAM allocated to instances |
| Volume Storage | Persistent volume storage |
NCI does not currently charge for the following resources, however this may change in the future:
Usage is calculated for the full period in which resources are allocated, with resolution down to the second. Some values are updated periodically, typically on a ten minute schedule - changes to those values will take effect on the first update after the change was made.
An instance is a virtual machine consisting of virtual CPU cores, memory, and persistent storage. Flavours specify the shape of an instance - the number of virtual CPUs, the amount of memory, and the size of the local storage. A flavour must be specified by the user when the instance is created, which then determines the resources allocated to the instance's virtual machine - the flavour is stored with the instance metadata and persists through the lifetime of the instance, so that whenever the instance is booted it receives the same allocation of resources.
NCI flavours are given names which reflect the allocation of these three resources: the name consists of a prefix (typically c3 - any other prefix will indicate a non-standard or custom flavour), followed by a triple made up of the vCPU count, the memory allocation in gigabytes, and the disk allocation in gigabytes. For example, the c3.2c4m10d flavour is a standard public flavour which allocates 2 vCPUs, 4GB of memory and 10GB of disk to an instance.
Although the flavour associated with an instance is persistent, this association can be changed using a resize operation, updating the flavour stored in the instance metadata - this results in the instance being allocated the resources defined by the new flavour. A resize operation will shut down the instance, update the instance metadata to reflect the new flavour, possibly resize the instance disk, and then boot the instance back up. Note that a resize will not change the data on the instance disks - the size may change, however the existing data will be unchanged.
Resizing an instance to a flavour with smaller allocations of vCPU and memory is not an issue, however resizing to a flavour with a smaller disk will not work. Resizing to a flavour with a larger disk is generally safe, but will require a filesystem resize to make the new storage space usable - the details of this resize will depend on the filesystem type. |
NCI charges for instances based on their flavour, and the period in which the instance exists in the system. Flavour charging rates are defined per hour; fractional hours are charged pro-rata. The charging rate for each instance is determined by the instance flavour - after a resize operation, the charging rate will reflect the resized flavour. Note that instance flavour for accounting purposes is updated periodically, so there may be a small delay between the resize taking effect and the update to the charging rate - the original charging rate is applied during this period.
Unlike usage charges in the HPC context, cloud usage charges reflect the amount of resources allocated to an instance - this means that usage charges are levied for the whole time that an instance exists on the system, not just the time in which it is running. This is necessitated by the fact that once an instance is created, it can be booted up at any time; once it is running, it can make use of all the resources allocated to it - running processes on all its vCPUs, writing data to every byte of memory allocated or filling the persistent storage. Because of that, it is necessary to ensure that the resources allocated to each instance are available the whole time the instance can potentially run, which is then reflected in our cloud charging model.
Each flavour has a charging rate defined for it, which is determined by the NCI Cloud Team - indicative charging rates for standard Nirin flavours are listed in the table below.
For most flavours the NCI Cloud Team uses a fairly simple model to determine the charging rate: we weight each of the three core resource types based on their availability, and then we set the charging rate according to the highest weighted cost of each resource. Currently the base ratios are 1 vCPU = 2GB memory = 10GB disk = 1.25SU/hour, so a flavour with 1vCPU, 2GB memory and 10GB disk is charged at 1.25SU/hour, while a flavour with 2vCPU, 2GB memory and 10GB disk would be charged at 2.5SU/hour based on the vCPU allocation, and a flavour with 1vCPU, 8GB memory and 20GB disk would be charged at 5SU/hour based on the memory allocation. Note: The model describe here is for information purposes, and is not definitive - the actual charging rate for any flavour is entirely at the discretion of the NCI Cloud Team. |
| Flavour Name | vCPUs | Mem (GB) | Root disk (GB) | Service Unit (SU) / hour | Service Unit (SU) / day | Service Unit (SU) / week | Service Unit (SU) / qtr (91.25 days) |
|---|---|---|---|---|---|---|---|
| c3.1c0.5m1d | 1 | .5 | 1 | 1.25 | 30 | 210 | 2,737.5 |
| c3.1c1m5d | 1 | 1 | 5 | 1.25 | 30 | 210 | 2,737.5 |
| c3.1c2m10d | 1 | 2 | 10 | 1.25 | 30 | 210 | 2,737.5 |
| c3.2c4m10d | 2 | 4 | 10 | 2.50 | 60 | 420 | 5,475 |
| c3.4c8m10d | 4 | 8 | 10 | 5.00 | 120 | 840 | 10,950 |
| c3.8c16m10d | 8 | 16 | 10 | 10.0 | 240 | 1680 | 21,900 |
Note: These charging rates are correct at the time of publication, but this document is not the authoritative source for this information - please contact the NCI Helpdesk to confirm current charging rates.
Flavours are either public or private - public flavours are available to all projects, private flavours are only available to a project on request. All public flavours give access to our highly available aggregate, private flavours may grant access to additional more specialised aggregates with different service levels. Flavours available to your project are visible in the dashboard instance creation dialogue, or via the openstack command line client - this will include all public flavours, as well as any private flavours your project has access to.
In addition to existing public and private flavours, projects with specialised requirements can request custom private flavours sized to meet their needs. Any such flavours will be made available at the discretion of the NCI Cloud Team; projects requesting such flavours will be notified of the charging rate when they request the flavour.
| Flavour Name | vCPUs | Mem (GB) | Root Disk (GB) | Ephemeral Disk (GB) |
|---|---|---|---|---|
| c3.16c32m10d | 16 | 32 | 10 | 0 |
c3pl.1c2m10d | 1 | 2 | 10 | 0 |
c3pl.2c4m20d | 2 | 4 | 20 | 0 |
c3pl.8c16m80d | 8 | 16 | 10 | 70 |
| c3pl.8c28m20d | 8 | 28 | 20 | 0 |
| c3pl.16c48m200d | 16 | 48 | 20 | 180 |
Charging for private flavours is available on request.
Requests for custom flavours should be made through the NCI Helpdesk - the ticket will be escalated to the NCI Cloud Team for assessment and discussion. Projects requesting custom flavours should provide a detailed explanation of their specialised requirements.
Volume storage provides persistent storage which can be attached to an instance - a volume attached to an instance will present to the operating system as a standard hard drive. Once attached to an instance a volume will stay attached until it is explicitly detached; once detached from the instance it can then be attached to a different instance.
When a volume is created the size must be specified - this is effectively the size of the disk. Volumes may be resized, and as with an instance resize the amount charged for a resized volume will reflect the new size. Volume size for accounting purposes is updated periodically; as with instance flavour there may be a small delay before the updated size takes effect, with the original charge rate applying during this period.
Please note that resizing the volume will not automatically resize the filesystem on the volume - that must be done manually after the resize is complete. The process for resizing varies depending on the filesystem used - please refer to the filesystem documentation for details.
Shrinking a volume is technically possible, but runs a very serious risk of data loss or irrecoverable data corruption. BEFORE shrinking the volume, the filesystem on the volume must be resized to fit within the planned new volume size, relocating much of the data in the process. This is at best a risky operation, and is not possible in many cases: many common filesystems do not support being shrunk at all, and those that do generally recommend against it because of the risks of data loss. The NCI Cloud Team strongly recommends against attempting to shrink a volume. Instead, we recommend creating a new volume of the target size and then copying the data from the old volume to the new volume - this is a safe and reliable operation. |
Nirin volume storage is backed by a highly redundant and reliable CEPH storage cluster. A number of different tiers are available, providing different performance characteristics - these tiers are specified via the volume type, which may be specified when the volume is created. If the volume type is not specified, it will default to Nirin2_General, the general use storage tier.
The old |
While it is possible to change the volume type of an existing volume, the NCI Cloud Team does not recommend attempting this. The recommended approach is to create a new volume of the desired type, and copy data from the old volume to the new volume.
All projects with volume storage quota can access the default storage tier (the Nirin2_General volume type). Projects with specific needs may request access to the higher performance tiers by contacting the NCI Helpdesk.
As with compute resources, and for similar reasons, NCI charges for the allocated size of each volume rather than the amount of data written to it.
Charging rates for volume storage are determined by the storage tier specified for the volume - see the table below for details.
| Tier | Description | Cinder Volume Type | Charge Rate (SU per 100GB per hour) | Charge Rate (SU per 1TB (1024GB) per hour) | Charge Rate (SU per 1TB per day) | Charge Rate (SU per 1TB per qtr (91.25 days) |
|---|---|---|---|---|---|---|
| General | General use volume storage - suitable for most use cases | Nirin2_General | 0.6 | 6.14 | 147.45 | 13,455.36 |
| Transaction | Transaction oriented storage, suitable for IOP-oriented use cases like databases | Nirin2_Transaction | 1.8 | 18.43 | 442.36 | 40,366.08 |
| Throughput | Highly optimised storage suitable for high throughput relatively small volume use cases (Note this tier can only support small volume sizes) | Nirin2_Throughput | 2.4 | 24.57 | 589.82 | 53,821.44 |
| Old default (obsolete) | Old general use storage - now deprecated. New volumes should always use one of the Nirin2 volume types. | __DEFAULT__ | 0.75 | 7.68 | 184.32 | 16,819.20 |
Each project with Nirin access has a set of quotas for various resources. These quotas are not directly related to a project's usage - quotas and usage are somewhat orthogonal concepts in the cloud context.
Cloud quotas determine the amount of each resource that the project can use at any given point in time - they represent the peak allowed resource usage for the project.
Usage charges are calculated from the cumulative resources usage for the project - they are effectively the area under a plot of actual usage over time.
For a project with consistent usage patterns the actual usage over time may be effectively constant; for a project with bursty usage patterns the usage over time may vary considerably. The first project may be happy with quotas that are the same as their regular usage - their usage never changes, so a static quota is sufficient to meet their needs. The second project may need to have quotas set much higher than their long-term average usage, in order to allow them to scale up their usage as required - most of the time their usage will be well below their quota, but occasionally a burst of activity will push their usage up to their quota, before falling back down again after the burst of activity passes.
In both cases projects will be charged for their actual usage, regardless of the quotas set.
Typically, the NCI Cloud Team will set project quotas at the time of provisioning on the assumption that usage patterns will be consistent and stable throughout each quarterly charging period, so that a project will be able to consume its allocation at a steady pace. Projects which need higher quotas to support bursty usage patterns should contact the NCI Helpdesk to discuss their requirements.
Note: Project quotas can be adjusted by the NCI Cloud Team at any time - please contact the NCI Helpdesk to request changes. Actioning such requests will be performed at the discretion of the NCI Cloud Team.