Für mein Homelab war ein Upgrade notwendig. Dabei habe ich mich für die Minisforum MS-01 Mini-Workstations entschieden. Mit drei NVME-SSD Anschlüssen für Festplatten / SSDs, zwei 10G LAN und zwei 2,5G LAN Anschlüssen, sowie zwei Thunderbolt Anschlüssen ist dieser Rechner hervorragend ausgestattet für ein Proxmox Cluster.
Drei Cluster-Nodes werden mindestens benötigt, wenn man einen Proxmox Cluster mit Ceph installieren möchte. Und genau für Ceph macht es sinn, die 20G Thunderbolt Netzwerkverbindung für den Ceph Cluster Sync zu nutzen. Damit ergeben sich drei logische Abschnitte für die Anleitung: Allgemeine Installation inkl. Proxmox, Einrichten vom Thunderbolt Netzwerk, Installation von Ceph.
Für mein Cluster verwende ich folgende Hardware-Komponenten (Affiliate-Links zu Amazon):
- MINIS FORUM MS-01 Mini Workstation Intel Core i9-13900H – Bei der CPU Wahl auf vPro Enterprise Support achten, da ist die KVM-Konsole mit dabei
- CORSAIR Vengeance DDR5 SODIMM 64GB (2x32GB) DDR5 5200MHz
- Samsung PM9A3 MZ-QL21T900 – SSD – 1.92 TB – U.2 PCIe 4.0 x4 NVMe – U.2 NVME SSD – der MS-01 unterstützt genau eine dieser SSD. Für Ceph vermutlich eine gute Investition in Langlebigkeit.
- Kingston Data Center DC2000B PCIe 4.0 NVMe M.2 2280 240G Enterprise SSD – Für das Betriebssystem
- Anker Thunderbolt 4 Kabel – Als Netzwerk für Ceph
- HDMI Dummy Plug
Mein Softwarestand von Proxmox ist 8.2.8 – in anderen Versionen könnte es Änderungen geben, die eine andere Handhabung benötigen. Ich schreibe diese Anleitung mehr als „Installationsdokumentation“, damit ich bei einer eventuellen Neuinstallation hier eine Gedankenstütze habe.
Allgemeine Installation
Hardware
Zuerst muss das MS-01 geöffnet werden und der Lüfter auf der Oberseite entfernt werden. Darunter wird der DDR5 RAM installiert und danach wieder der Lüfter mit den drei Schrauben montiert.
Danach die U.2 und die M.2 SSD auf der anderen Seite installieren. Die Anleitung zeigt, wo jeweils montiert werden soll. Dafür muss die Abdeckung mit den drei langen Schrauben runter. M.2 festschrauben. Dann Adapter für die U.2 SSD aus der Verpackung mit verbauen – U.2 auf Adapter verschraueben, dann die obere Abdeckung mit den drei langen Schrauben montieren.
!!!!!!!! Schalter auf U.2 stellen!!!!!!!!
Gehäuse wieder schließen. Mehr muss man an der Hardware nicht machen. Probelauf machen und ins BIOS.
!!!!!!!! Der erste Start des PC kann ggf. etwas dauern!!!!!!!!
Der RAM muss „eingelernt“ werden.
https://www.crucial.com/support/articles-faq-memory/ddr5-memory-training
Das kann bis zu 15 Minuten dauern:
https://www.reddit.com/r/MiniPCs/comments/1eeolrx/minisforum_ms01_doa_or_am_i_an_idiot/
Im BIOS schauen, dass sowohl RAM als auch die Festplatten / SSD erkannt werden.
BIOS Update einspielen
Das BIOS Update zur Auslieferung war bei mir bei 1.22 – auf der Webseite war bereits die Version 1.26 zum Download verfügbar. Deswegen gleich als erstes das BIOS Update durchführen. Das geht relativ einfach:
- USB Stick mit FAT32 formatieren
- Zuerst den Ordner „EFI“ von der Version 1.22 auf den Stick kopieren
- Danach alles von der Version 1.26 auf den Stick kopieren
- Stick einstecken
- Ins BIOS wechseln („Del“) und Secure Boot deaktivieren (lässt es sich nicht direkt entfernen, dann „Default Settings“ -> Save and Reboot -> Secure Boot entfernen)
- Booten vom USB Stick
- Vorgang mit Tastendruck unterbrechen
- Eintippen: „FS0:“ – Der Doppelpunkt ist bei Shift + Ö. Falls das USB Laufwerk ein anderes ist – man sieht es beim Boot recht gut, welche Laufwerke zur Verfügung stehen
- Update starten mit „AfuEfiFlash.nsh“
https://forums.servethehome.com/index.php?threads/minisforum-ms-01-bios.43328/page-5#post-445485
BIOS Einstellungen
Danach geht es erst noch ins BIOS, die Konfiguration von ARM muss noch erfolgen, damit man sich überhaupt an der KVM Konsole anmelden kann.
!!!!!!! 2,5G LAN Port LINKS verwenden!!!!!!
Zuerst muss das Passwort gesetzt werden, dazu den Unterpunkt MEBx auswählen. Das Passwort hat eine spezielle Komplexität. Es werden nicht alle Sonderzeichen akzeptiert, brauch jedoch Sonderzeichen, und es muss mindestens 8 Zeichen haben. Macht man das nicht, folgen seltsame Fehlermeldungen…
Im Menü noch ein paar weitere Settings einstellen, die Anleitung hilft dabei:
https://spaceterran.com/posts/step-by-step-guide-enabling-intel-vpro-on-your-minisforum-ms-01-bios
Für das Netzwerk habe ich DHCP für ARM deaktiviert und eine statische IP vergeben.
Meine für mich wichtigen BIOS Einstellungen waren die folgenden:
- Onboard devices:
- Primary Display auf HG einstellen
- HD Audio -> Disabled
- SA-PCIE Port & PCH-PCIE Port -> ASPM auf Disabled setzen
- PCH-PCIE Port -> WIFI -> Disabled setzen
Nach dem Speichern und Reboot kann man den MeshCommander (Bei mir gab es die Version 0.9.6) installieren und den Server hinzufügen. Wichtig ist dabei das Passwort auf „Digest/TLS“ einzustellen.
Damit ARM funktioniert, muss auch der HDMI Dummy Plug oder ein aktiver Bildschirm gesteckt sein.
Installation von Proxmox
Vor der Installation alle Thunderbolt Kabel abziehen, dann sind keine „seltsamen“ Einstellungen dazu installiert, die diese Anleitung nicht abdeckt.
Jetzt kann Proxmox installiert werden. Einfach die ISO auf einen USB Stick „mit „brennen“. Hierfür die bekannten tools wie beispielsweise win32diskimager verwenden. Von dem Stick booten und dem Installer folgen. Bei mir wurde es auf die kleine M.2 NVME SSD installiert. Hostname korrekt vergeben (bspw. proxmox1.home, proxmox2.home, proxmox3.home) und eine statische IP vergeben.
Nach dem ersten Reboot kann die Weboberfläche aufgerufen werden.
Benutzername und Passwort wurden ebenfalls beim Installer angelegt, bzw. der Benutzer ist root. Hier sollte man perspektivisch den Benutzer root deaktivieren und davor einen anderen Nutzer zur Administration anlegen.
Proxmox wichtigste Einstellungen und Updates
Zuerst macht es Sinn folgende Webseite mit den Proxmox VE Helper-Scripts zu besuchen:
https://tteck.github.io/Proxmox
Dort sind zwei Scripte sehr sinnvoll:
- Proxmox VE Post install
- Proxmox VE Processor Microcode
Proxmox VE Post install konfiguriert die Update-Quellen richtig, sofern man ein Lab aufbaut und dafür die Community Version verwenden möchte. Für ein produktives Setup mit offiziellem Support müssen die Quellen nicht separat angepasst werden, jedoch der Key eingetragen werden. Das Post Install Script ruft man in der Console wie folgt auf:
bash -c "$(wget -qLO - https://github.com/tteck/Proxmox/raw/main/misc/post-pve-install.sh)"
Hier kann alles akzeptiert werden, außer der Deaktivierung von High Availability. Danach wird das Update durchgeführt und das System sollte neu gestartet werden.
Danach sollten die Microcode Updates installiert werden. Den aktuellen Stand kann man mit dem folgenden Befehl aufrufen:
grep microcode /proc/cpuinfo
Es wird etwas angezeigt wie bspw.
microcode : 0x411c
Dann wird das Script ausgeführt und in meinem Fall „intel-microcode_3.20240910.1~deb12u1_amd64.deb“ ausgewählt:
bash -c "$(wget -qLO - https://github.com/tteck/Proxmox/raw/main/misc/microcode.sh)"
Nach dem Reboot kann man wieder den microcode abfragen mit:
grep microcode /proc/cpuinfo
Jetzt wird ggf. eine andere Zeichenfolge angezeigt:
microcode : 0x4122
Jetzt kann man noch Updates durchführen und neu starten:
apt autoclean -y && apt autoremove --purge -y && apt update && apt upgrade -y && apt dist-upgrade -y && reboot now
Nach dem Reboot kann das Thunderbolt Netzwerk eingerichtet werden.
Quelle:
https://pve.proxmox.com/wiki/Firmware_Updates
Proxmox Hosts File anpassen
Für jeden Node sollten die Hostnamen der anderen Nodes mit deren IP Adressen hinterlegt werden. Dabei müssen die eigenen IP Adressen und Namen verwendet werden.
- Datacenter -> Node 1 -> System -> Hosts
- Eintragen von Node 2 und 3 unter Node 1 – bspw.
192.168.0.12 proxmox02.home proxmox02
192.168.0.13 proxmox03.home proxmox03 - Klick auf „Save“
- Wiederholen auf allen drei Nodes
Thunderbolt Netzwerk einrichten
Zuerst die drei MS-01 mit den Thunderbolt Kabeln verbinden. Wenn man immer den Linken an den Rechten einsteckt, hat man hier etwas Struktur. Nachdem alle drei Nodes verbunden sind, kann man mit der Installation und Einrichtung beginnen. Hierzu gibt es auch von scyto eine sehr ausführliche Anleitung, die ich grundsätzlich verwende, jedoch mit mehreren Änderungen:
https://gist.github.com/scyto/67fdc9a517faefa68f730f82d7fa3570
Hilfreich fürs grundsätzliche Verständnis waren ebenfalls folgende Artikel oder Videos:
- https://www.youtube.com/watch?v=dAjw_4EpQdk
- https://www.youtube.com/watch?v=Tb3KH2RbsTE
- https://www.ibm.com/docs/en/ts3500-tape-library?topic=formats-subnet-masks-ipv4-prefixes-ipv6
- https://forum.proxmox.com/threads/intel-nuc-13-pro-thunderbolt-ring-network-ceph-cluster.131107/
- https://www.uni-koeln.de/~pbogusze/posts/FRRouting_openfabric_tech_demo.html
- https://docs.frrouting.org/en/latest/fabricd.html#sample-configuration
- https://github.com/EasyNetDev/linux-multi-loopback
- https://www.apalrd.net/posts/2023/cluster_routes/
- https://forum.proxmox.com/threads/create-a-cluster-by-using-the-lan-ip-not-the-main-public-ip-how-to.77264/
Als ersten Schritt wird lldpd insatlliert:
apt install lldpd lshw htop -y
Zuerst werden die Netzwerkadapter und die Netzwerkadressen gesetzt. Dabei ist man in der Vergabe der IP Adresse recht frei. Einfach das X austauschen gegen die Node Nummer (1-3) ist der einfachste Weg. Wird hier wie in der originalen Anleitung alles in eine neue „thunderbolt“ Datei geschrieben, tauchen die Einstellungen leider nicht im Webinterface von Proxmox auf und sind damit für die wichtigen Einstellungen nicht verfügbar.
Zuerst werden die Einträge für die Network interfaces gesetzt. Dafür muss die Interfaces Datei angepasst werden:
nano /etc/network/interfaces
Diese Einträge hinzufügen direkt hinter dem loopback interface (lo)
iface en05 inet manual
#do not edit it GUI
iface en06 inet manual
#do not edit it GUI
Anmerkung: Die Originale Anleitung schlägt MTU 65520 vor. Startet man jedoch „ifreload –syntax-check –all –debug“ wird folgende Warnung ausgegeben: „warning: en05: mtu: value of out range „65520“: valid attribute range: 552-9216″. Deswegen habe ich die mtu auf den „üblichen“ Wert für JUMBO Frames mit 9000. frr unterstützt grundsätzlich eine Frame Größe von 65535.
https://stonefly.com/resources/jumbo-frames-configuration-and-best-mtu-size/
https://docs.frrouting.org/_/downloads/en/stable-8.1/pdf/
Danach sollten die Kernel Module „thunderbolt“ und „thunderbolt-net“ am Ende der Datei hinzugefügt werden:
nano /etc/modules
Zeilen am Ende der Datei einfügen:
- thunderbolt
- thunderbolt-net
Datei speichern und schließen. Für den nächsten Schritt müssen die Adressen der Thunderbolt Devices gefunden werden. Dazu startet man
udevadm monitor
Danach wird einfach das eine Thunderbolt Kabel ausgesteckt und der Output gelesen. Es wird die Bezeichnung nach /devices/pci0000:00/….. gesucht. Das wiederholt man für den rechten und den linken Anschluss.
Bei mir waren die Bezeichner folgende:
- rechter Anschluss: 0000:00:0d.2
- linker Anschluss: 0000:00:0d.3
Mit diesem Wissen erstellt man nun zwei Dateien. Ist der Anschluss ein anderer, muss die Datei natürlich entsprechend angepasst werden. Die erste Datei erstellt man mit
nano /etc/systemd/network/00-thunderbolt0.link
Und dem Inhalt
[Match]
Path=pci-0000:00:0d.2
Driver=thunderbolt-net
[Link]
MACAddressPolicy=none
Name=en05
Die zweite Datei erstellt man mit
nano /etc/systemd/network/00-thunderbolt1.link
Und dem Inhalt
[Match]
Path=pci-0000:00:0d.3
Driver=thunderbolt-net
[Link]
MACAddressPolicy=none
Name=en06
Jetzt kann eine udev Regel angelegt werden. Damit wird bei Thunderbolt Kabelanschluss ein script ausgeführt:
nano /etc/udev/rules.d/10-tb-en.rules
Mit folgendem Inhalt befüllen:
ACTION=="move", SUBSYSTEM=="net", KERNEL=="en05", RUN+="/usr/local/bin/pve-en05.sh"
ACTION=="move", SUBSYSTEM=="net", KERNEL=="en06", RUN+="/usr/local/bin/pve-en06.sh"
Speichern und schließen. Danach müssen die zwei refernzierten Dateien erstellt und befüllt werden:
nano /usr/local/bin/pve-en05.sh
Mit dem Inhalt befüllen
#!/bin/bash
# this brings the renamed interface up and reprocesses any settings in /etc/network/interfaces for the renamed interface
/usr/sbin/ifup en05
Speichern und schließen und die zweite Datei erstellen
nano /usr/local/bin/pve-en06.sh
Folgender Inhalt:
#!/bin/bash
# this brings the renamed interface up and reprocesses any settings in /etc/network/interfaces for the renamed interface
/usr/sbin/ifup en06
Beide Dateien müssen nun ausführbar gemacht werden
chmod +x /usr/local/bin/*.sh
und danach müssen die Dateien in initramfs verlinkt werden:
update-initramfs -u -k all
IPv4 und IPv6 forwarding muss aktiviert werden.
nano /etc/sysctl.conf
Dann müssen folgende Einträge unkommentiert werden, also das # Symbol entfernt werden
- net.ipv6.conf.all.forwarding=1 (# Symbol am Zeilenanfang entfernen)
- net.ipv4.ip_forward=1 (# Symbol am Zeilenanfang entfernen)
Datei speichern und schließen.
Jetzt die Netzwerke und Adressen festlegen.
nano /etc/network/interfaces.d/thunderbolt
Und folgenden Inhalt einfügen
auto lo:0
iface lo:0 inet static
address 10.0.0.8X/32
auto lo:6
iface lo:6 inet static
address fc00::8X/128
allow-hotplug en05
iface en05 inet manual
mtu 9000
allow-hotplug en06
iface en06 inet manual
mtu 9000
Speichern und schließen, reboot.
reboot
OpenFabric Routing
Kurzversion:
apt install frr -y
sed -i'.bak' 's/fabricd=no/fabricd=yes/g' /etc/frr/daemons
systemctl restart frr
sed -i'.bak' "`wc -l < /etc/network/interfaces`i\\post-up sleep 5 && /usr/bin/systemctl restart frr.service\\" /etc/network/interfaces
Langversion: frr installieren.
apt install frr -y
frr Daemon Datei editieren, um fabricd zu aktivieren:
nano /etc/frr/daemons
und folgende Änderungen durchführen:
Alt:
fabricd=no
Neu:
fabricd=yes
Service neu starten und Änderung post-up in die Interfaces Konfig eintragen:
systemctl restart frr
nano /etc/network/interfaces
Folgenden Inhalt ans Ende (aber VOR der Zeile „source…“) eintragen:
post-up sleep 5 && /usr/bin/systemctl restart frr.service
OpenFabric konfigurieren
In die OpenFabric Shell kommt man mit „vtysh“. Hier kann die aktuelle Konfiguration angezeigt werden mit „show running-config“.
vtysh
In dieser Shell wird die folgende Konfiguration eingetragen. Dabei muss wieder das X geändert werden auf den Node-Namen. Copy-Paste alles in die Shell – auf das letzte Ausrufezeichen „!“ achten und mit Enter bestätigen. Zuerst den Konfigurationsmodus starten mit
configure
Jetzt konfigurieren
ip forwarding
ipv6 forwarding
!
interface en05
ip router openfabric 1
ipv6 router openfabric 1
exit
!
interface en06
ip router openfabric 1
ipv6 router openfabric 1
exit
!
interface lo
ip router openfabric 1
ipv6 router openfabric 1
openfabric passive
exit
!
router openfabric 1
net 49.0000.0000.000X.00
exit
!
Anmerkung: Alternativ kann auch hier in der shell direkt die IP Adresse vom Interface definiert werden, wie hier dargestellt:
https://www.uni-koeln.de/~pbogusze/posts/FRRouting_openfabric_tech_demo.html
https://docs.frrouting.org/en/latest/fabricd.html#sample-configuration
Das hat den Nachteil, dass man auf dem jeweiligen Knoten im Webinterface nicht erkennen kann, dass diese IP-Adresse gesetzt wurde und damit belegt ist. Eine doppelte Definition ist nach meinem Verständnis nicht hilfreich.
Danach folgende Befehle, um die Konfiguration zu speichern:
end
write memory
Nun kann man sich die aktuelle Konfiguration wieder mit „show running-config“ anschauen und danach die Shell beenden:
exit
Falls etwas schief gelaufen ist, die frr Datei direkt editieren: „nano /etc/frr/frr.conf“ und danach den Service neu starten: „/usr/bin/systemctl restart frr.service“
Alle Nodes auf dem gleichen Versionsstand
Dann kann die OpenFabric Konfiguration validiert werden mit folgendem Befehl:
vtysh -c "show openfabric topology"
Nun können alle Nodes gegenseitig gepingt werden.
Problem: IPv4 Netzwerk funktioniert nicht
Kurzversion:
(crontab -l 2>/dev/null; echo "@reboot sleep 30 && /usr/bin/systemctl restart frr.service") | crontab -
Langversion:
Tippt man manuell „/usr/bin/systemctl restart frr.service“ ein, so kommen die IPv4 Adressen hoch. Zuvor war nur IPv6 korrekt verbunden und pingbar.
crontab -e
@reboot sleep 30 && /usr/bin/systemctl restart frr.service
Slow
Dazu einen neuen Eintrag im crontab machen, der nach dem restore der IPv4 Adressen (vgl. voriges Problem), den Monitor Node neustartet:
(crontab -l 2>/dev/null; echo "@reboot sleep 60 && systemctl restart ceph-mon.target") | crontab -
Powersave Modus aktivieren
Einfach einen neuen Crontab anlegen, der die CPU umstellt weg vom performance Modus zum Powersave Modus. Die Ersparnis liegt bei mir etwa bei 10 Watt für alle drei Nodes zusammen.
Kurzversion:
(crontab -l 2>/dev/null; echo "@reboot echo "powersave" | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor >/dev/null 2>&1") | crontab -
Langversion:
Crontab editieren:
crontab -e
Folgenden Inhalt hinzufügen, danch speichern.
@reboot echo "powersave" | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor >/dev/null 2>&1
Bei nächsten Neustart kann man mit folgendem Befehl überprüfen, ob der Modus korrekt gesetzt wurde. Hier sollte dann powersafe stehen:
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
Proxmox Cluster einrichten
Das Cluster wird auf Node 1 erstellt:
- Navigation zu Datacenter -> Cluster -> Klick auf „Create Cluster“
- Cluster Namen vergeben, bspw. Proxmox-Cluster01
- Cluster Network auf Default belassen, das ist Link 0 mit der aktuellen IP
- Create
- Sobald es fertig ist, Klick auf „Join Information“ & „Copy Information“
Dann geht es rüber auf Node 2
- Navigation zu Datacenter -> Cluster -> Klick auf „Join Cluster“
- Paste Join Information
- Passwort Feld ausfüllen mit der Login-Information von Node 1
- Cluster Network die IP des lokalen Knoten auswählen
- Join ‚Proxmox-Cluster01‘ klicken
- Danach muss man die Seite per F5 neu laden und sich erneut einloggen, da hier offensichtlich neue Zertifikate verteilt wurden.
- Nun sind zwei Nodes im Verbund zu sehen
Danach rauf auf Node 3
- Navigation zu Datacenter -> Cluster -> Klick auf „Join Cluster“
- Paste Join Information
- Passwort Feld ausfüllen mit der Login-Information von Node 1
- Cluster Network die IP des lokalen Knoten auswählen
- Join ‚Proxmox-Cluster01‘ klicken
- Danach muss man die Seite per F5 neu laden und sich erneut einloggen, da hier offensichtlich neue Zertifikate verteilt wurden.
- Nun sind alle drei Nodes im Verbund zu sehen
Anmerkung: Wenn was schief läuft, kann man einfach den Node vom Cluster wieder entfernen. https://pve.proxmox.com/wiki/Cluster_Manager#_remove_a_cluster_node
Cluster Migration Network
Hier kann das Netzwerk definiert werden, über welches VMs migriert werden. Ich lege das auch direkt mit auf das Thunderbolt Netzwerk, schlicht weil da die höchste Performance verfügbar ist. In einem solchen Fall leidet sicherlich mindestens kurzfristig die Latenz für das ceph Cluster – in einer Produktionsumgebung sollte deswegen idealerweise auch dafür ein separates Netzwerk bereitgestellt werden.
Damit erreicht man schon mal mehr als 100 MB/s. Für mehr Performance kann man in einem Daisy Chain Thunderbolt Network natürlich auch „security“ deaktivieren. Ist kein öffentliches Netzwerk, dadurch erreicht man etwas mehr Geschwindigkeit.
nano /etc/pve/datacenter.cfg
Zeile hinzufügen am Ende der Datei.
migration: network=10.0.0.1/24,type=insecure
Wird die Zeile mit dem ausgewählten Netzwerk statt „secure“ auf „insecure“ gestellt, kann es etwas schneller sein. Bei mir war der Unterschied: 500 MB/s IPv4 „secure“ und 1,8-2 GB/s IPv4 oder IPv6 „insecure“. Lohnt sich.
Cluster HA Group erstellen
Hier wird erstellt, welche Gruppe an Servern gemeinsam die Hochverfügbarkeit liefern.
- Datacenter -> HA -> Groups
- Create
- ID vergeben, beispielsweise: ClusterGroup1
- Alle drei Nodes auswählen
- Create
Ceph HA Setup
Zuerst muss auf jedem Node das Repository für ceph aktiviert werden. Navigation auf jedem Node: Updates -> Repositories und das „ceph-reef“ Repository mit „no-subscription“ (oder falls man eine Subscription hat, das andere) aktivieren. Danach wieder updates auf allen Nodes durchführen:
apt autoclean -y && apt autoremove --purge -y && apt update && apt upgrade -y && apt dist-upgrade -y
Für Ceph fand ich noch zusätzlich folgende Artikel hilfreich:
- https://pve.proxmox.com/wiki/Deploy_Hyper-Converged_Ceph_Cluster
- https://docs.ceph.com/en/latest/releases
Jetzt geht es einfach voran im Webinterface.
- Node1 -> Ceph -> „Install Ceph“
- Ceph Version: „reef“
- Repository: „No-Subscription“
- „Start reef installation“ (mit „Advanced“ aktiviert)
- Installation und Updates bestätigen
- „Next“
- „Public Network“ das Netzwerk auswählen, über das die VMs kommunizieren sollen, NICHT das Thunderbolt Netzwerk. Ist in aller Regel die vmbr0
- „Cluster Network“ -> Hier das erstellte Thunderbolt Netzwerk verwenden, das auch im Rahmen der Cluster Migrations verwendet wird. Ich wähle hierfür die IPv4 Adresse aus. Die IPv6 (fc00::01/112) kommt in frr deutlich schneller hoch – aber dann kann ich keine OSD anlegen?!?!
- Replicas auf 3 und 2 belassen. Damit kann ein Node ausfallen, ohne das Cluster lahmzulegen
- „Next“
- „Finish“
Diesen Prozess nun für die anderen zwei Nodes durchführen. Hier kommt unter Configuration die Meldung „Configuration already initialized“.
Danach muss man die bisher verwendete vmbr1 löschen (Thunderbolt Migration Network). Dabei verliert man nicht die Einstellungen für CEPH und auch nicht für Data Migration Network.
Ceph Monitor
Für Hochverfügbarkeit benötigt man mindestens 3 Monitors. Ein Monitor enthält die „master copy“ der „cluster map“. Ein Monitor wird über den Wizard im Webinterface schon automatisch erstellt. Das bedeutet, es müssen noch zwei weitere erstellt werden.
Im GUI / Webinterface wieder recht einfach:
- Datacenter -> Node1 -> Ceph -> Monitor – Obere Tabelle
- Create
- Host ist Node2 -> Create
- Create
- Host ist Node3 -> Create
Ceph Manager
Der Manager ist zur Überwachtung der Nodes. Damit macht es Sinn für Hochverfügbarkeit, diesen zumindest auf jedem Monitor Node zu installieren. Das geht auch wieder ganz einfach über das Webinterface
- Datacenter -> Node1 -> Ceph -> Monitor – Untere Tabelle
- Create
- Host ist Node2 -> Create
- Create
- Host ist Node3 -> Create
Ceph OSDs
Vorbereitung:
- Datacenter -> Node1 -> Disks
- Wipe Disk
- Initialize Disk with GPT
Die OSD sind „Object Storage Deamons“. Über diese werden Objekte über das Netzwerk gespeichert. Die Empfehlung ist: Für jede physikalische Platte sollte ein solcher OSD erstellt werden. Auch das geht wieder einfach über das Webinterface:
- Datacenter -> Node1 -> Ceph -> OSD
- Create: OSD
- Disk (bei mir /dev/nvme0n1 mit ca. 2 TB) auswählen
- Rest bei Standard-Einstellungen belassen
- „Create“
Das muss nun alles auf allen Nodes durchgeführt werden. Danach („Reload“!) bekommt man eine Übersicht in diesem OSD Menü über alle drei Festplatten auf allen drei Nodes.
Tauchen die OSD nicht im Menü auf (außer im Menü Ceph als „ghost“), muss man die OSD löschen, das Volume löschen und alles neu erstellen.
- ceph auth del osd.X
- ceph osd rm osd.X
- ceph-volume lvm zap /dev/nvme0n1 –destroy
- /usr/bin/dd if=/dev/zero of=/dev/nvme0n1 bs=1M count=10 conv=fsync
- shred -n 1 -v /dev/nvme0n1
Wieder die hilfreichen Quellen
- https://forum.proxmox.com/threads/ghost-osd-in-the-dashboard.87601/
- https://forum.proxmox.com/threads/disk-partition-dev-nvme0n1-has-a-holder-500-festplatte-kann-nicht-gel%C3%B6scht-werden.151686/
Ceph Pool
Ein Ceph pool ist eine logische Gruppe, um objekte zu speichern. Innerhalb eines pools sind „Placement Groups“ – kurz pg.
Im Pool kann damit definiert werden, wie häufig die Daten gespeichert werden – replicas angelegt werden auf diesen Placement Groups.
Erstellen ist auch wieder einfach übers Webinterface möglich. Ich möchte bei dem Pool der einfachheit halber allen Speicher zuordnen.
- Datacenter -> Node1 -> Ceph -> Pools
- „Create“ – Name bspw. ceph-pool-01
- Rest Default Einstellungen
- „Create“
Damit erscheint der neue Speicher bei jedem Clusternode mit dem gegebenen Namen und man kann VMs darauf verschieben / migrieren.
Hochverfügbarkeit einstellen / automatisieren
Ein paar Einstellungen machen Sinn, um die Arbeiten für Neustarts oder Ausfälle zu minimieren:
- Datacenter -> Options
- „Cluster Resource Scheduling“: Haken an „Rebalance on Start“
- „HA Settings“: Auf migrate stellen. Damit werden VMs beim Shutdown automatisch auf einen anderen Node verschoben
Virtuelle Maschinen auf das Ceph Cluster verschieben
Jetzt werden noch eventuell lokal laufende Test-VMs auf den HA-Ceph-Speicher verschoben. Das geht ganz einfach:
- Datacenter -> Node -> VM
- Hardware
- Auf die Hard Disk einfach klicken
- Oben „Disk Action“ -> „Move Storage“
- Neuen Speicher auswählen – wie oben „ceph-pool-01“
- Delete Source anhaken
- „Move Disk“
Fertig, Cluster up and running.
Pingback: Docker Swarm Cluster auf Openmediavault | OCH-group.de