In letzter Zeit immer wieder hängende Backups von ceph -> nfs

[fips]

6 nodes davon 3x Ceph Mon, 1x Ceph OSDs, 2x nur VM/CT node.
1x NFS Backup

Ceph: Bluestore auf SSDs

Ceph Netzwerk und Backup Netzwerk liegen auf 10G
Cluster und VM auf jeweils VLAN getrennten 1G.

Kernel: Linux 4.15.17-1-pve #1 SMP PVE 4.15.17-9
PVE Manager: pve-manager/5.2-1/0fcd7879

Node Hardware: HP 360/380 G7 und G8
Backup: Supermicro und FreeNAS


Ich habe jetzt mal einen Cronjob in einem der "bösen" CTs eingerichtet, welcher 15 Minuten vor dem Backup einen Neustart durchführt.
Vielleicht ist ja irgendwas gelockt und daher kann der Snapshot nicht durchgeführt werden.

 

[fips]

ok, der Reboot hat nichts gebracht, ein Backupjob hing heute wieder.
Durch das letzte Post sieht man auch, dass es eben nur ab und an passiert. Sind jetzt ja doch 9 Tage vergangen und es hat dazwischen problemlos gesichert.

 

[Alwin]

6 nodes davon 3x Ceph Mon, 1x Ceph OSDs, 2x nur VM/CT node.

Die anderen Nodes halten keine OSDs? Wenn nicht, dann steht das Cluster, wenn die eine Node ausfällt oder genug OSDs. Auch wird diese Node zum Engpass, da alle Daten nur auf diese geschrieben werden. Ceph braucht und profitiert stark von der Verteilung der Daten.

Ich habe jetzt mal einen Cronjob in einem der "bösen" CTs eingerichtet, welcher 15 Minuten vor dem Backup einen Neustart durchführt.
Vielleicht ist ja irgendwas gelockt und daher kann der Snapshot nicht durchgeführt werden.

can't aquire lock '/var/run/vzdump.lock' - got timeout

Das Lock wird außerhalb des Containers, von vzdump gesetzt. Sehr Wahrscheinlich läuft ein Backup Prozess eines andere Containers, zu dieser Zeit. Das Timeout beträgt standardmäßig 2 Stunden.

Ein tieferer Einblick, was zu diesem Zeitpunkt auf dem System los ist, kann mit atop, sar und den syslog/journal logs gewonnen werden. Die Tools bieten eine Möglichkeit das Geschehen aufzuzeichnen.

http://www.linux-magazin.de/ausgaben/2011/07/realtime-monitoring/
https://www.thomas-krenn.com/de/wiki/Linux_Performance_Aufzeichnung_und_Auswertung_mit_sar

 

[fips]

Sorry hab das dumm geschrieben:
Es sind insgesamt 6 nodes: 3 als Ceph Mon und OSDs, 1er nur mit OSDs (kein Mon) und 2 sind ohne Ceph (keine OSDs, kein Mon).

Zwischen dem letzten "regulären" Backup Job (der immer erfolgreich ist) und dem Task mit den "bösens" CTs vergehen 4:30 Stunden...

Da es sich ja um CTs handelt würde es reichen die Monitoringtools auf dem node auszuführen oder?


EDIT:
Heute war dieser Eintrag im Syslog des node:

Jul 18 05:00:01 ceph6 CRON[1708850]: (root) CMD (vzdump 208 209 --mailnotification always --quiet 1 --compress lzo --storage Backup --mode snapshot --mailto admin@example.com)
Jul 18 05:00:02 ceph6 vzdump[1708851]: <root@pam> starting task UPID:ceph6:001A1334:02F2E8D1:5B4EAD32:vzdump::root@pam:
Jul 18 05:00:02 ceph6 vzdump[1708852]: INFO: starting new backup job: vzdump 208 209 --compress lzo --storage Backup --mailto admin@example.com --mailnotification always --mode snapshot --quiet 1
Jul 18 05:00:02 ceph6 vzdump[1708852]: INFO: Starting Backup of VM 208 (lxc)
Jul 18 05:00:30 ceph6 kernel: [494743.654179] Modules linked in: veth rbd libceph nfsv3 nfs_acl nfs lockd grace fscache ip_set ip6table_filter ip6_tables xfs iptable_filter softdog nfnetlink_log nfnetlink dm_thin_pool dm_persistent_data dm_bio_prison dm_bufio intel_rapl sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel ipmi_ssif kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel aes_x86_64 crypto_simd glue_helper cryptd zfs(PO) zunicode(PO) zavl(PO) icp(PO) intel_cstate mgag200 ttm drm_kms_helper drm fb_sys_fops syscopyarea sysfillrect sysimgblt hpilo intel_rapl_perf snd_pcm snd_timer snd soundcore pcspkr serio_raw lpc_ich shpchp ioatdma ipmi_si ipmi_devintf ipmi_msghandler mac_hid acpi_power_meter zcommon(PO) znvpair(PO) spl(O) vhost_net vhost tap ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp
Jul 18 05:00:30 ceph6 kernel: [494743.654579] Hardware name: HP ProLiant DL380p Gen8, BIOS P70 07/01/2015
Jul 18 05:00:30 ceph6 kernel: [494743.654634] RIP: 0010:rbd_queue_workfn+0x462/0x4f0 [rbd]
Jul 18 05:00:30 ceph6 kernel: [494743.654714] RDX: 0000000000000000 RSI: 0000000000000082 RDI: ffff9eaedee56490
Jul 18 05:00:30 ceph6 kernel: [494743.655698] R13: ffff9ea21ded1680 R14: 0000000000000000 R15: 0000000000001000
Jul 18 05:00:30 ceph6 kernel: [494743.658411] CR2: 0000559c0af78548 CR3: 00000009eb00a006 CR4: 00000000000606e0
Jul 18 05:00:30 ceph6 kernel: [494743.661081]  process_one_work+0x1e0/0x400
Jul 18 05:00:30 ceph6 kernel: [494743.663723]  ? process_one_work+0x400/0x400
Jul 18 05:00:30 ceph6 kernel: [494743.666607]  ? SyS_exit_group+0x14/0x20
Jul 18 05:00:30 ceph6 kernel: [494743.670039] RIP: rbd_queue_workfn+0x462/0x4f0 [rbd] RSP: ffffb0c37107be18
Jul 18 05:01:00 ceph6 systemd[1]: Starting Proxmox VE replication runner...
Jul 18 05:01:01 ceph6 systemd[1]: Started Proxmox VE replication runner.
Jul 18 05:02:00 ceph6 systemd[1]: Starting Proxmox VE replication runner...
Jul 18 05:02:01 ceph6 systemd[1]: Started Proxmox VE replication runner.
Jul 18 05:03:00 ceph6 systemd[1]: Starting Proxmox VE replication runner...

 

[Alwin]

Sorry hab das dumm geschrieben:
Es sind insgesamt 6 nodes: 3 als Ceph Mon und OSDs, 1er nur mit OSDs (kein Mon) und 2 sind ohne Ceph (keine OSDs, kein Mon).

Macht nix, dann passt ja eh das Setup.

Da es sich ja um CTs handelt würde es reichen die Monitoringtools auf dem node auszuführen oder?

Ja und genug Platz für die Aufzeichnung sollte vorhanden sein.

 

[fips]

Ich habe nun vor gut 2 Monaten die 3 CTs vom Ceph Storage auf das local Storage verschoben, Backup mit lokalem tmp wie zuvor auf das NFS, und nun ist Schluss mit den hängenden Backups.

Ich werde mal die Nodes mit den neuesten Updates versorgen und dann die CTs wieder auf das Ceph legen.

 

[fips]

Hab nur mal eine CT von local wieder zurück auf Ceph Storage gelegt und gestern hatte ich das gleiche Problem mit dem hängenden Backup wieder.

 

[Alwin]

Hab nur mal eine CT von local wieder zurück auf Ceph Storage gelegt und gestern hatte ich das gleiche Problem mit dem hängenden Backup wieder.

Und hat die Aufzeichnung etwas ergeben?

 

[Mario Hosse]

Schreib uns bitte einmal die gesetzten Optionen auf dem NFS-Server /etc/exports!
z.B.:
(rw,acl,async,no_root_squash,no_subtree_check)