Proxmox-Experimente

05.09.2020

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!

Alle Artikel rss Wochenübersicht Monatsübersicht Github Repositories Gitlab Repositories Mastodon Über mich home xmpp


Vor 5 Jahren hier im Blog

  • Trigger Hippy - Cave Hill Cemetary

    18.09.2016

    Gute-Laune-Musik gefällig? Bitte sehr...

    Weiterlesen...

Neueste Artikel

  • The Things (Network) Stack v3

    Ich berichtete vor einiger Zeit über meine ersten Versuche der Beschäftigung mit LoRaWAN und The Things Netzwork.

    Weiterlesen...
  • The Future of Programming 2013 (1973?)

    Bret Victor liefert hier einen Vortrag mit Polylux und nimmt die Zuhörer auf eine Zeitreise in die Vergangenheit mit...

    Weiterlesen...
  • The Ultimate RISC

    Ich habe in meinem diesjährigen Urlaub ein Projekt umgesetzt, das ich eigentlich anders geplant hatte - ich wollte meine eigene CPU from scratch bauen...

    Weiterlesen...

Manche nennen es Blog, manche Web-Seite - ich schreibe hier hin und wieder über meine Erlebnisse, Rückschläge und Erleuchtungen bei meinen Hobbies.

Wer daran teilhaben und eventuell sogar davon profitieren möchte, muß damit leben, daß ich hin und wieder kleine Ausflüge in Bereiche mache, die nichts mit IT, Administration oder Softwareentwicklung zu tun haben.

Ich wünsche allen Lesern viel Spaß und hin und wieder einen kleinen AHA!-Effekt...

PS: Meine öffentlichen GitHub-Repositories findet man hier.