Private Cloud und Virtualisierungsplattformen auf dedizierten Servern

Hypervisor-Optionen für Bare Metal

Proxmox VE

Proxmox Virtual Environment ist die praktische Wahl für die meisten Teams, die eine private Cloud auf einem einzelnen dedizierten Server oder einem kleinen Cluster aufbauen. Es ist Open Source, basiert auf Debian und kommt mit einer Web-Benutzeroberfläche, die sowohl KVM-Virtualisierungsmaschinen als auch LXC-Container über dieselbe Oberfläche verwaltet. Das Unternehmensabonnement bietet zusätzlich Zugriff auf Repositorys und Supportverträge, aber die Community-Edition ist für den produktiven Einsatz voll funktionsfähig.

Proxmox kümmert sich um die Live-Migration von VMs zwischen Knoten, die Konfiguration von gemeinsam genutztem Speicher, Hochverfügbarkeits-Clustering und die Integration des Proxmox Backup Servers, der das Erstellen von VM-Snapshot-Backups echt einfach macht. Für Teams, die eine Private Cloud betreiben wollen, ohne einen eigenen VMware-Administrator einzustellen, ist Proxmox der richtige Startpunkt.

VMware vSphere / ESXi

VMware ESXi ist immer noch der Standard in Unternehmen, die schon eine VMware-Infrastruktur haben, zertifizierte Integrationen nutzen und Teams mit VMware-Zertifizierungen haben. Das Lizenzmodell hat sich nach der Übernahme von VMware durch Broadcom im Jahr 2023 ziemlich verändert, was viele Unternehmen dazu gebracht hat, Proxmox und KVM-Alternativen genauer anzuschauen. Für Unternehmen, die schon auf das VMware-Ökosystem setzen, bleibt ESXi auf dedizierten Bare-Metal-Servern eine gute Wahl. Für Teams, die neu anfangen, sind Proxmox oder KVM aus Kostengründen eine Überlegung wert.

KVM mit libvirt

Linux KVM (Kernel-based Virtual Machine) ist die Hypervisor-Schicht, die sowohl unter dem Virtualisierungsstack von RHEL als auch unter der Infrastruktur vieler Cloud-Anbieter läuft. libvirt liefert die Verwaltungs-API, virt-manager oder Cockpit bieten einfache GUIs. Für Teams, die sich mit Linux-Administration und Infrastructure-as-Code-Tools (Terraform, Ansible) auskennen, bietet KVM mit libvirt mehr Flexibilität als Proxmox, allerdings mit einer weniger integrierten Verwaltungserfahrung.

VM-Dichteplanung auf 192 GB RAM

Die Frage, die sich bei der Bereitstellung eines Private-Cloud-Knotens stellt, ist, wie viele VMs draufpassen. Die Antwort hängt komplett von den VM-Workload-Profilen ab.

VM-Profil	RAM pro VM	VMs auf einem 192-GB-Server	Anmerkungen
Entwicklungsumgebung	4GB	~40 VMs	Lass 16 GB für den Hypervisor-Overhead übrig.
Webanwendungs-VM	8GB	~20 VMs	Typisch für LAMP/LEMP-Stack-Server
Datenbankserver-VM	32GB	~5 VMs	Anforderungen an den InnoDB-Pufferpool
Gemischte Arbeitslast	Durchschnittlich 8–16 GB	10–15 VMs	Realistische Produktionsschätzung

Bei diesen Zahlen wird nicht von einer Überbelegung des Speichers ausgegangen. Proxmox und KVM unterstützen beide Speicherballooning und Überbelegung, wodurch VMs mehr Speicher zur Verfügung gestellt werden kann, als physisch vorhanden ist, da davon ausgegangen wird, dass VMs ihre gesamte Zuweisung nicht gleichzeitig nutzen. Für Entwicklungsumgebungen ist eine 2-fache Überbelegung okay. Bei Produktionsdatenbank-VMs solltest du niemals eine Überbelegung machen.

Halt ungefähr 16 bis 24 GB physischen RAM außerhalb der VM-Zuweisung für den Hypervisor, den Speicher-Cache (den Seitencache des Host-Betriebssystems für VM-Festplatten-Images) und alle Verwaltungsdienste, die auf dem Bare-Metal-Host laufen, frei.

CPU-Überbuchungsraten

Der AMD EPYC 4545P hat 16 Kerne und 32 Threads. Die CPU-Überbuchungsraten bestimmen, wie viele vCPUs du im Verhältnis zu den physischen Threads bereitstellst:

• Verhältnis 1:1 (insgesamt 32 vCPU): Passt für Produktions-VMs, die gleichbleibende Workloads ausführen. Keine VM muss auf CPU-Zeit warten.
• Verhältnis 2:1 (insgesamt 64 vCPU): Geeignet für gemischte Umgebungen, in denen Entwicklungs- und Produktions-VMs nebeneinander existieren. Entwicklungs-VMs sind normalerweise nicht aktiv.
• Verhältnis 4:1 (insgesamt 128 vCPU): Passt für Umgebungen, die nur für die Entwicklung gedacht sind, mit sporadischen, aber nicht gleichzeitigen Workloads. Für die Produktion nicht okay.

Bei Proxmox zeigt die CPU-Auslastungsmetrik auf dem Host-Dashboard die tatsächliche CPU-Auslastung an: Wenn die Summe der CPU-Auslastung aller VMs 100 % der Hostkapazität überschreitet, fangen die VMs an, auf CPU-Zeit zu warten. Beobachte das bei neuen Bereitstellungen, bevor du dich auf eine Produktions-VM-Dichte festlegst.

Speicherkonfiguration für VM-Flotten

VM-Festplatten-Images auf NVMe

NVMe als Backend für VM-Festplatten-Images verändert das Leistungsprofil jeder VM auf dem Host. Die Festplatten-E/A der VM läuft über die Hypervisor-Ebene, aber dank des NVMe hat eine VM, die viele Datenbank-Schreibvorgänge macht, keinen spürbaren Einfluss auf andere VMs auf demselben Host.

Erstell in Proxmox einen lokalen LVM-Speicherpool, der auf das NVMe zeigt. Dabei wird LVM-Thin-Provisioning genutzt, das Speicherplatz vom NVMe nach Bedarf zuweist, anstatt die gesamte VM-Festplattengröße im Voraus zuzuweisen. Ein Pool von VMs, die jeweils mit 50 GB Festplatten ausgestattet sind, braucht vielleicht nur 200 GB NVMe , wenn die meisten VMs nur wenige Daten haben.

RAID-Konfiguration für VM-Speicher

InMotion nutzt mdadm RAID 1 (Software-Spiegelung) für die beiden NVMe . Das sorgt für Redundanz im VM-Speicherpool: Wenn ein NVMe kaputt geht, gehen die VM-Daten nicht verloren, während man auf den Austausch wartet. Für eine Private Cloud, die Produktions-VMs hostet, ist dieser Basisschutz echt wichtig.

Die RAID 1-Konfiguration bietet 3,84 TB nutzbaren NVMe für VM-Disk-Images. Bei einer Flotte von 15 VMs mit durchschnittlich 200 GB bereitgestelltem Speicherplatz pro VM sind das 3 TB bereitgestellte Kapazität. Mit LVM-Thin-Overprovisioning liegt die tatsächliche Auslastung normalerweise bei 40 bis 60 % der bereitgestellten Kapazität, sodass ein komfortabler Spielraum bleibt.

Proxmox Backup Server

Proxmox Backup Server (PBS) läuft als Dienst auf dem Hypervisor-Host oder einem separaten Rechner und kümmert sich um deduplizierte inkrementelle VM-Backups. Eine Umgebung mit 20 VMs und einer durchschnittlichen VM-Festplattennutzung von 100 GB erzeugt ungefähr 2 TB an einzigartigen Daten. Mit Deduplizierung speichert PBS normalerweise 3 bis 5 tägliche Backups in weniger als 3 TB Speicherplatz, je nachdem, wie oft sich die VMs ändern.

Der 500 GB große Backup-Speicher von Premier Care ergänzt den lokalen PBS-Speicher für Kopien wichtiger VM-Backups außerhalb des Servers.

Netzwerkkonfiguration und VLAN-Isolation

Das Isolieren von VM-Gruppen auf Netzwerkebene ist echt wichtig für eine Private Cloud, vor allem wenn Entwicklungs-, Staging- und Produktions-VMs denselben physischen Host nutzen.

In Proxmox sind Netzwerkbrücken (vmbr0, vmbr1 usw.) mit physischen Netzwerkkarten oder VLANs verbunden. Wenn man für jede Umgebungsgruppe eigene Brücken macht und die VMs den richtigen Brücken zuordnet, hat man eine Layer-2-Isolation. VMs auf der Produktionsbrücke können nicht direkt mit VMs auf der Entwicklungsbrücke quatschen, ohne über eine Router- oder Firewall-VM zu gehen.

Bei Clustern mit mehreren Servern sorgt ein 10-Gbit/s-Netzwerkanschluss für die nötige Bandbreite zwischen den Knoten, um Live-VM-Migrationen und den Zugriff auf gemeinsam genutzten Speicher zu ermöglichen, ohne dass es zu Konflikten mit dem VM-Netzwerkverkehr auf einer überlasteten 1-Gbit/s-Verbindung kommt.

Kostenvergleich: Private Cloud vs. Cloud-VMs

Der Kostenvergleich wird klar, wenn du die Cloud-Entsprechung einer privaten Cloud-VM-Flotte berechnest:

Umwelt	Konfiguration	Monatliche Kosten
AWS EC2 (10x t3.large VMs)	2 vCPU, jeweils 8 GB	~520 $/Monat
AWS EC2 (10x m5.xlarge VMs)	4 vCPU, jeweils 16 GB	~1.380 $/Monat
InMotion Extreme + Proxmox (15 VMs)	Jeweils 8–16 GB, NVMe	349,99 $/Monat
InMotion Advanced + Proxmox (8 VMs)	Jeweils 4–8 GB, NVMe	149,99 $/Monat

Der Übergang geht echt schnell. Ein Team, das mehr als 5 Cloud-VMs betreibt, kommt irgendwann an den Punkt, wo eine private Cloud auf dedizierter Hardware pro VM günstiger ist. Bei 15 VMs auf einem Extreme-Server liegen die Kosten pro VM bei etwa 23 US-Dollar pro Monat, während sie bei AWS je nach Instanztyp zwischen 52 und 138 US-Dollar pro VM liegen.

Verwaltete vs. nicht verwaltete Virtualisierung

Um einen kompletten Hypervisor-Stack zu betreiben, braucht man Root-Zugriff auf den physischen Server. Die verwalteten dedizierten Server von InMotion umfassen die Betriebssystemverwaltung durch das APS-Team, aber die Hypervisor-Konfiguration selbst bleibt in der Verantwortung des Kunden. Speziell für Proxmox-Bereitstellungen läuft die von InMotion verwaltete Konfiguration parallel zur vom Kunden verwalteten VM-Administration.

Für Teams, die den physischen Server verwalten lassen wollen (Hardwareüberwachung, Betriebssystem-Updates, Netzwerkkonfiguration) und gleichzeitig ihre eigene VM-Ebene kontrollieren möchten, ist Managed Dedicated das richtige Modell. Für Teams, die vollen, nicht verwalteten Zugriff wünschen, um das Basisbetriebssystem und den Hypervisor-Stack unabhängig zu konfigurieren, bieten die Bare-Metal-Server von InMotion die passende Grundlage.

Erste Schritte mit Proxmox auf InMotion

• Bestell einen dedizierten Server der Kategorie „Extreme“ oder „Advanced“, je nachdem, wie viele VMs du brauchst.
• Frag bei der Bereitstellung nach der Installation von Proxmox VE von InMotion APS.
• Konfigurier den lokalen LVM-Speicherpool auf NVMe für VM-Festplatten-Images.
• Netzwerkbrücken und VLAN-Tagging für die Isolierung von Umgebungen einrichten
• Installiere Proxmox Backup Server für geplante VM-Snapshot-Backups.
• Hol dir Premier Care für die Verwaltung auf Betriebssystemebene und 500 GB Backup-Speicherplatz außerhalb des Servers.

Die meisten Teams, die Proxmox auf InMotion-Hardware nutzen, merken, dass die VM-Dichte ihre bisherigen Cloud-Ausgaben schon im ersten Monat doppelt so effizient macht. Der Verwaltungsaufwand für eine private Cloud ist echt, aber viel geringer als gedacht, vor allem mit der einheitlichen Weboberfläche von Proxmox.