Hallo Experten
Wir haben heute Nachmittag spontan und ohne erkennbaren Auslöser ein merkwürdiges Phänomen. Das Web-UI zeigt nur den jeweils aktuellen Host über den man das Web-UI aufgerufen hat als Online, alle anderen Hosts sind mit Fragezeichen versehen.
Zuerst dachte ich an ein Problem mit Corosync, oder evtl mit dem Corosync Netz oder mit Multicast.
Deshalb habe ich zunächst von allen Hosts alle anderen Hosts über das Corosync Netz angepingt. Das war erfolgreich.
Dann habe ich mit omping alle Hosts simultan per Multicast gepingt. Auch das war völlig Problemlos. 10.000 Pakete gesendet, 9.992 OK, was völlig im Rahmen ist.
Ich dachte, okay, vielleicht stimmt was mit dem Corosync Dienst nicht. Habe daher mal auf dem Host auf dem nur unwichtige Gäste laufen, den Corosync angehalten und wieder gestartet. Keine Veränderung
Was mich total irritiert ist die Ausgabe von pvecm status
Ein Host ist Down, aber der hat einen Hardwareschaden und wird bald repariert. Ansonsten sieht der Cluster total OK aus. Das WebUI sagt unter Datacenter -> Summary ebenfalls, das alles OK ist. Ich kann aber keine Gäste migrieren, ich bekomme von der WebUI des einen Hosts keine Infos über die Gäste die auf anderen Hosts laufen und alle Hosts außer der über den ich das WebUI aufgerufen habe werden mit ? markiert. VM-Namen werden auch nicht angezeigt.
Der pvestatd sieht verdächtig aus. Ich traue mich aber nicht, den jetzt neu zu starten. Auf dem Host laufen VMs die wir für den Betrieb brauchen und ich kann die VMs gerade ja nicht migrieren.
Zu dem Zeitpunkt als der Fehler aufgetreten ist sind keinerlei Veränderungen am Cluster vorgenommen worden. Alle VMs sind normal erreichbar, Ceph läuft problemlos. Deshalb lasse ich den Cluster erstmal einfach so laufen. Ich hoffe das lässt sich ohne Down-Time lösen...
Hat jemand eine Idee? Welche Infos braucht ihr zur Fehlersuche noch?
Ich hätte noch das Syslog, aber heute Nachmittag gab es ein Turnover, da müsste ich erstmal gucken wo was interessantes drin steht und wie man da ran kommt. Bin nicht so der Profi was journalctl angeht.
Wir haben heute Nachmittag spontan und ohne erkennbaren Auslöser ein merkwürdiges Phänomen. Das Web-UI zeigt nur den jeweils aktuellen Host über den man das Web-UI aufgerufen hat als Online, alle anderen Hosts sind mit Fragezeichen versehen.
Zuerst dachte ich an ein Problem mit Corosync, oder evtl mit dem Corosync Netz oder mit Multicast.
Deshalb habe ich zunächst von allen Hosts alle anderen Hosts über das Corosync Netz angepingt. Das war erfolgreich.
Dann habe ich mit omping alle Hosts simultan per Multicast gepingt. Auch das war völlig Problemlos. 10.000 Pakete gesendet, 9.992 OK, was völlig im Rahmen ist.
Ich dachte, okay, vielleicht stimmt was mit dem Corosync Dienst nicht. Habe daher mal auf dem Host auf dem nur unwichtige Gäste laufen, den Corosync angehalten und wieder gestartet. Keine Veränderung
Was mich total irritiert ist die Ausgabe von pvecm status
root@vm-2:~# pvecm status
Quorum information
------------------
Date: Thu Mar 7 17:07:03 2019
Quorum provider: corosync_votequorum
Nodes: 7
Node ID: 0x00000002
Ring ID: 1/475104
Quorate: Yes
Votequorum information
----------------------
Expected votes: 8
Highest expected: 8
Total votes: 7
Quorum: 5
Flags: Quorate
Membership information
----------------------
Nodeid Votes Name
0x00000001 1 192.168.16.1
0x00000002 1 192.168.16.2 (local)
0x00000003 1 192.168.16.3
0x00000004 1 192.168.16.4
0x00000005 1 192.168.16.5
0x00000006 1 192.168.16.6
0x00000008 1 192.168.16.8
Quorum information
------------------
Date: Thu Mar 7 17:07:03 2019
Quorum provider: corosync_votequorum
Nodes: 7
Node ID: 0x00000002
Ring ID: 1/475104
Quorate: Yes
Votequorum information
----------------------
Expected votes: 8
Highest expected: 8
Total votes: 7
Quorum: 5
Flags: Quorate
Membership information
----------------------
Nodeid Votes Name
0x00000001 1 192.168.16.1
0x00000002 1 192.168.16.2 (local)
0x00000003 1 192.168.16.3
0x00000004 1 192.168.16.4
0x00000005 1 192.168.16.5
0x00000006 1 192.168.16.6
0x00000008 1 192.168.16.8
root@vm-2:~# cat /etc/pve/corosync.conf
logging {
debug: off
to_syslog: yes
}
nodelist {
node {
name: vm-1
nodeid: 1
quorum_votes: 1
ring0_addr: 192.168.16.1
}
node {
name: vm-2
nodeid: 2
quorum_votes: 1
ring0_addr: 192.168.16.2
}
node {
name: vm-3
nodeid: 3
quorum_votes: 1
ring0_addr: 192.168.16.3
}
node {
name: vm-4
nodeid: 4
quorum_votes: 1
ring0_addr: 192.168.16.4
}
node {
name: vm-5
nodeid: 5
quorum_votes: 1
ring0_addr: 192.168.16.5
}
node {
name: vm-6
nodeid: 6
quorum_votes: 1
ring0_addr: 192.168.16.6
}
node {
name: vm-7
nodeid: 7
quorum_votes: 1
ring0_addr: 192.168.16.7
}
node {
name: vm-8
nodeid: 8
quorum_votes: 1
ring0_addr: 192.168.16.8
}
}
quorum {
provider: corosync_votequorum
}
totem {
cluster_name: Langeoog
config_version: 11
interface {
bindnetaddr: 192.168.16.1
ringnumber: 0
}
ip_version: ipv4
secauth: on
version: 2
}
logging {
debug: off
to_syslog: yes
}
nodelist {
node {
name: vm-1
nodeid: 1
quorum_votes: 1
ring0_addr: 192.168.16.1
}
node {
name: vm-2
nodeid: 2
quorum_votes: 1
ring0_addr: 192.168.16.2
}
node {
name: vm-3
nodeid: 3
quorum_votes: 1
ring0_addr: 192.168.16.3
}
node {
name: vm-4
nodeid: 4
quorum_votes: 1
ring0_addr: 192.168.16.4
}
node {
name: vm-5
nodeid: 5
quorum_votes: 1
ring0_addr: 192.168.16.5
}
node {
name: vm-6
nodeid: 6
quorum_votes: 1
ring0_addr: 192.168.16.6
}
node {
name: vm-7
nodeid: 7
quorum_votes: 1
ring0_addr: 192.168.16.7
}
node {
name: vm-8
nodeid: 8
quorum_votes: 1
ring0_addr: 192.168.16.8
}
}
quorum {
provider: corosync_votequorum
}
totem {
cluster_name: Langeoog
config_version: 11
interface {
bindnetaddr: 192.168.16.1
ringnumber: 0
}
ip_version: ipv4
secauth: on
version: 2
}
root@vm-2:~# systemctl status pve-cluster.service
● pve-cluster.service - The Proxmox VE cluster filesystem
Loaded: loaded (/lib/systemd/system/pve-cluster.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2019-01-03 09:39:18 CET; 2 months 2 days ago
Main PID: 2545 (pmxcfs)
Tasks: 13 (limit: 7372)
Memory: 116.0M
CPU: 2h 51min 8.710s
CGroup: /system.slice/pve-cluster.service
└─2545 /usr/bin/pmxcfs
Mar 07 16:28:44 vm-2 pmxcfs[2545]: [dcdb] notice: received sync request (epoch 1/2274/00000004)
Mar 07 16:28:44 vm-2 pmxcfs[2545]: [dcdb] notice: received sync request (epoch 1/2274/00000005)
Mar 07 16:28:44 vm-2 pmxcfs[2545]: [dcdb] notice: received sync request (epoch 1/2274/00000006)
Mar 07 16:28:44 vm-2 pmxcfs[2545]: [dcdb] notice: received sync request (epoch 1/2274/00000007)
Mar 07 16:28:44 vm-2 pmxcfs[2545]: [status] notice: received sync request (epoch 1/2274/00000002)
Mar 07 16:28:44 vm-2 pmxcfs[2545]: [status] notice: received sync request (epoch 1/2274/00000003)
Mar 07 16:28:44 vm-2 pmxcfs[2545]: [status] notice: received sync request (epoch 1/2274/00000004)
Mar 07 16:28:44 vm-2 pmxcfs[2545]: [status] notice: received sync request (epoch 1/2274/00000005)
Mar 07 16:28:44 vm-2 pmxcfs[2545]: [status] notice: received sync request (epoch 1/2274/00000006)
Mar 07 16:28:44 vm-2 pmxcfs[2545]: [status] notice: received sync request (epoch 1/2274/00000007)
● pve-cluster.service - The Proxmox VE cluster filesystem
Loaded: loaded (/lib/systemd/system/pve-cluster.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2019-01-03 09:39:18 CET; 2 months 2 days ago
Main PID: 2545 (pmxcfs)
Tasks: 13 (limit: 7372)
Memory: 116.0M
CPU: 2h 51min 8.710s
CGroup: /system.slice/pve-cluster.service
└─2545 /usr/bin/pmxcfs
Mar 07 16:28:44 vm-2 pmxcfs[2545]: [dcdb] notice: received sync request (epoch 1/2274/00000004)
Mar 07 16:28:44 vm-2 pmxcfs[2545]: [dcdb] notice: received sync request (epoch 1/2274/00000005)
Mar 07 16:28:44 vm-2 pmxcfs[2545]: [dcdb] notice: received sync request (epoch 1/2274/00000006)
Mar 07 16:28:44 vm-2 pmxcfs[2545]: [dcdb] notice: received sync request (epoch 1/2274/00000007)
Mar 07 16:28:44 vm-2 pmxcfs[2545]: [status] notice: received sync request (epoch 1/2274/00000002)
Mar 07 16:28:44 vm-2 pmxcfs[2545]: [status] notice: received sync request (epoch 1/2274/00000003)
Mar 07 16:28:44 vm-2 pmxcfs[2545]: [status] notice: received sync request (epoch 1/2274/00000004)
Mar 07 16:28:44 vm-2 pmxcfs[2545]: [status] notice: received sync request (epoch 1/2274/00000005)
Mar 07 16:28:44 vm-2 pmxcfs[2545]: [status] notice: received sync request (epoch 1/2274/00000006)
Mar 07 16:28:44 vm-2 pmxcfs[2545]: [status] notice: received sync request (epoch 1/2274/00000007)
root@vm-2:~# systemctl status pvestatd.service
● pvestatd.service - PVE Status Daemon
Loaded: loaded (/lib/systemd/system/pvestatd.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2019-01-03 09:39:19 CET; 2 months 2 days ago
Main PID: 3353 (pvestatd)
Tasks: 1 (limit: 7372)
Memory: 82.9M
CPU: 1d 4h 8min 453ms
CGroup: /system.slice/pvestatd.service
└─3353 pvestatd
Mar 07 15:09:48 vm-2 pvestatd[3353]: got timeout
Mar 07 15:09:48 vm-2 pvestatd[3353]: status update time (5.179 seconds)
Mar 07 15:34:28 vm-2 pvestatd[3353]: got timeout
Mar 07 15:34:28 vm-2 pvestatd[3353]: status update time (5.168 seconds)
Mar 07 15:34:38 vm-2 pvestatd[3353]: got timeout
Mar 07 15:34:38 vm-2 pvestatd[3353]: status update time (5.188 seconds)
Mar 07 15:34:48 vm-2 pvestatd[3353]: got timeout
Mar 07 15:34:48 vm-2 pvestatd[3353]: status update time (5.182 seconds)
Mar 07 15:34:58 vm-2 pvestatd[3353]: got timeout
Mar 07 15:34:58 vm-2 pvestatd[3353]: status update time (5.178 seconds)
● pvestatd.service - PVE Status Daemon
Loaded: loaded (/lib/systemd/system/pvestatd.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2019-01-03 09:39:19 CET; 2 months 2 days ago
Main PID: 3353 (pvestatd)
Tasks: 1 (limit: 7372)
Memory: 82.9M
CPU: 1d 4h 8min 453ms
CGroup: /system.slice/pvestatd.service
└─3353 pvestatd
Mar 07 15:09:48 vm-2 pvestatd[3353]: got timeout
Mar 07 15:09:48 vm-2 pvestatd[3353]: status update time (5.179 seconds)
Mar 07 15:34:28 vm-2 pvestatd[3353]: got timeout
Mar 07 15:34:28 vm-2 pvestatd[3353]: status update time (5.168 seconds)
Mar 07 15:34:38 vm-2 pvestatd[3353]: got timeout
Mar 07 15:34:38 vm-2 pvestatd[3353]: status update time (5.188 seconds)
Mar 07 15:34:48 vm-2 pvestatd[3353]: got timeout
Mar 07 15:34:48 vm-2 pvestatd[3353]: status update time (5.182 seconds)
Mar 07 15:34:58 vm-2 pvestatd[3353]: got timeout
Mar 07 15:34:58 vm-2 pvestatd[3353]: status update time (5.178 seconds)
Der pvestatd sieht verdächtig aus. Ich traue mich aber nicht, den jetzt neu zu starten. Auf dem Host laufen VMs die wir für den Betrieb brauchen und ich kann die VMs gerade ja nicht migrieren.
Zu dem Zeitpunkt als der Fehler aufgetreten ist sind keinerlei Veränderungen am Cluster vorgenommen worden. Alle VMs sind normal erreichbar, Ceph läuft problemlos. Deshalb lasse ich den Cluster erstmal einfach so laufen. Ich hoffe das lässt sich ohne Down-Time lösen...
Hat jemand eine Idee? Welche Infos braucht ihr zur Fehlersuche noch?
Ich hätte noch das Syslog, aber heute Nachmittag gab es ein Turnover, da müsste ich erstmal gucken wo was interessantes drin steht und wie man da ran kommt. Bin nicht so der Profi was journalctl angeht.
