2016-06-16 10:10:22
来 源
中存储
Openstack
Nova是OpenStack庞大项目集中最成熟的子项目。在其总分为8分的成熟度评分中获得了8分满分,用户部署率高达93%。

以下文章由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集群架构设计的相关工作。

声明: 此文观点不代表本站立场;转载须要保留原文链接;版权疑问请联系我们。