Haben Sie mal 3 Minuten? Fehlende Daten in den Graphen

D

devaux

Active Member
Feb 3, 2024
190
45
28
Hallo,
Ich mache momentan diverse Tests mit Proxmox. Heute ist mir ein komisches Phaenomen aufgefallen. Ich habe 2 Cluster mit je zwei Nodes im Testbetrieb. 3 davon hatten zur gleichen Uhrzeit einen Unterbruch in allen Graphen - einer nicht.
Diese sind alle im gleichen Netz und identisch am gleichen Switch angeschlossen. Hat jemand eine Idee wieso dies passiert ist oder wo ich am besten nachgucke, ob es sich hier um ein Problem oder einen "Glitch" handelt?

1717929680721.png
 
Das nennt sich logfile(s) und die liegen im /var/log/.. Verzeichnis.
P.S. Graphen des Proxmox VE interessieren mich nicht und ich schaue nicht darauf.
Das ist ein Server, den ich im eine SSH Konsolensitzung administriere.
 
Wenn ich was in den Logfiles oder im systemd-Log sehen/finden wuerde, wuerde ich hier nicht fragen.
Graphen empfinde ich noch relativ wichtig um Engpaesse oder irgendwelche Unstimmigkeiten praeventiv abfedern zu koennen. Das koennen natuerlich alle handhaben wie sie moechten.
 
  • Like
Reactions: ferengie
devaux said:
Ich habe 2 Cluster mit je zwei Nodes
Click to expand...
Dass das nicht gut ist, ist vermutlich klar? Naheliegend wäre jeweils ein Container im anderen Cluster als "Quorum-Device" :-)

"Kein Quorum" kann verschiedene Ursachen (Netzlast?) und verschiedene Auswirkungen haben. Zunächst wird "/etc/pve" read-only. Ob das Einfluss auf die Statistik-Erfassung hat, kann ich nicht sagen. Aber gerade im Testbetrieb spart man manchmal "Dinge" ein, weil man meint, dass man sie nicht braucht - mit "komischen" Effekten...

devaux said:
einen Unterbruch in allen Graphen
Click to expand...
Ich hatte das auch schon. Einmal lag es an einem verstorbenen "pve-statd". Ein anderes mal bilde ich mir ein (nicht wirklich verifiziert), dass es schlicht an der zu hohen Systemlast lag. Genauer: hohe "iowait"-Werte aufgrund langsamer Massenspeicher.

Den genauen Grund konnte ich in meinem Fall nicht klären, das Problem verschwand "von selbst"...

Viele Grüße
 
UdoB said:
Dass das nicht gut ist, ist vermutlich klar? Naheliegend wäre jeweils ein Container im anderen Cluster als "Quorum-Device" :)

"Kein Quorum" kann verschiedene Ursachen (Netzlast?) und verschiedene Auswirkungen haben. Zunächst wird "/etc/pve" read-only. Ob das Einfluss auf die Statistik-Erfassung hat, kann ich nicht sagen. Aber gerade im Testbetrieb spart man manchmal "Dinge" ein, weil man meint, dass man sie nicht braucht - mit "komischen" Effekten...


Ich hatte das auch schon. Einmal lag es an einem verstorbenen "pve-statd". Ein anderes mal bilde ich mir ein (nicht wirklich verifiziert), dass es schlicht an der zu hohen Systemlast lag. Genauer: hohe "iowait"-Werte aufgrund langsamer Massenspeicher.

Den genauen Grund konnte ich in meinem Fall nicht klären, das Problem verschwand "von selbst"...

Viele Grüße
Click to expand...
Ja, das mit den 2 Nodes ist mir bewusst ;) Ist nur ein Testbetrieb ohne HA und nichts.
Aber Du hast natuerlich Recht. Ich werde wohl da noch nachbessern.

Das mit dem "langsamen Massenspeicher" klingt aber interessant. Alle 4 Hosts haben den selben PBS eingebunden - Ein Test-Testsystem ;)
Koennte es sein, dass der Zugriff auf diesen Test-PBS zu dieser Zeit gerade "gestoert" war und die fehlende Protokollierung hervorgerufen hat?
Das waere eine Erklaerung... Aber nicht sehr toll, da waehrend dieser Zeit alle Graphen den Ausfall aufweisen.
Wieso dann aber nur 3 von 4 Hosts?
 
Last edited:
devaux said:
Ja, das mit den 2 Nodes ist mir bewusst ;) Ist nur ein Testbetrieb ohne HA und nichts.
Aber Du hast natuerlich Recht. Ich werde wohl da noch nachbessern.

Das mit dem "langsamen Massenspeicher" klingt aber interessant. Alle 4 Hosts haben den selben PBS eingebunden - Ein Test-Testsystem ;)
Koennte es sein, dass der Zugriff auf diesen Test-PBS zu dieser Zeit gerade "gestoert" war und die fehlende Protokollierung hervorgerufen hat?
Das waere eine Erklaerung... Aber nicht sehr toll, da waehrend dieser Zeit alle Graphen den Ausfall aufweisen.
Wieso dann aber nur 3 von 4 Hosts?
Click to expand...
Ja, das könnte die Ursache sein. WEnn du einen 2 Node Cluster ohne Quorum betreibst, macht er auch ohne HA alle VMs aus, wenn der zweite mal neu bootet. Das ist ein klassischer Corosync Cluster (funktioniert genauso wie ein Microsoft Failovercluster) und dem ist es egal ob due HA oder andere Features nutzt.
 
Hmnein, waren eigentlich alle 4 Nodes online. Auch haben die VMs nicht neugestartet. Die Konstellation hatte ich schon oefter, dass eine von den beiden Nodes ausgeschaltet waren und da hat keine VM irgendwas selber gemacht - was ich sehr zu schaetzen weiss
Es ist ja auch so, dass die 3 PVE waehrend dieser 3 Minuten bei KEINEM Graphen etwas gezeichnet haben.
Habe jetzt einen Quorum-Host eingerichtet. Mal schauen, ob der "Glitch" wieder auftritt.
 
Solche Aussetzer im Grafen hast du öfters mal, wenn du einen Node neu startest, Netzwerklast oder Latenzen hast. Natürlich auch wenn DIenste neustarten, wie z.B. bei Updates.
 
Ich habe eine QNAP-Storage, die per iSCSI angebunden ist. Einmal über ein Management-Netz und einmal über ein Storage-Netz.
Leider bindet dessen Firmware iscsi stets auf alle Netzwerkinterfaces (kann man nicht abschalten).
Jedesmal wenn der iscsid ein autodiscover macht, findet er den gleichen Speicher über zwei Netzwerkadressen.
Immer wenn das passiert, dann gibts beim abrufen dieser Performance-Daten einen Timeout und rrd timeouted und schreibt keine Werte in die Diagramme.
Im Systemlog des PVE-Hosts stehen dann die Timeouts.
Sobald ich /etc/iscsi/nodes beim betreffenden Node die zweite Netzwerkadresse des QNAP herauslösche, klappen auch die Diagramme wieder.
 
quantumjump said:
Ich habe eine QNAP-Storage, die per iSCSI angebunden ist. Einmal über ein Management-Netz und einmal über ein Storage-Netz.
Leider bindet dessen Firmware iscsi stets auf alle Netzwerkinterfaces (kann man nicht abschalten).
Click to expand...
Bei den meisten geht das im Bereich Netzwerk, indem man nur bestimmte Protokolle auf einem Interface erlaubt.
quantumjump said:
Jedesmal wenn der iscsid ein autodiscover macht, findet er den gleichen Speicher über zwei Netzwerkadressen.
Immer wenn das passiert, dann gibts beim abrufen dieser Performance-Daten einen Timeout und rrd timeouted und schreibt keine Werte in die Diagramme.
Im Systemlog des PVE-Hosts stehen dann die Timeouts.

Sobald ich /etc/iscsi/nodes beim betreffenden Node die zweite Netzwerkadresse des QNAP herauslösche, klappen auch die Diagramme wieder.
Click to expand...
Wenn du nur die gewünschten IP als Target hinterlegst, sucht er beim Discovery nur auf dem Netzwerk. Ich gebe immer nur die gewünschten IP Kreise beim Discovery an und das klappt dann immer.
Bei NAS Systemen empfehle ich eh lieber NFS zu nutzen. Die iSCSI Integrationen der NAS Hersteller sind oft nicht do dolle.
 
Ich vermute ich habe bei mir die Ursache für die kaputten Graphen gefunden!

Die VMs (vHDs) liegen bei mir auf einem QNAP-NAS, das über NFS angebunden ist. Das NAS ist über eine LACP-LAG (2x 10G) an meinem Mikrotik-Switch angebunden. QNAP kann als LACP-Transmit-Hash nur Layer2+3. Mikrotik jedoch bis Layer 3+4. AFAIK war best practice immer, dass man auf jedem Gerät stets den höchstmöglichen Transmit-Hash nehem solle, um eine möglichst feingranulare Auslastung der Links zu gewährleisten. Auch wenn die Transmit-Hashes auf unterschiedlichen Layern arbeiten.

Wenn ich den Switch nun auch auf Layer2+3 stelle (wie das NAS), sind die Abbrüche weg! Es scheint, dass es hier rigendwo zu einen Blödsinn kommt! Also, auch wenn es überall anders steht, auch bei LACP sollten die Transmit-Hashes auf beiden Seiten matchen!!

ChatGPT sagt dazu:
  • Verbindungsabbrüche (FS auf dem NAS hängt)
  • Korrupte oder flackernde Graphen in Proxmox
  • Sporadisch langsame I/O
  • VMs frieren kurz ein oder Crashen

Das ist typisch, wenn Pakete eines TCP-Flows über unterschiedliche Pfade hin- und zurückgehen → Out-of-order packets, was TCP abstraft oder schlimmstenfalls Drop verursacht, weil es als Angreifer/Fehlkommunikation erkannt wird.
Click to expand...

https://serverfault.com/a/474797
https://learningnetwork.cisco.com/s...have-to-be-the-same-on-both-sides-of-the-link
 
HalloWelt said:
Ich vermute ich habe bei mir die Ursache für die kaputten Graphen gefunden!

Die VMs (vHDs) liegen bei mir auf einem QNAP-NAS, das über NFS angebunden ist. Das NAS ist über eine LACP-LAG (2x 10G) an meinem Mikrotik-Switch angebunden. QNAP kann als LACP-Transmit-Hash nur Layer2+3. Mikrotik jedoch bis Layer 3+4. AFAIK war best practice immer, dass man auf jedem Gerät stets den höchstmöglichen Transmit-Hash nehem solle, um eine möglichst feingranulare Auslastung der Links zu gewährleisten. Auch wenn die Transmit-Hashes auf unterschiedlichen Layern arbeiten.

Wenn ich den Switch nun auch auf Layer2+3 stelle (wie das NAS), sind die Abbrüche weg! Es scheint, dass es hier rigendwo zu einen Blödsinn kommt! Also, auch wenn es überall anders steht, auch bei LACP sollten die Transmit-Hashes auf beiden Seiten matchen!!

ChatGPT sagt dazu:


https://serverfault.com/a/474797
https://learningnetwork.cisco.com/s...have-to-be-the-same-on-both-sides-of-the-link
Click to expand...
Ja, bei LACP sollten immer alle die gleiche Spreche sprechen. Das mit dem höchsten Layer ist richtig, aber nur wenn beide Seiten das können.
 
You must log in or register to reply here.
Top Bottom