Proxmox VE Geschichte | Cluster-Node tot

Ok, das war knapp.

Hier kommt eine Geschichte, von deren gutem Ende ich einigermaßen überrascht bin. Auch mal wieder überrascht darüber, wieviel man in kurzer Zeit zu lernen imstande ist, wenn man sich blind auf seine jahrelange Erfahrung in der IT verlässt und dabei ordentlich ins Klo greift. Offenbar steigt mit zunehmender Erfahrung auch die Gefahr, leichtsinnig zu werden.

Aber:

"Wer andauernd begreift, was er tut, bleibt unter seinem Niveau." - Martin Walser

Wie berichtet und hier zu überprüfen, betreibe ich seit einigen Monaten ein Cluster aus Proxmox VE-Nodes, auf denen zahlreiche Dienste in Docker-Containern laufen. Ganz nach der Auffassung, dass meine Daten so nah wie möglich bei mir sein sollten, gehe ich den Weg des Self-Hostings wo immer es möglich und sinnvoll ist.

So entstand über die Zeit im Homelab ein Hypervisor-Cluster aus 4 Nodes und ebenso vielen lokalen Docker-Instanzen, die, zusammen mit zwei Oracle-Cloud-Instanzen, zu einem Environment zusammengefasst sind. Node "pve" schalte ich nur bei Bedarf per WOL hinzu. (Intel Xeon, 12-Kerne, stromdurstig)

Lokale Proxmox-Nodes Cluster-Resources

Soweit so gut.

Da in diesem Cluster mittlerweile neben Credentials (PW-Safe), sämtliche persönliche Daten (Private-Cloud) sowie die Infrastruktur für das papierlose Büro (DMS "Paperless") liegen, nutze ich zur Datensicherung einen virtualisierten Proxmox Backup Server (PBS) mit zusätzlicher Synchronisierung auf einen zweiten PBS, der sich ein einem anderen Brandabschnitt (Kriechkeller) befindet. Mein Konzept umfasst monatliche, wöchentliche, tägliche und stündliche Snapshots mit unterschiedlicher Retention (Vorhaltedauer).

Diese Backup-Daten brauchen Platz. Und daher weht der Wind dieser ganzen Geschichte.

Der bisherige, primäre PBS (Node "pve"), ist eine alte Fujitsu Celsius Workstation mit 12-Kern Xeon und HDDs. Dieser ist zwar extrem zuverlässig, aber eben auch extrem stromdurstig... Mein Plan ist nun, einen der aktuell für ca. 35,00 EUR zu bekommenden Fujitsu Futro S920 Thin-Clients auf wirtschaftlich maximalen Speicherplatz (All-Flash) auszubauen, der so aussehen sollte.

DriveInterfaceSizePurpose
DogfishmSATA256GBBoot-Drive
SandiskSATA2TBData-Drive
WD BlueNVMe2TBBackup-Pool
WD BlueNVMe2TBBackup-Pool
Ext. HDDUSB1TBBackup-Pool

Schnittstellen-Mischmasch
Um wirklich jede Schnittstelle zu verwenden, kommt noch eine externe USB-HDD (aktuell für stündliche Snapshots) zum Einsatz. Diese lässt sich im Notfall (Brand, Flucht) auch schnell abziehen und wegtragen.

Da der Thin-Client keine nativen NVMe-Ports bereitstellt, glaubte ich an einen Glücksfall, als ich bei Amazon folgende Adapterkarte in der Preiskategorie "EnAbblunnenEi" fand:

Vermeintliche Dual-NVMe-Adapterkarte

Derart geblendet von der chinesischen Ingenieurskunst, blies ich alle Warnzeichen in den Wind und ignorierte Gewissenhaft, dass einer der auf den ersten Blick baugleichen M.2-Ports um 180° gedreht auf der PCIe-Karte montiert war. Auch war mir zwar aufgefallen aber letztlich egal, dass 2xNVMe PCIe 3.0 oder gar 4.0 niemals nie ohne aktive Komponenten (Multiplexer) über einen PCIe x4-Steckplatz zu transportieren sein wird. Die Adaper-Karte hat jedoch keinen einzigen Chip an "Board".
Fazit: Das Abendessen musste auf den Tisch, den ich zum Schrauben am Rechner benutzte, die Frau machte Druck und so stopfte ich viel zu schnell alles zusammen:

Grober Schnitzer
Mechanisch passte das ja irgendwie, nur nicht so richtig...

Dann kam die Gewissheit: Magic Smoke - Der Geruch von heißer Elektronik nach dem Einschalten des Rechners...

  1. Erkenntnis:
    • Lies die Beschreibung eines Produktes genau durch und lass Dich nicht vom günstigen Preis blenden!
    • Im Fall des o.g. Adapters ist es nämlich so, dass nur der untere Port für NVMe-SSDs und der obere Port ausschließlich für SATA-SSDs zu verwenden ist!
    • Dann läuft die NVMe-SSD über PCIe und die SATA-SSD über den mit dem Mainboard per Kabel zu verbindenden SATA-Port. Die Karte dient der SATA-SSD lediglich zur Stromversorgung.
    • Faulheit und Ignoranz soll und muss auf diesem Weg unbedingt bestraft werden.

Erfolg des Ganzen war, dass der Futro S920 Thin-Client hinüber war und sich nicht mehr einschalten ließ. Meine erste Befürchtung war nun, dass zumindest eine der beiden 2TB NVMe-SSDs gegrillt waren, im schlimmsten Fall vielleicht sogar alles, was am PCIe- und/oder am SATA-Interface hing. Eine optische Überprüfung ergab jedoch keine Rückschlüsse auf defekte Komponenten durch Hitzeentwicklung. Bis jetzt weiß ich nicht, was den Schmorgeruch verursacht hat.

OK, soweit so schlecht.

Wohlweislich hatte ich einen weiteren Futro S920-Client zur Hand. Diesen wollte ich eigentlich zu einer OPNsense-Firewall umbauen, aber nun muss er als Ersatz herhalten. Und wie soll es anders sein? Murphy, was machst Du hier??? Der Ersatz-Client ist nach dem Auspacken direkt ebenfalls kaputt - Dead-on-Arrival...

Es könnte nicht besser laufen, denke ich, erstelle eine Rücksende-Anfrage bei Ebay und bestelle direkt einen weiteren Futro S920 für 35,00 EUR. Unglaublicherweise ist dieser am nächsten Tag per UPS geliefert und es kann weiter gehen.

Dieser funktioniert sogar und nach dem Umbau des RAM und der mSATA-SSD (erstmal ohne die anderen Datenträger) meldet die Kiste, kein bootfähiges Device im Rechner zu finden. Es kostete mich zwei Tage des BIOS-Updatens und anderen Versuchen den Fehler einzugrenzen, bis ich einsehen musste, dass die Boot-Partition beim Einschalten mit dem Magic Smoke beschädigt worden sein musste.

Dies war dahingehend kritisch, da das Boot-Device bei Proxmox VE sämtliche Infos zum Cluster-Node und je nach Einrichtung des Local-Storage (in diesem Fall ZFS) auch noch die Configs der VMs und zugehörige Disk-Images enthält.

Folgende Optionen standen nun zur Auswahl:

  1. Entfernen des defekten Nodes im Cluster nach dieser Anleitung.
  2. Aufsetzen des Nodes auf neuer Hardware unter Verlust sämtlicher Konfigs.
  3. Rejoinen des Nodes in den Cluster und zeitaufwendiges Wiederherstellen der Netzwerke, Storages und VMs aus Backups.

Da der defekte Node zugleich auch den virtualisierten Proxmox Backup Server enthielt, schied das Neuaufsetzen als "schnelle Lösung" aus. Wäre auch zu einfach 😉
Es standen zwar noch VM-Backups auf dem zweiten PBS (Node "pve") zur Verfügung, der letzte Sync lag allerdings mehr als zwei Wochen zurück und den zweiten, nun defekten PBS hatte ich bisher nicht im Backup (Wie sichert man einen ganzen PBS und seinen Sync-Kollegen korrekterweise gegen Ausfall? - das muss ich mir noch überlegen).

Nun aber zurück zum Boot-Problem:

Nach einigem Recherchieren fand ich heraus, dass es im Debug-Modus des Proxmox-Installers (Booten von USB-Stick) das Kommando "proxmox-boot-tool" gibt. Das hört sich vielversprechend an und tatsächlich dient es dem Wiederherstellen einer verloren gegangenen Boot-Partition auf UEFI und Legacy-Systemen, bei denen der Boot-Datenträger mit ZFS angelegt wurde. Grub hat scheinbar u.U. Probleme zuverlässig von einer ZFS-Partiition zu starten (siehe hier).

Frisch ans Werk:

  1. Booten des Proxmox-Installers vom USB-Stick und Starten des Debug-Mode per Menü und anschließendem (CTRL-D).
  2. Mittels lsblk -o +FSTYPE sucht man nun die 512MB große Partition mit dem VFAT-Dateisystem heraus und merkt sich das Device (in meinem Fall /dev/sda2). Gibt es eine 512MB große Partition ohne Dateisystem, wird diese zuerst mittels proxmox-boot-tool format /dev/sdXY formatiert (Ansonsten kann auf das Formatieren verzichtet werden).
  3. Anschließend wird die Partition mittels proxmox-boot-tool init /dev/sdXY der Konfiguration hinzugefügt.
  4. Sollte eine Warnung bezüglich einer "non-existing UUID" erscheinen, diese nicht existierende Konfiguration mittels proxmox-boot-tool clean entfernen.
  5. Nun kann mittels proxmox-boot-tool status überprüft werden, ob eine Partition mit dem Ergebnis grub und/oder uefi ausgegeben wird.
  6. Nach einem Reboot (Strg-Alt-Entf) sollte klar sein, ob der Proxmox-Node wieder von selbst startet.

In meinem Fall tat er das erwartungsgemäß nicht, so dass ich mit dem Defekt scheinbar ganze Arbeit geleistet und sämtliche Daten und nicht nur die Grub-Konfig aus der Partition gelöscht hatte. Zu merken war dies daran, dass der Rechner nun direkt in die Grub-Rescue-Shell bootete. Immerhin ein Fortschritt.

Dem Problem der fehlenden Dateien kommt man folgendermaßen bei:

  1. Booten des Proxmox-Installers vom USB-Stick und Starten des Debug-Mode per Menü und anschließendem (CTRL-D).
  2. Mounten des ZFS-Pools (meistens "rpool") in einen leeren Pfad (z.B. /mnt) mittels zpool import -f -R /mnt rpool
  3. Bind-mounten der virtuellen Dateisysteme, die zum Ausführen von proxmox-boot-tool benötigt werden:
    • mount -o rbind /proc /mnt/proc
    • mount -o rbind /sys /mnt/sys
    • mount -o rbind /dev /mnt/dev
    • mount -o rbind /run /mnt/run
  4. Root in /mnt wechseln mittels chroot /mnt /bin/bash
  5. Wiederholen der Schritte 3-6 aus dem obigen Abschnitt (beginnend mit proxmox-boot-tool init /dev/sdXY).

Mit ein bisschen Glück startet die ganze Fuhre nun wieder brav in die Proxmox-Instanz 😀

Nach diesem kurzen Intermezzo sehe ich ein, dass Dual-NVMe-Adapter für PCIe x4-Slots nicht an jeder Ecke und schon gar nicht günstig zu haben sind, so dass es nun vorerst bei 2 anstelle 4TB zusätzlichem Backup-Speicherplatz bleiben muss.

Dazu genügt nun wirklich ein Single-Slot-Adapter für 7,50 EUR.

So funktioniert es