Nova Cells V2如何帮助OpenStack集群突破性能瓶颈？

以下文章由UnitedStack有云Nova PTL刘家军在2016年5月29日的“奔跑吧，OpenStack！——UnitedStack与您面对面·深圳站·奥斯汀分享专场”上的演讲整理而成。

在OpenStack大家庭中，Nova算得上是最“古老”的项目了。根据OpenStack社区旨在展现不同子项目成熟度的Navigator项目显示，Nova是OpenStack庞大项目集中最成熟的子项目。在其总分为8分的成熟度评分中获得了8分满分，用户部署率高达93%。

在诞生至今的6年时间里，Nova这一OpenStack计算组件持续成熟和丰富，同时针对变化的部署需求不断寻求新的突破。在这其中，Nova Cells功能正是Nova项目在OpenStack集群扩展性方面需求技术突破的一个重要功能。正处在研发阶段的Nova Cells V2是近期Nova最受瞩目的一个新功能。

为什么引入Nova Cells？

在讨论Nova Cells V2功能的意义时，我们首先要了解为什么要引入Cells，是什么原因或者什么问题需要增加这样的新服务。事实上，引入Cells功能最核心要解决的问题就是OpenStack集群的扩展性。

对于云端架构来说，它默认拥有非常大的资源池，而这些资源池需要很多的服务器加以支持。OpenStack在架构设计时，就已经充分考虑到了服务的可扩展性。不过，在实际的使用中，用户经常会遇到问题，主要的问题包括两个方面，这就是数据库和消息队列的瓶颈问题。而Cells正是Nova内部为了解决数据库、消息队列瓶颈问题而设计的一种计算节点划分部署方案。

如果你仔细研究OpenStack的架构，你会发现OpenStack通过不同的项目对不同的资源接口进行抽象和封装。而在这些资源之间，是通过消息队列来进行通信的，同时也会有跨项目的通信。事实上，每一个项目都会有数据库的访问，以及消息队列的使用。而数据库和消息队列正在成为整个OpenStack扩展的瓶颈。尤其是消息队列，伴随着集群规模的扩展，其性能下降是非常明显的。通常情况下，当集群规模扩展到200个节点，一个消息可能要在十几秒后才会响应，集群的整体性能大大下降。

为了解决上面的问题，Nova引入了Cells的机制（如下图所示）。

▲ Nova Cells V2架构设计

Nova Cells V1为什么没有普及？

Nova Cells V1版本在Nova的早期版本中就已经实现，只是由于各种设计造成的问题，导致很少被人使用。我们先来看看Nova Cells V1的架构。

▲ Nova Cells V1架构

在Nova Cells V1架构中，将不同的计算资源划分为一个个的Cell，在每个Cell中有独立的调度、连接服务，不同的Cell之间可以构成树状的结构，逐步向下扩展，可以轻松实现规模的扩展。每一个Cell中，会有独立的数据库服务、独立的消息队列，不同的Cell之间，通过Nova的Cell服务进行消息的传递。具体的实现方法是，创建虚拟机的请求首先到达API Cell，然后通过调度决定虚拟机应该创建在哪个Cell中。接下来把这个请求通过Nova Cells服务传递给Cell中的Nova调度服务，该服务收到请求后，根据资源统计的信息决定将该请求分发到Cell中的哪一个Host上。

Nova Cells V1实际上拥有一个非常知名的实际部署案例，就是CERN（欧洲原子能研究中心）。CERN的整个OpenStack集群拥有5000台以上的物理服务器，这样规模的基础设施是无法通过单Region方式进行部署的。CERN采用的方法是在顶层设计一个API Cell，然后将物理服务器以200台为一组的规模划分成20几个Cell，每一个Cell做一个AZ（可用域），在每个Cell中部署虚拟机。

Nova Cells V1版本在实际部署的过程中面临着许多问题和限制。由于Nova的网络模块在设计时并没有Host Aggregate的概念，其安全组具有一定的局限，对AZ的支持也很有限，同时Cell内部的调度功能也是很局限的。在V1版本中，调度被分为两层，一层是Cell之间的调度，另外一层是在Cell内部的调度。在Cell内部，调度的支持策略和过滤条件都是相对局限的。

除了功能上的一些问题，Nova Cells V1更为严重的短板体现在它的开发和部署方面。在Nova项目中，Nova Cells V1是一个可选组件，其成熟度较低，部署率也很低。可以说，之前用户对于这个功能的了解和关注程度都是比较低的，而参与开发这一功能的开发者也很少。

虽然社区在很早就引入了Nova Cells的功能，但是经过了多个版本的迭代，它仍然没有得到很好的采用。好在近期社区开始积极解决Nova Cells架构设计方面的问题，并且对其功能进行了重新的规划和设计，较好地吸取了之前的教训，加快向Nova Cells V2版本演进。

Nova Cells V2的构想与规划

在Nova Cells V2架构中（其架构如下图所示）。我们看到在新的架构中，Nova调度放置在API Cell中，并且多出了Cell0模块。如果你在进行虚拟机调度操作时，调度到任何一个Cell都出错，或者没有可用Cell的话，这是系统会先将请求放置在Cell0中，Cell0中只有一个Nova DB。

▲ Nova Cells V2架构

Nova Cells V2更大的变化体现在调度方面。V2版本采用了单层调度服务模式，通过一层调度就可以决定具体的Cell，以及Cell里面的Host。在每一个Cell中，包含自己的消息队列，Nova-Conductor需要与数据库进行交互。而每个Cell内，不需要有单独的调度。

Nova Cells V2的架构设计吸取了V1版本在实现上的教训。它将Nova DB分离，把全局信息放置在API Cell中，同时把虚拟机的一些信息保存在单独的Cell中，尽量地减少全局数据。

Nova Cells V2在未来将会采用统一的部署模式。在Newton版本之后，Nova Cells将不再是一个可选项，而是一个默认选项。也就是说，用户在部署OpenStack集群时，一定要部署Nova Cells服务。这是一个非常重大的变化，对于OpenStack集群的架构设计、云服务的高可用设计等方面都将产生深远的影响。

成为默认选项后，Nova Cells在开发和部署方面的用户参与度将大大提升，而伴随着越来越多的开发者和用户参与Nova Cells功能的开发和测试，这个功能将会更加快速地走向稳定和成熟。不过，需要说明的是，Nova Cells V2版本仍在处在紧密的开发阶段，仍然面临一些不确定的因素，例如对网络的支持（不支持Nova-network），对Host Aggregate特性的支持，密钥对、Server Group的支持等。在未来，Nova Cells V2仍然面临一些变数，OpenStack社区正在进行很多优化和改进工作，希望我们能够尽快看到更具革命性的Nova Cells功能。

演讲者简介：

刘家军，UnitedStack有云创始工程师、Nova组PTL，从2012年开始接触OpenStack项目，深度关注和研究的项目包括Nova、Neutron、Ironic等，同时拥有Puppet运维经验。目前主要专注于Nova研发方向，同时参与OpenStack集群架构设计的相关工作。