nova cell v2的实现过程

40阅读 0评论2019-10-22 hiyachen
分类:云计算

为什么要引入nova cells

主要是为了降低数据库和消息队列的访问瓶颈。
      对于云端架构来说,它默认拥有非常大的资源池,而这些资源池需要很多的服务器加以支持。OpenStack在架构设计时,就已经充分考虑到了服务的可扩展性。不过,在实际的使用中,用户经常会遇到问题,主要的问题包括两个方面,这就是数据库和消息队列的瓶颈问题。而Cells正是Nova内部为了解决数据库、消息队列瓶颈问题而设计的一种计算节点划分部署方案。
如果你仔细研究OpenStack的架构,你会发现OpenStack通过不同的项目对不同的资源接口进行抽象和封装。而在这些资源之间,是通过消息队列来进行通信的,同时也会有跨项目的通信。事实上,每一个项目都会有数据库的访问,以及消息队列的使用。而数据库和消息队列正在成为整个OpenStack扩展的瓶颈。尤其是消息队列,伴随着集群规模的扩展,其性能下降是非常明显的。通常情况下,当集群规模扩展到200个节点,一个消息可能要在十几秒后才会响应,集群的整体性能大大下降。

cell v2

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

从架构图上 , 可以看到 :
1、api 和 cell 有了明显的边界 。 api 层面只需要数据库 , 不需要 Message Queue。
2、nova-api 现在依赖 nova_api 和 nova_cell0 两个数据库 。
3、nova-scheduler 服务只需要在 api 层面上安装 ,cell 不需要参数调度 。 这样实现了一次调度就可以确定到具体在哪个 cell 的哪台机器上启动
4、这里其实依赖 placement 服务 , 以后的文章会提到
5、cell 里面只需要安装 nova-compute 和 nova-conductor 服务 , 和其依赖的 DB 和 MQ
6、所有的 cell 变成一个扁平架构 。 比之前的多层父子架构要简化很多 。
7、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。 其表结构如下 :


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 具体信息 。

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 的优点

1):数据库和消息队列作为 nova 的一等公民 。
2):在 cell 的数据库里没有冗余数据 , 所有共享数据都在 nova-api 中
3):全局数据和 cell 数据有一条清晰的界线
4):非 cell 用户很容易的就可以迁移到 cell v2 上面 。 不需要更改现在的部署架构
5):cell v1 的用户也可以迁移到 cell v2 上 。 只要手动建立起所有的 mapping, 关掉现在存在的 nova-cell 服务 , 清掉最上层 cell 的数据库 。 但是最上层 cell 本质上和其它 cell 是不同的 。 所以需要调整架构
6):增减 cell 变的十分简单 , 而且在把某个 cell 加入之前 , 可以在其它环境进行测试

Cell v2 相关命令

因为 cell v2 完全靠 database 的操作为建立 , 所以也没有相关的 api 接口 。 主要靠 nova-manage cell_v2 命令 。 详细说明参见REF
usage: nova-manage cell_v2 [-h]                        {create_cell,delete_cell,delete_host,discover_hosts,list_cells,list_hosts,map_cell0,map_cell_and_hosts,map_instances,simple_cell_setup,update_cell,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 版本 。

cells创建流程,例子。
https://docs.openstack.org/developer/nova/cells.html
来源:
http://www.99cloud.net/html/2017/jiuzhouyuanchuang_0306/301.html
源自:
https://www.jianshu.com/p/653e43a02ddc

cell v2

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

image.png

从架构图上 , 可以看到 :

作者:JohnLee1100
链接:https://www.jianshu.com/p/653e43a02ddc
来源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。


上一篇:deepin的微信----龙芯中科(完全自主CPU处理器)
下一篇:openstack学习之neutron_ml2_plugin