Stromverbrauch reduzieren beim Cluster mit 3 Nodes

[arnaud056]

Hallo zusammen,
ich habe zu Hause einen kleinen Cluster mit 3 Nodes, der für meinen Bedarf z.Z. sehr gut läuft:
- Node1: 24/7 hinter Switch1
- Node2: 24/7 hinter Switch2 (mit trunk an switch1 verbunden)
- Node3: Backups, 2 Std am Tag, hinter Switch2

Leider ist mit der Verbrauch zu hoch, besonders in der Zeit, wo so gut wie alles iddle läuft:
=> Ich möchte den Node2 (+ seinen Switch) nur noch nach Bedarf in Betrieb haben und nur Node1 24/7 lassen.

Vorweg:
- ich habe natürlich die VMs und CTs selektiert, die 24/7 laufen würden und diese nur auf Node1 laufen lassen. Er packt das.
- Alles zum Thema HA und Ausfallsicherheit ist mir bewußt (denke ich...). Wenn Node1 plötzlich nicht weiter will, muss ich ggf. vom Hand die VMs+CTs aus dem täglichen Backup auf Node2 + evtl. Node3 retaurieren und evtl. Daten von den letzten 24Std verlieren.
Die Praxis der letzten Jahren hat gezeigt, dass es absolut tragbar wäre.
- ich möchte möglichst eine exotische Konfiguration vermeiden, wo ich vor jedem Update zittern muss, ob alles dabei kaputt geht und hinterher nur am "reparieren" beschäftigt bin. Also möglichst innerhalb der offiziellen Wegen bleiben und ... möglichst einfache Lösung.

Der "angedachte" Plan:
- Node1 bekommt 2 Votes
- Node2 bleibt mit 1 Vote
- Node3 bleibt ebenso mit 1 Vote
- es kommt einen externen Q-device mit 1 Vote
Quorum= dann 3 Votes. Ich kann Node1 allein mit dem Q-device betreiben. Fällt Node1 aus, müssen Node2 + Node3 zum einsatz kommen, damit das Leben weiter geht.

Ist sowas überhaupt denkbar?

Ich habe irgendwo im Forum gelesen, das mit dem Q-device ginge nicht, wenn die Nodes mehr als 1 Vote haben. Aber ich finde es nicht mehr wieder und ich weiß nicht, ob diese Info überhaupt stimmt....

Die entsprechende Anpassung der conf. scheint nicht besonders schwer zu sein, aber das wird erst zum Thema wenn der "Plan" OK ist.

Danek vorab für eure Rückmeldungen und Kommentare.

Gruß Arnaud

 

[metalworkers]

Hallo Arnaud ,

mal ein anderer Ansatz,
was löst deinen Clust nicht auf ?

Und machst es mit einzelnen Maschinen ?
wie es aussieht hast ja keinen Bedarf für den Cluster

 

[arnaud056]

Hallo metalworkers,
und Danke für den feedback.

In der Tat, die Notwendigkeit nach einem Cluster ist sehr fraglich....Auf die Idee zum single Node zurück zu gehen bin ich auch gekommen. Ich habe jahrelang die PVEs als single Node betrieben, damit war ich auch glücklich.
Nur ich möchte den Luxus von einem Cluster bei der Administration nicht mehr vermissen. Das ist einfach klasse die VMs und CTs hin und her nach Bedarf migrieren zu können, dank ZFS replication geht das ruck-zuck, backup-restore ist schon was anderes...Zentrales storage management ist auch super praktisch.....

Und so könnte ich "ebenmal" etwas Platz auf den Node2 machen, um 3 PVEs+QDevice als VM für diesen Test zu installieren.
Ich versuche den "Plan" etstmal mi den VMs zu testen. Die 3 PVEs-VM sind schon als standard Cluster eingebunden. Snapshots wurden erstellt.....

Ich mache weiter und berichte asap.

Gruß Arnaud

 

[arnaud056]

so kurzes Feedback: ich habe PVE-VM#1 2 votes gegeben und versucht den QDevice einzubinden:

# pvecm qdevice setup 192.168.60.0
Clusters with an odd node count are not officially supported!

Nach einer kurzen Suche bin ich auf den Topic https://forum.proxmox.com/threads/q...-discourage-from-perfectly-safe-setup.139809/ und auf diesen https://forum.proxmox.com/threads/s...when-nodes-are-odd-but-votes-are-even.142251/ wo @bjodah das Selbe wie ich versucht hat.
Das sieht nach einem Rattenschwanz aus.....

Gruß Arnaud

 

[Johannes S]

In der Tat, die Notwendigkeit nach einem Cluster ist sehr fraglich....Auf die Idee zum single Node zurück zu gehen bin ich auch gekommen. Ich habe jahrelang die PVEs als single Node betrieben, damit war ich auch glücklich.
Nur ich möchte den Luxus von einem Cluster bei der Administration nicht mehr vermissen. Das ist einfach klasse die VMs und CTs hin und her nach Bedarf migrieren zu können, dank ZFS replication geht das ruck-zuck, backup-restore ist schon was anderes...Zentrales storage management ist auch super praktisch.....

Kann ich gut verstehen, darum habe ich auch einen Cluster. Aber: Das hat seinen Preis und nächstes Jahr(?) soll es ja eine erste Version eines zentralen Managmentinterfaces geben (analog zum Vcenter von vmware). Damit dürfte das dann schon wieder ander ausschauen. Über die Kommandozeile kann man ja jetzt schon zwischen verschiedenen Clustern replizieren und migrieren.

 

[arnaud056]

Nabend.
Ich fasse zusammen, was ich gelesen und verstanden habe:

• gerade Anzahl der Node => Qdevice verwenden, Qdevice bekommt 1 Vote
• ungerade Anzahl der Node => kein Qdevice verwenden laut dem offiziellen Weg
• ungerade Anzahl der Node => Verwendung eines Qdevices wird vom offiziellen Weg abgeraten, ist aber durch "--force" doch möglich. Alle Nodes müssen 1 Vote haben. Da bekommt der Qdevice aber n-1 Votes! => alle Maschinen können abgeschaltet werden so lange der Qdevice steht und alle Maschinen müssen in Betrieb sein, wenn der Qdevice ausfällt / nicht erreichbar ist / abgeschaltet wird.

=> make your choice!

Mir ist dabei bewusst geworden, das was zählt ist nicht die Anzahl der Votes des Nodes, sondern die Anzahl der Nodes!

Ich muss erstmal ein paar Nächte darüber schlaffen, um zu entscheiden, was ich mache.

Gruß Arnaud

 

[UdoB]

alle Maschinen können abgeschaltet werden so lange der Qdevice steht

Huh???

"alle"???

Nach meinem Verständnis müssen 50.1% der Votes vorhanden sein, damit der Cluster administrierbar bleibt. Das lässt sich aber im Desaster-Recovery-Fall per "expected n" überschreiben.

Üblicherweise bedingt das mindestens zwei physische Stimmengeber, also eben 3 Nodes oder 2*1+1. Ehrlicherweise sei aus meiner Sicht ergänzt: vernünftigerweise will man 4Nodes+1QDev oder fünf Nodes haben. Oder mehr...!

 

[arnaud056]

Huh???

"alle"???

Nach meinem Verständnis müssen 50.1% der Votes vorhanden sein, damit der Cluster administrierbar bleibt. Das lässt sich aber im Desaster-Recovery-Fall per "expected n" überschreiben.

... es muss natürlich immer mindestens eine Machine geben, sonst ist der Cluster komplett aus

Aber das mit den >50% past wenn der Qdevice bekommt n-1 Votes, oder? n=3Nodes => Qdevice hat 2 votes. Max Votes=5, Qdevice + 1 Node machen 3 Votes >50%, geht doch?

Mit dem --force soll mann den "Algorythmus" dabei auch wechseln: von fiftty-fifty zun LastMamStanding.

Wenn ich etwas Zeit am WE werde ich es mit den PVE-VMs probieren.... bis alles kaputt ist....

 

[UdoB]

LastMamStanding

Das hat seine speziellen Herausforderungen, die nicht vom PVE-Normalfall abgedeckt werden.

 

[arnaud056]

vernünftigerweise will man 4Nodes+1QDev oder fünf Nodes haben. Oder mehr...!

ja, "möchte" zumindest, aber dafür dreht mir der Zähler zu schnell!!

 

[arnaud056]

Das hat seine speziellen Herausforderungen, die nicht vom PVE-Normalfall abgedeckt werden.

Ja, ich habe versucht es mit

wird vom offiziellen Weg abgeraten

auszudrücken.

 

[UdoB]

ja, "möchte" zumindest, aber dafür dreht mir der Zähler zu schnell!!

Da bin ich bei dir. Ich überlege nach Island zu ziehen und mir einen Vulkan zu kaufen. Die Strompreise in .de scheinen das zu rechtfertigen :-(

 

[Johannes S]

Generell sind Cluster dafür ausgelegt, dass sie im Dauerbetrieb laufen. Hochverfügbarkeit erlaubt einen zwar, dass man mal was abschaltet (für Wartungszwecke) oder auch aufallen darf (wegen hardwareschaden o.ä.), trotzdem ist es nicht Sinn der Sache einen Teil der Knoten dauerhaft nicht zu betreiben und dafür sich dann mit den Voting drumherum zu tricksen. Wenn man wegen Stromverbrauch oder aus anderen Gründen einen Teil der Hosts nicht ständig betreiben will, sollte man keinen Cluster mit ihnen betreiben. Und nur wegen dem Dashboard würde ich das definitiv nicht tun, man kann ja mit qm und pct remote-migrate ja auch so (halt über die Konsole) zwischen ihnen migrieren, bis das angekündtigte Managmentdashboard verfügbar ist. Will man einen Cluster, aber geringere Stromkosten, wäre die naheliegende Lösung die bisherige Hardware auf ebay zu verscheuern und sich dafür Mini-PCs o.ä. zuzulegen. Die sind vergleichsweise genügsam und reichen fürs Homelab locker. Festplatten, RAM etc kann man ja aus der alten Hardware übernehmen.

 

[arnaud056]

Generell sind Cluster dafür ausgelegt, dass sie im Dauerbetrieb laufen

ich stimme dir zu.

trotzdem ist es nicht Sinn der Sache einen Teil der Knoten dauerhaft nicht zu betreiben und dafür sich dann mit den Voting drumherum zu tricksen

nein, aber es kann eine sehr nette Nebenfunktion sein. Und wie oben gesagt, wenn die Sache nicht 100% betrieben wird wie es "soll", sind "Anpassungen" nötig. Und zwischen anpassen und komplett umkonfigurieren ist viel Platz für eigenes Ermessen bzgl. was vertretbar ist.

mit qm und pct remote-migrate ja auch so (halt über die Konsole) zwischen ihnen migrieren

das wußte ich tatsächlich nicht, werde ich nachlesen. Danke für den Tipp!

die naheliegende Lösung die bisherige Hardware auf ebay zu verscheuern und sich dafür Mini-PCs o.ä. zuzulegen

Das geht nicht (!!), weil ich gar keinen "richtigen" Server habe, sondern nutze vom Anfang an nur diverse low-power, passiv, selbst assemblierten Serverschen und mich da schon mit den entsprechenden Nachteilen (fehlende NICsx oder Anschlüsse für Festplatten usw...) auseinander setzen (sowie ärgern) musste.
Bis jetzt konnte ich mich beherschen, keine geile Rackmaschine anzuschaffen.....

Prinzipiell geht es mir darum, die Verschwendung zu reduzieren, die sich möglich leicht und sogar ohne Kosten reduzieren lassen kann. Es ist genau so wie das Licht auszuschalten, wenn man ein Zimmer verläßt oder die Nachtsabsenkung bei der Heizung. Was nicht gebraucht wird, sollte reduziert bzw. ausgeschaltet sein. Wenn es aber gebraucht wird, sollte es möglich sein, die Leistung abzurufen.
Ich finde dass 24/7 die volle Leistung zu verbrauchen ist genau so "blöd" - egal, ob zu Hause oder in einem Betrieb, der sogar 1-schichtig von Mo. bis Fr. fahren würde - als nie Leistung zu haben, weil alles 24/7 auf dem Sparniveau gedrosselt oder begrenzt ist.
Ich bin einfach für Flexibilität!

Nebenbei, beim Schreiben dieser Zeilen ist mir der Gedanke gekommen, ein Cluster könnte eine Superlösung sein, um gezielt von den schwachen zu den starken Maschinen beim Arbeitsbeginn zu wechseln und umgekehrt beim Arbeitsschluss.....

Aber wir driften vom Thema etwas weg. Wie oben geschrieben, ich habe verstanden, dass ich mich für eine der 3 möglichen Option entscheiden muss.

Gruß Arnaud

 

[Johannes S]

das wußte ich tatsächlich nicht, werde ich nachlesen. Danke für den Tipp!

Steht (wie so vieles, wo nach Leute hier fragen) in der Doku:
https://pve.proxmox.com/pve-docs/pct.1.html
https://pve.proxmox.com/pve-docs/qm.1.html

Oder hier im Forum:
https://forum.proxmox.com/threads/cross-cluster-remote-migration-beispiel-mit-erklärungen.124540/

Ich finde dass 24/7 die volle Leistung zu verbrauchen ist genau so "blöd" - egal, ob zu Hause oder in einem Betrieb, der sogar 1-schichtig von Mo. bis Fr. fahren würde - als nie Leistung zu haben, weil alles 24/7 auf dem Sparniveau gedrosselt oder begrenzt ist.

Sehe ich anders. Sobald die Umgebung groß genug ist, ist es eigentlich immer sinnvoller, den Kram 24/7 laufen zu lassen, warum? Weil man damit Sachen die man eh machen muss (wie Updates, Backups- und andere regelmäßige Wartungsaufgaben) dann in die Abends- und Wochenendzeiten verlagern kann, wo sie weniger stören. Der höhere Stromverbrauch ist meistens kein so hoher Kostenfaktor wie die Personalkosten, falls man nicht funktionierenden Shutdown- und Startautomatismen hinterherrennen muss.

Nebenbei, beim Schreiben dieser Zeilen ist mir der Gedanke gekommen, ein Cluster könnte eine Superlösung sein, um gezielt von den schwachen zu den starken Maschinen beim Arbeitsbeginn zu wechseln und umgekehrt beim Arbeitsschluss.....

Das setzt aber voraus, dass die entsprechende Software für solche Szenarien ausgelegt ist. Nun habe ich da vielleicht den falschen Eindruck (lasse mich gerne korrigieren), aber mein bisheriger Eindruck ist, dass dies für Proxmox VE schlicht nicht der Fall ist, bzw. in Kombination mit der HA-Funktion Probleme macht. Also wäre die Lösung: Alles wichtige kommt auf die Maschine für 24/7, alles andere entsprechend auf andere und man schaltet die Sachen dann immer ein/aus, wie man sie braucht, ohne dass die im gleichen Cluster liegen. Der wichtige Punkt: Nicht im gleichen Cluster liegen, um eben die damit einhergehenden Probleme zu umschiffen.

 

[arnaud056]

Vielen Dank für die Links. Das ganze mit der Migration aussenhalb vom Cluster scheint erstmal nicht so einfach wie in der GUI zu gehen....

Der höhere Stromverbrauch ist meistens kein so hoher Kostenfaktor wie die Personalkosten, falls man nicht funktionierenden Shutdown- und Startautomatismen hinterherrennen muss.

Ja, stimmt: Wenn 500 Leute morgens warten um sich einlogen zu können, laufen die Kosten sicherlich schneller!! Ich kann mir auch vorstellen, dass der/die Admin auch etwas flotter wird, um die Störung zu beseitigen.......

Also wäre die Lösung: Alles wichtige kommt auf die Maschine für 24/7, alles andere entsprechend auf andere und man schaltet die Sachen dann immer ein/aus, wie man sie braucht, ohne dass die im gleichen Cluster liegen.

Ich muss tatsächlich die Entscheidung noch etwas reifen lassen, aber ich tendiere langsam dazu, meine 24/7-Machine aus dem Cluster zu nehmen und die beiden anderen mit dem Qdevice nach Bedarf laufen zu lassen.
Da ich mit ZFS "arbeite", könnte ich regelmäßige Snapshots zum Cluster schicken (pve-zsync), wenn dieser in Betrieb ist, und damit vom Cluster eine wichtige VM oder CT starten (ich kann vorher die config über backup-restore laden aber die restaurierte VM/CT ausgeschaltet lassen), wenn die 24/7-Machine etwas länger aussen Betrieb gehen soll.

Gruß Arnaud

 

[Johannes S]

Was envtl. auch eine Überlegung wert sein könnte: In r/homelab auf Reddit hat ein anderes Energiekostenopfer geschrieben, dass er seine ganze Labhardware verkauft hätte und nun sich einen Server bei Hetzner gemietet hätte (worauf er dann Proxmox VE laufen lässt). Die Servermiete (um die 40-50 Euro wenn ich mich richtig erinnere) kommt ihn günstiger, als die Strom- und sonstigen Kosten

 

[metalworkers]

mal nen einwurf zum nachts laufen lassen.
Bei mir im HomeLab, da laufen Datensicherungen und co meist gegen mittags. Da dort in der Regel die meiste Energie vom Dach kommt


Aber allgemein hätte es schon etwas wenn man nen Cluster rein als Verwaltungskonsole betreiben könnte.
Ich hab bei mir auch einen Aktiven Node der 24/7 läuft .
Und den rest nur bei bedarf an.

 

[Johannes S]

Aber allgemein hätte es schon etwas wenn man nen Cluster rein als Verwaltungskonsole betreiben könnte.

Genau das (Verwaltungskonsole) ist ja als Feature angekündigt und soll nächstes Jahr (nachdem es schon vorher auf der Roadmap war) dann auch in einer ersten (auch weil die ganzen Überläufer von vmware das von daher (vsphere Center) kennen und sich wünschen) Form zur Verfügung stehen. Im englischen Forum gibt es dazu schon länger eine Diskussion, auch wenn noch nichts konkretes bekannt ist:
https://forum.proxmox.com/threads/multi-datacenter-management.66830/

Ich muss tatsächlich die Entscheidung noch etwas reifen lassen, aber ich tendiere langsam dazu, meine 24/7-Machine aus dem Cluster zu nehmen und die beiden anderen mit dem Qdevice nach Bedarf laufen zu lassen.

Naja, das halte ich für Blödsinn, wenn du die eh nicht ständig am Laufen hast, wozu dann noch einen Cluster? Ist dann doch mit dem Quorum und Voten nur eine unnötige Fehlerquelle, von Hochverfügbarkeit hast du dich mit dem "nur nach Bedarf einschalten" ja eh verabschiedest.
Wenn es dir darum geht, alles über die GUI bedienen zu können: Richte dir in allen Hosts eine kleine VM mit dem Proxmox Backup Server ein und lasse dir die VMs der Knoten von ihnen sichern. Der BackupServer kann sich auch die Backups von anderen BackupServern ziehen, auch mit regelmäßiger Synchronisierung. Wenn du also feststellst, dass du eine VM auf einen anderen Host haben möchtest:

1. Backup der VM erstellen, ggf. abschalten (ist aber nicht unbedingt erforderlich)
2. Backup vom PBS auf zweiten ProxmoxVE-Knoten einspielen, VM damit starten (Live-Restore erlaubt dass Starten der VM während der Restore noch läuft!)
3. Nicht mehr benötigten Server herunterfahren

Da ich mit ZFS "arbeite", könnte ich regelmäßige Snapshots zum Cluster schicken (pve-zsync), wenn dieser in Betrieb ist, und damit vom Cluster eine wichtige VM oder CT starten (ich kann vorher die config über backup-restore laden aber die restaurierte VM/CT ausgeschaltet lassen), wenn die 24/7-Machine etwas länger aussen Betrieb gehen soll.

Ja und das sollte eben auch mit den beiden Cluster-Knoten funktionieren, wenn die nicht in einen gemeinsamen Cluster sind.

 

[arnaud056]

Energiekostenopfer

so schlimm ist es auch nicht! ich klage am hohen niedrigen Niveau!

einen Server bei Hetzner gemietet

darüber habe ich auch nachgedacht, aber es ist in dem Fall ein klares "Nein", das geht mir zu weit! Es geht ums Prinzip und auch um die Philosophie: Ich hoste meine Daten und soweit es geht auch die "Serices", die ich nutze.
Das ist schon richtig, dass unter dem Strich ein VPS sicherlich güsntiger ist, wenn mann die Kosten für die Anschaffung der Hardware noch dazu berücksichtigt.
Aber man kann es auch noch günstiger haben in dem man alles Gugöl oder M$S oder Apfel gibt..... ich weiß, die meisten Leute sind viel schlauer als ich: Die sparen sich das Geld und die Mühe.
Bei mir ist es aber Hobby, also es darf was kosten und manchmal auch keinen Sinn haben.

Backup vom PBS auf zweiten ProxmoxVE-Knoten einspielen, VM damit starten (Live-Restore erlaubt dass Starten der VM während der Restore noch läuft!)

Ein zentrales PBS habe ich für den täglichem Backup. Die Funktion des Live-Restore kannte ich auch nicht. Ich muss die Doku lesen https://pve.proxmox.com/pve-docs/chapter-vzdump.html#_live_restore ... und probieren.

Gruß Arnaud