Dagegen hilft ja NFS.
Aber nur, wenn die Storage-Hardware das anbietet. Der OP erwähnt eine SAN, die können das ja oft nicht, sondern werden über FibreChannel angebunden. Wenn die Storage-Hardware NFS anbietet, wäre das aber auch meine Empfehlung an den OP, weil das von allen Optionen vmfs am Nächsten kommen dürfte und damit auch Snapshots und thin-provisoning abgebildet werden können.
Persönlich, glaube ich, dass ZFS keine wirklichen mehrwert hier bieten kann, da der SAN im RAID-6 läuft und wir tägliche und wöchentliche Backups machen.
Aber deswegen frage ich, was für meinen Anwendungsfall eventuell besser wäre, da ich aktuell zu LVM-Thin tendiere.
Sowohl ZFS als auch LVM/thin sind NICHT (außer in der Sonderform ZFS-over-iscsi, das muss deine Hardware unterstützen, was die meisten nicht tun) als shared storage geeignet oder willst du deine beiden Knoten nicht in einen Cluster packen? Dann würde sich anbieten eine VM mit dem ProxmoxDatacenterManager anzulegen, dann kann man den nutzen um (auch ohne Cluster) VMs zwischen beiden Knoten hin- und herzumigrieren.
So oder so wäre ich vorsichtig damit nicht dafür gedachte Sachen (wie ZFS oder lvm/thin) für Netzwerkstorage zu verwenden.
LVM/thick wäre also der way to go, wobei der Snapshot support dafür noch in "tech preview" ist und man einiges bedenken muss. Die Details stehen in den bereits verlinkten Artikeln von bbgeek17 bei Blockbridge. Grob gesagt: Die Verwendung dieses Features kann in relevanten Maße Performance kosten (muss man also mal mit und ohne vergleichen) und es gibt noch einige Kinderkrankheiten. Darum ist es ja auch noch in "technology preview".
Da fehlt außerdem noch ein dritter Knoten fürs Quorum, das muss aber kein ausgewachsener Server sein, dafür kann man auch einen alten Rechner, einen Raspberry oder Mini-PC nehmen:
https://pve.proxmox.com/wiki/Cluster_Manager#_corosync_external_vote_support
Eine beliebte Variante ist es, als quorum einen ProxmoxBackupServer zu nehmen (der kann gerne ein schwachbrüstiger alter Server sein, außer Backup macht der ja nichts), wie sowas aussehen kann hat der Proxmox Mitarbeiter aaron mal im englischen Forum beschrieben:
https://forum.proxmox.com/threads/2-node-ha-cluster.102781/post-442601
Er hat einen dritten Knoten auf deutlich schwächerer Hardware als sein Cluster, darauf werden der BackupServer und eine single-node von ProxmoxVE installiert, um das ganze sauber vom eigentlichen Cluster zu trennen (sonst würde ein Hacker mit Zugriff auf das eine auch ins Andere kommen, das will man vermeiden). Das Qdevice läuft dann in einen Container oder VM in ProxmoxVE.
Das Interessante am BackupServer ist nun, dass selbst wenn man ihn für das Backup nicht braucht, man ihn als Quasiersatz für Snapshots nutzen kann (nicht für jeden usecase, aber das häufige "Snapshot vor Update, Update machen, falls nötig zurück auf alten Stand" wird damit gut abgedeckt), da das Snapshot-Backup einen vom Storage unabhängigen Mechanismus des qemu/kvm Hypervisors/Emulators nutzt. Mit PBS gibt es die Möglichkeit des live-restores, das heißt nach dem Restore startet die VM sofort (keine Downtime) und lädt dann den Rest während des Restores nach Bedarf nach, dauert dann halt etwas:
https://pve.proxmox.com/wiki/Migrate_to_Proxmox_VE#Alternatives_to_Snapshots
Wie macht ihr denn eure Backups aktuell? Und testet ihr auch die restores regelmäßig, sonst nützen die Backups einen wenig
Wenn ihr keine SAN hättet, würde ich tatsächlich für so ein kleines System zu ZFS storage replication raten, also in beiden Servern möglichst dicke Enterprise-SSDs mit powerloss-protection im Mirror (NICHT RAIDZ, das ist ok für Datengräber, nicht für VM-Workloads:
https://forum.proxmox.com/threads/fabu-can-i-use-zfs-raidz-for-my-vms.159923/). Die Replikation synchronisiert dann regelmäßig zwischen beiden Servern. Eine Migration bei der Wartung eines Knoten geht dann recht flott (da nur noch alle Änderungen seit letzten Sync übertragen werden müssen) und beim Ausfall eines Knotens fährt die VM auf den anderen Knoten mit dem letzten übertragenen Stand fort (man hat also einen kleinen Datenverlust, standardmäßig werden die VMs alle 15 Minuten repliziert, das kann man auf eine Minute reduzieren oder bei (weniger wichtigen Diensten) auch erhöhen). Wenn der dabei zwangsläufig auftretende minimale Datenverlust nicht akzeptabel ist, ist das aber natürlich keine Option, aber hier im Forum wird immer mal wieder von kleineren Setups berichtet, wo die Leute damit ganz glücklich sind. Und nicht nur Privatanwender, Proxmox selbst haben auf ihrer Seite eine success story einer portugiesischen Online-Apotheke:
https://www.proxmox.com/en/about/about-us/stories/story/farmacia-nova-da-maia ZFS oder lvm/thin (falls auf dem lokalen Rechner HW-Raid zum Einsatz kommen soll, sonst würde ich aus den von Udo genannten Gründen zu ZFS tendieren) kann auch noch ein anderer Ansatz für einen Workaround in Sachen Snapshots dienen: Man kann im laufenden Betrieb VM-platten zwischen Storages verschieben, es wäre also folgendes möglich:
- Backup der VM außerhalb der Reihe anlegen (für alle Fälle)
- Storage auf lokalen Speicher des Knotens (ZFS/lvm/thin...) verlagern, Snapshot machen
- Wartungsarbeiten durchführen, für die man den Snapshot machen wollte
- Falls nötig Snapshot einspielen, oder löschen
- Storage wieder auf SAN migrieren
- Sollte der lokale Knoten samt VM-Daten genau in dem Zeitraum abrauchen->Backup aus 1. Schritt einspielen
- Allerdings könnte man auch direkt nur mit Backup als Snapshotersatz arbeiten...
