锁

sanlock 的 wdmd 看门狗在多 vg 场景下不适合启用：只要一个锁空间续约失败，wdmd 就不喂狗，导致宿主机被强制重启。上层的事应该上层做，双写并发控制应该用业务全局锁，而不是依赖底层存储机制。 现象 sanlock 这里，还是应该把 wdmd 给禁用了。尤其是在多 vg 场景下，不太适合。 根因 wdmd 是什么 wdmd 是 Watchdog Multiplexing Daemon（看门狗多路复用守护进程）。 为什么多 vg 场景下不适合 一个锁空间，sanlock 会和 wdmd 建立一个连接。一个 vg 一个锁空间。 只要有一个锁空间续约失败，wdmd 就不会喂狗。 所以，如果一个 vg 断联了，其他 vg 正常，客户其实不希望关闭宿主机。 哪些情况会触发 reset 存储 IO 压力大，也会导致 sanlock 续约失败，但是上面的虚拟机是正常的； 如果 wdmd 自身异常了，也会触发 watchdog reset； 如果 sanlock 服务异常了，也会触发 watchdog reset； 有些慢存储，sanlock 容易锁过期、失效，也会触发 reset。 这些都不是用户想看到的。 设计思考 sanlock 是个底层存储锁，但是上层应用有自己的场景和控制逻辑。 底层做，只能一刀切： 要么很严格，动不动就关宿主机了； 要么很宽松，那可能还是会造成双写数据不安全。 上层的事上层做。 双写，终究是因为有两个虚拟机。 所以，要在创建虚拟机那里使用业务的全局锁，来做并发控制，而不是依赖底层存储机制。 小结 wdmd 看门狗在多 vg 场景下不适合启用； 只要一个锁空间续约失败，wdmd 就不喂狗，导致宿主机被强制重启； 存储 IO 压力大、wdmd 异常、sanlock 异常、慢存储锁过期，都可能触发 reset； 底层锁只能一刀切，双写并发控制应该用业务全局锁，上层的事上层做。