高可用性
了解 DC/OS 中的高可用特性和最佳实践
领导者/追随者架构
Mesos
Mesos 可以高可用性模式运行,需要运行三个或五个主控。在 HA 模式下运行时,一个主控被选为领导者,其他主控则是追随者。每个主控都有一个复制了的日志,其中包含有关群集的某种状态。ZooKeeper 执行选举以选择领导主控。有关这方面的更多信息,请参阅 。
Marathon
Marathon 可以高可用性模式与一个选举的领导者一起运行,使得可以运行多个 Marathon 实例(HA 为至少两个)。Marathon 使用 ZooKeeper 进行领导者选举。追随者不接受写入或 API 请求;相反,追随者代理所有 API 请求代理给领先的 Marathon 实例。
ZooKeeper
故障域隔离
故障域隔离是构建 HA 系统的重要组成部分。为正确处理故障情形,系统必须跨故障域分布,以便在故障后存活。故障域有不同的类型,其中几个例子包括:
- 物理域:包括机器、机架、数据中心、地区和可用性区域。
GROUP_BY
约束算子 来实现。
# 问题的分离
高可用性服务应当分离,责任在服务之间分担。例如,Web 服务应从数据库和共享缓存中分离。
# 消除单一故障点
单一故障点有多种形式。例如,当系统中的每个服务共用一个 ZooKeeper 群集时,类似 ZooKeeper 的服务可能成为单一故障点。您可以通过为单独的服务运行多个 ZooKeeper 群集来降低这些风险。Exhibitor 使得这变得简单。
其他常见的单一故障点包括:
- 单个数据库实例(如 MySQL)
- 一次性服务
- 非 HA 负载均衡器
快速故障检测
快速故障检测有多种形式。ZooKeeper 等服务可用于提供故障检测,例如检测网络分区或主机故障。服务健康状况检查也可用于检测某些类型的故障。作为最佳实践,服务应揭示健康检查端点,这可以被 Marathon 等服务所使用。
快速故障切换
- 使用 HA 负载均衡器,如 Marathon-LB,或内部 。
- 在构建服务时遵循 REST 最佳做法:尤其是避免在请求之间在服务器上存储客户端状态。