Proxmox Basis Setup für ZFS und / oder Ceph im Cluster

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