第 1 部分：使用 Consul 构建面向健康的 Ceph 对象网关 (RGW) 负载均衡

2025年9月20日 Daniel Alexander Parkes, Anthony D'Atri

第 1 部分：使用 Ceph Ingress Concentrators 和 Consul 实现 S3 动态负载均衡 ¶

注意：本文档描述的功能预计将在即将发布的 Tentacle 版本中提供。

随着对象存储部署的增长，维护 S3 兼容端点的高可用性和弹性访问变得越来越复杂。传统的负载均衡器通常是集中式的、静态配置的，并且不知道后端服务的健康状况。它们可能引入性能瓶颈、运维开销和单点故障。在分布式或横向扩展环境中，服务必须实时适应拓扑结构变化和故障，这些限制尤其成问题。

Ceph Tentacle 引入了 ingress concentrators（入口集中器）：通过 cephadm 部署的每个节点上的 HAProxy 服务。每个集中器都位于本地对象网关 (RGW) 守护程序池的前端，允许每个 Ceph 节点充当 S3 入口点。这种分布式设计通过本地化流量处理来提高容错能力并简化扩展。

Ingress concentrators 本身并不提供动态路由或自动故障转移。这就是 HashiCorp Consul 和 CoreDNS 发挥作用的地方。通过将 Consul 的服务发现和健康检查与 CoreDNS 的可编程 DNS 集成，我们可以实现智能、健康感知的负载均衡——所有这些都不依赖静态配置或外部 DNS 基础设施。

在这篇博文中，你将学习如何

理解和部署 Ceph ingress Concentrators
使用 Consul 动态注册和监控它们
集成 CoreDNS 以实现基于 DNS 的健康感知路由
验证路由逻辑和故障转移场景

为什么静态负载均衡有局限性 ¶

Ceph 对象网关 (RGW) 部署的一个常见起点是在一组网关守护程序前面放置一两个 HAProxy 实例。通常，这些 HAProxy 服务与 Keepalived 配对以创建共享的虚拟 IP (VIP)，提供基本的高可用性。虽然这种方法功能齐全，但随着对象存储环境的增长，它很快就会暴露出局限性

集中式瓶颈：使用单个 VIP，所有 S3 流量一次性通过一个节点和一个守护程序。这成为可扩展性和性能瓶颈，尤其是在繁重的工作负载下。
手动负载分配：虽然你可以在节点之间配置多个 VIP，但必须明确引导客户端在它们之间分配请求。这通常需要客户端中的自定义逻辑或静态 DNS 循环赛条目，两者都不能自动适应节点健康状况或集群变化。
缺乏服务感知：传统的 DNS 和 VIP 故障转移机制在网络层运行。它们无法原生检测单个 Ceph 对象网关 (RGW) 守护程序是否响应或健康。如果节点可达但 RGW 服务已降级或无响应，客户端仍可能被路由到该节点。
运维摩擦：添加或移除网关节点通常涉及重新配置 HAProxy 和 DNS 记录，这会引入停机风险并使自动化工作流复杂化。

为了高效扩展并提供弹性 S3 访问，我们需要一个分布式入口模型，该模型能够适应拓扑结构变化、自动检测服务健康状况并动态引导客户端请求。这就是 Ceph ingress Concentrators、Consul 和 CoreDNS 组合提供现代化、灵活替代方案的地方。

Cephadm 入口和集中器 ¶

传统的 Ceph 入口架构 ¶

作为 Ceph 编排层的一部分，cephadm 提供对部署入口服务的内置支持。这提供了一种方便且可用于生产的方式，将负载均衡器（通常是 HAProxy）放置在一组 Ceph 对象网关 (RGW) 守护程序前面。

Ceph 入口服务的行为类似于标准负载均衡器设置：它运行一个集中式 HAProxy 服务（与 Keepalived 配对以实现高可用性），将流量分配给多个 RGW。Ceph 自动生成 HAProxy 配置并针对注册到特定服务的所有 RGW 实例。此模型在许多环境中都运行良好。例如

当你更喜欢集中式流量控制且不需要节点级入口时。
当你想要向客户端公开单个外部 VIP 并集中管理 TLS 终止时。
当你的 RGW 数量相对静态，或者当更改通过自动化得到良好管理时。

这是一个此类设置的示例

service_type: rgw
service_id: foo
placement:
  label: rgw
  count_per_host: 2
spec:
  rgw_frontend_port: 8080

此配置将在每个带有 rgw 标签的节点上部署两个 RGW 守护程序。第一个将侦听端口：8080，第二个侦听 8081。可以分层放置一个入口 HAProxy 服务（单独定义），将客户端流量转发到集群中的所有后端 RGW。

然而，随着对象存储环境的增长，尤其是在大规模或边缘分布式场景中，集中式负载均衡可能会引入运维复杂性

网络流量必须跨越多个跳数，降低了局部性。
单个 VIP 意味着单个逻辑瓶颈，除非你引入多个入口点和外部负载均衡逻辑。
RGW 的动态扩展可能仍需要更新面向客户端的负载均衡器或外部 DNS。

Ceph Tentacle 新功能：Ingress Concentrators ¶

Ceph Tentacle 将支持集中器，这是 cephadm 中的一项新功能，它部署每个节点上的 ingress concentrators。集中器是在每个 Ceph 节点上运行的本地 HAProxy 实例，并充当该节点本地 RGW 守护程序的集中器。它为每个主机提供一个单一的 IP:PORT 端点，并自动平衡该同一节点上的 RGW 之间的流量。

这带来了几个优点

流量局部性：每个 HAProxy 仅路由到本地 RGW。
简化的网关扩展：增加 count_per_host，本地 HAProxy 会自动更新。
不需要 Keepalived：每个节点服务于自己的流量。故障转移在 DNS 层自然发生（当我们集成 Consul 时会详细介绍）。
这是一个支持集中器的 RGW 服务配置示例

service_type: rgw
service_id: client
service_name: rgw.client
placement:
  label: rgw
  count_per_host: 2
networks:
  - 192.168.122.0/24
spec:
  rgw_frontend_port: 8088
  rgw_realm: multisite
  rgw_zone: madrid
  rgw_zonegroup: europe
  zonegroup_hostnames:
    - s3.cephlab.com
  concentrator: haproxy
  concentrator_frontend_port: 8080
  concentrator_monitor_port: 1967
  concentrator_monitor_user: admin

通过此配置

每个带有 rgw 放置标签的主机都运行两个对象网关守护程序：一个在 8088 上，另一个在 8089 上。
本地 HAProxy 集中器侦听：8080，仅将流量转发到本地节点 RGW。

HAProxy 监控端口 (1967) 用于公开本地健康状态，我们稍后将其集成到 Consul 中以进行 DNS 感知负载均衡。

注意：此设置侧重于基于 DNS 的路由和服务感知。它不涉及 SSL/TLS 终止。在生产部署中，TLS 应在 Ceph 对象网关 (RGW) 级别终止。
为了支持虚拟主机风格的 S3 访问（例如 https://bucket1.s3.cephlab.com)，你的 RGW TLS 证书必须包含 *.s3.cephlab.com 的主题备用名称 (SAN) 条目。

使用 Consul 实现动态 DNS 负载均衡 ¶

为了根据服务健康状况和节点可用性智能地路由 S3 流量，我们需要的不只是传统 DNS。这就是 HashiCorp Consul 发挥作用的地方。

Consul 是一个分布式服务网格和服务发现工具。其核心功能包括

用于注册服务的控制平面
内置健康检查
支持实时更新的基于 DNS 的服务发现

通过将 Consul 集成到我们的 Ceph 集群中，我们可以使用实时更新的健康入口节点列表动态回答 s3.cephlab.com 等 DNS 查询。这使得对 S3 端点的分布式、负载均衡访问成为可能，而无需外部负载均衡器或静态 DNS 配置。

为什么选择 Consul？ ¶

在我们的案例中，Ceph 集群中的每个节点都运行一个本地 HAProxy 集中器，作为其 Ceph 对象网关 (RGW) 守护程序的终止器。我们希望这些端点能够

自动注册为服务
持续监控健康状况
仅在健康时通过 DNS 返回

Consul 通过其基于代理的架构处理所有这些问题。

控制平面和仲裁 ¶

Consul 以分布式模式运行。它需要一个服务器代理仲裁（通常为 3 或 5 个）才能充当控制平面。这些服务器维护集群状态并执行领导者选举。

每个参与节点（例如 RGW 节点）也运行一个 Consul 代理，该代理与控制平面通信并执行本地任务，例如注册服务和运行健康检查。

在小型集群中，同一节点可以同时充当服务器和代理。对于我们的示例，我们将部署三个服务器模式的 Consul 代理，每个代理都在 cephadm 管理的容器内运行。它们将构成核心控制平面，并注册本地 HAProxy ingress services。

我们将使用以下节点作为 Consul

ceph-node-00 → 192.168.122.12
ceph-node-01 → 192.168.122.179
ceph-node-02 → 192.168.122.94

这些节点中的每一个也都在运行本地 Ceph 对象网关 (RGW) 和相应的 HAProxy 集中器。因此，每个节点都将

运行一个 Consul 服务器代理。
注册其自己的本地 HAProxy（入口终止器）。
对 HAProxy 监控端口执行健康检查。
加入 Consul 集群进行服务传播。

接下来，我们将逐步配置 Consul 代理，使用 cephadm 将它们部署为容器，并验证它们是否正确地通告了健康的入口服务。

步骤 1：使用 Cephadm 在 Ceph 节点上配置 Consul ¶

在所有三个 Ceph 节点上，将以下形式的文件放置在 /etc/consul.d/consul.hcl。此示例显示了主机 ceph-node-00 (192.168.122.12) 的内容

datacenter = "madrid"
data_dir = "/opt/consul"
bind_addr = "192.168.122.12"
client_addr = "0.0.0.0"
retry_join = [
  "192.168.122.12",
  "192.168.122.179",
  "192.168.122.94"
]
server = true
bootstrap_expect = 3

services = [
  {
    name = "ingress-rgw-s3"
    port = 8080
    check = {
      id       = "http-check"
      name     = "HAProxy Check"
      http     = "http://192.168.122.12:1967/health"
      interval = "10s"
      timeout  = "2s"
    }
  }
]

请务必为每个节点调整 bind_addr 和 HAProxy 健康检查 URL。

通过 Cephadm 自定义容器部署 Consul ¶

在 ceph-node-00 上创建以下 consul.yml Ceph 服务规范文件

service_type: container
service_id: consul
placement:
  hosts:
    - ceph-node-00
    - ceph-node-01
    - ceph-node-02
spec:
  image: docker.io/hashicorp/consul:latest
  entrypoint: '["consul", "agent", "-config-dir=/consul/config"]'
  args:
    - "--net=host"
  ports:
    - 8500
    - 8600
    - 8300
    - 8301
    - 8302
  bind_mounts:
    - ['type=bind','source=/etc/consul.d','destination=/consul/config', 'ro=false']

并使用 ceph orch apply 命令应用它

$ ceph orch apply -i consul.yml

验证 Consul 服务/容器是否已启动

$ ceph orch ps --daemon_type container
NAME                            HOST          PORTS                                                STATUS         REFRESHED  AGE  MEM USE  MEM LIM  VERSION    IMAGE ID      CONTAINER ID  
container.consul.ceph-node-00   ceph-node-00  *:8500,8600,8300,8301,8302,8500,8600,8300,8301,8302  running (20h)     5m ago  20h    35.8M        -  <unknown>  ee6d75ac9539  78753a2f9a4a  
container.consul.ceph-node-01   ceph-node-01  *:8500,8600,8300,8301,8302,8500,8600,8300,8301,8302  running (20h)     7m ago  20h    37.6M        -  <unknown>  ee6d75ac9539  68bb749e0022  
container.consul.ceph-node-02   ceph-node-02  *:8500,8600,8300,8301,8302,8500,8600,8300,8301,8302  running (20h)     7m ago  20h    35.5M        -  <unknown>  ee6d75ac9539  b42ea94cd403

检查所有 Consul 容器是否正在运行并已加入集群

$ podman exec -it $(podman ps |grep consul| awk '{print $1}') consul members
Node          Address               Status  Type    Build   Protocol  DC      Partition  Segment
ceph-node-00  192.168.122.12:8301   alive   server  1.21.4  2         madrid  default    <all>
ceph-node-01  192.168.122.179:8301  alive   server  1.21.4  2         madrid  default    <all>
ceph-node-02  192.168.122.94:8301   alive   server  1.21.4  2         madrid  default    <all>

确认 Consul 已注册服务

$ podman exec -it $(podman ps |grep consul| awk '{print $1}') consul catalog services
consul
ingress-rgw-s3

检查哪些节点正在提供入口服务

$ podman exec -it $(podman ps |grep consul| awk '{print $1}') consul catalog nodes -service ingress-rgw-s3
Node          ID        Address          DC
ceph-node-00  cdd2e96c  192.168.122.12   madrid
ceph-node-01  ac868e52  192.168.122.179  madrid
ceph-node-02  d16446b3  192.168.122.94   madrid

结论。使用 Consul 实现健康感知入口的基础 ¶

在这第一部分中，我们解决了 Ceph 上可扩展 S3 部署的一个关键挑战：如何构建一个容错、动态和去中心化的入口层，该层能够自动适应节点和服务健康状况。

通过利用

通过 cephadm 在每个节点上部署的 ingress terminators
仅路由到本地 RGW 守护程序的 HAProxy concentrators
HashiCorp Consul，提供分布式服务注册和健康监控

...我们为强大、健康感知的访问层奠定了基础。每个 Ceph 节点现在都充当一个智能入口点，由 Consul 动态跟踪并通过其内置的 DNS 接口公开。

但仅有 Consul 是不够的。大多数应用程序和 S3 客户端不会搜索 .consul DNS 域或端口 8600，它们需要使用标准 DNS 机制解析 mybucket.s3.cephlab.com 等名称。如果没有 DNS 网桥，这种动态服务感知仍将局限于 Consul 生态系统内。

第 2 部分预告。使用 CoreDNS 连接 DNS 并启用虚拟主机存储桶 ¶

在本博客系列的下一部分中，我们将

介绍 CoreDNS 作为客户端和 Consul 之间的可编程 DNS 网桥
使用 cephadm 自定义容器在每个节点上部署 CoreDNS 容器以实现高可用性
配置 DNS 重写以支持虚拟主机风格的 S3 访问
通过存根区域委托集成企业 DNS
使用 DNS 工具验证客户端仅接收健康端点
模拟节点故障并演示客户端的透明访问。

继续阅读第 2 部分：使用 CoreDNS 连接 DNS 到 Ceph Ingress

作者感谢 IBM 对社区的支持，为我们提供时间来创建这些帖子。