• 云原生

Apache Mesos 采用 fail-fast（快速失败）的错误处理策略，这意味着生产环境中必须依赖进程监督器、Paxos 复制日志的 quorum 管理和正确的外部访问配置来保证集群稳定运行。本文基于 docs/operational-guide.md 展开，结合 src/master/flags.cpp、src/master/main.cpp、src/master/http.cpp 等源码实现，讲解进程监督器的选型依据、Master quorum 的扩容/缩容/替换标准操作、--advertise_ip/--advertise_port外部访问配置，以及向非领先 Master 发起 HTTP 请求时的重定向行为。

一、进程监督器：fail-fast 策略的运维兜底

1.1 Mesos 的 fail-fast 错误处理

Mesos 对严重错误的处理哲学是 "fail-fast"：一旦发生严重错误，Mesos 进程通常会直接退出，而不是试图在可能已经损坏的状态下继续运行。文档中给出的典型例子是：当 Mesos 配置为高可用模式后，领先（leading）的 master 一旦发现自身与 Zookeeper quorum 发生分区失联，会主动 abort 自己。这是一种安全预防措施，确保前任 leader 不会在不安全状态下继续对外通信。

这种设计对运维的直接含义是：master/agent 进程退出是"正常"的故障表现，外部必须有机制负责拉起它。

1.2 生产部署必须使用进程监督器

因此，Mesos 生产部署通常使用进程监督器（process supervisor），例如 systemd 或 supervisord，用于：

• 检测 Mesos 进程何时退出；
• 配置监督器在进程失败时自动重启，和/或通知集群运维人员介入排查。

从源码结构看，Mesos 官方部署脚本也印证了这一点：仓库中的 src/deploy/ 目录提供了mesos-master-env.sh.template、mesos-agent-env.sh.template等环境模板，配合mesos-daemon.sh.in、mesos-start-cluster.sh.in等脚本管理进程启停，而 support/packaging/ 中还提供了 systemd unit 文件模板，可直接作为监督器配置的起点。

1.3 相关启动参数

理解进程监督器为什么必要，还需要理解 master 持久化路径的选择。--work_dir参数定义在 src/master/flags.cpp 中，其官方帮助文本明确指出：

"Path of the master work directory. This is where the persistent information of the cluster will be stored. Note that locations like/tmpwhich are cleaned automatically are not suitable for the work directory when running in production..."

即工作目录（如/var/lib/mesos/master）存放集群的持久化信息，生产环境绝不能放在会被自动清理的路径（如/tmp）下——否则监督器自动重启 master 后，可能加载到不一致或丢失的状态。

二、变更 Master Quorum：基于 Paxos 复制日志

2.1 复制日志与--quorum的含义

Master 使用Paxos 复制日志（Paxos-based replicated log）作为存储后端，--registry=replicated_log是当前唯一支持的生产存储后端。源码 src/master/flags.cpp 中--registry的帮助文本确认了这一点：

"Persistence strategy for the registry; available options are `replicated_log`, `in_memory` (for testing)."

默认值即为replicated_log（in_memory仅用于测试）。每个 master 进程都作为复制日志的一个副本（log replica）参与 ensemble，而--quorum标志决定多数派（majority）的大小。该参数的源码定义同样在 src/master/flags.cpp 中，帮助文本给出了硬约束：

"The size of the quorum of replicas when using `replicated_log` based registry. It is imperative to set this value to be a majority of masters i.e., `quorum > (number of masters)/2`. NOTE: Not required if master is run in standalone mode (non-HA)."

并且 src/master/main.cpp 中做了启动期校验：使用replicated_log而未指定--quorum时，master 会直接报错退出（"Need to specify --quorum for replicated log based ..."）。复制日志的数据落在--work_dir下的replicated_log子目录（见 src/master/main.cpp 中path::join(flags.work_dir.get(), "replicated_log")的用法）。

2.2 各 quorum 规模的容错能力

下表给出不同 master 数量下 quorum 大小与容错能力的对应关系：

即部署2N-1个 master、quorum 取N时，可以容忍N-1个 master 故障。文档建议：在需要高可用时，推荐运行 3 或 5 个 master。

2.3 关键注意事项：Master 数量必须严格受控

配置 quorum 时必须保证实际运行的 master 数量恰好等于上表中的数目。如果额外多启动了 master 进程，就会破坏 quorum 假设，可能导致日志损坏。因此官方建议用某种机制对 master 进程的运行施加"静态主机白名单"约束（即只允许固定的那几台主机运行 master，对应社区 issue MESOS-1546 提出的在 Mesos 内部加入安全白名单的诉求；复制日志在线重配置则对应 MESOS-683）。

从源码结构看，目前 master 启动流程中并没有内建"主机白名单"校验，因此这一约束必须由部署层（如配置管理工具、systemd 单元仅部署在指定主机）来保证——这是运维层面的硬性要求。

2.4 增大 quorum（示例：3 -> 5 个 master，quorum 2 -> 3）

随着集群规模扩大，可能需要增大 quorum 以获得更强的容错能力。以从 3 个 master（--quorum=2）扩展到 5 个 master（--quorum=3）为例：

1. 初始状态：3 个 master 以--quorum=2运行；
2. 将原来的 3 个 master 以--quorum=3重启；
3. 再启动 2 个新 master，同样使用--quorum=3。

若要将 quorum 增量为 N，则重复上述过程 N 次，每次只加一步（quorum 值 +1 并补齐对应 master 数量）。

2.5 缩小 quorum（示例：5 -> 3 个 master，quorum 3 -> 2）

反向操作以从 5 个 master 缩减到 3 个为例：

1. 初始状态：5 个 master 以--quorum=3运行；
2. 从集群中移除 2 个 master，并确保它们不会被重新拉起（参见上文"关键注意事项"——被移除的 master 必须被白名单排除）。此时 3 个 master 以--quorum=3运行；
3. 将这 3 个 master 以--quorum=2重启。

若要将 quorum 减量为 N，则重复上述过程 N 次。

2.6 从单 master 迁移到多 master

一个重要的限制：当前从单 master 模式迁移到多 master，必须先清掉复制日志状态并重新开始。这会清除所有持久化数据（agent 信息、maintenance 信息、quota 信息等）。从 1 个 master 迁移到 3 个 master 的操作为：

1. 停掉原来的独立（standalone）master；
2. 删除复制日志数据（--work_dir目录下的replicated_log子目录）；
3. 以--quorum=2启动原来的 master 和两个新 master。

注意：--quorum仅在非 HA 的 standalone 模式下才可以省略；一旦启用replicated_log后端，--quorum必选（见 src/master/main.cpp 中的校验逻辑）。

2.7 替换一个故障 master

结合 2.3 节的注意事项：只要确保故障的 master 不会再重新加入 ensemble（即从白名单中移除、不再启动），就可以安全地用一个**空日志（empty log）**启动一个新 master，让它自行追赶（catch up）日志。这是 Mesos 复制日志副本的标准恢复方式：新副本以空状态启动，通过 Paxos 复制协议向现有副本同步全部日志内容，无需人工拷贝数据目录。

三、Mesos Master 的外部访问配置

3.1 问题场景

如果 master 的默认 IP（或命令行参数--ip指定的 IP）是内网 IP，那么外部的实体（例如框架调度器 framework scheduler）将无法访问到 master。针对该场景，可以通过mesos-master的--advertise_ip和--advertise_port命令行参数配置一个"对外可访问的 IP:port"。

3.2 参数语义与源码印证

源码 src/master/flags.cpp 中对这两个参数的定义明确了其行为边界：

add(&Flags::advertise_ip, "advertise_ip", "IP address advertised to reach this Mesos master.\n" "The master does not bind using this IP address.\n" "However, this IP address may be used to access this master."); add(&Flags::advertise_port, "advertise_port", "Port advertised to reach Mesos master (along with\n" "`advertise_ip`). The master does not bind to this port.\n" "However, this port (along with `advertise_ip`) may be used to\n" "access this master.");

要点：

• master 并不绑定（bind）在advertise_ip/advertise_port上，它仍然监听--ip/--port指定的内部地址；
• 配置后，外部实体（框架调度器等）通过advertise_ip:advertise_port与 master 交互，需要在网络层（防火墙、NAT、负载均衡代理等）将该地址的请求代理转发到 master 实际监听的内部 IP:port；
• 相关参数--ip的帮助文本说明其为 "IP address to listen on"，且不能与--ip_discovery_command同时使用。

因此，运维上的落地方式是：在 master 所在网络边界上建立一个入口（例如反向代理或 NAT 映射），把外部流量转到内部监听端口，然后让--advertise_ip/--advertise_port指向该入口地址，使调度器、CLI 等外部客户端能够连通 master。

四、向非领先（non-leading）Master 发起 HTTP 请求

4.1 行为说明

部分 master 的 HTTP 端点（例如/state、/machine/down）只有领先（leading）master 才能应答。当这类请求被发送到非领先的 master 上时，会得到以下两种响应之一：

• 307 Temporary Redirect：如果该 master 知道当前 leader 是谁，会返回 307，并在响应头中给出领先 master 的位置，客户端可以跟随重定向；
• 503 Service Unavailable：如果该 master 不知道当前的 leader 是谁（例如刚成为 follower、ZooKeeper 会话尚未建立等），则返回 503。

4.2 源码印证

这一行为在源码中有多处体现：

• src/master/master.cpp 中注册了/redirect路由，直接调用http.redirect(request)，用于把请求重定向到领先 master；
• src/master/http.cpp 中几乎每个端点的帮助文本都声明了统一契约："Returns 307 TEMPORARY_REDIRECT redirect to the leading master when the master is not the leader. Returns 503 SERVICE_UNAVAILABLE if the leading master cannot be..."（即：非 leader 时返回 307 重定向到 leader；无法确定 leader 时返回 503）。

4.3 运维建议

• 客户端（脚本、CLI、监控探针）应当正确处理 307 重定向，或者直接使用 ZooKeeper 地址（--zk）选举出的当前 leader 地址发起请求，避免依赖某个固定 follower；
• 如果频繁看到 503，说明该 master 与 ZooKeeper 的 leader 发现机制之间存在问题，应检查--zk配置、ZooKeeper 会话超时（--zk_session_timeout，定义于 src/master/flags.cpp）以及 master 日志。

五、运维操作清单速查

六、小结

本文围绕 docs/operational-guide.md 梳理了 Mesos 生产运维的四条主线：其一，fail-fast 设计决定了必须部署进程监督器，并配合可靠的--work_dir持久化路径；其二，基于 Paxos 复制日志的 quorum 变更必须遵循"先改 quorum 值、再增删副本"的严格顺序，且 master 主机集合必须受静态白名单约束，以防日志损坏；其三，内外网隔离环境下通过--advertise_ip/--advertise_port暴露访问入口；其四，HTTP 客户端需正确处理非 leader master 的307/503响应。以上每一条都有对应的源码参数定义与启动校验作为落地依据，可直接用于生产环境的部署与变更操作。

• 云原生