Proxmox von Hardware über Installation bis zum sicheren Betrieb

Proxmox, was ist das eigentlich?
Proxmox ist ein österreichischer Softwarehersteller der Open-Source-Plattformen für Virtualisierung, Backup und ein Mail Gateway entwickelt. Die Software ist quelloffen und lässt sich ohne Funktionseinschränkungen komplett kostenfrei nutzen. Proxmox bietet Support und Service für seine Produkte an, man zahlt also nicht für die Lizenzen, sondern für den Support. Dies ist in produktiven Umgebungen sehr wichtig, aber die Software lässt sich im vollen Funktionsumfang vorab testen bzw. uneingeschränkt betreiben.

Wir beschäftigen uns auf dieser Seite speziell mit Proxmox VE (der Virtualisierung) und dem Backup-Server.

Inhaltsverzeichnis Proxmox Tipps & Tricks

Ziel-Gruppe für Proxmox

Proxmox VE lässt sich sehr flexibel einsetzen und kann an die benötigte Umgebung angepasst werden. Also ein Produkt für viele Umgebungen. Als Beispiel können drei sehr unterschiedliche Gruppen betrachtet werden:

1. Ein kleines Unternehmen, was nur ein zwei oder drei Anwendungen virtualisieren möchte, wenig Budget zur Verfügung hat, aber trotzdem viel Leistung und Verfügbarkeit benötigt:

a) Single Server mit Proxmox und ZFS (Hardware dann mit 7x24x4 Support)
b) Replikationen auf einen zweiten Server mit ZFS / Proxmox Backup Server
c) Unkompliziert, geringe Kosten, hohe Leistung
d) jederzeit erweiterbar auf Cluster oder Ceph


2. Der Mittelstand mit mindestens drei Proxmox VE Server, aber keinen externen Shared Storage, sondern Ceph:

a) Drei identische Server mit redundantem Netzwerk und internen SSDs als Speicherplatz
b) Live Migration, High Availability und Datensicherung auf Proxmox Backup Server
c) extrem flexibel, hoch verfügbar, auch der zweite Standort / Brandabschnitt ist kein Problem


3. Größeres Unternehmen mit vielen VMs, hoher Performance und mehreren Standorten oder Filialen:

a) die passende Anzahl von Proxmox VE Server
b) einen eigenen Ceph Cluster mit 3 oder mehr Nodes oder ein externes Shared Storage über iSCSI oder Fibre Channel
c) Proxmox VE Server mit FZS und Replikation in kleinen Filialen
d) Proxmox VE Cluster mit internem Ceph in größeren Filialen mit Replikation in den Hauptstandort
e) Datensicherung auf den Proxmox Backup-Server mit Replikation auf zweiten Standort und/oder Sicherung auf Tape.
f) mehr Virtualisierungs-Nodes - kein Problem
g) mehr Speicherplatz - kein Problem - weitere HDD/SSD im Ceph Node
h) mehr Performance im Speichernetz - kein Problem - weitere Ceph Nodes dazu fügen

Proxmox VE und die passende Hardware

Was ist bei der Hardware-Auswahl zu beachten? Proxmox basiert auf der aktuellen Linux Debian Version, dafür sollte also die Hardware kompatibel sein.

Wichtig wenn ZFS eingesetzt werden soll:
1. ZFS ist KEIN Shared Storage im Cluster!
2. ZFS benötigt physikalische Festplatten oder SSDs, keinen RAID Controller bzw. keine LUN eines RAID Controllers.
3. ZFS benötigt RAM, dies sollte eingeplant werden.
4. Für hohe Performance sollten SSDs verbaut werden.
5. Für einen Cluster werden mindestens 3 Server benötigt.
6. Im Unternehmen im kritischen Bereich sollten die Server identisch sein.

Wichtig wenn Ceph eingesetzt werden soll:
1. Ceph ist ein Shared Storage.
2. Ceph benötigt mindestens 3 Nodes (es können die Proxmox VE Nodes sein).
3. Ceph benötigt physikalische Festplatten oder SSDs, wie ZFS auch keine LUN eines RAID Controllers.
4. Ceph benötigt RAM und auch CPU Leistung.
5. Ceph benötigt mindestens 10 Gbit/s Ethernet als Netzwerk.
6. Für hohen Durchsatz und beste Performance sollten zwei Netzwerke vorhanden sein.
7. Redundanz ist auch hier besonders wichtig (Netzwerk).
8. Meist werden die Daten auf 3 Nodes "gespiegelt", es muss also genügend Plattenplatz vorhanden sein (3 fach).
9. Ceph kann auf einem eigenen Cluster betrieben werden, also unabhängig von Proxmox.

Proxmox und die Installation

Installation Einzelserver:
1. Auf Redundanz bzw. die passende Sicherung achten.
2. ZFS ist in diesem Fall das Storage der Wahl, es bietet die meisten Möglichkeiten.
3. Wichtig: Fällt dieser Server aus, so fallen alle VMs und Container auch aus!
4. Backup-Server einrichten und die Backups testen (ZFS bietet viele Möglichkeiten)

Proxmox VE - Storage im Single Server

Installation Cluster:
1. Redundanz beachten, mindestens 3 Server (zur Not 2 und ein Quorum)
2. Redundanz im Netzwerk herstellen, Cluster redundant verbinden.
3. Auch für Ceph wird eine redundantes Netzwerk benötigt.
4, Uhrzeit im Cluster MUSS gleich sein, NTP verwenden!
5. ZFS im Cluster ist kein Shared Storage!
6. Ohne Shared Storage ist kein "richtiges" HA möglich.
7. Shared Storage mit FC oder iSCSI hat Nachteile bei SnapShots.
8. Ceph ist eine sehr gute Alternative für Shared Storage ohne große Nachteile.

Proxmox VE - Cluster erstellen

Proxmox VE - Cluster mit ZFS

Proxmox und Timeserver:
Wichtig ist die richtige Uhrzeit auf den einzelnen Proxmox Nodes. Besonders problematisch wird eine unterschiedliche Zeit in einem Cluster. Warum ist das so? Viele Schlüssel für die Anmeldung sind zeitabhängig. Ist der Unterschied in den Zeiten zu groß, dann klappen Anmeldungen nicht mehr und auch Verschlüsselungen können Probleme bekommen.
Neben den reinen Cluster-Funktionen kann der Host aber auch den virtuellen Maschinen die Uhrzeit vorgeben. Und dann sind ganze Umgebungen mit der falschen Uhrzeit unterwegs ...

Proxmox nutzt normalerweise aus der Grundinstallation heraus Timeserver aus dem Debian Pool. Ist ein interner Zeitserver verfügbar, dann kann auch dieser genutzt werden. Wichtig ist diese Einstellung, wenn Zeitserver im Internet durch die Firewall geblockt werden.

Unter /etc/chrony/chrony.conf die folgenden Zeilen ergänzen bzw. ersetzen:

server ntp1.example.com iburst
server ntp2.example.com iburst
server ntp3.example.com iburst

Hierbei natürlich die entsprechenden Timeserver als FQN oder IP eintragen. Danach muss der chrony-Dienst noch neu gestartet werden:

systemctl restart chronyd

Kontrolle ob das geklappt hat und der Timeserver auch erreichbar ist:

journalctl --since -1h -u chrony

Hinweis: Diese Einstellung ist aktuell nicht über die GUI erreichbar.

Ceph Storage im Proxmox Cluster:
Mit Ceph kann Proxmox einen echten Shared Storage nutzen. Ceph ist hierbei ein verteilter Objektspeicher und kann für virtuelle Maschinen oder Container genutzt werden. Dies ist sehr ähnlich dem VMware vSAN, da die Ceph Knoten auch auf den Hypervisoren laufen können. Ceph kann jedoch auch als eigenständiger Speicher aufgebaut werden.

Dies sind die Hauptbestandteile eines Ceph Clusters:

1. Monitor: Die Monitore überwachen den aktuellen Zustand des Ceph Clusters und kennen alle beteiligten Komponenten. Sie tauschen die Statusinformationen aus. Es wird mindestens ein Monitor benötigt, für die Verfügbarkeit sollten es aber mindestens 2 sein.
2. Manager: Seit Version 12 wird auch ein Manager benötigt, der externe Zugriffe regelt und zusätzliche Monitoring-Aufgaben übernimmt.
3. OSD (Object Storage Daemon): Dieser Prozess ist für die Speicherung der Daten auf jedem Host zuständig. Es gibt also mindestens einen OSD pro Node des Storage-Clusters und maximal so viele wie HDDs oder SSDs vorhanden sind.
4. Journal: Das Journal nimmt alle geschriebenen Daten als erstes auf und wird für evtl. Recovery Funktionen benötigt. Das Journal ist seit Version 12 in den Datenspeicher integriert. Vorher benötigte man ein eigenes Device.
5. RBD oder RADOS Block Device: Die ist eine virtuelle Festplatte aus dem Ceph und wird als Device im Proxmox VE genutzt. Es ist im Ceph die Schicht zur Datenspeicherung.
6. CephFS: Ein verteiltes Dateisystem mit Cluster-Funktionen. Es kann also auf mehreren Hosts gemountet werden. Das CephFS nutzt MDS, einen Metadaten-Speicher.
7. Pool: Dies ist eine logische Einheit, in welchem verschiedene RBD Device zusammengefasst werden bzw. sie werden aus dem Pool gebildet. Im Pool wird festgelegt, wie oft die Daten gespeichert werden sollen, also wie oft repliziert werden muss.

Ceph Storage im Proxmox Cluster erstellen

Fibre Channel Shared Storage im Proxmox Cluster:
Ein Shared Storage von einem Fibre Channel System (oder auch iSCSI) kann relativ einfach in Proxmox eingebunden werden. Dies ist aber nicht über die GUI möglich und es sind auch nicht alle benötigten Komponenten vorab installiert. Die Grundkonfiguration muss über SSH erfolgen, hier müssen die erforderlichen Pakete installiert und konfiguriert werden. Dies sind nur wenige Befehle, die mehr oder weniger nach einer Anleitung durchgeführt werden können. Wichtig ist allerdings die Kontrolle, ob alles so geklappt hat, wie gefordert.

1. Installation der fehlenden Pakete:
apt update
apt install multipath-tools

2. Multipathing Grundkonfiguration:
multipath -v3 (Auslesen der benötigten WWID)
multipath -a WWID (Freigeben der WWID)
multipath -v3 (Aktivieren der WWID)

3. LVM einrichten:
pvcreate /dev/dm-1
vgcreate san1 /dev/dm1

4. Weiter in der GUI

Fibre Channel Shared Storage im Proxmox Cluster

iSCSI Shared Storage im Proxmox Server:
Ein iSCSI Storage kann über die GUI in Proxmox eingebunden werden. Aber nur, wenn es nicht redundant angeschlossen ist, also nur mit einem Pfad. Bei redundanten Anbindungen ist es nicht über die GUI möglich und es sind auch nicht alle benötigten Komponenten vorab installiert. Die Grundkonfiguration muss über SSH erfolgen, hier müssen die erforderlichen Pakete installiert und konfiguriert werden. Dies sind nur wenige Befehle, die mehr oder weniger nach einer Anleitung durchgeführt werden können. Wichtig ist allerdings die Kontrolle, ob alle Pfade vorhanden sind und der LVM auch auf dem multipath Device eingerichtet wurde.

1. Installation der fehlenden Pakete:
apt update
apt install multipath-tools

2. iSCSI Grundkonfiguration:
in /etc/iscsi/iscsid.conf die Zeilen
node.startup = automatic
node.session.timeo.replacement_timeout = 15
ändern. Es dürfen vorher keine Targets verbunden worden sein!
systemctl restart open-iscsi
iscsiadm -m session
lsscsi
Konfiguration der Targets im Proxmox: /etc/iscsi/nodes/*

3. Multipathing Grundkonfiguration:
multipath -v3 (Auslesen der benötigten WWID)
multipath -a WWID (Freigeben der WWID)
multipath -v3 (Aktivieren der WWID)

3. LVM einrichten (geht auch über die GUI):
pvcreate /dev/dm-1
vgcreate san1 /dev/dm1

4. Weiter in der GUI

iSCSI Shared Storage im Proxmox Server

Virtuelle Maschinen im Proxmox Cluster:
Auf dem Proxmox Cluster können virtuelle Maschinen neu erstellt oder von anderen Umgebungen migriert werden. Mögliche Beispiele stellen wir in Videos vor.

1. Linux Server als virtuelle Maschine neu erstellen
2. Windows Server als virtuelle Maschine neu erstellen
3. Bestehende virtuelle Maschine von VMware migrieren
4. Bestehende virtuelle Maschine von Hyper-V migrieren

Linux Server als virtuelle Maschine neu erstellen

Windows Server 2022 als virtuelle Maschine neu erstellen

Hinweise zum Video:
Download der Treiber für die VM: https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/

Importieren einer VMware VM in Proxmox

Hinweise zum Video:
Download der Treiber für die VM: https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/
Download OVF Tools: https://developer.vmware.com/web/tool/4.6.0/ovf-tool/

Befehle:
1. ovf-Tool herunterladen und entpacken (wget und unzip)
2. in das Verzeichnis wechseln
1. ./ovftool vi://root@esx-server/import-vm /import/
2. qm importovf id-nr /import/import-vm/import-vm.ovf storage

Update zum Import einer VMware VM in Proxmox

Hinweise zum Video:
Download der Treiber für die VM: https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/

Die OVF Tools von VMware (das ist Open Source) sind in der Proxmox VE 8.2.2 schon integriert. Dies ermöglicht den einfachen Import einer virtuellen Maschine.

Proxmox VE - Betrieb im Unternehmen

Was ist beim professionellen Betrieb einer Proxmox Umgebung zu beachten? Hardware und Installation muss entsprechend durchgeführt und die Redundanzen müssen vorhanden sein. Wichtig ist dann die kontinuierliche Überwachung der Systeme. Sollte ein Node ausfallen, oder ein LAN Switch oder auch nur ein Speichersystem volllaufen, alles dies muss sofort erkannt werden. Das ist aber bei jeder Umgebung, egal ob Virtualisierung und Storage, wichtig und entscheidend für die Zuverlässigkeit.

Wenn man etwas passieren sollte, dann ist der Support wichtig. Einmal für die Hardware und zum anderen auch für die Software, also Proxmox VE und Proxmox Backup (wenn dies zusammen eingestzt wird).

Und eines hilft meistens: Keep it simple! Es muss übersichtlich, aber trotzdem dokumentiert sein. Die Abläuft müssen klar und strukturiert und am besten einheitlich sein. Nichts führt schneller zum Übersehen von Fehlern, wenn zum Beispiel jede VM anders ist und jede Sicherung zu einem anderen Zeitpunkt und in einem anderen Ablauf durchgeführt wird.

Gerade mit weniger Erfahrung in Linux sollte man sich an die Standards von Proxmox halten. Klar, ZFS kann mit vielen Funktionen erweitert werden, es kann ein Caching aktiviert, komplexe Replikationen und Clones erstellt werden, also automatisch. Aber wenn man es nicht durchschaut und später Fehler nicht findet, dann lieber an Standards halten. Hilft dann auch beim Support-Fall.

Proxmox - Datensicherung und Restore

1. Wenn man es einfach haben möchten, den Proxmox Backup Server verwenden.
2. ZFS bietet sich mit SnapShots und Replikationen in kleinen Umgebungen an.
3. Backups testen!

Also eigentlich nichts besonderes im Vergleich zu anderen Herstellern. Der Vorteil bei Proxmox: Das Backup gibt es vom gleichen Hersteller mit der gleichen Oberfläche und einer nahtlosen Integration.

Proxmox Backup Server PBS Grundlagen

Proxmox - Security / Schutz vor Hackern

In der Basis-Installation ist nur ein User vorhanden, der "root" für die Weboberfläche und SSH bzw. Console. Ein User der alles darf, aber auch alles zerstören kann. Ein idealer Zustand für den Hacker, eine Katastrophe für den Admin. Also was können wir tun?

1. Den root-User so weit wie möglich in der Nutzung begrenzen, also nur für den Notfall
2. Komplexe und individuelle Passwörter für die User
3. User mit speziellen beschränkten Rechten definieren für die alltägliche Nutzung
4. Zweifaktor Authentifizierung nutzen
5. Netzwerk segmentieren, kein Zugriff aus dem Internet erlauben

Proxmox Security im Basis-System

Proxmox Security bei der Datensicherung

Wie lässt sich jetzt auf dem Backup-Server das Pruning (also das Löschen der alten Sicherungen) individuell steuern?

Durch ein einfaches Skript auf dem Backup-Server. Dieses überprüft die Anzahl der entsprechenden Sicherungen pro VM und Löscht im Falle eines Falles dann die passenden alten Sicherungen:

AUS="/tmp/prune.log"
AUS2="/tmp/prune877"
echo "Prune fuer VM100:" >> $AUS
proxmox-backup-client prune vm/100 --keep-daily 7 --keep-hourly 8 --keep-monthly 6 --keep-yearly 4 > $AUS2
cat $AUS2 | grep keep | wc -l >> $AUS
cat $AUS2 | grep remove >> $AUS

Achtung: Dieses Skript löscht wirklich die Sicherung der VM100!!!

Dieses Skript löscht alle Sicherung älter als 7 tägliche, 8 stündliche, 6 monatliche und 4 jährliche Versionen. Es wird z.B. als CRON-Job einmal pro Tag auf dem Backup-Server gestartet. Es folgt die Ausgabe der Anzahl der vorgehaltenen und der gelöschten Sicherungen. Diese Ausgabe kann z.B. per Mail an den Administrator geschickt werden.
Werden keine individuellen Aufbewahrungszeiten benötigt, kann der Prune-Job einfach über die Weboberfläche des Backup-Servern genutzt werden.

Proxmox - ZFS Boot reparieren

Der Proxmox Server bootet von einem ZFS Spiegel und jetzt ist eine Platte ausgefallen? Das lässt sich einfach wieder reparieren. Wichtig ist beim Austausch der Platte, auch wirklich die funktionsfähige Platte im System zu lassen. Im Falle eines Falles bootet das System auch nur von einer Boot-Platte. Was ja genau der Sinn eines RAID 1 als Boot-Platte ist ...

Proxmox Server mit ZFS Boot reparieren

Die folgenden Befehle können in diesem Fall hilfreich sein. Wichtig auf jeden Fall eine Sicherung und bei kleinsten Zweifeln auf den Hilfeseite von Proxmox schauen:

sgdisk /dev/sda -R /dev/sdd (Quelle = sda Ziel = sdd)
sgdisk --randomize-guids /dev/sdd (Ziel = sdd)
proxmox-boot-tool format /dev/sdd2 (Ziel = sdd2, Achtung der formatiert wirklich!)
efibootmgr -v (wenn EFI not supported, dann grub)
proxmox-boot-tool init /dev/sdd2 grub (Ziel = sdd2 mit grub)
proxmox-boot-tool status
ls -lah /dev/disk/by-id
zpool attach rpool alte-part3 neue-part3 (neue und alte aus dem disk by-id)
zpool status rpool

Achtung: Bei Secure Boot weitere Infos

Proxmox - ZFS Boot Recovery

Der Proxmox Server bootet von einem ZFS Laufwerk? Und beim letzten Update ist etwas falsch gelaufen? Oder die letzte Änderung am System war nicht so gut? Dienste starten nicht mehr oder VMs sind plötzlich sehr langsam oder nicht mehr lauffähig? Also an der Hardware ist alles in Ordnung, aber die letzte Änderung war wohl nicht so gut ...

Wenn man VORHER einen SnapShot der ZFS Boot-Platten gemacht hat, dann lassen sich die letzten Änderungen sehr einfach wieder zurück rollen. Wichtig dabei, die Anleitung klappt nur, wenn auch von einem ZFS gebootet wird.

Hinweis:
Dies sollte die letzte Rettung für ein nicht mehr lauffähiges System sein. Es besteht die Möglichkeit, dass das System nach der Recovery nicht mehr stabil oder nicht mehr bootfähig ist. Daher sollte IMMER auf ein aktuelles Backup geachtet werden. Dies schließt nicht nur die virtuellen Maschinen und Container ein, sondern auch die Boot-Platten bzw. die Konfiguration. Ist die Konfiguration gesichert und alle Anpassungen wurden dokumentiert, dann ist immer noch eine Neuinstallation möglich, falls die Recovery fehlschlägt.

Proxmox Server nach Updates mit ZFS recovern

Die folgenden Befehle können in diesem Fall hilfreich sein. Wichtig auf jeden Fall eine Sicherung und bei kleinsten Zweifeln auf den Hilfeseite von Proxmox schauen:

zfs snapshot -r root@vers7 (vor jeder größeren Änderung)

Boot von der Installations-CD (oder Installations-USB-Stick)
in "Installation mit Debug" wechseln

in der Commandline (evtl. erst die zweite CLI) dann folgende Befehle:
zpool import -f rpool
zpool list (rpool muss vorhanden sein)
zfs list -t snapshot (die SnapShots vor der Änderung müssen vorhanden sein)
zfs roolback -r rpool@vers7
zfs roolback -r rpool/ROOT@vers7
zfs roolback -r rpool/ROOT/pve-1@vers7
zfs roolback -r rpool/data@vers7
Anpassung auf den jeweiligen Namen des SnapShots und evtl. der ZFS-Verzeichnisse
zpool export rpool

Reboot
Achtung: Beim ersten Reboot im grub oder UEFI die richtigen Kernel auswählen, wenn dort eine Änderung passiert ist!
Soll weiterhin der alte Kernel gebootet werden, dann in /etc/default/grub anpassen und update-grub nicht vergessen

Erklärungen und Erläuterungen

1. ZFS
ZFS ist ein von Sun Microsystems entwickeltes transaktionales Dateisystem, das zahlreiche Erweiterungen für die Verwendung im Server- und Rechenzentrumsbereich enthält. Hierzu zählen die vergleichsweise große maximale Dateisystemgröße, eine einfache Verwaltung selbst komplexer Konfigurationen, die integrierten RAID-Funktionalitäten, das Volume-Management sowie der prüfsummenbasierte Schutz vor Datenübertragungsfehlern.

2. Ceph
Ceph ist eine quelloffene verteilte Speicherlösung. Kernkomponente ist mit RADOS (Reliable Autonomic Distributed Object Store) ein über beliebig viele Server redundant verteilbarer Objektspeicher. Ceph bietet dem Nutzer drei Arten von Storage an:
Einen mit der Swift- und S3-API kompatiblen Objektspeicher (RADOS Gateway)
virtuelle Blockgeräte (RADOS Block Devices)
CephFS, ein verteiltes Dateisystem.

Ceph kann als RADOS Block Device (RBD) über das Ceph iSCSI Gateway auch als hochverfügbares iSCSI-Target bereitgestellt werden. Dadurch kann es auf Client-Seite durch viele Betriebssysteme (auch Windows) genutzt werden. Die Entwicklung startete im Jahr 2012 und Ceph ist die Basis für viele Cloud-Architekturen.