Seit ich davon gehört habe war ich neugierig auf Proxmox und wie das Versprechen von Hochverfügbarkeit damit umgesetzt werden kann. In der Firma, in der ich arbeite wird dieses System auf einem experimentellen Blech-Cluster bereits seit einiger Zeit betrieben - Zeit alse, selber einiger Erfahrungen zu sammeln

Ich entschloss mich dazu - da es sich hier erst einmal um ein Experiment handeln sollte - auf einem Windows-Rechner unter Hyper-V drei VMs einzurichten, die zu meinen Knoten eines kleinen Proxmox-Clusters werden sollten. Da es sich um Windows handelte war noch vor dem Booten der ersten VM mit dem inzwischen heruntergeladenen ISO ein Stolperstein aus dem Weg zu räumen: In HyperV-VMs funktioniert nested Virtualisierung nicht und es gitb auch keine Möglichkeit, dies über die GUI zu aktivieren - also Powershell als Administrator starten und

Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true

ausführen - in meinem Fall also dreimal für jeden der angestrebten Proxmox-Knoten. Anschließend ließ sich das System installieren.

Nachdem ich die drei Knoten zu einem Cluster zusammengefasst hatte, fuhr ich das System zunächst noch einmal herunter um zwei weitere Änderungen an den VMs vorzunehmen:

Ich fügte je eine weitere Netzwerkschnittstelle und virtuelle Festplatte zu jeder VM hinzu - als Vorbereitung für Ceph.

Nachdem ich die VMs wiedr hochgefahren hatte führte ich zunächst einige vorbereitende Arbeiten aus, die zur Installation zusätzlicher Pakete führten: In der Dokumentation wird ausgeführt, dass man NTP nutzen sollte, damit der Cluster reibungslos arbeiten kann. Nachdem ich meinen eigenen NTP-Server betreibe, wollte ich den natürlich auch in den VMs benutzen. Dabei musste ich erstaunt feststellen, dass NTP überhaupt nicht aktiv war - trotzdem ich die offiziellen Install-Images benutzt hatte. Da Proxmox auf Debian beruht, war es aber kein Problem, die benötigten Pakete mittels apt install nachzuinstallieren. Anschließend trug ich meinen eigenen NTP-Server in die Konfigurationsdatei ein und es dauerte wie erwartet nicht lange, dass er als vertrauenswürdiges Zeitnormal akzeptiert wurde. Nun wollte ich mit den gerade hinzugefügten neuen virtuellen Netzwerkkarten ein eigenes Netz aufbauen, das Ceph dann zur Koordinierung nutzen konnte. Dazu administrierte ich über die Web-Konsole die Netzwerkinterfaces und wurde wieder überrascht: als ich die Änderungen mittels Apply Configuration übernehmen wollte, bekam ish statt dessen die Meldung zu Gesicht: you need ifupdown2 to reload network configuration (500). Das bedeutete wieder die Nachinstallation eines weiteren Pakets: dieses mal mittels apt install ifupdown2.

Nun konnte ich an die Einrichtung von Ceph auf jedem Rechner des Clusters gehen. Anschließend fügte ich auf jedem Rechner einen Object Storage Daemon (OSD) hinzu - dafür werden die Festplatten benötigt, die ich zusätzlich jeder der VMs spendiert hatte. Anschließend wurden diese wiederum zu einem Pool zusammengefasst, der nun als Grundlage für die Installation der VMs, bzw. Container im Cluster dienen kann.

Als ich meinen ersten LXC-Container für weitere Tests in Betrieb nehmen wollte, war zunächst wieder Suchen in der Dokumentation angesagt: Standardmäßig kennt Proxmox nach der Installation keine Templates. Diese sind erst separat zu "erwerben:"

pveam update
pveam available|more
pveam download local ubuntu-20.04-standard_20.04-1_amd64.tar.gz

Danach konnte ich einen ersten LXC-Container in Betrieb nehmen, der mir dann als Testhäschen in meinen Migrations- und HA-Tests dienen sollte.

Die Migration konnte ich gleich ausprobieren - sie funktionierte. Für die Hochverfügbarkeit muss man zunächst eine Gruppe anlegen, in die die Knoten des Clusters aufgenommen werden, zwischen denen die wichtigen Container und VMs hin- und her wandern können sollen.

Anschließend kann man dann die wichtigen VMs und Container dieser Gruppe zuordnen und damit beginnen, die eine oder andere VM herunterzufahren. Was jetzt noch bliebe ist ein Test, der das Netzwerk zwischen den Knoten trennt, so dass die VM zwar noch am Leben ist, der Cluster aber wegen des Quorums der Meinung ist, dass die VM weg ist und sie nochmals startet. Vielleicht werde ich einen solchen Test nochmals anstellen, wenn ich mir überlegt habe, wie ich ein solches Szenario im Labor nachstellen kann.

Jetzt bin ich erst einmal damit zufrieden, was ich alles gelernt habe. Der Cluster wird wahrscheinlich demnächst wieder das Zeitliche segnen, die Experimente waren aber jedenfalls interessant...

Und es war natürlich auch wichtig, den Cluster mittels Grafana zu überwachen!

Kommentar hinzufügen (via ) Kommentare ansehen (via )

Kommentar hinzufügen (via ) Kommentare ansehen (via )