目录
- 一、NOVA简介
- 二、作用
- 三、系统架构
- 四、组件介绍
- 4.1 API--通信接口
- 4.2 Scheduler--调度器
- 4.2.1 过滤器(filter)
- 4.2.2 计算权值(weight)
- 4.3 Compute--计算器
- 4.3.1 支持方式
- 4.3.2 功能
- 4.4 Conductor--管理器
- 4.5 PlacementAPI--安置接口
- 五、Nova 的 Cell 架构
- 5.1 产生原因
- 5.2 架构图
一、NOVA简介
- 计算服务是openstack最核心的服务之一,负责维护和管理云环境的计算资源,它在openstack项目中代号是nova。
- Nova自身并没有提供任何虚拟化能力,它提供计算服务,使用不同的虚拟化驱动来与底层支持的Hypervisor(虚拟机管理器)进行交互。所有的计算实例(虚拟服务器)由Nova进行生命周期的调度管理(启动、挂起、停止、删除等)
- Nova需要keystone、glance、neutron.cinder和swift等其他服务的支持,能与这些服务集成,实现如加密磁盘、裸金属计算实例等。
二、作用
- Nova是OpenStack最核心的服务模块,负责管理和维护云计算环境的计算资源,负责整个云环境虚拟机生命周期的管理。
- Nova是OpenStack的计算服务,负责维护和管理的网络和存储,提供计算服务。
三、系统架构
- DB:用于数据存储的sql数据库。
- API:用于接收HTTP请求、转换命令、通过消息队列或HTTP与其他组件通信的nova组件。
- Scheduler:用于决定哪台计算节点承载计算实例的nova调度器。
- Network:管理IP转发、网桥或虚拟局域网的nova网络组件。
- Compute:管理虚拟机管理器与虚拟机之间通信的nova计算组件。
- Conductor:处理需要协调(构建虚拟机或调整虚拟机大小)的请求,或者处理对象转换
四、组件介绍
4.1 API–通信接口
- 实现了RESTful API功能,是外部访问Nova的唯一途径,同时也是客户端与Nova之间的中间层,可以与第三方系统集成
- 接收外部的请求并通过Message Queue将请求发送给其他的服务组件,同时也兼容EC2 API,所以也可以用EC2的管理工具对nova进行日常管理。
- 作为核心组件,可集中查询所有组件的API端点
- API可以处理与虚拟机生命周期相关的操作
Nova-api对接收到的HTTP API做以下处理
- 鉴权,即检查参数是否合法有效
- 作为计算节点的核心,调用其他项目去服务通过HTTP发送的请求
- 清空Nova子服务中的相关运算,只返回结果给客户端
4.2 Scheduler–调度器
- Scheduler可译为调度器,由nova-scheduler服务实现,主要解决的是如何选择在哪个计算节点上启云实例的问题。它可以应用多种规则,如果考虑内存信用率、cpu负载率、cpu构架(intel/amd)等多种E素,根据一定的算法,确定虚拟机实例能够运行在一台计算服务器上。Nova-scheduler服务会从队列中接收一个虚拟机实例的请求,通过读取数据库的P容,从可用资源池中选择最合适的计算节点来创建亲的虚拟机实例。
- 创建虚拟机实例时,用户会提出资源需求,如cpu.内存、磁盘各需要多少。Openstack将这些需求定义在实例类型中,用户只需指定使用哪个实例类型可以了
决策虚拟机创建在哪个主机(计算节点)上。决策一个虚拟机应该调度到某物理节点,需要经过两个子组件:
4.2.1 过滤器(filter)
过滤出可以创建虚拟机的主机。
scheduler_available_filters选项用于配置可用过滤器,默认是所有nova自带的过滤器都可以用于过滤作用
Scheduler_available_filters = nova.scheduler.filtersall filters
另外还有一一个选项schedyler_default_filters用于指定nova-scheduler服务真正使用的过滤器,默认值如下
Scheduler_ delault filters = RetryFilters, AvailabiltyZoneFilter, RamFilter,
ComputeFilter, ComputeCapabilitiesFilter, ImagePropertiesFilter,
ServerGroupAntiffinityFilter, ServerGroupAffinityFilter
过滤器将从以下几个方面进行过滤
- RetryFilter(再审过滤器)
主要作用是过滤掉之前已经调度过的节点。如A. B、C都通过了过滤,A权重最大被选中执行操作,由于某种原因,操作在A上失败了。Nova-litr将重新执行过滤操作,那么此时A就被会RetryFilter直接排除,以免再次失败
- AvailabilityZoneFilter (可用区域过滤器)
为提高容灾性并提供隔离服务,可以将计算节点划分到不同的可用区域中Openstack默认有一一个命名为nova的可用区域, 所有的计算节点初始是放在nova区域中的。用户可以根据需要创建自己的-一个可用区域。创建实例时,需要指定将实例部署在哪个可用区域中。Nova scheduler执行过滤操作时,会使用AvailabilityZoneFilter不属于指定可用区域计算节 点过滤掉
- RamFilter (内存过滤器)
根据可用内存来调度虚拟机创建,将不能满足实例类型内存需求的计算节点过滤掉,但为了提高系统资源利用率,Openstack在计算节 点的可用内存时允许超过实际内存大小,超过的程度是通过nova .con配置文件中ram. allocation. ratio参数来控制的,默认值是1.5。
vi /etc/nova/nova.conf
ram_allocation_ratio=1.5
- DiskFilter (硬盘调度器)
根据磁盘空间来调度虚拟机创建,将不能满足类型磁盘需求的计算节点过滤掉。磁盘同样允许超量,超量值可修改nova .con中disk. alocation. _ratio参数控制,默认值是1.0
vi /etc/nova/nova.conf
disk_allocation_ratio=1.0
- CoreFilter(核心过滤器)
根据可用CPU核心米响度应拟忆创廷,将个能满正头例夫型VCPU需冰的计算节点过宽掉。vCPU也允许超量,超量值是通过修改nova. conf中cpu_ llocation. ratio参数控制,默认值是16.
vi /etc/nova/nova. conf
cpu_allocation_ratio=16.0
- ComputeFilter(计算过滤器)
保证只有nova-compute服务正常工作的计算节点才能被nova-scheduler调度,它是必选的过滤器。
- ComputeCapablilitiesFilter (计算能力过滤器)
根据计算节点的特性来过滤,如x86_ 64和ARM架构的不同节点,将实例分别进行过滤
- ImagePropertiesFilter(镜像属性过滤器)
根据所选镜像的属性来筛选匹配的计算节点。通过元数据来指定其属性。如希望镜像只运行在KVM的Hyperisor上,可以通过Hypervisor Type属性来指定。
- ServerGroupAntiAffinityFilter( 服务器组反亲和性过滤器)
要求尽量将实例分散部署到不同的节点上。即考虑到实例之间的服务会相互冲突,将实例泡在不同的服务器上
- ServerGroupffinityilter(服务器组亲和性过滤器)
与反亲和性过滤器相反,此过滤器尽量将实例部署到同一个计算节点上
- 计算节点的资源会通过计划任务的方式会分两次实时更新到数据库。
- 创建虚拟机的时候, Scheduler 会根据 DB 库中收集的计算节点的资源。
- 在 Scheduler 创建计算节点后,会返回一个值给 DB 库,从而在下一次创建虚拟机的时候,不会因为 DB 库中更新不及时的原因造成创建虚拟机失败
4.2.2 计算权值(weight)
根据权重大小进行分配,默认根据资源可用空间进行权重排序。
注意:
所有权重位于nova/scheduler/weights目录下。目前默认实现是RAMweighter,根据计算节点空闲的内存量计算权重值,空闲越多,权重越大,实例将被部署到当前空闲内存最多的计算节点上
OpenStack源码位置
/usr/lib/python2.7/site-packages
权重源码位置
/usr/lib/python2.7site-packages/nova/scheduler/weights
4.3 Compute–计算器
- Nova-compute在计算节点上运行,负责管理节点上的实例。通常一个主机运行一个Nova-compute服务,一个实例部署在哪个可用的主机上取决于调度算法。OpenStack对实例的操作,最后都是提交给Nova-compute来完成。
- Nova-compute可分为两类,一类是定向openstack报告计算节点的状态,另一类是实现实例生命周期的管理。
4.3.1 支持方式
通过Driver (驱动)架构支持多种Hypervisor虚拟机管理器
- 面对多种Hypervisor, nova-compute为这些Hypervisor定义统一的接口.
- Hypervisor只需要实现这些接口, 就可以Driver的形式即插即用到OpenStack系统中
4.3.2 功能
- 定期向OpenStack报告计算节点的状态
- 每隔一-段时间,nova-compute就会报告当前计算节点的资源使用情况和nova-compu
服务状态。 - nova-compute是通过Hypervisor的驱动获取这些信息的。
- 实现虚拟机实例生命周期的管理
- OpenStack对虚拟机实例最主要的操作都是通过nova-compute实现的。
创建、关闭、重启、挂起、恢复、中止、调整大小、迁移、快照 - 以实例创建为例来说明nova- compute的实现过程。
(1)为实例准备资源。
(2)创建实例的镜像文件。
(3)创建实例的XML定义文件。
(4)创建虚拟网络并启动虚拟机。
4.4 Conductor–管理器
- 由nova-conductor模块实现,旨在为数据库的访问提供一层安全保障。Nova-conductor作为nova-compute服务与数据库之间交互的中介,避免了直接访问由nova-compute服务创建对接数据库.
- Nova-compute访问数据库的全部操作都改到nova-conductor中,nova-conductor作为对数据库操作的一个代理,而且nova-conductor是部署在控制节点上的。
- Nova-conductor有助于提高数据库的访问性能,nova-compute可以创建多个线程使用远程过程调用(RPC)访问nova-conductor.
- 在一个大规模的openstack部署环境里,管理员可以通过增加nova-conductor的数量来应付日益增长的计算节点对数据库的访问量。
4.5 PlacementAPI–安置接口
- 以从前对资源的管理全部由计算节点承担,在统计资源使用情况时,只是简单的将所有计算节点的资源情况累加起来,但是系统中还存在外部资源,这些资源由外部系充提供。如ceph、 nfs等提供的存储资源等。面对多种多样的资源提供者,管理员需要统一的、简单的管理接口来统计系统中资源使用情况,这个接口就是PlacementAPl。
- PlacementAPl由nova-placement-api服务来实现, 旨在追踪记录资源提供者的目录和资源使用情况。
- 被消费的资源类型是按类进行跟踪的。如计算节点类、
共享存储池类、IP地址类等。
五、Nova 的 Cell 架构
5.1 产生原因
- 当openstack nova集群的规模变大时,数据库和消息队列服务就会出现瓶颈问题。Nova为提高水平扩展及分布式、大规模的部署能力,同时又不增加数据库和消息中间件的复杂度,引入了Cell概念。
- Cell可译为单元。为支持更大规模的部署,openstack将大的nova集群分成小的单元,每个单元都有自己的消息队列和数据库,可以解决规模增大时引起的瓶颈问题。在Cell中,Keystone. Neutron. Cinder.Glance等资源是共享的。
5.2 架构图