Flexible Management of SSD and Bulk Volumes

Thanks to the SSD-only root volume and an optional bulk volume, we already provide you with the optimal storage space for your application – both for heavily used data and for data that is accessed on rare occasions only. As of now, servers and volumes at are no longer tied to each other: You can add virtually any number of SSD and/or bulk volumes to your servers and even move them between your servers as required.

How you can benefit from the new volume management

Following our high ambition regarding simplicity, the start of a new server remains basically unchanged. For optimal performance, the operating system is installed on an SSD-only volume, whereby the first 10 GB are free as before. However, with a click on "Show more options" you can now add virtually any number of additional volumes to your new server. For example, you can create a separate volume for /var – without changing the existing partitioning of the root volume. Additional SSD and bulk volumes can also be added or removed later as required.

With most available operating system images, a maximum root volume size of 2 TB is viable (due to partitioning scheme and file system, among other things). With additional volumes you can now go beyond this limit and manage larger amounts of data on our high-performance SSD-only storage cluster. And if you want to start small first, scaling volumes up later now even works on the fly: after OpenStack did not support this feature in combination with Ceph in the past, engineers from have developed a corresponding solution, which will also be provided upstream to the official OpenStack project.

Which other possibilities are available through our API

The API of course offers all the benefits mentioned above as well. It is also possible to detach additional volumes from the respective virtual servers and connect them to other servers later. This allows you to use such volumes to move data from one virtual server to another. Please note that the root volume of a virtual server cannot be detached from the server and/or deleted separately.

In the same way you can "put aside" existing data, e.g. while the respective virtual server is being deleted and reinstalled. In this case, pass an empty list to the API call as the new server UUID – the volume with the data remains in your account and can be reattached to another virtual server at any later time. For more information about the newly available API calls, please refer to our API documentation.

What to look forward to as a Kubernetes user

Support for "CSI" is already in the pipeline: The "Container Storage Interface", whose specification is currently being finalized, is a defined interface for the automatic provisioning of "Persistent Volumes" in Kubernetes. Without manual intervention, persistent volumes of the desired type and size can be created as soon as a container references a corresponding "Persistent Volume Claim". Persistent Volumes created in this way are not bound to a specific node, but available wherever they are needed by a container.

With the support for additional volumes and the extension of our API, we have laid the foundations on which the CSI driver will be based. Of course, the enhancements will also benefit all other orchestration solutions, including our Ansible Cloud Module and the Terraform plug-in for the provider "cloudscale".

If in the past you sometimes wished for the flexibility of an external hard drive, additional volumes now offer you just that. They are also the ideal solution if, for example, you need more storage space only temporarily – as soon as you no longer need the space, simply delete the volume again. Or just let the orchestration tool of your choice do the work for you thanks to the new API calls.

The perfect volume for all your data,
Your team

Back to overview