sanlock 的 wdmd 看门狗在多 vg 场景下不适合启用：只要一个锁空间续约失败，wdmd 就不喂狗，导致宿主机被强制重启。上层的事应该上层做，双写并发控制应该用业务全局锁，而不是依赖底层存储机制。

现象

sanlock 这里，还是应该把 wdmd 给禁用了。尤其是在多 vg 场景下，不太适合。

根因

wdmd 是什么

wdmd 是 Watchdog Multiplexing Daemon（看门狗多路复用守护进程）。

为什么多 vg 场景下不适合

  1. 一个锁空间，sanlock 会和 wdmd 建立一个连接。一个 vg 一个锁空间。
  2. 只要有一个锁空间续约失败，wdmd 就不会喂狗。

所以，如果一个 vg 断联了，其他 vg 正常，客户其实不希望关闭宿主机。

哪些情况会触发 reset

  • 存储 IO 压力大，也会导致 sanlock 续约失败，但是上面的虚拟机是正常的；
  • 如果 wdmd 自身异常了，也会触发 watchdog reset；
  • 如果 sanlock 服务异常了，也会触发 watchdog reset；
  • 有些慢存储，sanlock 容易锁过期、失效，也会触发 reset。

这些都不是用户想看到的。

设计思考

sanlock 是个底层存储锁，但是上层应用有自己的场景和控制逻辑。

底层做，只能一刀切：

  • 要么很严格，动不动就关宿主机了；
  • 要么很宽松，那可能还是会造成双写数据不安全。

上层的事上层做。

双写，终究是因为有两个虚拟机。

所以，要在创建虚拟机那里使用业务的全局锁，来做并发控制，而不是依赖底层存储机制。

小结

  • wdmd 看门狗在多 vg 场景下不适合启用；
  • 只要一个锁空间续约失败，wdmd 就不喂狗，导致宿主机被强制重启；
  • 存储 IO 压力大、wdmd 异常、sanlock 异常、慢存储锁过期，都可能触发 reset；
  • 底层锁只能一刀切，双写并发控制应该用业务全局锁，上层的事上层做。