启用 TripleO 通过 Ceph Ansible 部署 Ceph

https://blueprints.launchpad.net/tripleo/+spec/tripleo-ceph-ansible

使用新的 Mistral 工作流启用 TripleO 通过 Ceph Ansible 部署 Ceph。这将使 Ceph 安装与 TripleO 的耦合度降低，但现有的操作员接口用于使用 TripleO 部署 Ceph 将仍然受支持，直到 Queens 版本的结束。

问题描述

Ceph 社区维护 ceph-ansible 以部署和管理 Ceph。TripleO 社区的成员也维护类似的工具。这是一个建议，让 TripleO 通过 Mistral 触发 Ceph 社区的工具，作为部署和管理 Ceph 的替代方法。

使用其他项目部署和管理 Ceph 的好处

避免重复劳动

如果 Ceph 社区的工具中存在 TripleO 使用的工具中没有的功能或错误修复，那么 TripleO 社区的成员可以允许部署者直接使用这些功能，而不是编写他们自己的实现。如果此建议成功，那么将来可能不再需要维护两个代码库（以及包含的错误修复和测试）。例如，如果 ceph-ansible 修复了一个正确处理块设备替代系统路径的错误，例如 /dev/disk/by-path/ 而不是 /dev/sdb，那么 puppet-ceph 中就不需要修复相同的错误。此细节也将很好地从部署者那里抽象出来，因为此规范建议与 TripleO Heat 模板保持一致。因此，部署者不需要更改 ceph::profile::params::osds 参数，因为相同的 OSD 列表将有效。

采用这种方法，可能会出现 TripleO 的部署架构具有 ceph-ansible 中不存在的独特功能的情况。在这种情况下，可能需要采取措施以确保这些功能与这种方法保持一致。在任何情况下，此建议都不会使 TripleO 部署者绕过 TripleO 并直接使用 ceph-ansible。此外，由于 Ceph 本身不是 OpenStack 服务，而是 TripleO 使用的服务，因此这种方法仍然符合 TripleO 的使命。

OpenStack 和非 OpenStack Ceph 部署之间的一致性

部署者可能会从 Ceph 社区寻求 Ceph 部署的帮助，如果两个部署都使用相同的工具，则此过程将简化。

启用 Ceph 管理与 TripleO 的解耦

Ceph 管理的复杂性可以移动到不同的工具中，并在适当的时候从 TripleO 中抽象出来，从而使 TripleO 的 Ceph 管理方面变得不那么复杂。将此与容器化的 Ceph 结合使用将提供灵活的部署选项。这是当今难以实现的部署者优势。

Ceph 社区的工具中 TripleO 的工具中没有的功能

Ceph 社区工具 ceph-ansible [1] 为 OpenStack 用户提供了在 TripleO 的工具链中找不到的好处，包括部署 Ceph 到容器中的 playbook 以及在不中断服务的情况下将非容器化部署迁移到容器化部署。此外，通过将 Ceph 部署在 TripleO 中变得不那么紧密地耦合，而是将其移动到新的 Mistral 工作流中，这将使在未来的版本中通过类似 Tendrl [2] 的工具添加业务逻辑层，以提供额外的基于 Ceph 策略的配置，甚至提供图形化工具来查看 Ceph 集群的状态，变得更容易。但是，此 Pike 提案的范围不包括 Tendrl，而是采取了第一步，通过直接触发 ceph-ansible 通过 Mistral 工作流部署 Ceph。在 Pike 周期完成后，可能会考虑在未来的规范中触发 Mistral。

提议的变更

概述

ceph-ansible [1] 项目提供了一组用于部署和管理 Ceph 的 playbook。已经编写了一个概念验证 [3]，它使用来自实验性 mistral-ansible-actions 项目 [4] 的两个自定义 Mistral 操作，使 undercloud 上的 Mistral 工作流触发 ceph-ansible 以生成一个可用的超融合的 overcloud。

在本周期结束时使用 TripleO 部署 Ceph 的部署者体验应该是以下

  1. 部署者选择部署包含任何 Ceph 服务器服务的角色：CephMon、CephOSD、CephRbdMirror、CephRgw 或 CephMds。

  2. 部署者提供与今天在 Heat env 文件中提供的相同的 Ceph 参数，例如 OSD 列表。

  3. 部署者启动部署并获得带有 Ceph 的 overcloud

因此，部署者体验保持不变，但在后台启动了一个 Mistral 工作流，该工作流触发 ceph-ansible。完成此操作的 Mistral 工作流的详细信息如下。

通过 Mistral 部署 TripleO Ceph

TripleO 部署 Ceph 集群的工作流将被更改，以便有两种方法来部署 Ceph 集群；当前 TripleO 支持的方法和本提案中描述的方法。

此处描述的工作流假定以下内容

  1. 部署者选择从 THT 的 roles_data.yaml 中找到的以下五个服务列表中部署 Ceph 服务器服务：CephMon、CephOSD、CephRbdMirror、CephRgw 或 CephMds。

  2. 部署者选择包含新的 Heat 环境变量文件，这些文件将在实施此规范时位于 THT 中。新的 Heat 环境变量文件将更改任何这五个服务的实现，从上一步。使用 storage-environment.yaml，默认情况下将触发 puppet-ceph 部署 Ceph，将仍然触发 puppet-ceph 部署 Ceph。但是，如果包含新的 Heat 环境变量文件而不是 storage-environment.yaml，则服务的实现将由 ceph-ansible 完成；它已经在以下角色中为主机配置这些服务 Ansible 库存：mons、osds、mdss、rgws 或 rbdmirrors。

  3. undercloud 具有一个名为 /usr/share/ceph-ansible 的目录，其中包含此规范中描述的 ceph-ansible playbook。它将存在，因为其安装将包含 ceph-ansible 包的安装。

  4. Undercloud 上的 Mistral 将包含两个名为 ansible 和 ansible-playbook（或类似名称）的自定义操作，还将包含以下任务的每个工作流，并且可以通过运行 openstack workflow list 来观察。假设 tripleo-common 包将被修改以发布这些操作，并且它们将在 undercloud 安装后可用。

  5. Heat 将发布一个新的 CustomResource 类型，如 OS::Mistral::WorflowExecution [6]，它将执行自定义 Mistral 工作流。

标准 TripleO 工作流，如部署者执行的，将创建一个自定义 Heat 资源，该资源启动一个独立的 Mistral 工作流以与 ceph-ansible 交互。一个这样的 Heat 资源示例是 OS::Mistral::WorflowExecution [6]。

每个独立的 Mistral 工作流可以直接在 tripleo-common/workbooks 中实现。将为下面描述的每个目标创建一个单独的 Mistral workbook

  • OpenStack 和 Ceph 的初始部署

  • 将其他 Ceph OSD 添加到现有的 OpenStack 和 Ceph 集群

Pike 周期最初的目标是保持与 TripleO 和 puppet-ceph 中当前可能实现的功能相同，但使用容器化的 Ceph。如果时间允许或在未来的周期中，可以编写其他 Mistral 工作流，以利用 ceph-ansible playbook 向 TripleO 的 Ceph 部署添加新功能，以缩小 Ceph 集群并安全地删除 OSD，或通过使用 Ceph 的“noout”标志对集群执行维护，以便维护不会导致比必要的更多的数据迁移。

OpenStack 和 Ceph 的初始部署

在此新的 Mistral 工作流和 Ceph-Ansible 在 TripleO 初始部署期间触发的事件序列如下

  1. 在 Undercloud 上定义 Overcloud，包括与存储相关的 Heat 参数，这些参数稍后将通过 Mistral 工作流传递给 ceph-ansible。

  2. 使用标准 Ceph 选项运行 openstack overcloud deploy，但包含一个新的 Heat 环境变量文件，以使服务部署的实现使用 ceph-ansible。

  3. undercloud 组装并将部署计划上传到 undercloud Swift 和 Mistral 环境。

  4. Mistral 启动工作流以部署 Overcloud 并相应地与 Heat 交互。

  5. 达到一个点，Overcloud 节点被镜像、启动和联网。此时，undercloud 可以访问 Overcloud 节点的配置或管理 IP。

  6. 创建一个新的 Heat 资源，该资源启动一个 Mistral 工作流，以在具有任何五个 Ceph 服务器服务的系统上部署 Ceph，包括 CephMon、CephOSD、CephRbdMirror、CephRgw 或 CephMds [6]。

  7. 托管 Ceph 服务的服务器将根据其服务的需要打开相关的防火墙端口，例如，Ceph 监视器防火墙配置为在 TCP 端口 6789 上接受连接。[7]。

  8. Heat 资源传递与 tripleo-heat-templates environments/storage-environment.yaml 中通常找到的相同参数，但通过新的 Heat 环境变量文件。可以传递其他文件以包含覆盖，例如 OSD 磁盘列表。

  9. Heat 资源将参数作为参数传递给 Mistral 工作流。这将包括有关哪些主机应该具有这五个 Ceph 服务器服务中的哪些服务的信息。

  10. Mistral 工作流将这些参数转换为 ceph-ansible 期望的参数，例如 ceph::profile::params::osds 将变为 devices，尽管它们将具有相同的内容，这将是块设备的列表。转换包括构建可以通过调用 ansible-playbook –extra-vars 将传递给 playbook 的参数列表。通常 ceph-ansible 使用 group_vars 目录中的修改后的文件，但在这种情况下，不会修改任何文件，而是以编程方式传递参数。因此，/usr/share/ceph-ansible 中的 playbook 可以未经修改地运行，这将是默认目录。但是，将 /usr/share/ceph-ansible playbook 的替代位置作为参数传递将是可能的。此时尚未运行任何 playbook。

  11. Mistral 环境将被更新以生成一个新的 SSH 密钥对，用于 ceph-ansible 和 Overcloud 节点，使用与 TripleO 验证创建 SSH 密钥和将公钥安装到 Overcloud 节点上相同的方法。在此环境更新之后，将能够在 undercloud 上运行 mistral environment-get ssh_keys_ceph 并以 JSON 格式查看公钥和私钥。

  12. Mistral Action Plugin ansible-playbook 将被调用并传递如上所述的参数列表。用于 tripleo-validations 的动态 ansible 库存将使用 -i 选项使用。为了使 ceph-ansible 像往常一样工作，库存中必须有一个名为 [mons] 和 [osds] 的组，以及可选的组 [mdss]、[rgws] 或 [rbdmirrors]。可以对 TripleO common 发布的 tripleo-validations 项目的 tripleo-ansible-inventory 脚本进行修改以支持此操作，或对其进行派生工作。

  13. Mistral 工作流将根据将要引导的机器数量计算 Ansible 中的 fork 数量，并将此数字与 ansible-playbook –forks 一起传递。

  14. Mistral 验证 Ansible ping 模块是否可以为 mons、osds、mdss、rgws 或 rbdmirrors 组中的任何组执行 ansible $group -m ping，这些组是由部署者请求的。例如，如果部署者仅指定 CephMon 和 CephOSD 服务，那么 Mistral 将仅运行 ansible mons -m ping 和 ansible osds -m ping。Ansible ping 模块将通过先前描述的密钥作为 heat-admin 用户通过 SSH 进入每个主机。如果失败，则部署失败。

  15. Mistral 使用 ansible-playbook 操作启动 Ceph 安装。

  16. Mistral 工作流创建一个 Zaqar 队列，以将进度信息发送回客户端（CLI 或 Web UI）。

  17. 工作流将消息发布到“tripleo”Zaqar 队列或原始部署工作流提供的队列名称。

  18. 如果部署状态出现问题，可以通过 `openstack workflow execution list | grep ceph` 以及位于 `/var/log/mistral/{engine.log,executor.log}` 的日志来查看。运行 `openstack stack resource list` 将显示启动 Mistral 工作流的自定义 Heat 资源，但 `openstack workflow execution list` 和 `openstack workflow task list` 将包含有关 Mistral 工作流中完成的步骤的更多详细信息。

  19. Ceph 部署在容器中，必须防止任何组合服务发生任何配置文件冲突，例如，如果 Nova 计算容器（由 TripleO 部署）和 Ceph OSD 容器位于同一节点上，则它们必须具有不同的 ceph.conf 文件，即使这些文件具有相同的内容。不过，ceph-ansible 将管理 Ceph 服务的 ceph.conf，而 puppet-ceph 仍将管理 OpenStack 服务的 ceph.conf，这两种工具都不会尝试管理相同的 ceph.conf，因为它位于容器主机上的不同位置，并绑定挂载到不同容器内的 `/etc/ceph/ceph.conf`。

  20. 在 Mistral 工作流成功完成后，自定义 Heat 资源被认为已成功创建。如果 Mistral 工作流未成功完成，则 Heat 资源不被认为已成功创建。TripleO 应以与处理任何未能创建的 Heat 资源相同的方式处理此情况。例如，由于工作流是幂等的，如果资源创建失败是由于传递了错误的参数或由于临时网络问题，则部署程序可以简单地运行堆栈更新，Mistral 工作流将再次运行，如果导致第一次运行失败的问题得到解决，则部署应成功。类似地，如果用户更新参数，例如，将新的磁盘添加到 `ceph::profile::params::osds`，则工作流将再次运行，而不会破坏正在运行的 Ceph 集群的状态，但它将配置新的磁盘。

  21. 在满足上一步骤的依赖关系后，将创建 TripleO Ceph 外部 Heat 资源，以将适当的 Overcloud 节点配置为 Ceph 客户端。

  22. 对于 CephRGW 服务，将发出 hieradata，以便将其用于 haproxy 监听器设置和 keystone 用户设置。

  23. Overcloud 部署将继续，就像它正在使用外部 Ceph 集群一样。

将额外的 Ceph OSD 节点添加到现有的 OpenStack 和 Ceph 集群

添加额外的 Ceph OSD 节点的流程与在 Overcloud 部署 OSD 时的流程类似

  1. 内省新的硬件以托管 OSD。

  2. 在包含节点计数的 Heat 环境文件中，增加 CephStorageCount。

  3. 使用标准 Ceph 选项和指定通过 ceph-ansible 实现 Ceph 部署的环境文件运行 `openstack overcloud deploy`。

  4. undercloud 更新部署计划。

  5. Mistral 启动工作流以更新 Overcloud 并相应地与 Heat 交互。

  6. 部署达到一个点，新 Overcloud 节点被镜像、启动和联网。 此时，undercloud 可以访问 Overcloud 节点的配置或管理 IP。

  7. 创建一个新的 Heat 资源，该资源启动一个 Mistral 工作流以添加新的 Ceph OSD。

  8. 在 OSD 主机上打开 TCP 端口 6800:7300 [7]。

  9. Mistral 环境已经具有 SSH 密钥对，如初始部署场景中所述。用于将公共 SSH 密钥安装到 TripleO 验证的 Overcloud 节点上的相同过程用于安装 ceph-ansible 的 SSH 密钥。

  10. 如果需要，Mistral 工作流会根据将要引导的新机器数量更新 Ansible 中的分支数。

  11. 动态 Ansible 库存将包含新节点。

  12. Mistral 确认 Ansible 可以执行 `ansible osds -m ping`。这将导致 Ansible 以 heat-admin 用户身份通过 SSH 进入所有 CephOsdAnsible 节点，包括新节点。如果这失败，则更新将失败。

  13. Mistral 使用 Heat 中找到的 Ceph 变量，如初始部署场景中所述。

  14. Mistral 运行 ceph-ansible 中的 osd-configure.yaml playbook 以添加额外的 Ceph OSD 服务器。

  15. 服务器上的 OSD 每个都部署在自己的容器中，并且 `docker ps` 将列出每个 OSD 容器。

  16. 在 Mistral 工作流完成后，自定义 Heat 资源被认为已更新。

  17. 由于 Overcloud Ceph 客户端只需要来自 Ceph 监视器的有关新 OSD 的信息，因此无需更改 TripleO Ceph 外部 Heat 资源。

  18. Overcloud 部署将继续，就像它正在使用外部 Ceph 集群一样。

配置文件的容器化

如 Containerize TripleO 规范中所述，容器化服务的配置文件将由 Puppet 生成，然后通过配置卷传递给容器化服务 [8]。ceph-ansible 已经支持类似的容器化功能，它使用以下序列生成 ceph.conf 配置文件。

  • Ansible 在监视器节点上生成 ceph.conf

  • Ansible 运行监视器容器并绑定挂载 /etc/ceph

  • 未对 ceph.conf 进行任何修改

  • Ansible 将 ceph.conf 复制到 Ansible 服务器

  • Ansible 将 ceph.conf 和密钥复制到适当的机器

  • Ansible 运行 OSD 容器并绑定挂载 /etc/ceph

  • 未对 ceph.conf 进行任何修改

这些类似的过程是兼容的，即使在容器主机运行多个 OpenStack 服务但每个服务都需要其自己配置文件副本的情况下也是如此。例如，考虑一个托管 Nova 计算和 Ceph OSD 服务的容器化节点。在这种情况下，Nova 计算服务将是 Ceph 客户端，puppet-ceph 将生成其 ceph.conf，而 Ceph OSD 服务将是 Ceph 服务器，ceph-ansible 将生成其 ceph.conf。Puppet 需要配置 Ceph 客户端，因为 Puppet 配置其他 OpenStack 相关配置文件，如 TripleO 已经提供的。这两个生成的 ceph.conf 文件都需要存储在容器化主机上的单独目录中，以避免冲突，并且这些目录可以映射到不同容器中的特定目录。例如，host0 可以具有以下版本的 foo.conf，用于两个不同的容器

host0:/container1/etc/foo.conf  <--- generated by conf tool 1
host0:/container2/etc/foo.conf  <--- generated by conf tool 2

当每个容器在主机上启动时，不同的配置文件可以映射到不同的容器

docker run containter1 ... /container1/etc/foo.conf:/etc/foo.conf
docker run containter2 ... /container2/etc/foo.conf:/etc/foo.conf

在上述场景中，有必要从相同的参数生成两个配置文件。即，Puppet 和 Ansible 将使用 Heat 环境文件中的相同值，但会以不同的方式生成配置文件。在配置程序运行后，即使 Puppet 幂等更新了 ceph.conf 的行，而 Ansible 使用了 Jina2 模板，也无关紧要。重要的是两个配置文件具有相同的值，例如，相同的 FSID。

如 Containerize TripleO 规范中所述生成的配置文件不会在将其传递给容器来宾的绑定挂载之前将这些配置文件存储在容器主机 `/etc` 目录中。默认情况下，ceph-ansible 在容器主机 `/etc` 目录中生成初始 ceph.conf，然后使用绑定挂载将其传递到容器。为了与 Containerize TripleO 规范保持一致，ceph-ansible 将获得一个新功能，用于在容器中部署 Ceph，以便它不会在容器主机 `/etc` 目录中生成 ceph.conf。相同的选项需要应用于生成 Ceph 密钥环时；这些密钥环将存储在容器中的 `/etc/ceph` 中，但不在容器主机上。

由于 undercloud 上的 Mistral 运行 ansible playbook，undercloud 上的“mistral”用户将是进入 Overcloud 节点以运行 ansible playbook 的用户。需要小心确保用户不会进行超出范围的更改。

替代方案

从高级别来看，该提案是使用 TripleO 部署 Ceph 的当前方法的替代方案，并提供了问题描述中列出的好处。

从较低级别来看，应考虑如何在 Workflow 部分中描述的实现此提案的方式。

  1. 在拆分堆栈场景中，在硬件由第一个 Heat 堆栈配置后，在创建配置 Heat 堆栈之前，可以运行类似于 POC 中的 Mistral 工作流 [3]，以配置 Ceph 节点上的 Ceph。此场景将更类似于使用 TripleO Heat Templates 环境文件 puppet-ceph-external.yaml 部署 TripleO 的场景。这可能是对新的 OS::Mistral::WorflowExecution Heat 资源 [6] 的替代方案。

  2. 在初始工作流部分中，提出“创建一个新的 Heat 资源，该资源启动一个 Mistral 工作流以部署 Ceph”。这可能很困难，因为通常，可组合的服务当前定义了 puppet 数据的片段，然后将这些片段组合起来定义部署步骤，并且还没有一种方法可以在部署的给定步骤中支持运行任意 Mistral 工作流。因此，可以先启动 Mistral 工作流，然后等待概述部分第 6 步中描述的内容。

安全影响

  • 将在 undercloud 上创建一个新的 SSH 密钥对，并且可以通过类似于 `mistral environment-get ssh_keys_ceph` 的命令在 Mistral 环境中访问该密钥对。此过程将遵循与创建 TripleO 验证中使用的 Overcloud 节点上的 SSH 密钥相同的模式，因此在这一方面不会发生任何新的事情；只是相同类型过程的另一个实例。

  • 将使用其他工具对 Overcloud 进行配置，但影响应通过容器隔离。

  • 无论如何配置 Ceph 服务，都需要更改防火墙。此规范将实现 Ceph 服务的防火墙规则的奇偶校验 [7]。

其他最终用户影响

无。

性能影响

以下适用于 undercloud

  • Mistral 需要运行额外的 workflow

  • Heat 在部署 Ceph 中的作用将减小，因此 Heat 堆栈将更小。

其他部署者影响

Ceph 将使用一种经过验证的方法进行部署，但其集成是 TripleO 的新功能。

开发人员影响

无。

实现

负责人

主要负责人

fultonj

其他贡献者

gfidente leseb colonwq d0ugal（审查 Mistral 工作流/操作）

工作项

  • 原型化 Mistral 工作流，以独立在 Overcloud 节点上安装 Ceph [3]。[完成]

  • 原型化 Heat 资源以启动独立的 Mistral Workflow [6]。[完成]

  • 扩展 mistral-ansible-actions 以包含必要的选项 (fultonj)

  • 参数化 mistral 工作流 (fultonj)

  • 更新并合并 Heat CustomResource [6] (gfidente)

  • 让 ceph-ansible 创建用于容器化部署的 openstack 池和密钥：https://github.com/ceph/ceph-ansible/issues/1321 (leseb)

  • 将 ceph-ansible 打包到 ceph.com 中并推送到 centos cbs (fultonj / leseb)

  • 通过修改 RDO 的 instack RPM 的 spec 文件以添加依赖项，使 undercloud 安装生成 /usr/share/ceph-ansible (fultonj)

  • 将 mistral 工作流和 ansible-mistral-actions 提交到 tripleo-common (fultonj)

  • 原型化新的服务插件接口，该接口定义了每个服务的 workflow (gfidente / shardy / fultonj)

  • 将新服务提交到 tht/roles_data.yaml，以便用户可以使用它。这应该包括对 tripleo-heat-templates ci/environments/scenario001-multinode.yaml 的更改，以包含新的服务，例如 CephMonAnsible，以便对 CI 进行测试。如果所有服务都可以共存，这才能起作用。我们可能会先更改 ovb-nonha 场景，因为我们认为这可能会更快。当 CI 迁移到 tripleo-quickstart 并且有一个仅容器的场景时，我们希望添加一个混合容器化部署。

  • 实现删除 Ceph 集群的场景

  • 实现将额外的 Ceph OSD 节点添加到现有的 OpenStack 和 Ceph 集群的场景

  • 实现删除 Ceph OSD 节点的场景

  • 实现对 Ceph OSD 节点进行维护（可选）

依赖项

通过 ceph-ansible 容器化 Ceph 服务，以确保配置工具不会竞争。这需要与 Containerize TripleO 规范 [9] 兼容。

测试

对 tripleo-heat-templates 的 scenario001-multinode.yaml 进行更改，其中包括部署新的服务 CephMonAnsible 和 CephOsdAnsible（请注意，这些角色名称将在完全工作时更改）。此测试场景可能无法工作，除非所有服务都可以共存；但是，初步测试表明这可行。最初 scenario004 将不会被修改，并将继续使用 puppet-ceph。

文档影响

需要一份新的 TripleO 后端配置文档“使用 ceph-ansible 部署 Ceph”。

参考资料