配置分区和分域

使用 DC/OS 中的高可用性功能

本专题讨论 DC/OS 中的高可用性 (HA) 功能,以及在 DC/OS 上构建 HA 应用程序的最佳做法。

术语

分区

区域是具有隔离电源、网络和连接的故障域。通常,分区是云提供商管理的单个数据中心或本地独立的故障域。例如,AWS 可用性分区或 GCP 分区。分区内的服务器通过高带宽(例如,1-10+ Gbps)、低延迟(高达 1 ms)和低成本链接建立连接。

分域

分域是由一个或多个分区组成的地理分域,例如一片地铁区域。分域内的分区通过高带宽(例如,1-4 Gbps)、低延迟(高达 10 ms)、低成本建立链接。分域通常通过可变带宽通过公共互联网连接(例如,10-100 Mbps) 和延迟 (100-500 ms) 链接。

机架

机架通常由一组服务器(节点)组成。机架有自己的电源和开关,它们全都安装在同一框架上。在 AWS 等公共云平台上,机架没有等效概念。

一般建议

延迟

DC/OS 管理节点应通过高可用性和低延迟网络链路相互连接。这是必须的,因为在这些节点上运行的一些协作组件使用 quorum 写入以实现高可用性。例如,Mesos 管理节点、Marathon 调度器和 ZooKeeper 使用 quorum 写入。

同样,大多数 DC/OS 服务使用 ZooKeeper(或 etcdconsul等等)实现调度器首要实例选择和状态存储。要有效实现这一目标,服务调度器必须通过高可用性、低延迟网络链接连接到 ZooKeeper 组件。

路由

DC/OS 网络需要一个唯一的地址空间。群集实体不能共享相同的 IP 地址。例如,应用程序和 DC/OS 代理必须具有他们的唯一 IP 地址。所有 IP 地址都应在群集内路由得到。

首要/从属架构

HA 系统中的常见模式是首要/从属概念。这有时也被称为主控/从属、主要/副本或这些内容的某些组合。当您有一个权威进程及 N 个备用进程时使用。在某些系统中,备用进程也可能可以服务于请求或执行其他操作。例如,当与正本/副本一起运行 MySQL 等数据库时,该副本可以发送只读请求,但不能接受写入(只有正本才接受写入)。

在 DC/OS中,许多组件都遵循领导者/追随者模式。我们将在本文讨论其中部分组件及其工作方式。

Mesos

Mesos 可以高可用性模式运行,需要运行三个或五个管理节点。在 HA 模式下运行时,一个主控被选为领导者,其他主控则是追随者。每个主控都有一个复制了的日志,其中包含有关群集的某种状态。使用 ZooKeeper 进行首要节点选举即可选出首要管理节点。如需更多信息,请参阅 Mesos HA 文档

Marathon

Marathon 可以在 HA 模式下运行,允许运行多个 Marathon 实例( HA 模式下至少是两个),其中选中一个首要实例。Marathon 使用 ZooKeeper 进行领导者选举。追随者不接受写入或 API 请求;相反,追随者代理所有 API 请求代理给领先的 Marathon 实例。

ZooKeeper

DC/OS 中的许多服务都使用 ZooKeeper 以取得一致性。ZooKeeper 可用作分布式锁定服务、状态存储库和消息传递系统。ZooKeeper 使用 Paxos-like 日志复制和首要/从属架构,以保持多个 ZooKeeper 实例之间的一致性。参见 ZooKeeper 内部文档,了解有关 Zookeeper 工作原理的更多信息。

故障域隔离

故障域隔离是构建 HA 系统的重要组成部分。为正确处理故障情形,系统必须跨故障域分布,以便在故障后存活。以下是各种类型的故障域:

  • 物理域:包括机器、机架、数据中心、地区和可用性区域。
  • 网络域:同一网络内的机器可能会受网络分区的影响。例如,共享网络交换机可能发生故障或者配置无效。

如需更多信息,请参阅 多分区多分域 文档。

需要 HA 的应用程序也应跨故障域分配。Marathon 可以使用 UNIQUEGROUP_BY 约束算子 来实现。

问题的分离

HA 服务应当分离,责任在服务之间分派。例如,Web 服务应从数据库和共享缓存中分离。

消除单个故障点

单一故障点有多种形式。例如,当系统中的每个服务共用一个 ZooKeeper 群集时,类似 ZooKeeper 的服务可能成为单一故障点。可以通过运行多个 ZooKeeper 群集分别处理服务来降低风险。Exhibitor Universe 包 可以简化该操作。

其他常见的单一故障点包括:

  • 单个数据库实例(如 MySQL)
  • 一次性服务
  • 非 HA 负载均衡器

快速故障检测

快速故障检测有多种形式。ZooKeeper 等服务可用于提供故障检测,例如检测网络分区或主机故障。服务健康状况检查也可用于检测某些类型的故障。

注意:建议服务应揭示健康检查端点,这可以被 Marathon 等服务所使用。

快速故障切换

发生故障时,故障切换 应尽可能快

快速故障切换可通过以下方式实现:

  • 使用 HA 负载均衡器,如 Marathon-LB,或内部 第 4 层负载均衡器
  • 根据 12 因素应用 原则构建应用程序。
  • 在构建服务时遵循 REST 最佳做法:尤其是避免在请求之间在服务器上存储客户端状态。

许多 DC/OS 服务在出现错误时遵循故障快速切换模式。具体而言,出现不可恢复的情况时(如失去领导作用),Mesos 和 Marathon 都将关闭。