Cells v2 映射¶

https://blueprints.launchpad.net/nova/+spec/cells-v2-mapping

为了使计算 API 节点能够与单元格通信，它们需要了解如何连接到每个单元格。将创建一个新的数据库和表，用于存储这些信息，供 Nova 的数据库和 RPC 层使用。

问题描述¶

当 Nova 被划分为单元格时，计算 API 需要能够通过消息总线和数据库连接与每个单元格通信。目前，没有单元格标识符到消息队列和数据库连接的映射。也没有一种机制可以根据每次调用将 RPC 消息或数据库查询分派到不同的端点。

用例¶

希望对特定单元格进行数据库查询或发送 RPC 消息的开发者。

项目优先级¶

Cells v2 已成为 Kilo 项目的重点。

提议的变更¶

所提出的更改是为存储单元格到数据库和消息队列的映射而创建新的数据库和表。之所以提出新的数据库，是因为将要添加到其中的新表属于 Nova 的计算 API 层，而与属于单元格数据库的一些当前表不同。信息具体划分到哪里是一个正在进行中的工作。

新的数据库需要应用到它的单独的迁移线路。由于现在已经讨论了一段时间关于使用 alembic 处理数据库迁移的潜在好处，这可能是一个很好的机会。我认为应该研究并使用它，如果达成共识认为它有益，否则继续使用 sqlaclhemy-migrate。

Nova 需要一个连接字符串来连接到这个新的数据库，同时继续连接到当前的 ‘nova’ 数据库，直到我们可以完全迁移离开它。将引入一个新的配置选项来存储 ‘nova_api’ 数据库的连接信息。

此外，Nova 中的数据库和 RPC 抽象需要能够为每次调用/查询与任意端点通信。

目前还没有任何东西可以使用它，因此工作范围仅限于具备这样做的能力。

下图可能有助于可视化它。当收到一个关于单元格中实例的请求时，nova-api 将查询 cell_mapping 表，以获取与单元格数据库或消息队列交互所需的信息。实例到单元格的映射在另一个规范中描述。

          api/cell boundary
                |
                |
        +------------>cell-db
        |       |
    nova-api+--------->cell-mq
        +       |
        |       |
        |       |
        v       |
cell_mapping    |

备选方案¶

我们可以继续使用今天使用的 nova-cells 模型。

数据模型影响¶

将添加一个新的 ‘cell_mapping’ 表。它将添加到当前 ‘nova’ 数据库之外的新 ‘nova_api’ 数据库中。这个新的数据库将具有如下所述的部署影响

表结构如下所示：

CREATE TABLE `cell_mapping` (
  `created_at` datetime DEFAULT NULL,
  `updated_at` datetime DEFAULT NULL,
  `deleted_at` datetime DEFAULT NULL,
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `uuid` varchar(36) NOT NULL,
  `name` varchar(255) DEFAULT NULL,
  `deleted` int(11) DEFAULT NULL,
  `transport_url` mediumtext NOT NULL,
  `database_connection` mediumtext NOT NULL)

REST API 影响¶

无

安全影响¶

数据库中的 transport_url 和 database_connection 字段可能包含敏感数据。

通知影响¶

无

其他最终用户影响¶

无

性能影响¶

仅凭这项更改不会引入性能影响。当它被后续规范使用时，它会在 Nova 中的许多操作中引入另一个数据库查找。例如，‘nova show <uuid>’ 需要 Nova 在查询实例数据之前查找实例所在的数据库。这些数据将保持相对稳定，并且可以很容易地进行缓存，以帮助抵消任何性能损失。

其他部署者影响¶

这个蓝图引入了一个概念上与当前 nova 数据库不同的数据库。部署者需要考虑他们希望如何管理第二个数据库，无论它是否位于与当前 nova 数据库相同的宿主机上。它主要由 nova-api 服务使用，因此在考虑如何部署它时应考虑到这一点。

开发人员影响¶

这项更改意味着开发者应该理解 RPC 消息或数据库查询可能会命中多个端点之一。目前，这不应该影响 Nova 中的开发者工作。添加未来数据库迁移的开发者需要考虑它是在 API 级别还是单元格级别，并将其添加到适当的迁移集中。

实现¶

负责人¶

主要负责人: alaski
其他贡献者: 无

工作项¶

确保 Nova 数据库 API 可以在每次调用时与任意数据库通信。
添加用于连接到新数据库的配置选项。
研究如何在 Nova 中为新数据库建立单独的迁移路径。
为新数据库上的迁移设置单独的数据库迁移路径。
添加 ‘cell_mapping’ 表的数据库迁移。

依赖项¶

无

测试¶

由于这被设计为 Nova 的内部重构，没有用户可见的更改，因此当前的 Tempest 或功能测试应该足够。在某个时候，我们希望研究如何测试多个 Cell 或潜在地在 API 中公开 Cell 的概念，然后我们将解决测试要求。

文档影响¶

新数据库的存在和管理需要记录在案。目前不需要部署数据库，但部署者应该做好准备来开始管理它。

参考资料¶

https://etherpad.openstack.org/p/kilo-nova-cells

Cells v2 映射