Proxmox VE Archiv - Seite 2 von 2 - credativ®

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:

  1. 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.
  2. 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.

  3. Wie Sie sehen können, verbrauchen alle 8 VMs insgesamt 13.154,1 MB. Der obige Screenshot wurde auf unserem Proxmox VE-Host aufgenommen.

  4. Aktivieren Sie KSM Smart Scan mit dem folgenden Befehl auf dem Host:
    # echo "scan-time" > /sys/kernel/mm/ksm/advisor_mode
  5. 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

  1. Nach einer Weile, während KSM die Seiten scannt und zusammenführt, reduziert sich der verwendete Speicher auf 6.770,1 Mib.
  2. 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:

  1. Behalten Sie drei VMs und entfernen Sie die anderen.
  2. Aktivieren Sie Ballooning in jeder VM.
  3. 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.

  1. Passen Sie die maximale Speichereinstellung für jede VM auf 4 GB an.
  2. 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:

  1. 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.
  2. 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.

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. Durch sorgfältige Überwachung und Anpassung der Speicherzuweisungen können Sie eine stabile und effiziente virtuelle Umgebung gewährleisten.

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.

ONTAP-Snapshots für Proxmox VE

In modernen IT-Infrastrukturen ist Virtualisierung der Schlüssel zu effizientem Ressourcenmanagement. Durch Virtualisierung können Speicher-, CPU-, Netzwerk- und Speicherressourcen einfach virtuellen Maschinen (VM) zugewiesen und von diesen gemeinsam genutzt werden. Virtualisierung bietet auch den Vorteil, dass die virtuellen Maschinen zugewiesenen Ressourcen einfach geändert oder virtuelle Maschinen bei Bedarf geklont werden können. Da die Festplatte der virtuellen Maschine nur eine Datei ist, kann sie einfach in der Größe verändert, kopiert und gesichert werden.

Motivation

Einer der vielen Vorteile der Virtualisierung ist die Möglichkeit, auf einfache Weise Snapshots der Festplatten-Images virtueller Maschinen zu erstellen.

Proxmox VE bietet diese Möglichkeit für das qcow2-Festplatten-Imageformat, jedoch nicht für das raw-Format auf NFS-basiertem Speicher. Beim Erstellen eines VM-Festplatten-Snapshots mit Proxmox VE auf dem lokalen Dateisystem verwendet Proxmox VE die Funktionen des zugrunde liegenden Dateisystems, um Snapshots zu erstellen. In Fällen, in denen sich die VM-Festplatte auf einem NFS-Speicher befindet, ist es Proxmox VE nicht möglich, Dateisystemfunktionen zum Erstellen eines Snapshots zu verwenden, und muss daher auf dateibasierte Snapshots zurückgreifen.

Da NetApp ONTAP Snapshot-Funktionen auf Dateiebene und auf Volume-Ebene unter Verwendung eigener Dateisystemfunktionen bietet, könnte es von Vorteil sein, diese Funktionen gegenüber den dateibasierten Snapshots von Proxmox VE zu verwenden.

Der übliche Weg, Proxmox VE mit NetApp ONTAP zu verbinden, wäre NFS. NetApp ONTAP unterstützt auch iSCSI, dies ist jedoch nicht Gegenstand dieser Betrachtung, da ein mit iSCSI verbundener Speicher vollen Zugriff auf das Dateisystem bietet und Proxmox VE daher die Dateisystemfunktionen nutzen könnte.

ONTAP-Snapshots

Ein FileClone ist eine Kopie einer Datei, die auf dieselben Blöcke wie die Originaldatei verweist, wobei nur Änderungen in neue Blöcke geschrieben werden. Daher erfolgt das Erstellen eines FileClone sofort und das Schreiben in einen FileClone verursacht keinen Overhead, wie es ein dateibasierter Snapshot in Proxmox VE tut. Auch das Löschen oder besser das Zurückführen des Snapshots in das virtuelle Festplatten-Image ist nicht notwendig, da ein FileClone eine vollständige Kopie der ursprünglichen virtuellen Festplatte ist. Löschen Sie einfach die ursprüngliche virtuelle Festplatte und verwenden Sie weiterhin den FileClone oder wechseln Sie zurück zum ursprünglichen virtuellen Festplatten-Image und löschen Sie den Klon, wenn ein Rollback erforderlich ist.

Ein VolumeClone funktioniert auf die gleiche Weise wie der FileClone, jedoch auf Volume-Ebene. Ein VolumeClone erstellt eine sofortige Kopie eines kompletten Volumes, einen Snapshot. Der Snapshot referenziert die gleichen Blöcke wie das Original-Volume und Änderungen am Original-Volume werden in neue Blöcke geschrieben. Es ist auch möglich, auf den Snapshot zuzugreifen, indem ein neues Volume daraus erstellt wird, dies wird als FlexClone-Volume bezeichnet.

Dies kann verwendet werden, um einen Snapshot eines Proxmox VE-Speichers mit allen seinen virtuellen Festplatten-Images zu erstellen, anstatt Snapshots von einzelnen virtuellen Festplatten-Images zu erstellen. Mit der FlexClone-Volume-Funktionalität ist es einfach, auf die Daten im Klon zuzugreifen.

Da Proxmox VE die ONTAP-Funktionen nicht direkt unterstützt, gibt es ein kleines Python-Skript, das die ONTAP-Rest-API und die Proxmox VE-API verwendet, um diese Funktionen leicht zugänglich zu machen. Das Skript ist in der Lage, einen FileClone eines virtuellen Festplatten-Images zu erstellen, es kann den Klon von einer laufenden VM erstellen, ist aber auch in der Lage, eine VM vor dem Erstellen des Klons anzuhalten oder zu stoppen und die VM dann wieder zu starten.

Das Skript bietet auch einfachen Zugriff auf die VolumeClone- und FlexClone-Funktionen, es ist in der Lage, Klone eines Volumes zu erstellen, zu verwalten, zu mounten, zu unmounten und zu löschen. Beim Mounten eines Klons eines Volumes wird dieser auch automatisch als zusätzlicher Speicher an Proxmox VE angehängt.

NFS-Funktionen

Im Linux-Kernel 5.3 wurde die NFS-Mount-Option `nconnect` eingeführt. Standardmäßig verwendet ein NFS-Client eine TCP-Verbindung zum Server, was bei hoher NFS-Arbeitslast ein Engpass sein kann. Mit der Option nconnect kann die Anzahl der TCP-Verbindungen pro Server auf bis zu 16 Verbindungen erhöht werden.

nconnect wird von Proxmox VE seit Version 6.2 und von ONTAP 9 unterstützt und kann einfach verwendet werden, indem die nconnect=<value> zu den Mount-Optionen für die NFS-Freigabe auf der Client-Seite hinzugefügt wird.

Die andere interessante NFS-Mount-Option ist max_connect. max_connect legt die maximale Anzahl von Verbindungen zu verschiedenen Server-IPs fest, die zum selben NFSv4.1+-Server gehören. Dies wird als Trunking bezeichnet und ist eine Multipath-Funktionalität. Der Unterschied zu nconnect besteht darin, dass nconnect die Anzahl der TCP-Verbindungen zu einer Server-IP festlegt, während max_connect die Anzahl der TCP-Verbindungen zum selben Server über mehrere IPs festlegt. Dies wird von ONTAP seit Version 9.14.1 unterstützt.

Die Kombination der Optionen ist möglich, führt aber möglicherweise nicht zum gewünschten Ergebnis.

Mehr

Um die Ressourcennutzung weiter zu optimieren, ist die Datendeduplizierung auf Speichersystemen eine wichtige Funktion, da insbesondere virtuelle Festplatten-Images die gleichen (Betriebssystem-)Daten miteinander teilen. Die Deduplizierung reduziert den verwendeten Speicherplatz in diesem Anwendungsfall sehr effektiv. ONTAP unterstützt Deduplizierung.

Veeam & Proxmox VE

Veeam hat einen strategischen Schritt unternommen, indem es die Open-Source-Virtualisierungslösung Proxmox VE (Virtual Environment) in sein Portfolio integriert hat. Dies signalisiert sein Engagement für die sich entwickelnden Bedürfnisse der Open-Source-Community und des Open-Source-Virtualisierungsmarktes und positioniert Veeam als zukunftsorientierten Akteur in der Branche, der bereit ist, die wachsende Verbreitung von Open-Source-Lösungen zu unterstützen. Die Kombination von Veeams Datenschutzlösungen mit der Flexibilität der Proxmox VE-Plattform bietet Unternehmen eine überzeugende Alternative, die Kosteneinsparungen und verbesserte Datensicherheit verspricht.

Mit Proxmox VE wird nun auch eine der wichtigsten und oft angefragten Open-Source-Lösungen und Hypervisoren nativ unterstützt – und dies könnte definitiv eine Wende auf dem Virtualisierungsmarkt bedeuten!

Möglichkeiten für Open-Source-Virtualisierung

In vielen Unternehmen ist bereits eine wichtige Hypervisor-Plattform im Einsatz, begleitet von einer robusten Backup-Lösung – oft Veeam. Bislang fehlte Veeam jedoch die direkte Unterstützung für Proxmox VE, was eine Lücke für diejenigen hinterließ, die diese Open-Source-Virtualisierungsplattform nutzen oder in Betracht ziehen. Die neueste Version von Veeam ändert dies, indem sie die Möglichkeit bietet, Backups und Wiederherstellungen direkt in Proxmox VE-Umgebungen zu erstellen und zu verwalten, ohne dass Agenten innerhalb der VMs erforderlich sind.

Diese Weiterentwicklung bedeutet, dass nun ganze VMs über jeden Hypervisor hinweg gesichert und wiederhergestellt werden können, was eine beispiellose Flexibilität bietet. Darüber hinaus können Unternehmen einen neuen Proxmox VE-basierten Cluster nahtlos in ihre bestehende Veeam-Einrichtung integrieren und alles von einem einzigen, zentralen Punkt aus verwalten. Diese Integration vereinfacht Abläufe, reduziert die Komplexität und verbessert die Gesamteffizienz von Datenschutzstrategien in Umgebungen mit mehreren Hypervisoren, indem einfach eine All-in-One-Lösung vorhanden ist.

Ein ebenfalls stark unterschätzter Vorteil sind die Möglichkeiten, ganze VMs einfach zu migrieren, zu kopieren, zu sichern und wiederherzustellen, selbst unabhängig von ihrem zugrunde liegenden Hypervisor – auch bekannt als Cross-Platform-Recovery. Dadurch können Administratoren VMs nun von VMware ESXi-Knoten / vSphere oder Hyper-V auf Proxmox VE-Knoten verschieben. Dies bietet eine hervorragende Lösung, um eine neue Virtualisierungsplattform risikofrei einzuführen und zu bewerten. Für Unternehmen, die ihre Virtualisierungs- und Backup-Infrastruktur vereinheitlichen möchten, stellt dieses Update einen bedeutenden Fortschritt dar.

Integration in Veeam

Die Integration eines neuen Proxmox-Clusters in eine bestehende Veeam-Umgebung ist ein Beweis für die Einfachheit und das benutzerzentrierte Design beider Systeme. Wer mit Veeam vertraut ist, wird den Prozess als intuitiv und minimal störend empfinden, was eine nahtlose Erweiterung der Virtualisierungsumgebung ermöglicht. Diese einfache Integration bedeutet, dass Ihr neuer Proxmox VE-Cluster schnell unter den schützenden Schirm der robusten Backup- und Replikationsdienste von Veeam gebracht werden kann.

Trotz der allgemeinen Einfachheit des Prozesses ist es wichtig zu erkennen, dass einzigartige Konfigurationen und spezifische Umgebungen ihre eigenen Herausforderungen mit sich bringen können. Diese Sonderfälle sind zwar nicht häufig, aber erwähnenswert, da sie besondere Aufmerksamkeit erfordern können, um eine reibungslose Integration zu gewährleisten. Seien Sie jedoch versichert, dass dies lediglich Nuancen in einem ansonsten unkomplizierten Verfahren sind und selbst diese mit etwas zusätzlicher Sorgfalt effektiv verwaltet werden können.

Übersicht

Ab Version 12.2 wird die Proxmox VE-Unterstützung durch ein Plugin aktiviert und integriert, das auf dem Veeam Backup-Server installiert wird. Veeam Backup für Proxmox verfügt über eine verteilte Architektur, die den Einsatz von Worker-Nodes erfordert. Diese Nodes funktionieren analog zu Data Movern und erleichtern die Übertragung von Virtual-Machine-Payloads von den Proxmox VE-Hosts zum vorgesehenen Backup-Repository. Die Worker laufen auf einer Linux-Plattform und werden nahtlos über die Veeam Backup Server-Konsole instanziiert. Ihre Rolle ist entscheidend und ähnelt der von Proxy-Komponenten in analogen Systemen wie AHV- oder VMware-Backup-Lösungen.

Ein solcher Worker wird mindestens einmal in einem Cluster benötigt. Für eine verbesserte Leistung könnte ein Worker pro Proxmox VE-Node in Betracht gezogen werden. Jeder Worker benötigt 6 vCPU, 6 GB Arbeitsspeicher und 100 GB Festplattenspeicher, was berücksichtigt werden sollte.

Anforderungen

Dieser Blogbeitrag geht davon aus, dass eine bereits vorhandene Installation von Veeam Backup & Replication in Version 12.2 oder höher bereits vorhanden und für eine andere Umgebung wie VMware vollständig konfiguriert ist. Es wird auch davon ausgegangen, dass der Proxmox VE-Cluster bereits vorhanden ist und Anmeldeinformationen mit den erforderlichen Rollen zur Durchführung der Backup-/Wiederherstellungsaktionen vorliegen.

Konfiguration

Die Integration und Konfiguration eines Proxmox VE-Clusters kann vollständig innerhalb der Veeam Backup & Replication Console-Anwendung erfolgen und erfordert keine zusätzlichen Befehle auf einer CLI. Die zuvor erwähnten Worker-Nodes können vollautomatisch installiert werden.

Hinzufügen eines Proxmox-Servers

Um einen neuen Proxmox-Server in die Veeam Backup & Replication-Umgebung zu integrieren, muss man den Prozess durch Zugriff auf die Veeam-Konsole initiieren. Anschließend navigieren Sie durch die dafür vorgesehenen Abschnitte, um die Hinzufügung abzuschließen:

Virtuelle Infrastruktur -> Server hinzufügen

Dieses Verfahren entspricht dem etablierten Protokoll zur Einbindung von Nodes anderer Virtualisierungsplattformen, die mit Veeam kompatibel sind.

Anschließend zeigt Veeam Ihnen eine Auswahl möglicher und unterstützter Hypervisoren:

  • VM vSphere
  • Microsoft Hyper-V
  • Nutanix AHV
  • RedHat Virtualization
  • Oracle Virtualization Manager
  • Proxmox VE

In diesem Fall wählen wir einfach Proxmox VE und fahren mit dem Einrichtungsassistenten fort.

In den nächsten Schritten des Einrichtungsassistenten müssen die Authentifizierungsdetails, der Hostname oder die IP-Adresse des Ziel-Proxmox VE-Servers sowie ein Snapshot-Speicher des Proxmox VE-Servers definiert werden.

Hinweis: Bei den Authentifizierungsdetails achten Sie darauf, funktionierende Anmeldeinformationen für den SSH-Dienst auf dem Proxmox VE-Server zu verwenden. Wenn Sie normalerweise die root@pam-Anmeldeinformationen für die Weboberfläche verwenden, müssen Sie Veeam einfach die root-Anmeldeinformationen bereitstellen. Veeam initiiert eine Verbindung zum System über das SSH-Protokoll.

In einem der letzten Schritte des Einrichtungsassistenten bietet Veeam an, den erforderlichen Worker-Node automatisch zu installieren. Ein solcher Worker-Node ist eine kleine VM, die innerhalb des Clusters auf dem Ziel-Proxmox VE-Server läuft. Im Allgemeinen ist ein einzelner Worker-Node für einen Cluster ausreichend, aber zur Verbesserung der Gesamtleistung wird ein Worker pro Node empfohlen.

Nutzung

Sobald der Proxmox VE-Server erfolgreich in das Veeam-Inventar integriert wurde, kann er so mühelos verwaltet werden wie jeder andere unterstützte Hypervisor, wie VMware vSphere oder Microsoft Hyper-V. Ein wesentlicher Vorteil, wie im Screenshot gezeigt, ist die Möglichkeit, verschiedene Hypervisoren und Server in Clustern zentral zu administrieren. Dies eliminiert die Notwendigkeit einer separaten Veeam-Instanz für jeden Cluster und optimiert die Abläufe. Dennoch kann es spezifische Szenarien geben, in denen individuelle Setups für jeden Cluster vorzuziehen sind.

Dadurch wird nicht nur die Arbeit des Administrators bei der Arbeit mit verschiedenen Servern und Clustern vereinfacht, sondern bietet endlich auch die Möglichkeit für Cross-Hypervisor-Wiederherstellungen.

Backup-Jobs erstellen

Das Erstellen eines neuen Backup-Jobs für eine einzelne VM oder sogar mehrere VMs in einer Proxmox-Umgebung ist so einfach und genau dasselbe, wie Sie es bereits von anderen Hypervisoren kennen. Werfen wir jedoch einen kurzen Blick auf die erforderlichen Aufgaben:

Öffnen Sie die Veeam Backup & Replication-Konsole auf Ihrem Backup-Server oder Ihrer Management-Workstation. Um einen Backup-Job zu erstellen, navigieren Sie zum Tab Home und klicken Sie auf Backup Job, wählen Sie dann Virtual machine aus dem Dropdown-Menü.

Wenn der Assistent New Backup Job geöffnet wird, müssen Sie einen Namen und eine Beschreibung für den Backup-Job eingeben. Klicken Sie auf Next, um mit dem nächsten Schritt fortzufahren. Nun müssen Sie die VMs auswählen, die Sie sichern möchten. Klicken Sie im Schritt Virtual Machines auf Add und wählen Sie die einzelnen VMs oder Container wie Ordner, Cluster oder ganze Hosts aus, die Sie in das Backup aufnehmen möchten. Sobald Sie Ihre Auswahl getroffen haben, klicken Sie auf Next.

Der nächste Schritt besteht darin, anzugeben, wo Sie die Backup-Dateien speichern möchten. Wählen Sie im Schritt Storage das Backup-Repository aus und legen Sie die Aufbewahrungsrichtlinie fest, die bestimmt, wie lange Sie die Backup-Daten aufbewahren möchten. Nachdem Sie dies eingerichtet haben, klicken Sie auf Next.

Wenn Sie mehrere Backup-Proxys konfiguriert haben, können Sie im nächsten Schritt festlegen, welchen Sie verwenden möchten. Wenn Sie sich nicht sicher sind oder es bevorzugen, können Sie Veeam Backup & Replication den besten Proxy für den Job automatisch auswählen lassen. Klicken Sie nach Ihrer Auswahl auf Next.

Nun ist es an der Zeit, den Zeitplan für die Ausführung des Backup-Jobs festzulegen. Im Schritt Schedule können Sie den Job so einrichten, dass er automatisch zu bestimmten Zeiten oder als Reaktion auf bestimmte Ereignisse ausgeführt wird. Nachdem Sie den Zeitplan konfiguriert haben, klicken Sie auf Next.

Überprüfen Sie alle Einstellungen auf der Übersichtsseite, um sicherzustellen, dass sie korrekt sind. Wenn alles in Ordnung ist, klicken Sie auf Finish, um den Backup-Job zu erstellen.

 

Wenn Sie den Backup-Job sofort ausführen möchten, um sicherzustellen, dass alles wie erwartet funktioniert, können Sie dies tun, indem Sie mit der rechten Maustaste auf den Job klicken und Start auswählen. Alternativ können Sie warten, bis die geplante Zeit den Job automatisch auslöst.

Wiederherstellen einer gesamten VM

Der Wiederherstellungs- und Replikationsprozess für eine vollständige VM-Wiederherstellung entspricht den Standardverfahren. Er umfasst jedoch nun die wichtige Funktion der Cross-Hypervisor-Wiederherstellung. Diese Funktionalität ermöglicht die Migration von VMs zwischen verschiedenen Hypervisor-Typen ohne Kompatibilitätsprobleme. Wenn beispielsweise Proxmox VE in einem Unternehmensumfeld eingeführt wird, können Administratoren VMs mühelos von einem bestehenden Hypervisor auf den Proxmox VE-Cluster migrieren. Sollten während der Testphase Probleme auftreten, unterstützt der Prozess auch die Rückmigration zum ursprünglichen Hypervisor. Werfen wir einen Blick auf die Details.

Öffnen Sie die Veeam Backup & Replication-Konsole auf Ihrem Backup-Server oder Ihrer Management-Workstation. Um einen Backup-Job zu erstellen, navigieren Sie zum Tab Home und klicken Sie auf Backup Job, wählen Sie dann Virtual machine aus dem Disk-Menü.

Wählen Sie die Option Entire VM restore, die den Assistenten zur Wiederherstellung einer vollständigen virtuellen Maschine startet. Im ersten Schritt des Assistenten werden Sie aufgefordert, ein Backup auszuwählen, aus dem Sie wiederherstellen möchten. Sie sehen eine Liste der verfügbaren Backups; wählen Sie dasjenige aus, das die VM enthält, die Sie wiederherstellen möchten, und fahren Sie mit dem nächsten Schritt fort, indem Sie auf Next klicken.

Nun müssen Sie den Wiederherstellungspunkt festlegen. Typischerweise ist dies das aktuellste Backup, aber Sie können bei Bedarf auch einen früheren Punkt wählen. Nachdem Sie den Wiederherstellungspunkt ausgewählt haben, fahren Sie mit dem nächsten Schritt fort.

Der Assistent fordert Sie dann auf, das Ziel für die VM anzugeben. Dies ist der sehr praktische Punkt für die Cross-Hypervisor-Wiederherstellung, wo dies der ursprüngliche Speicherort oder ein neuer Speicherort sein kann, wenn Sie eine Migration durchführen oder die vorhandene VM nicht überschreiben möchten. Konfigurieren Sie die Netzwerkeinstellungen nach Bedarf, um sicherzustellen, dass die wiederhergestellte VM den entsprechenden Netzwerkzugriff hat.

Im nächsten Schritt haben Sie Optionen bezüglich des Power-Zustands der VM nach der Wiederherstellung. Sie können wählen, ob die VM automatisch eingeschaltet oder ausgeschaltet bleiben soll, je nach Ihren Bedürfnissen.

Bevor Sie den Wiederherstellungsprozess abschließen, überprüfen Sie alle Einstellungen, um sicherzustellen, dass sie Ihrem gewünschten Ergebnis entsprechen. Dies ist Ihre Chance, zurückzugehen und notwendige Anpassungen vorzunehmen. Sobald Sie mit der Konfiguration zufrieden sind, fahren Sie mit der Wiederherstellung der VM fort, indem Sie auf Finish klicken.

Der Wiederherstellungsprozess beginnt, und sein Fortschritt kann in der Veeam Backup & Replication-Konsole überwacht werden. Je nach Größe der VM und der Leistung Ihres Backup-Speichers und Netzwerks kann die Wiederherstellung einige Zeit in Anspruch nehmen.

Dateiwiederherstellung

Öffnen Sie die Veeam Backup & Replication-Konsole auf Ihrem Backup-Server oder Ihrer Management-Workstation. Um einen Backup-Job zu erstellen, navigieren Sie zum Tab Home und klicken Sie auf Backup Job, wählen Sie dann Virtual machine aus dem Disk-Menü.

Wählen Sie Restore guest files. Der Assistent für die dateibasierte Wiederherstellung wird gestartet und führt Sie durch die notwendigen Schritte. Der erste Schritt besteht darin, das VM-Backup auszuwählen, aus dem Sie Dateien wiederherstellen möchten. Durchsuchen Sie die Liste der verfügbaren Backups, wählen Sie das passende aus und klicken Sie dann auf Next, um fortzufahren.

Wählen Sie den Wiederherstellungspunkt aus, den Sie für die dateibasierte Wiederherstellung verwenden möchten. Dies ist typischerweise das aktuellste Backup, aber Sie können bei Bedarf auch ein früheres auswählen. Nachdem Sie den Wiederherstellungspunkt ausgewählt haben, klicken Sie auf Next, um fortzufahren.

In diesem Schritt müssen Sie möglicherweise das Betriebssystem der VM auswählen, aus der Sie Dateien wiederherstellen. Dies ist besonders wichtig, wenn das Backup von einem anderen Betriebssystem stammt als dem auf dem Veeam Backup & Replication-Server, da dies den Typ der für die Wiederherstellung erforderlichen Helper Appliance bestimmt.

Veeam Backup & Replication fordert Sie auf, eine Helper Appliance bereitzustellen, wenn das Backup von einem Betriebssystem stammt, das vom Windows-basierten Veeam Backup & Replication-Server nicht nativ unterstützt wird. Befolgen Sie die Anweisungen auf dem Bildschirm, um die Helper Appliance bereitzustellen, die den dateibasierten Wiederherstellungsprozess erleichtern wird.

Sobald die Helper Appliance bereit ist, können Sie das Dateisystem des Backups durchsuchen. Navigieren Sie durch das Backup, um die Dateien oder Ordner zu finden, die Sie wiederherstellen möchten.

Nachdem Sie die Dateien oder Ordner zur Wiederherstellung ausgewählt haben, werden Sie aufgefordert, das Ziel auszuwählen, an das Sie die Daten wiederherstellen möchten. Sie können am ursprünglichen Speicherort wiederherstellen oder einen neuen Speicherort angeben, je nach Ihren Anforderungen.

Überprüfen Sie Ihre Auswahl, um zu bestätigen, dass die richtigen Dateien wiederhergestellt werden und am richtigen Ziel ankommen. Wenn alles in Ordnung ist, fahren Sie mit der Wiederherstellung fort, indem Sie auf Finish klicken.

Der dateibasierte Wiederherstellungsprozess beginnt, und Sie können den Fortschritt in der Veeam Backup & Replication-Konsole überwachen. Die Zeit, die für die Wiederherstellung benötigt wird, hängt von der Größe und Anzahl der wiederherzustellenden Dateien sowie von der Leistung Ihres Backup-Speichers und Netzwerks ab.

Fazit

Zusammenfassend lässt sich sagen, dass das neueste Update für Veeam eine sehr wichtige und willkommene Integration mit Proxmox VE einführt, die eine erhebliche Lücke für Unternehmen schließt, die diese Open-Source-Virtualisierungsplattform übernommen haben. Durch die Ermöglichung direkter Backups und Wiederherstellungen ganzer VMs über verschiedene Hypervisoren hinweg, ohne dass In-VM-Agenten erforderlich sind, bietet Veeam nun eine beispiellose Flexibilität und Einfachheit bei der Verwaltung gemischter Umgebungen. Diese Weiterentwicklung optimiert nicht nur Abläufe und verbessert Datenschutzstrategien, sondern ermöglicht es Unternehmen auch, neue Open-Source-Virtualisierungsplattformen wie Proxmox VE mit minimalem Risiko einfach zu migrieren und zu bewerten. Es ist großartig zu sehen, dass immer mehr Unternehmen Anstrengungen unternehmen, Open-Source-Lösungen zu unterstützen, was die anhaltende Bedeutung von Open-Source-basierten Produkten in Unternehmen unterstreicht.

Zusätzlich bleibt für diejenigen, die neu mit Proxmox beginnen, der Proxmox Backup Server eine praktikable Open-Source-Alternative, und Sie finden unseren Blogbeitrag zur Konfiguration des Proxmox Backup Servers direkt hier. Insgesamt stellt dieses Update einen bedeutenden Schritt zur Vereinheitlichung von Virtualisierungs- und Backup-Infrastrukturen dar, der sowohl Vielseitigkeit als auch einfache Integration bietet.

Wir stehen Ihnen jederzeit für weitere Beratungs-, Planungs- und Integrationsbedürfnisse zur Verfügung. Egal, ob Sie neue Virtualisierungsplattformen erkunden, Ihre aktuelle Infrastruktur optimieren oder fachkundige Beratung zu Ihren Backup-Strategien suchen, unser Team ist bestrebt, Ihren Erfolg auf jedem Schritt des Weges zu gewährleisten. Zögern Sie nicht, uns für personalisierten Support und maßgeschneiderte Lösungen zu kontaktieren, um Ihre einzigartigen Anforderungen in Virtualisierungs- oder Backup-Umgebungen zu erfüllen.