Fence

稳定性相关的，要么不做，要么就要完善，要不然做了高可用，反而造成雪崩。高可用必备 fence，fence 就是 ipmi 强制关机，这是最稳妥的方式。 核心：高可用要么不做，要么做完善 稳定性相关的，要么不做，要么就要完善。 要不然做了高可用，反而造成雪崩。 比如一个 hyper 负载很高，本来可能 hyper 上个别业务有影响，结果触发灾难迁移，然后又迁移失败，反而导致多业务受影响，且恢复 2 天。哪个客户能接受！ 比如我们的灾难，触发了，迁移到一半又发现空间不足，迁移失败。就是不完整嘛，能不能迁移，要提前规划好，不能迁移就不要动 hyper。告警通知给用户，用户自己处理。 半死不活的状态，客户更希望给他们通知，他们自己处理，而不是我们下线 hyper。 灾难当然复杂，尤其是半死不活的状态，就是薛定谔的猫，这种确实不好处理。 所以更需要多方参照开源系统的设计，看他们背后的考量和策略，结合我们自己的业务来系统性的设计，而不是打补丁式的缝缝补补。 比如增加超时时间，比如增加个 ping 检查，比如增加个本地自检。 高可用必备 fence fence 就是 ipmi 强制关机，这就是最稳妥的方式。 其他方式都会有各种问题，且会带来其他复杂性。 比如自检，节点都有异常了，怎么保证自检能正常运行？ 外部观察是通过网络观察的，所有网络如果有问题就会判断为有问题，这种情况自检是正常的，两者如何协作？ 自检和外部检测是独立的，如果要协作就涉及到网络和协同，这两个本身就很复杂，再加上两个复杂的检测。 如果不协同，保持独立，那么两者的时间差会导致哪些状况？又是复杂场景。 如果采用集中式观察，采用 fence，这是业界主流的做法。 状态，状态，状态 这里面的要素是什么？ node 和资源，node 和资源的状态，非常非常重要。 要通过状态在分布式环境下协同控制。 状态，状态，状态。一定要围绕最终状态，一定要维护好最终状态，一定要确保最终状态的一致性、正确性。 然后其他机制都围绕最终状态设计。 这样通过最终状态，来解耦各种前因后果，解耦异常事件和恢复处理。 为什么这两个解耦非常重要？ 因为异常事件千千万，不同的异常的恢复处理也不同，形成千丝万缕，一个网状复杂性。 但是通过状态来解耦后，各种异常回归到状态，状态再对应到恢复处理。这是一个港股，两头各种线，线性复杂性。 这其实又对应到 k8s 的声明式哲学。 在当前系统已有架构下，核心状态就是两个维度： node，状态：是否正常； vm，状态：属于哪个 node，是否应该运行。 node 可能无法期望，因为硬件可能客观因素故障。vm 是有期望状态的，比如期望是运行，实际是关机的。 小结 高可用要么不做，要么做完善，要不然做了高可用反而造成雪崩； 能不能迁移要提前规划好，不能迁移就不要动 hyper； 高可用必备 fence，fence 就是 ipmi 强制关机，这是最稳妥的方式； 状态，状态，状态，一定要围绕最终状态，维护好最终状态的一致性、正确性； 通过最终状态来解耦异常事件和恢复处理，把网状复杂性变成线性复杂性。