Dokumentation

Dokumentation von den Kursen von sysops

Proxmox

Die Dokumentation für "Proxmox Produktiv mit ZFS betreiben" basiert auf einem kostenpflichtigen Kurs und soll dessen Inhalte wiedergeben, kann aber nicht die Betreuung und Beantwortung von Fragen, wie sie der Besuch des Kurses bietet, ersetzen. Es soll das Wissen von den hauptberuflichen Sysops Admins an Interessierte weitergegeben werden, die es danach auf den von Ihnen betreuten Systemen umsetzen können.

https://cloudistboese.de - Das Schulungsportal von sysops.tv

Proxmox VE - Alternative zu vSphere und Hyper-V mit Support aus Deutschland und Österreich

Was ist Proxmox VE

Wo sind die Grenzen von Proxmox VE

Weitere Funktionen, die eher weniger Sinn machen

Indikation für Einsatz

** Bei Proxmox kommt alles aus den Kernel (ZFS, Ceph, LXC, KVM, uvm.) **

Linux Kommandos die man kennen sollte

Proxmox Installation

Um Proxmox mit ZFS nutzen zu können, müssen die Platten direkt an Proxmox angebunden werden. Es sollte kein RAID Controller mit RAID 0 genutzt werden, da dies früher oder später zu Problemen und Datenverlusten führen wird! Damit auch eine Update von Promox 7.x auf 8.x gezeigt werden kann, wird im Kurs mit der Installation einer Proxmox Version 7.x begonnen und später auf 8 aktualisiert. Das Postinstall Script aus dem Bashclub wird installiert, um auch alle benötigten Tools für die tägliche Arbeit und im Problemfall im Zugriff zu haben. (z.B. ohne ein Netzwerkverbindung kann nichts mehr nachinstalliert werden)

Spickzettel für Installation

Proxmox GUI Zugriff

Update nach Proxmox 8.x - Für Einsteiger am einfachsten bei Erstinstallation zu üben

Proxmox Update 7 to 8

Das Pre-Upgrade Check Script pve7to8 sollte ausgeführt werden, um mögliche Probleme vor dem Upgrade erkennen zu können. Erstmal ohne Parameter und anschließend mit Parameter (--full: alle Checks).

** Für das Upgrade muss entweder eine Subskription erorben werden. Alternativ kann man auch das Enterprise Repository deaktivieren und das No-Subkription Repository aktivieren. Nur so erhält man Proxmox Updates!!! Ohne diese Auswahl kommen nur Debian Security Fixes!!!

Hier der Stand Version 7 zu 8

Wir empfehlen die VMs und Container zu stoppen und einen zeitnahen Reboot - Der neue Kernel passend zur GUI kann nur so aktiviert werden

apt update apt dist-upgrade pveversion

Letzte Version PVE 7 sollte nun installiert sein, kein Reboot notwendig hier

Upgradeprozedur bei Standardsystem

sed -i 's/bullseye/bookworm/g' /etc/apt/sources.list # ändert alle Repositories von Bullseye (Debian 11) zu Bookworm (Debian 12)

Enterprise Repo anpassen

echo "deb https://enterprise.proxmox.com/debian/pve bookworm pve-enterprise" > /etc/apt/sources.list.d/pve-enterprise.list

Debian update

screen # falls etwas schief geht kann man mit screen -r zurück zur Sitzung apt update apt dist-upgrade #sollte hier mehrere hundert Aktualisierungen ankündigen

Während des Upgrades sollte man alles mit N beantworten und den Diensteneustarts zustimmen. Es kommt ggf. auch ein Textdokument was mit w zu verlassen ist

Unser Postinstaller sorgt in kürzester Zeit für alle notwendigen Sicherheits- und Komforfunktionen für den Notfall

Postinstall aus bashclub (proxmox-zfs-postinstall) auf github

Wir sichern extra die /etc Ordner nach rpool/pveconf, da der Ordner /etc/pve aus einer Datenbank live erstellt wird. Er wäre bei einer Reparatur via Boot ISO leer!!!

Die ZFS auto Snapshots werden über die crontab ausgeführt. Dafür gibt es verschiedene Verzeichnisse:

In den Ordner liegt dann für jede "Aufgabe" ein eigene Datei (z.B. zfs-auto-snapshot), in welcher die auszuführen Kommandos enthalten sind. Dort ist auch hinterlegt wieviele auto snapshots aufgehoben werden sollenn. (--keep=96)

Die Zeitpunkte wann dieses ausgeführt werden sind in der Datei /etc/crontab definiert. z. B. könnte dort der tägliche Zeitpunkt angepasst werden

Ebenfalls finden sich Skripte ab Werk unter /etc/cron.d für z. B. Scrubbing und Trimming am Sonntag. Nicht jedem taugt dieser Zeitpunkt!

cat /etc/crontab 
# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# Example of job definition:
# .---------------- minute (0 - 59)
# |  .------------- hour (0 - 23)
# |  |  .---------- day of month (1 - 31)
# |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
# |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# |  |  |  |  |
# *  *  *  *  * user-name command to be executed
17 *	* * *	root	cd / && run-parts --report /etc/cron.hourly
25 6	* * *	root	test -x /usr/sbin/anacron || { cd / && run-parts --report /etc/cron.daily; }
47 6	* * 7	root	test -x /usr/sbin/anacron || { cd / && run-parts --report /etc/cron.weekly; }
52 6	1 * *	root	test -x /usr/sbin/anacron || { cd / && run-parts --report /etc/cron.monthly; }
#

Zusätzlich gibt es für jeden User (z.B. root) noch eine eigene crontab, diese liegen unter cd /var/spool/cron/crontabs/. Dort gibt es dann eine Datei root für den User root, falls diese erzeugt wurde. Diese Datei wird z.B. auf den Linux VMs genutzt, um das Trimming zeitgesteuert ausgeführen zu können.

proxmox-boot-tool / ZFS Feature Upgrade / Trimming einschalten

Mit dem promox-boot-tool könnten Platten nach einen Hardwaretausch wieder bootfähig gemacht werden. Heute sollte nach Möglichkeit uefi Boot eingesetzt werden und nicht mehr legacy Boot, damit werden die Boot Platten automatisch erkannt und müssen nicht einzeln durch probiert werden, wie bei legacy boot. Autotrim sollte auf den SSD ZFS Datasets eingeschaltet sein, damit gelöschte Blöcke wieder im Dateisystem schnell verfügbar gemacht werden.

Optionale Funktionen zur ZFS Storage Optimierung

Einige wichtige Ordner vom Proxmox:

PVE startet noch, hat aber defekte Installation oder Konfiguration - Rollback vom Debian mit PVE

Wenn der Proxmox nicht mehr richtig funktioniert, werden die folgenden Schritte durchgeführt, um ihn wieder herzustellen zu können. Die erforderlichen ZFS snapshots werden durch die "Tools" des Postinstaller erzeugt. Beim PVE Ordner (/etc/pve) handelt es sich um eine Datenbank (/dev/fuse 128M 20K 128M 1% /etc/pve), die ohne den Postinstaller nicht gesichert würden (rpool/pveconf 884G 128K 884G 1% /rpool/pveconf).

Daher sollte der Postinstaller aus dem Bashclub auf jeden Promox PVE installiert sein, damit die Konfigurationsverzeichnisse von Proxmox auf ZFS gesichert und mit Auto Snapshosts versehen werden !!!

**Sollte der Rollback Punkt z. B. auf einen Punkt von PVE 7 zeigen, so kann man beim Booten einen älteren Kernel auswählen

Nach erfolgreichem Neustart empfehle ich

Installation Windows mit VirtIO Treiber

** Inzwischen installiert der Postinstaller einmalig eine aktuelle Virtio Treiber ISO als stabile Version - Für spätere Downloads...**

Inzwischen kann man die geladene virtio.iso als zweites Laufwerk in die VM einklinken

q35 Version 5.2 - weniger Probleme als mit Version 8.0 wegen deutschen Treibern - ist für US optimiert ... - Probleme mit Netzwerkkarten möglich

EFI hat feste Bildschirmauflösung - kann nur im EFI der VM eingestellt werden (EFI BIOS) - Im Bootvorgang in der Console (Proxmox GUI) - ESC drücken

Während der Installation am einfachsten nur die VIOSCSI Treiber installieren, da sonst keine Disks angeboten werden Den Rest des Setups von der VIRTIO ISO kann nach der Installation erledigt werden. Das spart die dummen Sicherheitsfragen und geht schneller.

Am Ende sollte auf der VM Statusseite die IP Adresse zu sehen sein, ansonsten noch prüfen ob der Haken bei Guest Agent an ist!

Für alle die von den APPS genervt sind etwas lustiges zum nachbasteln

Get-appxPackage | Remove-appxPackage # man verliert Taschenrechner - alle App werden entfernt - auch der Storage wird entfernt - Nach Feature Update wieder alles da

**Windows installiert am Ende des Setups eine Wiederherstellungspartition. Diese ist eventuell zu entfernen, da ansonsten kein Resize möglich ist. Der Resize ist auf der Disk in PVE jederzeit möglich

** Windows ist inzwischen in der Lage freie Blöcke an ZFS zurückzugeben, für den Fall daß wie beschreiben SCSI Single + SSD Emulation plus Discard gewählt wurde**

Optional noch Hilbernation Mode aus

Unser Datastore Swap kann genutzt werden um die Auslagerungsdatei auf eine eigene Disk zu legen. Das spart bei ramhungrigen Systemen viel Platz, da dort keine automatischen Snapshots ausgeführt werden. Die Platte muss nicht gesichert werden. Bei Linux bitte die Swap Disks mit Backup einmal sichern

Trimming unter Linux

fstrim -av # muss eine Ausgabe bringen - sonst ist die VM falsch konfiguriert - VM Platten auf SSD und Discard umstellen

Festplatten Tausch bei Defekt oder S.M.A.R.T Fehler

Es reicht nicht mit zpool replace eine fehlende oder defekte Disk zu ersetzen. Sie könnte danach nicht booten. Wir benötigen ebenfalls zwei Partitionen mit dem Bootimage!

Der Fall beschreibt den Tausch optional gleich gegen eine größere Festplatte oder SSD

Erklärung zum Kommando sgdisk ... -- R ...

dmesg -Tw

Platte einbauen und Output prüfen, sdf ist neue Disk

zpool set autoexpand=on rpool # Erweiterung des Pools erfolgt am Ende automatisch! Bei Raid 10 reicht es zwei Disks zu Tauschen, bei RaidZx müssen allte getauscht werden um den Platz zu erweitern!

ls -althr /dev/disk/by-id | grep sdf (sdf wurde als neue Disk erkannt)

zpool status

Output zeigt aktive oder defekte Disks

	rpool                                                 ONLINE       0     0     0
	  mirror-0                                            ONLINE       0     0     0
	    ata-INTEL_SSDSC2KB019T8_PHYF951101ZS1P9DGN-part3  ONLINE       0     0     0
	    ata-INTEL_SSDSC2KB019T8_PHYF951102271P9DGN-part3  ONLINE       0     0     33

Wir tauschen nun die zweite Disk vorsorglich

-part3 zeigt deutlich daß es sich hier um die dritte Partion handelt die ersetzt werden muss, folglich sind Parition 1 und 2 zum booten!!!

ls -althr /dev/disk/by-id | grep ata-INTEL_SSDSC2KB019T8_PHYF951102271P9DGN-part3

lrwxrwxrwx 1 root root 10 Oct 15 17:38 ata-INTEL_SSDSC2KB019T8_PHYF951102271P9DGN-part3 -> ../../sdb3

Wir müssen also sdb3 ersetzen

Als erstes Paritionstabelle übernehmen und erweitern, falls größere Disk

sgdisk /dev/sdb -R /dev/sdf #sdb ist eine gute Disk, sdf die neue Disk
sgdisk -G /dev/sdf # neue GUID damit EFI die Disk unterscheiden kann
proxmox-boot-tool format /dev/sdf2 #format mit fat32
proxmox-boot-tool init /dev/sdf2 #kopiert Bootimage und notiert die Disk für künftige Updates

Optional

cfdisk /dev/sda # Partition vergrößern

** Beim nächsten sgdisk der Paritionstabelle einfach die große Disk als Vorlage nehmen

Jetzt den eigentlichen Datenbestand ersetzen

ls -althr /dev/disk/by-id | grep sdf | grep part3
zpool replace rpool ata-INTEL_SSDSC2KB019T8_PHYF951102271P9DGN-part3 ata-INTEL_SSDSC2KB019T8_PHYF95111111PXXX-part3

** Kontrolle des Erfolgs mit

zpool status # da soll dann die alte Disk raus sein und keine Fehler
zpool list # eventuell mehr freier Speicher nach Austausch von zwei Disks oder mehr
proxmox-boot-tool status #sollte zwei Treffer und einen Fehler melden, wegen gezogener defekter Disk
proxmox-boot-tool clean entfernt tote Bootdatenträger

Windows kaputt machen - Trojanersimulation

ZFS Cache

zpool add -n rpool cache ata-intense..
zpool add -nf rpool cache ata-intense.. # wenn schon Daten auf der Platte
zpool add -f rpool cache ata-intense..
zpool iostat -v 3
zpool iostat -v 1 # 1 sec

Das Wort "cache" im Kommando ist sehr wichtig, da sonst die Platte evt. als einzel Mirror an den stehenden Mirror angehängt wird und das wollen wir nicht, daher immer mit -n testen !!!

Proxmox Cluster

cd /etc/pve

service pveproxy restart


cd /rpool/pveconf 
zfs list -t snapshot rpool/ROOT/pve-1 


zfs rollback -r rpool/ROOT/pve-1@zfs-auto-snap_hourly-2023-09-28-1017 # panic Variante und Stromkabel nach 2 s


dd if=/dev/zero of=/dev/sda2 bs=1M count=511 
dd if=/dev/zero of=/dev/sdd2 bs=1M count=511 
proxmox-boot-tool status

Backup Proxmox Datenbank - Wie funktioniert das ?

Backup und Monitoring

zfs list # Ziel Backup Disk - Pool Backup
zfs create backup/repl -o com.sun:auto-snapshot=false 
zfs set com.sun:auto-snapshot=false backup 
bash-club-zfs-push-pull # auf Ziel ausführen


git clone https://github.com/bashclub/bashclub-zfs-push-pull.git
cd bashclub-zfs-push-pull
chmod +x 02pull
bashclub-zfs
cp bashclub-zfs /usr/bin

vi 02pull # Anpassen - In for Schleife ein echo zum Testen
bashclub-zfs # Parameter I und R - alte Snapshot und Zwischen-snapshots mitnehmen # Prinzipiell pull !!! - Quelle kommt nicht auf das Ziel, sondern nur Ziel kommt auf Quelle
cp 02pull /etc/cron.hourly

Für Trojaner sicher immer die "pull Methode" anwenden. Nur Ziel kommt auf die Quelle und nicht umgekehrt.

Monitoring

wget -O /usr/local/bin/checkzfs https://raw.githubusercontent.com/bashclub/check-zfs-replication/main/checkzfs.py  
chmod +x /usr/local/bin/checkzfs 
checkzfs --sourceonly 
checkzfs --filter rpool/data/ --replicafilter backup/repl --threshold 75,90 
checkzfs --filter rpool/data/ --replicafilter backup/repl --threshold 75,90 --columns +message 


checkzfs --filter rpool/data/ --replicafilter backup/repl --threshold 75,90 --columns +message --output checkmk
# Datei generieren und auf anderen Server kopieren - über scp 
zfs mount -a 
ls /backup/repl/subvol-100-disk-0/etc/pmg 
mkdir /mnt/restore 

mount /dev/zvol/backup/repl/vm-101-disk-1-part3 /mnt/restore 
ls /mnt/restore # Damit kann man Daten aus dem Windows zurückspielen 
umount /mnt/restore 

zfs create backup/klon -o com.sun:auto-snapshot=false 
zfs list -t snapshot backup/repl/vm-101-disk-1 
zfs clone backup/repl/vm-101-disk1@bashclub-zfs_2023-09-28_16:21:30 backup/klon/vm-101-disk-1 

mount /dev/zvol/backup/klon/vm-101-disk-1-part3 /mnt/restore 
ls /mnt/restore 
vi /etc/pve/qemu-server/9101.conf # Anpassung das der Klon verwendet wird 
    

umount /mnt/restore 
zfs get guid 
zfs get guid | grep bashclub-zfs_2023-09-28_16:46:50 
zfs get creation rpool/data/subvol-100-disk-0@bashclub-zfs_2023-09-28_16:46:50

zfs snapshot rpool/data/vm-100-disk-0@snap1 # snapshot auslösen 
zfs send rpool/data/vm-100-disk-0@snap1 | zfs recv -dvF backup/repl # local 
zfs send rpool/data/vm-100-disk-0@snap1 | ssh rot@zielip zfs recv -dvF # anderes System


ssh root@sourceip zfs send rpool/data/vm-100-disk-0@snap1 | zfs recv -dvF backup/repl # pull


checkzfs --filter rpool/data/ --replicafilter backup/repl --threshold 75,90 --columns+message --output mail

Verschlüsselung mit Proxmox, ZFS und Debian / Windows

Hier mal zur Überlegung was für einen Sinn macht

Physischer PC
Proxmox LXC


Proxmox LXC ZFS verschlüsselt

zfs create rpool/encrypted -o keylocation=prompt -o keyformat=passphrase -o encryption=on

#Datastore im PVE anlegen auf rpool/encrypted

nach Reboot zfs load-key #Passphrase eingeben, dann pct start xxx

Alternativ kann man das auch von außen alle Stunde auf Verdacht oder nach Prüfung per SSH auslösen

Proxmox VM



Proxmox VM ZFS verschlüsselt

zfs create rpool/encrypted -o keylocation=prompt -o keyformat=passphrase -o encryption=on

#Datastore im PVE anlegen auf rpool/encrypted

nach Reboot zfs load-key #Passphrase eingeben, dann qm start xxx

Alternativ kann man das auch von außen alle Stunde auf Verdacht oder nach Prüfung per SSH auslösen

Proxmox VM Gast verschlüsselt

Verschlüsselung wird bei der Installation vorgenommen. Nach jedem Reboot muss das Passwort in KVM Konsole von Proxmox eingegeben werden. Automatisierung nicht möglich
Abschließend ist das Ziel zu prüfen. Verschlüsselung gegen Diebstahl ist die ZFS Lösung völlig ausreichend. Replikation geht mit Raw (send -w), Backup nur wenn entsperrt ist.  Eine Sicherung einer intern verschlüsselten VM ist jederzeit, mit jeder Methode (PBS, ZFS) möglich, muss halt in jeder VM vorgenommen werden, LXCs lassen sich verschlüsselt nur gegen Diebstahl schützen, nicht gegen Einsicht.

Proxmox Best Practice Setup für ZFS und / oder Ceph im Cluster für Einsteiger (Stand Dezember 2024)

Der Verfasser des Artikels, Christian-Peter Zengel, hat zum Zeitpunkt des Artikels ca 15 Jahre Erfahrung mit ZFS und Proxmox. Er betreibt aktuell ca 150 Systeme mit Proxmox und ZFS

Das Einsatzgebiet geht von Standaloneinstallation bis zu ca 10 Hosts im Cluster. Es ist keine Ceph Expertise vorhanden!

Dieser Dokumentation basiert auf diesem online Kurse von cloudistboese.de

18.12.2024 - 11h Proxmox Best Practice Cluster mit ZFS + Ceph für Einsteiger

ZFS ist die perfekte Grundlage für kleine und mittlere Kunden komplett unverwundbar gegen Ausfall, Trojaner und vor allem Dummheit zu sein.

Ceph ist die Basis der höchsten Verfügbar- und Skalierbarkeit

In diesem Kurs vermitteln wir ZFS und Ceph Grundkenntnisse für Proxmox

Achtung: Das Tempo dieses Kurses ist relativ schnell, dafür werden alle Schritte mit Screenshots dokumentiert!

Er eignet sich für den schnellen Einstieg mit mit Wissen aus zuverlässiger Quelle.

Dauer ca 4h+

  • Basisinstallation Proxmox VE mit EFI auf ZFS
  • Installation und Hinweise auf Fehlerbehebung von PVE-Clustern
  • Einrichtung eines einfachen Ceph Clusters
  • Musteranlage einer VM und LXC für höchste Leistung und Platzersparnis
  • Konfiguration einer Hochverfügbarkeit für eine VM
  • Replikation mit Bordmitteln und deren Erfolgskontrolle
  • Automatisches Snapshotting von ZFS + Ceph mit CV4PVE + Admin GUI
  • Einrichtung Proxmox Backupserver auf LVM oder ZFS mit Sicherheitsoptimierung
  • Monitoring mit Check_MK plus Special Agent

Nach diesem Kurs kannst Du Proxmox im Cluster sicher und einfach betreiben.

Für erweiterte Trojanerabwehr bitte den Trojanersicherkurs besuchen.

Trainer/in: Christian Zengel

Der folgende Artikel eignet sich besonders für Einsteiger die mit mehr als einem Host im Cluster starten müssen.

Der Bezug auf Ceph soll lediglich zum Funktionsvergleich dienen. Wir empfehlen bis 10 Hosts immer ZFS!

Installation Proxmox

Ein System hat extra Platten für unseren Workshop, zwei wurden bereits installiert.

Es kommt der HPE Microserver Gen10 Plus V2, vorzugsweise mit ECC, zum Einsatz

Bildschirmfoto 2024-12-18 um 11.08.06.jpg

Wir installieren mindestens einen Raid1, 10 oder Z, niemals auf Basis eines Hardware Raid Controllers!

Für Cluster dringend alle IPs und Namen vorher klären, sonst kommt es zu späteren Zusatzarbeiten für den Cluster

Bildschirmfoto 2024-12-18 um 11.08.29.jpg

Cluster mit drei PVE erstellen

Cluster wird in Sekunden erzeugt, ein Node alleine läuft problemlos

Bildschirmfoto 2024-12-18 um 11.15.59.jpg

Bildschirmfoto 2024-12-18 um 11.17.18.jpg

Bildschirmfoto 2024-12-18 um 11.17.34.jpg

Cluster Nodes hinzufügen

Nodes mit den Join Information des ersten Clusternodes in der Zwischenlage auf neuen Node unter Join Cluster Einfügen und Rootpasswort und Clusternetz(e) bereitstellen

Bildschirmfoto 2024-12-18 um 11.17.55.jpg

Bildschirmfoto 2024-12-18 um 11.18.05.jpg

Bildschirmfoto 2024-12-18 um 11.18.42.jpg

Bildschirmfoto 2024-12-18 um 11.20.33.jpg

Der neue Node wird im Vorgang die Verbindung zum Browser verlieren, da er Schlüssel und Zertifikate des Clusters übernimmt. Der Browser muss neu geladen werden. Danach ist die Administration von jedem Clustermitglied aus möglich.

Lokale Storages benötigen lokalen Login zum Einrichten

Bildschirmfoto 2024-12-18 um 11.21.06.jpg

Postinstaller für erweiterte Funktionen

Unser Postinstaller vom #Bashclub funktioniert am besten mit Standalone.

Für unser Setup verzichten wir auf Autosnapshots für rpool/data, also dem local-zfs Store und auf das SSH-Hardening, aus Kompatibilitätsgründen

Diese Zusammfassung zeigt die für unser Setup günstigsten Settings, mehr Kontext im Kurs

Bildschirmfoto 2024-12-18 um 11.23.17.jpg

Demonstration ZFS Raid

Software Raid mit ZFS ist ultra schnell bei Problemen entstört. Der direkte Zugriff auf die Platten bringt via Monitoring Probleme vor Ausfall zum Vorschein. Im Beispiel packen wir eine Platte vor Reboot offline, bitte nicht nachmachen!

Bildschirmfoto 2024-12-18 um 11.23.54.jpg

Bildschirmfoto 2024-12-18 um 11.24.19.jpg

Trotz defektem Raid zeigt das Summarydashboard kein Problem. Hier muss mit Check_MK oder CV4PVE kontrolliert werden, oder...

Bildschirmfoto 2024-12-18 um 11.24.30.jpg

S.M.A.R.T Kontrolle via GUI aus Erfahrung oft noch ohne Fehler, während unser Check_MK Plugin schon Probleme erkennt!

Bildschirmfoto 2024-12-18 um 11.24.34.jpg

Bildschirmfoto 2024-12-18 um 11.24.50.jpg

Mühselige Kontrolle aller Systeme via GUI pro Host ist nicht praxistauglich!!!

Bildschirmfoto 2024-12-18 um 11.24.53.jpg

Musterinstallation Linux / Windows als VM

Der Postinstaller stellt die aktuelle Windows Treiber ISO in der Stabilen Version bereit, der Proxmox Installer das zweite Laufwerk dafür

Bildschirmfoto 2024-12-18 um 11.28.12.jpg

Bildschirmfoto 2024-12-18 um 11.28.19.jpg

i440FX als Maschinentyp und Bios sind inzwischen eher zu vermeiden, schliesslich soll der Kram lange laufen.

Funfact, i440FX war für die Pro Version des ersten Pentiums, dung ding da ding!


Bildschirmfoto 2024-12-18 um 11.28.43.jpg

Proxmox VE legt im ZFS oder Ceph ebenfalls einen Blockstorage für TPM und EFI Einstellungen an, diese werden Raw ohne Dateisystem geschrieben und haben nichts mit der EFI-Boot-Partition zu tun.

Die native Bildschirmauflösung des Systems wird in der VM beim Starten mit ESC eingestellt.

Der Virtio SCSI single Controller wird im Host als eigener Prozess und im Gast als eigener Controller pro Disk aktiviert

Der Qemu Agent sorgt für Shattenkopien, Freezing, Herunterfahren und mehr!

Bildschirmfoto 2024-12-18 um 11.29.33.jpg

Die Kombination von Discard, SSD Emulation, wie auch IO thread gibt bessere Auslastung und Entlastung von gelöschten Daten an den Host

Bildschirmfoto 2024-12-18 um 11.30.01.jpg

CPU Typ Host ist für identische Hardware in Clustern und Standalone zu bevorzugen, da hier alle Prozessorfunktionen genutzt werden

Bildschirmfoto 2024-12-18 um 11.30.41.jpg

Ballooning spart RAM beim einschalten und macht noch mehr. Treiber unter Windows sind notwendig

Bildschirmfoto 2024-12-18 um 11.31.00.jpg

Virtio Netzwerkkarten brauchen unter Windows eigene Treiber, performen aber bis 100Gbit

Bildschirmfoto 2024-12-18 um 11.31.21.jpg

Die eingebaute Replikation ist erst mal gut genug, auch wenn es mit Zsync besser geht. Dafür hat man, leider nur in der VM hier, Kontrolle über den Erfolg. Löscht man den Job, löscht sich das Replikat

Das Zeitfenster ist mit 15-60 Minuten optimal, mit einer Minute perfekt. Jedoch sollte man nicht jede VM auf eine Minute stellen. da hier das ZFS Auflisten zu Timeouts führt. 

Autosnapshotting ist nicht vorgesehen, leider!

Bildschirmfoto 2024-12-18 um 11.32.04.jpg

Bildschirmfoto 2024-12-18 um 11.32.23.jpg

Linux unterstützt alle Virtio Laufwerke und Netzwerkkarten nativ

Bildschirmfoto 2024-12-18 um 11.37.48.jpg

Installation Ceph

Der Assistent installiert die notwendigen Repositories. Wir empfehlen hier wenigstens die Community Subscription zu nehmen, da ein defekter Ceph-Cluster ein Single-Point-of-Failure ist

Bildschirmfoto 2024-12-18 um 11.44.26.jpg

Bildschirmfoto 2024-12-18 um 11.44.39.jpg

Bildschirmfoto 2024-12-18 um 11.46.22.jpg

Bildschirmfoto 2024-12-18 um 11.46.26.jpg

Die Auswahl der Netze für Cluster, Ceph, Rendundanz und weitere Segmentierungen sollten von einem Erfahrenen Fachmann vorgenommen werden. Wir empfehlen hier Inett aus Saarbrücken

Im aktuellen Setup können wir zum Testen nur das LAN nehmen, das wir ausdrücklich so nicht empfohlen!!!

Bildschirmfoto 2024-12-18 um 11.47.07.jpg

Bildschirmfoto 2024-12-18 um 11.47.37.jpg

Die Installation muss auf allen Clustermitgliedern wiederholt werden, wobei die Konfiguration via PVE Cluster übernommen wird

Jeder Host bekommt mindestens eine SSD als sog. OSD, ab drei Stück haben wir einen funktionierenden Ceph Cluster, ohne extra Sicherheit. Als Nettonutzplatz erhalten wir 1/3 der SSDs, in dem Fall knapp 1TB

Auf keinen Fall dafür in irgendeiner Weise Hardware Raid Controller nutzen!!!

Bildschirmfoto 2024-12-18 um 11.52.59.jpg

Ceph OSD Einrichtung

Bildschirmfoto 2024-12-18 um 11.53.32.jpg

Bildschirmfoto 2024-12-18 um 11.53.55.jpg

Ceph Pool anlegen

Der Pool verbindet die OSDs zum Verbund, die Rolle Monitor und Manager können auf mehrere Nodes verteilt werden, sonst wäre der Reboot des ersten Nodes nicht ohne Schaden möglich!

Bildschirmfoto 2024-12-18 um 11.54.36.jpg

Bildschirmfoto 2024-12-18 um 14.49.23.jpg

VM Migration Node zu Node

Die Übertragung einer laufenden VM oder eines LXC mit Shutdown ist bei ZFS und Ceph möglich.

Wärend bei CEPH der Speicher verteilt ist, muss bei ZFS RAM und Disk nocheinmalübertragen werden.

Bei vorheriger ZFS Replikation ist das meiste der VM schon auf dem Ziel und kann inkrementell ergänzr werden.

Gab es vorher keine Replikation muss die komplette VM übertragen werden.

Das Mittel der Übertragung ist je nach Zustand der VM via KVM oder ZFS möglich.

Ersteres würde zum Verlust von Snapshots führen!

Bildschirmfoto 2024-12-18 um 11.56.37.jpg

Bildschirmfoto 2024-12-18 um 11.56.53.jpg

Klonen zwischen ZFS und Ceph

Proxmox kann mit Bordmitteln die meisten Formate konvertieren.

Bildschirmfoto 2024-12-18 um 11.58.52.jpg

Qemu-Guest-Agent Installation

Dieses Paket für geordnetes Herunterfahren immer mitinstallieren und starten!

Bildschirmfoto 2024-12-18 um 12.02.01.jpg

IO Leistung der Systeme bei diesen Voraussetzungen

ZFS ist dreimal schneller und auf zwei Kisten verfügbar

Wir gehen von der sechsfachen benötigten Leistung aus um Leistungsmässig an ZFS Raid1 zu kommen

Bildschirmfoto 2024-12-18 um 12.11.17.jpg

Login für Root und PVE User mit zwei Faktor absichern!

Bildschirmfoto 2024-12-18 um 12.11.21.jpg

Bildschirmfoto 2024-12-18 um 12.11.35.jpg

Bildschirmfoto 2024-12-18 um 12.12.09.jpg

Weitere User benötigen entsprechende Rechte!

Bildschirmfoto 2024-12-18 um 12.12.28.jpg

Login Realm ist Linux User oder Proxmox Userbasis

Es können in der GUI keine weiteren Linux/PAM User angelegt werden, jedoch GUI aktiviert

Bildschirmfoto 2024-12-18 um 12.12.49.jpg

SSH Daemon gegen Passwort Login absichern

Bildschirmfoto 2024-12-18 um 12.13.29.jpg

Bildschirmfoto 2024-12-18 um 12.13.39.jpg

Eigene virtuelle Switche für VMs trennen das Verwaltungsnetz ab

Wenn die Resourcen vorhanden sind, dringend dafür sorgen daß Anwender und Gast VMs keinen Zugriff auf Proxmox VE, Switche und Firewalls haben

Bildschirmfoto 2024-12-18 um 12.14.57.jpg

Ein Blick auf ZFS klärt nicht welche VM auf welchem Host aktiv ist!

PVE1 und zwei sind auf den ersten Blick nicht zu unterscheiden, auch nicht mit Snapshotauflistung

Bildschirmfoto 2024-12-18 um 12.20.07.jpg

Bildschirmfoto 2024-12-18 um 12.20.50.jpg

Unser erweitertes Ablagekonzept macht die Funktion von abgelegten Daten viel deutlicher. Mehr auf cloudistboese.de

Bildschirmfoto 2024-12-18 um 12.21.29.jpg

Bildschirmfoto 2024-12-18 um 12.25.09.jpg

Prüfung der Replikationen muss mühselig pro VM vorgenommen werden

image.jpeg

Bildschirmfoto 2024-12-18 um 12.25.56.jpg

Leider zeigt das PVE Dashboard weder defekte Platten, noch Raids oder Replikationen in der Übersicht an. Hier wird später Check_MK oder CV4PVE für Übersicht sorgen müssen!

Bildschirmfoto 2024-12-18 um 12.26.11.jpg

Bildschirmfoto 2024-12-18 um 12.26.55.jpg

Postinstaller sichert komplette Konfiguration und dessen Historie mit Rsync und ZFS-Auto-Snapshot

Üblicherweise nutzen wir zfs-auto-snapshot gnadenlos auf alle Datasets und Volumes

Die Proxmox Konfiguration liegt jedoch in einer Datenbank und wird nach /etc/pve gemountet

Diesen Ordner sichern wir regelmässig nach /rpool/pveconf und bauen mit Autosnapshots eine Historie

Bildschirmfoto 2024-12-18 um 12.28.52.jpg

Hochverfügbarkeit einer VM / HA

Die HA Engine sorgt dafür daß VMs / LXC bei Ausfall eines Hosts auf einem anderen Host gestartet werden.

Der Übergang dauert mindestens zwei Minuten, wobei nur bei SAN oder CEPH kein Datenverlust entsteht

Bei ZFS verliert man dier die Replikationslücke!

Daher eignet sie  sich  am besten für Firewalls und Telefonanlagen


Die HA Gruppe definiert die gewünschte Ausführungspriorität, wobei höher mehr Prio hat

Prio 1 ist am niedrigsten

Bildschirmfoto 2024-12-18 um 13.20.48.jpg

Die VMs werden den Gruppen zugewiesen und definieren unseren Wunschort und Zustand

Bildschirmfoto 2024-12-18 um 13.21.03.jpg

Da PVE1 die höchste Priorität hatte wird VM 100 sofort dort hin migriert, die Replikation umgedreht

Bildschirmfoto 2024-12-18 um 13.21.24.jpg

Bildschirmfoto 2024-12-18 um 13.21.43.jpg

Wird ein Node neu gestartet, werden die VMs nicht automatisch umgezogen, sondern heruntergefahren.

Die Weboberfläche eines anderen Nodes muss dann geöffnet werden, die VMs vorher umgezogen werden!

Bildschirmfoto 2024-12-18 um 13.24.15.jpg

Bei Ceph sollte es kein Problem sein einen Node neuzustarten, jedoch muss dafür der Cluster redundant gebaut sein. Sonst besser alle VMs stoppen

Bildschirmfoto 2024-12-18 um 13.30.54.jpg

Bildschirmfoto 2024-12-18 um 13.33.21.jpg

Manuelle und automatische Snapshots

Manuelle Snapshots via GUI oder API werden mit dem passenden Datastoresnapshot ausgeführt, also ZFS, Ceph oder KVM

Bildschirmfoto 2024-12-18 um 13.36.44.jpg

Bei ZFS werden diese Zustände mitrepliziert und die Konfigurationsdatei um diesen Zustand erweitert

Bildschirmfoto 2024-12-18 um 13.37.17.jpg

Bildschirmfoto 2024-12-18 um 13.37.27.jpg

Bildschirmfoto 2024-12-18 um 13.37.32.jpg

Automatische Snapshots Monitoring und Management mit CV4PVE-Admin

kann eine sinnvolle Alternative zu zfs-auto-snapshot sein und ergänzt wichtige, fehlende Einblicke der PVE GUI

Bildschirmfoto 2024-12-18 um 13.38.57.jpg

Bildschirmfoto 2024-12-18 um 13.39.11.jpg

Bildschirmfoto 2024-12-18 um 13.40.57.jpg

Diese Anleitung scheint die sinnvollste, bitte auf eigene Maschine

Bildschirmfoto 2024-12-18 um 13.42.06.jpg

Bildschirmfoto 2024-12-18 um 13.45.00.jpg

Eigener PVE User plus gewünschte Rechte sind hier erklärt

Bildschirmfoto 2024-12-18 um 13.45.15.jpg

Bildschirmfoto 2024-12-18 um 13.45.28.jpg

Bildschirmfoto 2024-12-18 um 13.45.40.jpg

Bildschirmfoto 2024-12-18 um 13.45.52.jpg

Bildschirmfoto 2024-12-18 um 13.45.54.jpg

Bildschirmfoto 2024-12-18 um 13.46.13.jpg

Bildschirmfoto 2024-12-18 um 13.46.25.jpg

Bildschirmfoto 2024-12-18 um 13.47.36.jpg

Alle Replikationen mit Bordmitteln im Blick, nicht mehr jede VM muss aufgeklappt werden

Bildschirmfoto 2024-12-18 um 13.48.50.jpg

Automatische Snapshots können hier definiert werden, jedoch muss das Teil auf laufen

Bildschirmfoto 2024-12-18 um 13.51.18.jpg

Bildschirmfoto 2024-12-18 um 13.52.50.jpg

Bildschirmfoto 2024-12-18 um 13.53.32.jpg

Bildschirmfoto 2024-12-18 um 13.53.32.png

Bildschirmfoto 2024-12-18 um 13.53.50.jpg

ZFS Snapshots können via GUI nur einzeln zurückgerollt werden, hier ist Ceph im Vorteil

Bildschirmfoto 2024-12-18 um 13.53.50.png

Bildschirmfoto 2024-12-18 um 13.54.03.jpg

Bildschirmfoto 2024-12-18 um 13.54.03.png

Bildschirmfoto 2024-12-18 um 13.56.34.png

Replikation bricht nicht bei Rollback

Bildschirmfoto 2024-12-18 um 13.56.57.png

Proxmox kann von HW Raid, ZFS, BTRFS, jedoch nicht von Ceph booten

Den Ceph Zustand kann man nicht mit Check_MK Bordmitteln prüfen

Bildschirmfoto 2024-12-18 um 13.57.50.jpg

Datensicherung mit Proxmox Backup Server

Proxmox kann nativ erst mal nur eine Vollsicherung

Erst der Proxmox Backup Server bringt inkrementelle Backups und Management

Er kann auf einen bestehenden PVE installiert werden, alternativ auch als LXC

Bildschirmfoto 2024-12-18 um 14.03.19.jpg

Die Repos fehlen jedoch hier

Bildschirmfoto 2024-12-18 um 14.05.51.jpg

Bildschirmfoto 2024-12-18 um 14.06.08.png

Hier wäre aktuell Bookworm

Bildschirmfoto 2024-12-18 um 14.08.51.png

Bildschirmfoto 2024-12-18 um 14.09.02.png

Bildschirmfoto 2024-12-18 um 14.09.20.png

Zugriff in diesem Fall via PVE3 auf Port 8007 mit SSL

Bildschirmfoto 2024-12-18 um 14.09.48.jpg

Das Dateisystem könnte mit BTRFS, ZFS oder Ext4 bereitgestellt werden, wobei Ext4 keine Snapshots zum Absichern von Backups beherrscht, dafür 100% Platzausnutzung

Bildschirmfoto 2024-12-18 um 14.18.43.png

Bildschirmfoto 2024-12-18 um 14.19.30.jpg

Der Backupstore wird als Mountpoint bereitgestellt. SMB performt hier sehr schlecht

Root User plus Backupuser werden mit 2fa abgesichert!

Bildschirmfoto 2024-12-18 um 14.24.09.jpg

Bildschirmfoto 2024-12-18 um 14.24.13.jpg

Bildschirmfoto 2024-12-18 um 14.24.25.jpg

Bildschirmfoto 2024-12-18 um 14.24.32.jpg

Für die Sicherung benötigen wir einen Token auf den Backupuser

Bildschirmfoto 2024-12-18 um 14.24.45.jpg

Backup Benutzer und -Token benötigen die Berechtigung Datastore Backup

Bildschirmfoto 2024-12-18 um 14.25.28.jpg

Bildschirmfoto 2024-12-18 um 14.25.34.jpg

Bildschirmfoto 2024-12-18 um 14.25.44.jpg

Für den Datastore in PVE benötigen wir mehrere Parameter

Bildschirmfoto 2024-12-18 um 14.26.11.jpg

Oben den Datastorenamens seitens PVE, den Tokennamen wie sein Passwort.

Auf der Rechten Seite der Datastorename aus dem PBS und unten dessen Fingerabdruck, den wir auf der Startseite des PBS finden

Bildschirmfoto 2024-12-18 um 14.27.28.jpg

Danach taucht der Backupstore in jedem PVE auf, wenn gewünscht

Bildschirmfoto 2024-12-18 um 14.27.49.jpg

Achtung, das Bootvolume von PVE ist per Default auch als Backupstore definiert, weg damit!

Bildschirmfoto 2024-12-18 um 14.28.24.jpg

Bildschirmfoto 2024-12-18 um 14.28.30.jpg

Bildschirmfoto 2024-12-18 um 14.28.31.jpg

Erstes manuelles Backup zeigt den Dirty-Bitmap Status: created-new, was eine Vollsicherung bedeutet

Bildschirmfoto 2024-12-18 um 14.29.02.jpg

Bildschirmfoto 2024-12-18 um 14.29.19.jpg

Bildschirmfoto 2024-12-18 um 14.30.15.jpg

Die zweite Sicherung wird dann inkrementell durchgeführt, bis die VM gestoppt wird!!!

Bildschirmfoto 2024-12-18 um 14.30.40.jpg

Bildschirmfoto 2024-12-18 um 14.31.05.jpg

Löschen einer Sicherung ist gewollt nicht über PVE möglich, in PBS kann man das manuell durchführen oder automatisch.

Der Platz wird erst nach einem Prune lauf freigegeben!

Bildschirmfoto 2024-12-18 um 14.31.11.jpg

Bildschirmfoto 2024-12-18 um 14.31.34.jpg

Nach einem Reboot des Hosts oder Stoppen des Gasts wird wieder eine Vollsicherung durchgeführt, jedoch nur neue Chunks auf das Ziel geschrieben. Dadurch geht das auch noch relativ flott. Siehe die MB angaben unten bei der Sicherung

Bildschirmfoto 2024-12-18 um 14.32.32.jpg

Bildschirmfoto 2024-12-18 um 14.33.02.jpg

Für den automatischen Lauf immer VMs ausschliessen oder alles mitnehmen. Eine Auswahl der VMs führt zu Fehlern über die Zeit durch Unterlassung

Bildschirmfoto 2024-12-18 um 14.35.48.jpg

Die Retention, also das Aufräumen hier ist nicht sinnvoll, noch möglich

Bildschirmfoto 2024-12-18 um 14.36.48.jpg

In Prunejobs regelst Du die Aufhebezeiten und die Ausführung der Regel, was aber nur für die Auswahl relevant ist. Der Vorgang geht relativ schnell

Der Simulator von Proxmox hilft dabei

Bildschirmfoto 2024-12-18 um 14.37.41.jpg

Bildschirmfoto 2024-12-18 um 14.38.41.jpg

Bildschirmfoto 2024-12-18 um 14.38.50.jpg

Die Garbage Collection räumt dann alle Junks auf die in keinem Backup mehr benötigt werden.

Der Vorgang hat hohe Last und dauert, also bei Stilstand ausführen

Bildschirmfoto 2024-12-18 um 14.39.20.jpg

dBildschirmfoto 2024-12-18 um 14.40.54.jpg

Der Verify Job überprüft regelmässig die Vollständigkeit der Junks und die Integrität der Backups.  Der Erfolg wird in der Rechten Spalte in PVE und PBS angezeigt

Bildschirmfoto 2024-12-18 um 14.41.35.jpg

Bildschirmfoto 2024-12-18 um 14.41.55.jpg

Bildschirmfoto 2024-12-18 um 14.42.01.jpg

Optional Replikationskontrolle mit checkzfs von #Bashclub

Da unklar ist welcher Host gerade welche ZFS Maschine aktiv betreibt, bleibt uns nur den Vergleich aller Datastores gegeneinander.

Der Vorgang sollte nur ausgeführt werden wenn gerade keine Replikation läuf, sonst spuckt er Fehler

Bildschirmfoto 2024-12-18 um 14.59.16.jpg

Bildschirmfoto 2024-12-18 um 15.01.43 1.jpg

Bildschirmfoto 2024-12-18 um 15.01.43.jpg

Bildschirmfoto 2024-12-18 um 15.01.45.jpg

Für diesen Anwendungsfall ist eventuell CV4PVE einfacher, da es auch viele Teile vom Monitoring übernimmt

Bildschirmfoto 2024-12-18 um 15.17.28.jpg

Vielen Dank für Ihre Aufmerksamkeit

Christian-Peter Zengel (sysops.tv)

Resourcen

https://aow.de/books/ubersicht-des-projekts/page/prospekt - Unser aktueller Prospekt

https://aow.de - Linkliste zu allen Projekten

https://cloudistboese.de - Schulungsportal, alle Kurse können kostenfrei wiederholt werden. Kurse meist online, auch vor Ort

http://youtube.com/sysopstv - Livesendung Montags und Donnerstags gegen 17:15h, Donnerstags Stammtisch online

ZFS Grundlagen am Beispiel Proxmox VE(Stand Januar 2025)

Der Verfasser des Artikels, Christian-Peter Zengel, hat zum Zeitpunkt des Artikels ca 15 Jahre Erfahrung mit ZFS und Proxmox. Er betreibt aktuell ca 150 Systeme mit Proxmox und ZFS

Das Einsatzgebiet geht von Standaloneinstallation bis zu ca 10 Hosts im Cluster. Es ist keine Ceph Expertise vorhanden!

Dieser Dokumentation basiert auf diesem online Kurse von cloudistboese.de

21. + 23.01.2025 (13.00 Uhr bis 17.00 Uhr) - ZFS Grundlagen


ZFS ist die perfekte Grundlage für kleine und mittlere Systeme um gegen Ausfälle, Dummheit anderer und Erpressungstrojanern ideal aufgestellt zu sein.
In diesem Kurs erhalten sie Grundkenntnisse für Systeme wie Proxmox, TrueNAS oder ähnliche Systeme.

Der Fokus liegt auf der Technologie und der permanenten Sicherheit im Umgang mit Daten, Linux und dem Terminal.

Themen:

Nach diesem Kurs bist Du bei Ausfällen und Datenverlust vor dem Schlimmsten geschützt und in Minuten wieder produktiv!

https://de.wikipedia.org/wiki/ZFS_(Dateisystem)

https://www.proxmox.com/de/

https://cloudistboese.de

So erstellt Proxmox VE seinen ZFS Raid

zpool create -f -o cachefile=none -o ashift=12 rpool mirror disk1 disk2

Destruktives Anlegen (-f), kein automatisches Importieren beim Start (-o cachefile=none)
-o ashift=12 ist für 4k Festplatten, ashit=9 für 512e Disks, wobei man mit 12 nichts verkehrt macht
rpool ist der Name vom künftigen Pool, mirror der Raidlevel und die Disks wurden zweifelsfrei über Ihre ID definiert

Optionen für Raidlevel wären noch: ohne als Stripe, raidz, raidz2 oder raidz3, also Raid Level 5-7

 Bildschirmfoto 2025-01-21 um 13.41.23.jpg

Die ersten Zpool Manöver und die endlose Aktionsliste sieht man mit 

zpool history

Bildschirmfoto 2025-01-21 um 13.44.20.jpg

Manuelles Trimmen der SSDs um gelöscht Blöcke schner überschreiben zu können findet man unter /etc/cron.d
Ebenso wird nach diesem Zeitplan der sog. zpool scrub durchgeführt, der die Konsistenz der Redundanz prüft und ggf. korrigiert. Gefundene Fehler findet man dann mit zpool status

Bildschirmfoto 2025-01-21 um 13.47.45.jpg

Zum identifizieren der Platten bieten sich neben der PVE GUI noch folgende Befehle an. Es wird dringend empfohlen bereits genutzte Platten via PVE GUI zu wipen

dmesg -Tw (live)
lsblk
ls -althr /dev/disk/by-id

Bildschirmfoto 2025-01-21 um 13.50.01.jpg

Erstellen verschiedener Raidlevel und Ihrer Vorzüge

Mit ls -althr /dev/disk/by-id haben wir folgende Festplatten anhand ihrer aufgedruckten WWN Kennung identifiziert. Es ist dringend empfohlen bei HBAs sich die Slots und die Seriennummern beim Einbau zu notieren und in die Dokumentation aufzunehmen

wwn-0x5000cca01a72ded4 wwn-0x5000cca01a7b1e2c  wwn-0x5000cca01a83a61c wwn-0x5000cca01a832d24  wwn-0x5000cca01a83331c  wwn-0x5000cca01a7495b8  wwn-0x5000cca01a8417fc  

Stripe, also Raid0

zpool create -f test wwn-0x5000cca01a72ded4 wwn-0x5000cca01a7b1e2c  wwn-0x5000cca01a83a61c  wwn-0x5000cca01a832d24  wwn-0x5000cca01a83331c  wwn-0x5000cca01a7495b8

test                      ONLINE
 wwn-0x5000cca01a72ded4  ONLINE
 wwn-0x5000cca01a7b1e2c  ONLINE
 wwn-0x5000cca01a83a61c  ONLINE
 wwn-0x5000cca01a832d24  ONLINE
 wwn-0x5000cca01a83331c  ONLINE
 wwn-0x5000cca01a7495b8  ONLINE
 wwn-0x5000cca01a8417fc  ONLINE
Mirror, also Raid1

zpool create -f test mirror wwn-0x5000cca01a72ded4 wwn-0x5000cca01a7b1e2c

test
 mirror
   wwn-0x5000cca01a72ded4
   wwn-0x5000cca01a7b1e2c
Striped Mirror, also Raid10

zpool create -f test mirror wwn-0x5000cca01a72ded4 wwn-0x5000cca01a7b1e2c mirror  wwn-0x5000cca01a83a61c  wwn-0x5000cca01a832d24  mirror wwn-0x5000cca01a83331c  wwn-0x5000cca01a7495b8

test
 mirror
   wwn-0x5000cca01a72ded4
   wwn-0x5000cca01a7b1e2c
 mirror
   wwn-0x5000cca01a83a61c
   wwn-0x5000cca01a832d24
 mirror
   wwn-0x5000cca01a83331c
   wwn-0x5000cca01a7495b8
RaidZ, also Raid 5, Nettoplatz x-1

zpool create test raidz wwn-0x5000cca01a72ded4 wwn-0x5000cca01a7b1e2c  wwn-0x5000cca01a83a61c wwn-0x5000cca01a832d24  wwn-0x5000cca01a83331c  wwn-0x5000cca01a7495b8  wwn-0x5000cca01a8417fc  

test                        ONLINE       0     0     0
 raidz1-0                  ONLINE       0     0     0
   wwn-0x5000cca01a72ded4  ONLINE       0     0     0
   wwn-0x5000cca01a7b1e2c  ONLINE       0     0     0
   wwn-0x5000cca01a83a61c  ONLINE       0     0     0
   wwn-0x5000cca01a832d24  ONLINE       0     0     0
   wwn-0x5000cca01a83331c  ONLINE       0     0     0
   wwn-0x5000cca01a7495b8  ONLINE       0     0     0
   wwn-0x5000cca01a8417fc  ONLINE       0     0     0
RaidZ2, also Raid 6, Nettoplatz x-2

zpool create test raidz2 wwn-0x5000cca01a72ded4 wwn-0x5000cca01a7b1e2c  wwn-0x5000cca01a83a61c wwn-0x5000cca01a832d24  wwn-0x5000cca01a83331c  wwn-0x5000cca01a7495b8  wwn-0x5000cca01a8417fc  

 raidz2-0                  ONLINE       0     0     0
   wwn-0x5000cca01a72ded4  ONLINE       0     0     0
   wwn-0x5000cca01a7b1e2c  ONLINE       0     0     0
   wwn-0x5000cca01a83a61c  ONLINE       0     0     0
   wwn-0x5000cca01a832d24  ONLINE       0     0     0
   wwn-0x5000cca01a83331c  ONLINE       0     0     0
   wwn-0x5000cca01a7495b8  ONLINE       0     0     0
   wwn-0x5000cca01a8417fc  ONLINE       0     0     0

RaidZ-0, also Raid 5-0, Nettoplatz x-2, in diesem Beispiel

zpool create test raidz wwn-0x5000cca01a72ded4 wwn-0x5000cca01a7b1e2c  wwn-0x5000cca01a83a61c raidz wwn-0x5000cca01a832d24  wwn-0x5000cca01a83331c  wwn-0x5000cca01a7495b8  

 
test                        ONLINE       0     0     0
 raidz1-0                  ONLINE       0     0     0
   wwn-0x5000cca01a72ded4  ONLINE       0     0     0
   wwn-0x5000cca01a7b1e2c  ONLINE       0     0     0
   wwn-0x5000cca01a83a61c  ONLINE       0     0     0
 raidz1-1                  ONLINE       0     0     0
   wwn-0x5000cca01a832d24  ONLINE       0     0     0
   wwn-0x5000cca01a83331c  ONLINE       0     0     0
   wwn-0x5000cca01a7495b8  ONLINE       0     0     0
   wwn-0x5000cca01a8417fc  ONLINE       0     0     0

oder mit Spare, wenn Du davon nicht booten musst

zpool create test raidz wwn-0x5000cca01a72ded4 wwn-0x5000cca01a7b1e2c  wwn-0x5000cca01a83a61c raidz wwn-0x5000cca01a832d24  wwn-0x5000cca01a83331c  wwn-0x5000cca01a7495b8  spare wwn-0x5000cca01a8417fc

Erweiterung eines RaidZ zum RaidZ-0

test                        ONLINE       0     0     0
 raidz1-0                  ONLINE       0     0     0
   wwn-0x5000cca01a72ded4  ONLINE       0     0     0
   wwn-0x5000cca01a7b1e2c  ONLINE       0     0     0
   wwn-0x5000cca01a83a61c  ONLINE       0     0     0

zpool add -n test raidz wwn-0x5000cca01a832d24  wwn-0x5000cca01a83331c  wwn-0x5000cca01a7495b8

test
 raidz1-0
   wwn-0x5000cca01a72ded4
   wwn-0x5000cca01a7b1e2c
   wwn-0x5000cca01a83a61c
 raidz1
   wwn-0x5000cca01a832d24
   wwn-0x5000cca01a83331c
   wwn-0x5000cca01a7495b8

Erweiterung eines Raid durch Ersetzen mit größeren Platten

Die Platten müssen die Gleiche Geometrie hanben, also 4k zu 4k oder 512e zu 512e

Bei Raid 1 und 10 reicht es zwei Disks zu tauschen, bei RaidZx müssen alle Disks getauscht werden

Replace Vorgänge können auch laufen ohne die Redundanz zu brechen, wenn weitere Slots frei sind

Bei Erweiterung durch Austausch von großen und vor allem älteren Raid 10 prüfen ob in einem Mirror ggf. neue Platten getauscht wurden, diese sollten weiter im Betrieb bleiben, während ältere Paare getauscht werden können

rpool-hdd
 mirror-0
  2024-8T (vorher Disk aus 2014)
  2024-8T (vorher Disk aus 2014)
 mirror-1
  2014-2T
  2021-2T
 mirror-2
  2022-2T
  2014-2T

Caches und Logdevices

Vorsichtig formuloiert, Lese- und Schreibcache

First Level Cache, sog. ARC kommt aus dem RAM und bekommt idealerweise ca. 1GB für 1TB Nettodaten

Second Level Cache wird als Cachedevice als Partition auf einer schnelleren Disk als der Pool hat bereitgestellt, z. B. am idealsten mit NVMe

zpool add test -n cache sdl

test
 raidz2-0
   wwn-0x5000cca01a72ded4
   wwn-0x5000cca01a7b1e2c
   wwn-0x5000cca01a83a61c
   wwn-0x5000cca01a832d24
   wwn-0x5000cca01a83331c
   wwn-0x5000cca01a7495b8
   wwn-0x5000cca01a8417fc
cache
 sdl
Logdevice (Writecache muss gespiegelt werden)
Damit der Log auch genutzt wird muss man noch mit zfs set sync den cache aktivieren

zpool add test -n log mirror sdl 

zfs set sync=always test

test
 raidz2-0
   wwn-0x5000cca01a72ded4
   wwn-0x5000cca01a7b1e2c
   wwn-0x5000cca01a83a61c
   wwn-0x5000cca01a832d24
   wwn-0x5000cca01a83331c
   wwn-0x5000cca01a7495b8
   wwn-0x5000cca01a8417fc
logs
 mirror
   sdl
   sdk
Arc wird mit "arcstat 1" ausgelesen, er wird bei der Installation festgelegt oder später unter /etc/modprobe.d/zfs.conf geändert. update-initramfs -u macht das dann persistent und aktiviert die Änderungen beim nächsten reboot.
Zur Laufzeit ändert man den Firstlevelcahce mit 
Cache- und Logdevices mit zpool iostat 1

echo 2147483648 > /sys/module/zfs/parameters/zfs_arc_max
echo 1073741824 > /sys/module/zfs/parameters/zfs_arc_min
free -h && sync && echo 3 > /proc/sys/vm/drop_caches && free -h

arcstat 1

Bildschirmfoto 2025-01-21 um 15.15.59.jpg

Test der Leistung eines Pools

zfs create -o compression=off test/speed
cd /test/speed
dd if=/dev/zero of=dd.tmp bs=256k count=16384 status=progress
dd if=/dev/zero of=dd.tmp bs=2M count=16384 status=progress

Bildschirmfoto 2025-01-21 um 15.30.20.jpg

Bildschirmfoto 2025-01-21 um 15.31.09.jpg

Erweiterung der Funktionen des Pools

zpool status meldet neue Funktionen im ZFS und kann leicht und schnell mit

zpool upgrade -a

erledigt werden

Jedoch würde ich in jedem Fall empfehlen zu prüfen ob meine Notfall ISO diese Funktionen bereits unterstützt!

Bildschirmfoto 2025-01-21 um 15.59.16.jpg

Bildschirmfoto 2025-01-21 um 15.59.26.jpg

Für das Auslesen der Parameter von Pools, Volumes, Datasets und Snapshots gibt es den Parameter get

 

Bildschirmfoto 2025-01-21 um 16.00.49.jpg

Bereitstellen und entfernen von Pools ohne löschen

zpool import #zeigt was es zum importieren, also bereitstellen gibt

zpool import poolname oder -a für alle importiert den Pool oder alle verfügbaren Pools

Am elegantesten importiert man den Pool über

zpool import -d /dev/disk/by-id

damit man hinterher nicht sda, sdb, sondern die Bezeichner im Status sieht

Bildschirmfoto 2025-01-21 um 16.12.48.jpg

Nach der Bereitstellung würde man hier lediglich einen Mountpoint /test finden, bei TrueNAS /mnt/test. Dazu noch die Systemdatasets vom Proxmox selbst. Danach legen wir gleich mal ein Dataset namens dateisystem und ein Volume namens volume an.

Bildschirmfoto 2025-01-21 um 16.27.43.jpg

Datasets werden als Ordner gemountet und / oder /mnt

Volumes findet man unter /dev/zd... und zusätzlich mit vernünftigen Namen unter /dev/zvol/tankname/....

Bildschirmfoto 2025-01-21 um 16.28.41.jpg

Datasets werden mit Linuxcontainern, Backupfiles, Vorlagen oder Serverdateien bespielt

Volumes verhalten sich wie eingebaute Datenträger, jedoch virtuell. Sie stehen nach dem Import des Pools bereit und können in einer VM genutzt werden. Manipulationen an Volumes zur Vorbereitung oder Datenrettung können jedoch ebenso auf dem PVE Host vorgenommen werden

Diese Schritte übernimmt üblicherweise der Installer in der VM und sollen nur aufzeigen wie diese ZVOLs genutzt werden

Bildschirmfoto 2025-01-21 um 16.42.58.jpg

Bildschirmfoto 2025-01-21 um 16.43.33.jpg

Bildschirmfoto 2025-01-21 um 16.48.11.jpg

Bildschirmfoto 2025-01-21 um 16.48.19.jpg

Proxmox legt seine Datasets für LXC so ab

Bildschirmfoto 2025-01-21 um 16.52.46.jpg

und so die ZVOLs für VMs mit KVM, hier findet man die virtuellen Disk und /dev/zvol...

Bildschirmfoto 2025-01-21 um 16.51.58.jpg

Thin- und Thickprovisioning für Datasets und Volumes

Am Beispiel von Proxmox VE via GUI wird hier eine Thinprovision Festplatte für VM 301 mit 32GB und einer Standardblockgröße von 16k erzeugt. 8k sind nur bei Raid1 und 10 möglich. Hakt man den Thinprovision Haken nicht an, wird beim Erzeugen noch die Option -o refreservation=32G ergänzt. Diese macht bei ZFS mit Autosnapshots aber keinen Sinn

zfs create -s -b 16k -V 33554432k rpool/data/vm-301-disk-4

rpool/data/vm-301-disk-4                                  56K  1.17T    56K  - #hier kein Mount sonder unter /dev/zvol/...

Bei LXC werden Datasets genutzt und der Platz via Reservierung genutzt, wobei bei der genutzten Refquota auch die Snapshotaufhebezeiten den Nettoplatz verkleinern, daher größer dimensionieren, gerne mal doppelt so groß

 zfs create -o acltype=posixacl -o xattr=sa -o refquota=33554432k rpool/data/subvol-106-disk-1

rpool/data/subvol-106-disk-1                              96K  32.0G    96K  /rpool/data/subvol-106-disk-1 #hostzugriff möglich

Virtuelle Diskimages wie QCOW2, VMDK oder RAW-Dateien legt man üblicherweise nicht in Datasets, bestenfalls für NFS oder iSCSI Server

Snapshots

Snapshots können jederzeit erstellt oder gelöscht werden. Die Datasets und Volumes befinden sich immer in einem Livezustand der sich durch die Vektorkette der eventuell vorhandenen Snapshots ergibt. Entfernt man einen Snapshot, so verändert sich der Weg der Vektoren. Das Ganze geschieht fast ohne Last!

ZFS selbst bringt weder Workflows für Snapshotting, noch Replikationen mit. Es stellt nur die Werkzeuge bereit

Snapshots generiert man bei Proxmox offiziell mit der GUI manuell oder für Replikationen, jedoch leistet dieser Workflow nicht genug.

Daher nutzen wir...

apt install zfs-auto-snapshot -y

ZFS-AUTO-SNAPSHOT legt seine Verknüpfungen in alle Cronordner. Proxmox VE weiß erst mal nichts davon. Zu berücksichtigen ist hier lediglich daß wir den Pool nicht über 80% befüllen wollen. Gehen wir darüber hinaus, müssen wir in den Cronordnern die Verknüpfungen anpassen um die Aufhebezeiten zu reduzieren.

nano /etc/crontab #kann angepasst werden, die viertelstündlichen finden sich unter cron.d!

# .---------------- minute (0 - 59)
# |  .------------- hour (0 - 23)
# |  |  .---------- day of month (1 - 31)
# |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
# |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# |  |  |  |  |
# *  *  *  *  * user-name command to be executed
17 * * * * root cd / && run-parts --report /etc/cron.hourly
25 6 * * * root test -x /usr/sbin/anacron || { cd / && run-parts --report /etc/cron.daily; }
47 6 * * 7 root test -x /usr/sbin/anacron || { cd / && run-parts --report /etc/cron.weekly; }
52 6 1 * * root test -x /usr/sbin/anacron || { cd / && run-parts --report /etc/cron.monthly; }

cat /etc/cron.hourly/zfs-auto-snapshot 

exec zfs-auto-snapshot --quiet --syslog --label=hourly --keep=96 // #also in dem Fall 96 Stunden

Wir empfehlen für den Start folgende Settings: Drei Monate, sechs Wochen, zehn Tage, 96h und 12 Viertelstunden

Damit kommt man auf ca. 2,5x- 3x so viele Daten wie belegt wären ohne Snapshots. Erfahrungswert.

Das wären pro virtueller Disk oder LXC Mountpoint etwa 127 Snaphots, bei 20 Disks über 2540. 

Nicht davon abschrecken lassen, es geht auch easy fünfstellig, wenn die IO stimmt!

Die in PVE eingebaute Snapshotfunktion sollte nicht mit den Autosnapshots kombiniert werden. 

Im Problemfall stoppen wir die VM, manipulieren was zu machen ist und starten sie wieder!

Der eigentliche Vorteil der Snapshots in der GUI ist die Notierung der VM Definition zur Zeit der Erstellung, was wir über ein Backup im hauseigenen Postinstaller kompensieren. Dort findet man die Historie der PVE Config

Bildschirmfoto 2025-01-23 um 14.29.16.jpg

Kleines manuelles Beispiel, was für uns aber Z-A-S übernimmt

 

Snapshot

zfs snapshot tank/sub/datasetodervolume@snapshotname

Auflisten

zfs list -t snapshot tank/sub/datasetodervolume

VM oder LXC ausmachen

Rollback 

zfs rollback -r rpool/data/vm-100-disk-0@Test #danach ist alles neuere weg!  

VM oder LXC starten

Dynamik von Snapshots

Wir unterscheiden zwei Sorten von Datennutzung

Dynamik von Snapshots

Dank ZFS kann man langfristig Replikationen inkrementell vornehmen, jedoch dauert die erste Replikation natürlich länger, wenn schon Datenbestand da war

Übliche Vorgehensweise einer Datenübertragung

PC NTFS>SMB> Datei > SAMBA Server BTRFS LVM > EXT4 Datei = Konsistent? Bitrod?

Zu viele Köche verderben die Köchin

Funktion von Snapshotreplikation

Von ZFS zu Datei, was wenig Praxis findet

zfs send tank/dataset@snapshot > datei.zfs

zfs recv tank < datei.zfs

Von ZFS zu ZFS, was üblich ist

zfs send | zfs recv #laufen immer gleichzeitig

zfs send rpool/data/vm-100-disk-0@Test | zfs recv -dvF backuptank  
#überträgt den Zustand Test auf ein lokalen weiteren Pool, wobei das zfs Tool immer doppelt läuft

Pushreplikation

zfs send -pvwRI rpool/data/vm-100-disk-0@Test rpool/data/vm-100-disk-0@zfs-auto-snap_hourly-2025-01-23-1317 | zfs recv -dvF backuptank 
#Fortschritt, Infos, Rohdaten plus Historie, ideal für verschlüsselte Volumes, erspart das De- und Komprimieren

Workflow

Trojanerproblem: Wer auf Quelle sitzt kann Pushziele löschen

Lösung: Pullreplikation, ähnlich Backupsoftware, Transport SSH, Daten ZFS
Quelle |> Pullserver

zfs recv | ssh root@quelle zfs send #Pull Replikation via SSH

Von PVE zu PVE, was uns zu wenig ist

Bildschirmfoto 2025-01-23 um 16.26.18.jpg

Bildschirmfoto 2025-01-23 um 16.26.33.jpg

Bildschirmfoto 2025-01-23 um 16.26.37.jpg

Proxmox baut selbst keine Notfallpunkte auf und nutzt ZFS nur als Transport, nimmt jedoch manuelle und automatisierte Snapshots mit, auch von Z-A-S!

Weitere Kopien per ZFS sind nur per Pushverfahren möglich, was ideal für Angreifer ist wenn sie alles löschen möchten. Ein Backupserver ist hier unverzichtbar, bei Pullreplikation gehts ggf. auch ohne. Außer Haus ist es nicht möglich ein ZFS Replikat zu senden, da sich der Partner im lokalen Cluster befinden muss!

Nondestruktiver Rollback nach Trojanerbefallt bei Forensikbedarf

OPNsense Migration Legacy zu Instance, ohne neues Ausrollen von Konfigurationen

Sicher habt ihr schon die Meldung der OPNsense Firewall unter OpenVPN / Legacy gesehen

Die Migration zur Instanz ist nicht sonderlich kompliziert, jedoch gibt es zwei Fallstricke.

  1. Deaktiviert den alten Server
  2. Falls Shared Key verwendet wurde, unter Static Key diesen Text übernehmen, Mode Auth
  3. Konfiguriert eure neue Instanz mit mindestens diesen Einstellungen
    1. Role: Server
    2. Enabled: yes
    3. Port Number: wie bisher, z. B. 1194
    4. Type: TUN
    5. Server IP: Hier den alten Wert von IPv4 Tunnel Network übernehmen, z. B. 172.16.1.0/24
    6. Toplolgy: subnet
    7. Certificate: hier den alten Eintrag von Server Certificate übernehmen
    8. Certificate Authority: hier den alten Eintrag von Peer Certificate Authority übernehmen
    9. Dann links oben Advanced Mode einblenden
    10. Unter TLS static key den vorher angelegten Key auswählen
    11. Auth: den alten Wert von Auth Digest Algorithm übernehmen, z. B. SHA256
    12. Autentication: den vorherigen Serveranbieten, z. B. DC, UCS, Zamba auswählen, wenn vorhanden
    13. Renegotiate Time: 3600
    14. Auth Token Lifetime: 43200
    15. Local Network: den alten Wert von IPv4 Local Network auswählen
    16. Falls vorher bei Compression etwas ausgewählt war, selbst Disabled, dann Compression migrate unter Advanced anklicken
    17. Weitere Parameter falls benötigt

Der technische Stand dieser Dokumentation ist von April 2025 und funktioniert mit der Version OPNsense 25.1.4_1-amd64.

Die Business Edition 24.10 verfügt noch nicht über den Compression Migrate. Daher muss die Version Business 25.x abgewartet werden!

Beispiel

image.png

cz


Backup und Replikation trojanersicher für Proxmox VE mit Miyagi Workflow

Was wir uns Wünschen

Für eine Datensicherung wünschen wir uns drei Kopien der Daten an mindestens zwei Standorten, mit zwei Methoden. 
Zusätzlich ist die Kontrolle ohne Fehlerquote ein Muss!

Unsere Lösung erzeugt auf einem oder mehreren Systemen

  1. Natives Proxmox Backup ohne Löschmöglichkeit auf der Quelle (Restoreversprechen)
  2. Natives ZFS Replikat (Restoregarantie)
  3. Lückenloses Monitoring ohne Fehlerquote oder Aufwand
  4. Serialisierung der Sicherungen für bessere Leistung
  5. Automatisierung von Updates, Backupwartung und -verifizierung und Herunterfahren des Sicherungsservers
  6. Zentrales Dashboard für Funktion und Sicherung aller Systeme

  7. Schnelle Wiederherstellung durch Proxmox Backupserver oder Starten von replizierten Systemen

Als Ergebnis finden wir eine Backuphistorie für mehrere Monate bis Jahre und Replikate von ca. 14 Tagen bis drei Monate

image.png

# Auf dem Zielserver sollte das dann so aussehen

# Unsere Proxmox Backups mit fünf Tagen Snapshot gegen Kompromittierung
zfs list
rpool/pbsstore                    4.9T  30.4T  4.62T  /rpool/pbsstore 

#PVE mit LXC Container
rpool/repl/lwpve2/rpool/data/subvol-100-disk-0    168G  34.8G   165G  /rpool/repl/lwpve2/rpool/data/subvol-100-disk-0
rpool/repl/lwpve2/rpool/data/subvol-102-disk-0    918M  31.1G   872M  /rpool/repl/lwpve2/rpool/data/subvol-102-disk-0
#PVE mit KVM 
rpool/repl/lwpve3/rpool3/data/vm-301-disk-0       267K  41.0T   169K  - (finden sich unter /dev/zvol/rpool....)
rpool/repl/lwpve3/rpool3/data/vm-301-disk-1      40.6G  41.0T  26.7G  - (finden sich unter /dev/zvol/rpool....)
rpool/repl/lwpve3/rpool3/data/vm-301-disk-2       277G  41.0T   214G  - (finden sich unter /dev/zvol/rpool....)

Die Backups benötigen für die Wiederherstellung den Zeitpunkt, den Platz und Zeit, während die ZFS Replikate sofort Startfähig sind und in Potenter Hardware produktiv gehen können.

Die Aufhebezeiten für Backups und Replikaten können selbst festgelegt werden.

Überlegungen zu Proxmox VE

Proxmox VE ist primär nur ein überschaubares Frontend für KVM und LXC Virtualisierung.

Es ist natürlich denkbar alte VMware- und HyperV Lösungen auf Proxmox umzustellen.

Nutzt man Proxmox mit Hardware Raid oder SAN, verliert man im Vergleich zu den kommerziellen Lösungen eine Menge Komfort.

Natürlich ist die Hochverfügbarkeit und das schlanke Design ein Gewinn im Vergleich zu den kostenintensiven Lösungen des Mittbewerbs.

Proxmox lebt vor allem durch die im Hintergrund integrierten Lösungen KVM, LXC, SDN und vor allem ZFS und Ceph.

ZFS und Ceph schicken Hardware Raids und SANs auf die Ersatzbank und sind nunmehr oft obsolet.

Lösungen mit Ceph werden primär eingesetzt wenn im Härtefall kein Bit Daten verloren gehen darf, was allerdings mit einem vier- bis sechsfachen Kostenaufwand einhergeht.

Mit ZFS erreicht man realistisch eine Sicherung unter fünf Minuten oder besser, wenn notwendig. Nur weil bei einem Server das Licht ausgeht, sind noch lange die Daten nicht weg!!!

Bei eher nicht zu erwartenden Problemen mit einem Ceph Cluster müsste man eventuell von vorne starten.

Kleinere Installationen von ca. ein bis drei Proxmox Servern sollten daher mit ZFS installiert und untereinander repliziert werden.

Die Replikation mit Bordmitteln sieht jedoch nur den Transport und keine Historie der Systeme vor.

Da heutzutage SSDs und Festplatten nicht mehr von vorne bis hinten beschrieben werden, sondern zufällig, macht es Sinn die komplette Lebenszeit den kompletten Platz auszunutzen.

Von Dummheit, Fahrlässigkeit bis zum Trojaner

Vor Umstellungen und Maßnahmen führt der Admin üblicherweise einen Snapshot aus. Gerade VMware ist die absolut im Nachteil gegen die meisten Systeme, da Konsolidierung der Snapshots nach Tagen schon den Betrieb lahmlegen kann. Daher ist eine hohe Anzahl von Snapshots im HyperV und VMware keine Option.

Hier kommt ZFS ins Spiel.

Durch die auf Vektoren basierende Arbeitsweise von ZFS sind permanente Snapshots kein Nachteil für den Betrieb.

Wir empfehlen folgende Vorgehensweise.

Installation einer Snapshot Engine wie zfs-auto-snapshot oder CV4PVE (Web GUI für PVE)

Alle Programme inklusive Proxmox VE erstellen dieselbe Qualität an Snapshots, wobei zfs-auto-snapshot von Proxmox unentdeckt arbeitet.

Hierbei ist nur zu beachten, dass das System nicht über 80% belegt wird. Für den Fall der Überlastung können wir die Aufhebezeiten reduzieren.

Unser Vorschlag belegt üblicherweise ca. 2,5 mal so viel Platz wie die Nutzdaten.

Hier die optimalen Einstellungen aus unserer Praxis:

Für alles über drei Monate nutzen wir die tägliche Sicherung mit Proxmox Backup Server

Proxmox Backupserver Segen und Fluch

Proxmox Backup Server ist ein ideales Sicherungswerkzeug für virtuelle Maschinen und Linux Container auf Proxmox VE.

Das Design sieht vor daß hier Sicherungen von Proxmox VE nach Proxmox Backupserver geschoben werden, was Raum für Trojaner und Hacker bietet.

Es ist extrem wichtig, dem Backupuser im Server einen API Key bereitzustellen, der nur Sicherungs- und Widerherstellungsrechte besitzt.

Zwei Faktor Login, so wie die Deaktivierung des SSH Logins per Passwort sind absolut notwendig!

Der Backupserver kann nicht wissen wann ein Proxmox VE System seine Sicherung anliefert. Daher muss er permanent laufen.

Selbst ein Anschalten des Backupservers vor der geplanten Sicherung erlaubt ein Herunterfahren nach der Sicherung nicht, da es technisch nicht vorgesehen ist.

Ebenfalls ist das Monitoring der Backups nicht vorgesehen und mit Zabbix oder Check_MK nur mühselig einzurichten.

Die Mailbenachrichtigung ist unzureichend bis unbrauchbar. Ebenfalls fehlt ein  Dashboard für Backup, Festplattenzustand oder Raid-Probleme.

Wir benötigen einen weiteren Computer, an einem anderen Ort, mit zwei weiteren Kopien in zwei Methoden der Sicherung 

Proxmox VE bietet die Möglichkeit nativ mit dem Backupserver zu sichern und mit ZFS ein startfähiges Replikat nativ zu erstellen.

Backups bieten hier ein Wiederherstellungsversprechen, während ZFS eine Wiederherstellungsgarantie bietet

Voraussetzungen für den Miyagi Workflow
Installation Proxmox Backup und Einstellungen

Achtung: Proxmox VE hat als default den Store "local" auf Typ Backup stehen, dringend deaktivieren!

Installation Miyagi

Migration Univention Corporate Server & Kopano nach Zamba AD & Mailcow

Nachdem viele kleinere Kunden nur den Domaincontroller benötigen, jedoch UCS + Kopano für den Betrieb nutzen, kann UCS bei vielen Kunden nun ersetzt werden.
Das Upgrade auf UCS 5.2 zeigt erneut, dass sich der Aufwand eines Upgrades nicht mehr mit dem Nutzen eines Domaincontrollers rechnet.

Updates von Mailcow und Zamba AD Controller laufen künftig in wenigen Minuten, nicht mehrere Stunden

Kunden die Keycloak und eine supportete Umgebung wünschen bleiben bitte bei Univention!!!

Entsprechende Kurse finden Sie auf cloudistboese.de unter Mailcow und Domaincoltroller ablösen!

Systemvoraussetzungen

Installation zweiter Domaincontroller

Installation auf Proxmox im z. B. /root Ordner

git clone -b dev https://github.com/bashclub/zamba-lxc-toolbox

cd zamba-lxc-toolbox

cp conf/zamba.conf.example conf/zamba.conf

In der zamba.conf folgende Parameter an das System anpassen

LXC_TEMPLATE_STORAGE="local" #LXC Template Store
LXC_ROOTFS_SIZE="32" #DCs Root Size
LXC_ROOTFS_STORAGE="rpool-data" #or local-zfs #DCs Root Store
LXC_SHAREFS_SIZE="100" #DCs Root Backup Size
LXC_SHAREFS_STORAGE="rpool-data" #or local-zfs #DCs Backup Store
LXC_HOSTNAME="zmb-ad"
LXC_DOMAIN="windomain.local"
LXC_IP="10.0.0.254/24"
LXC_GW="10.0.0.1"
LXC_DNS="10.0.0.4" #your old UCS IP, If Windows Step Down to Level 2008R2 first!
LXC_BRIDGE="vmbr0"
LXC_PWD='Admin123'
ZMB_REALM="WINDOMAIN.LOCAL"
ZMB_DOMAIN="WINDOMAIN"
ZMB_ADMIN_USER="administrator"
ZMB_ADMIN_PASS='Admin123'

Die installation des LXCs als zweiten DC starten wir mit

bash install.sh -i 100 #für Container 100

Im Menü wählen wir Zamba-AD-Join

Nach der Installation können wir in den Container gelangen mit

pct enter 100

su -

wbinfo -u 

wbinfo -g

Dort Finden wir im Idealfall alle User und Gruppen, was den Erfolg bestätigt

Folgende Anpassung in der smb.conf macht das Leben leichter

vi /etc/samba/smb.conf

[global]

ldap server require strong auth = no

dns forwarder = 1.1.1.1 1.0.0.1

It was DNS

An dieser Stelle erhalten alle Computer mit festen IPs den neuen DNS-Server, der alte DNS Server vom UCS kann jetzt raus.

Im DHCP Server ersetzen wir ebenfalls den DNS Server mit dem neuen DC, der alte DNS Server vom UCS kann raus

Installation Mailcow

vi conf/zamba.conf.example conf/zamba.conf

Die Installation der Mailcow benötigt keine spezielle Anpassung im unteren Bereich außer dem LXC_HOSTNAME und den Netzwerkeinstellungen

bash install.sh -i 101 #für Container 101

Im Menü wählen wir Mailcow

Nach der Installation von Mailcow

pct enter 100

su -

cd /opt/mailcow-dockerized

./update.sh

Danach rufen wir das Mailcow Webinterface mit der Admin Seite auf

https://10.0.0.253/admin

Folgende Schritte sind unerlässlich

pct enter 100

su -

cd /opt/mailcow-dockerized

docker compose down

# Optional bei PMG Einsatz greylisting aus
# vi /opt/mailcow-dockerized/data/conf/rspamd/local.d/greylist.conf
# enabled = false;

docker compose up -d

Abschluss der Arbeiten
Proxmox Mail Gateway
Mailpiler
Dubletten bei mehrfachem Kopano Sync

Leider ist die IMAP Kompatibilität bei Kopano eher auf der niedrigen Seite.

Finden sich etliche Mails offensichtlich doppelt oder dreifach, führt man den zweiten Befehlt auf der Kopanoseite mehrfach aus.

apt install kopano-migration-imap #identisch imapsync

kopano-migration-imap --delete2duplicates --host1 mailcowhost --host2 10.0.0.8 --user1 user@domain.de --password1 mailcowpassword --user2 user@domain.de --password2 mailcowpassword --ssl1 --ssl2 --dry # dry für Vorabtest

Virtuelle Maschine mit Windows 10 Bios auf Proxmox zu Windows 11 mit UEFI umstellen

Windows 11 Migration Bios zu UEFI

Win11 Upgrade BIOS -> UEFI ist keine einfache Aufgabe
Auch wenn es Workarounds gibt, möchten wir für virtuelle Windows 11 Maschinen die maximale Lebensspanne an Upgrades. Daher passen wir das System im Bereich Partitionstabelle, TPM und virtuelle Hardware an

Systemplatte erweitern

In Proxmox großzügig die Platte, wenn Thin Provisioning aktiviert ist, erweitern.

Danach die Partition in Windows vergrößern, da wir am Ende Platz für eine EFI Partition benötigen!

BCD neu schreiben

bcdboot c:\windows /s c: /f all

Win Part als aktiv markieren

diskpart
select disk 0
select part 2
active

Disk zu GPT konvertieren

mbr2gpt.exe /convert /allowFullOS /disk:0

VM Shutdown und neu konfigurieren

image.png

VM einschalten

Shutdown

VM Starten

Stand der Technik nach DSGVO am Beispiel Kopano - Was sagt ChatGPT?

Auf Nachfrage interessierte mich die Meinung von ChatGPT zum Thema Übergangsfristen für abgelaufene Software, wie z. B. Kopano u. Ä. Nicht immer schafft man rechtzeitig die Migration auf aktuelle Systeme, meist wegen der Absprachen und Termin- und Kostengespräche mit Kunden

Nach der Datenschutz-Grundverordnung (DSGVO) gibt es keine ausdrücklichen Übergangsfristen für die Pflicht, Serversoftware auf dem Stand der Technik zu halten. Die Verordnung trat am 25. Mai 2018 in Kraft und gilt seither unmittelbar in allen EU-Mitgliedstaaten.

Was bedeutet "Stand der Technik" laut DSGVO?

Die DSGVO verlangt in Art. 32 Abs. 1 von Verantwortlichen und Auftragsverarbeitern geeignete technische und organisatorische Maßnahmen, um ein dem Risiko angemessenes Schutzniveau zu gewährleisten. Dabei ist „der Stand der Technik“ ein zentrales Kriterium.

Das bedeutet konkret:

Gibt es trotzdem Spielräume oder Fristen?

Zwar gibt es keine festen Fristen in der DSGVO, aber:

Beispiele:

Software Stand der Technik? Kommentar
Ubuntu 20.04 Ja (bis 2025) Unterstützt, wenn regelmäßig aktualisiert
Windows Server 2012 R2 Nein (EOL) Nicht mehr sicher, nicht DSGVO-konform
Apache 2.2 Nein Veraltet, seit Jahren nicht mehr unterstützt
Nextcloud (aktuelle LTS-Version) Ja Regelmäßige Updates, DSGVO-konform

Fazit:

Wenn du willst, kann ich dir eine Checkliste zur DSGVO-konformen Server-Softwarepflege erstellen.

 

Das Problem mit Kopano Groupware unter Univention Corporate Server (UCS) 5.0 liegt mittelfristig vor allem beim Thema "Stand der Technik" im Sinne der DSGVO – insbesondere in Bezug auf:

🔧 1. Veraltete Softwarebasis von Kopano

➡️ Risiko: Wenn Sicherheitslücken bekannt werden und keine Updates folgen, ist der „Stand der Technik“ nicht mehr gegeben.

📦 2. Eingeschränkte oder fehlende Wartung im UCS App Center

➡️ Risiko: Kein garantierter Support, keine klare Roadmap, und Integration in UCS nur noch teilweise gepflegt.

🔒 3. Unklare Sicherheitsgarantie & Datenschutzfolgeabschätzung

➡️ Risiko: Du trägst die volle Haftung bei Datenpannen – auch wenn die Ursache eine nicht gewartete Drittsoftware ist.

📆 4. Abhängigkeit von veralteten Komponenten

➡️ Risiko: Du bleibst auf alten Softwareständen – was DSGVO-widrig ist.

✅ Fazit: Wo ist mittelfristig das Problem?

Bereich Risiko DSGVO-Auswirkung
Sicherheitspatches fehlen Hoch Kein „Stand der Technik“
Keine Updates über App Center Mittel Wartung erschwert
Keine klare Produkt-Roadmap Hoch Planbarkeit & DSFA unmöglich
Technische Abhängigkeiten Mittel bis hoch Zunehmende Inkompatibilität

🔄 Empfehlung

Wenn du Kopano (noch) nutzt:

Wenn du möchtest, kann ich dir eine Migrations-Checkliste oder Alternativen zu Kopano unter UCS zusammenstellen.