Page tree

On this page

Overview

The following resources are currently included in Nirin Cloud usage charge calculations:

ResourceDescription
vCPUsVirtual CPUs allocated to instances
MemoryVirtual RAM allocated to instances
Volume StoragePersistent volume storage

NCI does not currently charge for the following resources, however this may change in the future:

  • public IP addresses (floating IPs)
    • please note that there is a limited number available and we strongly encourage users to minimise the number of public addresses they use
  • integrated object storage (Swift/S3 API endpoints)
    • please note that the integrated object storage service is not configured for large scale use, please contact the NCI Helpdesk before using it for large volumes of data
  • network ingress/egress

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.

Compute Resources - Flavours

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.

Charging Rates

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 NamevCPUsMem (GB)Root disk (GB)Service Unit (SU) / hourService Unit (SU) / dayService Unit (SU) / weekService Unit (SU) / qtr (91.25 days)
c3.1c0.5m1d1.511.25302102,737.5
c3.1c1m5d1151.25302102,737.5
c3.1c2m10d12101.25302102,737.5
c3.2c4m10d24102.50604205,475
c3.4c8m10d48105.0012084010,950
c3.8c16m10d8161010.0240168021,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.

Private Flavours

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.

Selected Commonly Used Private Flavours

Flavour Name

vCPUs

Mem (GB)

Root Disk (GB)Ephemeral Disk (GB)
c3.16c32m10d1632100

c3pl.1c2m10d

1

2

10

0

c3pl.2c4m20d

2

4

20

0

c3pl.8c16m80d

8

16

10

70
c3pl.8c28m20d828200
c3pl.16c48m200d164820180

Charging for private flavours is available on request.

Requesting a Custom Flavour

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

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.

Storage Tiers

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 __DEFAULT__ volume type is obsolete and being retired - existing volumes with this type should be migrated over to one of the Nirin2 volume types. Please contact the NCI Helpdesk for assistance.

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.

Charging Rates

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.

TierDescriptionCinder Volume TypeCharge 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)

GeneralGeneral use volume storage - suitable for most use casesNirin2_General0.66.14147.4513,455.36
TransactionTransaction oriented storage, suitable for IOP-oriented use cases like databasesNirin2_Transaction1.818.43442.3640,366.08
ThroughputHighly optimised storage suitable for high throughput relatively small volume use cases
(Note this tier can only support small volume sizes)
Nirin2_Throughput2.424.57589.8253,821.44
Old default
(obsolete)
Old general use storage - now deprecated. New volumes should always use one of the
Nirin2 volume types.
__DEFAULT__0.757.68184.3216,819.20

Quotas, Usage Charges, and Usage Patterns

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.

 

Related pages

There is no content with the specified labels