Cells V2¶

Nova cells v2 已经在 Ocata 和 Pike 周期中引入。事实上，现在所有的 Pike 部署都使用 nova cells v2，通常使用单个计算单元。

问题描述¶

Nova cells v2 允许一组计算节点拥有自己的专用数据库、消息队列和调度器，同时仍然通过中央 API 服务进行管理。这具有以下好处

降低大型部署中 Rabbit 和 MySQL 的压力¶

即使是中等规模的云，数据库和消息代理也可能很快成为瓶颈。Cells 可以用来缓解这种压力，为每组计算节点提供一个数据库和消息队列。值得注意的是，charms 已经支持将 neutron 等的流量放在单独的 rabbit 实例中。

创建多个故障域¶

将计算单元与其本地服务分组，可以创建离散的故障域（至少从 nova 的角度来看）。

远程计算单元（边缘计算）¶

在某些部署中，一组计算节点可能远离（从网络角度来看）中央服务。在这种情况下，让计算节点充当一个大部分独立的组可能是有用的。

每个单元不同的 SLA¶

不同的计算节点组可以具有不同的性能水平、HA 等。一个单元可能没有本地 HA 用于数据库、消息队列和调度器，用于开发单元，但生产单元可以具有运行集群服务的更高规格服务器。

(这些用例是根据 *4 释义的。)

提议的变更¶

为了方便 cells v2 部署，需要添加一些相对简单的接口和关系。从 nova 的角度来看，拓扑结构如下所示。本规范建议将其映射到这个 charm 拓扑。

Superconductor 访问子单元¶

Superconductor 需要能够查询计算单元的数据库，并在计算单元的消息总线上发送和接收消息。最干净的方法是在 superconductor 和计算单元的数据库和消息总线之间建立直接的 Juju 关系。为了方便这一点，nova-cloud-controller charm 将添加以下关系

requires:
  shared-db-cell:
    interface: mysql-shared
  amqp-cell:
    interface: rabbitmq

Superconductor 配置子单元¶

有了上述更改，superconductor 可以访问子数据库和消息队列，但不知道与它们关联的计算单元名称。为了解决这个问题，nova-cloud-controller charm 将具有以下新的关系

provides:
  nova-cell-api:
    interface: cell
requires:
  nova-cell:
    interface: cell

新的 cell 关系将用于传递单元名称、数据库服务名称和消息队列服务名称。

{
  'amqp-service': 'rabbitmq-server-cell1',
  'db-service': 'mysql-cell1',
  'cell-name': 'cell1',
}

有了这些信息，superconductor 可以检查附加到其 shared-db-cell 和 amqp-cell 关系的的服务名称，并为它们构建 URL。然后，superconductor 能够通过运行以下命令在 api 数据库中创建单元映射

nova-manage cell_v2 create_cell \
    --name <cell_name> \
    --transport-url <transport_url> \
    --database_connection <database_connection>

在单元可以映射之前，superconductor 需要有五个关系到位，并且它们各自的上下文需要完成。鉴于 nova-cloud-controller 是一个非反应式 charm，需要特别注意确保单元映射无论这些关系完成的顺序如何都能发生。

计算调度器不再向 keystone 注册¶

计算调度器不需要向 keystone 注册端点，也不需要服务凭证。因此，identity-service 关系不应用于计算单元。应该在 nova-cloud-controller charm 中放置一个保护，以防止计算单元的 nova-cloud-controller 在 keystone 中注册不正确的端点。

计算调度器单元名称配置选项¶

计算调度器需要知道自己的单元名称，以便它可以将此信息传递给 superconductor。为了允许这一点，nova-compute charm 将添加一个新的配置选项

options:
  cell-name:
    type: string
    default:
    description: |
      Name of the compute cell this controller is associated with. If this is
      left unset or set to api then it is assumed that this controller will
      be the top level api and cell0 controller.

不设置单元名称假定当前行为，即将 nova-cloud-controller 与 api 服务、cell0 和 cell1 关联。

nova-compute 服务凭证¶

nova-compute charm 需要服务凭证来进行到 Nova Placement API 和 Neutron API 服务的 RPC 调用。它目前通过其 cloud-compute 关系获得这些凭证，这充其量是丑陋的。但是，鉴于计算单元的 nova-cloud-controller 将不再与 keystone 具有关系，它将没有可以传递给 nova-compute 的任何凭证。通过将 cloud-credentials 关系添加到 nova-compute charm 来克服这一点。

requires:
  cloud-credentials:
    interface: keystone-credentials

nova-compute 将请求基于其服务名称的用户名，以便可以区分不同单元的用户。

定制 vhost 和数据库名称¶

nova-cloud-controller charm 应该删除指定 nova 数据库名称和 rabbitmq vhost 名称的能力，或者新的 cell 接口需要支持将这些信息传递给 superconductor，以便 superconductor 可以从计算节点的数据库和消息队列请求访问正确的资源。

禁用未使用的服务¶

计算单元的 nova-cloud-controller 只需要运行调度器服务和可能的控制台服务。应该通过 charm 禁用未使用的服务。

新的单元调度器 charm？¶

计算节点中的 nova cloud controller 仅运行一小部分 nova 服务，并且不需要内置到当前 nova-cloud-controller charm 中的许多复杂性。这引出了一个问题，即是否运行调度器的新的简化反应式 charm 会更有意义。实际上，上述大部分更改都影响 superconductor 而不是计算调度器。但是，从另一个角度来看，允许 nova-cloud-controller charm 作为子调度器运行所需的更改实际上非常小，因此可能不值得创建新的 charm。值得注意的是一些历史背景，每次决定创建可以以多种模式运行的 charm 的决定，都会在稍后的日期以某种成本被推翻（ceph 是一个很好的例子）。

考虑到所有这些，将不会编写新的 charm，并且现有的 nova-cloud-controller charm 将扩展以添加对作为计算调度器运行的支持。

消息队列¶

关于非 nova 服务使用哪个消息队列的灵活性。可以为它们创建一个专用的 rabbit 实例，或者它们可以重用 api 服务使用的 rabbit 实例。

遥测等¶

本规范不涉及与遥测的集成。但是，这需要进一步调查，以确保可以收集消息数据。

Juju 服务名称¶

将单元名称嵌入到每个单元特定组件的服务名称中将是有用的，但不是必需的。例如，部署 cellN 的服务可能如下所示

juju deploy nova-compute nova-compute-cellN
juju deploy nova-cloud-controller nova-cloud-controller-cellN
juju deploy mysql mysql-cellN
juju deploy rabbitmq-server rabbitmq-server-cellN

备选方案¶

什么都不做，不支持额外的 nova v2 单元。
复活对已弃用且存在错误的 cells v1 的支持

实现¶

负责人¶

主要负责人: 未知

Gerrit Topic¶

对于与此规范相关的所有补丁，请使用 Gerrit 主题“<topic_name>”。

git-review -t cellsv2

现有工作¶

在编写规范时，为了参考创建了原型 charms 和一个 bundle：Bundle 和 charm 差异

工作项¶

从 nova-compute 和 nova-cloud-controller charms 中删除对 cells v1 的支持
将 identity-context 关系添加到 nova-compute，并确保提供的凭证在 nova.conf 中渲染 placement 和 keystone 部分时使用。
将 shared-db-cell 关系添加到 nova-cloud-controller，假设在请求访问时使用“nova”数据库名称。
将 amqp-cell 关系添加到 nova-cloud-controller，假设在请求访问时使用“openstack”vhost 名称。
为 nova-cloud-controller 添加代码以注册单元。这将使用 shared-db-cell 和 amqp-cell 关系的 AMQ 和 SharedDB 上下文来创建单元映射。
更新 nova-cloud-controller 中的 nova.conf 模板，仅在 nova-cloud-controller 是 superconductor 时才渲染 api db url。
更新数据库初始化代码，仅在不是 superconductor 时才运行相关的单元迁移。
添加 nova-cell 和 nova-cell-api 关系，并确保 shared-db、amqp shared-db-cell、amqp-cell 和 nova-api-cell 关系都尝试注册计算单元。
编写使用 cells 拓扑的 bundle
检查与其他服务的集成（特别是 designate 和遥测）

仓库¶

不需要新的存储库。

文档¶

nova-cloud-controller 和 nova-compute 的 README 需要更新，以解释新的关系和配置选项。
带有部署演练和说明的博客。
更新 Openstack Charm 文档，以解释如何进行多单元部署
将 bundle 添加到 charm store。

安全性¶

我没有意识到任何新的安全风险

测试¶

多单元拓扑可能超出了 amulet 测试的范围
将 bundle 添加到 openstack-charm-testing
Mojo 规范

依赖项¶

我想到的没有

鸣谢¶

cells 等的许多好处都来自 *4

*1 https://docs.openstack.org/nova/pike/cli/nova-manage.html *2 https://docs.openstack.org/nova/latest/user/cellsv2-layout.html *3 https://bugs.launchpad.net/nova/+bug/1742421 *4 https://openstack.org/videos/sydney-2017/adding-cellsv2-to-your-existing-nova-deployment

Cells V2