TripleO Ceph Ingress Daemon 集成¶
从 Octopus 版本开始，Ceph 引入了自己的 day1 工具 cephadm 和自己的 day2 工具 orchestrator，取代了 ceph-ansible。在 Wallaby 和 Xena 周期中，TripleO 逐渐放弃了 ceph-ansible 并采用了 cephadm [1]，如 [2] 中所述。在 Xena 周期中，一种在 TripleO 环境中部署 Ceph 的新方法已经建立，现在可以在创建 overcloud 之前配置 Ceph 集群，将 Ceph 集群的最终配置留给 overcloud 部署阶段，该配置取决于由 tripleo-heat-templates 接口定义的启用的 OpenStack 服务。下一个目标是尽可能多地使用部署的 ceph 接口来部署 Ceph 服务，而不是在 overcloud 部署期间进行部署。作为这项工作的一部分，我们应该关注高可用性方面，它在当前版本中的实现方式以及 Ceph 应该如何更改。本规范是对 [3] 的后续，它定义了依赖 Ceph 提供的 HA daemon 的要求，并描述了 TripleO 为实现此目标所需的更改。
问题描述¶
在以下描述中，我们指的是 Ganesha daemon 以及相关 Ceph Ingress daemon 部署的需求，但同样适用于所有需要高可用性配置的现有 daemon（例如，RGW 和下一个 Ceph 版本的 Ceph dashboard）。在 TripleO 中，我们支持在 Ceph 集群由 TripleO 管理和 Ceph 集群本身不由 TripleO 管理时部署 Ganesha。当集群由 TripleO 管理时，根据规范 [3]，最好让 cephadm 管理 NFS 容器的生命周期，而不是使用 tripleo-ansible 部署它，这已得到广泛覆盖并解决，允许 tripleo Ceph mkspec 模块支持新的 Ceph daemon [4]。由 cephadm 部署的 ceph-nfs daemon 具有自己的 HA 机制，称为 ingress，它基于 haproxy 和 keepalived [5]，因此我们不再使用 pcmk 作为 VIP 的所有者。这意味着我们将运行 pcmk 和 keepalived，以及由 tripleo 部署的 haproxy 和由 cephadm 部署的另一个 haproxy，在同一服务器上（尽管侦听器在不同的端口上）。这种方法仅依赖 Ceph 组件，并且涵盖了外部和内部场景。但是，采用 ingress daemon 用于 TripleO 部署的 Ceph 集群意味着我们需要让 overcloud 意识到新的正在运行的服务：因此，拟议的更改旨在引入一个新的 TripleO 资源，该资源可以正确处理与 Ceph 服务的接口，并与 tripleo-heat-templates 角色保持一致。
提议的变更¶
概述¶
本规范提出的更改需要引入一个新的 TripleO Ceph Ingress 资源，该资源描述了提供负载平衡和 HA 的 ingress 服务。添加新的 OS::TripleO::Services::CephIngress 资源的影响可以在以下项目中看到。
tripleo-common¶
如“容器镜像准备”[6] 中所述，undercloud 可以用作所有与 ceph 相关的容器的容器注册表，并且已经为 部署的 ceph 引入了一种新的受支持的语法，以从经过身份验证的注册表下载容器。但是，根据 [7]，Ceph ingress daemon 不会内置到 Ceph daemon 容器中，因此 tripleo 容器镜像准备 应该执行以拉取新的容器镜像/标签到 undercloud 中，就像 Ceph Dashboard 和常规 Ceph 镜像一样。一旦 ingress 容器可用，就可以在 ceph-nfs 或 ceph-rgw 之上部署 daemon。特别是，如果将实施本规范，部署的 ceph 将是设置 ceph-nfs 中此 daemon 的唯一方法，从而简化 tripleo-heat-templates 接口并减少 tripleo ansible 任务的执行次数，因为部分配置在 overcloud 部署之前移动。作为这项工作的一部分，考虑到 Ceph 相关的容器镜像随着时间的推移而增长，将向 tripleo-container jinja 模板 [8] 添加一个新的条件，以避免在 Ceph 未由 TripleO 部署时拉取额外的 ceph 镜像 [10]。这将为所有 Ceph 外部集群用例以及现有的 CI 作业（没有 Ceph）带来新的优化。
tripleo-heat-templates¶
将在 cephadm 空间内创建一个 Heat 资源。新的资源也将添加到现有的 Controller 角色中，并且所有相关的环境文件都将使用新的引用进行更新。此外，如规范 [3] 中所述，ceph-nfs 的 pacemaker 约束以及相关的 vip 将被删除。tripleo-common ceph_spec 库已经能够生成这种 daemon 的规范，并且它将触发 cephadm [4] 来部署 ingress daemon，前提是 NFS Ceph 规范应用于现有的集群并且后端 daemon 正在运行。如前所述，ingress daemon 也可以部署在 RGW 实例之上，因此拟议的更改对所有需要 HA 配置的 Ceph 服务都有效。
安全影响¶
应用于现有的 ceph-nfs 实例的 ingress daemon 由 cephadm 管理，从而简化了生命周期模型。在应用 ceph-nfs 实例后会生成 ingress daemon 的 Ceph 规范，并且如 [5] 所述，它需要两个额外的选项
frontend_port
monitoring_port
这两个端口由 haproxy 接受传入请求和用于监控目的，因此我们需要让 TripleO 意识到这项新服务并正确设置防火墙规则。只要规范中定义的端口传递到 overcloud 部署过程并定义在 tripleo-heat-templates CephIngress daemon 资源中，就会运行 firewall_rules tripleo ansible 角色，并为前端和监控端口应用规则。此 daemon 使用的常规网络（并受新应用规则的影响）是 StorageNFS，但我们可能会遇到操作员覆盖它的情况。与 CephIngress 资源相关的容器镜像的生命周期、构建和安全性方面不由 TripleO 管理，Ceph 组织负责维护和更新。
升级影响¶
现有 Ceph 集群的问题在规范 [8] 中有涵盖。
性能影响¶
由于引入了两个新的镜像（以及等效的 tripleo-heat-templates 服务），因此需要一些时间才能将这些新的附加容器拉取到 undercloud 中。但是，tripleo_containers jinja 模板已更新，将 Ceph 相关的容器镜像分离出来。特别是，在容器镜像准备阶段，添加了一个新的布尔选项，并且可以通过将 ceph_images 布尔值设置为 false 来避免拉取 Ceph 镜像。通过这样做，我们可以提高在不需要 Ceph 时性能。
开发人员影响¶
这项工作可以轻松扩展到将 RGW 服务迁移到部署的 ceph，但这超出了本规范的范围。
实现¶
部署流程¶
本规范中描述的部署和配置将在 openstack overcloud ceph deploy 期间发生，如 [8] 中所述。当前 openstack overcloud network vip provision 的实现允许为每个网络配置 1 个 vip，这意味着使用新的 Ceph Ingress daemon（需要每个服务 1 个 vip）可能会破坏仍然使用存储网络（或任何其他网络，具体取决于 tripleo-heat-templates 覆盖）上配置的 vip 并由 pacemaker 管理的组件。将为 openstack overcloud ceph deploy 命令添加一个新的选项 –ceph-vip [11]。可以使用此选项为输入中定义的“service/network”映射指定的每个 Ceph 服务保留 VIP。例如，通用的 ceph 服务映射可以是以下内容
---
ceph_services:
- service: ceph_nfs
network: storage
- service: ceph_rgw
network: storage
对于添加到上述列表中的每个服务，将在指定的网络（可以是可组合网络）上创建一个虚拟 ip，并将其用作 ingress daemon 的 frontend_vip。如概述部分所述，将定义并部署 ingress 对象，并且应该管理此组件的 VIP 和 HA。
负责人¶
fmount
fultonj
gfidente
工作项¶
创建一个新的 Ceph 前缀的 Heat 资源，该资源描述了 TripleO 环境中的 Ingress daemon。
将 haproxy 和 keepalived 容器添加到 Ceph 容器列表中，以便在 容器镜像准备 阶段拉取它们。
创建一组任务来部署 nfs 和相关的 ingress daemon
弃用与 ceph-nfs 相关的 pacemaker 配置，包括 manila-share 服务与 ceph-nfs 之间的 pacemaker 约束
创建升级 playbook 以从 TripleO/pcmk 管理的 nfs ganesha 迁移到由 cephadm 部署并由 ceph orch 管理的 nfs/ingress daemon
取决于 directord/task-core 迁移的状态，我们可能会跳过 ansible 部分，尽管我们可以用它来入门，扩展现有的 tripleo-ansible cephadm 角色。
依赖项¶
这项工作依赖于 tripleo_ceph_nfs 规范 [3]，该规范从 tripleo 部署的 ganesha 迁移到 cephadm 方法。
测试¶
NFS daemon 功能可以在 day1 启用，并且将针对现有的 TripleO scenario004 [9] 进行测试。作为实施计划的一部分，更新现有的 heat 模板环境 CI 文件（其中包含 Heat 资源和测试作业参数）是本规范的目标之一。
文档影响¶
文档将描述引入到 部署的 ceph cli 的新参数，以便能够将其他 daemon（ceph-nfs 和相关的 ingress daemon）作为部署的 ceph 的一部分进行部署。但是，我们应该为需要从 TripleO/pcmk 管理的 nfs ganesha 迁移到由 cephadm 部署并由 ceph orch 管理的 nfs daemon 的现有环境提供升级说明。
