# Proxmox Storage-Architektur: Wo Ihre Daten wirklich wohnen

TL;DR / Management Summary In Proxmox VE gibt es kein “Universal-Storage”. Die Wahl des Backends hängt von zwei Faktoren ab: Performance und Verfügbarkeit. Während lokales ZFS die beste Performance für Einzelknoten bietet, ermöglicht Shared Storage (NFS, iSCSI, Ceph) erst die Magie der Hochverfügbarkeit (HA) und Live-Migration. Ein Senior Admin versteht den I/O-Pfad vom Gast-Betriebssystem bis auf die physische Platter/Zelle und optimiert diesen für die jeweilige Workload.

# 1. Das Storage-Modell: Block vs. Datei

Proxmox unterscheidet strikt zwischen zwei Arten von Speicher-Backends. Die Wahl beeinflusst, welche Features (Snapshots, Clones) verfügbar sind.

# Architektur-Übersicht (Mermaid)

graph TD
    subgraph F[File-Level Storage - Shared/Local]
        NFS[NFS / SMB]
        DIR[Local Directory - ext4/xfs]
        QCOW2[.qcow2 Dateien]
    end

    subgraph B[Block-Level Storage - Shared/Local]
        ZFS[ZFS - ZVOL]
        LVM[LVM-Thin]
        CEPH[Ceph RBD]
        RAW[Raw Devices / iSCSI]
    end

    subgraph V[Features]
        SNAP[Snapshots]
        CLONE[Cloning]
        THIN[Thin Provisioning]
    end

    QCOW2 --> SNAP & CLONE & THIN
    ZFS --> SNAP & CLONE & THIN
    CEPH --> SNAP & CLONE & THIN
    LVM --> SNAP & CLONE & THIN
    RAW -.-> |Eingeschränkt| V

1. File-Level (Datei-basiert): Speichert virtuelle Disks als Dateien (meist .qcow2). Flexibel, aber mit leichtem Overhead durch das Host-Dateisystem. Ideal für ISOs und Backups.
2. Block-Level (Block-basiert): Die VM schreibt direkt auf logische Volumes. Minimale Latenz, maximale Performance. Ideal für Datenbanken und High-Performance Workloads.

# 2. Lokaler Hochleistungsspeicher: ZFS

ZFS ist der Goldstandard für lokalen Speicher in Proxmox.

# Warum ZFS?

• ARC (Adaptive Replacement Cache): Nutzt RAM als intelligenten Lese-Cache.
• Copy-on-Write (CoW): Snapshots kosten keinen Platz und keine Performance im Moment der Erstellung.
• Checksumming: Jeder Block wird mit einer Prüfsumme versehen. “Silent Data Corruption” (Bit-Rot) wird beim Lesen erkannt und (bei Spiegelung) automatisch repariert.

Senior Tipp: Das Sync-Problem Datenbanken fordern oft “Synchronous Writes” an (Sicherstellung, dass Daten physisch auf dem Platter liegen). Auf SSDs ohne Power-Loss Protection (PLP) führt dies zu einem massiven Performance-Einbruch.

• Lösung: Nutzen Sie eine dedizierte Enterprise-NVMe als SLOG (ZFS Intent Log) oder nutzen Sie Enterprise-SSDs mit PLP als Hauptspeicher.

# 3. Hochverfügbarer Speicher: Ceph

Ceph ist ein verteiltes, objektbasiertes Storage-System, das direkt in Proxmox integriert ist. Es verwandelt die lokalen Festplatten mehrerer Knoten in einen riesigen, redundanten Speicherpool.

# Ceph Replikations-Prinzip (Mermaid)

graph TD
    subgraph N1[Node 1]
        D1[OSD 1 - Disk]
        O1[Object A - Primär]
    end
    subgraph N2[Node 2]
        D2[OSD 2 - Disk]
        O2[Object A - Kopie 1]
    end
    subgraph N3[Node 3]
        D3[OSD 3 - Disk]
        O3[Object A - Kopie 2]
    end

    Client[VM Write Request] --> O1
    O1 --> O2
    O1 --> O3
    Note over Client,O3: Replikationsfaktor 3: Daten sind 3x vorhanden

Anforderungen für Ceph:

• Mindestens 3 Knoten (besser 5+).
• Dediziertes 10 Gbit/s Netzwerk (besser 25G+).
• Nur SSDs/NVMes (HDDs sind für moderne Ceph-Workloads zu langsam).

# 4. Klassischer Shared Storage: NFS & iSCSI

Wenn Sie ein zentrales NAS/SAN (z.B. TrueNAS, NetApp, Dell ME5) haben, binden Sie dieses via NFS oder iSCSI an.

• NFS: Einfach zu handhaben, dateibasiert. Gut für ISOs und mittlere Workloads.
• iSCSI: Block-basiert, hohe Performance. Erfordert Multipathing für Ausfallsicherheit.
• Vorteil: Ermöglicht Live-Migration zwischen Knoten in Sekunden, da nur der CPU/RAM-Status übertragen werden muss, nicht die virtuelle Festplatte.

# 5. Day-2 Operations: Storage-Optimierung

# Discard / TRIM

In einer virtualisierten Welt ist es wichtig, dass die VM dem Host mitteilt, wenn sie Speicherplatz freigibt.

1. Nutzen Sie den VirtIO-SCSI Controller.
2. Aktivieren Sie die Option Discard an der virtuellen Disk.
3. In der VM (Linux): Nutzen Sie fstrim -av oder die Mount-Option discard.

# I/O-Threads

Aktivieren Sie die Option IO-Thread für virtuelle Disks. Dies erlaubt QEMU, für jede Disk einen eigenen Thread im Host-OS zu starten, was die Parallelität massiv verbessert.

# 6. Troubleshooting & “War Stories”

# Der “Stale Mount” GAU

Szenario: Ein NFS-Server wurde gewartet und neu gestartet. Symptom: Das Proxmox-GUI “fror” ein, und Befehle wie pvesm status hingen endlos. Ursache: Linux NFS-Mounts im “Hard”-Modus blockieren alle Prozesse, die auf den Mount zugreifen wollen, wenn der Server weg ist. Lösung: Konfigurieren Sie NFS-Mounts immer mit der Option soft oder nutzen Sie ein dediziertes Storage-Netzwerk, das stabil bleibt.

# Die “ZFS-Full” Katastrophe

Szenario: Ein Admin füllte seinen ZFS-Pool zu 98%. Symptom: Die Performance brach um 90% ein. Snapshots konnten nicht mehr gelöscht werden. Ursache: ZFS ist ein Copy-on-Write Dateisystem. Zum Löschen von Daten muss ZFS neue Metadaten schreiben. Wenn kein Platz mehr da ist, kann ZFS nicht mehr löschen. Lösung: Halten Sie ZFS-Pools immer unter 80% Füllstand. Wenn es passiert: Erstellen Sie kurzzeitig ein leeres File, löschen Sie es und nutzen Sie den minimalen Platzgewinn, um Snapshots zu entfernen.

# 7. Experten-Checkliste für Proxmox Storage

• [ ] Thin Provisioning aktiv (spart massiv Platz)?
• [ ] VirtIO-SCSI mit Discard konfiguriert?
• [ ] ZFS ARC limitiert (Artikel 661)?
• [ ] 10G+ Netzwerk für Ceph oder Shared Storage vorhanden?
• [ ] Backup-Target physisch getrennt vom Produktiv-Storage?

# Anhang: Referenzen & Links

• Proxmox VE: Storage Documentation (Official)
• Ceph Architecture Guide
• OpenZFS: Performance Tuning