Introduction to flavors

When creating a virtual machine, this machine needs to have some specifications. It is for example important to know how many CPU's and how much memory the VM should have access to. In openstack the specifications of a VM is configured by selecting a flavor when the VM is created. The flavor contains information about how many CPU's and how much RAM the VM should have, in addition to how large (and fast) the default disk should be. The flavor can also give access to special resources like GPU's.

General purpose flavors

The flavors is organized into classes to help you select the correct flavor for your needs. Each of the classes have 5 flavors of various sizes (tiny, small, medium, large, xlarge). Currently the following classes exist:

• t1 - Tiny VM's
  • This class is intended for testing, or for VM's which does not really need much resources.
  • The disk are shaped to 150 IOPS, which is similar to a regular hard-drive.
• m1 - Medium-size General purpose
  • This class is for the general purpose VM's. These flavors have 4 GB RAM for each CPU (except for tiny, which have 1CPU/2GB RAM).
  • The disk are shaped to 300 IOPS, which is faster than an enterprise grade hard-drive.
• l1 - Large general purpose
  • This class is for general-purpose VM's where the m-series are too small. These flavors have 4GB RAM for each CPU.
  • The disk are shaped to 300 IOPS, which is faster than an enterprise grade hard-drive.
• c1 - CPU intensive VM's
  • This class is for VM's needing a lot of CPU, while not needing too much memory. These flavors have 2GB RAM for each CPU.
  • The disk are shaped to 300 IOPS, which is faster than an enterprise grade hard-drive.
• r1 - RAM intensive VM's
  • This class is for VM's needing a lot of RAM. These flavors have 8GB RAM for each CPU.
  • The disk are shaped to 300 IOPS, which is faster than an enterprise grade hard-drive.

Overview

The following general-purpose flavors exists in all our platforms:

+-----------+--------+------+-------+
| Name      |    RAM | Disk | VCPUs |
+-----------+--------+------+-------+
| t1.tiny   |    256 |   40 |     1 |
| t1.small  |    512 |   40 |     1 |
| t1.medium |    768 |   40 |     1 |
| t1.large  |   1024 |   40 |     2 |
| t1.xlarge |   1536 |   40 |     2 |
| m1.tiny   |   2048 |   40 |     1 |
| m1.small  |   4096 |   40 |     2 |
| m1.medium |   8192 |   40 |     2 |
| m1.large  |  16384 |   40 |     4 |
| m1.xlarge |  32768 |   40 |     8 |
| l1.tiny   |  49152 |   40 |    12 |
| l1.small  |  65536 |   40 |    16 |
| l1.medium |  81920 |   40 |    20 |
| l1.large  |  98304 |   40 |    24 |
| l1.xlarge | 131072 |   40 |    32 |
| c1.tiny   |  16384 |   40 |     8 |
| c1.small  |  24576 |   40 |    12 |
| c1.medium |  32768 |   40 |    16 |
| c1.large  |  49152 |   40 |    24 |
| c1.xlarge |  65536 |   40 |    32 |
| r1.tiny   |  65536 |   40 |     8 |
| r1.small  |  98304 |   40 |    12 |
| r1.medium | 131072 |   40 |    16 |
| r1.large  | 196608 |   40 |    24 |
| r1.xlarge | 262144 |   40 |    32 |
+-----------+--------+------+-------+

GPU-based flavors:

Some of the openstack platforms are equipped with GPU's, and access to these are given on request.

• SkyHiGh:
  • gpu.v100.8G: 8CPU, 90GB RAM and 1/4 of a Nvidia Tesla v100 with 8GB GPU-RAM.
  • gpu.micro.a100.4G: 5CPU, 25GB RAM and 1/10 of a Nvidia Tesla A100 with 4GB GPU RAM.
  • gpu.medium.a100.10G: 12CPU, 60GB RAM and 1/4 of a Nvidia Tesla A100 with 10GB GPU RAM.
    • Currently primarily for affiliates of SFI NORCICS
  • gpu.large.a100.20G: 24CPU, 120GB RAM and 1/2 of a Nvidia Tesla A100 with 20GB GPU RAM.
    • Currentlt primarily for affiliates of SFI NORCICS
  • gpu.large.a100d.20G: 24CPU, 120GB RAM and 1/4 of a Nvidia Tesla A100D with 20GB GPU RAM
    • Currently exclusively for affilates of NBL
  • gpu.large+r.a100.20G: 24CPU, 240GB RAM and 1/2 of a Nvidia Tesla A100 with 20GB RAM
    • Currently exclusively for affilates of NBL
• SkyLoW:
  • gpu.m10.8G: 8 CPU, 20GB RAM and 1 Nvidia Tesla M10 with 8GB GPU-RAM.

IO-Intensive flavors

Most of our General-Purpose flavors are available in high-IO-versions. If 300IOPS are not enough for your use-case you can be granted access to flavors giving 600IOPS or 1200 IOPS:

Flavor "Not available"

. Our flavors are organized in various classes which are further described in this page.

Be aware that we in 2022 are in a transition-phase from an old naming-scheme to a new naming-scheme.

• The old naming-scheme is documented here.
• The old flavors will be removed during autumn 2022.
• The recommended upgrade-path from old flavors to new flavors is listed here.

The flavor naming format

At its core the flavors in our openstack-platforms are named with the following format: "<prefix>.<basic-specs>". The prefix is used to define what kind of VM it is (is it a prioritized or a regular VM? Does it have support for special CPU functionality or not?), while the "basic-specs" describes how many virtual CPU's and how much memory the VM should have. This results in flavors like so:

• gx1.2c4r: A 1st generation Intel Xeon based general-purpose (gx1) VM with 2 CPU cores and 4 GB RAM.
• sx1.16c64r: A 1st generation Intel Xeon based low-priority (sx1) VM with 16 CPU cores and 64 GB RAM. The low-priority flavors are very suitable for compute-loads that is not time-sensitive. Typically flavors with many CPU-cores do long-running batch-jobs and are prioritized lower than smaller flavors which typically hosts interactive applications.
• px1.4c8r: A 1st generation Intel Xeon based prioritized (px1) VM with 4 CPU cores and 8 GB RAM. The prioritized flavors are typically used for VM's hosting user-facing interactive applications to ensure that the application responds in a timely manner even when the same physical CPU's are heavily utilized by other long-term running jobs.

This should be enough for you to know what most of our generally available flavors mean. Please check in your platform what flavors are available, and if you need a configuration not currently present please contact us through NTNU Hjelp and we might be able to help you.

The rest of this article explores the naming-scheme more technically and detailed, in case you need to know the specifics of what we can provide to you.

Prefix

The prefix in the flavor-name indicates the capabilities of the CPU associated with the flavor. The prefix is divided into two parts:

• class: 2 letters indication flavor-class
• generation: a digit indicating the flavor generation.
• storage-location: optionally a single letter indicating the default storage-location.

Flavor classes

In our openstack-platforms we currently have the following classes:

• General purpose compute:
  • gx: based on Intel Xeon CPU's
• Prioritized compute. Used for some applications where short response-times are crucial, and it is proven that the general purpose is not sufficient.
  • px: based on Intel Xeon CPU's
• Scavenger compute. For compute-loads which is not time-sensitive, but it is nice with as much CPU as possible, the scavenger class allows us to allocate many CPU's that can be heavily utilized without affecting time-sensitive applications running on the same hardware.
  • sx: based on Intel Xeon CPU's
• Dedicated compute. Some compute-loads need dedicated hardware for predictible performance. Flavors of this class get dedicated CPU's not shared with anyone. 
  • dx: based on Intel Xeon CPU's
  • de: based on AMD EPYC CPU's.

Flavor generations

The generation-number is used to different various CPU-generations from each other. We currently employ two numbering-schemes; one for Intel-based flavors and one for AMD EPYC based flavors.

Intel Xeon based flavors:

The Intel Xeon based flavors can currently exist in 5 different generations. The following table lists the generations, and some of the functionality the generations provides.

Gen	CPU architecture	AES-acecleration	AVX	AVX2	AVX512 1.generation	AVX512 2.generation
1	Westmere
2	Sandy-Bridge
3	Haswell
4	Sky-Lake
5	Cascade-Lake

AMD EPYC based flavors:

Storage locations

The storage-location can optionally be described with a letter. The letter have the following meanings:

• no letter: The default storage-location is on a centralized SAN.
• h: The default storage-location is HDD's localized on the compute-node
• s: The default storage-location is SSD's localized on the compute-node.

Extended specifications

Some flavors equips the VM with additional resources like locally mounted storage or GPUs. Such flavors have extension appended to the flavor name to signal what resources are available.

GPUs

The GPUs are defined with the extension "<GPU-Type>-<GPU-RAM>". This will for example result in the following flavor name:

• dx5.12c96r.v100-8g: A flavor defining a VM with 12 dedicated Cascade-Lake CPU cores, 96GB RAM and a Nvidia Tesla v100 GPU with 8GB of memory

Local Storage

Some VM's would for performance reasons need storage which are locally attached to the compute-server, as that results in lower disk-latency than the regular case where storage is mounted over networks. Flavors providing local storage have the following extension in its name:

e<disk-size><size-suffix>

A flavor with local attached ssd's might be named like so:

• gx3s.8c32r.e500g: A flavor with Intel Haswell cores (gx3), default storage at a local SSD (s), 8CPU+32GB RAM (8c32r), and an extra disk of 500GB backed by the default storage configuration (e500g).

NVMe

Flavors that have NVMe-disks are described with the extension "nvme<SIZE>".

• For instance the flavor "x5.12c64r.nvme3t2" have 12 Cascade-Lake cores, 64GB RAM and a 3.2TB NVMe-disk attached.

Custom flavors

Some of our tenants have requirements not fitting the "general purpose" use-cases, and is investing in dedicated compute-nodes equipped with accellerators, local storage and similar. These tenants usually gets custom flavors (Identified by the keyword 'custom' in its name) providing access to these resources. The meaning behind each of the custom flavors is given to the personell needing access.

Flavor "Not available"

You might have VM's using flavors you do not hav access to anymore (for instance if a public flavor is set as private, or your access to a private flavor is revoked)If a flavor get changed (ex: m1.medium gets more memory) the old flavor will be deleted and a new one will be created. In this case existing VM's would be listed with the flavor "Not Available". This does not really matter, as the quotas is counted correctly, and openstack knows which specs the machine is supposed to have, but if you would like to give the machine a new flavour you should simply resize it to a new flavor. If you resize to a flavor to small to support the machine nothing will happen, so you should not loose any data regardless of which flavor you decide to resize to.

...