Proxmox-Cluster und SANs: Warum sich Storage nach dem VMware-Exit anders verhält

VMware zu verlassen fühlt sich an, wie ein Pflaster abzureißen. Schmerzhaft, klar, aber alle sagen einem, dass es sich lohnt. Lizenzmüdigkeit, explodierende Kosten und Verträge, die sich plötzlich feindselig anfühlen, sind die bekannten Gründe. Proxmox tritt dagegen ruhig, offen und erfrischend ehrlich auf. Es verspricht Clustering, HA, Live-Migration und eine Zukunft, in der Sie nicht bei jedem Verlängerungszyklus mit einem Vertriebsmitarbeiter verhandeln müssen.

Also tun Sie das Naheliegende: Sie nehmen die Architektur, der Sie seit einem Jahrzehnt vertrauen, einen kleinen SAN-gestützten Cluster, und stecken Proxmox hinein. Gleicher Storage, neuer Hypervisor, klingt einfach. Genau da wird es seltsam.

Denn SAN-gestütztes Proxmox verhält sich nicht wie SAN-gestütztes VMware, selbst wenn technisch alles „funktioniert". Die Lücke liegt bei den Erwartungen und nicht bei der Performance, und sie erwischt viele Teams auf dem falschen Fuß.

Das Problem mit den eingefahrenen VMware-Routinen

Die meisten VMware-Umgebungen haben Admins auf eine ganz bestimmte Denkweise trainiert. Shared Block Storage ist der Mittelpunkt des Universums, Snapshots sind billig, und Thin Provisioning ist unsichtbar. Man überbucht Storage mit Selbstvertrauen und kümmert sich später um die Konsequenzen, in der Praxis also meistens nie.

VMFS schluckt die Komplexität, ohne viel Aufhebens zu machen. Das SAN erledigt seine Magie, und der Hypervisor hält sich raus. Beim Wechsel zu Proxmox gehen viele davon aus, dass diese Arbeitsteilung weiter gilt, das SAN also die Storage-Intelligenz übernimmt und der Hypervisor sie bloß konsumiert. Proxmox verbirgt Storage-Entscheidungen aber nicht, es zwingt Sie, dafür Verantwortung zu übernehmen.

Shared LVM: die erste Überraschung

Die meisten SAN-basierten Proxmox-Cluster starten mit Shared LVM über iSCSI oder Fibre Channel. Das wird unterstützt, ist dokumentiert und stabil, und auf dem Papier erfüllt es die Anforderungen an einen VMware-Ersatz. Es funktioniert auch: Live-Migration, HA und Multipath laufen.

Dann fangen die Fragen an. Warum sind Disks thick provisioniert? Warum fehlen Snapshots oder sind gefährlich? Warum gibt das Löschen einer VM keinen Speicherplatz zurück? An dieser Stelle bricht die eingefahrene VMware-Routine zusammen.

Shared LVM in Proxmox ist bewusst konservativ. Volumes wollen garantierten Speicherplatz, und Snapshots sind keine leichtgewichtigen Metadaten-Tricks, sondern waschechte Copy-on-Write-Strukturen, die sofort aufblähen können. Ein Snapshot einer 1-TB-virtuellen-Disk kann 1 TB Speicherdruck bedeuten, selbst wenn sich nichts ändert.

Thin Provisioning auf SAN-Ebene löst das nicht wie von Zauberhand, denn der Hypervisor sieht es nicht. Proxmox plant Storage so, als wäre er real, reserviert und endlich, und aus seiner Sicht ist er das auch. Admins erwarten Flexibilität, und Proxmox liefert stattdessen Vorhersagbarkeit.

„Aber das SAN macht doch Thin Provisioning"

Dieses Argument kommt oft, und technisch stimmt es. Viele moderne SANs beherrschen Thin Provisioning, Deduplizierung und Kompression hervorragend, geben Blöcke effizient frei und lügen höflich bei der Kapazität. Das Problem ist die Sichtbarkeit.

Mit Shared LVM versteht Proxmox nicht, wie das SAN in Ihrem Namen die Physik austrickst. Es sieht weiterhin ein großes, fixes LUN. Snapshotten Sie eine Disk, bereitet sich Proxmox auf das Worst-Case-Wachstum vor, und löschen Sie eine VM, gibt das SAN womöglich nichts frei, solange Discard nicht perfekt konfiguriert ist.

Diese Diskrepanz erzeugt ein falsches Sicherheitsgefühl. Alles sieht gut aus, bis es das nicht mehr tut, und dann geht es schnell schief.

NFS: die Option, gegen die sich alle wehren und die sie dann doch nutzen

Irgendwann in fast jeder Migration sagt es jemand laut: „Was, wenn wir einfach NFS nutzen?" Darauf folgen meist Stille, mildes Entsetzen und ein paar Witze über die Performance. Trotzdem ist NFS oft die Art, Shared Storage auf Proxmox zu betreiben, die am wenigsten überrascht.

Dateibasierter Storage schaltet qcow2-Disks frei, und damit ein Thin Provisioning, das Proxmox tatsächlich versteht. Snapshots leben innerhalb der Disk-Datei, statt ganze logische Volumes zu belegen, und die Speichernutzung wird sichtbar, vorhersagbar und wiederherstellbar.

NFS ist nicht so schnell wie rohes Block-Storage, nicht so elegant und kann Multipath nicht so wie Fibre Channel. Es verhält sich aber vorhersehbar, und bei einer Migration von VMware zählt das Verhalten mehr als Benchmarks.

Der Snapshot-Realitätscheck

Bei Snapshots prallen Erwartung und Realität am härtesten aufeinander. In VMware sind Snapshots gefährlich, aber trügerisch einfach. Jeder weiß, dass sie keine Backups sind, und jeder nutzt sie trotzdem, weil sie schnell, flexibel und meistens unproblematisch sind.

In Proxmox mit Shared LVM wirken Snapshots wie eine Falle. Es gibt sie, aber sie fühlen sich nicht sicher an, sie skalieren schlecht, und sie können Ihre Storage-Rechnung auf eine Weise sprengen, die VMware nie sichtbar gemacht hat.

Das erzwingt einen Kulturwandel. Teams behandeln VMs wieder wie Vieh, arbeiten mit unveränderlichen Images und externen Backups und setzen Snapshots nur kurzlebig ein, wenn überhaupt. Wiederhergestellt wird per Restore statt per Zurückspulen. Schlechter ist das nicht, nur anders, und anders ist während einer Migration unangenehm.

„Warum nicht einfach Ceph nutzen?"

Sobald der SAN-Schmerz einsetzt, betritt Ceph die Bühne. Ceph ist nativ und integriert, von Grund auf für Proxmox-Cluster entworfen. Es skaliert, heilt sich selbst und macht Shared Storage zum vollwertigen Bestandteil statt zur externen Abhängigkeit.

Kostenlos ist Ceph allerdings nicht, weder bei der Hardware noch beim Netzwerk und ganz sicher nicht bei der operativen Komplexität. Für kleine Cluster mit 2 bis 3 Nodes wirkt es oft wie Overkill, denn es will RAM, schnelle Disks und saubere Netzwerke, und es belohnt Disziplin statt Abkürzungen. Manche Teams lieben es, andere scheitern hart daran. Ceph ist keine Antwort auf SAN-Enttäuschung, sondern eine völlig andere Philosophie.

Das eigentliche Problem ist nicht der Storage

Diesen Teil sagt in Planungsmeetings selten jemand laut: Das eigentliche Problem sind die Annahmen und nicht die SANs.

VMware hat Admins darauf trainiert, nicht mehr über Storage-Mechanik nachzudenken. Proxmox holt diese Mechanik zurück an die Oberfläche. Es schützt Sie nicht vor falscher Rechnung und versteckt Risiko nicht hinter freundlichen Standardeinstellungen. Das fühlt sich wie ein Rückschritt an, bis man sieht, was man dafür bekommt: Transparenz, Kontrolle und weniger versteckte Abgründe. Das hilft aber nur, wenn man darauf vorbereitet ist.

Was erfolgreiche Migrationen gemeinsam haben

Teams, die SAN-gestützte Proxmox-Migrationen zufrieden abschließen, haben meist ein paar Dinge gemeinsam. Sie akzeptieren, dass sich nicht alles eins zu eins von VMware übertragen lässt, und gestalten Storage um die Stärken von Proxmox herum statt um VMware-Nostalgie. Sie behandeln Snapshots als Werkzeuge und nicht als Sicherheitsnetze, und sie planen Kapazität, als würde sie wirklich zählen, denn das tut sie wieder.

Manche landen bei NFS. Manche bleiben bei Shared LVM und passen ihre Erwartungen an. Manche setzen voll auf Ceph. Ein paar mischen lokalen Storage mit Replikation und hören ganz auf, zentralisierter Perfektion hinterherzujagen. Keine dieser Entscheidungen ist falsch. Falsch ist die Annahme, Proxmox verhalte sich unauffällig wie VMware, wenn man nur fest genug die Augen zusammenkneift.

Der Exit lohnt sich, schmerzfrei ist er nicht

Proxmox ist nicht kaputt, SANs sind nicht obsolet, und der Weg weg von VMware bedeutet keine niedrigeren Standards. Er bedeutet aber, neu zu lernen, wo die Leitplanken stehen.

Die Teams, die sich abmühen, sind selten die ohne technisches Können. Es sind die, die erwartet haben, dass die Storage-Schicht unsichtbar bleibt. Proxmox macht sie nicht unsichtbar, sondern ehrlich, und sobald Sie aufhören, dagegen anzukämpfen, ergibt der ganze Stack plötzlich viel mehr Sinn.