openstack 官方文档阅读之cells（一）

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服务使用配置文件和某些数据库记录，因此启动或重新启动配置不完整的服务可能会导致部署不正确。 完成上述步骤后，请重新启动服务。