Content
Slurm-HPC Pricing
If you want to do high performance computing using OCI, we offer to setup a SLURM stack for you. (see also https://portal.trit.au.dk/project/projects/public-wiki/wiki/oracle-cloud-infrastructure-and-slurm ). The benefits of using an HPC setup on OCI is scaleability. Other than some basic associated costs, you only pay for the compute resources you use, and depending on your needs, the compute available scales "infinitely" and can even include GPU instances. The pricing of the SLURM cluster can be split into 3 parts: the job-server, the compute-instances and the storage.
These prices are based on https://www.oracle.com/dk/cloud/costestimator.html and last updated 10th. April, 2025.
The Job-server
The job server is a set of 2 VM's that needs to be running 24/7 to manage SLURM administrative tasks and scale the available compute up or down depending on your needs. These are called the controller node (not accesible) and the login node (accessible). At their lowerst costs, this will be 2 VM's at 1core 2GB RAM each, which costs about 340DKK a month. Do note that the login node however also functions as a standard VM that you can use to do whatever you want with. For example, if you need a database or similair running for all your slurm tasks, you could opt to increase the specifications of the login node to something like 4 core 8GB ram.
The Compute-Instances
The central part of the SLURM server is of course the scaleable compute instances. These run on Oracles Autonomous Linux, and runs the script defined in the SLURM file. The servers that are spun up can be spun up with a custom number of cores and memory. The limits are that each core should have at minimum 1GB RAM, and at max 64GB per core.
By default, new machines are based on AMD's EPYC 7J13 (Called VM.Standard.E4.Flex on Oracle), which has cores that have a base frequency 2.55 GHz, max boost frequency 3.5 GHz. These can also be changed to AMD EPYC 9J14 (Called VM.Standard.E5.Flex on Oracle) with a base frequency 2.4 GHz, max boost frequency 3.7 GHz on request, if IPC is very important / if your workload cannot easily be parallelized.
Compute Pricing Examples |
EPYC 7J13 [DKK/Hour] |
EPYC 9J14 [DKK/Hour] |
(minimum config) 1 core 1 GB Ram |
0.18 |
0.22 |
4 cores 8 GB |
0.75 |
0.92 |
8 cores 16 GB |
1.51 |
1.83 |
16 cores 32 GB |
3.02 |
3.66 |
4 cores 256 GB |
3.26 |
4.25 |
4 cores 4 GB |
0.71 |
0.86 |
64 cores 64GB |
11.42 |
13.79 |
(Max Config EPYC 7J13) 114 cores 1760 GB |
36.96 |
46.72 |
(Max Config EPYC 9J14) 126 cores 2098 GB |
- |
53.69 |
Try making your own custom config on https://www.oracle.com/dk/cloud/costestimator.html using Compute - Virutal Machine and setting utilization to 1 hour a month
For example, a job requising spinning up 10 new E4 VM's with 16 cores and 32 threads would cost about 60DKK if theyre running for 2 hours
Do note that spin-up times (~15-20min) and time to destroy is also included in the billing from oracle. For this reason, in case of erroneous job submissions, etc. Compute instances stay for around an extra hour before they are destroyed.
Do also note that currently compute instances all need to share one configuration, meaning you can spin up as many machines of a specific configuration as you'd like, but only that configuration. Were actively looking to remedy this problem. Custom configurations can now be made, and initial instance configurations can be studied at https://portal.trit.au.dk/project/projects/public-wiki/wiki/the-different-vm-queues-of-slurm
The Storage
Doing storage on OCI is very different depending on your individual needs. (see also https://portal.trit.au.dk/project/projects/public-wiki/wiki/storage-on-oci ). In general, the less you need to access the data, and the slower you can live with, the cheaper data gets. For figuring out which if best for you, we recommend you read this article: https://www.oracle.com/cloud/storage/block-volumes/what-is-block-storage/vs-object-storage/ . The conclusion from the article reads as follows
Object storage is an excellent fit when used for many small files that don't require structure—such as email or a document archive—essentially WORM data. Block storage is best used when you want to store smaller chunks of data that take up less space and when an object versioning system is unavailable in object storage. File storage is great if you want to store data that requires many small transactions, such as a transactional database, time series files, and files with a low concurrency rate—for example, a single user editing a text file, spreadsheet, or document.
Estimated DKK/Month |
File Storage (Standard 1 Gbps) |
Block Storage (Balanced Performance) |
Object Storage (Standard w/ 100.000 requests/month) |
Price/GB |
2.02 |
0.29 |
0.11 |
10GB |
20.20 |
2.86 |
-? |
50GB |
100.98 |
14.31 |
6.98 |
128GB |
258.51 |
36.62 |
20.37 |
512GB |
1034.04 |
146.49 |
86.29 |
1024GB |
2068.07 |
292.98 |
174.18 |
4096GB |
8272.28 |
1171.91 |
701.54 |
As you can see, there are a lot of money to save depending on your need for storage performance and access. If you're a researcher, we also recommend looking at ERDA as an alternative to Object Storage. We are currently developing tools that helps with both exporting and importing data using ERDA.