Nova Cell

Nova Cell V2 详解 

如今 ，OpenStack 在控制平面上的性能瓶颈主要在 Message Queue 和 Database 。 尤为是 Message Queue , 随着计算节点的增长 ， 性能变的愈来愈差 。 为了应对这种状况 ， Nova 很早以前提出来 nova-cell ( 如下以 cellv1 代替 ) 的解决方案 。 目的是在把大的 OpenStack 集群分红小的单元 ， 每一个单元有本身的 Message Queue 和 Database。 以此来解决规模增长时引发的性能问题 。 并且不会向 Region 那样 ， 把各个集群独立运行 。 在 cell 里面 ，Keystone、Neutron、Cinder、Glance 等资源仍是共享的 。

cell v1
cellv1 最初的想法很好 ， 可是局限于早期 nova 的架构 ， 硬生生的加个 nova-cell 服务来在各个 cell 间传递消息 ， 使得架构更加复杂 。 如下是 cellv1 的架构：


cell v1 的问题在于 ：
 一、一直以来 ，cell v1 被标记为实验性质
 二、相关的测试不多 ， 并且也没有 v1 + neutron 的测试
 三、如今来讲功能已经冻结 ， 不会加入新的功能
 四、不严重的 Bug 根本不会去修复
 五、使用案例不多 。 如今常常提到的使用案例也只有 CERN（ 欧洲原子能研究中心 ）。 通常规模下 ， 彻底没有必要搭建 cell v1
因此 ， 如今进行部署的话 ， 若是用 cell, 就尽可能使用 cell v2 吧 。

cell v2
cell v2 自 Newton 版本引入 ，Ocata 版本变为必要组件 。 之后默认部署都会初始化一个单 cell 的架构 。
cell v2 的架构图以下 ， 看着比 cell v1 清爽很多 。


从架构图上 ， 能够看到 ：
一、api 和 cell 有了明显的边界 。 api 层面只须要数据库 ， 不须要 Message Queue。
二、nova-api 如今依赖 nova_api 和 nova_cell0 两个数据库 。
三、nova-scheduler 服务只须要在 api 层面上安装 ，cell 不须要参数调度 。 这样实现了一次调度就能够肯定到具体在哪一个 cell 的哪台机器上启动
四、这里其实依赖 placement 服务 , 之后的文章会提到
五、cell 里面只须要安装 nova-compute 和 nova-conductor 服务 ， 和其依赖的 DB 和 MQ
六、全部的 cell 变成一个扁平架构 。 比以前的多层父子架构要简化不少 。
七、api 上面服务会直接链接 cell 的 MQ 和 DB, 因此不须要相似 nova-cell 这样子的额外服务存在 。 性能上也会有及大的提高

nova_api & nova_cell0
自 Newton 版本 ，nova 就一直拆分 nova 数据库 ， 为 cell v2 作准备 。 把一些全局数据表从 nova 库搬到了 nova_api, 下面是如今 nova_api 里面的全部表 。


能够看到像 flavor, instance groups, quota 这些表已经迁移了过来 。
nova_cell0 数据库的 schema 和 nova 是同样的 ， 他存在的只要用途是 ： 当 instance 调度失败时 ， instance 的信息不属于任何一个 cell, 因此放到 cell0 上面 。 所以里面的数据并非过重要 。

Cell Related Tables
Cell 相关的数据库表都在 nova_api 里面 ， 包括 cell_mappings, host_mappings, instance_mappings。 其表结构以下 ：


一、cell_mappings 表 cell 的 Database 和 Mesage Queue 的链接 。 用于和子 cell 通信
二、host_mappings 是用于 nova-scheduler, 能够确认分配到的机器 。 这里其实也有一个坑 ， 以前 nova-compute 启动起来 ， 就能够直接使用了 ，cell v2 以后 ， 就须要手动运行 nova-manage cell_v2 discover_host , 把 host mapping 到 cell_mappings 表里面 ， 那台计算节点才会加入到调度中 。
三、instance_mappings 表里有全部 instance id, 这样在查询 instance 时 ， 就能够从这个表里查到他所在的 cell, 而后直连 cell 拿到 instance 具体信息 。

cell 流程


当想要获取一个机器的详细信息时 :
1.nova-api 先从 instance_mappings 表拿到 instance 的 cell_id
2.再从 cell_mappings 表拿到所在 cell 的 DB connection
3.直接链接 cell 的 DB 拿到机器的详细信息



当要重启一台机器时 ：
1.nova-api 先从 instance_mappings 表里拿到 instance 所在的 cell_id
2.从 cell_mappings 里拿到所在 cell 的 message queue 链接
3.nova-api 直接给 mq 的相关队列发重启机器的消息


当新建机器时 :
1.nova-api 接到用户的请求信息 ， 先转发到 nova-scheduler 进行调度 ， nova-scheduler 经过 placement service, 直接肯定分配到哪台机器上
2.nova-api 把 instance 的信息存入 instance_mappings 表
3.nova-api 把机器信息存到目标 cell 的 database
4.nova-api 给 cell 的 message queue 的相关队列发消息 ， 启动机器


Cell v2 的优势
•数据库和消息队列做为 nova 的一等公民 。
•在 cell 的数据库里没有冗余数据 ， 全部共享数据都在 nova-api 中
•全局数据和 cell 数据有一条清晰的界线
•非 cell 用户很容易的就能够迁移到 cell v2 上面 。 不须要更改如今的部署架构
•cell v1 的用户也能够迁移到 cell v2 上 。 只要手动创建起全部的 mapping, 关掉如今存在的 nova-cell 服务 ， 清掉最上层 cell 的数据库 。 可是最上层 cell 本质上和其它 cell 是不一样的 。 因此须要调整架构
•增减 cell 变的十分简单 ， 并且在把某个 cell 加入以前 ， 能够在其它环境进行测试

Cell v2 相关命令
由于 cell v2 彻底靠 database 的操做为创建 ， 因此也没有相关的 api 接口 。 主要靠 nova-manage cell_v2 命令 。 详细说明参见REF
nova-manage cell_v2
 
    create_cell
    delete_cell
    list_cells
 
    map_cell0
    discover_hosts
    simple_cell_setup
 
    map_cell_and_hosts
    map_instances
    verify_instance


其它 
计算节点自动发现
上面提到了如今 nova-compute 服务上线后 ， 不会自动加到 nova-api 的 host_mappings 里面 ， 也就不会加到 nova-scheduler 的调度中 。 须要手动运行 nova-manage cell_v2 discover_hosts 命令 。 这显示略显繁琐 。
在小型一些的环境上 ， 推荐打开自动发现功能 ， 就不用手动跑命令了 。


性能分析
为了拿到 instance 的详细信息 ， 须要查询 nova_api 数据库 ， 相比以前要多查询一次数据库 ( 虽然是有三个表 ， 可是能够用多表链接查询 ， 一次就能够拿到全部的结果 )。 可是一来数据至关少 ， 并且很容易加上一层 cache, 并不会对性形成什么影响 。

Kolla 实现 
如今 Kolla 已经支持自动部署一个基本的 cell 环境 ， 并且支持从没有 cell 的 Newton 升级到有 cell 的 Ocata 版本 。