Virtuelle Maschine, Container oder Bare Metal? Die passende Betriebsform ergibt sich aus der Anwendung, ihrer Herstellerfreigabe und dem Team, das sie dauerhaft betreibt. Ein Container macht ein altes ERP nicht automatisch wartbar. Ein physischer Server ist nicht automatisch schneller. Und eine VM ist keine Ausrede, um Backup und Updates zu vernachlässigen. DAXS beginnt deshalb mit dem konkreten Workload: Betriebssystem, Abhängigkeiten, Daten, Wiederanlauf und messbare Last.
Dieser Vergleich beantwortet die Frage, wo ein Dienst sinnvoll läuft. Wenn die Entscheidung für Anwendungscontainer bereits gefallen ist, folgt die andere Frage: Docker Compose oder Kubernetes für den Betrieb? Beide Schritte sollten getrennt entschieden werden.
Was wird überhaupt voneinander getrennt?
Eine virtuelle Maschine erhält virtuelle Hardware und ein eigenes Gastbetriebssystem. Das erlaubt beispielsweise einen Windows-Server-Gast neben Linux-Gästen auf demselben Hypervisor. Die VM ist eine gut abgrenzbare Einheit für Betriebssystem-Patches, Snapshots und Wiederherstellung; ihre Anwendung muss trotzdem konsistent gesichert werden. Auf Proxmox VE basiert dieser Weg auf KVM.
Ein Container teilt sich den Kernel des Hosts. Dabei sind zwei Betriebsformen auseinanderzuhalten: Ein Proxmox-LXC-Container ist ein leichtgewichtiges Linux-System, ein OCI-Anwendungscontainer verpackt üblicherweise eine einzelne Anwendung mit ihren Abhängigkeiten. Beide sind keine Windows-VMs und ersetzen keine eigene Kernel-Isolation. Für OCI-Container braucht das Team zusätzlich einen gepflegten Image-Build, eine Registry, Sicherheitsupdates und eine bewusste Lösung für persistente Daten. Eine Linux-VM als Container-Host kann eine sinnvolle Grenze für Betrieb, Backup und Rechte sein; sie ist keine technische Pflicht in jedem Szenario.
Bare Metal führt Betriebssystem und Anwendung direkt auf einem physischen Server aus. Das kann bei Herstellerbindungen, spezieller Hardware oder nachgewiesenen Latenzanforderungen passend sein. Es nimmt aber die Konsolidierung des betreffenden Hosts zurück und verlagert Wartungsfenster, Ersatzteile und Wiederanlauf stärker auf die physische Maschine. Auch hier entscheiden Messung und Supportzusage statt einer pauschalen Performancebehauptung.
Fünf typische Workloads und ihre erste Prüfspur
Die folgenden Wege sind Ausgangspunkte für einen Test, keine allgemeine Freigabe eines Produkts. Erst Herstellerdokumentation, Lizenzvertrag und ein Wiederherstellungstest machen daraus eine belastbare Entscheidung.
| Anwendung | Prüfspur | Kritische Frage |
|---|---|---|
| Windows-ERP mit Datenbank und Hersteller-Support | VM als naheliegender Startpunkt | Welche Gast-OS-, Hypervisor-, SQL- und Lizenzkombination ist tatsächlich freigegeben? |
| Eigener Linux-Webdienst mit reproduzierbarem Build | OCI-Anwendungscontainer, gegebenenfalls auf Linux-VM | Wer baut und aktualisiert Images, prüft Schwachstellen und betreibt Registry, Secrets und Logs? |
| Linux-Appliance eines Herstellers | Zuerst freigegebene VM prüfen | Akzeptiert der Hersteller Virtualisierung, virtuelle Geräte und den vorgesehenen Backup-/Restore-Weg? |
| Datenbank mit hoher Schreiblast | VM oder Bare Metal anhand Messwerten; Container nur mit getesteter Persistenz | Wie verhalten sich p95-/p99-Latenz, IOPS, Replikation und konsistenter Restore unter Spitzenlast? |
| Dienst mit Dongle, Spezialkarte oder direktem Gerätezugriff | VM-Passthrough testen; Bare Metal als Kandidat | Bleiben Hersteller-Support, Gerätezuordnung und Wiederanlauf nach einem Hosttausch möglich? |
Ein Datenbankcontainer ist nicht grundsätzlich falsch. Sein beschreibbares Container-Dateisystem ist aber nicht der Ort für Daten, die nach dem Ersetzen des Containers erhalten bleiben müssen. Volumes, Konsistenzverfahren, Backup und Restore sind explizit zu planen. Umgekehrt macht eine VM aus einer ungetesteten Datenbank-Sicherung noch keinen verlässlichen Wiederanlauf.
Die Entscheidung in sechs Prüfungen
- Hersteller und Lizenz: Unterstützte Betriebssysteme, Hypervisoren, Container-Runtimes und Hardwarebindungen schriftlich prüfen. Gerade Windows-Server-Rechte hängen unter anderem von Edition, lizenzierten Kernen, Zahl der virtuellen Umgebungen und Vertragsform ab; aus „eine VM“ folgt kein Pauschalpreis.
- Isolation und Berechtigungen: Welcher Dienst darf welchen anderen beeinflussen? Container haben Namespaces und Ressourcenbegrenzungen, teilen aber den Host-Kernel. Laufzeit, Privilegien, Mounts, Netzwerk und Updates gehören in die Sicherheitsprüfung.
- Leistung messen: CPU-, RAM- und I/O-Last, p95-/p99-Latenz sowie Spitzen und Batchfenster mit realen Daten erheben. Bare Metal nur wegen eines vermuteten „Virtualisierungs-Overheads“ zu wählen, kann teure Kapazität binden, ohne das eigentliche Storage- oder Netzproblem zu lösen.
- Daten und Wiederherstellung: RPO und RTO pro Dienst definieren. Einen kompletten Restore einschließlich Datenbank, Konfiguration, Zugangsdaten und Abhängigkeiten auf einem anderen Host üben.
- Änderungen und Personal: Wer patcht Gast-OS oder Host-Kernel? Wer baut Container-Images neu? Wer kann nachts einen fehlgeschlagenen Rollback oder einen Hardwaretausch durchführen? Die vorhandenen Fähigkeiten begrenzen die Zahl der sinnvoll parallel betriebenen Plattformen.
- Fehlerdomäne: Host, Storage, Netzwerk und Backup getrennt betrachten. Weder ein einzelner Bare-Metal-Server noch mehrere Container auf einem einzelnen Host werden durch ihren Namen hochverfügbar.
Aufwand vergleichen, bevor man Einsparungen behauptet
Für drei oder fünf Jahre gehört dieselbe Anwendung mit gleicher Last und gleichem Wiederanlaufziel in jede Spalte. Pro Weg sind einmalige Migration und Aufbau, Hardware samt Ersatzteilen, Betriebssystem- und Anwendungsrechte, Hypervisor- oder Runtime-Support, Energie, Backup, Monitoring sowie jährliche Personalstunden zu erfassen. Für OCI-Container kommen etwa Build-Pipeline, Registry, Image-Pflege und gegebenenfalls Orchestrierung hinzu. Für Bare Metal können Ausfall-Ersatzhardware und ein anderes Wartungsfenster relevant sein. Für VMs zählen Host-Kapazität und Gastbetriebssysteme. Ein vorhandener Cluster ist nur dann „kostenlos“ für den neuen Dienst, wenn Reserve, Lizenzen und Betriebsaufwand tatsächlich vorhanden sind.
Die prüfbare Grundformel lautet: Gesamtkosten über n Jahre = einmaliger Aufbau und Migration + n × (jährliche Lizenzen + Support + Energie + Backup + Betriebsstunden × interner Stundensatz) + geplante Erneuerung. n ist drei oder fünf. Keine der Betriebsformen hat ohne konkrete Angebote, Lastmessung und Supportbedingungen einen allgemeinen Kostenvorteil. Zum Vergleich muss auch der Preis eines nicht erreichten RPO/RTO sichtbar sein, statt ihn aus der Rechnung auszublenden.
Wie DAXS die Betriebsform festlegen würde
DAXS würde zuerst eine kleine Anwendungsliste mit Eigentümer, Datenfluss, Herstellerfreigabe, Abhängigkeiten und Wiederherstellungsziel erstellen. Für zwei realistische Kandidaten folgt ein kurzer technischer Test: produktionsnahe Last, Patch-/Upgrade-Weg, Ausfall eines Hosts oder Geräts und Restore auf einer anderen Maschine. Das Ergebnis ist eine nachvollziehbare Entscheidung pro Anwendung, keine Vorgabe, alle Dienste auf dieselbe Plattform zu ziehen.
Bestehende Windows- und Linux-VMs lassen sich häufig schrittweise beurteilen; Proxmox im Unternehmen beschreibt die Virtualisierungsbasis. Wenn der Containerweg überzeugt, hilft der Vergleich von Docker Compose und Kubernetes beim nächsten Schritt. Für einen konkreten Workload kann DAXS über Kontakt Freigaben, Messwerte und Restore gemeinsam in einen Betriebsentscheid übersetzen.
Quellen: Proxmox VE: KVM und LXC · Docker Engine: Sicherheitsmodell · Docker Engine: persistente Daten · Microsoft: Windows Server Virtualization Licensing Guidance.