News

Root and additional volumes

Every server at cloudscale.ch has a root volume on NVMe SSDs that contains the selected operating system after the initial start-up. The size of this volume can be determined for almost all images when creating the server to ensure that your data fit into this volume. If your project and the associated space requirements grow at a later point, scaling up the root volume is simple and can be performed on a running system.

In addition, it may make sense to save some of the data on separate volumes. Bulk volumes are a good choice when inexpensive storage space is required and performance is a lesser priority, e.g. for archive data. For a database that needs to remain separate from the rest of the system, on the other hand, an additional SSD volume would be the first-choice solution. Additional volumes can either be created when setting up a server or added to the server at a later date and scaled up as required. It is also possible to move additional volumes to another server or to delete them at any time.

Persistent volumes in container setups

Additional volumes are of particular significance in modern container setups. Containers or pods are volatile by nature, and as soon as they are replaced by a new instance or a new version, the data disappear. If, however, the data need to be maintained, the pod can be allocated a persistent volume, which means an additional volume for permanent data storage. Thanks to the "container storage interface" (CSI), persistent volumes of this kind can be created automatically by a container orchestration system such as Kubernetes and directly attached to the correct node so that the pod running there has access to it.

cloudscale.ch now supports up to 128 volumes per virtual server, thus also offering adequate scope for tightly packed container setups. You can scale up your cluster and migrate workloads between nodes, while the defined "persistent volume claims" (PVCs) are automatically fulfilled via CSI so that storage is available in the correct location. If you have already been using our CSI driver, make sure that you update to the most recent version.

Technical background

Support for up to 128 volumes per virtual server was made possible by changing the background technology. Newly created virtual servers use virtio-scsi for the volumes instead of virtio-blk. This means that the number of volumes is no longer limited by the number of supported PCI devices. We have also patched a bug in OpenStack, on which our cloud is based. This bug meant that – in addition to limited PCI devices – volumes from vda up to at most vdz, i.e. a maximum of 26, could be used.

The only change for you as a user is the change to the name of the volumes: instead of vda, vdb, etc. you will now find the volume sda and possibly further sdX in your virtual server. This also eliminates one of the main differences that needed to be considered when switching from a physical computer to a Linux cloud server. If a large number of volumes are actually being used, numbering after sdz continues with sdaa to sddx, which covers the current maximum of 128 volumes. You may need to check in your tools or scripts that the new names are being used for operations on volumes and partitions.

Example showing two volumes in an Ubuntu server:

ubuntu@my-server:~$ lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
[...]
sda       8:0    0   50G  0 disk
├─sda1    8:1    0 49.9G  0 part /
├─sda14   8:14   0    4M  0 part
└─sda15   8:15   0  106M  0 part /boot/efi
sdb       8:16   0  100G  0 disk
└─sdb1    8:17   0  100G  0 part
sr0      11:0    1  478K  0 rom

With up to 128 volumes per virtual server, you are now also equipped for larger container setups. Using Kubernetes and CSI is not a requirement, though. It goes without saying that the additional flexibility can also be applied to other use cases, from sophisticated LVM configurations to the clean separation of different data sets.

Claim your volumes!
Your cloudscale.ch team