With the help of the Compute Cloud, the Infrastructure-as-a-Service (IaaS) offer of the LRZ, individual virtual IT infrastructures can be created to solve tasks in the field of scientific computing, education and the processing of large amounts of data. Access to compute resources within the framework of an LRZ project is uncomplicated.
The operation is carried out according to the "best effort" principle. For critical services with a high level of reliability, our "Virtual Managed Server" service with an underlying infrastructure designed for high reliability is therefore recommended.
There is the possibility of operating hardware that is procured with the customer's own funds and according to the specifications of the LRZ via the cloud team; see chapter "Attended Compute Cloud Housing". Otherwise, the available resources are basically available to all interested parties on an equal footing.
A self-service portal and interfaces (APIs) can be used to provision and manage infrastructure resources. These include, for example, virtual machines (VMs), networks or storage resources. Each user receives full administrator access to their virtual infrastructure, can install their own software and is responsible for the configuration and security of their system environment. If licenses are required for the operation of software in the VMs, the user is solely responsible for the correct licensing.
Flavors
are used to govern the allocation of resources to a VM. A flavor is assigned a certain number of CPUs, a certain part of the main memory, etc. It therefore includes all the resources of a physical machine or a fraction of it, e.g. 1/1, 1/2, 1/4, 1/10, 1/20, 1/40. In addition, flavors determine which physical hardware VMs run on. It is not possible to provide individually configured flavors for individual users.
By default, users do not have access to all available flavors, but only to those that can be used depending on their quotas (see next section). This applies to flavors that provide large parts of the compute nodes. If a user wants to operate such a VM, he must contact the LRZ in advance, as not only must access to the flavors be activated, but also the user's quota must be increased.
Quotas
Quotas represent a limitation of resources that can be used by a user at the same time.
The use of quotas prevents individual users from overloading the systems and blocking compute nodes with other VMs. It also creates awareness of the physical capacity limits of the Compute Cloud. An adjustment of quotas is possible; for particularly computationally intensive projects, you can submit a request for quota expansion.
The default quota is set in such a way that most users can cope with it. It is based on the characteristics of the compute nodes and is intended to reflect the typical resource requirements of the users:
This means that a user can start a maximum of 4 VMs at the same time, using a maximum of 10 virtual CPU cores in total. For example, it can start several smaller VMs or a larger one with 10 cores.
As described, the quota can be increased for individual projects, e.g. if a user wants to use a GPU in one of his VMs. This request must be made by a master user of the project.
It is not possible to exceed the quota; in this case, OpenStack prevents the start of new VMs or the creation of new volumes.
Budgets
In order for a virtual machine to be started, (one) of the master users of the LRZ project must set both a project budget and the budget of the individual user to a value greater than 0. New LRZ projects and identifiers in a project are always initialized with a budget of 0.
Budgeting ensures that the use of the LRZ Compute Cloud does not incur more costs than have been approved by the implementing institution of the LRZ project. The additional user budget allows costs to be limited on a user basis, e.g. for the execution of theses.
Deletion of VMs and their data
The LRZ reserves the right to delete VMs and data of projects and users if they were deactivated or deleted more than three months ago or whose budget has been used up for more than three months.
Users are responsible for backing up the data in a timely manner.
Scope of Services and Service Specifics
Management
Self-service access to cloud management functionality is offered via a web interface and APIs for the creation and management of virtual infrastructure components such as
- Virtual Machines (VMs)
- Operating System Images
- Data volumes incl. snapshots
- Network configurations incl. own virtual networks
Virtual Servers
As described above, different flavors can be used in the Compute Cloud that correspond to different hardware types and proportions. A flavor determines the configuration provided, e.g. number of virtual CPUs, size of RAM or additional components such as GPUs.
In the Compute Cloud, CPUs are overprovisioned to meet the needs of as many users as possible. The main memory is not overprovisioned.
Operating Systems and Software
The LRZ provides up-to-date operating system images, whose runnability and compatibility with the environment have been tested. These images come directly from the sources of the respective distributor and are not changed or adapted by the LRZ, see https://docs.openstack.org/image-guide/obtain-images.html.
In addition, you can upload your own operating system images to the cloud and use them that are compatible with the virtual hardware.
The customer is responsible for the correct licensing of the operating system and software in the VM.
The Compute Cloud is an IaaS offering. The LRZ does not provide support for the configuration of the VMs and for software within the VMs.
Storage space
Block-based storage space is made available for operating system images, virtual server system drives, and data volumes.
The storage space is protected by redundancy against the failure of up to two components, but the LRZ does not create backups.
Snapshots and clones can be created by the users themselves, but these do not replace a data backup to be carried out by the customer. For data backup, you can use our "Backup and Archiving" service.
To manage larger amounts of data, we recommend using other storage offerings, such as Cloud Storage or Data Science Storage (DSS) for data volumes of 20 TiB or more.
Network
Customers can either use a generally provided network or create and use their own networks.
Security groups isolate your own virtual servers, even if they are operated in a common network, and perform a similar function to firewalls. They are fully configurable by the user. Network access to and from the virtual infrastructure is not restricted by the LRZ.
For external access to your own servers and services, so-called floating IPs are used; these can come from an internal MWN or worldwide IPv4 address range. This has an impact on the accessibility of the VMs: While VMs with MWN-internal IP addresses can only be reached from the MWN, VMs with IP addresses from the worldwide area can also be reached worldwide and are therefore much more exposed. We recommend that VMs only be equipped with addresses from the worldwide IP range if worldwide access is actually needed.
Capacity planning
Customer projects come with resource limits that limit the number of possible virtual servers and networks, available memory, and so on. The change of the limits can be requested by a Master User via the Service Desk.
In general, there is no assurance that a certain amount of resources can be provided at any given time. The cloud is operated according to the best-effort principle.
Fees
The use of the LRZ Compute Cloud is subject to a fee, depending on the resources used.
When creating a VM, the user specifies the flavor with which it should be created. Among other things, the flavor regulates the resource allocation to the VM, i.e. the number of CPU cores, the size of the main memory and whether a GPU is provided.
The LRZ provides the following flavors, among others, for the use of customer VMs, which have different prices depending on the resources provided. A complete list of all available flavors can be found on the documentation platform.
| Name | vCPUs | RAM | GPUs | (S) per Day | (V) per Day | (S) per Year | (V) per Year |
|---|---|---|---|---|---|---|---|
| lrz.tiny | 1 | 1,12 GiB | 0 | on request | on request | on request | on request |
| lrz.small | 1 | 4,5 GiB | 0 | on request | on request | on request | on request |
| lrz.medium | 2 | 9 GiB | 0 | on request | on request | on request | on request |
| lrz.large | 4 | 18 GiB | 0 | on request | on request | on request | on request |
| lrz.xlarge | 10 | 45 GiB | 0 | on request | on request | on request | on request |
| lrz.2xlarge | 20 | 90 GiB | 0 | on request | on request | on request | on request |
| lrz.4xlarge | 40 | 180 GiB | 0 | on request | on request | on request | on request |
| nvidia-v100.1 | 20 | 368 GiB | 1 | on request | on request | on request | on request |
You will only be charged for virtual machines that have resources assigned to them. If a VM is "shelved", there is no cost for it.
Budgets
In order to be able to limit the maximum costs that can be incurred, there are two types of budgets managed by the Master User:
- Project budget
The project budget sets the upper limit on the total cost that can be generated by the project. The total cost is made up of the costs generated by the individual users of the project. - User budget
The user budget offers the possibility to limit the costs that a single user can generate.
As soon as a budget is exceeded, the VMs in question are shelved. If the project budget is exceeded, all VMs of the project are shelved, and if a user budget is exceeded, all VMs of the corresponding user are shelved.
VMs cannot be restarted (i.e. their data can only be accessed again) after the budget has been increased.
The LRZ reserves the right to delete VMs and data if budgets have been exceeded for more than three months. Users are responsible for backing up data in a timely manner.