TripleO Ceph 客户端¶

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

用于 TripleO 集成 Ceph 集群的本地 Ansible 角色。

问题描述¶

从 Octopus 版本开始，Ceph 拥有自己的 day1 工具 cephadm [1] 和自己的 day2 工具 orchestrator [2]，它们将取代 ceph-ansible [3]。虽然 ceph-ansible 具有配置 Ceph 客户端所需的功能，例如将配置文件和密钥环分发到非 Ceph 集群成员的节点，但 cephadm 和 orchestrator 都不会管理 Ceph 客户端配置。

目标是在 TripleO 中创建一些新的 Ansible 角色，以执行 Ceph 客户端（Nova、Cinder、Glance、Manila）配置，这在 TripleO 中尤其重要，以支持 Ceph 集群由外部管理、不由 undercloud 控制的部署场景，但 OpenStack 服务的配置仍然是 TripleO 的责任。

提议的变更¶

概述¶

在 tripleo-ansible 中引入一个新的角色，用于 Ceph 客户端配置。

新角色将

将 OpenStack 服务配置为外部 Ceph 集群的客户端（在共置的情况下，Ceph 集群在逻辑上仍然是外部的）
为 RBD 和 CephFS 的 OpenStack 客户端（Nova、Cinder、Glance、Manila）提供 Ceph 配置文件和 cephx 密钥
完全支持多客户端，例如，一个 OpenStack 部署可以使用多个 Ceph 集群，例如多后端 Glance
快速配置客户端，例如，在一个地方生成密钥并有效地复制它
这是一个独立的角色，可用于配置 OpenStack 以连接到由外部管理的 Ceph 集群
不破坏现有的 CephExternalMultiConfig 支持，该支持用于在 DCN 环境（在 DCN 站点上部署仪表板不在本次提案的范围内）中配置 OpenStack 以使用多个 Ceph 集群。

替代方案¶

未来版本的 cephadm 可能会添加客户端配置支持，但即使今天可用，也有一些原因说明我们无法按原样使用此功能

它假定 cephadm 工具已配置为具有外部 Ceph 集群的管理员权限，而当我们不管理 Ceph 时，我们没有此权限；
它还假定每个客户端节点都已配置到外部 Ceph orchestrator 目录中，以便每个 Ceph MON 都可以通过 SSH 登录到客户端节点（overcloud 节点）；
虽然它提供了复制配置文件和 cephx 密钥环到远程客户端节点的必要功能，但它无法配置例如 Nova 的 libvirtd secret 用于 qemu-kvm，这仅在客户端是 OpenStack 时才相关的任务；

安全影响¶

没有直接源自创建新 Ansible 角色的决定。但是，密钥环本身的分配应使用 TripleO 服务实现，例如现有的 CephClient 服务，以便密钥环仅部署到实际需要它们的节点。

升级影响¶

目标是保留并重用当前用于驱动 ceph-ansible 的任何现有 Heat 参数；从操作员的角度来看，配置 Ceph 客户端的问题没有改变，不应该需要更改现有的参数，只是实现方式会改变。

性能影响¶

如 Proposed Change 部分所述，此角色的目的是正确配置客户端，并允许 OpenStack 服务连接到内部或外部 Ceph 集群，以及 DCN 环境中的多个 Ceph 集群。由于许多 OpenStack 服务（Nova、Cinder、Glance、Manila）都需要配置文件和密钥才能与 Ceph 集群正确交互，因此至少应执行两个操作

在一个地方生成密钥
有效地复制生成的密钥

ceph_client 角色应该非常小，并且在性能方面可以首先通过在中心位置创建密钥来改进。然后，生成的密钥只需要分发到 Ceph 集群的节点以及 Ceph 集群配置文件。将此角色添加到 tripleo-ansible 可以避免从纯部署的角度来看添加额外的调用；事实上，不会触发额外的 Ansible playbook，并且我们预计性能会得到改善，因为这里没有涉及额外的层。

开发人员影响¶

Ceph 的部署方式可能会改变任何维护 TripleO 代码以供使用 Ceph 的 OpenStack 服务的人员。理论上，不应该有任何变化，因为 CephClient 服务仍然会在相同的位置配置 Ceph 配置和 Ceph 密钥文件。这些开发人员只需要在模板稳定时切换到新的模板。

实现¶

新角色应由 TripleO 服务启用，就像 CephClient 服务今天一样。根据部署时选择的环境文件，此类服务的实际实现可以基于 ceph-ansible 或新角色。

当 Ceph 集群不是外部的，该角色还会创建池和 cephx 密钥环到 Ceph 集群中；这些步骤将在 Ceph 是外部时跳过，正是因为我们没有更改集群配置的管理员权限。

TripleO Heat 模板¶

依赖 ceph-ansible 的现有实现将保留在树中至少一个弃用周期。通过重用现有的 Heat 输入参数，我们应该能够仅通过切换部署时使用的环境文件，以透明的方式使用 ceph-ansible 或新角色来完成客户端配置。当前使用 environments/ceph-ansible/ceph-ansible-external.yaml 的 TripleO 用户，以便他们的 Overcloud 使用现有的 Ceph 集群，应该能够将相同的模板应用于新的模板来配置 Ceph 客户端，例如 environments/ceph-client.yaml。这将导致新的 tripleo-ansible/roles/ceph_client 角色被执行。

负责人¶

fmount
fultonj
gfidente
jmolmo

工作项¶

建议的时间表¶

OpenStack W: 将 tripleo-ansible/roles/ceph_client 作为实验性启动，然后在 001/004 场景中将其设置为默认值。我们预计它将在 W 周期内变得稳定。

依赖项¶

ceph_client 角色将添加到 tripleo-ansible 中，并允许配置 OpenStack 服务作为外部或 TripleO 管理的 Ceph 集群的客户端；tripleo-ansible 项目没有添加新的依赖项。ceph_client 角色将与 External Ceph、由 ceph-ansible 部署的 Internal Ceph 以及 [4] 中描述的 Ceph 部署一起工作。

测试¶

应该能够重新配置现有的已经使用 Ceph 部署的 CI 场景之一，以使用新的 ceph_client 角色，使其在代码稳定之前不进行投票。然后将另一个现有的 CI 场景切换到它。

文档影响¶

不需要文档更改。

TripleO Ceph 客户端