Hallo zusammen,
seit geraumer Zeit bin ich auf der Suche warum meine Backups manchmal einfach hängenbleiben.
Ist etwas nervig, aber seit einigen der letzten Proxmox Updates lässt sich die VM zumindest sauber beenden und nach einem Node-Neustart läuft alles wieder. Geht sicher besser, aber mangelndes WIssen wie man den snapshot sauber entsperrt endet halt im Neustart des Nodes.
Erst hatte ich die NFS in Verdacht, aber es scheint aber von Ceph zu kommen.
Die Daten werden von Node1 auf NFS gesichert. ODS0 und OSD1 liegen auf Node1. OSD5 liegt auf Node3.
dmesg:
[Thu Jun 21 17:06:00 2018] libceph: get_reply osd5 tid 438163 data 3997696 > preallocated 65536, skipping
ceph.log:
2018-06-21 17:00:00.000550 mon.node1 mon.0 192.168.1.1:6789/0 606 : cluster [INF] overall HEALTH_OK
2018-06-21 17:06:01.279224 osd.5 osd.5 192.168.1.3:6800/1909 1 : cluster [ERR] 3.2c missing primary copy of 3:34debe98:::rbd_data.ef02d643c9869.00000000000018af:head, will try copies on 1,2
Das Syslog zeigt weder auf dem Node1 noch auf dem NFS zu der Zeit irgendwas Passendes an.
Warum hat Node1 ein Problem, so daß das Backup einfach stehenbleibt, wenn Node3 Fehler auf der Platte findet?
Die Suche ergab: Ein ähnliches Problem ist angeblich gelöst seit Kernel 4.9.14. http://tracker.ceph.com/issues/19189
Der PVE-Kernel ist viel weiter.
Linux Node1 4.15.17-3-pve #1 SMP PVE 4.15.17-13 (Mon, 18 Jun 2018 17:15:04 +0200) x86_64 GNU/Linux
Hat das Problem noch jemand? Kann man da evtl. an der ceph.conf was drehen um das zu verhindern?
Evtl. ein Problem zu langsamer CPUs? Zu wenig Platte? Ceph kommuniziert mit 10GBit via Mesh. Proxmox mit 1GBit auch via Mesh. Backup und allgemeiner Zugriff der VMs laufen über 2 weitere Netzwerkkarten.
Vielen Dank im Voraus.
Gruß
Andreas
seit geraumer Zeit bin ich auf der Suche warum meine Backups manchmal einfach hängenbleiben.
Ist etwas nervig, aber seit einigen der letzten Proxmox Updates lässt sich die VM zumindest sauber beenden und nach einem Node-Neustart läuft alles wieder. Geht sicher besser, aber mangelndes WIssen wie man den snapshot sauber entsperrt endet halt im Neustart des Nodes.
Erst hatte ich die NFS in Verdacht, aber es scheint aber von Ceph zu kommen.
Die Daten werden von Node1 auf NFS gesichert. ODS0 und OSD1 liegen auf Node1. OSD5 liegt auf Node3.
dmesg:
[Thu Jun 21 17:06:00 2018] libceph: get_reply osd5 tid 438163 data 3997696 > preallocated 65536, skipping
ceph.log:
2018-06-21 17:00:00.000550 mon.node1 mon.0 192.168.1.1:6789/0 606 : cluster [INF] overall HEALTH_OK
2018-06-21 17:06:01.279224 osd.5 osd.5 192.168.1.3:6800/1909 1 : cluster [ERR] 3.2c missing primary copy of 3:34debe98:::rbd_data.ef02d643c9869.00000000000018af:head, will try copies on 1,2
Das Syslog zeigt weder auf dem Node1 noch auf dem NFS zu der Zeit irgendwas Passendes an.
Warum hat Node1 ein Problem, so daß das Backup einfach stehenbleibt, wenn Node3 Fehler auf der Platte findet?
Die Suche ergab: Ein ähnliches Problem ist angeblich gelöst seit Kernel 4.9.14. http://tracker.ceph.com/issues/19189
Der PVE-Kernel ist viel weiter.
Linux Node1 4.15.17-3-pve #1 SMP PVE 4.15.17-13 (Mon, 18 Jun 2018 17:15:04 +0200) x86_64 GNU/Linux
Hat das Problem noch jemand? Kann man da evtl. an der ceph.conf was drehen um das zu verhindern?
Evtl. ein Problem zu langsamer CPUs? Zu wenig Platte? Ceph kommuniziert mit 10GBit via Mesh. Proxmox mit 1GBit auch via Mesh. Backup und allgemeiner Zugriff der VMs laufen über 2 weitere Netzwerkkarten.
Vielen Dank im Voraus.
Gruß
Andreas