[SOLVED] Cluster mit ? und grau aber CPU RAM Anzeige in Übersicht funzt jedoch kein Graph

I

informant

Renowned Member
Jan 31, 2012
823
11
83
Hallo zusammen, nach einer Zeit kommt es bei mir immer wieder vor, dass nur der Cluster plötzlich ? bekommt und alles grau ist, er zeigt keinerlei Graphen mehr an. Aber CPU, RAM Live-Balken etc. in der Übersicht laufen und sind aktuell. An was kann das liegen, ich muss hier immer entweder den Cluster neu starten oder den Services (pvedaemon). Wie kann ich es beheben, so dass er dauerhaft online dargestellt wird? Alle Nodes sind grün und auch die Storages sind grün. Es ist immer nur der Cluster. Hat jmd. eine Idee?
 
Last edited:
Cluster-Kommunikation gestört. Möglicherweise läuft die Uhrzeit der einzelnen Knoten hier zu weit auseinander.
 
Nochmal es ist der Clsuter Server, dh wenn ich mich dort einwähle, sollte der ja nicht grau sein. Der Fehler kam erst mit 7to8. Datum zeit auf die Sekunde aktuell da Timeserverabgleich. Storages etc. alles ist erreichbar auch auf dem grauen Cluster. Lediglich ? kommen und grau und die Graphen sind weg. Alle Werte sind aktuell und Zugriffe funktionieren ebenfalls normal. Alle Nodes sind grün. Ich habe auch 2 Netze, einmal öffentlich einmal int. getrennt. Beide laufen sauber und ohne Verluste <= 0,5ms.
 
informant said:
Nochmal es ist der Clsuter Server, dh wenn ich mich dort einwähle, sollte der ja nicht grau sein. Der Fehler kam erst mit 7to8. Datum zeit auf die Sekunde aktuell da Timeserverabgleich. Storages etc. alles ist erreichbar auch auf dem grauen Cluster. Lediglich ? kommen und grau und die Graphen sind weg. Alle Werte sind aktuell und Zugriffe funktionieren ebenfalls normal. Alle Nodes sind grün. Ich habe auch 2 Netze, einmal öffentlich einmal int. getrennt. Beide laufen sauber und ohne Verluste <= 0,5ms.
Click to expand...

Was meinst Du mit "Cluster Server". Es gibt nicht den "Cluster Server". Mit einwählen meinst Du sicher einloggen. Bei den Time-Deltas im Cluster sprechen wir von Millisekunden, nicht von Sekunden.

Was meinst Du mit "grauem Cluster". Wieviele Cluster hast Du denn? Weißt Du was ein Cluster ist? Deine Fehlerbeschreibung ergibt für mich leider noch keinen Sinn.
 
  • Like
Reactions: Johannes S
Cluster = Hauptserver. Meines wissen nach ist ms = MIllisekunden... Ja den Server wo man sich einwählt und welcher alles Nodes verwaltet. Es gibt einen Cluster mit vielen Nodes darauf, wo der Fehler auftritt. Es können nicht mehrere Hauptserver (Cluster) in einem Login existieren, sondern nur einer. Alles andere sind Nodes.
 
informant said:
Cluster = Hauptserver. Meines wissen nach ist ms = MIllisekunden... Ja den Server wo man sich einwählt und welcher alles Nodes verwaltet. Es gibt einen Cluster mit vielen Nodes darauf, wo der Fehler auftritt. Es können nicht mehrere Hauptserver (Cluster) in einem Login existieren, sondern nur einer. Alles andere sind Nodes.
Click to expand...

Du verwechselt hier viele Dinge und nutzt Begrifflichkeiten, welche überhaupt keinen Sinn ergeben, aber ich löse das gerne mal für Dich auf.
  • Ein Cluster ist kein Hauptserver, ein Cluster ist der Zusammenschluss aus mehreren Rechnern zu einem Rechnerverbund.
  • In einem Cluster gibt es nicht den einen Server welcher alle verwaltet. Ein Cluster nutzt ein sogenanntes Quorum, eine Mehrheitsentscheidung
  • Auf einem Cluster können keine Nodes "drauf sein", ein Cluster besteht aus mehreren (2+n) Nodes. Ein Node ist ein Teil/Rechner eines Clusters
  • In einem Cluster gibt es (nach deiner Definition) nur "Hauptserver", denn jeder Node in einem Cluster hat das gleiche Recht und die gleiche Stimmen-Gewichtung
Wenn jetzt also ein Knoten deines Clusters (Verbund von Rechnern) grau ist, dann stimmt etwas mit der Kommunikation mit den anderen Knoten (Nodes) nicht. Du kannst Dich im Cluster immer auf _jedem_ Knoten "einwählen" (einloggen), da jeder Node den gleichen Zustand des Clusters kennt (oder kennen sollte).

Um das Problem zu debuggen brauchen wir erst einmal alle Logs aus dem Journal (journalctl) um zu schauen, was da los ist. Gerne nur für den corosync Prozess (journalctl -u corosync --since="2 days ago")
 
Last edited:
  • Like
Reactions: Johannes S
corosync hat eben keinen Fehler, daher hab ich den Eintrag hier verfasst. Sobald der Fehler wieder auftritt, werde ich gern corosync Log posten.
 
Last edited:
Hallo, anbei die Log, Fehler kam die Nacht, bis in der Nacht war nichts grau.
Dez 16 13:32:14 pegasus corosync[975]: [QUORUM] Sync members[1]: 1
Dez 16 13:32:14 pegasus corosync[975]: [QUORUM] Sync joined[1]: 1
Dez 16 13:32:14 pegasus corosync[975]: [TOTEM ] A new membership (1.7d) was formed. Members joined: 1
Dez 16 13:32:14 pegasus corosync[975]: [QUORUM] Members[1]: 1
Dez 16 13:32:14 pegasus corosync[975]: [MAIN ] Completed service synchronization, ready to provide service.
Dez 16 13:32:14 pegasus systemd[1]: Started corosync.service - Corosync Cluster Engine.
Dez 16 13:32:16 pegasus corosync[975]: [KNET ] link: Resetting MTU for link 0 because host 3 joined
Dez 16 13:32:16 pegasus corosync[975]: [KNET ] host: host: 3 (passive) best link: 0 (pri: 1)
Dez 16 13:32:16 pegasus corosync[975]: [KNET ] link: Resetting MTU for link 0 because host 2 joined
Dez 16 13:32:16 pegasus corosync[975]: [KNET ] host: host: 2 (passive) best link: 0 (pri: 1)
Dez 16 13:32:16 pegasus corosync[975]: [KNET ] pmtud: PMTUD link change for host: 3 link: 0 from 469 to 1397
Dez 16 13:32:16 pegasus corosync[975]: [KNET ] pmtud: PMTUD link change for host: 2 link: 0 from 469 to 1397
Dez 16 13:32:16 pegasus corosync[975]: [KNET ] pmtud: Global data MTU changed to: 1397
Dez 16 13:32:16 pegasus corosync[975]: [KNET ] link: Resetting MTU for link 0 because host 4 joined
Dez 16 13:32:16 pegasus corosync[975]: [KNET ] host: host: 4 (passive) best link: 0 (pri: 1)
Dez 16 13:32:17 pegasus corosync[975]: [KNET ] rx: host: 5 link: 0 is up
Dez 16 13:32:17 pegasus corosync[975]: [KNET ] link: Resetting MTU for link 0 because host 5 joined
Dez 16 13:32:17 pegasus corosync[975]: [KNET ] host: host: 5 (passive) best link: 0 (pri: 1)
Dez 16 13:32:17 pegasus corosync[975]: [KNET ] pmtud: PMTUD link change for host: 4 link: 0 from 469 to 1397
Dez 16 13:32:17 pegasus corosync[975]: [KNET ] pmtud: PMTUD link change for host: 5 link: 0 from 469 to 1397
Dez 16 13:32:17 pegasus corosync[975]: [KNET ] pmtud: Global data MTU changed to: 1397
Dez 16 13:32:17 pegasus corosync[975]: [QUORUM] Sync members[5]: 1 2 3 4 5
Dez 16 13:32:17 pegasus corosync[975]: [QUORUM] Sync joined[4]: 2 3 4 5
Dez 16 13:32:17 pegasus corosync[975]: [TOTEM ] A new membership (1.81) was formed. Members joined: 2 3 4 5
Dez 16 13:32:17 pegasus corosync[975]: [QUORUM] This node is within the primary component and will provide service.
Dez 16 13:32:17 pegasus corosync[975]: [QUORUM] Members[5]: 1 2 3 4 5
Dez 16 13:32:17 pegasus corosync[975]: [MAIN ] Completed service synchronization, ready to provide service.
Dez 16 15:39:13 pegasus corosync[975]: [TOTEM ] Retransmit List: b7a8

root@pegasus:~# journalctl -u corosync --since="1 days ago"
-- No entries --
root@pegasus:~# date
Do 18. Dez 11:33:05 CET 2025
root@pegasus:~#
Click to expand...

service pvedaemon status
● pvedaemon.service - PVE API Daemon
Loaded: loaded (/usr/lib/systemd/system/pvedaemon.service; enabled; preset: enabled)
Active: active (running) since Tue 2025-12-16 13:32:19 CET; 1 day 22h ago
Invocation: 2be9b5ac79ff4e4cae9b7b6aac1588e0
Process: 1034 ExecStart=/usr/bin/pvedaemon start (code=exited, status=0/SUCCESS)
Main PID: 1102 (pvedaemon)
Tasks: 4 (limit: 9301)
Memory: 175.9M (peak: 194.9M)
CPU: 1min 42.017s
CGroup: /system.slice/pvedaemon.service
├─ 1102 pvedaemon
├─290645 "pvedaemon worker"
├─414817 "pvedaemon worker"
└─417578 "pvedaemon worker"
Click to expand...


Nachdem der Fehler aufgetreten ist, sieht die Serviceliste so aus... Siehe Screenshot im Anhang.
Log pvestat sagt gestern Abend:
Dec 16 18:32:53 pegasus pvestatd[1075]: status update time (6.080 seconds)
Dec 17 23:48:19 pegasus systemd[1]: pvestatd.service: Main process exited, code=killed, status=11/SEGV
Dec 17 23:48:19 pegasus systemd[1]: pvestatd.service: Failed with result 'signal'.
Dec 17 23:48:19 pegasus systemd[1]: pvestatd.service: Consumed 1h 3min 6.169s CPU time, 186.2M memory peak.

Firewall syslog:
Dec 18 00:16:59 pegasus systemd[1]: pve-firewall.service: Main process exited, code=killed, status=11/SEGV
Dec 18 00:16:59 pegasus systemd[1]: pve-firewall.service: Failed with result 'signal'.
Dec 18 00:16:59 pegasus systemd[1]: pve-firewall.service: Consumed 41min 58.624s CPU time, 123.5M memory peak.
 

Attachments

  • screeenerror.png
    screeenerror.png
    41.6 KB · Views: 5
Last edited:
Mich wundern die MTU Änderungen, da scheint etwas mit dem Netzwerk nicht zu passen.
Wenn der pvestatd nicht läuft, hast du keinen Status oder Graphen. Starte den Dienst mal.
 
You must log in or register to reply here.
Top Bottom