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 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

Affinitätsregeln im Griff

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.

Fazit

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.
3. 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

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.

Wie und wann man Software-Defined Networks in Proxmox VE einsetzt

Was ist Software-Defined Networking?

Wie man ein SDN konfiguriert

Nachdem wir nun die Grundlagen und Möglichkeiten von Software-Defined Networking (SDN) kennen, wird es interessant, ein solches Netzwerk innerhalb eines Proxmox-Clusters einzurichten.

Proxmox bietet Unterstützung für Software-Defined Networking (SDN), sodass Benutzer verschiedene Arten von Netzwerkkonfigurationen integrieren können, um ihren spezifischen Netzwerkanforderungen gerecht zu werden. Mit Proxmox haben Sie die Flexibilität, aus verschiedenen SDN-Typen auszuwählen, darunter „Simple“, das wahrscheinlich auf unkomplizierte Netzwerkeinrichtungen ohne Bedarf an erweiterten Funktionen abzielt. Für Umgebungen, die eine Netzwerksegmentierung erfordern, ist VLAN-Unterstützung verfügbar, die die Möglichkeit bietet, den Datenverkehr innerhalb verschiedener virtueller LANs zu isolieren und zu verwalten. Komplexere Szenarien profitieren möglicherweise von der QinQ-Unterstützung, die mehrere VLAN-Tags auf einer einzigen Schnittstelle ermöglicht. Auch und sehr interessant für Rechenzentren: Proxmox bietet auch VxLAN-Unterstützung, die Layer-2-Netzwerke über eine Layer-3-Infrastruktur erweitert, was die Anzahl der möglichen VLANs erheblich erhöht, die sonst auf 4096 VLANs begrenzt wären. Zuletzt zu erwähnen ist die EVPN-Unterstützung, die ebenfalls Teil des SDN-Angebots von Proxmox ist, die erweiterte Layer-2- und Layer-3-Virtualisierung ermöglicht und eine skalierbare Steuerungsebene mit BGP (Border Gateway Protocol) für Multi-Tenancy-Umgebungen bietet.

In diesem Leitfaden führen wir Sie durch den Prozess der Einrichtung eines optimierten Software-Defined Network (SDN) innerhalb einer Proxmox-Clusterumgebung. Das Hauptziel ist die Einrichtung eines neuen Netzwerks, einschließlich seiner eigenen Netzwerkkonfiguration, die automatisch auf alle Knoten innerhalb des Clusters übertragen wird. Dieses neu erstellte Netzwerk wird durch seinen eigenen IP-Bereich erstellt, in dem virtuelle Maschinen (VMs) ihre IP-Adressen dynamisch über DHCP erhalten. Diese Einrichtung macht eine manuelle IP-Weiterleitung oder Network Address Translation (NAT) auf den Host-Maschinen überflüssig. Ein weiterer Vorteil dieser Konfiguration ist die Konsistenz, die sie bietet; das Gateway für die VMs bleibt immer konstant, unabhängig von dem spezifischen Host-Knoten, auf dem sie betrieben werden.

Konfiguration

Die Konfiguration von Software-Defined Networking (SDN) ist in den neuesten Proxmox VE-Versionen sehr einfach geworden, da der gesamte Prozess in der Proxmox-Weboberfläche durchgeführt werden kann. Daher verbinden wir uns einfach mit der Proxmox-Management-Weboberfläche, die typischerweise erreichbar ist unter:

• https://HOSTNAME:8006

Die SDN-Optionen sind im Datacenter-Kapitel im Unterkapitel SDN integriert. Alle weiteren Arbeiten werden nur innerhalb dieses Kapitels durchgeführt. Daher navigieren wir zu:
–> Datacenter
—-> SDN
——–> Zonen

Das Menü auf der rechten Seite bietet die Möglichkeit, eine neue Zone hinzuzufügen, wobei die neue Zone vom Typ Simple ausgewählt wird. Es öffnet sich ein neues Fenster, in dem wir direkt die erweiterten Optionen unten aktivieren. Anschließend werden weitere erforderliche Details angegeben.

ID: devnet01
MTU: Auto
Nodes: All
IPAM: pve
Automatic DHCP: Activate

Die ID stellt die eindeutige Kennung dieser Zone dar. Es kann sinnvoll sein, ihr einen wiedererkennbaren Namen zu geben. Normalerweise müssen wir die MTU-Größe für diese Art von Standard-Setups nicht anpassen. Es kann jedoch immer einige Sonderfälle geben. In den Node-Abschnitten kann diese Zone bestimmten Nodes oder einfach allen zugewiesen werden. Es kann auch Szenarien geben, in denen Zonen nur auf bestimmte Nodes beschränkt sind. Entsprechend unseren erweiterten Optionen können weitere Details wie DNS-Server und auch die Forward- & Reverse-Zonen definiert werden. Für dieses grundlegende Setup wird dies nicht verwendet, aber die automatische DHCP-Option muss aktiviert werden.

Nun werden die nächsten Schritte im Kapitel VNets durchgeführt, wo die zuvor erstellte Zone mit einem virtuellen Netzwerk verknüpft wird. Im selben Schritt werden wir auch zusätzliche Netzwerkinformationen wie den Netzwerkbereich usw. angeben.

Beim Erstellen eines neuen VNet muss eine Kennung oder ein Name angegeben werden. Es ist oft sinnvoll, den Namen des virtuellen Netzwerks an den zuvor generierten Zonennamen anzupassen. In diesem Beispiel werden die gleichen Namen verwendet. Optional kann ein Alias definiert werden. Wichtig ist die Auswahl der gewünschten Zone, die verwendet werden soll (z. B. devnet01). Nach dem Erstellen des neuen VNet haben wir die Möglichkeit, im selben Fenster ein neues Subnetz zu erstellen, indem wir auf die Schaltfläche Create Subnet klicken.

Innerhalb dieses Dialogs werden einige grundlegende Netzwerkinformationen eingegeben. Im Allgemeinen müssen wir das gewünschte Subnetz in CIDR-Notation angeben (z. B. 10.11.12.0/24). Die Definition der IP-Adresse für das Gateway ist ebenfalls möglich. In diesem Beispiel wird das Gateway auf der IP-Adresse 10.11.12.1 platziert. Wichtig ist die Aktivierung der Option SNAT. SNAT (Source Network Address Translation) ist eine Technik, um die Quell-IP-Adresse des ausgehenden Netzwerkverkehrs so zu ändern, dass es so aussieht, als ob er von einer anderen IP-Adresse stammt, die normalerweise die IP-Adresse des Routers oder der Firewall ist. Diese Methode wird häufig verwendet, um mehreren Geräten in einem privaten Netzwerk den Zugriff auf externe Netzwerke zu ermöglichen.

Nach dem Erstellen und Verknüpfen der Zone, des VNet und des Subnetzes kann die Konfiguration einfach auf der Weboberfläche angewendet werden, indem auf die Schaltfläche „Apply“ geklickt wird. Die Konfiguration wird nun mit den gewünschten Nodes synchronisiert (in unserem Beispiel alle).

Nutzung

Nach dem Anwenden der Konfiguration auf die Nodes innerhalb des Clusters müssen virtuelle Maschinen noch diesem Netzwerk zugewiesen werden. Glücklicherweise kann dies einfach über die reguläre Proxmox-Weboberfläche erfolgen, die nun auch das neu erstellte Netzwerk devnet01 im Networking-Kapitel der VM bereitstellt. Aber auch bereits vorhandene virtuelle Maschinen können diesem Netzwerk zugewiesen werden.

Wenn es um DevOps und Automatisierung geht, ist dies auch in der API verfügbar, wo virtuelle Maschinen dem neuen Netzwerk zugewiesen werden können. Eine solche Aufgabe könnte im folgenden Beispiel in Ansible wie folgt aussehen:

- name: Create Container in Custom Network
community.general.proxmox:
vmid: 100
node: de01-dus01-node03
api_user: root@pam
api_password: {{ api_password }}
api_host: de01-dus01-node01
password: {{ container_password }}
hostname: {{ container_fqdn }}
ostemplate: 'local:vztmpl/debian-12-x86_64.tar.gz'
netif: '{"net0":"name=eth0,ip=dhcp,ip6=dhcp,bridge=devnet01"}'


Virtuelle Maschinen, die diesem Netzwerk zugewiesen sind, erhalten sofort IP-Adressen innerhalb unseres zuvor definierten Netzwerks 10.11.12.0/24 und können ohne weitere Bedürfnisse auf das Internet zugreifen. VMs können auch über Nodes im Cluster verschoben werden, ohne dass das Gateway angepasst werden muss, selbst wenn ein Node heruntergefahren oder für Wartungsarbeiten neu gestartet wird.

Fazit

Zusammenfassend lässt sich sagen, dass die Integration von Software-Defined Networking (SDN) in Proxmox VE einen großen Vorteil aus technischer Sicht, aber auch aus Benutzersicht darstellt, da diese Funktion auch über die Proxmox-Weboberfläche nutzbar ist. Diese einfache Konfiguration ermöglicht es auch Personen mit begrenzter Netzwerkerfahrung, noch komplexere Netzwerkeinrichtungen einzurichten und zu verwalten.

Proxmox erleichtert es auch mit einfachen SDNs, grundlegende Netzwerke zu erstellen, die virtuelle Maschinen mit dem Internet verbinden. Sie müssen sich nicht mit komplizierten Einstellungen oder Gateways auf den Hauptknoten befassen. Dies beschleunigt die Inbetriebnahme virtueller Setups und verringert die Wahrscheinlichkeit von Fehlern, die zu Sicherheitsproblemen führen könnten.

Für Leute, die gerade erst anfangen, hat Proxmox eine benutzerfreundliche Website, die es einfach macht, Netzwerke einzurichten und zu steuern. Das ist wirklich hilfreich, weil es bedeutet, dass sie nicht viel kompliziertes Zeug lernen müssen, um loszulegen. Stattdessen können sie mehr Zeit damit verbringen, mit ihren virtuellen Computern zu arbeiten, und sich nicht zu viele Sorgen darüber machen, wie sie alles verbinden.

Leute, die mehr über Technologie wissen, werden es mögen, wie Proxmox ihnen erlaubt, komplexe Netzwerke einzurichten. Das ist gut für große Setups, weil es das Netzwerk besser laufen lassen, mehr Verkehr bewältigen und verschiedene Teile des Netzwerks voneinander trennen kann.

Genau wie andere nützliche Integrationen (z. B. Ceph) bietet auch die SDN-Integration große Vorteile für seine Benutzerbasis und zeigt die laufende Integration nützlicher Tools in Proxmox.