如下图大量数据上报给DB数据库：

如何理解cell? cell可以看做是一个单元，为支持更大规模的部署，openstack将大的nova集群分成小的单元，每个单元都有自己的消息队列和数据库，可以解决规模曾大时候引起的瓶颈问题，在cell中，keystone, neutron，cinder，glance等资源是共享的。

还有一个就是API节点上的数据库

单cell部署 架构模式：

多cell部署 架构模式：

下图整个有三部分组成，cell0， , cell1. cell2 位于最上层的cell0，也就是api-cell， 而下层的cell1与cell2则是平行对等的关系，他们之间无交互，相互独立，还可以继续增加cell3,cell4 。 而上层的api cell主要包括了
Nova API, Nova Scheduler, Nova Conductor 这3个 Nova 服务 ,同时在 API Cell 中还需要 MQ 提供组件内的通信服务。API Cell 中的 DB 包含两个数据库，分别是 api数据库 和 cell数据库，api 数据库保存了全局数据，比如 flavor 信息。此外 api 数据库中还有一部分表是用于 placement 服务的；而 cell数据库则是用于保存创建失败且还没有确定位于哪个 cell 的虚机数据，比如当虚拟机调度失败时，该虚拟机数据就会被保存到cell数据库中。也就是cell0数据库中。

在每个 Cell 中，都有自己独立使用的数据库、消息队列和 Nova Conductor 服务，当前 Cell 中的所有计算节点，全部将数据发送到当前 Cell 中的消息队列，由 Nova Conductor 服务获取后，保存至当前 Cell 的 Nova 数据库中。整个过程都不会涉及到 API Cell 中的消息队列。因此通过对计算节点进行 Cell 划分，可以有效降低 API Cell 中消息队列和数据库的压力。假如一个 MQ 能支持200个计算节点，则在划分 Cell 以后，每个 Cell 都可以支持200个计算节点，有 N 个 Cell 就可以支持 N X 200 个计算节点，因此可以极大提升单个 OpenStack 的集群管理规模。

在大致了解了 Cell V2 架构的基本组成后，接下来介绍一下在 Nova 组件中，究竟是如何实现 Cell 划分的。多 Cell 的实现涉及 nova_api 数据库中的3个表，分别是 cell_mappings, host_mappings, instance_mappings 表。这3个表之间的关系如下图所示：

cell_mappings 表记录了每个 Cell 的名字和其消息队列连接地址与数据库连接地址，通过该表中记录的信息，API Cell 中的 Nova API 服务和 Nova Conductor 服务就知道该如何连接到 Cell 中的消息队列和数据库了，并进一步将消息发送到 Cell 中的消息队列，或者直接访问 Cell 中的 Nova 数据库。

在 host_mappings 表记录了计算节点和 Cell 之间的对应关系，而instance_mappings 表则记录了 instance 和 Cell 之间的对应关系。通过这两个表的映射关系，API Cell 中的服务就可以轻易知道计算节点或者虚拟机所处的 Cell，并通过 cell_mappings 数据表中提供的链接对其进行操作。