单元主机映射¶

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

由于调度器将返回主机而不是单元，我们需要知道该主机位于哪个单元中。将创建一个新表，用于存储此映射关系。

问题描述¶

当 Nova 被划分为单元时，计算 API 需要知道与哪个单元通信，以便构建已调度的实例，或进行主机 API 请求。目前没有主机到单元的映射，因此仅凭主机无法知道如何将信息传递到该主机。

用例¶

运营商希望将他们的部署划分为单元，以实现扩展、故障域和构建原因。在划分后，我们需要一个查找表来知道主机位于哪个分区中。

项目优先级¶

Liberty 的优先级尚未确定。

提议的变更¶

拟议的更改是在 ‘nova_api’ 数据库中添加一个新表，用于存储主机到单元的映射关系，以及一个用于与其交互的对象。将数据迁移到此表将由单独的规格文档处理。

以下图表可能有助于可视化它。

                                 api/cell boundary
    scheduler returns a host             |
                |                        |
                v                        |
           nova-api+--------------------------->cell-db/rpc
                +                        |
                +----+                   |
                     |                   |
                     v                   |
host_mapping (joined with) cell_mapping  |

备选方案¶

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

数据模型影响¶

将在 ‘nova_api’ 数据库中添加一个新的 ‘host_mapping’ 表。

表结构如下所示：

CREATE TABLE `host_mapping` (
  `created_at` datetime DEFAULT NULL,
  `updated_at` datetime DEFAULT NULL,
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `host` varchar(255) NOT NULL,
  `cell_uuid` varchar(36) NOT NULL)

主机将是一个索引列。其他索引也是可能的，可以在代码审查中讨论。

应该注意的是，这里没有 ‘deleted’ 或 ‘deleted_at’ 列。如果主机存在，则应该映射它，只有当主机被永久删除时，才不需要保留它在这里。

REST API 影响¶

无

安全影响¶

无

通知影响¶

无

其他最终用户影响¶

无

性能影响¶

仅此更改本身不会引入性能影响。当它被后续规格文档使用时，它会在 Nova 中的某些操作中引入另一个数据库查找。

其他部署者影响¶

这将在 ‘nova_api’ 数据库中引入一个新表。如上文 “数据模型影响” 部分所述，在清理主机时应考虑它。如果从部署中删除主机，也可以从 host_mapping 表中删除它们。

开发人员影响¶

无

实现¶

负责人¶

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

工作项¶

添加 ‘host_mapping’ 表的数据库迁移。

添加 HostMapping 对象。

依赖项¶

无

测试¶

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

文档影响¶

应该添加关于新表及其用途的文档。

参考资料¶

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

Cells 主机映射