On 2021/1/22 16:17, Ulrich Windl wrote:
Gang He schrieb am 22.01.2021 um 09:13 in Nachricht
<1fd1c07d-d12c-fea9-4b17-90a977fe7...@suse.com>:
Hi Ulrich,
I reviewed the crm configuration file, there are some comments as below,
1) lvmlockd resource is used for shared VG, if you do not plan to add
any shared VG in your cluster, I suggest to drop this resource and clone.
2) second, lvmlockd service depends on DLM service, it will create
"lvm_xxx" related lock spaces when any shared VG is created/activated.
but some other resource also depends on DLM to create lock spaces for
avoiding race condition, e.g. clustered MD, ocfs2, etc. Then, the file
system resource should start later than lvm2(lvmlockd) related resources.
That means this order should be wrong.
order ord_lockspace_fs__lvmlockd Mandatory: cln_lockspace_ocfs2 cln_lvmlock
But cln_lockspace_ocfs2 provides the shared filesystem that lvmlockd uses. I
thought for locking in a cluster it needs a cluster-wide filesystem.
ocfs2 file system resource only depends on DLM resource if you use a
shared raw disk(e.g /dev/vdb3), e.g.
primitive dlm ocf:pacemaker:controld \
op start interval=0 timeout=90 \
op stop interval=0 timeout=100 \
op monitor interval=20 timeout=600
primitive ocfs2-2 Filesystem \
params device="/dev/vdb3" directory="/mnt/shared" fstype=ocfs2 \
op monitor interval=20 timeout=40
group base-group dlm ocfs2-2
clone base-clone base-group
If you use ocfs2 file system on top of shared VG(e.g./dev/vg1/lv1), you
need to add lvmlock/LVM-activate resource before ocfs2 file system, e.g.
primitive dlm ocf:pacemaker:controld \
op monitor interval=60 timeout=60
primitive lvmlockd lvmlockd \
op start timeout=90 interval=0 \
op stop timeout=100 interval=0 \
op monitor interval=30 timeout=90
primitive ocfs2-2 Filesystem \
params device="/dev/vg1/lv1" directory="/mnt/shared" fstype=ocfs2 \
op monitor interval=20 timeout=40
primitive vg1 LVM-activate \
params vgname=vg1 vg_access_mode=lvmlockd activation_mode=shared \
op start timeout=90s interval=0 \
op stop timeout=90s interval=0 \
op monitor interval=30s timeout=90s
group base-group dlm lvmlockd vg1 ocfs2-2
clone base-clone base-group
Thanks
Gang
Thanks
Gang
On 2021/1/21 20:08, Ulrich Windl wrote:
Gang He schrieb am 21.01.2021 um 11:30 in Nachricht
<59b543ee-0824-6b91-d0af-48f66922b...@suse.com>:
Hi Ulrich,
The problem is reproduced stably? could you help to share your
pacemaker crm configure and OS/lvm2/resource‑agents related version
information?
OK, the problem occurred on every node, so I guess it's reproducible.
OS is SLES15 SP2 with all current updates (lvm2-2.03.05-8.18.1.x86_64,
pacemaker-2.0.4+20200616.2deceaa3a-3.3.1.x86_64,
resource-agents-4.4.0+git57.70549516-3.12.1.x86_64).
The configuration (somewhat trimmed) is attached.
The only VG the cluster node sees is:
ph16:~ # vgs
VG #PV #LV #SN Attr VSize VFree
sys 1 3 0 wz--n- 222.50g0
Regards,
Ulrich
I feel the problem was probably caused by lvmlock resource agent script,
which did not handle this corner case correctly.
Thanks
Gang
On 2021/1/21 17:53, Ulrich Windl wrote:
Hi!
I have a problem: For tests I had configured lvmlockd. Now that the
tests
have ended, no LVM is used for cluster resources any more, but lvmlockd
is
still configured.
Unfortunately I ran into this problem:
On OCFS2 mount was unmounted successfully, another holding the lockspace
for
lvmlockd is still active.
lvmlockd shuts down. At least it says so.
Unfortunately that stop never succeeds (runs into a timeout).
My suspect is something like this:
Some non‑LVM lock exists for the now unmounted OCFS2 filesystem.
lvmlockd want to access that filesystem for unknown reasons.
I don't understand waht's going on.
The events at nod shutdown were:
Some Xen PVM was live‑migrated successfully to another node, but during
that
there was a message like this:
Jan 21 10:20:13 h19 virtlockd[41990]: libvirt version: 6.0.0
Jan 21 10:20:13 h19 virtlockd[41990]: hostname: h19
Jan 21 10:20:13 h19 virtlockd[41990]: resource busy: Lockspace resource
'4c6bebd1f4bc581255b422a65d317f31deef91f777e51ba0daf04419dda7ade5' is not
locked
Jan 21 10:20:13 h19 libvirtd[41991]: libvirt version: 6.0.0
Jan 21 10:20:13 h19 libvirtd[41991]: hostname: h19
Jan 21 10:20:13 h19 libvirtd[41991]: resource busy: Lockspace resource
'4c6bebd1f4bc581255b422a65d317f31deef91f777e51ba0daf04419dda7ade5' is not
locked
Jan 21 10:20:13 h19 libvirtd[41991]: Unable to release lease on
test‑jeos4
Jan 21 10:20:13 h19 VirtualDomain(prm_xen_test‑jeos4)[32786]: INFO:
test‑jeos4: live migration to h18 succeeded.
Unfortnuately the log message makes it practically impossible to guess
what
the locked object actually is (indirect lock using SHA256 as hash it
seems).
Then the OCFS for the VM images unmounts successfully while the stop of
lvmlockd is still busy:
Jan 21 10:20:16 h19 lvmlockd(prm_lvmlockd)[32945]: INFO:
