Cells 实例映射¶
https://blueprints.launchpad.net/nova/+spec/cells-instance-mapping
为了使计算 API 节点能够与正确的 cell 通信以获取实例信息,需要建立实例到 cell 的映射。将创建一个新的表来存储此映射。
问题描述¶
当 Nova 被划分为 cells 时,计算 API 需要知道与特定实例通信的 cell 是哪个。目前尚不存在实例与其所在 cell 的映射。
用例¶
运维人员希望将部署划分为 cells,以实现扩展、故障域和构建原因。在划分后,我们需要一个查找表来知道实例位于哪个分区。
项目优先级¶
Cells v2 已成为 Kilo 版本的项目优先级。
提议的变更¶
提出的变更是在 ‘nova_api’ 数据库中添加一个新表,用于存储实例到 cell 的映射。将更新与此表交互的数据库 API 和对象,以使用它。将数据迁移到此表将在单独的规格文档中处理。
以下图表可能有助于可视化它。
api/cell boundary
nova show <uuid> |
| |
v |
nova-api+-------------------->cell-db
+ + |
| +----+ |
| | |
v v |
instance_mapping cell_mapping |
备选方案¶
我们可以继续使用今天使用的 nova-cells 模型。
数据模型影响¶
将在 ‘nova_api’ 数据库中添加一个新的 ‘instance_mapping’ 表。
表结构如下所示:
CREATE TABLE `instance_mapping` (
`created_at` datetime DEFAULT NULL,
`updated_at` datetime DEFAULT NULL,
`id` int(11) NOT NULL AUTO_INCREMENT,
`instance_uuid` varchar(36) NOT NULL,
`cell_uuid` varchar(36) NOT NULL,
`project_id` varchar(255) NOT NULL)
instance_uuid 将是一个索引列。其他索引也很可能存在,可以在代码审查中讨论。
需要注意的是,这里没有 ‘deleted’ 或 ‘deleted_at’ 列。即使实例被删除,此映射仍然有效,因此不需要删除映射。例如,删除的实例列表仍然需要知道这些实例位于哪个 cell 中。
REST API 影响¶
无
安全影响¶
无
通知影响¶
无
其他最终用户影响¶
无
性能影响¶
仅此变更本身不会引入性能影响。当它被后续规格文档使用时,它会在 Nova 中的许多操作中引入另一个数据库查找。例如,‘nova show <uuid>’ 需要 Nova 在查询实例数据之前查找实例所在的数据库。以后可以使用 memcached 缓存此映射来优化它。
其他部署者影响¶
这在 ‘nova_api’ 数据库中引入了一个新表。如上文“数据模型影响”部分所述,在对 instances 表执行任何清理操作时,应考虑这一点。如果从 instances 表中删除实例,也可以从 instance_mapping 表中删除它们。
开发人员影响¶
开发人员应该开始意识到部署中的所有实例可能不在同一个数据库中。但此时不需要进行任何开发更改。
实现¶
负责人¶
- 主要负责人
alaski
- 其他贡献者
无
工作项¶
添加 ‘instance_mapping’ 表的数据库迁移。
依赖项¶
https://blueprints.launchpad.net/nova/+spec/cells-v2-mapping
测试¶
由于这被设计为 Nova 的内部重构,没有用户可见的更改,因此当前的 Tempest 或功能测试应该足够。在某个时候,我们希望研究如何测试多个 Cell 或潜在地在 API 中公开 Cell 的概念,然后我们将解决测试要求。
文档影响¶
应该添加关于新表及其用途的文档。
参考资料¶
https://etherpad.openstack.org/p/kilo-nova-cells https://review.openstack.org/#/c/139191/