Was ist PegaProx?

PegaProx etabliert sich als die zentrale, freie und open-source basierende Plattform für moderne Proxmox VE basierte Virtualisierung und positioniert sich als leistungsstarker Multi Cluster Manager für anspruchsvolle Enterprise Umgebungen. Während klassische Werkzeuge oft an ihre Grenzen stoßen und der Proxmox eigene Datacenter Manager viele zentrale Anforderungen bis heute nicht vollständig abdeckt, setzt PegaProx genau dort an und bietet eine durchgängige, klar strukturierte Lösung für die Verwaltung komplexer Infrastrukturen.

Als zentrale Steuerungseinheit vereint PegaProx sämtliche Aspekte des Cluster Managements (inkl. Multi-Cluster Management und Proxmox Backup Server) in einer einzigen Oberfläche und schafft damit eine konsistente Sicht auf alle Ressourcen, Workloads und Systeme. Administratoren müssen nicht länger zwischen einzelnen Clustern, Nodes oder isolierten Monitoring Lösungen wechseln, sondern erhalten eine vollständig integrierte Umgebung, die Transparenz, Kontrolle und Effizienz deutlich erhöht. Gerade in wachsenden Infrastrukturen mit mehreren Clustern wird dieser Ansatz zu einem entscheidenden Vorteil. Im täglichen Betrieb stehen Virtualisierungsverantwortliche immer wieder vor denselben Herausforderungen. Ressourcen müssen clusterübergreifend überwacht werden, Engpässe frühzeitig erkannt werden und Wartungsarbeiten koordiniert ablaufen, ohne die Verfügbarkeit zu gefährden. Gleichzeitig steigt mit zunehmender Komplexität das Risiko für Fehlkonfigurationen, inkonsistente Zustände und ungeplante Ausfälle. Auch weitere Features, die man aus anderen bekannten Virtualisierungslösungen aus dem Enterprise-Umfeld bereits kennt, spielen in PegaProx eine zentrale Rolle. PegaProx begegnet diesen Problemen mit einer konsequent zentralisierten Architektur, Echtzeitmetriken und intelligenter Automatisierung, die operative Abläufe vereinfacht und bisher fehlende Funktionen implementiert.

PegaProx for Proxmox: Cluster Übersicht

Entwickelt von einem kleinen, fokussierten Team mit starkem Praxisbezug, zudem auch unser Kollege Florian Paul Azim Hoberg (auch bekannt als gyptazy) als Core-Contributor gehört, legt PegaProx besonderen Wert auf reale Anforderungen aus dem Enterprise Umfeld. Funktionen wie die Verwaltung mehrerer Cluster als logische Einheit, eine globale Übersicht an Snapshots inkl. Clean-Up Funktion oder die dynamische Verteilung von Workloads basierend auf aktuellen Ressourcendaten (ProxLB) sind keine theoretischen Konzepte, sondern gezielt entwickelte Lösungen für den produktiven Einsatz. Das Ergebnis ist eine Plattform, die Proxmox VE auf ein neues Niveau hebt und Unternehmen eine leistungsfähige, skalierbare und zugleich verständliche Lösung für ihre Virtualisierungsstrategie bietet.

Was bietet PegaProx?

PegaProx vereint eine Vielzahl an Funktionen, die speziell für den professionellen Betrieb von Proxmox VE basierten Infrastrukturen entwickelt wurden. Der Fokus liegt dabei klar auf zentraler Steuerung, Automatisierung und Transparenz über mehrere Cluster hinweg. Statt fragmentierter Werkzeuge entsteht eine integrierte Plattform, die sowohl den täglichen Betrieb vereinfacht als auch komplexe Enterprise Anforderungen zuverlässig abbildet.

PegaProx mit zentraler, aggregierter Logging Übersicht

Um dies in Einklang mit den ProxTools zu bringen, wurden somit auch die von @gyptazy erstellten Tools wie ProxLB, ProxCLMC, ProxPatch, ProxSnap und ProxLog ebenfalls integriert und bieten zur einfachen Nutzbarkeit nun auch eine Möglichkeit zur administration über die grafische Oberfläche von PegaProx. Mit zu den wichtigsten Funktionen gehören:

Multi-Cluster Management
Unified Dashboard
Multi-Tenancy & End-User Self-Service Portal
Live Metrics
Cross-Cluster Load Balancing
Live Migration
Cross-Cluster Live Migration
High Availability und automatisches Failover
Snapshots und Snapshot Replikation
Zentralisierte Snapshot-Übersicht
Backup Management inklusive Verifikation
Rollenbasierte Zugriffskontrolle und Multi Tenancy
Integration externer Authentifizierungssysteme
Automatisierung und geplante Aufgaben
Rolling Updates / Patch-Management für Cluster Nodes
Integrierter Syslog Server
Ceph Management
Audit Logging und Monitoring Alerts
und vieles mehr

Diese Auswahl bildet nur einen Teil der Möglichkeiten ab, die PegaProx heute bereits bietet. Viele weitere Funktionen und kontinuierliche Weiterentwicklungen erweitern die Plattform stetig und orientieren sich eng an den realen Anforderungen moderner Virtualisierungsumgebungen. Einen vollständigen Überblick über alle Features, technische Details und aktuelle Entwicklungen sind auf der offiziellen GitHub Seite von PegaProx zu finden, auf der sämtliche Funktionen transparent dokumentiert und laufend ergänzt werden.

Installation & Konfiguration von PegaProx

Die Installation von PegaProx ist bewusst flexibel gestaltet, um unterschiedlichste Umgebungen und Anforderungen abzudecken. Egal ob schnelle Evaluierung, Integration in bestehende Infrastrukturen oder produktiver Enterprise Einsatz, PegaProx lässt sich auf mehreren Wegen bereitstellen und nahtlos in vorhandene Proxmox VE Landschaften integrieren. Alle Installationsmethoden verfolgen dabei das gleiche Ziel: eine möglichst einfache, reproduzierbare und transparente Bereitstellung ohne unnötige Komplexität.

Für die Installation stehen folgende Optionen zur Verfügung:

Bash Script
Schneller und unkomplizierter Einstieg über ein automatisiertes Installationsskript (wir raten jedoch dringend von dieser Methode ab, auch wenn sich diese Art mehr und mehr wieder etabliert):
curl -sSL https://raw.githubusercontent.com/PegaProx/project-pegaprox/refs/heads/main/deploy.sh | sudo bash
Docker Container Image
Bereitstellung als Container für maximale Portabilität und einfache Integration in bestehende Container Umgebungen
LXC Appliance
Vorgefertigtes LXC Template für den direkten Einsatz in Proxmox VE mit minimalem Setup Aufwand
VM Appliance
Vollständig vorkonfigurierte virtuelle Maschine für eine schnelle und isolierte Inbetriebnahme
Debian Paket
Native Installation über ein Debian Paket für Systeme, die bewusst ohne Container betrieben werden sollen
Debian Repository
Zentrale Paketquelle für einfache Updates, Versionierung und Integration in bestehende Paketmanagement Prozesse

Unabhängig von der gewählten Methode ist die grundlegende Konfiguration schnell abgeschlossen, sodass PegaProx innerhalb kürzester Zeit als zentrale Management Plattform für mehrere Proxmox VE Cluster zur Verfügung steht.

Fazit

PegaProx entwickelt sich rasant zu einer der spannendsten Lösungen im Umfeld von Proxmox VE basierter Virtualisierung und sorgt bereits jetzt für große Begeisterung in der Community. Viele Unternehmen sehen in PegaProx schon heute die zentrale Plattform, die ihnen bislang im Proxmox Ökosystem gefehlt hat, insbesondere wenn es um Multi Cluster Management, Automatisierung und eine konsistente Gesamtübersicht geht.

Die klare Struktur, der praxisnahe Funktionsumfang und die konsequente Ausrichtung auf reale Anforderungen im Enterprise Umfeld zeigen deutlich, welches Potenzial in der Plattform steckt. PegaProx schließt nicht nur bestehende Lücken, sondern definiert in vielen Bereichen einen neuen Standard für die Verwaltung komplexer Virtualisierungslandschaften.

Trotz dieser positiven Entwicklung sollte jedoch berücksichtigt werden, dass sich PegaProx aktuell noch in der Beta Phase befindet. Auch wenn bereits vieles stabil und durchdacht funktioniert, können jederzeit Probleme oder unerwartetes Verhalten auftreten. Für produktive Umgebungen sollte der Einsatz daher sorgfältig geprüft und gegebenenfalls zunächst in Test oder Staging Szenarien erfolgen.

Fehler, Wünsche oder Verbesserungsvorschläge können jederzeit über das Projekt auf GitHub gemeldet werden. Zusätzlich stehen die Entwickler direkt über den Discord Server von gyptazy projects zum Austausch und Support zur Verfügung.

Die Proxmox®-Installation ist ein entscheidender Schritt für Unternehmen, die auf eine professionelle Virtualisierungslösung setzen möchten. Diese umfassende Anleitung führt Sie durch den kompletten Prozess der Proxmox®-VE-Installation und hilft Ihnen dabei, eine stabile Hypervisor-Umgebung aufzubauen. Sie benötigen grundlegende Linux®-Kenntnisse und etwa 2–3 Stunden Zeit für die komplette Installation und Grundkonfiguration. Für diese Proxmox®-Anleitung brauchen Sie einen dedizierten Server mit mindestens 4 GB RAM, einen USB-Stick mit 8 GB Speicherplatz und Zugang zum BIOS des Zielrechners. Nach Abschluss dieser Schritte verfügen Sie über ein voll funktionsfähiges Proxmox®-VE-System für Ihre Servervirtualisierung.

Warum Proxmox® VE eine professionelle Virtualisierungslösung ist

Proxmox® Virtual Environment (VE) bietet Unternehmen eine kosteneffiziente Virtualisierungsplattform. Als Open-Source-Lösung ermöglicht Proxmox® VE flexible Lizenzmodelle. Aktuelle Preise finden Sie unter https://www.proxmox.com/de/produkte/proxmox-virtual-environment/preise.

Die integrierten Backup-Funktionen ermöglichen automatisierte Sicherungsstrategien ohne zusätzliche Software. Proxmox® VE unterstützt sowohl KVM-Virtualisierung für vollständige Betriebssysteme als auch LXC-Container für ressourcenschonende Anwendungen.

Enterprise-Features wie High Availability, Live Migration und Clustering sind standardmäßig verfügbar. Die webbasierte Verwaltungsoberfläche vereinfacht die Administration erheblich und ermöglicht den Zugriff von jedem Arbeitsplatz aus.

Proxmox® VE punktet durch seine Flexibilität und den direkten Zugang zum Quellcode. Typische Anwendungsbereiche umfassen Entwicklungsumgebungen, Testlabore und produktive Serverinfrastrukturen vor allem in mittelständischen Unternehmen.

Systemvoraussetzungen und Hardware-Vorbereitung prüfen

Überprüfen Sie vor der Proxmox®-Installation die Hardware-Kompatibilität Ihres Systems. Die minimalen Anforderungen umfassen einen 64-Bit-Prozessor mit Virtualisierungsunterstützung (Intel® VT-x oder AMD®-V).

Minimale Hardware-Anforderungen

CPU: 64-Bit-Prozessor mit Virtualisierungsfunktionen
RAM: 4 GB (empfohlen: 8 GB oder mehr)
Speicher: 32 GB verfügbarer Festplattenspeicher
Netzwerk: Gigabit-Ethernet-Adapter

Empfohlene Konfiguration für einen minimalen Server

CPU: Multi-Core-Prozessor mit mindestens 4 Kernen
RAM: 32 GB oder mehr für produktive Umgebungen
Speicher: SSD bzw. NVMe mit mindestens 500 GB für bessere Performance
Netzwerk: Redundante Netzwerkverbindungen

Aktivieren Sie im BIOS die Virtualisierungsfunktionen. Suchen Sie nach Einstellungen wie „Intel® VT-x“, „AMD®-V“ oder „Virtualization Technology“ und setzen Sie diese auf „Enabled“. Deaktivieren Sie Secure Boot, da dies zu Problemen während der Installation führen kann. Für Virtualisierungscluster sollten weitere Anforderungen berücksichtigt werden.

Proxmox®-VE-ISO herunterladen und Installationsmedium erstellen

Laden Sie die aktuelle Proxmox®-VE-ISO-Datei von der offiziellen Website herunter. Besuchen Sie proxmox.com und navigieren Sie zum Download-Bereich.

Wählen Sie die neueste stabile Version der Proxmox®-VE-ISO. Die Datei ist etwa 1 GB groß und enthält alle notwendigen Komponenten für die Installation.

Verifizieren Sie die Prüfsumme der heruntergeladenen ISO-Datei. Nutzen Sie dafür Tools wie sha256sum unter Linux® oder entsprechende Programme unter Windows®. Dies stellt sicher, dass die Datei vollständig und unverändert ist.

Bootfähigen USB-Stick erstellen

Schließen Sie einen USB-Stick mit mindestens 8 GB an Ihren Computer an.
Verwenden Sie Tools wie Rufus (Windows®) oder dd (Linux®) für die Erstellung.
Wählen Sie die heruntergeladene Proxmox®-ISO-Datei als Quelle.
Starten Sie den Schreibvorgang und warten Sie auf die Fertigstellung.

Alternativ können Sie die ISO-Datei auf eine DVD brennen, falls Ihr Zielsystem über ein optisches Laufwerk verfügt. USB-Sticks ermöglichen jedoch eine schnellere Installation.

Proxmox®-Installation durchführen und Grundkonfiguration

Starten Sie den Zielrechner vom erstellten Installationsmedium. Konfigurieren Sie im BIOS die Boot-Reihenfolge so, dass USB oder DVD vor der Festplatte steht.

Nach dem Start erscheint das Proxmox®-VE-Boot-Menü. Wählen Sie „Install Proxmox VE“ für eine Standardinstallation.

Installationsschritte durchführen

Akzeptieren Sie die Lizenzbedingungen durch einen Klick auf „I agree“.
Wählen Sie die Zielfestplatte für die Installation aus.
Konfigurieren Sie die Partitionierung (Standardeinstellungen sind meist ausreichend). Achtung: Das löscht die lokale Festplatte des Computers.
Geben Sie ein sicheres Root-Passwort ein und bestätigen Sie es.
Tragen Sie eine gültige E-Mail-Adresse für Systembenachrichtigungen ein.

Bei der Netzwerkkonfiguration vergeben Sie eine statische IP-Adresse für Ihr Proxmox®-System. Vermeiden Sie DHCP in produktiven Umgebungen, da sich die IP-Adresse ändern könnte.

Wichtiger Hinweis: Notieren Sie sich die IP-Adresse und das Root-Passwort. Sie benötigen diese Daten für den ersten Zugriff auf die Weboberfläche.

Der Installationsvorgang dauert etwa 10–15 Minuten. Nach Abschluss entfernen Sie das Installationsmedium und starten das System neu.

Erste Schritte nach der Installation optimieren

Nach dem Neustart ist Proxmox® VE über die Weboberfläche erreichbar. Öffnen Sie einen Browser und navigieren Sie zu https://ihre-proxmox-ip:8006.

Melden Sie sich mit dem Benutzernamen „root“ und dem während der Installation festgelegten Passwort an. Ignorieren Sie zunächst die SSL-Zertifikatwarnung des Browsers.

Repository-Konfiguration anpassen

Öffnen Sie die Shell über die Weboberfläche und führen Sie folgende Optimierungen durch:

Aktualisieren Sie die Paketlisten mit apt update.
Installieren Sie verfügbare Updates mit apt upgrade.
Konfigurieren Sie die Community-Repositories für kostenlose Updates.
Entfernen Sie die Enterprise-Repository-Warnung, falls gewünscht.

Eine Firewall-Grundkonfiguration sollte als nächster Schritt erfolgen. Aktivieren Sie die Proxmox®-Firewall und konfigurieren Sie Regeln für den SSH-Zugriff und das Webinterface.

Erstellen Sie zusätzliche Benutzerkonten für die tägliche Administration. Vermeiden Sie die permanente Nutzung des Root-Accounts und vergeben Sie spezifische Berechtigungen je nach Aufgabenbereich.

Konfigurieren Sie ein gültiges SSL-Zertifikat für die Weboberfläche. Dies erhöht die Sicherheit und eliminiert Browserwarnungen bei zukünftigen Zugriffen.

Wie credativ® bei Proxmox®-Implementierungen unterstützt

credativ® bietet umfassende Proxmox®-Virtualisierung von der Planung bis zum produktiven Betrieb. Unser erfahrenes Team begleitet Sie durch alle Phasen Ihrer Virtualisierungsinitiative.

Unsere Proxmox®-Services umfassen:

Professionelle Installationsberatung und Hardware-Dimensionierung für optimale Performance
24/7-Premium-Support mit direktem Zugang zu Open-Source-Spezialisten
Monitoring und Wartung Ihrer Proxmox®-Infrastruktur
Backup-Strategien und Disaster-Recovery-Konzepte
Schulungen und Workshops für Ihre IT-Teams
Migrationsservices von bestehenden Virtualisierungsplattformen

Wir entwickeln maßgeschneiderte Lösungen, die genau zu Ihren Anforderungen passen. Dabei profitieren Sie von unserem langjährigen Know-how im Open-Source-Bereich und der direkten Zusammenarbeit mit Proxmox®-Entwicklern.

Vereinbaren Sie noch heute ein unverbindliches Beratungsgespräch und erfahren Sie, wie wir Ihre Proxmox®-Implementierung zum Erfolg führen können. Kontaktieren Sie uns für eine individuelle Analyse Ihrer Virtualisierungsanforderungen.

Transparenzhinweis

Proxmox® ist eine eingetragene Marke der Proxmox Server Solutions GmbH. credativ® ist autorisierter Reseller von Proxmox®. Linux® ist eine eingetragene Marke von Linus Torvalds. Intel® ist eine eingetragene Marke der Intel Corporation. AMD® ist eine eingetragene Marke der Advanced Micro Devices Inc. Windows® ist eine eingetragene Marke der Microsoft Corporation.

Die Nennung der Marken dient ausschließlich der sachlichen Beschreibung von Migrationsszenarien und Dienstleistungen von credativ®. Es besteht keine geschäftliche Verbindung zu den genannten Markeninhabern ohne bestehende Reseller-Beziehung.

Was ist Proxmox® Enterprise Support und wie unterscheidet er sich von der Community Edition?

Proxmox® Enterprise Support ist die kostenpflichtige Variante der Virtualisierungsplattform mit professionellem Support, stabilen Updates und Zugang zu Enterprise-Repositories. Die Community-Repositories bieten dieselbe Grundfunktionalität kostenlos, jedoch ohne Support-Garantie und mit weniger intensiv getesteten Updates. Beide Versionen werden von der Proxmox® Server Solutions GmbH unter der AGPL-Lizenz bereitgestellt. Eine wichtige weitere Unterscheidung gibt es jedoch noch zusätzlich: Eine Community-Subscription ermöglicht den Zugriff auf die Enterprise-Repositories. Diese umfasst aber dann nur den Zugang und keinen weiteren Support.

Der wichtigste Unterschied liegt im Support-Level. Enterprise-Kunden erhalten direkten Zugang zum Proxmox®-Team für technische Probleme, während Community-Nutzer auf Foren und Community-Hilfe angewiesen sind. Enterprise Support umfasst verschiedene Service-Level von Standard bis Premium mit unterschiedlichen Reaktionszeiten.

Die Update-Zyklen unterscheiden sich erheblich. Enterprise-Repositories enthalten ausführlich getestete, stabile Updates, die für Produktionsumgebungen optimiert sind. Community-Updates erscheinen häufiger, sind aber weniger intensiv getestet und können instabiler sein.

Zusätzliche Enterprise-Funktionen umfassen erweiterte Backup-Möglichkeiten, Cluster-Management-Tools und spezielle Monitoring-Optionen. Diese Funktionen sind in der Community Edition nicht verfügbar und richten sich speziell an Unternehmensanforderungen.

Wann lohnt sich Proxmox® Enterprise Support für Unternehmen?

Enterprise Support eignet sich besonders für Unternehmen mit kritischen Produktionsumgebungen, begrenzten internen IT-Ressourcen oder strengen Compliance-Anforderungen. Unternehmen ab etwa 50 Mitarbeitenden oder mit hohen Verfügbarkeitsanforderungen profitieren in der Regel vom professionellen Support.

Ein kritischer Faktor sind die Verfügbarkeitsanforderungen Ihrer Systeme. Wenn Ausfälle hohe Kosten verursachen oder Geschäftsprozesse erheblich beeinträchtigen, ist die Investition in Enterprise Support gerechtfertigt. Dies gilt insbesondere für E-Commerce, Finanzdienstleister oder Produktionsbetriebe.

Die interne IT-Expertise spielt eine entscheidende Rolle. Fehlen spezialisierte Virtualisierungsexpertinnen und -experten im Team, bietet Enterprise Support wertvolle Unterstützung bei komplexen Problemen. Kleinere IT-Teams profitieren besonders von der verfügbaren Expertise.

Compliance-Anforderungen können Enterprise Support erforderlich machen. Viele Branchen benötigen dokumentierten Support für Audit-Zwecke. Enterprise Support bietet die notwendige Dokumentation und Nachverfolgbarkeit für regulierte Umgebungen.

Was kostet Proxmox® Enterprise Support und welche Lizenzmodelle gibt es?

Proxmox® Enterprise Support wird pro CPU-Socket mit verschiedenen Support-Leveln lizenziert. Aktuelle Preise finden Sie unter https://www.proxmox.com/de/produkte/proxmox-virtual-environment/preise.

Das Basic- oder Standard-Paket beinhaltet Zugang zu Enterprise-Repositories, Updates und E-Mail-Support während der Geschäftszeiten. Dieses Level eignet sich für kleinere Umgebungen ohne besonders hohe Verfügbarkeitsanforderungen.

Premium Support bietet kürzere Reaktionszeiten und erweiterte Services. Die Kosten liegen höher, sind bei kritischen Systemen jedoch durch minimierte Ausfallzeiten gut zu rechtfertigen.

Zusätzliche Kostenfaktoren umfassen die Anzahl der CPU-Sockets, die gewünschten Reaktionszeiten und spezielle Services wie Vor-Ort-Support oder individuelle Schulungen. Größere Deployments erhalten häufig Mengenrabatte.

Welche Alternativen gibt es zu Proxmox® Enterprise Support?

Alternativen zum offiziellen Enterprise Support umfassen Community-Support, Dienstleister von Drittanbietern, internen Kompetenzaufbau oder hybride Ansätze. Jede Option bietet je nach Unternehmenssituation unterschiedliche Vor- und Nachteile.

Community-Support über Foren und Dokumentation bleibt kostenlos, bietet jedoch keine Garantien für Reaktionszeiten oder Problemlösung. Erfahrene IT-Teams können häufig eigenständig Lösungen finden, während weniger erfahrene Teams damit Schwierigkeiten haben können.

Support durch spezialisierte Drittanbieter wie credativ® kann flexiblere Service-Pakete bieten. Diese Anbieter kennen lokale Anforderungen oft gut und bieten maßgeschneiderte Lösungen. Die Qualität variiert jedoch zwischen den Anbietern.

Interner Kompetenzaufbau durch Schulungen und Zertifizierungen bietet langfristige Unabhängigkeit, erfordert jedoch Investitionen in Personal und Zeit. Hybride Ansätze kombinieren interne Expertise mit externem Open-Source-Support für besonders komplexe Probleme.

Wie credativ® bei der Proxmox®-Entscheidung und dem Support hilft

credativ® unterstützt Sie bei der strategischen Entscheidung für die passende Proxmox®-Support-Strategie und bietet umfassende technische Betreuung für Ihre Virtualisierungsumgebung. Als herstellerunabhängiger Open-Source-Spezialist analysieren wir Ihre Anforderungen und entwickeln maßgeschneiderte Support-Konzepte.

Unsere Proxmox®-Services umfassen:

Bedarfsanalyse und Support-Strategieberatung für Ihre Virtualisierungsumgebung
24/7 technischer Support mit direktem Zugang zu Linux®- und Virtualisierungsexpertinnen und -experten
Optional: Proaktives Monitoring und Wartung Ihrer Proxmox®-Cluster
Migration und Implementierung von Proxmox®-Lösungen
Schulungen und Wissenstransfer für Ihre IT-Teams
Hybride Support-Modelle als Alternative zum reinen Enterprise Support

Mit über 25 Jahren Erfahrung im Open-Source-Bereich bieten wir Ihnen die Sicherheit professionellen Supports ohne Vendor-Lock-in. Kontaktieren Sie uns für eine kostenlose Beratung zu Ihrer optimalen Proxmox®-Support-Strategie.

Transparenzhinweis

Proxmox® ist eine eingetragene Marke der Proxmox® Server Solutions GmbH. credativ® ist autorisierter Reseller von Proxmox®. Linux® ist eine eingetragene Marke von Linus Torvalds.

Was ist der Unterschied zwischen ZFS, LVM und Ceph in Proxmox?

ZFS ist ein Copy-on-Write-Dateisystem mit integrierter Volume-Verwaltung und Datenredundanz. Es kombiniert Dateisystem und Volume-Manager in einer Lösung und bietet Features wie Snapshots, Komprimierung und automatische Fehlerkorrektur. ZFS eignet sich besonders für lokale Storage-Szenarien mit hohen Anforderungen an die Datenintegrität.

LVM (Logical Volume Manager) arbeitet als Abstraktionsschicht zwischen physischen Festplatten und dem Dateisystem. Es ermöglicht flexible Partitionierung und dynamische Volume-Größenänderungen zur Laufzeit. LVM bietet hohe Performance und einfache Verwaltung, benötigt jedoch zusätzliche Redundanzmechanismen wie Software-RAID.

Ceph stellt eine vollständig verteilte Storage-Architektur dar, die Daten über mehrere Knoten repliziert. Es bietet Object-, Block- und File-Storage in einem System und skaliert horizontal. Ceph eignet sich für große Cluster-Umgebungen mit hohen Anforderungen an die Verfügbarkeit.

Welche Storage-Lösung bietet die beste Performance für verschiedene Workloads?

LVM mit ext4 oder XFS liefert die höchste Performance für I/O-intensive Anwendungen wie Datenbanken. Der geringe Overhead macht es zur ersten Wahl für latenzkritische Workloads. ZFS folgt mit guter Performance bei gleichzeitigen Datenintegritäts-Features, während Ceph durch Netzwerk-Overhead höhere Latenz aufweist.

Für Datenbank-Workloads empfiehlt sich LVM mit schnellen SSDs und direktem Zugriff. Die minimale Abstraktionsschicht reduziert Latenz und maximiert IOPS. ZFS kann hier durch ARC-Cache und L2ARC-Beschleunigung konkurrenzfähige Performance bieten, besonders bei read-lastigen Workloads.

File-Services profitieren von ZFS-Features wie Deduplizierung und Komprimierung, die Speicherplatz sparen.

Ceph eignet sich für verteilte File-Services mit hohen Anforderungen an die Verfügbarkeit, auch wenn die Performance durch Netzwerkommunikation begrenzt wird. Hier lassen sich virtuelle Maschinen praktisch ohne großen Zeitverzug von Host zu Host migrieren, sei es durch ein Tool wie ProxLB oder auch im Fail-Over-Fall,

Virtuelle Maschinen laufen auf allen drei Systemen gut. LVM bietet die beste Roh-Performance, ZFS ermöglicht effiziente VM-Snapshots, und Ceph bietet Live-Migration zwischen Hosts ohne gemeinsamen Storage.

Feature	LVM	ZFS	Ceph
Architektur-Typ	Lokal (Block-Storage)	Lokal (Dateisystem & Volume Manager)	Verteilt (Object/Block/File)
Performance (Latenz)	Exzellent (Minimaler Overhead)	Gut (Skaliert mit RAM/ARC)	Moderat (Abhängig vom Netzwerk)
Snapshots	Ja	Ja (sehr effizient)	Ja
Datenintegrität	Begrenzt (RAID-abhängig)	Exzellent (Checksumming)	Exzellent (Checksumming)
Skalierbarkeit	Begrenzt (Single Node)	Medium (innerhalb des Hosts)	Sehr hoch (Horizontal im Cluster)
Netzwerk-Anforderung	Standard (1 GbE ausreichend)	Standard (1 GbE ausreichend)	Hoch (min. 10-25 GbE empfohlen)
Haupteinsatzgebiet	Maximale Single-Node Performance	Hohe Datensicherheit & Lokaler Speed	Enterprise Cluster & High Availability
Komplexität	Einfach	Moderat	Hoch

Wie entscheidet man zwischen lokaler und verteilter Storage-Architektur?

Lokale Storage-Lösungen wie ZFS und LVM eignen sich für Single-Host-Umgebungen oder wenn maximale Performance wichtiger ist als Hochverfügbarkeit. Verteilte Systeme wie Ceph sind notwendig, wenn Daten über mehrere Hosts verfügbar sein müssen oder automatische Failover-Mechanismen erforderlich sind.

Die Infrastrukturgröße spielt eine entscheidende Rolle. Einzelne Proxmox-Hosts oder kleine Setups mit zwei bis drei Servern funktionieren gut mit lokalen Storage-Lösungen. Ab drei bis vier Hosts wird Ceph interessant, da es echte Hochverfügbarkeit ohne Single Point of Failure ermöglicht. Ceph erfordert ein Quorum, sodass immer eine ungerade Anzahl an Knoten für Ceph bereit steht. Cluster-Setups mit einer geraden Anzahl sind also immer mit einer gewissen unterschiedlichen Nutzung behaftet - aber hier muss auch bei Proxmox VE Hand angelegt werden.

Netzwerkanforderungen unterscheiden sich erheblich. Lokale Storage-Systeme benötigen nur Standardnetzwerk für das Management, während Ceph dedizierte 10GbE-Verbindungen für optimale Performance erfordert. Heute setzt man ab einem gewissen Performance-Bedarf eher auf 25GbE-Verbindungen für die Datenllast. Diese Verbindungen stehen dann im Idealfall nur dem Ceph-System zur Verfügung und kommen zusätzlich zum Bedarf der Virtualisierung. Die Netzwerk-Infrastruktur beeinflusst daher maßgeblich die Storage-Entscheidung.

Wartungsaufwand und Komplexität steigen mit verteilten Systemen. ZFS und LVM sind einfacher zu verstehen und zu warten, während Ceph spezialisiertes Wissen für Konfiguration, Monitoring und Troubleshooting erfordert.

Proxmox VE mit ZFS bietet mit pe-sync einen Mittelweg zwischen echtem Shared Storage und lokaler Datenhaltung. Hiermit kann man automatisch Hosts miteinander in Sync halten. Allerdings ist dies nicht synchron sondern in bestimmten Zeitintervallen, etwa alle 15 Minuten. Für bestimmte Arbeitslasten kann dies absolut hinreichend sein.

Was sind die wichtigsten Faktoren bei der Proxmox-Storage-Planung?

Hardware-Anforderungen variieren stark zwischen den Storage-Technologien. ZFS benötigt ausreichend RAM (1 GB pro TB Storage), damit der integrierte ARC-Cache seine Leistung voll ausspielen kann, LVM läuft auf minimaler Hardware, und Ceph erfordert dedizierte Netzwerk-Hardware, ebenfalls ausreichend RAM und mehrere Hosts. Die Hardware-Ausstattung bestimmt oft die möglichen Storage-Optionen.

Backup-Strategien müssen zur gewählten Storage-Lösung passen. ZFS-Snapshots ermöglichen effiziente inkrementelle Backups, LVM-Snapshots bieten ähnliche Funktionalität, während Ceph-Backups über RBD-Snapshots oder externe Tools realisiert werden. Die Backup-Anforderungen beeinflussen die Storage-Wahl erheblich.

Skalierbarkeitsplanung sollte zukünftiges Wachstum berücksichtigen. LVM ermöglicht einfache Volume-Erweiterung, ZFS-Pools können um zusätzliche Laufwerke erweitert werden, und Ceph skaliert durch Hinzufügen neuer Hosts. Die geplante Wachstumsrichtung beeinflusst die optimale Storage-Architektur.

Budgetüberlegungen umfassen nicht nur Hardware-Kosten, sondern auch Wartungsaufwand und benötigte Expertise. Einfache LVM-Setups haben niedrige Gesamtkosten, während Ceph-Cluster höhere Investitionen in Hardware und Schulungen erfordern.

Bonus: ZFS und Ceph bieten beide integrierte Prüfsummenverfahren, die aktiv gegen den sogenannten "Bit Rot" - die schleichende Datenkorruption - helfen und diesen durch Redundanz automatisch erkennen und beheben können. Bei LVM ohne weitere Zusätze wie ein RAID-Layer erlaubt dies nicht.

Infotafel Proxmox VE ) ZFS vs. LVM vs. Ceph

Wie credativ® bei der Proxmox-Storage-Optimierung unterstützt

credativ® bietet umfassende Beratung und Implementierung für optimale Proxmox-Storage-Entscheidungen basierend auf Ihren spezifischen Anforderungen. Unsere Open-Source-Experten analysieren Ihre Workloads, Infrastruktur und Wachstumspläne, um die ideale Storage-Architektur zu empfehlen.

Unsere Services umfassen:

Detaillierte Storage-Architektur-Bewertung und Technologieauswahl
Professionelle Implementierung und Konfiguration von ZFS, LVM oder Ceph
Performance-Optimierung und Monitoring-Setup für gewählte Storage-Lösungen
24/7-Support und Wartung für produktive Proxmox-Umgebungen
Schulungen für Ihr IT-Team zu Storage-Management und Best Practices

Mit über 25 Jahren Erfahrung im Open-Source-Bereich und direktem Zugang zu unseren festangestellten Linux-Spezialisten erhalten Sie professionelle Proxmox-Unterstützung ohne Umwege über Callcenter. Kontaktieren Sie uns für eine individuelle Beratung zu Ihrer Proxmox-Storage-Strategie und profitieren Sie von unserem bewährten Enterprise-Support.

ProxCLMC – Was ist das?

Live-Migration ist eine der leistungsfähigsten und am häufigsten genutzten Funktionen in einem Proxmox VE Cluster. Sie setzt jedoch eine Voraussetzung voraus, die oft unterschätzt wird: eine konsistente CPU-Kompatibilität über alle Nodes hinweg. In realen Umgebungen bestehen Cluster selten aus identischer Hardware, bei der man einfach den CPU-Typ host verwenden könnte. Nodes werden über die Zeit hinweg hinzugefügt, CPU-Generationen unterscheiden sich und Funktionsumfänge entwickeln sich weiter. Obwohl Proxmox VE eine flexible CPU-Konfiguration erlaubt, ist die Ermittlung einer sicheren und zugleich optimalen CPU-Baseline für den gesamten Cluster bislang weitgehend eine manuelle und erfahrungsbasierte Aufgabe.

ProxCLMC (Prox CPU Live Migration Checker) wurde von unserem Kollegen Florian Paul Azim Hoberg (auch bekannt als gyptazy) in Rust als Open-Source Lösung unter der GPLv3 Lizenz entwickelt, um diese Lücke auf einfache, automatisierte und reproduzierbare Weise zu schließen. Das Tool untersucht alle Nodes eines Proxmox-VE-Clusters, analysiert nachfolgend deren CPU-Fähigkeiten und berechnet das höchstmögliche CPU-Kompatibilitätsniveau, das von jedem Node unterstützt wird. Anstatt sich auf Annahmen, Tabellenkalkulationen oder Versuch und Irrtum zu verlassen, erhalten Administratoren ein klares und deterministisches Ergebnis, das direkt bei der Auswahl von VM-CPU-Modellen verwendet werden kann.

In anderen Virtualisierungsökosystemen existieren vergleichbare Mechanismen bereits. Enterprise-Plattformen bieten häufig integrierte Werkzeuge oder automatische Hilfestellungen, um kompatible CPU-Baselines zu erkennen und ungültige Live-Migrationskonfigurationen zu verhindern. Proxmox VE verfügt derzeit jedoch über keinen solchen automatisierten Erkennungsmechanismus, sodass Administratoren CPU-Flags manuell vergleichen oder sich auf Betriebserfahrung verlassen müssen. ProxCLMC schließt diese Lücke, indem es eine clusterweite CPU-Kompatibilitätsanalyse bereitstellt, die speziell auf Proxmox-Umgebungen zugeschnitten ist.

Wie funktioniert ProxCLMC?

ProxCLMC ist so konzipiert, dass es sich nahtlos in bestehende Proxmox-VE-Cluster integrieren lässt, ohne zusätzliche Dienste, Agents oder Konfigurationsänderungen zu erfordern. Es ist vollständig in Rust geschrieben (vollständig Open Source unter GPLv3), wird als statisches Binary kompiliert und als Debian-Paket über das gyptazy-Repository bereitgestellt, um eine einfache Installation zu ermöglichen. Der Arbeitsablauf folgt einem klaren und transparenten Prozess, der widerspiegelt, wie Administratoren über CPU-Kompatibilität nachdenken, diesen jedoch zuverlässig und reproduzierbar automatisiert.

Nach dem Start parst das Tool die lokale corosync.conf auf dem Node, auf dem es ausgeführt wird. Dadurch kann ProxCLMC automatisch alle Mitglieder des Clusters erkennen, ohne auf externe Inventare oder manuelle Eingaben angewiesen zu sein. Die ermittelte Node-Liste entspricht somit stets dem tatsächlichen Zustand des Clusters.

Sobald alle Cluster-Nodes identifiziert sind, baut ProxCLMC eine SSH-Verbindung zu jedem Node auf. Über diese Verbindung liest es remote den Inhalt von /proc/cpuinfo. Diese Datei liefert eine detaillierte und maßgebliche Sicht auf die vom Host-Kernel bereitgestellten CPU-Fähigkeiten, einschließlich des vollständigen Satzes unterstützter CPU-Flags.

Aus den gesammelten Daten extrahiert ProxCLMC die relevanten CPU-Flags und wertet sie anhand klar definierter x86-64-CPU-Baseline-Definitionen aus. Diese Baselines sind direkt an die von Proxmox VE und QEMU unterstützten CPU-Modelle angelehnt, darunter:

x86-64-v1
x86-64-v2-AES
x86-64-v3
x86-64-v4

Durch die Zuordnung der CPU-Flags jedes Nodes zu diesen standardisierten Baselines kann ProxCLMC bestimmen, welche CPU-Level pro Node unterstützt werden. Anschließend berechnet das Tool den niedrigsten gemeinsamen CPU-Typ, der von allen Nodes im Cluster geteilt wird. Diese resultierende Baseline stellt das maximale CPU-Kompatibilitätsniveau dar, das sicher für virtuelle Maschinen verwendet werden kann und dennoch uneingeschränkte Live-Migrationen zwischen allen Nodes ermöglicht. Um eine allgemeine Vorstellung von der Ausgabe zu bekommen:

test-pmx01 | 10.10.10.21 | x86-64-v3 test-pmx02 | 10.10.10.22 | x86-64-v3 test-pmx03 | 10.10.10.23 | x86-64-v4 Cluster CPU type: x86-64-v3

Mit diesem Ansatz bringt ProxCLMC eine automatisierte CPU-Kompatibilitätsprüfung in Proxmox-VE-basierte Cluster. Vergleichbare Konzepte sind aus anderen Virtualisierungsplattformen bereits bekannt, etwa VMware EVC, bei dem die CPU-Kompatibilität clusterweit erzwungen wird, um sichere Migrationen zu gewährleisten. ProxCLMC überträgt diese grundlegende Idee auf Proxmox-Umgebungen, setzt sie jedoch leichtgewichtig, transparent und vollständig offen um und fügt sich damit nahtlos in bestehende Betriebs- und Arbeitsabläufe ein.

Installation von ProxCLMC

ProxCLMC wurde mit dem Ziel entwickelt, eine einfache Bereitstellung zu ermöglichen und sich sauber in bestehende Proxmox-VE-Umgebungen zu integrieren. Es kann direkt aus dem Quellcode genutzt oder als paketiertes Debian-Binary installiert werden und eignet sich damit sowohl für Entwicklungs- als auch für Produktionsumgebungen.

Der vollständige Quellcode ist öffentlich auf GitHub verfügbar und kann unter folgender Adresse abgerufen werden:
https://github.com/gyptazy/ProxCLMC

Dies ermöglicht vollständige Transparenz, Auditierbarkeit sowie die Möglichkeit, das Tool an individuelle Anforderungen anzupassen oder selbst zu bauen.

Voraussetzungen und Abhängigkeiten

Vor der Installation von ProxCLMC müssen folgende Voraussetzungen erfüllt sein:

Ein Proxmox-VE-Cluster
SSH-Authentifizierung zwischen allen Proxmox-VE-Nodes
Netzwerkverbindung zwischen allen Cluster-Mitgliedern

ProxCLMC nutzt SSH, um jeden Node remote zu untersuchen und CPU-Informationen auszulesen. Eine passwortlose SSH-Authentifizierung wird daher empfohlen, um eine reibungslose und automatisierte Ausführung zu gewährleisten.

Installation über das Debian-Repository

Der empfohlene Weg zur Installation von ProxCLMC auf Debian-basierten Systemen, einschließlich Proxmox VE, ist über das von gyptazy bereitgestellte Debian-Repository. Dieses Repository wird auch zur Distribution des ProxLB-Projekts genutzt und fügt sich nahtlos in die üblichen Paketmanagement-Workflows ein.

Um das Repository hinzuzufügen und ProxCLMC zu installieren, führen Sie die folgenden Befehle aus:

Die Nutzung des Repositories stellt sicher, dass ProxCLMC einfach installiert, aktualisiert und gemeinsam mit anderen Systempaketen verwaltet werden kann.

Installation über ein Debian-Paket

Alternativ kann ProxCLMC auch manuell über ein vorgebautes Debian-Paket installiert werden. Dies ist besonders nützlich für Umgebungen ohne direkten Repository-Zugriff oder für Offline-Installationen.

Das Paket kann direkt über das CDN von gyptazy heruntergeladen und mit dpkg installiert werden:

Diese Methode bietet den gleichen Funktionsumfang wie die Installation über das Repository, jedoch ohne automatische Updates.

Fazit

ProxCLMC zeigt exemplarisch, wie schnell Lücken im Open-Source-Virtualisierungsökosystem geschlossen werden können, wenn reale betriebliche Anforderungen direkt adressiert werden. Ähnlich wie das ProxLB-Projekt (GitHub), das erweiterte Scheduling- und Balancing-Funktionen für Proxmox-VE-basierte Cluster bereitstellt, konzentriert sich ProxCLMC auf einen sehr spezifischen, aber kritischen Bereich, der zuvor weitgehend manuellen Prozessen und Erfahrungswerten überlassen war.

Durch die Einführung einer automatisierten CPU-Kompatibilitätserkennung bringt ProxCLMC eine Funktionalität in Proxmox-VE-Cluster, die in Enterprise-Virtualisierungsplattformen üblicherweise erwartet wird, bislang jedoch nicht in automatisierter Form verfügbar war. Es zeigt, dass Open-Source-Lösungen nicht durch fehlende Funktionen begrenzt sind, sondern vielmehr die Freiheit bieten, Plattformen genau dort zu erweitern und anzupassen, wo es am wichtigsten ist.

Mit ProxCLMC können Betreiber nun automatisch den am besten geeigneten CPU-Typ für virtuelle Maschinen in einem Proxmox-VE-Cluster ermitteln und so sichere Live-Migrationen sowie ein konsistentes Verhalten über alle Nodes hinweg gewährleisten. Zusammen mit Projekten wie ProxLB unterstreicht dies die Stärke des Open-Source-Modells: fehlende Enterprise-Funktionen können transparent ergänzt, an reale Anforderungen angepasst und mit der Community geteilt werden, um das Proxmox-Ökosystem kontinuierlich zu verbessern. Sollte Sie ebenfalls Bedarf an weiteren Anpassungen oder Entwicklungen Rund um oder für Proxmox VE benötigen, so unterstützten wir Sie gerne bei der Realisierung! Zögern Sie nicht mit uns Kontakt aufzunehmen – gerne beraten wir Sie zu Ihrem Vorhaben!

Effiziente Storage-Automatisierung in Proxmox mit dem proxmox_storage Modul

Die Verwaltung von unterschiedlichsten Storage-Systemen in Proxmox Umgebungen ist oft mit wiederkehrenden Aufgaben verbunden. Ob es um das Anlegen neuer Speicher, die Anbindung von NFS, CIFS Shares, iSCSI oder die Integration komplexerer Backends wie CephFS oder Proxmox Backup Server geht, in größeren Umgebungen mit mehreren Nodes oder ganzen Clustern kann dies schnell zeitaufwändig, fehleranfällig und schwer nachvollziehbar werden.

Mit Ansible lassen sich diese Prozesse effizient automatisieren und standardisieren. Anstatt manuell Konfigurationen vorzunehmen, sorgt Infrastructure as Code für eine klare Struktur, Reproduzierbarkeit und Nachvollziehbarkeit aller Änderungen. Ähnlich zu dem relativ neuen Modul proxmox_cluster, welches die Erstellung und den Beitritt von Proxmox Nodes zu Clustern automatisiert, erfolgt dies nun analog zu Storage-Systemen. Genau hier setzt das von unserem sehr geschätzten Kollegen Florian Paul Azim Hoberg (in der open-source Community auch als gyptazy sehr bekannt) entwickelte Ansible Modul proxmox_storage an. Es ermöglicht die einfache und flexible Integration verschiedener Storage Typen direkt in Proxmox Nodes und Cluster, automatisiert, konsistent und jederzeit wiederholbar. Das Modul befindet sich bereits in den Ansible Community.Proxmox Collections und ist Bestandteil der Collections ab Version 1.3.0.

Dadurch wird die Storage Verwaltung in Proxmox nicht nur schneller und sicherer, sondern fügt sich auch nahtlos in moderne Automatisierungs Workflows ein.

Ansible Modul: proxmox_storage

Das proxmox_storage Modul ist ein im Haus der credativ entwickeltes Ansible Modul zur automatisierten Verwaltung von Storage in Proxmox VE. Es unterstützt verschiedene Storage Typen wie NFS, CIFS, iSCSI, CephFS und Proxmox Backup Server.

Mit dem Modul lassen sich neue Storage Ressourcen anlegen, bestehende Konfigurationen anpassen und nicht mehr benötigte Speicher vollständig automatisiert wieder entfernen. Durch die Integration in Ansible Playbooks wird eine idempotente und reproduzierbare Verwaltung von Storage in Proxmox Nodes und Clustern ermöglicht. Das Modul vereinfacht komplexe Konfigurationen und reduziert Fehlerquellen, die bei manueller Einrichtung auftreten können.

iSCSI Storage hinzufügen

Die Einbindung von iSCSI Storage in Proxmox ermöglicht den zentralisierten Zugriff auf blockbasierten Speicher, der flexibel von mehreren Nodes im Cluster genutzt werden kann. Durch die Nutzung des proxmox_storage Moduls lässt sich die Anbindung automatisiert und konsistent konfigurieren, was sowohl Zeit spart als auch Fehler bei der manuellen Einrichtung verhindert.

- name: Add iSCSI storage to Proxmox VE Cluster
  community.proxmox.proxmox_storage:
    api_host: proxmoxhost
    api_user: root@pam
    api_password: password123
    validate_certs: false
    nodes: ["de-cgn01-virt01", "de-cgn01-virt02", "de-cgn01-virt03"]
    state: present
    type: iscsi
    name: net-iscsi01
    iscsi_options:
      portal: 10.10.10.94
      target: "iqn.2005-10.org.freenas.ctl:s01-isci01"
    content: ["rootdir", "images"]

Die Einbindung erfolgt dabei im Rahmen eines einzigen Tasks, bei dem die konsumierenden Nodes, sowie die iSCSI relevanten Informationen definiert werden. Ebenso lässt sich definieren, für welchen „Content“ dieser Speicher genutzt werden soll.

Proxmox Backup Server hinzufügen

Der Proxmox Backup Server (PBS) wird in Proxmox VE ebenfalls als Storage betrachtet und kann daher genauso wie andere Speicherarten in die Umgebung eingebunden werden. Mit dem proxmox_storage Modul lässt sich ein PBS unkompliziert in einzelne Nodes oder ganze Cluster integrieren, wodurch Backups zentral, konsistent und automatisiert zur Verfügung stehen.

- name: Add PBS storage to Proxmox VE Cluster
  community.proxmox.proxmox_storage:
    api_host: proxmoxhost
    api_user: root@pam
    api_password: password123
    validate_certs: false
    nodes: ["de-cgn01-virt01", "de-cgn01-virt02"]
    state: present
    name: backup-backupserver01
    type: pbs
    pbs_options:
      server: proxmox-backup-server.example.com
      username: backup@pbs
      password: password123
      datastore: backup
      fingerprint: "F3:04:D2:C1:33:B7:35:B9:88:D8:7A:24:85:21:DC:75:EE:7C:A5:2A:55:2D:99:38:6B:48:5E:CA:0D:E3:FE:66"
      export: "/mnt/storage01/b01pbs01"
    content: ["backup"]

Hinweis: Wichtig zu beachten ist dabei der zu definierende Fingerprint des Proxmox Backup Server Systems. Dieser ist immer dann relevant, wenn das zugehörige Zertifikat der Instanz nicht von einer beglaubigten root CA ausgestellt wurde. Bei der Nutzung und Legitimation einer eigenen root CA ist diese Definition nicht notwendig.

Entfernen von Storage

Nicht mehr benötigte oder veraltete Speicher lassen sich in Proxmox VE ebenso einfach wieder entfernen. Mit dem proxmox_storage Modul wird dieser Vorgang automatisiert und idempotent durchgeführt, sodass die Konfiguration des Clusters stets konsistent bleibt und ungenutzte Ressourcen sauber aufgeräumt werden. Ein besonderer Vorteil zeigt sich bei Storage Migrationen, da alte Speicher nach erfolgreicher Übertragung der Daten kontrolliert entfernt werden können. Auf diese Weise lassen sich Umgebungen schrittweise modernisieren, ohne dass manuelle Eingriffe oder unnötige Konfigurationsreste im Cluster verbleiben.

- name: Remove storage from Proxmox VE Cluster
  community.proxmox.proxmox_storage:
    api_host: proxmoxhost
    api_user: root@pam
    api_password: password123
    validate_certs: false
    state: absent
    name: net-nfsshare01
    type: nfs

Fazit

Das Beispiel der automatisierten Storage-Integration mit Ansible und Proxmox verdeutlicht eindrucksvoll die Vorteile und die Erweiterbarkeit von Open-Source-Lösungen. Open-Source-Produkte wie Proxmox VE und Ansible lassen sich flexibel kombinieren und bieten dadurch eine enorme Bandbreite an Einsatzmöglichkeiten, die sich auch im Enterprise-Umfeld bewähren.

Ein entscheidender Vorteil ist dabei die Unabhängigkeit von einzelnen Herstellern, wodurch Unternehmen keinen Vendor Lock-In fürchten müssen und langfristig mehr Gestaltungsfreiheit behalten. Gleichzeitig wird deutlich, dass die erfolgreiche Umsetzung solcher Szenarien fundiertes Wissen und Erfahrung voraussetzt, um die Möglichkeiten von Open-Source optimal auszuschöpfen.

Während dies jedoch nur einen Teilbereich abdeckt, zeigt unser Kollege Florian Paul Azim Hoberg (gyptazy) hier in seinem Video „Proxmox Cluster Fully Automated: Cluster Creation, NetApp Storage & SDN Networking with Ansible“ eindrucksvoll, wie eine Vollautomatisierung mit Proxmox aussehen kann.

Genau hier stehen wir als Partner zur Seite und unterstützen Sie gerne in den Bereichen Automatisierung, Entwicklung sowie bei allen Fragen rund um Proxmox und moderne Infrastrukturen. Zögern Sie nicht mit uns Kontakt aufzunehmen – gerne beraten wir Sie!

Automatisierte Proxmox-Abonnementverwaltung mit Ansible

Bei der Bereitstellung von Proxmox VE in Enterprise-Umgebungen, sei es für neue Standorte, die Erweiterung bestehender Cluster oder die Migration von Plattformen wie VMware, ist Automatisierung unerlässlich. Diese Szenarien umfassen typischerweise die Bereitstellung von Dutzenden oder sogar Hunderten von Knoten über mehrere Standorte hinweg. Das manuelle Aktivieren von Abonnements über die Proxmox-Weboberfläche ist in diesem Umfang nicht praktikabel.

Um Konsistenz und Effizienz zu gewährleisten, sollte jeder Teil des Bereitstellungsprozesses von Anfang an automatisiert werden. Dies umfasst nicht nur die Installation und Konfiguration von Knoten, die automatisierte Cluster-Erstellung, sondern auch die Aktivierung des Proxmox-Abonnements. In der Vergangenheit erforderte dieser Schritt oft eine manuelle Interaktion, was die Bereitstellung verlangsamte und unnötige Komplexität verursachte.

Jetzt gibt es eine saubere Lösung dafür. Mit der Einführung des neuen Ansible-Moduls proxmox_node ist die Abonnementverwaltung vollständig integriert. Dieses Modul ermöglicht es Ihnen, die Abonnementaktivierung als Teil Ihrer Ansible-Playbooks zu handhaben, wodurch es möglich wird, den gesamten Prozess zu automatisieren, ohne jemals die Weboberfläche öffnen zu müssen.

Diese Verbesserung ist besonders wertvoll für Massenbereitstellungen, bei denen Zuverlässigkeit und Wiederholbarkeit am wichtigsten sind. Jeder Knoten kann nun direkt nach dem Booten automatisch konfiguriert, lizenziert und produktionsbereit sein. Es ist ein großartiges Beispiel dafür, wie sich Proxmox VE kontinuierlich zu einer unternehmensfreundlicheren Plattform entwickelt und gleichzeitig die Flexibilität und Offenheit beibehält, die es auszeichnet.

Ansible-Modul: proxmox_node

Da die Automatisierung in modernen IT-Betrieben immer wichtiger wird, ist die Verwaltung der Proxmox VE-Infrastruktur über standardisierte Tools wie Ansible zu einer gängigen Praxis geworden. Bis jetzt, obwohl verschiedene Community-Module zur Interaktion mit Proxmox-Ressourcen verfügbar waren, erforderte die Knotenverwaltung oft benutzerdefinierte Workarounds oder direkten SSH-Zugriff. Diese Lücke wurde nun mit der Einführung des neuen proxmox_node Moduls geschlossen.

Dieses Modul wurde von unserem Team bei credativ GmbH entwickelt, insbesondere von unserem Kollegen, der in der Community unter dem Handle gyptazy bekannt ist. Es wurde Upstream beigetragen und ist bereits Teil der offiziellen Ansible Community Proxmox Collection, die jedem zur Verfügung steht, der die Collection über Ansible Galaxy oder Automation Controller Integrationen verwendet.

Das proxmox_node Modul konzentriert sich auf Aufgaben, die direkt mit dem Lebenszyklus und der Konfiguration eines Proxmox VE-Knotens zusammenhängen. Was dieses Modul besonders leistungsfähig macht, ist, dass es direkt mit der Proxmox API interagiert, ohne dass ein SSH-Zugriff auf den Knoten erforderlich ist. Dies ermöglicht einen saubereren, sichereren und API-gesteuerten Ansatz zur Automatisierung.

Das Modul unterstützt derzeit mehrere Schlüsselfunktionen, die im realen Betrieb unerlässlich sind:

Verwaltung von Abonnementlizenzen
Eine der herausragenden Funktionen ist die Möglichkeit, einen Proxmox VE-Abonnementschlüssel automatisch hochzuladen und zu aktivieren. Dies ist unglaublich hilfreich für Unternehmen, die Cluster in großem Umfang ausrollen, wo die Lizenzierung konsistent und automatisch als Teil des Bereitstellungs-Workflows gehandhabt werden sollte.
Steuerung der Leistungszustände
Die Energieverwaltung von Knoten kann nun über Ansible erfolgen, was es einfach macht, Knoten im Rahmen von Playbook-gesteuerten Wartungsaufgaben oder während automatisierter Clusteroperationen zu starten (über Wake-on-Lan) oder herunterzufahren.
Verwaltung der DNS-Konfiguration
DNS-Einstellungen wie Resolver und Suchdomänen können deklarativ geändert werden, wodurch sichergestellt wird, dass alle Knoten die gleichen Konfigurationsrichtlinien ohne manuelle Eingriffe befolgen.
Verwaltung von X509-Zertifikaten
Das Modul ermöglicht es Ihnen auch, die von dem Knoten verwendeten TLS-Zertifikate zu verwalten. Unabhängig davon, ob Sie intern PKI-signierte Zertifikate bereitstellen oder extern ausgestellte verwenden, können Sie mit dem proxmox_node Modul diese über die Automatisierung auf saubere und wiederholbare Weise hochladen und anwenden.

Indem all diese Funktionalität in einem einzigen, API-gesteuerten Ansible-Modul zusammengeführt wird, wird der Prozess der Verwaltung von Proxmox-Knoten wesentlich zuverlässiger und wartungsfreundlicher. Sie müssen nicht mehr mit Shell-Befehlen um pveproxy herumskripten oder SSH verwenden, nur um Knoteneinstellungen zu verwalten.

Beispiel für die Integration von Abonnements

Das Hinzufügen eines Abonnements zu einem Proxmox VE-Knoten ist so einfach wie die folgende Aufgabe. Dies zeigt zwar den einfachsten Weg für einen einzelnen Knoten, kann aber auch in einer Schleife über ein Dictionary verwendet werden, das die zugehörigen Abonnements für jeden Knoten enthält.

- name: Platzieren einer Abonnementlizenz auf einem Proxmox VE-Knoten
  community.proxmox.node:
  api_host: proxmoxhost
  api_user: gyptazy@pam
  api_password: password123
  validate_certs: false
  node_name: de-cgn01-virt01
  subscription:
  state: present
  key: ABCD-EFGH-IJKL-MNOP-QRST-UVWX-YZ0123456789

Fazit

Für uns bei credativ schließt dieses Modul eine echte Lücke in der Automatisierungslandschaft rund um Proxmox und demonstriert, wie fehlende Funktionen in Open-Source-Projekten durch Upstream-Beiträge effektiv angegangen werden können. Es verstärkt auch die breitere Bewegung der deklarativen Verwaltung von Infrastruktur, bei der die Konfiguration versioniert, dokumentiert und leicht reproduzierbar ist.

In Kombination mit anderen Modulen aus der Community Proxmox Collection wie unserem kürzlich erschienenen proxmox_cluster Modul, proxmox_node hilft, das Bild einer vollständig automatisierten Proxmox VE-Umgebung zu vervollständigen — von der Cluster-Erstellung und VM-Bereitstellung bis hin zur Knotenkonfiguration und Lizenzierung. Wenn Sie Hilfe oder Unterstützung bei der Erstellung von Proxmox VE-basierten Virtualisierungsinfrastrukturen, Automatisierung oder kundenspezifischer Entwicklung zur Anpassung an Ihre Bedürfnisse suchen, helfen wir Ihnen gerne weiter! Sie können uns jederzeit gerne kontaktieren.

Effiziente Proxmox-Cluster-Bereitstellung durch Automatisierung mit Ansible

Das manuelle Einrichten und Verwalten von Servern ist in der Regel zeitaufwendig, fehleranfällig und schwer zu skalieren. Dies wird besonders bei groß angelegten Rollouts, beim Aufbau komplexer Infrastrukturen oder bei der Migration aus anderen Virtualisierungsumgebungen deutlich. In solchen Fällen stoßen traditionelle manuelle Prozesse schnell an ihre Grenzen. Eine konsequente Automatisierung bietet eine effektive und nachhaltige Lösung für diese Herausforderungen.

Proxmox ist eine leistungsstarke Virtualisierungsplattform, die für ihre Flexibilität und ihren umfassenden Funktionsumfang bekannt ist. In Kombination mit Ansible, einem schlanken und agentenlosen Automatisierungstool, wird die Verwaltung ganzer Systemlandschaften deutlich effizienter. Ansible ermöglicht die Definition wiederverwendbarer Konfigurationen in Form von Playbooks, wodurch sichergestellt wird, dass Bereitstellungsprozesse konsistent, transparent und reproduzierbar sind.

Um eine vollständig automatisierte Bereitstellung von Proxmox-Clustern zu ermöglichen, hat unser Teammitglied, das in der Open-Source-Community unter dem Alias gyptazy bekannt ist, ein dediziertes Ansible-Modul namens proxmox_cluster. Dieses Modul übernimmt alle notwendigen Schritte, um einen Proxmox-Cluster zu initialisieren und zusätzliche Knoten hinzuzufügen. Es wurde offiziell in die Upstream Ansible Community Proxmox Collection aufgenommen und ist ab Version 1.1.0 über Ansible Galaxy installierbar. Dadurch wird der manuelle Aufwand für die Cluster-Bereitstellung deutlich reduziert. Weitere Einblicke finden Sie in seinem Blogbeitrag mit dem Titel „How My BoxyBSD Project Boosted the Proxmox Ecosystem„.

Durch die Einführung dieser Lösung kann nicht nur wertvolle Zeit gespart werden, sondern es wird auch eine solide Grundlage für eine skalierbare und wartungsarme Infrastruktur geschaffen. Im Gegensatz zu fragilen, aufgabenbasierten Ansätzen, die oft auf Ansibles shell oder command Modulen basieren, nutzt diese Lösung das volle Potenzial der Proxmox-API durch ein dediziertes Modul. Dadurch kann sie in verschiedenen Bereichen ausgeführt werden und benötigt keinen SSH-Zugriff auf die Zielsysteme.

Dieser automatisierte Ansatz ermöglicht es, komplexe Setups effizient bereitzustellen und gleichzeitig die Grundlage für stabile und zukunftssichere IT-Umgebungen zu schaffen. Solche Umgebungen können zu einem späteren Zeitpunkt erweitert werden und sind nach einer konsistenten und wiederholbaren Struktur aufgebaut.

Vorteile

Die Verwendung des proxmox_cluster Moduls für die Proxmox-Cluster-Bereitstellung bringt mehrere entscheidende Vorteile für moderne IT-Umgebungen. Der Fokus liegt auf einer sicheren, flexiblen und skalierbaren Interaktion mit der Proxmox-API, einer verbesserten Fehlerbehandlung und einer vereinfachten Integration in verschiedenen Anwendungsfällen:

Nutzung der nativen Proxmox-API
Volle Unterstützung für das Proxmox-Authentifizierungssystem
- Unterstützung der API-Token-Authentifizierung
Kein SSH-Zugriff erforderlich
Einsetzbar in mehreren Bereichen:
- Von einem dedizierten Bereitstellungs-Host
- Von einem lokalen System
- Innerhalb des Kontexts des Zielsystems selbst
Verbesserte Fehlerbehandlung durch API-Abstraktion

Ansible Proxmox Modul: proxmox_cluster

Das neu hinzugefügte proxmox_cluster Modul in Ansible vereinfacht die automatisierte Bereitstellung von Proxmox VE-Clustern erheblich. Mit nur einer einzigen Aufgabe ermöglicht es die nahtlose Erstellung eines kompletten Clusters, wodurch Komplexität und manueller Aufwand auf ein Minimum reduziert werden.

Erstellung eines Clusters

Die Erstellung eines Clusters erfordert jetzt nur noch eine einzige Aufgabe in Ansible unter Verwendung des Proxmox_Cluster-Moduls:

- name: Create a Proxmox VE Cluster
  community.proxmox.proxmox_cluster:
  state: present
  api_host: proxmoxhost
  api_user: root@pam
  api_password: password123
  api_ssl_verify: false
  link0: 10.10.1.1
  link1: 10.10.2.1
  cluster_name: "devcluster"

Anschließend wird der Cluster erstellt und zusätzliche Proxmox VE-Knoten können dem Cluster beitreten.

Beitritt zu einem Cluster

Zusätzliche Knoten können dem Cluster nun ebenfalls mit einer einzigen Aufgabe beitreten. In Kombination mit der Verwendung eines dynamischen Inventars wird es einfach, eine Liste von Knoten aus einer definierten Gruppe zu durchlaufen und diese innerhalb einer Schleife dem Cluster hinzuzufügen. Dieser Ansatz ermöglicht die schnelle Bereitstellung größerer Proxmox-Cluster auf effiziente und skalierbare Weise.

- name: Join a Proxmox VE Cluster
  community.proxmox.proxmox_cluster:
  state: present
  api_host: proxmoxhost
  api_user: root@pam
  api_password: password123
  master_ip: "{{ primary_node }}"
  fingerprint: "{{ cluster_fingerprint }}"
  cluster_name: “devcluster"

Cluster-Beitrittsinformationen

Damit ein Knoten einem Proxmox-Cluster beitreten kann, sind in der Regel die Beitrittsinformationen des Clusters erforderlich. Um diese Informationen nicht für jeden einzelnen Cluster manuell definieren zu müssen, kann auch dieser Schritt automatisiert werden. Im Rahmen dieser Funktion wurde ein neues Modul namens cluster_join_info eingeführt. Es ermöglicht, die notwendigen Daten automatisch über die Proxmox-API abzurufen und für die weitere Verwendung im Automatisierungsprozess bereitzustellen.

- name: List existing Proxmox VE cluster join information
  community.proxmox.proxmox_cluster_join_info:
  api_host: proxmox1
  api_user: root@pam
  api_password: "{{ password | default(omit) }}"
  api_token_id: "{{ token_id | default(omit) }}"
  api_token_secret: "{{ token_secret | default(omit) }}"
  register: proxmox_cluster_join

Fazit

Während die Automatisierung im Kontext von Virtualisierungstechnologien oft auf die Bereitstellung von Gastsystemen oder virtuellen Maschinen (VMs) ausgerichtet ist, zeigt dieser Ansatz, dass Automatisierung auf einer viel tieferen Ebene innerhalb der zugrunde liegenden Infrastruktur angewendet werden kann. Es ist auch möglich, Szenarien vollständig zu automatisieren, in denen Knoten zunächst mit einem kundenspezifischen Image mit vorinstalliertem Proxmox VE bereitgestellt werden und anschließend automatisch der Cluster erstellt wird.

Als offizieller Proxmox-Partner unterstützen wir Sie gerne bei der Implementierung einer umfassenden Automatisierungsstrategie, die auf Ihre Umgebung zugeschnitten ist und auf Proxmox-Produkten basiert. Sie können uns jederzeit kontaktieren!

ProxLB – Die neue Version des Loadbalancers für Proxmox Cluster steht in Version 1.1.0 bereit!

Kein April Scherz – endlich ist sie da – die langersehnte Version 1.1.0 von ProxLB wurde heute offiziell veröffentlicht! Diese neue Version bringt ein vollständiges Code-Refactoring mit sich, das nicht nur die Wartung erleichtert, sondern auch die Grundlage für zukünftige Erweiterungen schafft. Außerdem werden zahlreiche Bugs behoben und weitere Features implementiert. ProxLB ist das Ergebnis des Engagements unseres Mitarbeiters Florian Paul Azim Hoberg, besser bekannt als gyptazy, der mit seinem Wissen und seiner Leidenschaft eine leistungsfähige Open-Source-Lösung für Proxmox-Cluster entwickelt hat. Wir als credativ GmbH unterstützen dabei die Tätigkeiten in diesem open-source Projekt und freuen uns, wenn dies auch künftig noch mehr von der Community aufgenommen und genutzt wird. Künftig wird ProxLB dabei auch weitere interessante Features wie ein dynamisches Energiemanagement (ähnlich zu DPM) und ein automatisiertes Node-Security-Patching integriert bekommen, die in der Community bereits oft angefragt wurden.

Lücke zu VMware schließen

ProxLB - An Advanced Loadbalancer for Proxmox Clusters

ProxLB schließt die Lücke, die durch das Fehlen eines Dynamic Resource Scheduler (DRS) in Proxmox entstanden ist. Als leistungsstarker Load Balancer werden dabei Workloads bzw. virtuelle Maschinen (VMs) intelligent über alle Nodes im Cluster migriert, welches für eine insgesamt optimale Nutzung der Ressourcen in einem Proxmox Cluster sorgt. Dabei berücksichtigt ProxLB die CPU-, Speicher- und Festplattenauslastung, um Überprovisionierung zu vermeiden und die Leistung zu maximieren.

Wartungsmodus

Ein besonderes Highlight von ProxLB ist der Wartungsmodus. Sobald ein oder mehrere Node(s) in den Wartungsmodus versetzt werden, werden alle darauf laufenden VMs und Container automatisch auf andere Nodes verschoben – natürlich unter Berücksichtigung der bestmöglichen Ressource-Auslastung im Cluster. Dies ermöglicht problemlose Updates, Neustarts oder Hardware-Wartungen, ohne den laufenden Betrieb zu stören.

Affinitätsregeln im Griff

Darüber hinaus bietet ProxLB umfangreiche Möglichkeiten zur Anpassung durch Affinitäts- und Anti-Affinitätsregeln. Administratoren können festlegen, dass bestimmte VMs entweder gemeinsam auf einem Node laufen oder bewusst voneinander getrennt werden. Dies ist besonders nützlich für hochverfügbare Anwendungen oder spezielle Workloads. Ein weiteres praktisches Feature ist die Möglichkeit, den optimalen Node für neue Gäste zu identifizieren. Diese Funktion lässt sich problemlos in CI/CD-Pipelines integrieren, beispielsweise mit Ansible oder Terraform, um Deployments zu automatisieren und die Cluster-Effizienz weiter zu steigern. Wie dies anhand von ProxLB mit Terraform funktioniert, kann man in diesem Beispiel sehen.

ProxLB zeichnet sich zudem durch seine tiefe Integration in die Proxmox-API aus. Die gesamte Access Control List (ACL) wird unterstützt, sodass keine zusätzlichen SSH-Zugriffe erforderlich sind. Dies sorgt nicht nur für mehr Sicherheit, sondern auch für eine einfachere Verwaltung. Egal ob als Einmal-Operation oder im Daemon-Modus: ProxLB ist flexibel einsetzbar und bietet eine transparente und effiziente Lösung für das Cluster-Management. Dank der offenen und freien Lizenz können Nutzer die Software an ihre Bedürfnisse anpassen und zur Weiterentwicklung beitragen.

Download

ProxLB lässt sich auf verschiedensten Weisen installieren und betreiben. So kann ProxLB auf dedizierter Hardware, einer dedizierten VM (auch innerhalb des Clusters), in LXC, auf einem Proxmox Node selber oder gar in einem Docker Container durch die bereitgestellten Container-Images betrieben werden. Das Installations-Kapitel im Projekt selbst erklärt dies dabei etwas detaillierter und beschreibt auch die Nutzung des Projekt eigenen Repositorys für Debian basierende Systeme.

Typ	Download
Debian Package	proxlb_1.1.0_all.deb
Container Image	cr.gyptazy.com/proxlb/proxlb:latest

Fazit

Mit der Version 1.1.0 wird ProxLB seinem Ruf als unverzichtbares Tool für Proxmox-Administratoren, gerade für Wechsler aus dem VMware Bereich, mehr als gerecht. Probieren Sie die neue Version aus und erleben Sie, wie einfach und effizient das Load Balancing in Ihrem Cluster sein kann! Gerne unterstützen wir Sie auch bei der Integration und dem Betrieb von ProxLB in Ihrem Cluster, als auch bei allen anderen Themen Rund um Proxmox – auch bei der Planung einer Migration von anderen Hypervisor-Technologien zu Proxmox!

Einen Merkzettel zum Teilen können Sie hier herunterladen: ProxLB Flyer

Einführung

Proxmox Virtual Environment (VE) ist eine leistungsstarke Open-Source-Plattform für die Virtualisierung in Unternehmen. Sie unterstützt erweiterte Funktionen für die dynamische Speicherverwaltung, darunter Kernel Samepage Merging (KSM) und Memory Ballooning, mit denen sich die Speichernutzung optimieren und die Leistung verbessern lässt. In diesem Blogbeitrag wird die Effektivität der KSM- und Memory-Ballooning-Funktionen in Proxmox VE anhand von Linux-Virtual Machines (VMs) bewertet. Wir richten eine VM mit Proxmox VE für eine Testumgebung ein, führen Tests durch und analysieren die Ergebnisse, um zu verstehen, wie diese Funktionen virtualisierten Umgebungen zugute kommen können. Darüber hinaus werden wir uns mit den Sicherheitsbedenken bei der Aktivierung von KSM und den Risiken im Zusammenhang mit der Verwendung von Ballooning befassen, insbesondere in Datenbankumgebungen.

Was ist KSM?

Kernel Samepage Merging (KSM) ist eine Funktion zur Speicherdeduplizierung im Linux-Kernel, die nach identischen Speicherseiten in verschiedenen Prozessen sucht und diese zu einer einzigen Seite zusammenfasst, um den Speicherverbrauch zu reduzieren. Dies ist besonders nützlich in virtualisierten Umgebungen, in denen mehrere VMs ähnliche oder identische Daten im Speicher haben können, beispielsweise wenn dasselbe Betriebssystem oder dieselben Anwendungen ausgeführt werden.

KSM wurde bereits vor langer Zeit mit der Linux-Kernel-Version 2.6.32 im Jahr 2009 eingeführt. Das hindert die Entwickler jedoch nicht daran, neue Funktionen für KSM einzuführen, wie der 6.x-Kernel zeigt. Es gibt neue Änderungen, die Sie hier finden können: Aufschlüsselung der Änderungen an Kernel Samepage Merging (KSM) nach Kernel-Version. Wie Sie sehen können, fügen die Kernel-Entwickler dem Linux-Kernel ständig neue Funktionen für KSM hinzu, um dessen Funktionalität weiter zu verbessern.

Der derzeit in Proxmox VE verwendete Linux-Kernel ist beispielsweise 6.8.x. Er unterstützt die neu hinzugefügte Funktion „Smart Scan“, die wir in diesem Blogbeitrag gemeinsam testen werden.

Was ist Memory Ballooning?

Memory Ballooning ist eine Technik, die in virtualisierten Umgebungen verwendet wird, um die Speicherzuweisung von VMs dynamisch an ihren aktuellen Bedarf anzupassen. Ein „Balloon-Treiber” innerhalb der Gast-VM weist ungenutzten Speicher einem Speicherpool (dem „Balloon”) zu, sodass der Hypervisor Speicherressourcen bei Bedarf anderen VMs zuweisen kann. Dies trägt zur Optimierung der Speichernutzung im gesamten Hostsystem bei und stellt sicher, dass der Speicher effizient genutzt und nicht für inaktive VMs verschwendet wird.

Testaufbau

Um die KSM- und Ballooning-Funktionen in Proxmox VE zu evaluieren, haben wir einen Testcluster eingerichtet, der aus einem Knoten besteht, den wir in einer VM mit 16 GB RAM betreiben. Auf diesem Beispielcluster werden dann mehrere Linux-Gast-VMs ausgeführt, um die KSM- und Memory-Ballooning-Funktionen zu demonstrieren.

Die folgende Abbildung zeigt eine Übersicht über unsere Test-VM-Konfiguration:

Proxmox VE Host:

Eine VM zur Installation von Proxmox VE 8.2.
- 8 Cores vCPU
- 16GB RAM
- 200GB Virtio storage

Linux Gast VM Template:

Linux Gast
- 2GB RAM
- Installiertes Debian LXQt desktop
- 16GB Virtio storage

Linux Gast VMs:

8 VMs, Linked-Clone aus dem Template

Tests durchführen

Wir führen zwei Testreihen durch. Zunächst bewerten wir nur KSM. Anschließend führen wir eine weitere Testreihe durch, um Memory Ballooning ohne KSM zu testen.

Einrichtung von Gast-VMs für KSM-Tests:

Wir haben 8 VMs aus unserer VM-Vorlage mit jeweils 2 GB RAM geklont, wie Sie in der Abbildung unten sehen können.
Jede VM wurde mit 2 GB RAM konfiguriert, ohne dass Ballooning aktiviert wurde.
Als Nächstes starten wir diese 8 VMs und starten sie mit LXQt Desktop Auto-Login, ohne KSM auszulösen. Hier möchten wir überprüfen, wie viel Speicher jede dieser VMs verbraucht, bevor wir irgendeine Art von Reduzierungsmechanismus anwenden.
Wie Sie sehen können, verbrauchen alle 8 VMs insgesamt 13.154,1 MB. Der obige Screenshot wurde auf unserem Proxmox VE-Host aufgenommen.
Aktivieren Sie KSM Smart Scan mit dem folgenden Befehl auf dem Host:
```
# echo "scan-time" > /sys/kernel/mm/ksm/advisor_mode
```
KSM aktivieren:
```
# echo 1 > /sys/kernel/mm/ksm/run
```

Beobachtungen zu KSM Smart Scan

Die KSM-Funktion Smart Scan scheint im Vergleich zur klassischen ksmtuned-Methode effizienter zu sein, da sie Optimierungen für das Scannen von Seiten enthält, die Seiten überspringen, wenn die Deduplizierung bei früheren Versuchen nicht erfolgreich war. Dadurch wird die für das Scannen von Seiten erforderliche CPU-Zeit erheblich reduziert, was besonders hilfreich ist, wenn das System einen „stabilen Zustand” erreicht hat. Während unserer Tests haben wir nicht beobachtet, dass ksmd nennenswerte Systemressourcen beansprucht, sodass KSM Smart Scan die Speichernutzung mit minimalem Overhead optimieren kann.

Testergebnisse

Nach einer Weile, während KSM die Seiten scannt und zusammenführt, reduziert sich der verwendete Speicher auf 6.770,1 Mib.
Wir können auch den KSM-Freigabestatus in der Proxmox VE WebUI sehen.

Es wurde eine deutliche Verringerung des Speicherverbrauchs festgestellt. Obwohl während des KSM-Betriebs ein leichter Anstieg der CPU-Auslastung durch ksmd zu verzeichnen war, kam es zu keiner nennenswerten Verschlechterung der VM-Leistung. Dies zeigt, dass KSM effizient arbeitet, ohne das System stark zu belasten. Die Zusammenführung identischer Seiten führte zu einer besseren Speichernutzung, sodass mehr VMs ohne zusätzliche Hardware auf demselben Host ausgeführt werden konnten.

Kernel Samepage Merging (KSM) in Windows-VMs

KSM ist eine native Funktion des Linux-Kernels, die auf Hypervisor-Ebene arbeitet, Speicherseiten aller VMs scannt und identische Seiten zu einer einzigen gemeinsamen Seite zusammenführt. Dieser Prozess reduziert den Gesamtspeicherbedarf der VMs.

Bei Windows-VMs behandelt der Hypervisor deren Speicher ähnlich wie bei Linux-VMs, indem er identische Seiten identifiziert und zusammenführt. Das bedeutet, dass die Vorteile von KSM auch auf Windows-VMs ausgeweitet werden können, die auf Proxmox VE laufen, da Proxmox selbst unter Linux läuft und daher die KSM-Kernel-Funktion nutzt, unabhängig davon, welches Betriebssystem die Gast-VMs auf Proxmox VE ausführen.

Einrichtung der Gast-VMs für Ballooning-Tests:

Als Nächstes sehen wir uns Memory Balloning in einem weiteren Test an. Um die Balloning-Funktionen in Proxmox VE zu bewerten, werden wir die für KSM-Tests verwendete Proxmox VE-Umgebung mit den folgenden Anpassungen umfunktionieren:

Behalten Sie drei VMs und entfernen Sie die anderen.
Aktivieren Sie Ballooning in jeder VM.
Stellen Sie den minimalen Speicher auf 2048 MB und den maximalen Speicher auf 5120 MB in jeder VM ein.
.

Deaktivieren Sie KSM:

Um KSM manuell zu deaktivieren, führen Sie den folgenden Befehl aus:

# echo 2 > /sys/kernel/mm/ksm/run

Das folgende Bild zeigt eine Übersicht über die Einrichtung unserer Ballooning-Test-VMs:

Aufgrund des Memory Ballooning sollte nun für jede VM mehr Speicher verfügbar sein. Testen wir dies, indem wir mit stress-ng jeder Gast-VM 4 GB Speicher zuweisen und den zugewiesenen Speicher für eine von Ihnen festgelegte Anzahl von Sekunden halten:

$ stress-ng --vm-bytes 4G -m 1 --vm-hang <seconds>

Die Option –vm-hang <Sekunden> gibt an, wie viele Sekunden die VM hängen bleibt, bevor der Speicher freigegeben wird.

OOM-Killer!

Wir haben beobachtet, dass der OOM-Killer auf dem Proxmox VE-Host ausgelöst wurde.

Die Auslösung des OOM-Killers auf dem Host ist problematisch. Die Zuweisung von 5 GB Speicher an jede VM führte zu einer übermäßigen Überbelegung, wodurch der OOM-Killer aufgrund unzureichender Speicherressourcen zur Bewältigung der Host-Workload aktiviert wurde.

Das Auslösen des OOM-Killers ist immer problematisch, aber auf dem Host ist es noch schlimmer als in Gast-VMs, da man nie weiß, welche VM beendet und getötet wird, oder es zumindest sehr schwer vorherzusagen ist.

Einer der Hauptzwecke von Memory Ballooning ist es, die Auslösung des OOM-Killers auf dem Host-System zu vermeiden, da dieser „mehr“ Schaden anrichten kann als ein OOM-Killer, der innerhalb einer bestimmten VM ausgelöst wird.

Reduzieren Sie die maximale Speicherkonfiguration in VMs für Ballooning-Tests.

Um das Problem der Überbelegung zu beheben, reduzieren wir die maximale Speicherkonfiguration in jeder VM auf 4 GB.

Passen Sie die maximale Speichereinstellung für jede VM auf 4 GB an.
Starten Sie drei VMs.

Als Nächstes verwenden wir stress-ng in der Gast-VM, um 3 GB Speicher zuzuweisen und dann für eine bestimmte Dauer ohne CPU-Auslastung auf jeder Gast-VM zu hängen:

$ stress-ng --vm-bytes 3G -m 1 --vm-hang <seconds>

Dies ist der Befehl top in der Gast-VM.

Überprüfen der Speichernutzung auf dem Host

Nach dem Ausführen des stress-ng-Tests überprüfen wir die Speichernutzung auf dem Host:

Der freie Speicherplatz auf dem Host ist nun knapp. Die dritte VM, die versucht, Speicherplatz zuzuweisen, weist aufgrund der begrenzten Ressourcen auf dem Host eine sehr hohe CPU-Auslastung auf.

Nach einer Weile können wir beobachten, wie der Ballooning-Treiber beginnt, Speicherplatz von den Gast-VMs auf dem Host zurückzugewinnen. Der RES (belegter physischer Speicher) jeder VM wurde reduziert:

Der Ballooning-Treiber fordert nun Speicher von jeder Gast-VM zurück, um den verfügbaren freien Speicher auf dem Host zu erhöhen. Diese Maßnahme trägt dazu bei, die Arbeitslast des Hosts aufrechtzuerhalten, führt jedoch aufgrund der reduzierten Speicherzuweisung zu einer Verlangsamung aller anderen Gast-VMs.

Auswirkungen von Ballooning auf Gast-VMs

Die verlangsamten VMs verfügen schließlich nicht mehr über genügend freien Speicher, um ihre Workloads aufrechtzuerhalten. Infolgedessen wird der OOM-Killer innerhalb der Gast-VMs ausgelöst:

Alle VMs hängen eine Weile, dann löst der OOM-Killer aus, um den Prozess stress-ng zu beenden. Danach kehren die VMs in ihren normalen Zustand zurück, und auf dem Host ist ausreichend freier Speicher verfügbar:

Wann wird Memory Stealing ausgelöst?

Um festzustellen, wann Memory Stealing ausgelöst wird, führen wir einen weiteren Test durch. Wir verwenden denselben Befehl stress-ng, um 3 GB Speicher auf zwei VMs zuzuweisen.

Als Nächstes weisen wir der dritten VM nach und nach Speicher zu, beginnend mit 512 MB, und fügen dann schrittweise weitere 512 MB hinzu, bis wir beobachten, dass die Speicherrückgewinnung ausgelöst wird.

Während wir die Speicherzuweisung auf der dritten VM schrittweise erhöhen, überwachen wir die Speichernutzung des Hosts:

Wir stellen fest, dass Memory Stealing noch nicht ausgelöst wird, wenn der verfügbare freie Speicher auf dem Host 2.978,1 MB (ca. 18,5 %) des Gesamtspeichers erreicht.

Weisen wir der dritten VM etwas mehr Speicher zu, um den verfügbaren freien Speicher auf dem Host weiter zu reduzieren. Wir haben festgestellt, dass der Ballooning-Treiber Speicher von den Gast-VMs stiehlt, wenn der verfügbare freie Speicher auf dem Host etwa 15 % des Gesamtspeichers erreicht:

An dieser Stelle können wir sehen, dass der den VMs zugewiesene Speicher reduziert wird und die CPU-Auslastung deutlich ansteigt.

Der Speicherentnahmeprozess wird fortgesetzt, bis der verfügbare freie Speicher auf dem Host wieder 20 % des Gesamtspeichers erreicht. Nach der Freigabe des zugewiesenen Speichers aus der dritten VM stellen wir fest, dass der Rückgewinnungsprozess stoppt, wenn der verfügbare freie Speicher auf dem Host 20 % des Gesamtspeichers erreicht.

Visualisierung der Ergebnisse der Ballooning-Tests

Die folgende Abbildung veranschaulicht die Beobachtungen aus unseren Tests:

Auf diesem Bild sehen Sie die folgenden wichtigen Punkte:

Mehr als 20 % freier Speicherplatz auf dem Host: Die anfängliche Speicherzuweisung für die VMs, wobei jede VM so konfiguriert ist, dass ihr maximal 4 GB Speicher zugewiesen werden können.
Auslösen von Memory Stealing: Der Punkt, an dem der verfügbare freie Speicher auf dem Host auf etwa 15 % des Gesamtspeichers sinkt, wodurch der Ballooning-Treiber ausgelöst wird, um Speicher von den Gast-VMs zurückzugewinnen. Die rote Farbe in Gast-VMs zeigt eine erhöhte CPU-Auslastung an, da der Ballooning-Treiber Speicher stiehlt und dadurch die Leistung der Gast-VMs beeinträchtigt.

Memory Ballooning in Windows VMs

Memory Ballooning funktioniert auch mit Windows-VMs in Proxmox VE durch Windows VirtIO-Treiber. Die Treiber-ISO finden Sie im Proxmox-Wiki oder können direkt von VirtIO-Treiber-ISO heruntergeladen werden.

Vergleich zu Linux VMs

Memory Hot Plug wird in Linux-VMs unterstützt, sodass sich die Gesamtspeichermenge dynamisch ändern kann, wenn der Ballooning-Treiber aktiv ist. Das bedeutet, dass Sie in Linux-VMs sehen können, wie sich die Gesamtspeicherzuweisung in Echtzeit anpasst, während der Ballooning-Treiber arbeitet. Windows unterstützt Memory Hot Plug nicht auf die gleiche Weise. Daher sehen Sie in einer Windows-VM keine Anpassung der Gesamtspeichermenge. Stattdessen werden Sie eine Zunahme der verwendeten Speichermenge beobachten. Trotz dieses Unterschieds ist das Endergebnis dasselbe: Der verfügbare freie Speicher wird reduziert, wenn der Ballooning-Treiber Speicher zurückgewinnt.

Dieser Screenshot zeigt, dass der belegte Speicher zunimmt, wenn Ballooning aktiv ist, um Speicher innerhalb der Windows-VM zu stehlen.

Ergebnisse

Memory Ballooning in Proxmox VE ist eine leistungsstarke Funktion zur dynamischen Verwaltung der Speicherzuweisung zwischen VMs, wodurch die Gesamtspeichernutzung des Hosts optimiert wird. Es ist jedoch wichtig, die Schwellenwerte zu kennen, die die Speicherrückgewinnung auslösen, um Leistungseinbußen zu vermeiden. Es wird empfohlen, eine angemessene Mindestspeichergrenze festzulegen, um sicherzustellen, dass bei Erreichen dieses Mindestschwellenwerts kein weiterer Speicher entzogen werden kann. Auf diese Weise wird die Stabilität der Gast-VM gewährleistet und verhindert, dass der OOM-Killer Prozesse innerhalb der Gast-VM beendet. Durch geeignete Einstellungen, sorgfältige Überwachung und Anpassung der Speicherzuweisungen können Sie eine stabile und effiziente virtuelle Umgebung sicherstellen.

Sicherheitsbedenken

Auswirkungen der Aktivierung von KSM

Laut dem Dokument Kernel Samepage Merging (KSM) aus dem Proxmox VE-Wiki werden die Auswirkungen von KSM erwähnt. Es gibt bereits einige Dokumente von Forschern, die belegen, dass „Memory Deduplication as Threat to the Guest OS” , dass es möglich ist, „ Remote-Speicherdeduplizierungsangriffe” durchzuführen und Linux-VMs durch „Neuer FFS-Rowhammer-Angriff kapert Linux-VMs” zu kompromittieren.
In diesem Zusammenhang sollten Sie KSM nur aktivieren, wenn Sie die vollständige Kontrolle über alle VMs haben. Wenn Sie Proxmox VE für die Bereitstellung von Hosting-Diensten verwenden, sollten Sie zur Sicherheit Ihrer Nutzer die Deaktivierung von KSM in Betracht ziehen. Darüber hinaus sollten Sie die Vorschriften Ihres Landes überprüfen, da die Deaktivierung von KSM möglicherweise gesetzlich vorgeschrieben ist.

Risiken bei der Verwendung von Datenbanken mit Ballooning

Memory Ballooning passt die Speicherzuweisung von VMs dynamisch an den Bedarf an. Diese Funktion ist zwar vorteilhaft für die Optimierung der Speichernutzung, birgt jedoch gewisse Risiken, wenn sie mit Datenbanken wie PostgreSQL verwendet wird, deren Leistung stark vom verfügbaren Speicher abhängt. Wenn der Balloon-Treiber zu viel Speicher zurückgewinnt, kann es durch Überbelegung von Speicherseiten dazu kommen, dass OOM-Killer den Prozess mit der höchsten Punktzahl beendet, bis die Situation mit hoher Speicherauslastung vorbei ist. Und der Prozess mit den höchsten Metrikwerten könnte sich auf den Speicherverbrauch beziehen, was höchstwahrscheinlich die Datenbank selbst betrifft.

In diesem Fall sollten Sie den Datenbankserver in einer VM ohne aktiviertes Memory Ballooning ausführen oder keine Überbelegungsrichtlinie im Linux-Kernel innerhalb der Gast-VM festlegen, wenn Sie keine solche Kontrolle haben.

Schlussfolgerung

Unsere Tests zeigen, dass KSM und Memory Ballooning in Proxmox VE effektive Funktionen zur Optimierung der Speichernutzung in virtualisierten Umgebungen sind. KSM kann den Speicherverbrauch durch die Zusammenführung identischer Seiten über VMs hinweg erheblich reduzieren, während Memory Ballooning eine dynamische Anpassung der Speicherzuweisung je nach Bedarf ermöglicht.

Zusammen können diese Funktionen die Effizienz und Leistung virtualisierter Workloads verbessern und Proxmox VE zu einer robusten Lösung für die Virtualisierung in Unternehmen machen.

Durch die Nutzung von KSM und Memory Ballooning können Unternehmen eine bessere Ressourcenauslastung erzielen und möglicherweise Hardwarekosten senken. Wenn Sie die volle Kontrolle über den Host und alle VMs haben, sollten Sie diese Funktionen in Proxmox VE aktivieren, um diese potenziellen Vorteile zu nutzen.

Dieser Artikel wurde ursprünglich von Andrew Lee verfasst.

Was ist PegaProx?

Was bietet PegaProx?

Installation & Konfiguration von PegaProx

Fazit

Warum Proxmox® VE eine professionelle Virtualisierungslösung ist

Systemvoraussetzungen und Hardware-Vorbereitung prüfen

Minimale Hardware-Anforderungen

Empfohlene Konfiguration für einen minimalen Server

Proxmox®-VE-ISO herunterladen und Installationsmedium erstellen

Bootfähigen USB-Stick erstellen

Proxmox®-Installation durchführen und Grundkonfiguration

Installationsschritte durchführen

Erste Schritte nach der Installation optimieren

Repository-Konfiguration anpassen

Wie credativ® bei Proxmox®-Implementierungen unterstützt

Transparenzhinweis

Ähnliche Beiträge

Was ist Proxmox® Enterprise Support und wie unterscheidet er sich von der Community Edition?

Wann lohnt sich Proxmox® Enterprise Support für Unternehmen?

Was kostet Proxmox® Enterprise Support und welche Lizenzmodelle gibt es?

Welche Alternativen gibt es zu Proxmox® Enterprise Support?

Wie credativ® bei der Proxmox®-Entscheidung und dem Support hilft

Transparenzhinweis

Ähnliche Beiträge

Was ist der Unterschied zwischen ZFS, LVM und Ceph in Proxmox?

Welche Storage-Lösung bietet die beste Performance für verschiedene Workloads?

Wie entscheidet man zwischen lokaler und verteilter Storage-Architektur?

Was sind die wichtigsten Faktoren bei der Proxmox-Storage-Planung?

Wie credativ® bei der Proxmox-Storage-Optimierung unterstützt

Ähnliche Beiträge

Ähnliche Beiträge

Der Fahrplan für den Abend

Der erste Talk: Proxmox-Management im Deep-Dive

Der zweite Talk: High-Tech Connectivity trifft Open Source

Verpflegung & Anmeldung

ProxCLMC – Was ist das?

Wie funktioniert ProxCLMC?

Installation von ProxCLMC

Voraussetzungen und Abhängigkeiten

Installation über das Debian-Repository

Installation über ein Debian-Paket

Fazit

Effiziente Storage-Automatisierung in Proxmox mit dem proxmox_storage Modul

Ansible Modul: proxmox_storage

iSCSI Storage hinzufügen

Proxmox Backup Server hinzufügen

Entfernen von Storage

Fazit

Automatisierte Proxmox-Abonnementverwaltung mit Ansible

Ansible-Modul: proxmox_node

Beispiel für die Integration von Abonnements

Fazit

Effiziente Proxmox-Cluster-Bereitstellung durch Automatisierung mit Ansible

Vorteile

Ansible Proxmox Modul: proxmox_cluster

Erstellung eines Clusters

Beitritt zu einem Cluster

Cluster-Beitrittsinformationen

Fazit

ProxLB – Die neue Version des Loadbalancers für Proxmox Cluster steht in Version 1.1.0 bereit!

Lücke zu VMware schließen

Wartungsmodus

Affinitätsregeln im Griff

Download

Fazit

Einführung

Was ist KSM?

Was ist Memory Ballooning?

Testaufbau

Tests durchführen

Einrichtung von Gast-VMs für KSM-Tests:

Beobachtungen zu KSM Smart Scan

Testergebnisse

Kernel Samepage Merging (KSM) in Windows-VMs

Einrichtung der Gast-VMs für Ballooning-Tests:

Deaktivieren Sie KSM:

OOM-Killer!

Reduzieren Sie die maximale Speicherkonfiguration in VMs für Ballooning-Tests.

Überprüfen der Speichernutzung auf dem Host

Auswirkungen von Ballooning auf Gast-VMs