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!
DaDieser 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+
Nach diesem Kurs kannst Du Proxmox im Cluster sicher und Replikationeinfach nutzt, haben wir eine riesige Fülle an Werkzeugen und Arbeitsweisen entwickelt um davon zu profitieren.betreiben.
Dort
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!
Login Realm ist Linux User oder Proxmox Userbasis
Es können in der GUI keine weiteren Linux/PAM User angelegt werden, jedoch GUI aktiviert
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