Proxmox Basis 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!

Da Proxmox VE zwar ZFS an Bord hat, es aber nur für Migration und Replikation nutzt, haben wir eine riesige Fülle an Werkzeugen und Arbeitsweisen entwickelt um davon zu profitieren.

Diese Informationen erhalten sie auf dem YouTube Kanal von sysops.tv oder als strukturierte Kurse auf cloudistbösen.de

Dort erhalten Sie alle Informationen zum Betrieb und Migration zu Proxmox und alle Werkzeuge im Windows oder kommerzielle Firewalls abzulösen.

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

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

Cluster mit drei PVE erstellen

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

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

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

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

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!

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

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

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

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

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!

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!

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

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

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

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

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!

Linux unterstützt alle Virtio Laufwerke und Netzwerkkarten nativ

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

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

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

Ceph OSD Einrichtung

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!

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!

Klonen zwischen ZFS und Ceph

Proxmox kann mit Bordmitteln die meisten Formate konvertieren.

Qemu-Guest-Agent Installation

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

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

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

Weitere User benötigen entsprechende Rechte!

SSH Daemon gegen Passwort Login absichern

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

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

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

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

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!

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

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

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

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

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!

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

Manuelle und automatische Snapshots

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

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

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

Diese Anleitung scheint die sinnvollste, bitte auf eigene Maschine

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

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

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

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

Replikation bricht nicht bei Rollback

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

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

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

Die Repos fehlen jedoch hier

Hier wäre aktuell Bookworm

Zugriff in diesem Fall via PVE3 auf Port 8007 mit SSL

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

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

Root User plus Backupuser werden mit 2fa abgesichert!

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

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

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

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

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

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

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

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

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!

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

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

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

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

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

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

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

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

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