TripleO Ceph¶
https://blueprints.launchpad.net/tripleo/+spec/tripleo-ceph
一个轻量级的 Ansible 框架，用于 TripleO 与使用 cephadm 部署并使用 Ceph orchestrator 管理的 Ceph 集群集成。
问题描述¶
从 Octopus 版本开始，Ceph 拥有自己的 day1 工具，称为 cephadm，以及自己的 day2 工具，称为 orchestrator，这将取代 ceph-ansible。TripleO 的 Ceph 集成应该如何应对？我们目前提供的用户体验是
描述一个包含 Ceph 的 OpenStack 部署，TripleO 将“实现它”
以上对于 TripleO 来说从 Kilo 版本开始就是事实，并且应该继续保持。TripleO 还应继续支持超融合支持（OpenStack 和 Ceph 容器的共置）。这两者都具有足够的价值（一个工具和超融合），以证明该项目的合理性。同时，我们希望以与 Ceph 项目发展一致的方式部署 Ceph，并从 TripleO 中解耦 Ceph day2 管理的复杂性。
提议的变更¶
概述¶
修改 tripleo-ansible、tripleo-heat-templates 和 python-tripleoclient，以支持以下目标
提供 Ansible 角色，通过调用 cephadm 和 Ceph orchestrator 来部署 Ceph
专注于 Ceph RBD、RGW、CephFS 和 Dashboard 部署的 day1 问题，通过利用 cephadm bootstrap –apply-spec，如 Ceph issue 44873 中所述
默认情况下，day2 Ceph 操作应直接使用 Ceph orchestrator 或 Ceph Dashboard 进行，而不是运行 openstack overcloud deploy
TripleO 堆栈更新不会触发此规范引入的新 Ansible 角色。
基于来自 TripleO 的参数（包括来自 Ironic 的硬件详细信息）提供一种 Ceph 安装方案
为已部署的 Ceph 集群配置 cephx 密钥环和池
支持 OpenStack/Ceph 容器在同一主机上的共置（超融合） - cephadm 调解循环不得破坏 OpenStack 配置 - TripleO 配置更新不得破坏 Ceph 配置
提供 Ceph 集成，但最大限度地提高 OpenStack 和 Ceph 之间的正交性
在 W 周期内 TripleO CephClient 服务的实现包含在另一个正在审核的规范中 757644。这项工作将在描述在此规范中的工作之前合并，因为它将与当前的 Ceph 部署方法兼容。它也将与此规范中描述的未来部署方法兼容。
集成点¶
TripleO Victoria 的 OpenStack/Ceph 的默认部署方法是以下 2 步流程
使用 metalsmith 部署节点
使用 openstack overcloud deploy 部署 OpenStack 和 Ceph
项目 2 的 Ceph 部分使用 external_deploy_steps_tasks 调用 ceph-ansible，通过使用 tripleo-ansible 角色：tripleo_ceph_common、tripleo_ceph_uuid、tripleo_ceph_work_dir、tripleo_ceph_run_ansible。
此规范的最终目标是支持以下 4 步流程
使用 metalsmith 部署硬件
配置网络（包括存储网络）
使用 tripleo-ansible/python-tripleoclient 提供的角色和接口部署 Ceph
使用 openstack overcloud deploy 部署 OpenStack
项目 2 上面依赖于 review 752437 中描述的网络数据 v2 格式规范，以及后续的网络相关功能，该功能将端口管理移出 Heat，并支持在 Heat 堆栈部署之前应用网络配置，如 review 760536 中所述。
项目 3 上面是此规范的重点，但它不一定是唯一的集成点。如果无法在部署 OpenStack 之前配置存储网络，那么新的 Ceph 部署方法仍然会通过 external_deploy_steps_tasks 进行，就像 Victoria 中的 2 步流程中一样。换句话说，Ceph 可以在 2 步流程的 overcloud 部署期间部署，也可以在 4 步流程的 overcloud 之前部署；无论哪种方式，我们将改变 Ceph 的部署方式。
在 overcloud 部署之前部署 Ceph 的好处是 Ceph 部署的复杂性与 OpenStack 部署的复杂性解耦。即使 Ceph 在 overcloud 之前部署，其部署仍然是 TripleO 的一部分，就像裸机部署是 TripleO 的一部分一样；即使使用单独的工具，例如 metalsmith 或 cephadm 来部署未在运行 openstack overcloud deploy 时部署的资源。
关于 Ceph 在 overcloud 部署之前与期间的部署方式的更多详细信息，将在实施部分中介绍。
替代方案¶
我们可以要求部署者执行以下操作
部署硬件并配置网络
使用 cephadm 和 orchestrator 直接配置该硬件与 Ceph，并创建可由 CephX 客户端访问的 OpenStack 池
使用 TripleO 配置 OpenStack
我们已经使用 Ussuri 和 config-download 标签完成了上述 POC，仅运行某些步骤，但更希望提供一个自动化 Ceph 部署的选项。TripleO 项目已经确保从一个到三个是自动化的，并且只需要两个命令，因为 tripleo python 客户端现在有一个调用 metalsmith 的选项。另一种选择是不自动化第二步，但这对用户不友好。
另一种选择是继续使用 ceph-ansible，就像我们今天一样。但是，即使 ceph-ansible 今天可以部署 Octopus，并将继续支持 Luminous 和 Nautilus 的部署，但该项目有一个 cephadm-adopt playbook，用于将 ceph-ansible 部署的 Ceph 集群转换为由 cephadm orchestrator 管理，因此似乎正在远离真正的 Octopus 支持。ceph-ansible 有大量的代码和 day2 支持；将其移植到 cephadm 或 orchestrator 比完成此项目的工作量更大，范围更小，耦合更松散。
安全影响¶
cephadm 工具是命令式的，需要 SSH 访问 Ceph 集群节点才能执行远程命令并部署指定的服务。此命令需要安装在将托管可组合 CephMon 服务的 overcloud 节点之一上。从 cephadm 的角度来看，该节点将是创建 Ceph 集群的引导节点。
因此，Ceph 集群节点必须可 SSH 访问，并提供具有 root 权限的用户来执行某些任务。例如，使用 cephadm 添加新主机的标准方法是运行以下命令
ssh-copy-id -f -i /etc/ceph/ceph.pub root@*<new-host>*
ceph orch host add *<new-host>*
TripleO 部署流程，特别是 config-download，已经提供了正确配置和运行上述两个操作的要素，因此从安全角度来看，影响与之前的部署模型相比没有变化。
我们将创建一个名为 ceph-admin 的用户，使用 config-download 创建 tripleo-admin 用户的方式，然后 cephadm 将在运行命令以添加其他主机时使用此用户。
升级影响¶
Ceph Nautilus 集群仍然由 ceph-ansible 管理，并且可以启用 cephadm 作为新的默认后端，一旦 Octopus 版本发布。因此，从 Nautilus 开始，升级过程中确定了两个主要步骤
使用 ceph-ansible rolling_update 升级集群：ceph-ansible 应该提供一个滚动更新 playbook，可以执行以将所有服务升级到 Octopus 版本
将现有集群迁移到 cephadm/orchestrator：当所有服务都升级到 Octopus 后，将执行 cephadm-adopt 作为附加步骤
新的 Ceph Octopus 部署集群将默认使用 cephadm 和 ceph orchestrator，未来的升级路径将由 cephadm_upgrade 提供，该升级路径将能够运行、停止和恢复所有 Ceph 升级阶段。此时，day2 ceph 操作需要直接使用 ceph orchestrator 进行。因此，不再需要在 openstack overcloud deploy 命令中包含 tripleo-heat-templates/environments/ceph-ansible/* 文件，除了如 review 757644 中所述的 Ceph 客户端配置，它将有一个新的环境文件。
注意
未来版本的升级过程可能会根据 OpenStack 的要求进行略微修改。
其他最终用户影响¶
从操作员的角度来看，主要好处是能够利用部署阶段和 day2 操作之间的明确分离，以及 Ceph 部署和 OpenStack 部署之间的分离。同时，TripleO 仍然可以使用单个工具来解决所有部署阶段的操作，但可以依赖 orchestrator 来处理 day2 任务。
许多常见任务现在可以以相同的方式执行，无论 Ceph 集群是内部的（由 TripleO 部署的）还是外部的。操作员可以使用 cephadm 和 orchestrator 工具，这些工具可以从 Ceph 集群监视器节点之一访问。
例如，由于 cephadm 维护集群的状态，操作员现在无需与 TripleO 交互即可执行以下任务
监视器替换
OSD 替换（如果需要硬件更改，则 Ironic 可能会参与其中）
注意
即使 cephadm 独立使用，当与 Ceph orchestrator 结合使用时，应该支持执行 day2 操作所需的所有命令，我们的计划是让 tripleo-ceph 继续管理和编排 TripleO 应该参与的操作。例如，如果添加 CephStorage 节点作为扩展操作，则 tripleo-ceph Ansible 角色应该调用以添加 OSD。
性能影响¶
堆栈更新不会触发 Ceph 工具，因此“仅 OpenStack”的更改不会因 Ceph 操作而延迟。Ceph 客户端配置所需的时间更短，但此好处在 review 757644 中涵盖。
其他部署者影响¶
与 ceph-ansible 一样，cephadm 以 RPM 的形式分发，可以从 Ceph 存储库安装。但是，由于更改了部署方法，并且 cephadm 需要 Ceph 监视器节点来引导一个最小集群，我们希望将 cephadm RPM 安装在 overcloud 镜像上。截至今天，此 RPM 大约为 46K，我们预计这将简化安装过程。当 cephadm 引导第一个 Ceph 监视器（默认在第一个 Controller 节点上）时，它将下载必要的 Ceph 容器。与当前的 Ceph 集成形成对比，ceph-ansible 需要安装在 undercloud 上，然后它管理将 Ceph 容器下载到 overcloud 节点。在 cephadm 和 ceph-ansible 的情况下，不需要对 overcloud 节点进行其他软件包更改，因为这两个工具都在容器中运行 Ceph。
此更改会影响所有部署与 Ceph 接口的 TripleO 用户。不与 Ceph 接口的任何 TripleO 用户将不会直接受到此项目的影响。
当前使用 environments/ceph-ansible/ceph-ansible.yaml 来使他们的 overcloud 部署内部 Ceph 集群的 TripleO 用户需要在部署 W 时迁移到新方法。这些文件将在下面详细描述中被弃用。
提出的更改在合并后不会立即生效，因为 ceph-ansible 和 cephadm 接口将同时存在于 intree 中。
开发人员影响¶
如何配置 Ceph 对于维护 TripleO 代码以使用 Ceph 的 OpenStack 服务可能会发生变化。理论上不应该有变化，因为 CephClient 服务仍然会在相同的位置配置 Ceph 配置和 Ceph 密钥文件。这些开发人员只需要在新的接口稳定后切换到新的接口。
实现¶
如何在 Ceph 在 overcloud 部署之前或期间部署时将配置数据传递给新的工具，如集成点部分开头的规范中描述的那样，将在本节中更详细地介绍。
弃用¶
tripleo-heat-templates/environments/ceph-ansible/* 和 tripleo-heat-templates/deployment/ceph-ansible/* 中的文件将在 W 中被弃用，并在 X 中删除。它们将被下一节中介绍的新 THT 参数取代，除了 ceph-ansible/ceph-ansible-external.yaml，它将被 environments/ceph-client.yaml 取代，如 review 757644 中所述。
以下 tripleo-ansible 角色将在 W 的开始时被弃用：tripleo_ceph_common、tripleo_ceph_uuid、tripleo_ceph_work_dir 和 tripleo_ceph_run_ansible。ceph_client 角色不会被弃用，但它将按照 review 757644 中所述重新实现。将引入新的角色来取代 tripleo-ansible。
在 X 期间完成此处描述的项目之前，我们将继续维护已弃用的 ceph-ansible 角色和 Heat 模板，在 W 的整个过程中，因此很可能在一个版本中，我们将同时支持 intree ceph-ansible 和 cephadm。
新的 THT 模板¶
并非所有 Ceph 的 THT 配置都可以删除。防火墙仍然基于 THT 配置，如下一节所述，THT 还控制部署哪个可组合服务以及部署在哪里。以下新文件将在 tripleo-heat-templates/environments/ 中创建
cephadm.yaml: 触发新的 cephadm Ansible 角色，直到 openstack overcloud ceph … 使其不再必要。包含 Ceph 最终状态定义 YAML 输入部分中描述的文件路径。
ceph-rbd.yaml: RBD 防火墙端口、池和 cephx 密钥默认值
ceph-rgw.yaml: RGW 防火墙端口、池和 cephx 密钥默认值
ceph-mds.yaml: MDS 防火墙端口、池和 cephx 密钥默认值
ceph-dashboard.yaml: Ceph Dashboard 防火墙端口默认值
以上所有文件（cephadm.yaml 除外）都将导致打开适当的防火墙端口，并连接到 Ceph 集群以创建 Ceph 池和访问这些池的 cephx 密钥的新幂等 Ansible 角色。将创建哪些端口、池和密钥取决于包含哪些文件。例如，如果部署者运行 openstack overcloud deploy … -e ceph-rbd.yaml -e cep-rgw.yaml，则将配置 Nova、Cinder 和 Glance 使用 Ceph RBD，RGW 将配置 Keystone，但不会创建 MDS 服务的防火墙端口、池和密钥，并且防火墙不会为 Ceph dashboard 打开。
以上所有文件（cephadm.yaml 除外）都不会导致 Ceph 本身被部署，并且以上文件中也不会包含部署 Ceph 本身所需的参数。例如，PG 数量和 OSD 设备将不再在 THT 中定义。相反，部署 Ceph 本身所需的参数将位于 tripleo_ceph_config.yaml 中，如 Ceph 最终状态定义 YAML 输入部分所述，cephadm.yaml 将仅包含对这些文件的引用。
如上所述创建的 cephx 密钥和池将产生如下所示的输出数据
pools:
- volumes
- vms
- images
- backups
openstack_keys:
- caps:
mgr: allow *
mon: profile rbd
osd: 'osd: profile rbd pool=volumes, profile rbd pool=backups,
profile rbd pool=vms, profile rbd pool=images'
key: AQCwmeRcAAAAABAA6SQU/bGqFjlfLro5KxrB1Q==
mode: '0600'
name: client.openstack
以上内容可以写入文件，例如 ceph_client.yaml，并作为输入传递给 review 757644 中描述的新 ceph 客户端角色（以及 Ceph 最终状态定义 YAML 输出中描述的输出 ceph_data.yaml 文件）。
在 DCN 部署中，此类型的信息是从 Heat 堆栈中通过 overcloud export ceph 提取的。当使用新的部署方法时，此信息可以直接从每个生成的 yaml 文件（例如 ceph_data.yaml 和 ceph_client.yaml）中获取，每个 Ceph 集群一个。
防火墙¶
目前防火墙未由 ceph-ansible 配置，也不会由 cephadm 配置，因为将使用其 –skip-firewalld。我们预计默认 overcloud 在 openstack overcloud deploy 引入它们之前不会有防火墙规则。前一节中描述的 THT 参数将具有与它们将要弃用的参数相同的防火墙端口（environments/ceph-ansible/*），以便根据服务和基于可组合角色的方式在防火墙中打开适当的端口，就像今天一样。
OSD 设备¶
当前的默认值对于某些人来说总是错误的，因为可用磁盘的 devices 列表总是会根据硬件而变化。新的默认值将使用所有可用设备通过运行 ceph orch apply osd –all-available-devices 来创建 OSD。但是，仍然可以通过 ceph-ansible 语法的 devices 列表来覆盖此默认值，该列表将被弃用。取而代之的是，将使用 cephadm drivegroups 定义的 OSD 服务规范，并且该工具将通过运行 ceph orch apply osd -i osd_spec.yml 来应用它。有关 osd_spec.yaml 的更多信息，请参阅 Ceph 最终状态定义 YAML 输入部分。
Ceph 放置组参数¶
新工具将使用启用 pg autotuner 功能的 Ceph 部署。用于设置放置组的参数将被弃用。那些希望禁用 pg autotuner 的人可以在 Ceph 部署后使用 Ceph CLI 工具来执行此操作。
Ceph 最终状态定义 YAML 输入¶
无论 Ceph 是在 overcloud 部署之前还是期间部署的，都将创建一个使用 cephadm 部署 Ceph 的新 playbook，它将接受以下文件作为输入
deployed-metal.yaml: 此文件是通过运行类似 openstack overcloud node provision … –output deployed-metal.yaml 的命令生成的，在使用 metalsmith 时。
(可选)“deployed-network-env”：该文件是由 openstack network provision 生成的，如 review 752437 中所述。当在 overcloud 部署之前部署 Ceph 时，此文件用于识别存储网络。当在 overcloud 部署期间部署 Ceph 时，这不再是必需的，因此是可选的，并且存储网络将像今天一样被识别。
(可选) 任何有效的 cephadm config.yml 规范文件，如 Ceph issue 44205 中所述，可以直接传递给 cephadm 执行，并在适用时将覆盖列表中末尾文件中所有相关设置。
(可选) 任何有效的 drivegroup YAML 文件（例如 osd_spec.yml）可以传递，并且该工具将使用 ceph orch apply osd -i osd_spec.yml 应用它。此设置将覆盖列表中末尾文件中所有相关设置。
tripleo_ceph_config.yaml: 此文件将包含与 TripleO Heat 模板支持的几乎所有 Ceph 选项兼容的配置数据，但防火墙、ceph 池和 cephx 密钥除外。此文件的模板将在新的 tripleo-ansible 角色之一（例如 tripleo_cephadm_common）中作为默认值提供。
输入到新 playbook 的另一个数据源是下一节中介绍的 inventory。
Ansible Inventory 和 Ansible 用户¶
当前的 Ceph 实现使用 Ansible 用户 tripleo-admin。该用户和相应的 SSH 密钥由 tripleo-ansible 角色 tripleo_create_admin 创建。此角色使用 heat-admin 帐户，如果未将 –overcloud-ssh-user 选项传递给 openstack overcloud node provision，则 heat-admin 帐户是默认帐户。当前的实现还使用 tripleo-ansible-inventory 生成的 inventory。如果 Ceph 在 overcloud 之前部署，则这些资源将不可用，并且如果 Ceph 在 overcloud 部署期间部署，则不需要它们。
无论 Ceph 是在 overcloud 之前还是期间部署，在部署 Ceph 之前，应运行 openstack overcloud admin authorize，并且它应传递选项以启用可用于 cephadm 的 ceph-admin 用户，并允许为 spec 中描述的 Ansible 角色进行 SSH 访问。
将实现一个新的命令 openstack overcloud ceph inventory，该命令为 spec 中描述的新 playbook 和角色创建 Ansible inventory。此命令将需要以下输入
deployed-metal.yaml: 此文件是通过运行类似 openstack overcloud node provision … –output deployed-metal.yaml 的命令生成的，在使用 metalsmith 时。
(可选) roles.yaml: 如果未传递此文件，则将使用 /usr/share/openstack-tripleo-heat-templates/roles_data.yaml 代替。如果 deployed-metal.yaml 中的角色在 roles.yaml 中找不到定义，则会抛出错误，表明正在使用的角色未定义。通过使用此文件，TripleO 可组合角色将继续像今天一样工作。与“OS::TripleO::Services::Ceph*”匹配的服务将对应于新的 Ansible inventory 组，该组中的主机将对应于 deployed-metal.yaml 中找到的主机。
(选项) -u –ssh-user <USER>: 这不是文件，而是一个默认值为“ceph-admin”的选项。这代表由 openstack overcloud admin authorize 在所有 overcloud 节点上创建的用户。
(选项) -i –inventory <FILE>: 这不是文件，而是一个默认值为“/home/stack/inventory.yaml”的选项。这代表将创建的 inventory。
如果 Ceph 在 overcloud 之前部署，用户需要运行此命令以生成 Ansible inventory 文件。他们还需要将生成的 inventory 文件路径传递给 openstack overcloud ceph provision 作为输入。
如果 Ceph 在 overcloud 部署期间部署，用户不需要了解此命令，因为 external_deploy_steps_tasks 将直接运行此命令以生成 inventory，然后再使用此 inventory 运行新的 tripleo ceph playbook。
Ceph 最终状态定义 YAML 输出¶
新的 playbook 将把输出数据写入一个 yaml 文件，该文件包含有关 Ceph 集群的信息，并可用于其他过程。
如果 Ceph 在 overcloud 之前部署，如果运行 openstack overcloud ceph provision –output ceph_data.yaml，则 ceph_data.yaml 将传递给 openstack overcloud deploy … -e ceph_data.yaml。 ceph_data.yaml 文件将包含键/值对，例如 Ceph FSID、Name 和 Ceph monitor IP。
如果 Ceph 与 overcloud 一起部署，如果 external_deploy_steps_tasks 调用新的 playbook，则将相同的文件写入其默认位置（/home/stack/ceph_data.yaml），并且新的客户端角色将直接从该文件读取参数。
此文件的一个示例，例如 ceph_data.yaml，如下所示
cluster: ceph
fsid: af25554b-42f6-4d2b-9b9b-d08a1132d3e899
ceph_mon_ips:
- 172.18.0.5
- 172.18.0.6
- 172.18.0.7
在 DCN 部署中，此类型的信息是从 Heat 堆栈中通过 overcloud export ceph 提取的。当使用新的部署方法时，此信息可以直接从 ceph_data.yaml 文件中获取，每个 Ceph 集群一个。此文件将作为输入传递给 review 757644 中描述的新 ceph 客户端角色。
在 Overcloud 部署期间部署 Ceph 的要求¶
如果 Ceph 在 overcloud 部署期间部署，则应满足以下条件
external_deploy_steps_tasks playbook 将在执行 openstack overcloud deploy 后执行新的 Ansible 角色。
如果运行 openstack overcloud node provision .. –output deployed-metal.yaml，则 deployed-metal.yaml 将作为输入传递给 openstack overcloud deploy。这是我们在 V 中当前的行為。
Ceph 的 day2 节点扩展操作应通过运行 openstack overcloud node provision 和 openstack overcloud deploy 来完成。除非这些操作被明确设置为“noop”，否则这将包括重新断言 OpenStack 服务的配置。
创建自己的 Ansible inventory 和用户
“Ceph 最终状态定义 YAML 输入”的路径通过 THT 参数引用，以便在 external_deploy_steps_tasks 运行时，它会将此文件传递给新的 playbook。
在 Overcloud 部署之前部署 Ceph 的要求¶
如果 Ceph 在 overcloud 部署之前部署，则应满足以下条件
新的 Ansible 角色将在用户运行类似 openstack overcloud ceph … 的命令时触发；此命令旨在在运行 openstack overcloud node provision 以触发 metalsmith 之后，但在运行 openstack overcloud deploy 之前运行。
如果运行 openstack overcloud node provision .. –output deployed-metal.yaml，则 deployed-metal.yaml 将作为输入传递给 openstack overcloud ceph provision。
Ceph 的 day2 节点扩展操作应通过运行 openstack overcloud node provision、openstack overcloud network provision 和 openstack overcloud admin authorize 来启用 ceph-admin 用户来完成。但是，没有必要运行 openstack overcloud ceph …，因为操作员应连接到 Ceph 集群本身以添加额外的资源，例如使用 cephadm shell 将新硬件添加为 OSD 或其他 Ceph 资源。如果操作包括添加同时具有 Ceph 和 OpenStack 服务的融合节点，则第三步将是运行 openstack overcloud deploy。
需要用户在使用新的 Ceph 部署工具之前创建 inventory（和用户）。
“Ceph 最终状态定义 YAML 输入”直接传递。
容器注册表支持¶
已经支持在 undercloud 上托管容器注册表。此注册表包含 Ceph 和 OpenStack 容器，并且可以在部署之前或部署期间填充它。在 overcloud 部署之前部署 ceph 时，需要在部署之前填充它。此 spec 中描述的新集成将指示 cephadm 从由 ContainerCephDaemonImage 标识的相同来源拉取 Ceph 容器。例如
ContainerCephDaemonImage: undercloud.ctlplane.mydomain.tld:8787/ceph-ci/daemon:v4.0.13-stable-4.0-nautilus-centos-7-x86_64
Ceph 在 Overcloud 之前部署的网络要求¶
将通过运行以下命令完成部署
openstack overcloud node provision …
openstack overcloud network provision … (参见 review 751875)
openstack overcloud ceph … (触发 cephadm/orchestrator)
openstack overcloud deploy …
过去堆栈更新完成了所有操作，但 metalsmith 建立了一种新的模式。根据 review 752437 和后续 spec 将端口管理移出 Heat，并在 Heat 堆栈部署之前应用网络配置，最终可以在 openstack overcloud deploy 运行之前配置网络。这为本 spec 的更大目标创造了一个机会，即在保持完全集成的同时，Ceph 和 OpenStack 部署之间的松散耦合。配置存储和存储管理网络后，就可以在配置任何 OpenStack 服务之前部署 Ceph。无论同一节点是托管 Ceph 和 OpenStack 容器，都应该可以做到这一点。
在 overcloud 部署之前部署 Ceph 的开发工作可以通过以下两种方法开始，在完成 reviews 752437 和 760536 中描述的工作之前
选项 1: - openstack overcloud deploy –skip-tags step2,step3,step4,step5 - 使用 tripleo-ceph 开发代码启动 Ceph - openstack overcloud deploy –tags step2,step3,step4,step5
最后一步还将配置 ceph 客户端。此序列已在提案的概念验证中得到验证。
选项 2：- 从 undercloud 创建存储和存储管理网络（使用 review 751875） - 根据 review 760536 为每个节点创建 Ironic 端口 - 使用 instances Nics Properties 传递一个字典列表，以便在通过 metalsmith 部署节点时，不仅在 ctlplane 网络上，还在存储和存储管理网络上配置节点 - Metalsmith/Ironic 应该附加 VIF，以便节点连接到存储和存储管理网络，以便随后可以部署 Ceph。
Ceph 使用的 PID1 服务¶
在 W 周期内，我们无法在 overcloud 部署之前完全部署 HA Dashboard 和 HA RGW 服务。因此，我们将像今天一样部署这些服务；通过使用 ceph 工具，虽然我们将使用 cephadm 代替 ceph-ansible，然后在 overcloud 部署期间完成这些服务的配置。虽然服务本身的部署工作将在 overcloud 部署之前完成，但该服务在 overcloud 部署之后才能以 HA 方式访问。
为什么我们无法在 overcloud 之前完全部署 HA RGW 服务？虽然 cephadm 可以在没有 TripleO 的情况下部署 HA RGW 服务，但其实现方式使用了 keepalived，而 keepalived 不能与 controller 节点上必需的 pacemaker 共存。因此，在 W 周期内，我们将继续使用带有 haproxy 的 RGW 服务，并在未来的周期中与 PID1 团队合作，重新考虑将其作为单独的部署。
为什么我们无法在 overcloud 之前完全部署 HA Dashboard 服务？cephadm 目前没有为其 dashboard 的内置 HA 模型，并且 HA Dashboard 仅在由 TripleO 部署时可用（除非手动配置）。
需要 VIP 的 Ceph 服务（Dashbard 和 RGW）需要提前知道 VIP 是什么，但这些 Ceph 服务在部署之前不需要能够 ping 通这些 VIP。相反，我们将能够根据与 review 751875 和 760536 相关的 work 知道 VIP 是什么。我们将这些 VIP 作为输入传递给 cephadm。
例如，如果我们提前知道 Dashboard VIP，我们可以运行以下命令
ceph --cluster {{ cluster }} dashboard set-grafana-api-url {{ dashboard_protocol }}://{{ VIP }}:{{ grafana_port }}"
新的自动化随后可以将 VIP 参数保存在 ceph mgr 全局配置中。部署者然后可以等待来自 overcloud 部署的 haproxy 可用，以便提供类似于 Victoria 部署的 HA dashbard。
如果我们能在 overcloud 部署之前解决上述问题会更简单，但这样做超出了本规范的范围。但是，我们可以在 X 周期左右的时间，通过与 Ceph orchestrator 社区合作，提供具有新工具的 HA dashboard。
今天的 TripleO 还支持在任何组合网络上部署 Ceph dashboard。如果 review 760536 中包含的工作允许我们提前组合和部署 overcloud 网络，那么我们计划将参数传递给 cephadm，以继续支持 dashboard 在其专用网络上运行。
TLS-Everywhere¶
如果 Ceph 在 overcloud 之前配置，那么我们将无法获得通过 TripleO 的 tls-everywhere 框架生成的证书和密钥。我们期望 cephadm 能够部署 Ceph Dashboard（带有 Grafana）、RGW（带有通过 haproxy 的 HA）并启用 TLS。为了保持正交性，我们可以要求 RGW 和 Dashboard 的证书和密钥在 TripleO 之外生成，以便这些服务可以在没有 overcloud 的情况下完全部署。但是，由于我们仍然需要使用前面部分中描述的 PID1 服务，我们将继续使用 TripleO 的 TLS-e 框架。
负责人¶
fmount
fultonj
gfidente
jmolmo
工作项¶
创建一个与 tripleo_ansible/roles/tripleo_cephadm_* 匹配的 roles 集合，这些 roles 可以与当前的 tripleo_ceph_common、tripleo_ceph_uuid、tripleo_ceph_work_dir、tripleo_ceph_run_ansible roles 共存。
修补 python tripleo 客户端以支持新的命令选项
创建一个新的 external_deploy_steps_tasks 接口，用于在 overcloud 部署期间使用新方法部署 Ceph
更新 THT scenario001/004 以使用新的 Ceph 部署方法
建议的时间表¶
OpenStack W：尽早合并 tripleo-ansible/roles/ceph_client descrbed 在 review 757644 中，因为它将与 ceph-ansible 内部 ceph 部署一起工作。创建 tripleo-ansible/roles/cephadm_* roles 和 tripleo 客户端工作，以将 Octopus 作为实验版本部署，然后作为默认版本（仅当稳定时）。如果新的 tripleo-ceph 尚未稳定，那么 Wallaby 将以 Nautilus 支持的形式发布，该支持由 ceph-ansible 部署，就像 Victoria 一样。无论哪种方式，通过当前 THT 和 tripleo-ansible 触发的 Nautilus 支持都将被弃用。
OpenStack X：tripleo-ansible/roles/cephadm_* 成为默认版本，tripleo-ansible/roles/ceph_* 被删除，除了新的 ceph_client，tripleo-heat-templates/environments/ceph-ansible/* 被删除。迁移到 Ceph Pacific，该版本于 2021 年 3 月上游 GA。
依赖项¶
如果我们选择在 overcloud 部署期间部署 Ceph，则不需要上述最后两项。
测试¶
本项目将针对至少两种不同的场景进行测试。这将确保对不同的用例和集群配置有足够的覆盖，这与 TripleO CI 中当前存在的 job 定义的状态非常相似。定义的场景将测试可以在 day1 启用的不同功能。作为实施计划的一部分，定义 tripleo-heat-templates 环境 CI 文件（包含测试 job 参数）是本项目的目标之一，我们应该确保有
一个基本场景，涵盖使用 cephadm 部署 ceph 集群；我们将根据此场景对 tripleo-ceph 项目进行 gate，以及相关的 tripleo heat templates 部署流程；
一个更高级的用例，旨在测试可以应用于 ceph 集群并由 tripleo-ceph 项目编排的配置。
上述两项与 TripleO CI 中今天维护的测试套件非常相似，并且可以通过修改现有场景来实现，并为 cephadm 部署模型添加适当的支持。可以创建一个 WIP patch 并提交，以测试和 gate tripleo-ceph 项目，并且当它变得足够稳定时，scenario001 就可以被官方合并。可以将相同的方法应用于现有的 scenario004，可以将其视为对第一个测试 job 的改进。这主要用于测试 Rados Gateway 服务部署和 manila pools 和 key 配置。job 定义过程的一个重要方面与 standalone vs multinode 相关。正如过去所见，multinode 可以帮助发现 standalone 环境中看不到的问题，但当然可以在下一个周期中改进 job 配置，并且可以从 standalone 测试开始，这正是今天 CI 中存在的。
文档影响¶
tripleo-docs 将更新，以涵盖 Ceph 与新工具的集成。
