Nova Cells¶

概述¶

Nova cells V2 是一个特性，它允许 Nova 部署扩展到比以往更大的规模。这是通过将计算节点分片成称为cells（单元）的池来实现的，每个单元都有一个单独的消息队列和数据库。

关于 cells 的更多信息可以在 Nova 文档中找到这里和这里。本文档假定读者熟悉 cells 的概念。

Cells：部署视角¶

从部署的角度来看，nova cell 支持涉及将 Nova 服务分成两组 - 全局服务和每个 cell 的服务。

全局服务

nova-api
nova-scheduler
nova-super-conductor (在多 cell 模式下)

每个 cell 的控制服务

nova-compute-ironic (用于 Ironic cells)
nova-conductor
nova-novncproxy
nova-serialproxy
nova-spicehtml5proxy

每个 cell 的计算服务

nova-compute
nova-libvirt
nova-ssh

另一个考虑因素是 cells 依赖的数据库和消息队列集群。稍后会讨论这一点。

服务放置¶

有多种方法可以在多 cell 环境中放置服务。

单 cell 拓扑¶

单 cell 拓扑默认使用，并且限制为单个 cell

        +----------------+
        |                ++
        |                |-+
        |   controllers  |-|
        |                |-|
        |                |-|
        +------------------|
         +-----------------|
          +----------------+

+--------------+     +--------------+
|              |     |              |
|   cell 1     |     |   cell 1     |
|   compute 1  |     |   compute 2  |
|              |     |              |
+--------------+     +--------------+

所有控制服务都在控制器上运行，并且没有 superconductor。

专用 cell 控制器拓扑¶

在这种拓扑中，每个 cell 都有一个专用的控制器组来运行 cell 控制服务。下图显示了具有两个 cell 的云的拓扑结构

                                +----------------+
                                |                ++
                                |                |-+
                                |   controllers  |-|
                                |                |-|
                                |                |-|
                                +------------------|
                                 +-----------------|
                                  +----------------+

                   +----------------+        +----------------+
                   |                ++       |                ++
                   |   cell 1       |-+      |   cell 2       |-+
                   |   controllers  |-|      |   controllers  |-|
                   |                |-|      |                |-|
                   +------------------|      +------------------|
                    +-----------------|       +-----------------|
                     +----------------+        +----------------+

+--------------+     +--------------+        +--------------+     +--------------+
|              |     |              |        |              |     |              |
|   cell 1     |     |   cell 1     |        |   cell 2     |     |   cell 2     |
|   compute 1  |     |   compute 2  |        |   compute 1  |     |   compute 2  |
|              |     |              |        |              |     |              |
+--------------+     +--------------+        +--------------+     +--------------+

共享 cell 控制器拓扑¶

注意

Kolla Ansible 尚未支持这种拓扑结构。

另一种配置是将多个 cell 的 cell 控制服务放置在单个共享的 cell 控制器组上。如果单个 cell 的控制服务不能完全消耗一组 cell 控制器的资源，这可能允许更有效地利用硬件

                                +----------------+
                                |                ++
                                |                |-+
                                |   controllers  |-|
                                |                |-|
                                |                |-|
                                +------------------|
                                 +-----------------|
                                  +----------------+

                                +----------------+
                                |                ++
                                |   shared cell  |-+
                                |   controllers  |-|
                                |                |-|
                                +------------------|
                                 +-----------------|
                                  +----------------+

+--------------+     +--------------+        +--------------+     +--------------+
|              |     |              |        |              |     |              |
|   cell 1     |     |   cell 1     |        |   cell 2     |     |   cell 2     |
|   compute 1  |     |   compute 2  |        |   compute 1  |     |   compute 2  |
|              |     |              |        |              |     |              |
+--------------+     +--------------+        +--------------+     +--------------+

数据库 & 消息队列¶

全局服务需要访问 API 和 cell0 数据库的数据库，以及消息队列。每个 cell 需要自己的数据库和消息队列实例。这些可以是单独的数据库和消息队列集群，也可以是共享的数据库和消息队列集群，通过数据库名称和虚拟主机进行分区。目前 Kolla Ansible 支持部署共享数据库集群和消息队列集群。

配置¶

参见

配置 Kolla Ansible 以部署多个 cells 通常需要使用 inventory 主机和组变量。

启用多 cell 支持¶

默认情况下禁用对部署多个 cell 的支持 - nova 以单 conductor 模式部署。

可以通过在 globals.yml 中将 enable_cells 设置为 yes 来启用多个 cell 的部署。这以 superconductor 模式部署 nova，为每个 cell 提供单独的 conductor。

命名 cells¶

默认情况下，所有 cell 服务都部署在单个未命名的 cell 中。这种行为与 Kolla Ansible 的先前版本兼容。

要将主机部署到不同的 cell，请为 cell 中的主机设置 nova_cell_name 变量。这可以使用主机变量或组变量来完成。

组织¶

在单 cell 部署中，以下 Ansible 组用于确定服务的位置

compute: nova-compute, nova-libvirt, nova-ssh
nova-compute-ironic: nova-compute-ironic
nova-conductor: nova-conductor
nova-novncproxy: nova-novncproxy
nova-serialproxy: nova-serialproxy
nova-spicehtml5proxy: nova-spicehtml5proxy

在多 cell 部署中，这仍然是必要的 - 计算主机必须位于 compute 组中。但是，为了进一步控制 cell 服务的位置，使用了以下变量

nova_cell_compute_group
nova_cell_compute_ironic_group
nova_cell_conductor_group
nova_cell_novncproxy_group
nova_cell_serialproxy_group
nova_cell_spicehtml5proxy_group

为了保持向后兼容性，默认情况下会设置这些变量。对于多 cell 部署，应将其设置为仅包含该 cell 中计算主机的组的名称。

示例¶

在以下示例中，我们有两个 cell，cell1 和 cell2。每个 cell 都有两个计算节点和一个 cell 控制器。

清单

[compute:children]
compute-cell1
compute-cell2

[nova-conductor:children]
cell-control-cell1
cell-control-cell2

[nova-novncproxy:children]
cell-control-cell1
cell-control-cell2

[nova-spicehtml5proxy:children]
cell-control-cell1
cell-control-cell2

[nova-serialproxy:children]
cell-control-cell1
cell-control-cell2

[cell1:children]
compute-cell1
cell-control-cell1

[cell2:children]
compute-cell2
cell-control-cell2

[compute-cell1]
compute01
compute02

[compute-cell2]
compute03
compute04

[cell-control-cell1]
cell-control01

[cell-control-cell2]
cell-control02

Cell1 组变量 (group_vars/cell1)

nova_cell_name: cell1
nova_cell_compute_group: compute-cell1
nova_cell_conductor_group: cell-control-cell1
nova_cell_novncproxy_group: cell-control-cell1
nova_cell_serialproxy_group: cell-control-cell1
nova_cell_spicehtml5proxy_group: cell-control-cell1

Cell2 组变量 (group_vars/cell2)

nova_cell_name: cell2
nova_cell_compute_group: compute-cell2
nova_cell_conductor_group: cell-control-cell2
nova_cell_novncproxy_group: cell-control-cell2
nova_cell_serialproxy_group: cell-control-cell2
nova_cell_spicehtml5proxy_group: cell-control-cell2

请注意，这些示例 cell 组变量指定了所有控制台代理服务的组以供完整性。您需要确保没有端口冲突。例如，如果在 cell1 和 cell2 中，您都使用默认的 novncproxy 控制台代理，您可以将 nova_novncproxy_port: 6082 添加到 cell2 组变量以防止与 cell1 发生冲突。

数据库¶

每个 cell 的数据库连接通过以下变量配置

nova_cell_database_name
nova_cell_database_user
nova_cell_database_password
nova_cell_database_address
nova_cell_database_port

默认情况下，Kolla Ansible 部署的 MariaDB 集群用于此目的。对于未命名的 cell，为了保持向后兼容性，使用 nova 数据库。

消息队列¶

每个 cell 的 RPC 消息队列通过以下变量配置

nova_cell_rpc_user
nova_cell_rpc_password
nova_cell_rpc_port
nova_cell_rpc_group_name
nova_cell_rpc_transport
nova_cell_rpc_vhost

对于通知

nova_cell_notify_user
nova_cell_notify_password
nova_cell_notify_port
nova_cell_notify_group_name
nova_cell_notify_transport
nova_cell_notify_vhost

默认情况下，Kolla Ansible 部署的消息队列集群用于此目的。对于未命名的 cell，所有 OpenStack 服务使用的虚拟主机 / 用于保持向后兼容性。对于命名的 cell，使用名为 nova_<cell name> 的虚拟主机。

Conductor & API 数据库¶

默认情况下，cell conductors 配置为访问 API 数据库。目前这是必要的，因为 Nova 中的某些操作需要 *upcall*。

如果不需要这些操作，可以通过将 nova_cell_conductor_has_api_database 设置为 no 来防止 cell conductors 访问 API 数据库。

控制台代理¶

有关配置 Nova 中控制台访问的常规信息，请参见这里。对于具有多个 cell 的部署，每个 cell 的控制台代理必须可通过唯一的端点访问。我们通过为每个 cell 的控制台代理添加一个 HAProxy 前端来实现这一点。每个前端必须使用不同的端口。可以通过以下变量配置端口

nova_novncproxy_port
nova_spicehtml5proxy_port
nova_serialproxy_port

Ironic¶

目前，所有基于 Ironic 的实例都部署在单个 cell 中。该 cell 的名称通过 nova_cell_ironic_cell_name 配置，默认情况下为未命名的 cell。nova_cell_compute_ironic_group 可用于设置部署 nova-compute-ironic 服务的组。

部署¶

在多 cell 环境中的部署与在单 cell 环境中的部署没有不同 - 使用 kolla-ansible deploy 命令。

扩展¶

在大型环境中，将新的计算资源添加到现有部署是一个常见的操作任务。在多 cell 环境中，这些资源很可能全部添加到新的或现有的 cell 中。理想情况下，我们不希望在部署这些新资源时影响其他 cell，甚至控制器主机。

Kolla Ansible 中的 Nova cells 支持构建方式使得可以添加新的 cell 或扩展现有 cell 而不影响云的其余部分。这是通过 kolla-ansible 的 --limit 参数来实现的。例如，如果我们正在将一个新 cell cell03 添加到现有的云，并且该 cell 的所有主机（控制和计算）都位于 cell03 组中，我们可以将其用作限制

kolla-ansible deploy --limit cell03

在添加新 cell 时，我们还需要确保为该 cell 中的控制台代理配置 HAProxy。

kolla-ansible deploy --tags haproxy

这种方法的另一个好处是，它应该更快地完成，因为 Ansible 管理的主机数量减少了。

升级¶

与部署类似，可以使用 kolla-ansible upgrade 以相同的方式在多 cell 环境中执行升级。

分阶段升级¶

注意

当 nova_safety_upgrade 为 yes 时，分阶段升级不适用。

在大型环境中，升级整个站点所涉及的风险可能很大，并且一次升级一个 cell 的能力至关重要。这是一个非常高级的过程，尝试此操作的运营商应熟悉 Nova 升级文档。

在这里，我们使用 Ansible 标签和限制来控制升级过程。我们仅考虑 Nova 升级。假设所有依赖服务都已升级（请参见 ansible/site.yml 以获取正确的顺序）。

第一步，可以在升级之前执行，是执行数据库模式迁移。

kolla-ansible upgrade --tags nova-bootstrap

接下来，我们升级全局服务。

kolla-ansible upgrade --tags nova-api-upgrade

现在可以升级 cell 服务。这可以分批进行，一次升级一个或多个 cell，使用 --limit。例如，要升级 cell03 中的服务

kolla-ansible upgrade --tags nova-cell-upgrade --limit cell03

在此阶段，我们可能希望对新服务进行测试，以检查它们是否正常工作，然后再继续到其他 cell。

一旦所有 cell 都已升级，我们可以重新加载服务以删除 RPC 版本固定，并执行在线数据迁移。

kolla-ansible upgrade --tags nova-reload,nova-online-data-migrations

Nova 升级现在完成，可以继续升级其他服务。

Nova Cells

Nova Cells¶

概述¶

Cells：部署视角¶

服务放置¶

单 cell 拓扑¶

专用 cell 控制器拓扑¶

共享 cell 控制器拓扑¶

数据库 & 消息队列¶

配置¶

启用多 cell 支持¶

命名 cells¶

组织¶

示例¶

数据库¶

消息队列¶

Conductor & API 数据库¶

控制台代理¶

Ironic¶

部署¶

扩展¶

升级¶

分阶段升级¶

kolla-ansible 21.0.1.dev2

页面内容