open stack——Nove计算服务
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了open stack——Nove计算服务，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含12570字，纯文字阅读大概需要18分钟。
内容图文
open stack——Nove
- 一、Nove计算服务
- 二、Nova系统架构
- 三、Nova组件介绍
- 四、虚拟机实例化流程
- 五、Nova部署架构
- 六、Nova的cell架构
一、Nove计算服务
- 计算服务是open stack最核心的服务之一，负责维护和管理云环境的计算资源，它在open stack项目中代号是nova。
- Nova自身并没有提供任何虚拟化能力，它提供计算服务，使用不同的虚拟化驱动来与底层支持的Hypervisor（虚拟机管理器）进行交互。所有的计算实例（虚拟服务器）由Nove进行生命周期的调度管理（启动、挂起、停止、删除等）
- Nova需要keystone、glance、neutron、cinder和swift等其他服务的支持，能与这些服务集成，实现如加密磁盘、裸金属计算实例等。
二、Nova系统架构
- Nova由多个服务器进程组成，每个进程执行不同的功能。
- DB:用于数据存储的sql数据库
- API：用于接收HTTP请求、转换命令、通过消息队列或HTTP与其他组件通信的nova组件。
- Scheduler：用于决定那台计算节点承载计算实例的nova调度器。
- Network：管理IP转发、网桥或虚拟局域网的nova网络组件。
- Compute：管理虚拟机管理器与虚拟机之间的通信的nova组件。
- Conductor：处理需要协调（构建虚拟机或调整虚拟机大小的）请求，或者处理对象转换。
三、Nova组件介绍
1.API
- API是客户访问nova的http接口，它由nova-api服务实现，nova-api服务接收和响应来自最终用户的计算api请求。作为openstack对外服务的最主要接口，nova-api提供了一个集中的可以查询所有api的端点。
- 所有对nova的请求都首先由nova-api处理。API提供REST标准调用服务，便于与第三方系统集成。
- 最终用户不会直接发送RESTful API请求，而是通过open stack命令行、dashbord和其他需要跟nova交换的组件来使用这些API。
- 只要跟虚拟机生命周期相关的操作，nova-api都可以响应。
- Nova-api对接收到的HTTP API请求做以下处理：
1.检查客户端传入的参数是否合法有效
2.调用nova其他服务来处理客户端HTTP请求
3.格式化nova其他子服务返回结果并返回给客户端
- Nova-api是外部访问并使用nova提供的各种服务的唯一途径，也是客户端和nova之间的中间层。
2.Scheduler
- Scheduler可译为调度器，由nova-scheduler服务实现，主要解决的是如何选择在哪个计算节点上启动实例的问题。它可以应用多种规则，如果考虑内存使用率、cpu负载率、cpu架构（inte/amd）等多种因素，根据一定的算法，确定虚拟机实例能够运行在哪一台计算服务器上。nova-scheduler服务会从队列中接收一个虚拟机实例的请求，通过读取数据库内容，从可用资源池中选择最合适的计算节点来创建新的虚拟机实例。
- 创建虚拟机实例时，用户会提出资源需求，如cpu、内存、磁盘各需要多少。open stack将这些需求定义在类型类型中，用户只需指定使用哪种实例类型就可以了。
调度器的类型
- 随机调度器(chance scheduler)：从所有正常运行nova-compute服务的节点中随机选择。
- 过滤器调度器(dfilter scheduler)：根据指定的过滤条件以及权重选择最佳的计算节点。filter又称为筛选器。
- 缓存调度器(caching scheduler)：可以看作随即调度器的一种特殊类型，在随即调度的基础上将主机资源信息缓存在本地内存中，然后通过后台的定时任务定时从数据库中获取最新的主机资源信息。
过滤器调度器调度过程
- 主要分为两个阶段
1.通过指定的过滤器选择满足条件的计算节点，比如内存的使用率小于50%，可以使用多个过滤器依次进行过滤。
2.对过滤之后的主机列表进行权重计算的排序，选择最优的计算节点来创建虚拟机实例。
预选：选择出符合条件的并进行打分
优选：以分数*权重的方式得出最后的总分排序，最后择优选择
调度器与DB数据库
- scheduler组件决定的是虚拟机实例部署在哪台计算节点上并调度，在调度之前，会先向数据库获取宿主机资源信息作为依据；
- 之后可通过过滤器和权重选择最合适的节点调度，或者指定节点直接调度；
- 计算节点的 libvirt 工具负责收集宿主机的虚拟化资源，根据已创建的实例再次统计资源，将资源信息更新到数据库中，整个更新资源信息的过程是周期性执行的，而不是实时的；
- 所以存在一个问题，当刚创建完一个实例，随即又需要创建时，数据库还未来得及更新宿主机的最新状态，那么调度器依据的信息就不正确，有可能所选的节点资源并不够用，而导致调度失败。
- 这同时也是缓存调度器的缺陷，无法实时获取租主机资源信息。我们可在调度完成时，直接将资源信息返回给数据库，更新数据库状态，解决这个问题。
过滤器
- 当过滤器需要执行调度操作时，会让过滤器对计算节点进行判断，返回True或Flase。
- scheduler_available_filters选项用于配置可用过滤器，默认是所有Nova自带过滤器都可以用于过滤作用
Scheduler_avaliable_filters = nova.scheduler.filters.all_filters
- 另外还有一个选项scheduler_default_filters用于指定nova-scheduler服务真的使用过滤器，默认值如下
Scheduler_default_filters = RetryFilters,AvailabilityZoneFilter,RamFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter, ServerGroupAffinityFilter
RetryFilter（再审过滤器）
- 主要作用是过滤之前已经调度过的节点。如A、B、C都通过了过滤，A权重最大被选中执行该操作，由于某种原因，操作在A上失败了。Nove-filter将重新执行过滤操作，那么此时A就被会Retry-Filter直接排除，以免再失败。
AvailabilityZoneFilter（可用区过滤器）
- 为了提提高容灾性并提供隔离服务，可以将计算节点划分到不同的可用区域中。Openstack默认有一个命名为nove的可用区域，所有的计算节点初始是放在nove区域中的。用户可以根据需要创建自己的一个可用的区域。创建实例时，需要指定将实例部署在哪个可用区域中。Nove-scheduler执行过滤操作时，会使用AvailabilityZoneFilter不属于指定可用区域计算节点过滤。
RamFilter（内存过滤器）
- 根据可用内存来调度虚拟机创建，将不能满足实例类型内存需求的计算节点过滤掉，但为了提高系统资源利用率，Openstack在计算节点的可用内存时允许超过实际内存大小，超过的程度是通过nova.con配置文件中ram_allocation参数来控制的，默认值是1.5。
vi /etc/nova/nova.conf
Ram allocation ratio=1.5
DisFilter（硬盘调度器）
- 根据磁盘空间来调度虚拟机创建，将不能满足类型磁盘需求的计算节点过滤掉。磁盘同样允许超量，超量值可修改nova.conf中disk_allication_ratio参数控制，默认值是1.0
vi /etc/nova/nova.conf
disk_allocation_ratio=1.0
CoreFilter（核心过滤器）
- 根据可用CPU核心来调度虚拟机创建，将不能满足实例类型vCPU需求的计算节点过滤掉。vCPU也允许超量，超量值是通过修改nova.conf中cpu_ allocation_ratio参数控制，默认值是16。
Vi /etc/nova/nova. conf
cpu_allocation_ ratio=16.0
ComputeFilter(计算过滤器)
- 保证只有Nova-compute服务正常工作的计算节点才能被nova-scheduler调度，它是必选的过滤器。
ComputeCapablilitiesFilter（计算能力过滤器）
- 根据计算节点的特性来过滤，如x86_64和ARM架构的不同节点，要将实例
ImagePropertiesFilter（镜像属性过滤器）
- 根据所选镜像的属性来筛选匹配的计算节点。通过元数据来指定其属性。如希望镜像只运行在KVM的Hypervisor上，可以通过Hypervisor Type属性来指定。
过滤调度器将按照列表中的顺序依次过滤
- ServerGroupAntiAffinityFilter(服务器组反亲和性过滤器)要求尽量将实例分散部署到不同的节点上。例如有3个实例s1、s2、s3，3个计算节点A、B、C，具体操作如下：
创建一个anti-affinit策略的服务器组
openstack server group create-policy anti-affinity group-1
权重
- 在对计算节点进行过滤时，多个过滤器依次进行过滤，而不是并行，相当于一个个预选，避免重复对同一个节点进行所有过滤项检验。过滤之后的节点再通过计算权重进行排序。
- 所有权重位于nova/scheduler/weights 目录下，目前默认是RAMweighter，根据计算节点空闲的内存计算权重，内存空闲越多权重越大，计算节点按照内存空闲进行排序。
scheduler组件小结
- 定位：决定实例具体创建在哪个计算节点
- 调度流程：
有多个调度器、过滤器共同合作，一次过滤，首先筛选出符合要求的节点，接着以权重（一般是基于内存空闲）的方式，对节点打分排序，最终决定出一个节点。 - 子功能：
粗过滤（基础资源），例如CPU、内存、磁盘
精细化过滤，例如镜像属性，服务性能契合度
高级过滤，亲和性/反亲和性过滤 - 过滤之后，可以进行随机调度，会进行再筛选，即污点机制，对剩下的节点过滤，排除掉之前有故障的节点。
3.compute计算组件
Nova-compute在计算节点上运行，负责管理节点上的实例。通常一个主机运行一 个Nova-compute服务, 一个实例部署在哪个可用的主机上取决于调度算法。OpenStack对实例的操作最后都是提交给Nova-compute来完成。
Nova-compute可分为两类，一类是定向openstack报告计算节点的状态，另一类是实现实例生命周期的管理。
- 定期向OpenStack报告计算节点的状态
每隔一段时间，nova-compute就会报告当前计算节点的资源使用情况和nova-compute服务状态。nova-compute是通过Hypervisor的驱动获取这些信息的。 - 实现虚拟机实例生命周期的管理
OpenStack对虚拟机实例最主要的操作都是通过nova-compute实现的。包括创建、关闭、重启、挂起、恢复、中止、调整大小迁移、快照。
以实例创建为例来说明nova-compute的实现过程。
(1)为实例准备资源。
(2)创建实例的镜像文件。
(3)创建实例的XML定义文件。
(4)创建虚拟网络并启动虚拟机。
4.conductor协调组件
- 为数据库的访问提供一层安全保障。Nova-conductor作为nova-compute服务与数据库之间交互的中介，避免了compute直接访问，由nova-compute服务对接数据库，compute组件位于第三方上，与架构外部进行交互。这样就可避免一些越权操作，并且为数据库分压。
- Nova-compute访问数据库的全部操作都改到nova-conductor中，nova-conductor作为对数据库操作的一个代理，而且nova-conductor是部署在控制节点上的。
- Nova-conductor有助于提高数据库的访问性能，nova-compute可以创建多个线程使用远程过程调用(RPC)访问nova-conductor。
- 在一个大规模的openstack部署环境里，管理员可以通过增加nova-conductor的数量来应对日益增长的计算节点对数据库的访问量。
5.Placement API
- 以前对资源的管理全部由计算节点承担，在统计资源使用情况时，只是简单的将所有计算节点的资源情况累加起来，但是系统中还存在外部资源，这些资源由外部系统提供。如ceph、nfs等提供的存储资源等。
面对多种多样的资源提供者，管理员需要统一的、简单的管理接口来统计系统中资源使用情况，这个接口就是Placement API。 - PlacementAPI由nova-placement-api服务来实现， 旨在追踪记录资源提供者的目录和资源使用情况。被消费的资源类型是按类进行跟踪的。 如计算节点类、共享存储池类、IP地址类等。
四、虚拟机实例化流程
1.用户访问控制台
可以通过多种方式访问虚拟机的控制台
- Nova-novncproxy守护进程: 通过vnc连接访问正在运行的实例提供一个代理，支持浏览器novnc客户端。（最常用的）
- Nova-spicehtml5proxy守护进程: 通过spice连接访问正在运行的实例提供一个代理，支持基于html5浏览器的客户端。
- Nova-xvpvncproxy守护进程: 通过vnc连接访问正在运行的实例提供一个代理，支持openstack专用的java客户端。
- Nova-consoleauth守护进程: 负责对访问虚拟机控制台提供用户令牌认证。这个服务必须与控制台代理程序共同使用，即上面三种代理方式。
2.如果无法通过控制台/URL连接到内部实例：
产生原因
1、实验场景中，虚拟机资源不足
2、实验场景中，镜像问题（公共镜像，作为测试用的镜像）
3、生产环境中，路由配置问题，路由网关配置到了其他实例地址，内部有多个实例项目。
解决方法
- 首先用户（openstack最终用户或其他程序）执行nova client提供的用于创建虚拟机的命令。
- nova-api服务监听到来自客户端的http请求，会将请求转换为AMQP消息之后上传到消息队列。
- 通过消息队列调用conductor服务
- conductor服务从消息队列中接收到虚拟机的实例化请求后，进行准备工作
- conductor通过消息队列告诉scheduler服务去选择一个合适的计算节点创建虚拟机，此时scheduler会读取数据库的内容
- conductor服务从nova-schedule服务得到了计算节点的信息后，通过消息队列通知compute服务实现虚拟机的创建。
五、Nova部署架构
1.经典架构部署
2.负载均衡架构部署
1.资源压力大，集群服务器压力（数据库）
2.运维管理人员，管理的复杂性提高，故障排除的复杂程度提高（不方便管理）
六、Nova的cell架构
1.使用此架构的原因
- 为了解决openstack nova集群的规模变大时,数据库和消息队列服务就会出现瓶颈问题。Nova为提高水平扩展及分布式、大规模的部署能力，同时又不想增加数据库和消息中间件的复杂度，从而引入了Cell概念。
- 核心理念：
1.提高数据库瓶颈、缓解数据库压力
2.提高消息队列瓶颈、缓解消息队列压力
3.减轻了conductor的压力
2.cell的概念
- Cell可译为单元。为支持更大规模的部署,openstack将大的nova集群分成小的单元，每个单元都有自己的消息队列和数据库，可以解决规模增大时引起的瓶颈问题。在Cell中，Keystone、Neutron、 Cinder、Glance等资源是共享的。
3.cell架构的数据库
- nova-api数据库：存放全局信息，这些全局数据表是从nova库迁移过来的，包括实例模型信息，实例组，配额信息。
- nova-cell0数据ku：当实例调度失败时，实例的信息不属于任何一个cell，所以存放到cell0数据库中。
单cell部署
多cell部署
多cell部署的架构，可以从分层的角度来看：
- 为了应付集群规模的扩大，对数据库、消息队列进行扩容，实现nova规模的扩展。通过划分多个小的cell单元，多个单元同时处理业务，每个cell单元都有各自的数据库和消息队列。为了管理这些小的单元，需要一个集中化管理组件 super conductor，主conductor来管理cell单元，同时完成自身的工作。
- 黄色方框：是对消息队列的划分。划分为API消息队列，和cell单元中的消息队列。API消息队列中是外部对nova的请求，以及nova内部子服务之间的通信请求，作为它们之间通信的载体。cell消息队列中是cell单元需要处理的业务请求。
- 红色方框：是对conductor的划分，super-conductor用于集中管理cell单元，同时负责通知 nova-scheduler 调度计算节点，调度失败直接写入cell0，成功则控制任务具体下发给哪个cell单元处理，将所有数据写入数据库。cell中的conductor，通过消息队列收到本cell需要创建实例的请求后，会通知nova-compute创建实例，进行具体的处理和协调。
- 绿色方框：是对数据库的划分。API数据库存放全局的交互数据，总的资源统计。cell0数据库存放实例创建失败的信息，cell1/2存放各自单元成功创建实例的信息，对应处理的请求数据。
- Nova-api：每个创建实例的请求都有编号，创建成功与否的结果会存储在cell数据库中，nova-api会根据编号，从cell数据库中调取到请求的最终结果，格式化后返回给用户。
内容总结
以上是互联网集市为您收集整理的open stack——Nove计算服务全部内容，希望文章能够帮你解决open stack——Nove计算服务所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。
来源：【匿名】