TripleO Ceph Ganesha 集成 Manila¶
从 Octopus 版本开始，Ceph 引入了自己的 day1 工具 cephadm 和自己的 day2 工具 orchestrator，取代了 ceph-ansible。在 Wallaby 和 Xena 周期中，TripleO 移除了对 ceph-ansible 的依赖，并采用了 cephadm [1]，如 [2] 中所述。然而，ganesha 守护进程的部署仍然由 tripleo-ansible 控制，包含一组任务，旨在复制 ceph-nfs ceph-ansible role 的相关部分 [3]。这种选择确保了与旧版本的向后兼容性。
问题描述¶
在 TripleO 中，我们支持在 Ceph 集群由 TripleO 管理和 Ceph 集群不由 TripleO 管理两种情况下部署 Ganesha。当集群由 TripleO 管理时，可以通过 tripleo-ansible 模块将 NFS 守护进程作为常规 TripleO 服务部署 [4]。最好让 cephadm 管理 NFS 容器的生命周期，而不是使用 tripleo-ansible 部署它。为了做到这一点，我们需要在 TripleO 和 Manila 两者上进行以下更改
orchestrator 提供了一个接口，Manila 应该使用该接口与 ganesha 实例交互。nfs orchestrator 接口在 [5] 中描述，可用于操作 nfs 守护进程，以及创建和删除导出。过去，ganesha 配置文件完全由 ceph-ansible 自定义；orchestrator 将有一组覆盖来保持向后兼容性。通过设置一个存在于 Ceph 集群内的 userconfig 对象来实现此结果 [5]。将能够使用 orchestrator 提供的相同接口来检查、更改和重置 nfs 守护进程配置 [11]。
部署的 NFS 守护进程基于 watch_url 机制 [6]：采用 cephadm 部署的 ganesha 实例需要 Manila 驱动程序更新以支持这种新方法。这项工作在 [10] 中描述。
cephadm 部署的 ceph-nfs 守护进程有自己的 HA 机制，称为 ingress，它基于 haproxy 和 keepalived [7]，因此我们将不再使用 pcmk 作为 VIP 的所有者。请注意，这意味着我们将运行 pcmk 和 keepalived，以及由 tripleo 部署的 haproxy 和由 cephadm 部署的另一个 haproxy 在同一服务器上（尽管监听端口不同）。由于 cephadm 正在控制 ganesha 的生命周期，因此将不再使用 pcs cli 与 ganesha 守护进程交互，我们将更改 ingress 守护进程的使用位置。
当 Ceph 集群不由 TripleO 管理时，Ganesha 服务当前作为独立服务部署在 overcloud 上，并配置为使用外部 Ceph MON 和 MDS 守护进程。但是，如果实施此规范，则将不再由 TripleO 部署独立 ganesha 服务。相反，我们将要求外部 ceph 集群的管理员将 ceph-nfs 服务添加到该集群。尽管 TripleO 仍然会配置 Manila 以使用该服务。
因此，在外部情况下，Ganesha 不会被部署，并且必须在 overcloud 部署期间作为输入提供有关外部 Ganesha 的详细信息。我们还将提供工具来帮助已在 overcloud 上部署 Ganesaha 的人将服务迁移到他们的外部 Ceph 集群。从高层来看，流程如下
生成一个 cephadm 规范，以便在外部 ceph 集群由 cephadm 管理后，可以使用该规范添加具有所需属性的 ceph-nfs 服务。
禁用 VIP PCS 使用，并提供记录的方法将其移动到外部 ceph 集群。
提议的变更¶
概述¶
一个 ansible 任务将生成 Ceph NFS 守护进程规范，并触发 cephadm [2] 部署 Ganesha 容器。
NFS 规范应被渲染并应用于现有的 Ceph 集群
ingress 规范应被渲染（作为 NFS 部署的一部分）并应用于集群
容器将不再由 pacemaker 控制。
安全影响¶
无，TripleO 已经用于生成 Ceph 集群配置和密钥链的代码将被消耗。
升级影响¶
我们将弃用由 PCS 管理的 ganesha，以便它仍然可以工作直到 Z。
我们将提供 playbook，从旧的 NFS 服务迁移到新的服务。
我们假设这些 playbook 将在 Z 中可用，并在升级到下一个版本之前运行。
其他最终用户影响¶
对于全新部署，现有的输入参数将被重用以驱动新的部署工具。对于现有环境，在 Ceph 升级后，TripleO 部署的 NFS 实例将被停止并由提供的迁移 playbook 移除，以及相关的 pacemaker 资源和约束；cephadm 将能够部署和管理新的 NFS 实例，最终用户将看到 NFS 服务中断。
性能影响¶
没有更改。
其他部署者影响¶
“部署的 ceph”：对于此规范的首次实施，我们将在 overcloud 部署期间部署，但我们将努力交付使其与“部署的 ceph”兼容。VIP 在 openstack overcloud network vip provision 之前，在 openstack overcloud network provision 之前，以及在 openstack overcloud node provision 之前被配置，因此我们将提前拥有 ingress VIP，以便我们可以使用“部署的 ceph”执行此操作。
directord/task-core：最终我们需要在 directord/task-core 工具中实现这一点，但可以从添加到 tripleo_ceph role 的 ansible 任务开始。根据我们在实施时 directord/task-core 迁移的状态，我们可能会跳过 ansible 部分，尽管我们可以用它进行 POC 以开始使用。
开发人员影响¶
假设 manila 服务能够使用 watch_url 机制与 Ganesha 交互，NFS 守护进程可以作为常规 Ceph 守护进程使用 tripleo-ansible 模块提供的 spec 方法生成 [4]。
实现¶
部署流程¶
此规范中描述的部署和配置将在 openstack overcloud deploy 期间发生，如 [8] 中所述。这与 tripleo-ansible 在 step2 中用于配置这些服务的方式一致。tripleo-ansible 任务应从纯 ansible 模板方法移动到根据提供的输入生成 systemd unit 的方法，到基于 cephadm 的守护进程，该守护进程可以使用常规 Ceph mgr config-key 机制进行配置。如概述部分所述，将定义并部署一个 ingress 对象，并且应该管理此组件的 VIP 和 HA。
负责人¶
fmount
fultonj
gfidente
工作项¶
更改 tripleo-ansible 模块以支持 Ceph ingress 守护进程类型
创建一组任务来部署 nfs 和相关的 ingress 守护进程
弃用与 ceph-nfs 相关的 pacemaker 配置，包括 pacemaker 约束，即 manila-share 服务和 ceph-nfs 之间的约束
创建升级 playbook，从 TripleO/pcmk 管理的 nfs ganesha 迁移到由 cephadm 部署并由 ceph orch 管理的 nfs 守护进程
依赖项¶
这项工作取决于 manila 规范 [10]，该规范从 dbus 迁移到 watch_url 方法
测试¶
NFS 守护进程功能可以在 day1 启用，并且将针对现有的 TripleO scenario004 [9] 进行测试。作为实施计划的一部分，更新现有的 heat 模板环境 CI 文件，其中包含测试作业参数，是此规范的目标之一。作业定义过程的一个重要方面与独立 vs 多节点相关。如过去所见，多节点可以帮助捕获在独立环境中不可见的问题，但当然可以在下一个周期中改进作业配置，我们可以从今天的 CI 中存在的独立测试开始。
文档影响¶
无需对 TripleO 文档进行任何更改，因为描述的接口保持不变。但是，我们应该为需要从 TripleO/pcmk 管理的 nfs ganesha 迁移到由 cephadm 部署并由 ceph orch 管理的 nfs 守护进程的现有环境提供升级说明。
