Reboot Befehl auf einem Node startet alle neu

[backpulver]

Moin,

ich habe heute einen neuen Node (Nummer 4) in das Cluster gehoben.

Habe ihn dann in die HA Gruppe gehoben und die Replizierungen eingerichtet.

Nun habe ich den aktualisiert und neu gestartet und sehe, dass auf einmal alle einfach mit neustarten.

Das ist neu. Wie kann ich das verhindern? Liegt das vllt an der HA Gruppe?

Eine zweite kleine Frage.
Wie kann ich das Cluster optimal erreichbar und produktiv machen? Aktuell rufe ich es über einen Node auf (Webgui). Wenn ich den aber neu starte, muss ich ja die IP wechseln.
Möchte gerne, dass ich die Informationen über alle Nodes, VMs und Co. möglichst live sehe und nicht lange diese Fragezeichen. Wie löst ihr das? Mit einem PI und der übernimmt dann diese Rolle? Aktuell sind all meine 4 Nodes kleine intel CPU Server.

LG

 

[Falk R.]

Wie sieht denn deine HA Config aus?

Am besten hat ein Cluster immer eine ungerade Anzahl von Knoten oder ein Q-Device (Quorum). Das mit dem Management ist normal und entweder wechselst du vor einem Reboot auf einen anderen Node oder du baust dir einen Loadbalancer davor.

 

[backpulver]

Wie sieht denn deine HA Config aus?

Am besten hat ein Cluster immer eine ungerade Anzahl von Knoten oder ein Q-Device (Quorum). Das mit dem Management ist normal und entweder wechselst du vor einem Reboot auf einen anderen Node oder du baust dir einen Loadbalancer davor.

Die HA Gruppe:


Und dann sind jeweils die VMS einfach mit replikationen auf die jeweils beiden anderen Nodes.

Mehr hab ich da nicht eingestellt.

In welcher Form wäre der Loadbalancer am besten? Ein Pi oder sowas? Ich bin da noch recht unsicher.

 

[Falk R.]

Poste mal deine /etc/pve/corosync.conf.

Als QDevice kannst du jedes Linux nutzen auch einen Pi, obwohl die Pi im Moment recht teuer sind.
Ein gebrauchter Thin Client tut es da auch.

 

[Dunuin]

Meine Vermutung wäre da auch gewesen: Du startest einen Node neu -> Quorumsverlust weil Node offline -> Fencing greift ein und rebootet dir die verbliebenen Nodes

Am besten mal das durchlesen für die Cluster Basics: https://pve.proxmox.com/wiki/Cluster_Manager

 

[Falk R.]

Eigentlich dürfte bei 3 verbliebenen Nodes nix passieren. Daher vermute ich einen Fehler im Corosync Netzwerk.

 

[backpulver]

Poste mal deine /etc/pve/corosync.conf.

Als QDevice kannst du jedes Linux nutzen auch einen Pi, obwohl die Pi im Moment recht teuer sind.
Ein gebrauchter Thin Client tut es da auch.

Muss hierzu sagen. Aktuell ist N-1 nicht verfügbar. Server wartet aktuell auf ein Ersatzteil. Nur N-2,3,4 ist verfügbar.

Wenn ich N-4 neustarte und über N-2 mit Webgui verbunden bin, sind alle weg.

Thinclient habe ich keinen mehr übrig. N-3,4 sind Thinclients. Hätte noch einen Pi Zero übrig.

logging {
  debug: off
  to_syslog: yes
}


nodelist {
  node {
    name: N-1
    nodeid: 1
    quorum_votes: 1
    ring0_addr: 10.0.0.11
  }
  node {
    name: N-2
    nodeid: 2
    quorum_votes: 1
    ring0_addr: 10.0.0.12
  }
  node {
    name: N-3
    nodeid: 3
    quorum_votes: 1
    ring0_addr: 10.0.0.13
  }
  node {
    name: N-4
    nodeid: 4
    quorum_votes: 1
    ring0_addr: 10.0.0.14
  }
}


quorum {
  provider: corosync_votequorum
}


totem {
  cluster_name: DOMAIN
  config_version: 8
  interface {
    linknumber: 0
  }
  ip_version: ipv4-6
  link_mode: passive
  secauth: on
  version: 2
}

 

[Dunuin]

Also fällst du dann von von 3/4 auf 2/4 Votes und damit kein Quorum mehr, daher der Reboot wegen Fencing.

 

[backpulver]

Also fällst du dann von von 3/4 auf 2/4 Votes und damit kein Quorum mehr, daher der Reboot wegen Fencing.

Wie löse ich das am Besten? Qdevice oder kann ich das irgendwie ändern?

 

[Dunuin]

Wie löse ich das am Besten? Qdevice oder kann ich das irgendwie ändern?

Ja, das wäre wohl die beste Option. Dann würde das noch laufen, wenn da 2 von 4 echten PVE Nodes ausfallen.

Andere eher unschöne Optionen wären einem node 2 votes geben oder das "expected votes" von 4 auf 3 zu senken.

 

[Falk R.]

Am besten q-Device einrichten, dann hast du deutlich mehr Verfügbarkeit.

 

[backpulver]

Am besten q-Device einrichten, dann hast du deutlich mehr Verfügbarkeit.

Ok habe den Pi Zero ready gemacht. Leider kann ich ihn nicht zum Qdevice machen, weil dazu alle Nodes online sein müssen und N-1 wie geschrieben aktuell nicht online und nicht verfügbar ist... Kann ich das irgendwie umgehen? Ich weiß nicht, wie lange ich noch auf das Ersatzteil warten muss :/

 

[Falk R.]

Dann hilft nur den Node aus de,m Cluster werfen und nachher neu joinen.

 

[backpulver]

Ok, habe ich nun gemacht. Nun sagt mir der Setup Befehl folgendes:

root@N-2:/etc/pve# pvecm qdevice setup 10.0.0.10
Clusters with an odd node count are not officially supported!
root@N-2:/etc/pve#

mach ich ein -f dran, schläft die host verification fehl

root@N-2:/etc/pve# pvecm qdevice setup 10.0.0.10 -f
/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/root/.ssh/id_rsa.pub"
/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed

/bin/ssh-copy-id: WARNING: All keys were skipped because they already exist on the remote system.
                (if you think this is a mistake, you may want to use -f option)


INFO: initializing qnetd server
Certificate database (/etc/corosync/qnetd/nssdb) already exists. Delete it to initialize new db

INFO: copying CA cert and initializing on all nodes
Host key verification failed.
bash: line 1: corosync-qdevice-net-certutil: command not found
bash: line 1: corosync-qdevice-net-certutil: command not found

INFO: generating cert request
command 'corosync-qdevice-net-certutil -r -n C-Lab' failed: open3: exec of corosync-qdevice-net-certutil -r -n C-Lab failed: No such file or directory at /usr/share/perl5/PVE/Tools.pm line 455.

Habe den Pi Zero mit Raspbian 32 bit installiert und danach diese Sachen installiert:

Via SSH komme ich drauf, auch von den Nodes aus.

Jemand eine Lösung für mich? Hab da nicht viel gefunden.