Cinder-Volumes in OpenStack erstellen & anhängen

Die Root-Disk einer Instanz lebt und stirbt mit der Instanz. Sobald Daten einen Rebuild, eine Größenänderung oder einen Wechsel auf einen anderen Hypervisor überstehen sollen, brauchen Sie Block-Storage, der unabhängig vom Compute existiert. In OpenStack ist dieser Dienst Cinder, und auf einer ernsthaften Cloud setzt er meist auf Ceph auf, sodass jedes Volume repliziert und ausfallsicher ist.

Dieses Tutorial behandelt den gesamten Lebenszyklus: ein Volume erstellen, an eine laufende Instanz anhängen, im Gast formatieren und mounten sowie für Backups snapshotten. Es knüpft an das Starten der ersten Instanz an und spiegelt lokale Storage-Konzepte wie LVM auf der Cloud-Ebene.

Voraussetzungen

• Eine laufende OpenStack-2025.2-Cloud mit openstack-Client und projektbezogenen Zugangsdaten.
• Eine laufende Instanz (z. B. web-01), in die Sie sich per SSH einloggen können.
• Ausreichend Volume- und Gigabyte-Quota im Projekt – prüfen mit openstack quota show.

Schritt 1: Ein Volume erstellen

Erstellen Sie ein leeres 10-GB-Volume. Bietet Ihre Cloud mehrere Volume-Typen (etwa SSD-gestützt gegenüber Kapazitäts-Tiers), übergeben Sie --type; andernfalls wird der Standardtyp verwendet:

openstack volume create --size 10 --description 'app data' data-vol01
openstack volume list

Ein frisch erstelltes Volume meldet den Status available – es existiert, ist aber noch an nichts angehängt:

openstack volume show data-vol01 -c status -c size
# | size   | 10        |
# | status | available |

Schritt 2: Das Volume an eine Instanz anhängen

Hängen Sie das Volume an Ihre Instanz an. Nova reicht es dem Gast als neues Block-Device durch, typischerweise /dev/vdb (die nächste freie virtio-Disk):

openstack server add volume web-01 data-vol01
openstack volume show data-vol01 -c status -c attachments
# Status wechselt zu 'in-use'

Schritt 3: Im Gast formatieren und mounten

Das Volume ist nun in der Instanz sichtbar, aber roh. Loggen Sie sich per SSH ein, bestätigen Sie das Device, erstellen Sie ein Dateisystem und mounten Sie es:

ssh -i ~/.ssh/mykey.pem ubuntu@203.0.113.50
lsblk
sudo mkfs.ext4 /dev/vdb
sudo mkdir -p /mnt/data
sudo mount /dev/vdb /mnt/data
df -h /mnt/data

Den Mount dauerhaft machen

Damit er Neustarts übersteht, tragen Sie das Volume über seine UUID statt des Gerätenamens (der sich ändern kann) in /etc/fstab ein:

sudo blkid /dev/vdb
# UUID kopieren, dann:
echo 'UUID=<ihre-uuid> /mnt/data ext4 defaults,nofail 0 2' | sudo tee -a /etc/fstab
sudo mount -a

Schritt 4: Das Volume für Backups snapshotten

Ein Snapshot erfasst das Volume zu einem Zeitpunkt und ist die Basis für Backups und Klone. Für einen crash-konsistenten Snapshot können Sie --force bei angehängtem Volume nutzen – das Dateisystem vorher ruhigzustellen ist jedoch sicherer:

openstack volume snapshot create --volume data-vol01 data-vol01-snap-2026-05-27
openstack volume snapshot list

Zur Wiederherstellung erstellen Sie ein neues Volume aus dem Snapshot und hängen es wie jedes andere an:

openstack volume create --snapshot data-vol01-snap-2026-05-27 --size 10 data-vol01-restored

Schritt 5: Ein Volume vergrößern

Volumes lassen sich auf den meisten Backends online erweitern. Das Wachstum ohne Detach hängt vom Treiber ab; der sichere, universelle Weg ist: abhängen, erweitern, wieder anhängen und dann das Dateisystem im Gast vergrößern:

openstack server remove volume web-01 data-vol01
openstack volume set --size 20 data-vol01
openstack server add volume web-01 data-vol01
# im Gast:
sudo resize2fs /dev/vdb

Verifizierung

Bestätigen Sie, dass das Volume angehängt, gemountet und persistent ist. Nach einem Neustart der Instanz sollten Daten und Mount weiterhin vorhanden sein:

openstack volume list
openstack server show web-01 -c volumes_attached
# im Gast nach dem Neustart:
df -h /mnt/data && ls -la /mnt/data

Häufige Fehler und Fehlersuche

Volume hängt in 'attaching' oder 'detaching'

Das deutet meist auf eine Nova/Cinder-Kommunikationsstörung oder ein ausgelastetes Backend hin. Prüfen Sie den Status mit openstack volume show und die Cinder-Logs; ein Admin kann einen blockierten Zustand mit cinder reset-state zurücksetzen, wenn er sich nicht von selbst löst.

Device im Gast nicht sichtbar

Führen Sie lsblk erneut aus – der Kernel braucht evtl. einen Moment. Erscheint es gar nicht, bestätigen Sie das Anhängen mit openstack server show -c volumes_attached und dass der Gast die virtio-Treiber hat (alle modernen Cloud-Images haben sie).

Volume lässt sich nicht löschen

Ein Volume im Status in-use oder mit Snapshots lässt sich nicht löschen. Hängen Sie es zuerst ab, löschen Sie abhängige Snapshots und dann das Volume.

Quota überschritten

Scheitert die Erstellung an der Quota, haben Sie das Volume-Limit oder die Gigabyte-Grenze des Projekts erreicht. Prüfen Sie mit openstack quota show und räumen Sie auf oder fordern Sie mehr an, wie in Projekt- und Quota-Einrichtung beschrieben.

Aufräumen

openstack server remove volume web-01 data-vol01
openstack volume snapshot delete data-vol01-snap-2026-05-27
openstack volume delete data-vol01

Fazit

Sie haben einer Cloud-Instanz persistenten, snapshotfähigen Block-Storage hinzugefügt und ihn Neustarts, Rebuilds und Größenänderungen überstehen lassen. Auf einem verteilten Speicher wie Ceph sind diese Volumes repliziert und ausfallsicher – das Cloud-Pendant zum flexiblen Speicher, den Sie von Hand mit LVM bauen, aber als Self-Service und API-gesteuert. Kombinieren Sie dies mit Mandanten-Networking und einer laufenden Instanz für einen vollständigen, zustandsbehafteten Workload.

Dieses Ceph-Backend zu betreiben – OSDs dimensionieren, Replikation tunen und Haltbarkeit garantieren – übernimmt clouditiv für Sie auf einer gemanagten On-Premise-Cloud, damit Ihre Volumes standardmäßig ausfallsicher sind und Ihre Daten in Deutschland bleiben.