使用 Cephadm 和 Ansible 自动化 Ceph 集群部署：分步指南（第一部分）

Daniel Parkes, Anthony D'Atri (IBM)

简介

在大数据时代，高效可靠地管理海量存储对企业来说是一项关键挑战。Ceph 已成为领先的软件定义存储解决方案，以其灵活性、可扩展性和稳健性而闻名。在此基础上，Ceph 提升了这些功能，提供与企业环境无缝集成以及高效管理 PB 级数据的先进工具。

本博客文章系列将深入探讨使用 Ceph 最先进的编排器 cephadm 自动化 Ceph 集群部署。此外，对于使用 Ansible 自动化基础设施的客户，我们将分享一个示例，该示例使用基础设施即代码方法，并借助 Jinja2 模板和 Ansible。

基础设施即代码

基础设施即代码 (IaC) 通过将基础设施设置视为代码来彻底改变基础设施管理。这使我们能够将软件开发实践（例如版本控制、测试和持续集成）应用于基础设施管理，从而降低出错风险并加快部署和扩展速度。

对于 Ceph，像 Ansible 和 cephadm 这样的工具是 IaC 实践的完美示例。它们允许管理员以代码的形式定义 Ceph 集群的期望状态，从而更容易地跨不同环境部署、管理和扩展这些集群。

Ceph 编排工具的简要历史

随着 Ceph 越来越受欢迎，集群迅速增长，对有效的编排工具的需求变得越来越重要。多年来，已经开发了几种工具来简化和自动化 Ceph 集群的部署和管理。让我们简要了解一下它们

  • ceph-deploy 是最早引入的工具之一，旨在简化 Ceph 集群的部署。作为一个轻量级的命令行实用程序，ceph-deploy 允许管理员通过自动化配置 Ceph 守护程序（如 MON、OSD 和 MGR）中的许多手动步骤来快速设置基本的 Ceph 集群。

  • ceph-ansible 标志着一个重要的进步，因为它将 Ceph 部署与 Ansible（一种流行的开源自动化工具）集成。这种方法采用了基础设施即代码 (IaC) 的原则，允许管理员在 Ansible playbook 中定义整个 Ceph 集群配置。

  • cephadm 当前捆绑的 Ceph 编排器，我们将在下一节中详细介绍。

Cephadm 简介

与它的前身不同，cephadm 使用 Docker 或 Podman 将所有 Ceph 守护程序作为容器部署。这种容器化方法确保了跨不同环境的一致性，并简化了依赖项的管理，从而更容易地部署、升级和扩展 Ceph 集群。

Cephadm 使用声明式规范文件来定义集群的期望状态，这标志着 Ceph 集群管理方式的重大改进。管理员现在可以提前描述整个集群配置，而 Cephadm 会持续确保集群与该期望状态匹配。这个过程也被称为收敛。

除了其强大的部署功能外，Cephadm 还与 Ceph Dashboard 集成，提供内置的监控和警报，并支持自动升级，使其成为迄今为止 Ceph 生态系统中功能最全面、用户最友好的编排工具。

使用 Cephadm 重复自动化 Ceph 集群部署

现代 IT 环境越来越需要跨不同环境（开发、测试和生产）重复部署和扩展存储集群。Cephadm 在此时派上用场。通过自动化 Ceph 集群的部署和管理，Cephadm 消除了传统上涉及设置分布式存储系统的手动、容易出错的过程。

Cephadm 的声明式方法

cephadm 使用声明式服务规范文件，允许管理员在单个、可重用的文件中定义 Ceph 集群的整个配置，该文件适合于版本控制。该规范文件可以描述从 OSD、Monitor 和 Manager 的放置到 File、Block 和 Object 服务的设置和配置的所有内容。通过应用此规范文件，cephadm 可以自动使集群收敛到与期望状态匹配，从而确保跨多个部署的一致性。

重要的是要注意，Cephadm 提供 Ceph 集群服务的部署和生命周期。但是，并非所有特定服务的日常操作（例如创建 Ceph 对象存储 (RGW) 用户）当前都由 Cephadm 涵盖。

融入基础设施即代码 (IaC)

cephadm 完全融入了基础设施即代码 (IaC) 范例。IaC 将基础设施配置视为软件代码，将其存储在版本控制中，自动化其应用，并启用持续交付管道。使用 cephadm，规范文件充当定义存储基础设施的代码。

例如，您可以将 cephadm 规范文件存储在 Git 等版本控制系统中，并带有可选的 CICD 管道。当集群配置发生更改时，它们将被提交和推送，从而触发自动管道，这些管道将根据更新的规范文件部署或更新 Ceph 集群。这种方法简化了部署，并确保您的存储基础设施始终与您的应用程序和服务需求保持同步。

请注意，特定的 cephadm 配置更改需要重新启动相应的服务，这必须与自动化工具协调，才能在应用后生效。

Cephadm 服务规范文件演练，提供 Ceph 集群的自动化部署

以下是一个 Cephadm 规范文件的示例，该文件可在引导过程中启用完整的 Ceph 集群部署。此基本示例旨在帮助您入门；生产部署需要进一步自定义规范文件。

service_type: host
hostname: ceph1
addr: 10.10.0.2
location:
  root: default
  datacenter: DC1
labels:
- osd
- mon
- mgr
---
service_type: host
hostname: ceph2
addr: 10.10.0.3
location:
  datacenter: DC1
labels:
- osd
- mon
- rgw
---
service_type: host
hostname: ceph3
addr: 10.10.0.4
location:
  datacenter: DC1
labels:
- osd
- mds
- mon
---
service_type: mon
placement:
  label: "mon"
---
service_type: mgr
service_name: mgr
placement:
 label: "mgr"
---
service_type: osd
service_id: all-available-devices
service_name: osd.all-available-devices
spec:
  data_devices:
    all: true
    limit: 1
placement:
  label: "osd"
---
service_type: rgw
service_id: objectgw
service_name: rgw.objectgw
placement:
  count: 2
  label: "rgw"
spec:
  rgw_frontend_port: 8080
  rgw_frontend_extra_args:
   - "tcp_nodelay=1"
---
service_type: ingress
service_id: rgw.external-traffic
placement:
  label: "rgw"
spec:
  backend_service: rgw.objectgw
  virtual_ips_list:
  - 172.18.8.191/24
  - 172.18.8.192/24
  frontend_port: 8080
  monitor_port: 1967

第一个 service_type 是 host，它枚举集群中的所有主机，包括其主机名和 IP 地址。location 字段指示主机在 Ceph CRUSH 拓扑中的位置，这是一种分层结构，用于告知集群中数据放置和检索。请查看 此文档 以获取更多信息。

通过在主机上设置特定的标签，Cephadm 可以有效地安排和部署容器化的 Ceph 服务到所需的节点，有时一个节点可以拥有多个标签，从而托管多个 Ceph 服务。这确保了资源隔离并减少了所需的节点数量，从而优化了生产环境中的资源利用率并降低了成本。

请注意，我们添加到集群的主机需要配置一组先决条件才能成功加入 Ceph 集群。本博客系列还将涵盖自动化这些先决条件的部署。

service_type: host
hostname: ceph1
addr: 10.10.0.2
location:
  root: default
  datacenter: DC1
labels:
- osd
- mon
- mgr

之后，我们有了 Monitor 和 Manager 服务部署。我们有一个简单的配置，仅使用 placement parameter。使用 placement 参数，我们告诉 cephadm 它可以将 Monitor 服务部署到带有 mon 标签的任何主机上。

---
service_type: mon
placement:
  label: "mon"
---
service_type: mgr
service_name: mgr
placement:
  label: "mgr"

接下来，我们有 osd 服务类型。cephadm OSD 服务类型非常灵活：它允许您定义几乎可以想象的任何 OSD 配置。有关 OSD 服务规范的完整详细信息，请查看 此文档

在我们的示例中，我们采用了最直接的方法之一：我们告诉 Cephadm 使用可用设备上所有空闲/可用的媒体设备作为 OSD，同样使用 placement 参数。它只会配置带有 osd 标签的节点上的 OSD 设备。

在下一节中，我们配置 cephfs 服务以部署 Ceph 共享文件系统，包括元数据服务 (MDS) 守护程序。有关所有服务规范配置选项，请查看 此文档

最后，我们填充 rgw 服务类型以设置 Ceph 对象网关 (RGW) 服务。RGW 服务为客户端提供与 S3 和 Swift 兼容的 HTTP RESTful 端点。在此示例中，在 placement 部分，我们将 RGW 服务的数量设置为 2。这意味着 Cephadm 调度程序将查找在具有 rgw 标签的可用主机上安排两个 RGW 守护程序。tcp_nodelay=1 前端选项禁用 Nagle 拥塞控制，这可以提高 RGW 操作在小对象上的延迟。

---
service_type: mds
service_id: cephfs
Placement:
  count: 2
  label: "mds"
---
service_type: rgw
service_id: objectgw
service_name: rgw.objectgw
placement:
  count: 2
  label: "rgw"
rgw_realm: 
rgw_zone: 
rgw_zonegroup: 
spec:
  rgw_frontend_port: 8080
  rgw_frontend_extra_args:
  - "tcp_nodelay=1"

Ceph 还提供了一个基于 haproxy 和 keepalived 的开箱即用的负载均衡器，称为 ingress 服务，这对于熟悉 Kubernetes 管理员来说可能是一个熟悉术语。在此示例中，我们使用 ingress 服务在我们的集群中运行的 RGW 守护程序之间平衡客户端 S3 请求，为对象服务提供 HA 和负载平衡。详细信息 在此

我们使用 rgw 标签服务将 haproxy/keepalived 守护程序与 RGW 服务共置。然后，我们使用 virtual_ips_list 规范参数设置客户端将用于访问 S3 端点 API 的浮动虚拟 IP 地址 (VIP) 列表。

---
service_type: ingress
service_id: rgw.external-traffic
placement:
  label: "rgw"
spec:
  backend_service: rgw.objectgw
  virtual_ips_list:
    - 172.18.8.191/24
    - 172.18.8.192/24
  frontend_port: 8080
  monitor_port: 1967

一旦我们定义并准备好所有服务规范，我们需要将规范文件传递给 cephadm 引导命令，以部署和配置我们如文件中所述的集群。这是一个使用 --apply-spec 参数传递集群规范文件的引导命令示例

# cephadm bootstrap \
    --registry-json /root/registry.json \
    --dashboard-password-noupdate \
    --ssh-user=cephadm \
    --mon-ip  \
    --apply-spec /root/cluster-spec.yaml

下一步

在本系列文章的下一期中，我们将探讨如何结合使用 Jinja2 (J2) 模板和 Ansible 与 cephadm 服务规范文件。这种方法将演示如何构建 Ceph 集群部署的基础设施即代码 (IaC) 框架，从而促进使用 Git 作为 Ceph 配置管理的单一来源的简化持续交付 (CICD) 管道。

脚注

作者谨此感谢 IBM 对社区的支持，通过促使我们有时间创建这些帖子。