External votes für Cluster?

[antimon]

Hallo zusammen,

ich habe 3 Proxmox-Server in einem Cluster. Allerdings möchte ich längerfristig aus Stromspargründen nur einen Knoten betreiben und die anderen beiden nur bei Bedarf hochfahren. Dann habe ich natürlich das Problem, dass der Cluster eingefroren wird, sobald nur noch ein Knoten verfügbar ist.
Meine Idee war, zwei Raspis zu verwenden, die als externe "Voter" dienen und damit auch bei zwei ausgeschalteten Servern mit 3 Stimmen eine Mehrheit vorhanden ist.
Allerdings habe ich irgenwie aus der Doku rausgelesen, dass das wohl nicht so einfach funktioniert - ich gebe aber zu, dass ich nicht ganz verstanden habe, wie das genau gemeint ist.

Könnt Ihr mir hier helfen, geht das Szenario, das ich mir vorstelle, so umzusetzen? Würde das mit zwei Raspis klappen oder gibt es einen anderen, besseren Weg?

 

[AST]

Ich habe es noch nicht mit einem Raspberry versucht, läuft das System denn generell?
Dieses Case habe ich als Laborsystem, da ist es aber ein ShuttlePC der da mit einem Celeron rumlangweilt.
Wichtig ist halt, dass man dem HA (Pool) sagt, dass er bitte nicht den Shuttle im Worstcase mit VMs zuknallt.

 

[antimon]

Sorry, ich glaube ich habe das falsch rübergebracht... also ich möchte nicht den Raspi für VMs verwenden, sondern nur für zusätzliche Votes.
Wenn von einem Cluster mit 3 Nodes 2 offline sind, kann man am dritten ja nichts mehr einstellen. Das möchte ich vermeiden, denn solange noch 3 von 5 Votes übrig sind (ein Proxmox-Host und 2 Raspi-Votes) wäre (zumindest meiner Theorie nach) noch handlungsfähig...
Aber ich habe leider keine Ahnung ob die Theorie auch so in der Praxis klappt...

 

[ph0x]

Da das so wahrscheinlich niemand betreibt, erstellst jetzt einfach zwei VMs, die als QDevice agieren und schaust, was passiert, wenn du zwei Server runterfährst.
Aber mal am Rande: Wozu hat man ein Cluster, wenn man nur einen Server betreiben möchte?

 

[antimon]

Hmm jo kann ich machen - ich möchte mir halt nur nicht den Cluster "versauen", wenn ich die Votes wieder rausnehmen müsste... deswegen habe ich gehofft, dass jemand da schon Erfahrung mit hat...

Wozu man den Cluster hat? Naja ich brauche für mein Homelab zwar kein HA oder so, aber ich möchte doch damit experimentieren und Erfahrungen sammeln.
Hauptsächlich soll ein Server laufen (Strom sparen!), aber wenn ich irgendwas testen oder temporär VMs vom Hauptserver verschieben möchte, werden der oder die anderen Server mit hochgefahren. Aber warum soll der ganze Cluster immer laufen, wenn ich damit gerade nicht arbeite?

 

[ph0x]

Dann virtualisier ein Cluster und probier es damit aus.

 

[loomes]

Ja das geht einwandfrei mit dem QDevice auf einem PI. Habe ich hier mit einem Pi4 laufen. Sollte also mit zweien auch gehen.

corosync-quorumtool
Quorum information
------------------
Date:             Fri May 28 17:33:09 2021
Quorum provider:  corosync_votequorum
Nodes:            4
Node ID:          1
Ring ID:          1.1a6a
Quorate:          Yes

Votequorum information
----------------------
Expected votes:   5
Highest expected: 5
Total votes:      5
Quorum:           3
Flags:            Quorate Qdevice

Membership information
----------------------
    Nodeid      Votes    Qdevice Name
         1          1    A,V,NMW proxmox (local)
         2          1    A,V,NMW proxmox2
         3          1    A,V,NMW proxmox3
         4          1    A,V,NMW proxmox1
         0          1            Qdevice

 

[ph0x]

Ich glaub, dass es gehen sollte, ist soweit klar. Nur, ob es tatsächlich funktioniert, weiß bislang keiner.

 

[loomes]

Du siehst doch anhand meines quorumtool Auszugs das es funktioniert. Qdevice = 1 Vote.
Und das kann in der corosync.conf sogar noch angepasst werden auf z.B. 2, dann braucht es keine zwei Pi's.
Die Sinnhaftigkeit des ganzen ist natürlich eher fragwürdig, aber hier wurde ja nun nur gefragt ob es machbar ist... Ja ist es.
Im Grunde würde es bei einem 3er Cluster wo 2 Nodes ständig Off sind aber auch reichen ein "pvecm expected 1" abzusetzen auf dem verbleibenden Node nach dem runterfahren der zwei weiteren Nodes.

 

[antimon]

Okay, das ist schon mal schön zu hören - dann werd ich das mal ausprobieren und evtl. dem PI sogar zwei Votes geben...

Wir können gern noch mal über die Sinnhaftigkeit reden... wenn mein Ansatz verkehrt ist, lasse ich mich gern eines Besseren belehren:
Voraussetzungen:
- Ein Server soll 24/7 laufen, die anderen beiden Server nur bei Bedarf (Stromrechnung!).
- Wenn zwei oder mehr Server laufen, soll eine Live-Migration funktionieren - um beispielsweise um am Hauptserver Wartungsarbeiten durchführen zu können, ohne die VMs runterzufahren.
- Der Befehl "pvecmd expected 1" ist mir bekannt - für mich ist das aber eine eher "schmutzige" Lösung. Denn nach einem Stromausfall muss ich damit manuell eingreifen um die VMs hochzufahren - das möchte ich vermeiden. Mit einem qdevice sollte das automatisch gehen, wenn ich das richtig verstehe.

Vielleicht stimmen meine Anforderungen nicht mit denen von Rechenzentrumsbetreibern überein, aber ich würde trotzdem gerne mit meinen vorhandenen Mitteln gerne das Optimum herausholen. Und für mich ergibt es nicht wirklich Sinn, zwei Server laufen zu lassen, auch wenn ich sie nicht nutze, nur "weil mans halt so macht"...

 

[ph0x]

- Ein Server soll 24/7 laufen, die anderen beiden Server nur bei Bedarf (Stromrechnung!).
- Wenn zwei oder mehr Server laufen, soll eine Live-Migration funktionieren - um beispielsweise um am Hauptserver Wartungsarbeiten durchführen zu können, ohne die VMs runterzufahren.

Ohne shared storage bedeutet das, dass der gesamte Platteninhalt transferiert werden muss. Das geht auf Dauer ziemlich auf die Nerven. Ging's mir zumindest.
Und mit shared storage laufen ja eh schonmal zwei Server ...
Der Wunsch nach stromsparendem Betrieb ich nachvollziehbar, aber deine Lösung kommt mit Unwägbarkeiten, die man auch ertragen können muss/will.

 

[H.G.]

Mehrere Votes sollten vermutlich tun, aber mehrere Qdevices gehen nach meinem Verständnis nicht, da man nicht "ein" Qdevice hinzufügt, sondern "das" Qdevice, das dann Nodeid 0 bekommt.

Da du das QDevice aber gar nicht für HA verwenden willst, sondern nur für die Votes, könntest du dann nicht einfach dem Node, der immer laufen soll, genug Votes für eine Mehrheit geben? (Nie probiert, nur eine Idee...) Würde halt bedeuten, die Partition, in der dieser Node ist, hat immer Recht. Nur wenn der kaputt geht, hast du halt ein Problem, das du dann halt manuell beheben musst (z.B. Expected und Votes neu verteilen), aber da du kein HA machst, sollte das ja egal sein. Braucht außerdem weniger Strom als ein Pi.

 

[antimon]

Der Wunsch nach stromsparendem Betrieb ich nachvollziehbar, aber deine Lösung kommt mit Unwägbarkeiten, die man auch ertragen können muss/will.

Nun ja, gäbs nicht externe Restrictions, so würde ich die 3 Proxmox Server permanent laufen lassen und nen Shared Storage auch noch. Oder gleich GlusterFS oder Ceph. Oder alles zusammen.
Aber abgesehen von der Stromrechnung merkt man 300 W Abwärme unterm Dach schon auch irgendwie. Macht im Sommer nicht so Spaß.
Aber wenn ich wählen könnte, hätte ich auch ein Haus mit einem klimatisierten Keller. Und dann 2 Racks statt nur einem halbhohen.
Geht halt leider nicht alles immer so, wie man es gerne hätte...

Da du das QDevice aber gar nicht für HA verwenden willst, sondern nur für die Votes, könntest du dann nicht einfach dem Node, der immer laufen soll, genug Votes für eine Mehrheit geben? (Nie probiert, nur eine Idee...) Würde halt bedeuten, die Partition, in der dieser Node ist, hat immer Recht. Nur wenn der kaputt geht, hast du halt ein Problem, das du dann halt manuell beheben musst (z.B. Expected und Votes neu verteilen), aber da du kein HA machst, sollte das ja egal sein. Braucht außerdem weniger Strom als ein Pi.

Den Ansatz finde ich super, werde ich ausprobieren! Der PI läuft für Temperaturüberwachung/Monitoring sowieso, aber der muss nicht unbedingt eingebunden werden.
Nein, HA fände ich zwar cool, aber wäre bei mir trotzdem Overkill. Und wenn der Knoten kaputt ginge, muss ich die Maschinen eh manuell ausm Backup wiederherstellen, dann kann ich da auch manuell an die Config gehen.
Das heisst praktisch, ich gebe dem Knoten 3 Votes, dann ist er auf jeden Fall immer in der Überzahl?

 

[ph0x]

In dem Fall würde ich darüber nachdenken, den Raspi als QDevice mit einer Stimme hinzuzufügen und dem ständig laufenden Knoten zwei Stimmen zu geben.
Somit könnte der Knoten auch völlig kaputtgehen und du hättest mit den beiden verbleibenden Maschinen plus Pi noch ein Quorum und müsstest dann nicht erst recht das Rudern anfangen.

 

[antimon]

Stimmt, das ist noch besser! Gut, dass ich euch gefragt habe!