详细讲解【openstack 】T版中nova组件的cell

一、cell的概述

1.1、 cell的定义（出现的原因）

当openstack nova 集群的规模变大时，所有的 Nova Compute节点全部连接到同一个 MQ，在有大量定时任务通过 MQ 上报给Nova-Conductor服务的情况下，数据库和消息队列服务就会出现瓶颈，而此时nova为提高水平扩展及分布式，大规模的部署能力，同时又不增加数据库和消息中间件的复杂度，引入了Cell概念。

1.2、 cell的功能

（1）Messages的路由，即父cell通过nova-cell将Messages路由到子cell的AMQP（消息队列）模块。

（2）分级调度功能，即调度某个instances的时候先要进行cell的选择，目前只支持随机调度，后续会增加基于filter和weighing策略的调度。

（3）资源统计，子cell定时的将自己的资源信息上报给父cell，用来给分级调度策略提供决策数据和基于cell的资源监控。

（4）cell之间的通信(通过rpc远程调用完成)。

二、cell简介

2.1 cell的两种模式架构图

2.2 多cell架构图

2.3 工作原理

从架构图看，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 的集群管理规模。