Direkt zum Hauptinhalt

Proxmox Vergleich der Storage-Varianten vs. ZFS zu Fuß

Vergleich der Storage-Varianten

Funktion/Eigenschaft Ceph RBD Lokales ZFS iSCSI + LVM thick
Gemeinsamer Cluster-Storage Ja Nein Ja
Verteilte Speicherung Ja Nein Nur wenn das SAN sie bereitstellt
Kein einzelner Storage-Kopf als Ausfallpunkt Ja, korrekt aufgebaut Nein Abhängig vom SAN
Thin Provisioning Ja Optional mit sparse Nein
Feste Platzreservierung Möglich/steuerbar Ja, über Reservation Standard
Proxmox-Snapshots Ja Ja Ab PVE 9 für VMs über Volume Chains
Linked Clones Ja Ja Nein
Full Clones Ja Ja Ja
VM- und LXC-Datenträger Ja Ja Ja, über LVM
Schnelle Live-Migration ohne Kopieren der VM-Platte Ja Nein Ja
Migration mit Kopieren des Storage Ja Ja Ja
Proxmox-Storage-Replikation Nicht nötig; Ceph repliziert intern Ja, asynchron zwischen Nodes Normalerweise durch das SAN
Selbstheilung Ja Lokal innerhalb des ZFS-Pools Aufgabe des SAN
Prüfsummen gegen stille Datenfehler Ceph-intern Nativ durch ZFS Abhängig vom SAN
Administration hauptsächlich in PVE Sehr gut integriert Sehr gut integriert Gut, SAN bleibt separat
Typischer Einsatz Größerer HA-Cluster Einzelserver oder kleiner Cluster Bestehendes zentrales SAN

Ceph RBD ist shared, thin-provisioned, redundant, selbstheilend und unterstützt Snapshots sowie Clones. Lokales ZFS unterstützt ebenfalls Snapshots und Clones, ist aber nicht shared. Reines iSCSI bietet selbst keine Speicherverwaltung; Proxmox empfiehlt deshalb normalerweise eine große LUN mit LVM darüber. Proxmox Storage-Dokumentation

Besonderheit bei iSCSI

Man muss drei Varianten auseinanderhalten:

  1. Direktes iSCSI

    • Fertige LUN pro VM beziehungsweise bereits auf dem SAN angelegte LUNs
    • Shared Storage
    • Keine nativen Proxmox-Snapshots oder Clones
  2. iSCSI + klassisches LVM („thick“)

    • Eine große gemeinsame LUN
    • Proxmox erzeugt darin Logical Volumes
    • Speicherplatz wird fest zugeteilt
    • Clusterweites Locking durch Proxmox
    • Seit Proxmox VE 9 sind VM-Snapshots als qcow2-Volume-Chain möglich; keine effizienten LVM-thin-Snapshot
  1. ZFS over iSCSI

    • ZFS läuft auf dem entfernten Storage-Server
    • Proxmox erzeugt dort per SSH ZVOLs und exportiert diese als iSCSI-LUNs
    • Shared und snapshotfähig
    • Nicht dasselbe wie gewöhnliches iSCSI+LVM
    • Der ZFS-Storage-Server kann ohne HA-Konzept zum Single Point of Failure werden

Populäre Proxmox-Funktionen und ihre Storage-Abhängigkeit

Proxmox-Funktion Ceph Lokales ZFS iSCSI thick
KVM-VMs und LXC-Container
HA-Neustart auf anderem Node Nur mit Replikat oder Storage-Wiederherstellung
Live-Migration Sehr gut Mit Plattenkopie Sehr gut
VM-Snapshot einschließlich RAM-Zustand Eingeschränkt bzw. versionsabhängig
Template und Linked Clone Kein Linked Clone
Backup mit Proxmox Backup Server
Storage-Migration
VM-Festplatte online vergrößern
Automatische Storage-Replikation Ceph-intern pvesr/ZFS send-receive SAN-intern
Zentraler Betrieb über Weboberfläche/API