Warum Organisationen nicht auf Proxmox wechseln

Seit der Übernahme von VMware durch Broadcom taucht Proxmox in jedem Gespräch über Infrastruktur-Kostensenkung auf. Die Lizenzrechnung sieht verlockend aus: ein Bruchteil der VMware Enterprise Plus-Preise, Open Source, voller Funktionsumfang. Kostenbewusste CTOs fragen sich, warum sie nicht einfach wechseln sollten.

Hier ist die ehrliche Antwort: nicht als Drop-in-Ersatz.

Proxmox tauscht Hersteller-Leitplanken gegen volle Kontrolle. Dieser Tausch hat reale Kosten: in Fachwissen, Tooling und operativer Reife. Organisationen, die Proxmox als direkten Austausch betrachten, haben typischerweise Schwierigkeiten. Organisationen, die es als Plattformwechsel angehen, mit entweder interner Expertise oder einem Managed Partner, haben Erfolg.

Nach drei Jahren Proxmox in Produktion mit über 1000 VMs bei Natron zeigen wir, was die meisten Evaluationen falsch einschätzen.

Proxmox hat keine Leitplanken und genau das ist der Punkt (und das Problem)

VMware nimmt Sie an die Hand. Es gibt eine Hardware Compatibility List. Es gibt validierte Referenzarchitekturen. VMware warnt Sie, blockiert Sie oder verweigert schlicht den Dienst, wenn Ihr Setup die Anforderungen nicht erfüllt. Für viele Unternehmen kann genau das ein zweischneidiges Schwert sein.

Proxmox lässt Sie alles tun. Jede Hardware, jede Konfiguration, jede Topologie. Zwei-Node-Cluster ohne Quorum Device? Kein Problem. Consumer-SSDs als Ceph Journals? Nur zu. Cluster mit mehr VMs überladen, als er verkraften kann? Bitte sehr. Proxmox wird Sie nicht aufhalten. Es geht davon aus, dass Sie wissen, was Sie tun.

Das ist ein bedeutender Kompromiss.

Die Freiheit, eigene Hardware, eigenes Netzwerkdesign und eigenes Storage-Layout zu wählen, bedeutet: Sie können genau die Infrastruktur bauen, die Sie brauchen, optimiert für Ihre Workloads und Ihr Budget. Kein Hersteller, der Ihnen sagt, dass Ihre einwandfreien Server nicht auf der freigegebenen Liste stehen. Keine erzwungenen Hardware-Refresh-Zyklen, weil sich eine Kompatibilitätsmatrix geändert hat.

Aber es bedeutet auch: Proxmox geht davon aus, dass Sie wissen, was Sie tun. Es gibt keinen Wizard, der Ihre Architektur validiert. Keine Pre-Flight-Prüfung, die Ihnen sagt, dass Ihr Ceph-Netzwerk unterdimensioniert ist oder Ihr HA Fencing mit dieser Hardware nicht funktionieren wird. Sie sind die Leitplanke.

Genau hier kommen viele VMware-Migrationen ins Stocken. Teams, die eine Plattform gewohnt sind, die sie in gute Entscheidungen lenkt, haben plötzlich totale Freiheit und totale Verantwortung. Sie brauchen fundiertes Wissen in Linux, Networking, Storage und Hardware. Sie müssen verstehen, warum ein Design funktioniert, nicht nur einem Referenzhandbuch des Herstellers folgen.

Das ist keine Kritik. Es ist der Hauptgrund, warum Organisationen den Schritt nicht wagen. Wenn Ihr Team starke Linux- und Infrastruktur-Kompetenzen hat (oder einen Managed Proxmox Partner, der diese mitbringt), ist die Freiheit eine Superkraft.

HA klingt einfach. Ist es nicht.

Proxmox hat integrierte High Availability. Häkchen setzen, VM einer HA-Gruppe zuweisen, fertig. Wenn ein Node ausfällt, startet die VM auf einem anderen Node neu.

In der Theorie.

In der Praxis braucht Corosync zuverlässige, latenzarme Verbindungen zwischen den Nodes. Wenn diese Verbindungen instabil werden, entstehen Split-Brain-Szenarien, und Split-Brain in einem Hypervisor-Cluster ist die Art von Problem, die Ihren Tag ruiniert.

Was wir auf die harte Tour gelernt haben:

• Redundante Corosync Links. Corosync ist der Herzschlag Ihres Clusters. Ein einziger Link, der im falschen Moment instabil wird, kann einen Split-Brain auslösen. Redundanz ist keine Option, sondern Pflicht.
• Failover-Tests müssen durchgeführt werden. Konfiguriertes HA ist nicht validiertes HA. Ziehen Sie ein Stromkabel, simulieren Sie eine Netzwerkpartition, schalten Sie einen Node aus. Wenn Sie es nicht getestet haben, wissen Sie nicht, ob es funktioniert.
• Kapazitätsplanung der Ressourcen. Wenn ein Node ausfällt, starten seine VMs auf den verbleibenden Nodes neu. Wenn diese bereits bei 80% Auslastung laufen, haben Sie keinen HA-Cluster: Sie haben einen Cluster, der zweimal ausfällt.

HA ist essenziell. Aber behandeln Sie es als etwas, das Sie planen, nicht als etwas, das Sie aktivieren.

Monitoring ist kein Nice-to-have: Es ist das Produkt

Die integrierte Proxmox-Oberfläche zeigt Ihnen das Nötigste: CPU-Graphen, Speicherverbrauch, ein Task-Log. Das reicht, um zu wissen, dass etwas kaputt ist. Es sagt Ihnen nichts darüber, warum, nichts darüber, was als Nächstes ausfallen wird, und nichts darüber, ob Ihr Cluster gesund ist oder nur ruhig.

In der Produktion ist die eigentliche Arbeit nicht die Installation eines Monitoring-Stacks. Es geht darum herauszufinden, was Sie wirklich überwachen müssen. Proxmox gibt Ihnen keine fertige Antwort. Sie müssen selbst erarbeiten, welche Signale relevant sind: Hält Ihr Storage-Netzwerk mit, oder drosselt es die VM-Performance im Stillen? Sind Ihre OSD-Disks gesund oder degradieren sie unbemerkt? Ist Ihr HA Fencing unter realen Ausfallbedingungen zuverlässig oder nur unter den Bedingungen, die Sie getestet haben?

Das braucht Zeit und Vorfälle. Sie lernen, was Sie überwachen müssen, indem Sie auf Probleme stossen, die Sie nicht kommen sahen. Jeder Produktionsvorfall lehrt Sie etwas, das zu einem Alert oder einem Dashboard werden sollte. In drei Jahren haben wir dieses Wissen aufgebaut. Wir wissen, welche Metriken Ausfälle vorhersagen, bevor sie eintreten, und welche Alerts nur Rauschen sind.

Das ist eine der grösseren Lücken bei einer VMware-Migration. VMware kommt mit Jahrzehnten an Tooling, Integrationen und zertifizierten Beratern, die Ihr Problem schon einmal gesehen haben. Proxmox kommt mit einer grossartigen Plattform und einem leeren Blatt. Sie müssen die Observability-Schicht selbst aufbauen, und es braucht echte Produktionserfahrung, um sie gut aufzubauen.

Ceph Storage: Das Fundament, das stimmen muss

Die meisten grösseren Proxmox-Deployments setzen Ceph für verteilten Storage ein. Es ist tief integriert, Open Source und skaliert horizontal. Es ist aber auch die Komponente, die die sorgfältigste Konfiguration erfordert, um im grossen Massstab zuverlässig zu laufen.

Was wir beim Betrieb von Ceph in Produktion gelernt haben:

• Netzwerktrennung ist nicht verhandelbar. Ceph braucht ein eigenes, dediziertes Netzwerk, getrennt von VM-Traffic und Management. Wir verwenden 25-Gbit-Links für das Ceph-Cluster-Netzwerk und 10 Gbit für das Public Network. Ceph und VM-Traffic auf denselben Links zu mischen, führt zu Latenzspitzen während des Rebalancings.
• OSD-Anzahl und Dimensionierung sind entscheidend. Wir standardisieren auf Enterprise-NVMe-Drives, 3.84 TB, 7.68 TB oder 15.36 TB pro OSD. Consumer-Drives sind keine Option für Produktions-Workloads.
• Recovery Thundering Herd. Wenn ein OSD ausfällt, rebalanciert Ceph die Daten über die verbleibenden Drives. Ist Ihr Cluster bereits zu über 90% ausgelastet, konkurriert dieses Rebalancing mit dem Produktions-I/O und kann den gesamten Cluster degradieren. Wir halten eine strikte Kapazitätsobergrenze ein.
• Placement Groups sind entscheidend. Zu wenige PGs bedeuten ungleichmässige Datenverteilung. Zu viele bedeuten, dass Ihre OSDs mehr Zeit mit PG-Verwaltung verbringen als mit I/O. Die Formel ist nicht kompliziert, aber es im grossen Massstab zu korrigieren, ist schmerzhaft.

# Check Ceph cluster health and capacity
ceph status
ceph df
ceph osd pool ls detail

# Monitor OSD performance
ceph osd perf

# Check for slow OSDs (common precursor to disk failure)
ceph daemon osd.0 perf dump | jq '.osd.op_latency'

Ceph ist keine Black Box. Es sagt Ihnen alles, wenn Sie wissen, wo Sie schauen müssen. Die Herausforderung ist, das Monitoring und Alerting aufzubauen, das diese Signale in handlungsrelevante Erkenntnisse verwandelt, bevor sie zu Incidents werden.

Die wahren Kosten einer VMware-Migration

Lizenzeinsparungen sind der Gesprächseinstieg. Aber die Gesamtkosten einer Proxmox-Migration umfassen weit mehr als Lizenzgebühren.

Die Organisationen, die den besten ROI mit Proxmox erzielen, sind diejenigen, die entweder in ein dediziertes Plattform-Team investieren oder mit einem Managed Proxmox Provider zusammenarbeiten, der das operative Wissen vom ersten Tag an mitbringt.

Erfolgreich migrieren: Eigenaufbau oder Partner

Nach drei Jahren und Dutzenden von Kundenprojekten sehen wir zwei Wege, die funktionieren:

Weg 1: Intern aufbauen. Investieren Sie in 2-3 Engineers mit fundiertem Wissen in Linux, Networking und Storage. Planen Sie 6-12 Monate Lernkurve ein und budgetieren Sie entsprechend. Dieser Weg funktioniert für Organisationen mit 50+ Servern, die volle Kontrolle wollen und die Talent-Pipeline haben, um das langfristig aufrechtzuerhalten.

Weg 2: Mit einem Managed Provider zusammenarbeiten. Nutzen Sie die dreijährige Produktionserfahrung eines Partners. Erhalten Sie eine validierte Architektur, einen Monitoring-Stack und operative Runbooks vom ersten Tag an. Ihr Team konzentriert sich auf das, was auf der Plattform läuft, nicht auf die Plattform selbst. Dieser Weg funktioniert für Organisationen jeder Grösse, die die Kostenvorteile von Proxmox wollen, ohne die Expertise von Grund auf aufzubauen.

Beide Wege funktionieren. Der Ansatz, der typischerweise in Schwierigkeiten führt, ist Proxmox wie VMware zu behandeln: darauf zu vertrauen, dass die Plattform einen leitet, zu wenig in Monitoring zu investieren und die HA-Validierung zu überspringen. Ohne diese Grundlagen funktioniert die Migration selten dauerhaft.

Was wir selbst noch herausfinden

Ehrlichkeit ist wichtig. Nach drei Jahren gibt es immer noch schwierige Themen:

• DRS-ähnliches Workload-Balancing. Proxmox HA startet VMs auf anderen Nodes neu, verteilt Workloads aber nicht automatisch über den Cluster. Proxmox arbeitet daran, aber aktuell ist es ein manueller Prozess sicherzustellen, dass der Cluster ausgewogen und nicht überlastet ist.
• Enterprise-Backup-Integration. Proxmox Backup Server ist solide für die Grundlagen, aber die Integration mit Enterprise-Backup-Tools (Veeam, Commvault) erfordert Aufwand. Das Ökosystem verbessert sich schnell, ist aber noch nicht auf VMware-Niveau.
• Multi-Site Ceph. Stretched Clusters über Rechenzentren hinweg sind möglich, aber operativ komplex. Wir betreiben derzeit standortlokale Ceph Clusters mit Replikation auf Anwendungsebene.
• GPU Passthrough im grossen Massstab. Einzelnes GPU Passthrough funktioniert gut. Die Verwaltung einer Flotte von GPU-fähigen VMs mit Live Migration ist im Vergleich zu VMwares ausgereiftem vGPU-Ökosystem noch ein manueller Prozess.

Das sind keine Dealbreaker. Es sind Bereiche, in denen das Ökosystem jünger ist und mehr operativen Einsatz erfordert. Wir teilen sie, weil Organisationen wissen sollten, worauf sie sich einlassen.

Sie müssen das nicht alleine herausfinden

Die Wissenslücke ist genau das, was wir bei Natron schliessen. Wir sind kein Reseller, der letzte Woche die Dokumentation gelesen hat. Wir sind Engineers, die Proxmox seit drei Jahren in Produktion betreiben, mit der operativen Geschichte, die das belegt.

Was die Zusammenarbeit mit uns bedeutet:

• Managed Proxmox Clusters: Wir designen, deployen, überwachen und warten Ihre Umgebung, damit sich Ihr Team auf das konzentrieren kann, was auf der Plattform läuft, nicht auf die Plattform selbst.
• Migrationsunterstützung: Ob Sie von VMware, Hyper-V oder Bare Metal kommen, wir haben es schon gemacht und wissen, wo die Fallstricke liegen.
• Ein echter Monitoring-Stack vom ersten Tag an: Prometheus, Grafana, Alertmanager, massgeschneiderte Dashboards. Kein Häkchen zum Abhaken, sondern derselbe Stack, den wir für unsere eigene Infrastruktur einsetzen.
• Zuerst ein ehrliches Gespräch: Wir sagen Ihnen, ob Proxmox für Ihre Workloads passt. Wenn nicht, sagen wir das lieber im Voraus, als Ihnen etwas zu verkaufen, das nicht funktioniert.

Wir sind Natron mit Sitz in Bern. Wir bauen und betreiben die Natron Cloud: Managed Cloud-Infrastruktur auf Proxmox für Unternehmen, die digitale Souveränität ohne den operativen Aufwand wollen.