cellv2官方文档
https://docs.openstack.org/nova/latest/user/cells.html
现在,当请求命中特定实例的Nova API时,将从数据库中获取实例信息,该数据库包含实例当前所在的计算节点的主机名。
如果请求需要对实例(大多数是其中)执行操作,则使用主机名来作为消息队列的名称,并在其中写入一条消息,该消息将会找到正确计算节点。
这个提议的内容是将上面的主机名查找改为两部分,它们产生三条信息而不是一条。 基本上,我们还将获取数据库和队列连接信息,而不仅仅是查找实例所在的计算节点的名称。
因此,当被要求对实例采取行动时,我们将:
1、查找该实例相关的三个信息(数据库,队列,主机名)
2、连接到该数据库并获取实例记录信息
3、连接到队列并将消息发送到正确的主机名队列
以上与现有组织结构有两种不同。 首先,在知道实例所在的位置之前,我们需要进行两次数据库查找。 其次,我们需要连接到相应的数据库和队列。
这两者都有性能影响,但我们相信我们可以通过使用memcache缓存实例映射信息以及连接到多个数据库和队列系统的来缓解影响。 单元格数量总是远小于实例数量。
这种变化会对可用性产生影响,因为如果某个cell中存在数据库故障,如查询多个单元格的“nova list”命令可能会导致只得到部分的结果。
有关在这种情况下推荐的做法的更多信息,请参阅CellsV2管理。 cell内的数据库故障会导致比列表不完整更大的问题,因此它期望问题被快速处理,并且cellsv2将通过在结果响应中提示数据可能不完整。
在资源组织方面,这与我们对当前cell的处理方式非常相似,我们决定将此称为“cellsv2”消除歧义。
从此以后后,将不再进行“无cell”部署。 Nova的默认安装将是单个cell设置。
优势:
这个的好处是:
1、数据库和队列的分片作为nova中的第一类特征。 所有代码路径都将通过查找过程,因此我们将不会像使用当前使用的cell那样具有相同的功能奇偶校验问题。
2、顶部没有所有cell数据库的高级复制。 对于像实例索引这样的东西,API需要一个自己的数据库,但它不需要复制顶层cell的所有数据。
3、它在全局和本地数据元素之间划清界限。 像flavors和keypairs这样的东西显然是全局性的概念,只需要在顶层cell里面保存。 提供这种隔离允许计算节点变得更加无状态,还能隔离掉全局数据如删除/改变的操作。
4、现有的non-cells用户将立即获得从现有部署中生成新“cell”而无需更改其构架。 只需将有关新数据库和队列系统的信息添加到新索引,就可以使用这些资源。
5、现有cells用户需要填写cells映射索引,关闭现有cell同步服务,最终清理其顶级数据库。 但是,由于高级cell没有实质性的不同,他们不必重新构建他们的构架以转移到cellsv2。
6、在允许被调度之前,把新的主机集定义为新的“cell”,部署并测试。
数据库分离:
如上所述,全局数据和本地cell数据之间存在区别。
全局与本地的数据,对于一个cell的细分。 由于对更难以清洁放置的数据达成共识,将填写缺失的数据。 丢失的数据主要与调度和网络有关。
Global (API-level) Tables
instance_types instance_type_projects instance_type_extra_specs quotas project_user_quotas quota_classes quota_usages security_groups
security_group_rules security_group_default_rules provider_fw_rules key_pairs migrations networks tags
Cell-level Tables
instances instance_info_caches instance_extra instance_metadata instance_system_metadata instance_faults instance_actions
instance_actions_events instance_id_mappings pci_devices block_device_mapping virtual_interfaces
Setup of Cells V2
随着更多CellsV2实现的完成,所有运营商都需要对其部署进行更改。 对于所有部署(甚至那些只打算拥有一个单元的部署),这些更改都与配置相关,包括主nova配置文件以及数据库中的一些额外记录。
现在,所有nova部署都必须具有以下可用和配置的数据库:
1、The “API” database —nova_api
2、One special “cell” database called “cell0” —nova_cell0
3、One (or eventually more) “cell” databases —nova_cell1
因此,一个小的nova部署将有一个API数据库,一个cell0,一个我们称之为“cell1”的数据库。
高级跟踪信息保存在API数据库中。
从未计划过的实例将被降级到cell0数据库,这实际上是无法启动的实例的坟墓。
所有成功/运行的实例都存储在“cell1”中。
注意:
由于Nova服务使用配置文件和某些数据库记录,因此启动或重新启动配置不完整的服务可能会导致部署不正确。 完成上述步骤后,请重新启动服务。