Umstellung von VMware auf Proxmox

Aufbau des ComConsult-Testlabors

Der zentrale Teil unseres Testlabors (CoCo-Testlab) besteht aus vier Servern der Marke Eigenbau, welche zu einem Cluster zusammengeschlossen sind. Dabei hat jeder Server 32 CPU-Kerne, 384 GB Arbeitsspeicher, 1x 250 GB NVMe SSD, 2x 960 GB SSDs und 4x 4 TB HDDs. Für das Netzwerk stehen neben den zwei 10-Gbit/s-Anschlüssen on Board noch weitere acht 1-GBit/s-Anschlüsse zur Verfügung.

Auf allen Server ist VMware ESXi installiert. Die Server sind zu einem VMware vCenter zusammengeschlossen. Als Storage wird VMware vSAN genutzt, wobei die 960 GB SSDs als Cache für die HDDs dienen. Die Storage-Kommunikation läuft über die 10-Gbit/s-Anschlüsse und einen dedizierten 10G-Switch und die restliche Netzwerkkommunikation erfolgt über die 1G-Anschlüsse. Den genauen Aufbau kann man im Artikel „Das CoCo-Testlab – Eine Spielwiese für unsere Berater“ nachlesen.

Die Planung

Wie bei jedem Projekt ist die Planung der Durchführung einer der wichtigsten Schritte im gesamten Vorhaben, schließlich kann das Ziel auf verschiedenen Wege erreicht werden. Der sicherste und auch kostenintensivste Weg wäre, neue Server anzuschaffen und einen parallelen Aufbau durchzuführen. In dem Fall hätten wir wenig bis gar keinen Ausfall der Umgebung und einen fließenden Übergang zum neuen Testlabor. Da unsere Server jedoch erst drei Jahre alt sind, entschieden wir uns gegen diese Möglichkeit. Es handelt sich schließlich immer noch um eine Spielwiese, und somit muss ein 24/7-Betrieb nicht gewährleistet werden. Wir wollten also eine Teil-Migration durchführen: einen oder zwei Server aus dem VMware-Cluster entfernen und somit auch das vSAN aufsplitten, alle virtuellen Maschinen (VM) auf die Cluster-losen Server verschieben und danach den Cluster komplett auflösen, um dann die Proxmox-Installation zu beginnen. Wie viele Server wir als Backup-Option nutzen, hängt von diversen Faktoren ab, zum Beispiel wie viele VMs überhaupt gesichert werden und wie viele davon eingeschaltet sein müssen. Die Ausfallsicherheit während des Migrationszeitraums spielt auch eine große Rolle. Nach einer kleinen Aufräumaktion hatten bei uns alle VMs auf einem Server Platz, auch wenn man dort nicht alle hätte starten dürfen. Dementsprechend hatten wir zwei Möglichkeiten:

Möglichkeit 1:

• 2 x ESXi-Server als Mini-Cluster
• 1 x ESXi-Witness auf einem Raspberry Pi oder Ähnlichem
• 2 x Proxmox-Server als Mini-Cluster
• 1 x Proxmox-Witness auf einem Raspberry Pi oder Ähnlichem

Möglichkeit 2:

• 1 x ESXi-Server
• 3 x Proxmox-Server als Cluster

Da genügend Speicherplatz auf einem Server zur Verfügung stand und in dem Durchführungszeitraum ein Großteil der VMs nicht benötigt wurde, haben wir uns für Möglichkeit 2 entschieden, wobei die wichtigsten VMs nochmal separat auf eine Festplatte exportiert wurden.

Für Storage gibt es verschiedene Varianten bei Proxmox. Wir hätten ZFS nutzen können und mittels Replica in vorgegebenen Abständen alles absichern können. Alternativ könnten wir ein Ceph erstellen, welches scheinbar ein Pendant zu vSAN von VMware ist. Zu diesem Zeitpunkt hatten wir noch das Verständnis, dass man die SSDs nicht als Cache für die HDDs (wie wir es zuvor beim VMware-Cluster hatten) nutzen kann. Dementsprechend wollten wir zwei Cephs aufbauen: eins für die SSDs und eins für die HDDs. Ein Ergebnis vorab: Im Nachhinein ist man immer schlauer, und im späteren Verlauf der Umsetzung mussten wir das Ceph im laufenden Betrieb umbauen.

Zusätzlich sollte die bisher genutzte dezentrale Benutzerverwaltung im Zuge der Migration durch eine zentrale Benutzerverwaltung abgelöst werden. Der Wunsch nach einem Single-Sign-On bestand bei den Nutzern schon länger, und da das CoCo-Testlab herunterfahren werden musste, konnten wir dies bei allen Servern und Diensten in einem Schwung umsetzen. Im Zuge dessen entschlossen wir uns außerdem, alle benötigten pfSensen (von der Umgebung selbst und den einzelnen Testnetzen der Nutzer) komplett neu aufzusetzen, anstatt die Konfigurationen auf den alten pfSensen mühselig anzupassen.

Im Bereich Netzwerk sollte sich mit der neuen Umgebung auch einiges verändern: Ein neues VLAN- und IP-Konzept wurde direkt mit umgesetzt. Dieses neue Konzept bietet die Möglichkeit, durch VLAN und IP-Adresse die Zuordnung zum jeweiligen Competence Center bzw. zu Gruppen, und die Möglichkeit, verschiedene Netze aus verschiedenen Gruppen miteinander verbinden zu können. Dies ist zum Beispiel der Fall, wenn eine Monitoring-VM aus der Gruppe Netze eine VM aus der Gruppe NAC überwachen soll. Bislang war dies nicht immer möglich, da manche Testnetze aufgrund von alten Konfigurationen überlappende private IP-Bereiche nutzten. Das Projekt selbst war schon länger geplant und sollte ursprünglich erst während unseres Umzuges im August umgesetzt werden. Es wurde primär aus einem Grund vorgezogen: Netzwerktechnisch gibt es einen parallelen Aufbau. Sollte im Laufe der Umsetzung eine VM nicht richtig funktionieren, konnten wir ohne IP-Konflikte beide VMs (die VM auf Proxmox und auf dem ESXi) starten und die Konfigurationen entsprechend vergleichen.

Die Planung war somit abgeschlossen, und der Termin der Umsetzung wurde auf den 23. Dezember 2024 festgelegt.

Die Vorbereitungen

Der erste Schritt bei der Umsetzung bestand darin, bei einem der vier ESXi-Server alle VMs auf einen der anderen Server zu verschieben. Dank vMotion geht dies bei einem VMware-Cluster mit vSAN als Storage sehr einfach und zügig. Bevor der leer geräumte Server aus dem Cluster entfernt werden konnte, war die Vorbereitung auf den worst-case-Fall erforderlich: Es wurden mit dem ovftool entsprechende Backups von den wichtigsten VMs erstellt. Bei den wichtigsten VMs handelte es sich vor allen Dingen um die Maschinen, welche bei Neuerstellung einen sehr hohen Konfigurationsaufwand erfordern würden, wie z.B. EveNG (Netzwerkvirtualisierungssoftware), Cisco ISE (Netzwerksicherheitslösung) oder den gesamten LoRaWAN-Aufbau (Long Range Wide Area Network). Es wurden außerdem die Konfigurationen aller pfSensen gesichert, um bei Bedarf im worst-case-Fall spezielle Konfigurationen überprüfen zu können. Als nächstes wurden dann die entsprechenden Festplatten aus dem vSAN entfernt und als neuer lokaler Speicher dem Server zugeordnet, um daraufhin alle VMs auf den Server zu migrieren. Nachdem dies erledigt und ein kurzer Test der VMs erfolgreich war, konnte der Server aus dem vCenter entfernt werden. Unser Backup stand also, und die anderen drei Server konnte ohne Rücksicht auf Verluste mit Proxmox neuinstalliert werden.

Nachdem auf allen drei Servern Proxmox installiert war, mussten diese zu einem Cluster zusammengeschlossen werden. Im Gegensatz zu einem ESXi-Cluster muss man einen Server als Master bestimmen. Auf diesem Master-Server erstellt man den Cluster bequem über die Weboberfläche unter „Datacenter à Cluster à Create Cluster“. Daraufhin wird die benötigte Join-Information angezeigt, welche man bei den restlichen Servern unter „Datacenter à Cluster à Join Cluster“ neben den Login-Daten vom Master-Server einfügen muss. Der nächste Schritt ist die Anpassung der Netzwerkkonfiguration aller Server (siehe Abbildung 1). Diese Konfiguration muss für das SDN (Software-Defined-Network) und das Ceph auf allen Server identisch sein.

Es wurden also vier Linux Bridges sowie zwei Linux Bond erstellt und die verschiedene Netzwerkkarten entsprechend zugeordnet. Das Ceph selbst sollte über die 10GE-onboard-Netzwerkkarten laufen, und die restliche Netzwerkkommunikation wurde auf die anderen Netzwerkkarten verteilt.

Als nächstes wurden die beiden Ceph aufgebaut: CoCo-VIP mit den SSDs und CoCo-Data mit den HDDs. Die Festplatten selbst wurden verschlüsselt. Wie genau Ceph funktioniert und welche Konfigurationsmöglichkeiten man hat, erläutern wir demnächst im Netzwerk-Insider. Dort wird es einen Artikel speziell zum Thema Ceph geben. Wichtig war für unseren Test, dass die erstellten Cephs im Datacenter als Storage mit dem entsprechend konfigurierten Typ hinzugefügt werden. In unserem Fall richteten wir diese als Typ RBD (RADOS Block Device) ein.

Als nächster Punkt stand die Konfiguration der Netzwerkanbindung der einzelnen VMs auf der Agenda. Grundsätzlich muss man für den eigentlichen Betrieb diesen Schritt nicht zwingend durchführen, da bei jeder einzelnen VM die entsprechende Netzwerkkarte und auch die VLAN-ID in der virtualisierten Netzwerkkarte angeben werden kann. Da wir alle Funktionen von Proxmox im Laufe des Tests ausprobieren wollten, setzten wir von Anfang an den Grundstein und realisierten die Netzwerkanbindung über SDN, wenn auch zunächst in abgespeckter Form. Wir erstellten also lediglich zwei VLAN-Zonen, wobei die Zone MGMT für das gesamte Management-Netz genutzt wird und die Zone Network die Netzwerkanbindung der User-VMs zur Verfügung stellt. Diese kann man im „Datacenter à SDN à Zones“ erstellen. Bei der Erstellung der Zonen muss auch die entsprechende Bridge angegeben und somit festgelegt werden, über welche physischen Netzwerkkarten die Verbindung außerhalb der Proxmox-Server aufgebaut werden soll. Die Konfiguration der VLANs wird im Abschnitt VNets durchgeführt (siehe Abbildung 2). Ein VNet wird einer Zone zugeordnet, und dementsprechend bekommt man auch verschiedene Einstell-Möglichkeiten. Da unsere Zonen jeweils vom Typ VLAN sind, kann man beim Erstellen nicht nur den Namen und einen Alias des VNets angeben, sondern auch die entsprechende VLAN-ID.

Sobald diese VNets erstellt wurden, können sie der VM als Netzwerkkarte zur Verfügung gestellt werden.

Benutzerverwaltung und Berechtigungsstruktur

Im Bereich Benutzerverwaltung hat Proxmox standardmäßig zwei sogenannte Realms vorkonfiguriert: Den Proxmox VE Authentication Server und die Linux PAM Standard Authentication. Es besteht aber auch die Möglichkeit, weitere Realms hinzuzufügen und somit einen Active-Directory- oder anderen LDAP-Server (Lightweight Directory Access Protocol Server) anzubinden. Wir erstellten eine VM mit Windows Server, richteten darauf ein entsprechendes Active Directory mit eigener Domäne ein und fügten diese im „Datacenter à Permissions à Realms“ als Realm hinzu. Neben den Anbindungsinformationen wie IP-Adresse und Domäne wird auch ein Binduser benötigt. Außerdem besteht die Möglichkeit, gewisse Filter zu setzen, damit nicht jede Gruppe und jeder User aus dem AD synchronisiert wird. In Abbildung 3 kann man diese möglichen Einstellungen sehen.

Welche Schwierigkeiten wir bei diesen Filtern hatten, kann man im Blog „Active Directory, pfSense und OpenVPN – Manchmal liegt der (Denk-)Fehler im Detail“ nachlesen.

Sobald das Realm erstellt wurde, kann man eine automatische Synchronisierung konfigurieren, alle 30 Minuten bis hin zu jährlich. Möglich ist auch ein manueller Start der Synchronisierung.

Als nächstes kam die eigentliche Rechteverwaltung dran, welche sich sehr von VMware unterscheidet (siehe Abbildung 4). Bei VMware kann man zum Beispiel eine Ordner-Struktur aufbauen und darüber jeweils einem Nutzer bzw. einer Gruppe entsprechende Rechte bzw. Rollen zuweisen. Das Pendant dazu sind in Proxmox die Pools. Man kann aber auch die Berechtigungen (Permissions) direkt auf einzelne VMs oder unterschiedliche Typen (z.B. Container, VMs, Storages, …) verteilen. Bei den Rollen selbst gibt es einige vorkonfigurierte Rollen, zusätzlich kann man eigene Rollen erstellen und die Berechtigungen im Detail zuweisen.

Im Vergleich zu VMware sind die möglichen Berechtigungen bei Proxmox übersichtlicher gestaltet, wobei man bei VMware mehr Einstellungen im Detail vornehmen kann.

Nachdem die entsprechenden Rollen nach unserem Berechtigungskonzept erstellt und den jeweiligen Pools zugewiesen waren, konnte die Migration der VMs beginnen.

Migration der VMs und HA

Als Nächstes mussten alle VMs auf den neuen Proxmox-Server migriert werden, doch wie kann man dies am besten durchführen? Proxmox bietet da eine sehr einfache Möglichkeit: Den ESXi-Server als Storage hinzufügen und von da aus die VMs importieren. Das Hinzufügen als Storage kann unter „Datacenter à Storage“ vorgenommen werden, wobei man natürlich neben der IP-Adresse des ESXi-Servers auch dessen Log-in-Daten benötigt. Bei Bedarf kann man die Zertifikatsverifizierung überspringen. Dies ist vor allen Dingen dann nötig, wenn der ESXi-Server lediglich ein selfsigned-Zertifikat verwendet. Sobald eine VM migriert war, wurde diese einem entsprechenden Pool für die Berechtigungen zugewiesen und ein kurzer Funktionstest durchgeführt. Falls eine VM nicht funktionierte, wurde diese erst einmal mit einem entsprechenden Tag „error“ versehen, um die Probleme nachträglich behandeln zu können.

Als dann alle VMs liefen, kamen wir zum letzten Schritt: die Konfiguration der High Availability (HA). Diese ist in unserer Umgebung wichtig, da wir einige VMs bereitstellen, die bei Ausfall eines Proxmox-Servers immer noch funktionieren müssen. Beispiele dafür sind unser Testlab-AD oder die diversen pfSensen. Die HA wird auch im Datacenter-Bereich konfiguriert. Man kann dort eine entsprechende Gruppe erstellen. Diese Gruppe beinhaltet die Server, welche für HA überwacht werden, und worauf migriert werden soll, sobald einer der Server nicht mehr erreichbar ist. Nachdem eine Gruppe erstellt wurde, kann für einzelne VMs die HA aktiviert werden. VMs in Request State „started“ lassen sich dann nicht mehr ausschalten, sie werden automatisch hochgefahren (siehe Abbildung 5).

Die HA-Konfiguration testeten wir, indem die Netzwerkkabel eines Servers entfernt wurden. Innerhalb von 5 Minuten waren die entsprechenden VMs wieder erreichbar. Nach diesem Test konnte das CoCo-Testlab den Nutzern am 27. Januar 2025 wieder zur Verfügung gestellt werden, um die letzten Funktionstests durchzuführen. Erst nachdem ein OK vom jeweiligen Nutzer kam, wurde die jeweilige Backup-VM auf dem ESXi gelöscht. Sobald keine VM mehr auf dem ESXi verblieben war, konnten wir auch diesen Server mit Proxmox neu installieren und in den Cluster integrieren. Danach wurden die VMs ohne Unterbrechungen auf alle Server verteilt, um eine gleichmäßige Ressourcenverteilung zu erzielen. Zumindest zum jetzigen Zeitpunkt haben wir noch nicht die Funktion gefunden, welche die VMs automatisch auf allen Servern verteilt (falls diese überhaupt existiert).

Probleme und Schwierigkeiten

Während der Umsetzung und im späteren Betrieb stießen wir auf diverse Probleme, die sich in die Bereiche VMs und Storage unterteilen lassen. Nach der Migration der VMs konnten manche nicht gebootet werden oder die Anzeige in der Proxmox-Konsole zeigte Fehler. Ersteres betraf primär unsere Windows-VMs und Letzteres diverse Linux-Maschinen mit einer grafischen Oberfläche. Bei den Windows-VMs lag das Problem darin, dass die Efi-Festplatte und das TPM (Trusted Platform Module) nach der Migration von Proxmox nicht als solches erkannt wurden. Nach Erstellung dieser Devices booteten die Windows-VMs wieder ganz normal. Das Troubleshooting bei den Linux-VMs war wegen der nichtssagenden Fehlermeldung etwas schwieriger (siehe Abbildung 6).

Man kann mittels einer Tastenkombination das Terminal aufrufen. Somit lag das Problem nicht an dem Boot-Vorgang wie bei den Windows-VMs, sondern bei dem Displaymanager. Im Endeffekt fanden wir heraus, dass die Proxmox-Konsole nicht mit Gnome kompatibel ist. Wir mussten also bei ca. 40 Linux-VMs den Displaymanager KDE Plasma installieren und Gnome deinstallieren.

Die Storage-Probleme tauchten erst auf, als wir die Testumgebung für alle Nutzer freigaben. Auf dem SSD-Ceph liefen lediglich die für den Betrieb der Umgebung wichtigen VMs, alle anderen waren dem HDD-Ceph zugeordnet. Das hatte zur Folge, dass bei den User-VMs nicht die erhoffte Storage-Geschwindigkeit ankam. Bei der EveNG-VM gab es zum Beispiel folgendes Ergebnis:

dd if=/dev/zero of=/tmp/test1.img bs=1G count=1 oflag=dsync
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 21.4141 s, 50.1 MB/s

dd if=/dev/zero of=/tmp/test2.img bs=512 count=1000 oflag=dsync
1000+0 records in
1000+0 records out
512000 bytes (512 kB, 500 KiB) copied, 134.155 s, 3.8 kB/s

Diese Schreibrate ist deutlich zu gering und dementsprechend musste sich etwas ändern, aber was? Zu Beginn des gesamten Vorhabens wussten wir noch nicht genau, wie ein Ceph funktioniert und welche Möglichkeiten man gerade bei unterschiedlichen Medien hat. Im Prinzip lag die Lösung darin, die WAL/DB auf SSDs laufen zu lassen und lediglich die Data auf den HDDs zu platzieren. Nach dieser Umstellung sahen die Schreibraten deutlich besser aus:

dd if=/dev/zero of=/tmp/test1.img bs=1G count=1 oflag=dsync
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 2.06633 s, 520 MB/s

dd if=/dev/zero of=/tmp/test2.img bs=512 count=1000 oflag=dsync
1000+0 records in
1000+0 records out
512000 bytes (512 kB, 500 KiB) copied, 3.66194 s, 140 kB/s

Wartungen / Updates tbd

Da Proxmox ein Linux-System ist, kann die Wartung in den meisten Fällen im laufenden Betrieb durchgeführt werden. Bei VMware musste man für Updates bislang immer ein Wartungsfenster bestimmen, da nacheinander jeder ESXi-Server in den Wartungsmodus versetzt werden musste, um die Updates zu installieren. Es war bislang immer nötig, den entsprechenden Server danach neu zu starten. Nach den Updates der einzelnen Server folgte dann immer ein Update der vCenter-VM und zum Schluss (falls nötig) ein Update des vSANs. Bei unserem neuen Proxmox-Server ist ein Wartungsfenster nicht mehr nötig, da die meisten Updates im laufenden Betrieb ohne Neustart des Servers durchgeführt werden können. Selbst ein Neustart der Server kann zügig mit minimalen Unterbrechungen durchgeführt werden. Diese Unterbrechungen sind jedoch so kurz, sodass die HA nicht getriggert wird und man somit auch nicht die VMs wieder auf ihren ursprünglichen Server verschieben muss.

Fazit

Es bleibt jetzt noch die Frage offen, ob Proxmox eine gleichwertige Alternative zu VMware ist. Ich kann diese Frage aus meiner Sicht bejahen, auch wenn es deutliche Unterschiede zwischen den beiden Produkten gibt. Beide Produkte haben ihre Vor- und Nachteile. Bei VMware fand ich die Berechtigungsstruktur und das vMotion besser. Dafür ist Proxmox meines Erachtens logischer aufgebaut und die Wartung einfacher gestaltet. Ersteres kann aber auch daran liegen, dass ich jetzt den gesamten Aufbau begleitet habe und nicht wie zuvor erst später hinzugekommen bin. Die Umstellung selbst war auf jeden Fall ein großes Projekt mit längeren Wartezeiten. Der Aufwand lag vor allem in wiederholten Umstellungen sowie in den Backups, die viel Zeit in Anspruch nahmen. Die Mühe hat sich meines Erachtens aber gelohnt, da wir wieder neue Technologien kostengünstig testen und auch bei Proxmox selbst noch mehr in die Tiefe gehen können. Und wer weiß, vielleicht nehmen wir jetzt auch endlich das Projekt „CoCo-Testlab Kaffee-kochen beibringen“ in Angriff.