[SOLVED] Replication pending

[Haithabu84]

Hallo,

habe gerade bei einem 2-Node-Cluster ein Problem festgestellt: Auf dem ersten Node laufen drei Container, die per Storage Replication auf den zweiten gebracht werden... auf dem zweiten Node läuft ein VM die auf den ersten Node repliziert wird.

Auf dem ersten Node hängt jetzt aber ein Replicatin Job im Status "syncing - pending" und die anderen Jobs sind ebenfalls pending. Beim zweiten Node die Replikation geht ohne Probleme weiter.

Auf dem ersten Node hängt es komplett.

Was mir auch aufgefallen ist:

2019-10-08 00:15:00 100-0: start replication job
2019-10-08 00:15:00 100-0: guest => CT 100, running => 1
2019-10-08 00:15:00 100-0: volumes => Containers:subvol-100-disk-0
2019-10-08 00:15:01 100-0: freeze guest filesystem
2019-10-08 00:15:01 100-0: create snapshot '__replicate_100-0_1570486500__' on Containers:subvol-100-disk-0
2019-10-08 00:15:01 100-0: thaw guest filesystem
2019-10-08 00:15:01 100-0: incremental sync 'Containers:subvol-100-disk-0' (__replicate_100-0_1570485603__ => __replicate_100-0_1570486500__)

Macht er das freeze/thaw des Filesystems immer, bei jeder Replikation? Ist das überhaupt empfehlenswert das über den Tag laufen zu lassen, wenn auf dem Container gearbeitet wird? Kann das zu irgendwelchen Problemen führen? Auf einem anderen Cluster läuft diese Art der Replikation bisher ohne Probleme.

Wie kann ich sicher die Jobs anhalten/löschen?

 

[Haithabu84]

Ich habe jetzt erstmal mit...

pvesr delete 100-0 --force

geschafft zumindest mal den Replication Job zu löschen.

Danach habe ich gelesen, dass auf der Ziel-Maschine die Datasets und Snapshots gelöscht werden müssen. Da kommt aber schon das nächste Problem:

zfs destroy -R spool/confs/subvol-100-disk-0@__replicate_100-0_1570485603__
cannot destroy 'spool/confs/subvol-100-disk-0/%recv': dataset is busy
cannot destroy snapshot spool/confs/subvol-100-disk-0@__replicate_100-0_1570485603__: snapshot is cloned

Was hat das zu bedeuten? Habe von einem Bug gelesen der eigentlich seit 2017 behoben sein sollte, aber jetzt hier tritt der selbe Fehler auf. Weiß jemand was man da machen kann? Außer die Maschine neu zu booten....

 

[wolfgang]

Hallo,

du hast ein hängendes ZFS.
Genauer gesagt ein hängendes Database.
Das hat wahrscheinlich auch zur Unterbrechung der Synchronisierungsjobs geführt.
Warum das hängt kann ich dir nicht sagen.
Ich würde mal die Logs durchgehen ob man was sieht.

 

[Haithabu84]

Welche Logs kommen den da genau in Frage? Syslog?

Durch die Logrotation ist leider schon das entsprechende Log weg. Ich habe aber gestern schon einen eventuellen Fehler ausgemacht und zwar gab es wohl eine Panic mit "zfs_inode_failure". Den kompletten Screen konnte ich leider nicht mehr sichern. Nach einem Reboot lief es wieder. Muss eventuell sogar mal Firmware-Upgrade bei diesem Server durchführen, da beim Booten schon ein entsprechender Hinweis erscheint.

Habe etwas gefunden:

Oct  8 00:00:06 virt1 kernel: [174122.316197] PANIC at zfs_znode.c:611:zfs_znode_alloc()
Oct  8 00:00:06 virt1 kernel: [174122.316226] Hardware name: Supermicro Super Server/X10SRH-CLN4F, BIOS 2.0 12/17/2015
Oct  8 00:00:06 virt1 kernel: [174122.316243]  spl_dumpstack+0x29/0x2b [spl]
Oct  8 00:00:06 virt1 kernel: [174122.316303]  ? zfs_inode_destroy+0xf8/0x110 [zfs]
Oct  8 00:00:06 virt1 kernel: [174122.316342]  ? evict+0x139/0x1a0
Oct  8 00:00:06 virt1 kernel: [174122.316382]  zfs_znode_alloc+0x625/0x680 [zfs]
Oct  8 00:00:06 virt1 kernel: [174122.316463]  ? __switch_to_asm+0x41/0x70
Oct  8 00:00:06 virt1 kernel: [174122.316467]  ? __switch_to_asm+0x35/0x70
Oct  8 00:00:06 virt1 kernel: [174122.316471]  ? __switch_to_asm+0x41/0x70
Oct  8 00:00:06 virt1 kernel: [174122.316477]  ? __switch_to_asm+0x41/0x70
Oct  8 00:00:06 virt1 kernel: [174122.316485]  taskq_thread+0x310/0x500 [spl]
Oct  8 00:00:06 virt1 kernel: [174122.316490]  kthread+0x120/0x140
Oct  8 00:00:06 virt1 kernel: [174122.316495]  ? __kthread_parkme+0x70/0x70
Oct  8 00:02:10 virt1 kernel: [174245.964018] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Oct  8 00:02:10 virt1 kernel: [174245.964051]  __schedule+0x2d4/0x870
Oct  8 00:02:10 virt1 kernel: [174245.964069]  ? spl_kmem_cache_free+0xb0/0x1d0 [spl]
Oct  8 00:02:10 virt1 kernel: [174245.964201]  ? destroy_inode+0x3e/0x60
Oct  8 00:02:10 virt1 kernel: [174245.964205]  ? insert_inode_locked+0x1d8/0x1e0
Oct  8 00:02:10 virt1 kernel: [174245.964335]  zfs_unlinked_drain_task+0x74/0x100 [zfs]
Oct  8 00:02:10 virt1 kernel: [174245.964340]  ? __switch_to_asm+0x41/0x70
Oct  8 00:02:10 virt1 kernel: [174245.964344]  ? __switch_to_asm+0x35/0x70
Oct  8 00:02:10 virt1 kernel: [174245.964350]  ? __switch_to_asm+0x35/0x70

Was es bedeutet ist mir bisher schleierhaft.

 

[wolfgang]

Welche Proxmox VE Version verwendest du?

pveversion -v

 

[Haithabu84]

Welche Proxmox VE Version verwendest du?

pveversion -v

Node1:

proxmox-ve: 6.0-2 (running kernel: 5.0.21-2-pve)
pve-manager: 6.0-7 (running version: 6.0-7/28984024)
pve-kernel-5.0: 6.0-8
pve-kernel-helper: 6.0-8
pve-kernel-5.0.21-2-pve: 5.0.21-6
pve-kernel-5.0.15-1-pve: 5.0.15-1
ceph-fuse: 12.2.11+dfsg1-2.1+b1
corosync: 3.0.2-pve2
criu: 3.11-3
glusterfs-client: 5.5-3
ksm-control-daemon: 1.3-1
libjs-extjs: 6.0.1-10
libknet1: 1.12-pve1
libpve-access-control: 6.0-2
libpve-apiclient-perl: 3.0-2
libpve-common-perl: 6.0-5
libpve-guest-common-perl: 3.0-1
libpve-http-server-perl: 3.0-2
libpve-storage-perl: 6.0-9
libqb0: 1.0.5-1
lvm2: 2.03.02-pve3
lxc-pve: 3.1.0-65
lxcfs: 3.0.3-pve60
novnc-pve: 1.1.0-1
proxmox-mini-journalreader: 1.1-1
proxmox-widget-toolkit: 2.0-7
pve-cluster: 6.0-7
pve-container: 3.0-7
pve-docs: 6.0-4
pve-edk2-firmware: 2.20190614-1
pve-firewall: 4.0-7
pve-firmware: 3.0-2
pve-ha-manager: 3.0-2
pve-i18n: 2.0-3
pve-qemu-kvm: 4.0.0-5
pve-xtermjs: 3.13.2-1
qemu-server: 6.0-7
smartmontools: 7.0-pve2
spiceterm: 3.1-1
vncterm: 1.6-1
zfsutils-linux: 0.8.1-pve2

Node2:

proxmox-ve: 6.0-2 (running kernel: 5.0.21-2-pve)
pve-manager: 6.0-7 (running version: 6.0-7/28984024)
pve-kernel-5.0: 6.0-8
pve-kernel-helper: 6.0-8
pve-kernel-5.0.21-2-pve: 5.0.21-3
pve-kernel-5.0.15-1-pve: 5.0.15-1
ceph-fuse: 12.2.11+dfsg1-2.1+b1
corosync: 3.0.2-pve2
criu: 3.11-3
glusterfs-client: 5.5-3
ksm-control-daemon: 1.3-1
libjs-extjs: 6.0.1-10
libknet1: 1.12-pve1
libpve-access-control: 6.0-2
libpve-apiclient-perl: 3.0-2
libpve-common-perl: 6.0-4
libpve-guest-common-perl: 3.0-1
libpve-http-server-perl: 3.0-2
libpve-storage-perl: 6.0-8
libqb0: 1.0.5-1
lvm2: 2.03.02-pve3
lxc-pve: 3.1.0-65
lxcfs: 3.0.3-pve60
novnc-pve: 1.0.0-60
proxmox-mini-journalreader: 1.1-1
proxmox-widget-toolkit: 2.0-7
pve-cluster: 6.0-7
pve-container: 3.0-7
pve-docs: 6.0-4
pve-edk2-firmware: 2.20190614-1
pve-firewall: 4.0-7
pve-firmware: 3.0-2
pve-ha-manager: 3.0-2
pve-i18n: 2.0-3
pve-qemu-kvm: 4.0.0-5
pve-xtermjs: 3.13.2-1
qemu-server: 6.0-7
smartmontools: 7.0-pve2
spiceterm: 3.1-1
vncterm: 1.6-1
zfsutils-linux: 0.8.1-pve2

 

[wolfgang]

Gut der pve-kernel-5.0.21-2-pve ist der gefixte.
Kann das sein das der Fehler noch mit älteren Kernel passiert ist?

 

[Haithabu84]

Gut der pve-kernel-5.0.21-2-pve ist der gefixte.
Kann das sein das der Fehler noch mit älteren Kernel passiert ist?

Nein. Da ich beide Server komplett neu aufgesetzt hatte mit Version 6.0 ISO. Es lief also nie eine andere Kernel-Version darauf. Nach der Installation wurden beide ebenfalls geupdatet. Sollten also fast identischen Versionstand bei allen Paketen aufweisen.

 

[wolfgang]

Bitte nochmals updaten mir ist entgangen das du noch die alte 0.8.1 ZFS Version hast.
Dann sollte es auch nicht mehr hängen.
Reboot nicht vergessen.