Speicher – Ergänzungen und Vertiefungen

Blockspeicher vs. Dateispeicher

Analogie

Stell dir den Hypervisor als Lagerverwalter vor.

Beim Blockspeicher (z.B. LVM, iSCSI, Ceph RBD) bekommt der Lagerverwalter einen leeren Bereich, der in nummerierte, gleich große Fächer aufgeteilt ist. Er kann dort VM-Festplatten als große zusammenhängende Blöcke ablegen — aber er kann nicht reinschauen, was drin ist. Er sieht nur "Block 47 bis 520 gehört zu VM-Disk disk-0 von VM 101". Was die VM intern damit macht (ext4 formatieren, Dateien anlegen), ist für den Hypervisor unsichtbar.

Beim Dateispeicher (z.B. Directory, NFS, CephFS) hat der Lagerverwalter ein fertiges Regalsystem mit Ordnern. Er sieht die VM-Disks als einzelne Dateien liegen — zum Beispiel vm-101-disk-0.qcow2 im Ordner images/101/. Er kann die Datei kopieren, verschieben, umbenennen oder sichern, ohne die VM dafür fragen zu müssen. Genau deshalb eignet sich Dateispeicher gut für Backups und ISO-Images.

Kernunterschied aus Hypervisor-Sicht: Kann der Hypervisor die VM-Disks als Dateien sehen und anfassen, oder sind es nur Blockbereiche, die er als Ganzes verwaltet?

Dateisystem auf Blockspeicher?

Ein häufiges Missverständnis: Der Hypervisor legt bei echtem Blockspeicher kein Dateisystem drauf. Er nutzt stattdessen einen Volume Manager (LVM, Ceph RBD, ZFS Zvols), der die Zuordnung von Blöcken zu VMs übernimmt — das ist eine andere Abstraktionsschicht als ein Dateisystem.

LVM/LVM-Thin: Verwaltet logische Volumes direkt als Blockgeräte. Die VM bekommt /dev/dm-X zugewiesen — ein rohes Blockgerät. Da liegt keine Datei vm-101-disk-0.qcow2 in einem Ordner. Die Zuordnung läuft über LVM-Metadaten, nicht über ein Dateisystem.
iSCSI: Der Hypervisor bekommt ein Blockgerät übers Netzwerk und reicht es direkt an die VM durch. Kein Dateisystem auf Hypervisor-Ebene.
ZFS: Sonderfall, da ZFS beides gleichzeitig ist:
- ZFS Dataset → Dateispeicher, qcow2-Dateien liegen darin
- ZFS Zvol → Rohes Blockgerät, kein Dateisystem dazwischen

Copy-on-Write (CoW)

Grundprinzip

Bei einem klassischen Dateisystem wie ext4 wird ein Block direkt überschrieben, wenn eine Datei geändert wird — der alte Inhalt ist danach weg. Bei ZFS passiert das nie:

ZFS schreibt die neuen Daten in einen freien Block
Der Zeiger im Metadaten-Baum wird aktualisiert
Erst danach wird der alte Block als frei markiert

Der ursprüngliche Block wird also nie direkt überschrieben.

Konsistenz ohne Journal

Bei ext4 braucht man ein Journal, das Schreibvorgänge protokolliert, damit nach einem Stromausfall das Dateisystem repariert werden kann. ZFS braucht das nicht — weil der alte Zustand immer intakt bleibt, bis der neue vollständig geschrieben ist.

Entweder der neue Zeiger wurde aktualisiert → neue Daten gelten
Oder nicht → alte Daten gelten (intakt)

Es gibt keinen Zwischenzustand, in dem das Dateisystem inkonsistent sein könnte. Deshalb gibt es bei ZFS auch kein fsck.

Snapshots durch CoW

Wenn ZFS einen Snapshot erstellt, muss es keine Daten kopieren. Es merkt sich einfach: "Die Blöcke, die jetzt existieren, bitte nicht freigeben." Da CoW sowieso nie alte Blöcke überschreibt, bleiben die Snapshot-Blöcke erhalten, während neue Änderungen in neue Blöcke geschrieben werden.

Ein Snapshot kostet initial null zusätzlichen Speicher
Er wächst nur, wenn sich Daten ändern (alte Blöcke werden aufbewahrt statt freigegeben)

Metadaten-Baum (Merkle Tree)

ZFS organisiert alle Daten in einer Baumstruktur:

Jeder Block hat eine Prüfsumme, die im übergeordneten Block gespeichert wird (nicht im Block selbst)
Wenn sich ein Block ändert, muss CoW auch den Eltern-Block neu schreiben (Prüfsumme ändert sich), und dessen Eltern, bis hoch zum Überblock (uberblock) an der Wurzel
Dadurch kann ZFS Korruption auf jeder Ebene erkennen

Auswirkungen in der Praxis

Fragmentierung: Weil Blöcke nie an der gleichen Stelle überschrieben werden, fragmentiert der Speicher über die Zeit. Bei HDDs spürbar, bei SSDs weniger relevant.
Schreib-Amplifikation: Durch das Neu-Schreiben des ganzen Pfads im Baum entsteht bei kleinen Änderungen mehr I/O als bei einem klassischen Dateisystem. Das ist der Preis für Konsistenz und Integrität.

Analogie für den Unterricht

Stell dir ein Notizbuch vor. Ein klassisches Dateisystem radiert eine Zeile aus und schreibt neu drüber — wenn dabei der Strom ausfällt, ist die Zeile halb radiert und unleserlich.

ZFS schreibt die neue Version auf eine frische Seite und ändert erst dann das Inhaltsverzeichnis. Fällt der Strom aus, steht im Inhaltsverzeichnis entweder noch die alte Seite (intakt) oder schon die neue (auch intakt).

Und ein Snapshot? Das ist einfach die Anweisung: "Diese Seite nicht rausreißen, auch wenn wir eine neue Version haben."

Disk-Formate: Raw vs. qcow2

Raw

Ein 1:1-Abbild der virtuellen Festplatte. Wenn einer VM 50 GB zugewiesen werden, wird (bei Thick Provisioning) eine 50-GB-Datei oder ein 50-GB-Logical-Volume angelegt.

Keine Struktur drumherum, keine Metadaten, kein Header — einfach nur rohe Blöcke
Kommt bei Blockspeicher (LVM, Zvols, iSCSI) zum Einsatz, da Blockspeicher kein Dateiformat braucht
Maximale Performance durch direkten Zugriff ohne Indirektion

qcow2 (QEMU Copy-on-Write, Version 2)

Ein intelligentes Container-Format mit Header, Metadaten und Zuordnungstabelle.

Vorteile gegenüber Raw:

Thin Provisioning auf Dateiebene: Eine 50-GB-Disk belegt anfangs nur wenige MB und wächst mit den tatsächlich geschriebenen Daten
Snapshots innerhalb der Datei: qcow2 kann intern mehrere Zustände halten. Bei einem Snapshot wird (ähnlich wie bei ZFS CoW) in einen neuen Bereich geschrieben, der alte bleibt erhalten
Backing Files: Eine Basis-Datei (z.B. ein sauberes Debian-Image) kann als Grundlage dienen, davon abgeleitete qcow2-Disks speichern nur die Unterschiede (Linked Clones)

Nachteil: Kleiner Performance-Overhead durch die Zuordnungstabelle — jeder I/O muss erst aufgelöst werden.

Zusammenhang mit der Speicherart

Speicherart	Format	Thin Provisioning durch
LVM-Thin	Raw	LVM selbst
ZFS Zvol	Raw	ZFS selbst
iSCSI	Raw	Storage-Backend
Directory	qcow2	qcow2-Format
NFS	qcow2	qcow2-Format
ZFS Dataset	qcow2	qcow2-Format

Die Wahl des Disk-Formats hängt direkt mit der Speicherart zusammen: Bei Blockspeicher übernimmt der Volume Manager das Thin Provisioning, deshalb wird Raw genutzt. Bei Dateispeicher muss das Format selbst Thin Provisioning mitbringen, deshalb qcow2.

Proxmox Speicher

Inhaltsverzeichnis