Eine Node produziert regelmässig am Samstag Timeouts im Webinterface

[Stefan_Malte_Schumacher]

Hallo Proxmox-Gemeinde,

mein Mini-Cluster leidet immer noch unter den gelegentlichen TCP-Timeouts, die ich in in einem vorherigen Posting beschrieben habe. Ich habe nun auch das Webinterface der Nodes mit einem Active Check versehen. Node 1 und 3 produzieren gar keine Fehler, bei Node Nr.2 gibt es jeden Samstag - und nur am Samstag - bis zu 20 TCP-Timeouts. Ich gehe nicht davon aus, daß meine zufälligen Timeouts in deutlich niedrigerer Frequenz damit in einem Zusammen stehen. Warum produziert eine Node so viele Timeouts und warum nur am Samstag?

Viele Grüße
Stefan

root@hera:~# pveversion -v
proxmox-ve: 7.2-1 (running kernel: 5.15.60-1-pve)
pve-manager: 7.2-11 (running version: 7.2-11/b76d3178)
pve-kernel-5.15: 7.2-13
pve-kernel-helper: 7.2-13
pve-kernel-5.13: 7.1-9
pve-kernel-5.15.64-1-pve: 5.15.64-1
pve-kernel-5.15.60-2-pve: 5.15.60-2
pve-kernel-5.15.60-1-pve: 5.15.60-1
pve-kernel-5.15.53-1-pve: 5.15.53-1
pve-kernel-5.15.39-4-pve: 5.15.39-4
pve-kernel-5.15.39-1-pve: 5.15.39-1
pve-kernel-5.15.35-2-pve: 5.15.35-5
pve-kernel-5.15.35-1-pve: 5.15.35-3
pve-kernel-5.15.30-2-pve: 5.15.30-3
pve-kernel-5.13.19-6-pve: 5.13.19-15
pve-kernel-5.13.19-2-pve: 5.13.19-4
ceph-fuse: 15.2.15-pve1
corosync: 3.1.5-pve2
criu: 3.15-1+pve-1
glusterfs-client: 9.2-1
ifupdown2: 3.1.0-1+pmx3
ksm-control-daemon: 1.4-1
libjs-extjs: 7.0.0-1
libknet1: 1.24-pve1
libproxmox-acme-perl: 1.4.2
libproxmox-backup-qemu0: 1.3.1-1
libpve-access-control: 7.2-4
libpve-apiclient-perl: 3.2-1
libpve-common-perl: 7.2-3
libpve-guest-common-perl: 4.1-4
libpve-http-server-perl: 4.1-4
libpve-storage-perl: 7.2-10
libspice-server1: 0.14.3-2.1
lvm2: 2.03.11-2.1
lxc-pve: 5.0.0-3
lxcfs: 4.0.12-pve1
novnc-pve: 1.3.0-3
proxmox-backup-client: 2.2.7-1
proxmox-backup-file-restore: 2.2.7-1
proxmox-mini-journalreader: 1.3-1
proxmox-widget-toolkit: 3.5.1
pve-cluster: 7.2-2
pve-container: 4.2-3
pve-docs: 7.2-2
pve-edk2-firmware: 3.20220526-1
pve-firewall: 4.2-6
pve-firmware: 3.5-6
pve-ha-manager: 3.4.0
pve-i18n: 2.7-2
pve-qemu-kvm: 7.0.0-4
pve-xtermjs: 4.16.0-1
qemu-server: 7.2-4
smartmontools: 7.2-pve3
spiceterm: 3.2-2
swtpm: 0.7.1~bpo11+1
vncterm: 1.7-1
zfsutils-linux: 2.1.6-pve1

 

[Richard]

Hallo Proxmox-Gemeinde,

mein Mini-Cluster leidet immer noch unter den gelegentlichen TCP-Timeouts, die ich in in einem vorherigen Posting beschrieben habe. Ich habe nun auch das Webinterface der Nodes mit einem Active Check versehen. Node 1 und 3 produzieren gar keine Fehler, bei Node Nr.2 gibt es jeden Samstag - und nur am Samstag - bis zu 20 TCP-Timeouts. Ich gehe nicht davon aus, daß meine zufälligen Timeouts in deutlich niedrigerer Frequenz damit in einem Zusammen stehen. Warum produziert eine Node so viele Timeouts und warum nur am Samstag?

Viele Grüße
Stefan

root@hera:~# pveversion -v
proxmox-ve: 7.2-1 (running kernel: 5.15.60-1-pve)
pve-manager: 7.2-11 (running version: 7.2-11/b76d3178)
pve-kernel-5.15: 7.2-13
pve-kernel-helper: 7.2-13
pve-kernel-5.13: 7.1-9
pve-kernel-5.15.64-1-pve: 5.15.64-1
pve-kernel-5.15.60-2-pve: 5.15.60-2
pve-kernel-5.15.60-1-pve: 5.15.60-1
pve-kernel-5.15.53-1-pve: 5.15.53-1
pve-kernel-5.15.39-4-pve: 5.15.39-4
pve-kernel-5.15.39-1-pve: 5.15.39-1
pve-kernel-5.15.35-2-pve: 5.15.35-5
pve-kernel-5.15.35-1-pve: 5.15.35-3
pve-kernel-5.15.30-2-pve: 5.15.30-3
pve-kernel-5.13.19-6-pve: 5.13.19-15
pve-kernel-5.13.19-2-pve: 5.13.19-4
.......

Ein "Samstag Problem" kenne ich auch von meinem privaten Server zu Hause. Da habe ich den Verdacht, dass Wochenende gerne von den Providern für Wartung genutzt wird und dann ggf. die Zuverlässigkeit des Netzwerks leidet. AFAIU wird das System bei einem Hoster betrieben, da sollte man mal diesen kontaktieren. Ob die Tatsache, dass es nur bei node2 passiert an dem node selbst liegt (d.h. an den VMs die in dem node laufen die einfach mehr traffic bringen oder an einer sonstigen Konfiguration) oder am der Anbindung der node2 beim Provider ist schwer zu sagen. Ich würde aus diesem Grund mal die VMs einer anderen node mit der von node2 tauschen und beobachten ob der Fehler "mitwandert". Wenn nein, ist da tatsächlich etwas schlecht angebunden bei node2.
Eine Möglichkeit wäre auch, am Samstag tcpdump laufen zu lassen und dann mit wireshark analysieren wo und wie genau diese timeouts passieren. Letzteres ist halt aufwändig und ob das überhaupt geht hängt auch vom Volumen des traffics ab.

Apropo: die vielen alten Kernels kann man bedenkenlos entfernen; sie werden überhaupt nur aufgehoben, um bei boot Problemen nicht verloren zu sein. Wenn ein Kernel mal gut laäuft gibt es keinen Grund mehr, die alten noch zu behalten.