上篇文章咱们从概念到原理,层层递进深刻讲述了Keystone项目,而本文旨在继续介绍OpenStack核心组件之一的Nova组件项目。html
相对于Keystone项目,Nova项目是做为OpenStack这个大开源项目最先也是最成熟的项目,从这一层面上也体现出Nova项目所提供的计算服务从始至终都是OpenStack最为核心的部分,笔者在以前的文章中谈到OpenStack这一开源项目所提供和管理的三大资源就是计算、网络和管理。这一样也是云计算的核心部分。html5
从笔者我的理解和观点来看的话,对于OpenStack而言,其真正的灵魂(能够理解为OpenStack中组件的复杂程度、使用几率以及故障出现几率等方面)一是在于宏观(这里“宏观的意思是相对早期版本的OpenStack平台而言”)的Nova(计算服务),二是在于相对其余服务最为复杂的Neutron网络服务(以后的文章也会针对该组件进行详细介绍),这里不包括CEPH分布式存储,由于CEPH自己就是能够认为是一个独立的大项目,其做用不只仅是OpenStack中Swift(对象存储服务)的高效分布式集群存储的替代,还包括与其余技术的结合和支持等做用。可是不管在实验环境仍是生产环境部署OpenStack云平台基本上选择CEPH做为分布式存储服务,固然在此我的补充一下,如果要进行OpenStack实验环境部署的话,对PC所配的硬件资源要求仍是比较高的,包括CPU、内存、存储(最好是SSD),笔者所配的基础硬件资源是i79代CPU、32G内存(三级缓存达到9M)、1T的SSD M.2接口的固态盘,网络是家用百兆宽带,固然在实验环境中未必须要太高的配置,能够相对下降一些要求,不过若是要想体验感较好的话仍是高配比较好,若是是决定从事这一方向的工做人员,能够购置服务器来模拟生产环境,这对初学者并不推荐哈。算法
闲话就再也不多说了,接下来笔者将从其概念概述、主要组件、架构模式、工做原理四个方面介绍Nova项目。数据库
Nova项目,做为OpenStack核心项目,提供着十分重要的计算服务,虽然说在其发展过程当中,部分核心组件在后来独立成为其余的核心项目及服务,可是Nova自身的核心地位也是很是之高的,由于了解OpenStack基础理论的朋友都知道OpenStack做为一种IaaS(基础设施即服务)的云计算服务,其最为核心的服务资源就是计算、存储和网络,而计算服务居于首位,在OpenStack云平台部署上,则正是经过Nova项目实现其计算服务的。api
之因此前言部分从宏观角度说Nova项目对于OpenStack是最核心也的项目之一是有其具体缘由的。在早期的OpenStack版本中,项目并非一次规划好的,而Nova项目在初期就将存储和网络包含于自身,及nova-volume和nova-network模块,即后期独立出的Cinder(块存储服务)和Neutron(网络服务)。浏览器
Nova项目从最初为云供应商提供实现IaaS服务的解决方案的初衷,到现在聚焦于大规模可扩展、高可用、可弹性伸缩服务和自助服务的目标,Nova一直在被优化改进升级。在2010年OpenStack项目成立之初,Nova项目主要分为Nova-Compute、Nova-volume和Nova-network三大功能模块。在2012年9月OpenStack的Folsom版本发行时,OpenStack社区才将Nova-volume和Nova-network独立出来分别构建了Cinder和Quantum项目(后因商标缘由改名为Neutron项目)。缓存
综上而言,Nova做为核心项目,在Linux服务器上做为一组守护程序运行。固然也须要依赖其余服务从而实现功能,下面讲解原理会着重介绍。其具体的功能主要是:负责管理实例虚拟机的生命周期、网络管理、存储卷管理。Nova支持建立虚拟机、裸机服务器(经过使用ironic),而且Nova计算资源的使用限额以项目为单位进行限制。服务器
Nova同Keystone同样,有组成自身的功能模块。其是由负责不一样功能的服务进程构成,Nova对外提供的服务接口为REST API,其内部组件模块之间的通讯基于RPC(远程过程调用)消息传递机制的。网络
下面来看一下组成Nova的一些主要组件:架构
Nova API服务组件。接收并响应最终用户的计算API调用请求,当其接收到请求后,一般将请求转发给Nova的其余组件进行处理,例如Nova-scheduler。
其遵循特定的策略并初始化大部分的编排操做,例如建立实例。
Nova API服务组件。Nova-API-Metadata服务主要是用于接收来自实例的元数据请求。
Nova核心服务组件。Nova-Compute是一个经过Hypervisor API建立和终止实例的工做进程(在后面的架构中将涉及Hypervisor)。先前笔者对OpenStack节点类型介绍过程当中有所说起,当时考虑到理解程度问题,没有细说。这里作一下详细说明。
在咱们部署OpenStack的计算服务时,一般选择将Nova-Compute单独部署在支持虚拟化的物理服务器上,咱们将这个物理服务器称做为计算节点。而常见的Hypervisor API有支持KVM/QEMU虚拟化引擎的Libvirt API、适用于XenServer / XCP虚拟化引擎的XenAPI以及支持VMware虚拟化引擎的VMware API。通常状况下,OpenStack默认使用的是KVM虚拟化引擎,所以在Nova-Compute中最经常使用的仍是Libvirt API。
总之,Nova-Compute主要功能就是接收来自消息队列的请求,而后执行对应的系统命令的。例如启动KVM实例并更新其在数据库中的状态。
Nova核心服务组件。主要负责从队列中获取虚拟机实例请求,并肯定其在哪台计算节点主机上运行。其采用的是过滤计算节点算法,即根据计算节点的CPU、内存和磁盘等参数进行筛选过滤。用户也能够经过自定义编辑nova.conf文件来指定过滤算法。
Nova核心服务组件。Nova-Conductor 主要是为了使Nova-Compute服务与数据库(云数据库)之间进行交互。也就是说,有了Nova-Conductor,在实际运行中,消除了Nova-Compute服务对云数据库的直接访问,而是经过Nova-Conductor实现对数据库的访问。
此外,该组件支持水平扩展到多个节点上同时运行(Nova在水平扩展时采用的是Cell的部署方式),可是不能将之部署到运行Nova-Compute的计算节点上,不然没法实现Nova-Compute与数据库之间的隔离。
Nova核心服务组件。Nova-Cert是服务器守候进程,主要为基于X509认证的Nova Cert提供服务。
属于虚拟机控制台服务。主要是提供用于经过VNC链接访问正在运行的实例的代理。支持基于浏览器的NoVNC客户端。
属于虚拟机控制台服务。主要提供用于经过SPICE链接访问正在运行的实例的代理。支持基于浏览器的HTML5客户端。Spice是Redhat开源虚拟化桌面的主要组件之一,可以提供与物理桌面彻底相同的最终用户体验,Open-Stack官方文档默认使用的虚拟机桌面访问方式为NoVNC,若是用户须要开启SPICE协议,则须要将NoVNC关闭。
Nova以外的核心组件。组件进程间消息交换传递的中心,通常用RabbitMQ实现。
Nova以外的核心组件。存储基础架构中对象的建立时和运行时的状态,包括:
从理论上讲,OpenStack Compute能够支持SQLAlchemy支持的任何数据库。常见的数据库是用于测试和开发工做的SQLite3,MySQL,MariaDB和PostgreSQL。
舒适提示:对于初学者理解Nova组件,重点在于理解前面的6个组件。
上两小节主要介绍了Nova项目的概念做用以及组成,本小节来看一下这些组成之间的联系,即Nova的逻辑架构示意图。
该架构图表示的是OpenStack 提供的计算服务,该服务是由Nova项目的各个功能组件模块一块儿支持的。
其中大部分组件在上一小节进行了介绍,其中,nova-consoleauth也是属虚拟机控制台的服务,主要为虚拟机控制台链接提供认证受权服务的,万万不要将其与右上角的nova-console混淆,nova-console是XenAPI风格的控制台服务,对于多数VNC代理软件,该组件几乎再也不使用。
针对上图可能对其中右下角的Hypervisor有所迷惑。同上文说起的Cell同样,这里不可能三言两语将这二者解释清楚,笔者在这里主要针对其做用进行说明。
Hypervisor呢,是运行于物理服务器和操做系统之间的软件层,主要是调度客户机系统对共享的物理硬件资源的使用请求,是虚拟化的基础,也是云计算的核心基础。因此上述的Nova-Compute组件就是依赖于Hypervisor API的调用来实现实例的建立以及终止的。
而cell呢,该功能模块主要是为了解决大规模Nova计算节点部署过程当中的集群瓶颈问题,该问题涉及到传统集群架构与云计算架构之间的区别了,有兴趣的朋友能够进行资料查阅。该问题就是共享消息队列系统的性能在大规模的计算节点部署集群(上百个,500个以上)大大下降。而有了Cell模块,就基具有支持OpenStack计算节点水平扩展和大规模部署的能力,本文重点并再也不次,关于Cell的具体原理和实现的过程在这里就不作详细介绍了。
此外,经过该架构逻辑图,能够发现,在Nova经过相应的服务的时候,各个组件服务之间的通讯都是通过QUEUE实现的,通常默认是RabbitMQ。其实,经过前面的几篇文章,不难发现一些规律(我的的理解或者说是发现),在OpenStack中,大多数状况下,通讯通常默认使用的的是消息队列进行的,数据库默认为Mariadb数据库,调用接口通常基于REST风格的RESTful API进行调用。
上图仅仅是Nova项目自身的架构图,那么Nova和其余服务是怎样的架构呢?其实上篇文章在讲述Keystone工做响应流程时所举案例包含了Nova所提供的服务功能。这里很少叙述。
这里穿插一些关于Cinder和Neutron项目的结构和组件来讲明一下Nova与这二者之间的逻辑架构。
为何将这三者的逻辑架构在这里给出呢?一方面是加深对Nova的理解,理解其与其余一些项目之间的联系,例如通讯方式等等,另外一方面就是Nova的发展了,前文说过最初的OpenStack项目,Nova是包含块存储和网络的,现在将这两者独立出来,成为两个项目,分别对应OpenStack Block Service 和 OpenStack Networking服务。
若是对Cinder和Neutron组件不熟悉也不要紧,这边主要理解上图中的三根虚线的含义便可。第四小节将会经过案例来简述Nova的工做原理。
其中,最上面的一条虚线表示的是Nova-Compute与网络服务Neutron-server之间的通讯关系,Neutron-server是OpenStack网络服务提供相应的API做为访问Neutron的入口,这表示Nova须要使用Neutron提供的网络服务为虚拟机实例之间和虚拟机实例与外网之间的通讯提供服务;
下面两条虚线表示的是Nova服务与块存储服务之间的通讯方式,由cinder中volume和scheduler提供接口与之通讯,这表示Nova须要使用Cinder服务提供块存储服务做为虚拟机实例的磁盘。笔者后期持续更新对各个核心项目的文章中,将会详细介绍Cinder以及Neutron项目等其余项目的相关知识。
舒适提示:AMPQ :高级消息队列协议,能够理解为一种通讯协议。
其实上文也多多少少涉及了Nova的工做流程以及些许原理,这里经过一个案例结合图示来说述理解Nova内部的工做机制。
假设须要用户须要建立一个虚拟机的场景,这里涉及到的其余项目提供的服务就尽可能跳过了,方便理解:
经过上面的案例将Nova的组件之间的关系梳理的同时,针对其内部工做原理进行理解。
不过在实际的OpenStack系统运行过程当中,Nova计算服务是须要和其余的服务进行交互的,例如经过与认证受权服务Keystone交互从而实现身份权限的识别认证过程,并经过OpenStack的镜像服务Glance为实例提供系统镜像,而用户和云管理员则经过OpenStack的控制面板服务Horizon与Nova进行交互等等。
本文主要介绍了Nova项目的概念概述、发展历程,详细介绍了Nova中核心组件的概念以及做用,给出了Nova自身的逻辑架构图以及其与块存储服务和网络服务的逻辑架构关系,最后经过一个简单案例介绍Nova内部的工做原理和工做过程。