[SOLVED] Einige Nodes ignorieren Backupjobs

N

NothingTV

Member
Nov 4, 2019
20
1
23
Hi,

wir bauen derzeit einen Proxmox Cluster auf basis von Ceph Storage auf und stoßen leider auf immer mehr Kinderkrankheiten.

Derzeit bspw. ignorieren einige Nodes jegliche Backupjobs. Es wird nichts gelogged, startet man die Backups manuell läuft er einwandfrei durch, er startet lediglich nicht von alleine. Die Uhrzeit usw. passen, wonach könnte man noch schauen, um das Problem einzugrenzen? Bzw. was für Informationen werden benötigt um da etwas besser helfen zu können?

Wir verwenden Proxmox VE 7.3-6, es sind derzeit vier Nodes im Cluster, 2 davon ignorieren die Backup jobs (daily Backup von ALLEN VMs auf ALLEN Nodes).
 
Ich habe schon viele Cluster installiert und sowas noch nie gesehen.
Tauchen in den Logs Fehler auf?
Wie ist die Corosync Konfiguration?
 
Verzeihung für die späte Antwort.

In den Logs konnten wir absolut nichts dazu sehen, fallen dir spezielle Logs dazu ein? Wir sehen nirgends irgendwelche Fehler.

Hier unsere Corosync.conf:
Bash: 
logging {
  debug: off
  to_syslog: yes
}

nodelist {
  node {
    name: nodename-6
    nodeid: 6
    quorum_votes: 1
    ring0_addr: 10.0.4.6
  }
  node {
    name: nodename-5
    nodeid: 5
    quorum_votes: 1
    ring0_addr: 10.0.3.6
  }
  node {
    name: nodename-2
    nodeid: 2
    quorum_votes: 1
    ring0_addr: 10.0.3.2
  }
  node {
    name: nodename-3
    nodeid: 3
    quorum_votes: 1
    ring0_addr: 10.0.3.3
  }
  node {
    name: nodename-1
    nodeid: 1
    quorum_votes: 1
    ring0_addr: 10.0.3.1
  }
  node {
    name: nodename-4
    nodeid: 4
    quorum_votes: 1
    ring0_addr: 10.0.3.4
  }
}

quorum {
  provider: corosync_votequorum
}

totem {
  cluster_name: Cluster-Name
  config_version: 12
  interface {
    linknumber: 0
  }
  ip_version: ipv4-6
  link_mode: passive
  secauth: on
  version: 2
}

Jeder Node verfügt über eine lokale IPv4 (3 Nodes auch eine öffentliche IPv4) und eine öffentliche IPv6.
 
Hi,
bitte die Ausgabe von folgenden Kommandos posten:
Code: 
pveversion -v
cat /etc/pve/jobs.cfg
cat /etc/pve/vzdump.cron
Was sagt denn systemctl status pvescheduler.service auf den problematischen Nodes?
 
Hier die Ausgabe des Nodes den wir mehr oder weniger derzeit als "Manager" missbrauchen:
proxmox-ve: 7.3-1 (running kernel: 5.15.83-1-pve)
pve-manager: not correctly installed (running version: 7.3-6/723bb6ec)
pve-kernel-helper: 7.3-4
pve-kernel-5.15: 7.3-1
pve-kernel-5.15.83-1-pve: 5.15.83-1
pve-kernel-5.15.30-2-pve: 5.15.30-3
ceph-fuse: 15.2.16-pve1
corosync: 3.1.7-pve1
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-pve2
libproxmox-acme-perl: 1.4.3
libproxmox-backup-qemu0: 1.3.1-1
libpve-access-control: 7.3-1
libpve-apiclient-perl: 3.2-1
libpve-common-perl: 7.3-2
libpve-guest-common-perl: 4.2-3
libpve-http-server-perl: 4.1-5
libpve-storage-perl: 7.3-2
libspice-server1: 0.14.3-2.1
lvm2: 2.03.11-2.1
lxc-pve: 5.0.2-1
lxcfs: 5.0.3-pve1
novnc-pve: 1.3.0-3
openvswitch-switch: residual config
proxmox-backup-client: 2.3.3-1
proxmox-backup-file-restore: 2.3.3-1
proxmox-mail-forward: 0.1.1-1
proxmox-mini-journalreader: 1.3-1
proxmox-offline-mirror-helper: 0.5.1-1
proxmox-widget-toolkit: 3.5.5
pve-cluster: 7.3-2
pve-container: 4.4-2
pve-docs: 7.3-1
pve-edk2-firmware: 3.20220526-1
pve-firewall: 4.2-7
pve-firmware: 3.6-3
pve-ha-manager: 3.5.1
pve-i18n: 2.8-2
pve-qemu-kvm: 7.1.0-4
pve-xtermjs: 4.16.0-1
qemu-server: 7.3-3
smartmontools: 7.2-pve3
spiceterm: 3.2-2
swtpm: 0.8.0~bpo11+2
vncterm: 1.7-1
zfsutils-linux: 2.1.9-pve1

vzdump: backup-c1afe881-7f49
schedule sun 01:00
enabled 1
mailnotification failure
mailto -----
mode snapshot
notes-template {{guestname}}
storage pbs1
vmid 900,107,999,998,903,902,901

vzdump: backup-4bdaee9a-0156
schedule 1:00
all 1
enabled 1
mailnotification failure
mailto -----
mode snapshot
node node-2
notes-template {{guestname}}
repeat-missed 1
storage pbs1

vzdump: backup-3b88f295-679b
schedule 3:00
all 1
enabled 1
mailnotification failure
mailto -----
mode snapshot
node node-2
notes-template {{guestname}}
repeat-missed 0
storage pbs1

vzdump: backup-26a95dcc-f120
schedule 5:00
all 1
enabled 1
mailnotification failure
mailto -----
mode snapshot
node node-1
notes-template {{guestname}}
repeat-missed 0
storage pbs1

vzdump: backup-85ed683e-371b
schedule 04:00
all 1
enabled 1
mailnotification failure
mailto -----
mode snapshot
node node-4
notes-template {{guestname}}
repeat-missed 0
storage pbs1

vzdump: d2659996-a9eb-4424-8c17-67af3af39518
schedule 07:00
compress zstd
enabled 1
mode snapshot
prune-backups keep-last=2
remove 1
repeat-missed 1
storage pbs2
vmid 342

vzdump: ca3261f9-1354-433e-b8d4-da46aaeab4c9
schedule 15:00
compress zstd
enabled 1
mode snapshot
prune-backups keep-last=1
remove 1
storage pbs2
vmid 481

vzdump: d2bf6060-2857-4353-833e-b7f979a036f0
schedule mon,fri,wed 06:00
compress zstd
enabled 1
mailto ----
mode snapshot
prune-backups keep-last=1
remove 1
storage pbs2
vmid 334

vzdump: 25b176ff-32d3-4b9a-8787-7c94a5f527f4
schedule tue,thu,fri,sat,sun 05:05
compress zstd
enabled 1
mailto ----
mode snapshot
prune-backups keep-last=1
remove 1
storage pbs2
vmid 307

vzdump: 4b3b265d-e323-4af1-8b06-5e9934ac28cc
schedule sun 11:00
compress zstd
enabled 1
mailto ----
mode snapshot
prune-backups keep-last=1
remove 1
storage pbs2
vmid 202

vzdump: 0864aaa4-f0c2-4183-b1b7-b9a6e059b010
schedule mon 07:00
compress zstd
enabled 1
mode snapshot
prune-backups keep-last=1
remove 1
storage pbs2
vmid 426

vzdump: backup-fcc10cc1-d08d
schedule 6:00
all 1
compress zstd
enabled 1
mailnotification failure
mailto ---
mode snapshot
node node-5
notes-template {{guestname}}
storage pbs1

vzdump: backup-fa691b73-1814
schedule 7:00
all 1
enabled 1
mailnotification failure
mailto ---
mode snapshot
node node-5
notes-template {{guestname}}
storage pbs1

# cluster wide vzdump cron schedule
# Automatically generated file - do not edit

PATH="/usr/sbin:/usr/bin:/sbin:/bin"

Spannend, der Befehl systemctl status pvescheduler.service zeigt, dass der Dienst inactive (dead) ist, startet man ihn, lädt er derzeit unendlich lange (noch kein timeout in Sicht)

Ist das gewollt, dass node6 in einem anderen IP Kreis ist?
Click to expand...
Tatsächlich nicht, wurde direkt beanstandet, der Node kam gestern erst dazu.
 
Last edited:
Code: 
nodename-[1-4] = 10.0.3.[1-4]
nodename-5     = 10.0.3.6

Monk triggered! o_O *scnr* :D
 
NothingTV said:
proxmox-ve: 7.3-1 (running kernel: 5.15.83-1-pve)
pve-manager: not correctly installed (running version: 7.3-6/723bb6ec)
Click to expand...
Wieso der pve-manager auf not correctly installed steht, würde ich einmal hinterfragen.
 
  • Like
Reactions: Neobin
NothingTV said:
Spannend, der Befehl systemctl status pvescheduler.service zeigt, dass der Dienst inactive (dead) ist, startet man ihn, lädt er derzeit unendlich lange (noch kein timeout in Sicht)
Click to expand...
Dieser Service ist für das Starten der Backup-Jobs verantwortlich, also liegt da das Problem. Wie schon vorgeschlagen wurde, als erstes würde ich mal versuchen pve-manager neu zu installieren. Steht irgendwas in den Logs, e.g. journalctl -b -u pvescheduler.service?
 
Monk triggered!
Click to expand...
same here, steht auf der To-Do :D
Code: 
apt-get install --reinstall pve-manager
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following package was automatically installed and is no longer required:
  openvswitch-common
Use 'apt autoremove' to remove it.
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 20 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
E: Internal Error, No file name for pve-manager:amd64
Das ist spannend.

Die Ausgabe von journalctl -b -u pvescheduler.service ist leer: -- No entries --

Ausgabe von systemctl status pve-guests.service
Code: 
● pve-guests.service - PVE guests
     Loaded: loaded (/lib/systemd/system/pve-guests.service; enabled; vendor preset: enabled)
     Active: activating (start) since Sun 2023-02-05 22:32:10 CET; 1 months 1 days ago
   Main PID: 4915 (pvesh)
      Tasks: 2 (limit: 629145)
     Memory: 101.7M
        CPU: 47.430s
     CGroup: /system.slice/pve-guests.service
             └─4915 /usr/bin/perl /usr/bin/pvesh --nooutput create /nodes/localhost/startall

Feb 05 22:43:31 node-1 pvesh[4915]: Starting VM 256
Feb 05 22:43:31 node-1 pve-guests[118162]: start VM 256: UPID:node-1:0001CD92:000134CB:63E02303:qmstart:256:root@pam:
Feb 05 22:43:31 node-1 pve-guests[4917]: <root@pam> starting task UPID:node-1:0001CD92:000134CB:63E02303:qmstart:256:root@pam:
Feb 05 22:43:36 node-1 pvesh[4915]: Starting VM 258
Feb 05 22:43:36 node-1 pve-guests[4917]: <root@pam> starting task UPID:node-1:0001D00F:000136C1:63E02308:qmstart:258:root@pam:
Feb 05 22:43:36 node-1 pve-guests[118799]: start VM 258: UPID:node-1:0001D00F:000136C1:63E02308:qmstart:258:root@pam:
Feb 05 22:43:39 node-1 pvesh[4915]: received interrupt
Feb 05 22:43:39 node-1 pvesh[4915]: Starting VM 259
Feb 05 22:43:39 node-1 pve-guests[119333]: start VM 259: UPID:node-1:0001D225:000137E1:63E0230B:qmstart:259:root@pam:
Feb 05 22:43:39 node-1 pve-guests[4917]: <root@pam> starting task UPID:node-1:0001D225:000137E1:63E0230B:qmstart:259:root@pam:
Da scheint wirklich etwas zu hängen
 
NothingTV said:
same here, steht auf der To-Do :D
Code: 
apt-get install --reinstall pve-manager
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following package was automatically installed and is no longer required:
  openvswitch-common
Use 'apt autoremove' to remove it.
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 20 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
E: Internal Error, No file name for pve-manager:amd64
Das ist spannend.

Die Ausgabe von journalctl -b -u pvescheduler.service ist leer: -- No entries --

Ausgabe von systemctl status pve-guests.service
Code: 
● pve-guests.service - PVE guests
     Loaded: loaded (/lib/systemd/system/pve-guests.service; enabled; vendor preset: enabled)
     Active: activating (start) since Sun 2023-02-05 22:32:10 CET; 1 months 1 days ago
   Main PID: 4915 (pvesh)
      Tasks: 2 (limit: 629145)
     Memory: 101.7M
        CPU: 47.430s
     CGroup: /system.slice/pve-guests.service
             └─4915 /usr/bin/perl /usr/bin/pvesh --nooutput create /nodes/localhost/startall

Feb 05 22:43:31 node-1 pvesh[4915]: Starting VM 256
Feb 05 22:43:31 node-1 pve-guests[118162]: start VM 256: UPID:node-1:0001CD92:000134CB:63E02303:qmstart:256:root@pam:
Feb 05 22:43:31 node-1 pve-guests[4917]: <root@pam> starting task UPID:node-1:0001CD92:000134CB:63E02303:qmstart:256:root@pam:
Feb 05 22:43:36 node-1 pvesh[4915]: Starting VM 258
Feb 05 22:43:36 node-1 pve-guests[4917]: <root@pam> starting task UPID:node-1:0001D00F:000136C1:63E02308:qmstart:258:root@pam:
Feb 05 22:43:36 node-1 pve-guests[118799]: start VM 258: UPID:node-1:0001D00F:000136C1:63E02308:qmstart:258:root@pam:
Feb 05 22:43:39 node-1 pvesh[4915]: received interrupt
Feb 05 22:43:39 node-1 pvesh[4915]: Starting VM 259
Feb 05 22:43:39 node-1 pve-guests[119333]: start VM 259: UPID:node-1:0001D225:000137E1:63E0230B:qmstart:259:root@pam:
Feb 05 22:43:39 node-1 pve-guests[4917]: <root@pam> starting task UPID:node-1:0001D225:000137E1:63E0230B:qmstart:259:root@pam:
Da scheint wirklich etwas zu hängen
Click to expand...
Bitte um output von:
  • strace -yyttT -f -s 512 -p 4915
  • ps auxwf
  • journalctl -b
 
NothingTV said:
Feb 05 22:43:39 node-1 pvesh[4915]: received interrupt
Click to expand...
Wurde der startup der VMs hier aktiv unterbrochen? Z.B. durch stoppen des startup tasks?
 
Code: 
strace: Process 4915 attached
12:46:21.055511 read(9<pipe:[129077]>,
ps auxwf: https://pastebin.com/EsnRBRde

Der Output von journalctl -b ist ebenfalls seeeeehr lang, wird der gesamte Output benötigt?

Wurde der startup der VMs hier aktiv unterbrochen? Z.B. durch stoppen des startup tasks?
Click to expand...
Prüfte gerade die Logs und tatsächlich gab es da ein Problem weshalb ein Reboot nötig war, daraufhin wurde der Auto-Start Prozess über die Proxmox GUI gestoppt.
 
Last edited:
Okay,
das Fehlerbild bleibt also das gleiche wie bereits bekannt. Ein SIGKILL an den Zombie Prozess und den startall Prozess sollte dazu führen, dass pve-guests.service fertig startet und pvescheduler.service als dessen Abhängigkeit dann auch starten kann. Also:
Code: 
kill -9 4915 4917
systemctl status pve-guests.service pvescheduler.service
 
kill -9 4915 4917
systemctl status pve-guests.service pvescheduler.service
Click to expand...
Das scheint es tatsächlich gewesen zu sein, der pvescheduler.service ist nun gestartet, der pve-manager konnte nun ebenfalls neu installiert werden.

Vielen lieben Dank!

Wir erhalten nun jedoch beim löschen eines Users noch die Meldungen cannot update tfa config, following nodes are not up to date: cluster node 'node-6' is too old, did not broadcast its version inf. Vermutlich weil die interne IP da noch nicht korrekt war, das wurde jedoch in dessen Netzwerk Config sowie der coroconfig angepasst. Es sind auch alle Nodes up-to-date, die Versionen sind identisch. Kann es sein, dass noch zum Abschluss ein reboot nötig ist? Ich mein, wenn dem so ist, wäre das ungünstig, aber mehr fällt uns langsam nicht ein. Die Zeit auf dem Systemen ist identisch, die Versionen (es ist überall die gleiche Proxmox Repo aktiv), die Nodes können sich auch untereinander kommunizieren.
 
NothingTV said:
Das scheint es tatsächlich gewesen zu sein, der pvescheduler.service ist nun gestartet, der pve-manager konnte nun ebenfalls neu installiert werden.

Vielen lieben Dank!

Wir erhalten nun jedoch beim löschen eines Users noch die Meldungen cannot update tfa config, following nodes are not up to date: cluster node 'node-6' is too old, did not broadcast its version inf. Vermutlich weil die interne IP da noch nicht korrekt war, das wurde jedoch in dessen Netzwerk Config sowie der coroconfig angepasst. Es sind auch alle Nodes up-to-date, die Versionen sind identisch. Kann es sein, dass noch zum Abschluss ein reboot nötig ist? Ich mein, wenn dem so ist, wäre das ungünstig, aber mehr fällt uns langsam nicht ein. Die Zeit auf dem Systemen ist identisch, die Versionen (es ist überall die gleiche Proxmox Repo aktiv), die Nodes können sich auch untereinander kommunizieren.
Click to expand...
Wurde beim Editieren der corosync config die Versionsnummer erhöht? Wie ist der derzeitige Status des Clusters?

Bitte um ouput von pvecm status und cat /etc/pve/.members
 
Ja, die wurde um 1 erhöht.

Cluster information
-------------------
Name: censored
Config Version: 13
Transport: knet
Secure auth: on

Quorum information
------------------
Date: Thu Mar 9 16:00:45 2023
Quorum provider: corosync_votequorum
Nodes: 5
Node ID: 0x00000002
Ring ID: 1.122
Quorate: Yes

Votequorum information
----------------------
Expected votes: 6
Highest expected: 6
Total votes: 5
Quorum: 4
Flags: Quorate

Membership information
----------------------
Nodeid Votes Name
0x00000001 1 10.0.3.1
0x00000002 1 10.0.3.2 (local)
0x00000003 1 10.0.3.3
0x00000004 1 10.0.3.4
0x00000006 1 10.0.4.6
{
"nodename": "node-2",
"version": 44,
"cluster": { "name": "censored", "version": 12, "nodes": 6, "quorate": 1 },
"nodelist": {
"node-4": { "id": 4, "online": 1, "ip": "10.0.3.4"},
"node-2": { "id": 2, "online": 1, "ip": "10.0.3.2"},
"node-1": { "id": 1, "online": 1, "ip": "10.0.3.1"},
"node-6": { "id": 6, "online": 1, "ip": "10.0.3.5"},
"node-3": { "id": 3, "online": 1, "ip": "10.0.3.3"},
"node-5": { "id": 5, "online": 0, "ip": "---"} // wird entfernt, da er permanent offline ist, die Meldung betraf nur ID 6
}
}
 
NothingTV said:
Ja, die wurde um 1 erhöht.

Cluster information
-------------------
Name: censored
Config Version: 13
Transport: knet
Secure auth: on

Quorum information
------------------
Date: Thu Mar 9 16:00:45 2023
Quorum provider: corosync_votequorum
Nodes: 5
Node ID: 0x00000002
Ring ID: 1.122
Quorate: Yes

Votequorum information
----------------------
Expected votes: 6
Highest expected: 6
Total votes: 5
Quorum: 4
Flags: Quorate

Membership information
----------------------
Nodeid Votes Name
0x00000001 1 10.0.3.1
0x00000002 1 10.0.3.2 (local)
0x00000003 1 10.0.3.3
0x00000004 1 10.0.3.4
0x00000006 1 10.0.4.6
{
"nodename": "node-2",
"version": 44,
"cluster": { "name": "censored", "version": 12, "nodes": 6, "quorate": 1 },
"nodelist": {
"node-4": { "id": 4, "online": 1, "ip": "10.0.3.4"},
"node-2": { "id": 2, "online": 1, "ip": "10.0.3.2"},
"node-1": { "id": 1, "online": 1, "ip": "10.0.3.1"},
"node-6": { "id": 6, "online": 1, "ip": "10.0.3.5"},
"node-3": { "id": 3, "online": 1, "ip": "10.0.3.3"},
"node-5": { "id": 5, "online": 0, "ip": "---"} // wird entfernt, da er permanent offline ist, die Meldung betraf nur ID 6
}
}
Click to expand...
Okay, vielleicht hilft es diesen node zu rebooten, es scheint der Key Value store nicht aktuell zu sein? Die pveversion des nodes ist die selbe?
 
Last edited:
You must log in or register to reply here.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom
Back