1、概述
OpenStack 在控制平面上的性能瓶颈主要在 Message Queue 和 Database 。 尤其是 Message Queue , 随着计算节点的增加 ， 性能变的越来越差 。 为了应对这种情况 ， Nova 很早之前提出来 nova-cell的解决方案 。起初是cell v1版本，由于架构负杂，自 Newton 版本引入cell v2。Cell V2出现之前所有的 Nova Compute节点全部连接到同一个 MQ，在有大量定时任务通过 MQ 上报给 Nova Conductor服务的情况下，消息队列非常容易出现性能瓶颈，从而限制了整个集群的规模。
2、架构
（1）nova-api 依赖 nova_api 和 nova_cell0 两个数据库 ；
（2）nova-scheduler 服务只需要在 api 层面上安装 ，cell 不需要参数调度 。 这样实现了一次调度就可以确定到具体在哪个 cell 的哪台机器上启动；
（3）cell 里面只需要安装 nova-compute 和 nova-conductor 服务 ， 和其依赖的 DB 和 MQ；
（4）api 上面服务会直接连接 cell 的 MQ 和 DB。
在每个 Cell 中，都有自己独立使用的数据库、消息队列和 Nova Conductor 服务，当前 Cell 中的所有计算节点，全部将数据发送到当前 Cell 中的消息队列，由 Nova Conductor 服务获取后，保存至当前 Cell 的 Nova 数据库中。整个过程都不会涉及到 API Cell 中的消息队列。因此通过对计算节点进行 Cell 划分，可以有效降低 API Cell 中消息队列和数据库的压力。
3、数据表
多 Cell 的实现涉及 nova_api 数据库中的3个表，分别是 cell_mappings, host_mappings, instance_mappings 表。
（1）cell_mappings 表 cell 的 Database 和 Mesage Queue 的连接 。 用于和子 cell 通讯；
（2）host_mappings 是用于 nova-scheduler, 可以确认分配到的机器 。 这里其实也有一个坑 ， 之前 nova-compute 启动起来 ， 就可以直接使用了 ，cell v2 之后 ， 就需要手动运行 nova-manage cell_v2 discover_host , 把 host mapping 到 cell_mappings 表里面 ， 那台计算节点才会加入到调度中 ；
（3）instance_mappings 表里有所有 instance id, 这样在查询 instance 时 ， 就可以从这个表里查到他所在的 cell, 然后直连 cell 拿到 instance 具体信息 。
当获取虚拟机详情时：
（1）nova-api 先从 instance_mappings 表拿到 instance 的 cell_id
（2）再从 cell_mappings 表拿到所在 cell 的 DB connection
（3）直接连接 cell 的 DB 拿到机器的详细信息
参考文章
https://cloud.tencent.com/developer/article/1473057
http://blog.chinaunix.net/uid-7374279-id-5826197.html
