高可用要么不做，要么做完善：fence 是必备

稳定性相关的，要么不做，要么就要完善，要不然做了高可用，反而造成雪崩。高可用必备 fence，fence 就是 ipmi 强制关机，这是最稳妥的方式。

核心：高可用要么不做，要么做完善

稳定性相关的，要么不做，要么就要完善。

要不然做了高可用，反而造成雪崩。

比如一个 hyper 负载很高，本来可能 hyper 上个别业务有影响，结果触发灾难迁移，然后又迁移失败，反而导致多业务受影响，且恢复 2 天。哪个客户能接受！

比如我们的灾难，触发了，迁移到一半又发现空间不足，迁移失败。就是不完整嘛，能不能迁移，要提前规划好，不能迁移就不要动 hyper。告警通知给用户，用户自己处理。

半死不活的状态，客户更希望给他们通知，他们自己处理，而不是我们下线 hyper。

灾难当然复杂，尤其是半死不活的状态，就是薛定谔的猫，这种确实不好处理。

所以更需要多方参照开源系统的设计，看他们背后的考量和策略，结合我们自己的业务来系统性的设计，而不是打补丁式的缝缝补补。

比如增加超时时间，比如增加个 ping 检查，比如增加个本地自检。

fence 就是 ipmi 强制关机，这就是最稳妥的方式。

其他方式都会有各种问题，且会带来其他复杂性。

比如自检，节点都有异常了，怎么保证自检能正常运行？

外部观察是通过网络观察的，所有网络如果有问题就会判断为有问题，这种情况自检是正常的，两者如何协作？

自检和外部检测是独立的，如果要协作就涉及到网络和协同，这两个本身就很复杂，再加上两个复杂的检测。

如果不协同，保持独立，那么两者的时间差会导致哪些状况？又是复杂场景。

如果采用集中式观察，采用 fence，这是业界主流的做法。

这里面的要素是什么？

node 和资源，node 和资源的状态，非常非常重要。

要通过状态在分布式环境下协同控制。

状态，状态，状态。一定要围绕最终状态，一定要维护好最终状态，一定要确保最终状态的一致性、正确性。

然后其他机制都围绕最终状态设计。

这样通过最终状态，来解耦各种前因后果，解耦异常事件和恢复处理。

为什么这两个解耦非常重要？

因为异常事件千千万，不同的异常的恢复处理也不同，形成千丝万缕，一个网状复杂性。

但是通过状态来解耦后，各种异常回归到状态，状态再对应到恢复处理。这是一个港股，两头各种线，线性复杂性。

这其实又对应到 k8s 的声明式哲学。

在当前系统已有架构下，核心状态就是两个维度：

node 可能无法期望，因为硬件可能客观因素故障。vm 是有期望状态的，比如期望是运行，实际是关机的。