Overview

The STFC Cloud provides a number of flavors to users but these fall into 4 categories at the moment.

The larger the flavor you choose the more resources you will be holding and the more power is consumed by the instance you have created. This also prevents other users from using these resources.

It is important that you should use the smallest flavor that meets the requirements of your workloads and if possible delete the instance when you are not using it.

Compute flavors

l flavors

(e.g. l6.c252, l3.nano, l2.xsmall)

These are flavors which utilize local SSD storage on the hypervisors with all of the storage being allocated to the root disk. Larger l flavors may struggle to live migrate due to capacity availability and disk image sizes so where possible be sure that you can recreate your machines using other methods, such as configuration management.

le flavors

(e.g. le3.small, le2.medium)

These are flavors which utilize local SSD storage on the hypervisors with 100GB being allocated to the root disk and the rest to an ephemeral disk. Larger le flavors may struggle to live migrate due to capacity availability and disk image sizes so where possible be sure that you can recreate your machines using other methods, such as configuration management.

Compute flavor list

GPU flavors

g flavors

(e.g. g-a100.x1, g-rtx4000.x4)

These have the same CPU configuration as l*.* flavors but have a GPU attached:

• g-rtx4000.* have one or more NVidia Quadro RTX 4000 cards attached (the smallest has 1, the largest has 4)

• g-rtx4000-ref.* have one or more NVidia Quadro RTX 4000 cards attached (the smallest has 1, the largest has 4)

  • These are older, out of warranty nodes which have been refitted with new GPUs. For this reason these are primarily reserved for short term use such as training courses. If you have a use case you want to use these for then please get in touch with cloud support.

• g-a4000.* have one or more NVidia RTX A4000 cards attached (the smallest has 1, the largest has 4)

• g-a4000-ref.* have one or more NVidia RTX A4000 cards attached (the smallest has 1, the largest has 4)

  • These are older out of warranty nodes which have been refitted with new GPUs. For this reason these are primarily reserved for short term use such as training courses. If you have a use case you want to use these for then please get in touch with support.

• g-v100.* have one or more NVidia Tesla V100 32GB cards attached (the smallest has 1, the largest has 4)

• g-a100.* have one or more NVidia Tesla A100 40GB cards attached (the smallest has 1, the largest has 4)

• g-a100-n100.* have one or more NVidia Tesla A100 40GB cards attached (the smallest has 1, the largest has 4) with higher core count and more network bandwidth

  • These are currently reserved for specific projects.

• g-a100-80gb.* have one or more NVidia Tesla A100 80GB cards attached (the smallest has 1, the largest has 8)

• g-arc-a770.* have one or two Intel Arc A770 16GB cards

  • These are very limited in number and are primarily in place for prototyping.

• g-amd-w6600.* have one or more AMD W6600 8GB cards (the smallest has 1, the largest has 4)

  • These are very limited in number and are primarily in place for prototyping.

f flavors

(e.g. f-xilinxu200.x1)

These are similar to the g* flavors but have fpga accelerators rather than GPUs

• f-xilinxu200.* have one or more Xilinx U200 FPGA cards

  • These are very limited in number

GPU flavor list

Flavor Lifetimes

In general flavors are tied to hardware generations. We run these generations for at least the length of their maintenance contracts.

Ideally we try to run these past the end of their maintenance contracts at a reduced SLA. This means that capacity available will decrease over time and all VMs on these flavors should be considered at risk.

There are several things that may shorten the amount of time that we run past the end of the contract.

• Hardware that is particularly prone to failure leading to high maintenance overheads

• Needing the rack or power space for increases in capacity, functionality or efficiency

• Hardware no longer being supported by the software we need to use

The Draining date is the date when access to the flavors will be restricted

The final EOL date is when the hardware turned off

We will re-evaluate these dates periodically and may revise the draining and EOL dates to be closer to the end of maintenance.

Deprecated flavors

c flavors

(e.g. c2.xlarge, c3.small)

l2 and le2 flavors

(e.g. l2.large, le2.small)

these flavors have now been renamed to dep-l2 and dep-le2 to reflect that these are deprecated and should be considered at risk. We will be confirming the Final End Of Life date for these shortly. This will be the date when any remaining running VMs will be terminated.

Related articles