Stor IT Back - Ihr Speicherspezialist
Proxmox Tipps und Tricks V1.5 (c) Stor IT Back 2024
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.
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
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.
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:
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 übr 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
multipath -v3
3. LVM einrichten:
pvcreate /dev/dm-1
vgcreate san1 /dev/dm1
4. Weiter in der GUI
Fibre Channel Shared Storage im Proxmox Cluster
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.
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.
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.
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
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?
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.
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
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
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.