精华内容
下载资源
问答
  • 文章目录1.Nova计算服务2.Nova系统架构3.nova组件介绍-API4.nova组件介绍-Scheduler 1.Nova计算服务 计算服务是openstack最核心的服务之一,负责维护和管理云环境的计算资源,它在openstack项目中代号是nova Nova...

    1.Nova计算服务

    • 计算服务是openstack最核心的服务之一,负责维护和管理云环境的计算资源,它在openstack项目中代号是nova
    • Nova自身并没有提供任何虚拟化能力,它提供计算服务,使用不同的虚拟化驱动来与底层支持的Hypervisor(虚拟机管理器)进行交互。所有的计算实例(虚拟服务器)由Nova进行生命周期的调度管理(启动、挂起、停止、删除等)
    • Nova需要keystone、glance、neutron、cinder和swift等其他服务的支持,能与这些服务集成,实现如加密磁盘、裸金属计算实例等

    2.Nova系统架构

    在这里插入图片描述

    • DB:用于数据存储的sql数据库
    • API:用于接收HTTP请求、转换命令、通过消息队列或HTTP与其他组件通信的nova组件
    • Scheduler:用于决定哪台计算节点承载计算实例的nova调度器
    • Network:管理IP转发、网桥或虚拟局域网的nova网络组件
    • Compute:管理虚拟机管理器与虚拟机之间通信的nova计算组件
    • Conductor:处理需要协调(构建虚拟机或调整虚拟机大小)的请求,或者处理对象转换

    3.nova组件介绍-API

    • API是客户访问nova的http接口,它由nova-api服务实现,nova-api服务接收和响应来自最终用户的计算api请求。作为openstack对外服务的最主要接口,nova-api提供了一个集中的可以查询所以api的端点

    • 所有对nova的请求首先由nova-api处理。API提供REST标准调用服务,便于与第三方系统集成

    • 最终用户不会直接该送RESTful API请求,而是通过openstack命令行、dashboard和其他需要跟nova交换的组件来使用这些API

    • 只要跟虚拟机生命周期的操作,nova-api都可以响应

    • Nova-api对接收到的HTTP API请求做以下处理:

      • (1)检查客户端传入的参数是否合法有效
      • (2)调用nova其他服务来处理客户端HTTP请求
      • (3)格式化nova其他子服务返回结果并返回给客户端
    • Nova-api是外部访问并使用nova提供的各种服务的唯一途径,也是客户端和nova之间的中间层

    4.nova组件介绍-Scheduler

    • Scheduler可译为调度器,由nova-scheduler服务实现,主要解决的是如何选择在哪个计算节点上启动实例的问题。它可以应用多种规则,如果考虑内存使用率、cpu负载率、cpu架构(Intel/amd)等多种因素,根据一定的算法,确定虚拟机实例能够运行在哪一台计算服务器上。Nova-scheduler服务会从队列中接收一个虚拟机实例的请求,通过读取数据库的内容,从可用资源池中选择最合适的计算节点来创建新的虚拟机实例。
    • 创建虚拟机实例时,用户会提出资源需求,如cpu、内存、磁盘各需要多少。Openstack将这些需求定义在实例类型中,用户只需指定使用哪个实例类型就可以了

    Nova调度器的类型

    • 随机调度器(chance scheduler):从所有正常运行nova-compute服务的节点中随机选择
    • 过滤器调度器(filter scheduler):根据指定的过滤条件以及权重选择最佳的计算节点。Filter又称为筛选器
    • 缓存调度器(caching scheduler):可看作随机调度器的一种特殊类型,在随机调度的基础上将主机资源信息缓存在本地内存中,然后通过后台的定时任务定时从数据库中获取最新的主机资源信息

    过滤器调度器过程

    主要分为连个阶段

    • 通过指定的过滤器选择满足条件的计算节点,比如内存使用小于50%,可以使用多个过滤器依次进行过滤
    • 对过滤之后的主机进行权重计算并排序,选择最优的计算节点来创建虚拟机实例

    在这里插入图片描述
    调度器与DB的交互过程

    scheduler组件决定的是虚拟机实例部署在哪台计算节点上并调度,在调度之前,会先向数据库获取宿主机资源信息作为依据;之后可通过过滤器和权重选择最合适的节点调度,或者指定节点直接调度;计算节点的 libvirt 工具负责收集宿主机的虚拟化资源,根据已创建的实例再次统计资源,将资源信息更新到数据库中,整个更新资源信息的过程是周期性执行的,而不是实时的,所以存在一个问题,当刚创建完一个实例,随即又需要创建时,数据库还未来得及更新宿主机的最新状态,那么调度器依据的信息就不正确,有可能所选的节点资源并不够用,而导致调度失败。这同时也是缓存调度器的缺陷,无法实时获取租主机资源信息。我们可在调度完成时,直接将资源信息返回给数据库,更新数据库状态,解决这个问题。
    在这里插入图片描述

    过滤器

    • 当过滤调度器需要执行调度操作时,会让过滤器计算节点进行判断,返回True或False。/etc/nova/nova.conf配置文件中

    • scheduler_available_filters选项用于配置可用过滤器,默认是所以nova自带的过滤器都可以用于过滤作用Scheduler_available_filters = nova.scheduler.filters.all_filters

    • 另外还有一个选项scheduler_default_filters用于指定nova-scheduler服务真正使用的过滤器,默认值如下

      Scheduler_default_filters = RetryFilters, AvailabilityZoneFilter, RamFilter,

      ComputerFilter, ComputeCapabilitiesFilter, ImagePropertiesFilter,

      ServerGroupAntiAffinityFilter, ServerGroupAffinityFilter

    过滤调度器将按照列表中的顺序依次过滤

    • RetryFilter(再审过滤器)

      主要作用是过滤掉之前已经调度过的节点。如A、B、C都通过了过滤,A权重最大被选中执行操作,由于某种原因,操作在A上失败了。Nova-filter将重新执行过滤器,那么此时A就被会RetryFilter直接排除,以免再次失败

    • AvailabilityZoneFilter(可用区域过滤器)

      为提高容灾行并提供隔离服务,可以将计算节点划分到不同的可用区域中。OpenStack默认有一个命名为nova的可用区域,所有的计算节点初始是放在nova区域中的。用户可以根据需要创建自己的一个可用区域。创建实例时,需要指定将实例部署在哪个可用区域中。Nova-scheduler执行过滤操作时,会使AvailabilityZoneFilter不属于指定可用区域计算节点过滤掉

    • RamFilter(内存过滤器)

      根据可用内存来调整虚拟机创建,将不能满足实例类型内存需求的计算节点过滤掉,但为了提高系统资源利用率,Openstack在计算节点的可用内存时允许超过实际内存大小,超过的程度是通过nova.conf配置文件中ram_allocation_ratio参数来控制的,默认值是1.5。

      vi /etc/nova/nova.conf

      Ram_allocation_ratio=1.5

    • DiskFilter(硬盘调度器)

      根据磁盘空间来调度虚拟机创建,将不能满足类型磁盘需求的计算节点过滤掉。磁盘同样允许超量,超量值可修改nova.conf中disk_allocation_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调度,它是必选的过滤器

    • ComputeCapabilitiesFilter(计算能力过滤器)

      根据计算节点的特性来过了,如不同的架构。

    • ImagePropertiesFilter(镜像属性过滤器)

      根据所选镜像的属性来筛选匹配的计算节点,通过元数据来指定其属性。如希望镜像只运行在KVM的Hypervisor上,可以通过Hypervisor Type属性来指定。

    • 服务器组反亲和性过滤器

      要求尽量将实例分散部署到不同的节点上,设置一个服务器组,组内的实例会通过此过滤器部署到不同的计算节点。适用于需要分开部署的实例。

    • 服务器组亲和性过滤器

      此服务器组内的实例,会通过此过滤器,被部署在同一计算节点上,适用于需要位于相同节点的实例服务。

    权重

    • 在对计算节点进行过滤时,多个过滤器依次进行过滤,而不是并行,相当于一个个预选,避免重复对同一个节点进行所有过滤项检验。过滤之后的节点再通过计算权重选出最终的计算节点。
    • 所有权重位于nova/scheduler/weights 目录下,目前默认是RAMweighter,根据计算节点空闲的内存计算权重,内存空闲越多权重越大,实例将被部署到内存空闲最大的计算节点。

    5.Nova组件介绍-Compute

    • Nova-compute在计算节点上运行,负责管理节点上的实例。通常一个主机运行一个Nova-compute服务,一个实例部署在哪个可用的主机上取决于调度算法。OpenStack对实例的操作,最后都是提交给Nova-compute来完成。

    • Nova-compute可分为两类,一类是定向openstack报告计算节点的状态,另一类是实现实例生命周期的管理

    • 通过Driver(驱动)架构支持多种Hypervisor虚拟机管理器

      • 面对多种Hypervisor,nova-compute为这些Hypervisor定义统一的接口
      • Hypervisor只需要实现这些接口,就可以Driver的形式即插即用到OpenStack系统中
    • 定期向OpenStack报告计算节点的状态

      • 每隔一段时间,nova-compute就会报告当前节点的资源使用情况和nova-compute服务状态
      • nova-compute是通过Hypervisor的驱动获取这些信息的
    • 实现虚拟机实例生命周期的管理

      • OpenStack对虚拟机实例最主要的操作都是通过nova-compute实现的。

        创建、关闭、重启、挂起、恢复、中止、调整大小、迁移、快照

      • 以实例创建为例来说明nova-compute的实现过程

        (1)为实例准备资源

        (2)创建实例的镜像文件

        (3)创建实例的XML定义文件

        (4)创建虚拟网络并启动虚拟机

    6.nova组件介绍-Conductor

    • 由nova-conductor模块实现,旨在为数据库的访问提供一层安全保障。Nova-conductor作为nova-compute服务由nova-compute服务与数据库之间交互的中介,避免了直接访问由nova-compute服务创建对接数据库
    • Nova-compute访问数据库的全部操作都改到nova-conductor中,nova-conductor作为对数据库操作的一个代理,而且nova-conductor是部署在控制节点上的
    • Nova-conductor有助于提高数据库的访问性能,nova-compute可以创建多个线程使用远程过程调用(RPC)访问nova-conductor
    • 在一个大规模的openstack部署环境里,管理员可以通过增加nova-conductor的数量来应付日益增长的计算节点对数据库的访问量

    7.nova组件介绍-PlacementAPI

    • 以前对资源的管理全部由计算节点承担,在统计资源使用情况时,只是简单的将所有计算节点的资源情况累加起来,但是系统中还存在外部资源,这些资源由外部系统提供。如ceph、nfs等提供的存储资源等。面对多种多样的资源提供者,管理员需要统一的、简单的管理接口来统计系统中资源使用情况,这个接口就是PlacementAPI
    • PlacementAPI由nova-placement-api服务来实现,旨在追踪记录资源提供者的目录和资源使用情况
    • 被消费的资源类型是按类进行追踪的。如计算节点类、共享存储池类、IP地址类等

    8.虚拟机实例化流程

    用户可以通过多种方式访问虚拟机的控制台

    • Nova-novncproxy守护进程:通过vnc连接访问正在运行的实例提供一个代理,支持浏览器novnc客户端
    • Nova-spicehtml5proxy守护进程:通过spice连接访问正在运行的实例提供一个代理,支持基于html5浏览器的客户端
    • Nova-xvpvncproxy守护进程:通过vnc连接访问正在运行的实例提供一个代理,支持openstack专用的java客户端
    • Nova-consoleauth守护进程:负责对访问虚拟机控制台提供用户令牌认证。这个服务必须与控制台代理程序共同使用

    9.控制台接口

    • 首先用户(可以是OpenStack最终用户,也可以是其他程序)执行Nova Client提供的用于创建虚拟机的命令
    • nova-api服务监听到来自于Nova Client的HTTP请求,并将这些请求转换为AMQP消息之后加入消息队列
    • 通过消息队列调用nova-conductor服务
    • nova-conductor服务从消息队列中接收到虚拟机实例化请求消息后,进行一些准备工作
    • nova-conductor服务通过消息队列告诉nova-scheduler服务去选择一个合适的计算节点来创建虚拟机,此时nova-scheduler会读取数据库的内容
    • nova-conductor服务从nova-scheduler服务得到了合适的将计算节点的信息后,在通过消息队列来通知nova-compute服务实现虚拟机的创建
    展开全文
  • 参考网络资料学习并整理如下内容,如果有错误请指出谢谢。...API服务器(nova-api)计算服务器(nova-computer)网络控制器(nova-network)调度器(nova-schedule)卷控制器(nova-volume)消息队列(queue)
     参考网络资料学习并整理如下内容,如果有错误请指出谢谢。


    1、nova逻辑架构:
         nova是云主机控制器,它包含很多组件。
        • API服务器(nova-api)
        • 计算服务器(nova-computer)
        • 网络控制器(nova-network)
        • 调度器(nova-schedule)
        • 卷控制器(nova-volume)
        • 消息队列(queue)
         1111.png
    • nova-api是整个nova的入口,他接受用户请求,将指令发送给消息队列,由相应的服务执行相关的指令消息
    • nova-computer是主要的执行守护进程,职责是基于各种虚拟化技术Hyperivisor实现创建和终止虚拟机。nova-computer有两个工作,接受消息队列中的执行指令,并执行相关指令,如部署虚拟机、维护数据库先关模型的状态数据。
    • nova-volume职责是创建、挂载、卸载持久化的磁盘虚拟机,运行机制类似nova-computer。同样是接受消息队列中的执行指令,并执行相关指令。volume相关职责包括:创建硬盘、删除硬盘,弹性计算硬盘(不明白这个是个什么意思),总之就是为虚拟机增加块设备存储。
    • nova-network的职责就是实现网络资源池的管理,包括ip池,网桥接口、vlan、防火墙的管理。接受消息队列指令并执行相关指令。network的职责包括如下:分配私有云、vlan管理、配置计算节点网络。
    • nova-schedule的职责就是调度虚拟机在那个计算节点上部署,接受消息队列指令并执行相关指令。
    • queue:消息队列(这个我一直弄不太懂,最近又专门看了rabbitMq工作原理才明白点,接下来也会分享下)。从架构上看nova各个组件之间的通信全是靠它了,她和db一起为各个守护进程之间传递消息。

    2、运行架构

         nova-api对外统一提供标准化接口,各子模块,如计算资源(computer),存储资源(volume)、网络资源(network)模块通过相应的api接口服务对外提供服务。
         
          API接口操作DB实现资源数据模型的维护。通过消息中间件,通知相应的守护进程如nova-compute实现服务接口,api与守护进程共享DB数据库,但守护进程侧重维护状态信息,网络资源状态。守护进程之间不能直接调用,需要通过api调用,如nova-compute为虚拟机分配网络,需要调用network-api,而不能直接调用nova-network,这样易于解耦合。

         下面以创建虚拟机为例:
    1. 通过调用nova-api创建虚拟机接口,nova-api对参数进行解析以及初步合法性校验,调用compute-api创建虚拟机vm接口,computer-api根据虚拟机参数(cpu、内存、磁盘、网络、安全组等)信息,访问数据库创建数据模型虚拟机实例记录。
    2. 接下来需要调用具体的物理机实现虚拟机部署,在这里就会涉及调度模块nova-scheduler,computer-api通过rpc的方式将创建虚拟机的基础信息封装成消息发送至消息中间件指定消息队列“scheduler”
    3. nova-scheduer订阅了消息队列“scheduler”的内容,接受到创建虚拟机的消息后,进行过滤,根据请求的虚拟资源,即flavor的信息,scheduler会找到一个可用的主机,如果没有找到就设置虚拟机的状态成ERROR,选择一台物理主机部署,如novan1,nova-scheduler将虚拟机的基本信息、所属物理主机信息发送值消息中间件指定消息队列“computer.novan1”
    4. novan1上nova-compute守护进程订阅消息队列“computer.novan1”,接受到消息后,根据虚拟机基本信息开始创建虚拟机
    5. nova-computer调用network-api分配网络ip
    6. nova-network接受到消息后,从fixedIP表中拿出一个可用的IP,nova-network根据私网资源池,结合DHCP,实现ip分配和ip绑定
    7. nova-computer通过调用volume-api实现存储划分,最后调用底层虚拟化技术,部署虚拟机。

    3、开发架构
         nova的主要代码都是nova文件夹下:
    • /nova/service.py :主机上运行所有服务的通信节点基类;所有服务的start位置。
    • /nova/config.py :配置信息
    • /nova/api/openstack : 提供openstack nova rest api接口服务
    • /nova/computer :计算资源池
    • /nova/computer/api.py :处理关于计算资源的所有的请求。
    • /nova/computer/manager.py :对实例相关的所有进程的处理
        • computerVirtAPI.py:计算virtapi
        • computerManager.py :管理实例从建立到销毁的运行过程
    • /nova/network :网络资源池
    • /nova/schedule : 调度资源池

    4、数据库相关表
    • computer_node :计算节点信息
    • fixed_ips: 固定ip表
    • instance_actions :实例的所有操作都会记录在这张表中,包括create 、delete、stop、reset等
    • instance_action_events
    • instance_types: 就是flavor
    • instances:虚拟机表
    • networks:网络信息
    • services: 各个子模块服务的信息,比如computer network scheduler conduct
    展开全文
  • openstack nova api模块分析

    千次阅读 2015-02-10 11:00:18
    Nova API 在nova中的作用 ...Nova API服务是openstack nova模块的核心模块。API服务使nova计算模块的命令和控制流程,为用户提供服务。API是一个HTTP web服务,负责处理认证、授权、基本命令和控制功能。缺省情况

    以下内容转自 http://blog.csdn.net/joelovegreen/article/details/16892997

    Nova API 在nova中的作用

    Nova API服务是openstack nova模块的核心模块。API服务使nova计算模块的命令和控制流程,为用户提供服务。API是一个HTTP web服务,负责处理认证、授权、基本命令和控制功能。缺省情况下,nova-api监控8774端口。为了接受和处理API请求,nova-api初始化大部分流程服务(比如驱动server和创建flavors),同时初始化策略(认证、授权和配额检查)。对于一小部分请求,它通过查询数据库处理整个请求,然后返回处理后的结果。对大部分复杂的请求,通过向数据库写信息和把消息发送到队列的方式,向其它服务进程发送消息。

     

    WSGI和Middleware

    WSGI,是一个web应用服务规范、规范规定了server和application的接口。如何一个应用A基于wsgi规范定义的接口编写、它将可以在任何遵守wgsi规范的server上运行(Philli J.Eby,2003).

    WSGI应用可以放入到中间件堆栈中,这些中间件必须实现WSGI的server和application两边接口。对于顶层应用、它就是一个server;然而,对于它的下层的应用,它是application。

    WSGI服务器只有一个工作,就是接受client发过来的请求,将请求传递给应用,然后将应用处理后的结果返回client。Application或中间件进行详细的处理。

     

    Webob,Routes和Paste

    Routes是Rails routes的一个Python语言实现,用于URL到应用action的映射,可以直接生成URL。Routes让编写Restful的URL更加容易、花费的工作更少。

    Webob是一个Python库,提供抓取wsgirequest环境、同时协助创建WSGI 响应response。Webob映射HTTP的大部分参数、包括http头解析,内容协商、正确处理条件和范围的的请求request(webob)。

    Paste depolment是一个查找和配置WSGI应用和服务的系统。对于WSGI应用消费者,提供一个单例函数,简单的功能(loadappp),该函数实现从一个配置文件或python Egg中加载WSGI应用。对于应用提供者,需要一个单例、简单的入口点,这样,应用用户不需要暴露应用的具体实现细节(Paste Deployment)。

    Nova API结构

    Nova.wsgi.server在每个Nova APIworker进程中,以嵌入式web服务器的方式通过服务。它封装和管理WSGI服务器的一个实现evenlet版本的服务器,运行在自我管理的green线程池(大小可以配置),提供定制化的socket(监听端口、最大连接队列)。

    避免把wsgi应用直接提供给WSGI server,nova.api.openstack.compute.APIRouters在一个wsgi server中绑定多个wsgi应用。这样做目的是,使每一个核心API和扩展资源应用直接,相互独立。

    Nova.api.openstack.compute.APIRouter的父类Nova.wsgi.Router使用routes.middleware.RoutesMiddleware映射请求到WSGI应用。Nova.api.openstack.wsgi.Resource(nova.Application的一个实现)是定义webob抓取wsgi应用入口点和处理进来请求的地方。所有核心和扩展的API实质上是nova.api.openstack.wsgi.Resource的控制器controllers, nova.api.openstack.wsgi.Resource也负责controller方法的分发。

     

    扩展API(Extension API)

    有两种方式扩展openstack API,创建一个新的WSGI resource或者扩展已存在wsgi resource的controllers。两种方式都需要编写一个新的模块module,在模块中声明一个控制器类处理请求;实现extensions.ExtensionDescriptor注册新创建resource或控制器extensions.Multiply的resource。扩展的controller可以定义在单独的API模块。比如nova.openstack.contrib.host中的实现。

     

    安全策略Security Policy

    Nova.openstack.commn.policy强制执行安全策略。在nova/policy.json中,每一个API可以有他们自己的策略,策略可以针对API的整个操作,或者全部操作。

    注,定义的规则将会递归解析,直到最后一个被解析。角色根据用户的凭证进行验证。

     

    Nova API 服务初始化

    Nova/bin/nova-api根据预配置的工作线程数量加载nova API。它创建一个wsgi server(可以根据enabled_apis配置启动多个server),server创建nova.api.openstackAPIRouter子类实例(实际上是routes.middleware.RoutesMiddleware)来处理请求分发,配置文件通过paste加载;然后,nova API使用nova.service.ProcessLauncher调用一个子进程,一直等到,直到nova-api退出。

    在初始化阶段,APIRouter的子类通过routes.Mapper资源为核心和扩展API应用,建立RESTful的资源,,比如nova.api.openstack.compute.APIRtouter提供计算API。子进程,可以nova 配置文件中配置的多个进程,准备好处理http请求。

    注,当为一个API配置一个或多个worker(osapi_compute_workes=3)时,子进程监听相同端口的方式是通过继承父进程打开的一个文件描述(服务套接字socket)。父进程在子进程被创建之前,创建和监听服务套接字(不提供连接)。

     

     

    加载Nova API应用

    Nova.wsgi.Server没有硬编码加载nova.api.opnestack.APIRouter实现,取而代之,Router及多个过滤器filter通过paste部署到wsgi服务器。相关信息放在paste配置文件中。比如,用户认证和利用率限制通过过滤器完成。Paste配置文件的名字是api-paste.ini,一般部署在/etc/nova目录下。



    扩展API加载

    根据osapi_compute_extension配置文件,ExtensionManager将会加载标准或选择的扩展实现。加载扩展实现的入口点定义在contrib包的初始化stage(standard_extensions和select_extensions)。标准扩展加载制定目录模块(计算和存储API的contrib包),使用标准扩展命名规范(模块的类与初始化的地方有相同的名字)。选择性模块加载nova配置文件中配置的模块。

    加载过程包括两个阶段:扩展模块加载和扩展API建立,如下图所示。


    处理请求

    客户请求首先到达nova.api.openstac.APIRouter实例,请求传递内部的routes.middleware。通过初始化阶段建立的route映射,RouteMiddleware中间件实例将请求路由到wsgi资源。WSGI资源(核心或扩展API资源)接受请求后,nova.api.openstack.wsgi.Resource将客户请求传递给请求处理方法(index,create,delete…或者其他定制的action),请求将在这些方法中处理。



    如何写核心API

    1.      写一个controller,为RESTful资源实现标准动作(index,create,delete)和其他定制的操作

    2.      在APIRouter实现中,建立标准Restful资源,比如compute的nova.api.opnestack.compute.APIRouter



    如何写扩展API

    1.      为一个新的Restful资源或已存在的资源,写一个controller实现标准操作(比如,index、create、delete…),其它定制的动作。

    2.      定义extensions.ExensionDescriptor的一个子类。子类实现get_resources和get_controller_extensions方法,建立一个新的资源或控制器扩展。

    3.      把controller和扩展描述类放进有同样名字的初始化的模块里。描述全部小写。这样做是为了,当系统配置为加载standard_extension时,让nova.api.openstack.extensions.load_standard_extensions识别出来。

    4.      把模块放在包被加载的目录下,一般是contrib包。

    5.      当创建资源扩展(extensions.ResourceExtension)时,如果需要创建一个定制资源,要提供一个custom_routes_fn,比如去除{tenant_id}路由组件。

     

    以下是一个domcuments简单API定义扩展。Controller实现定义了5个基本操作(CRUD和LIST)。

    [python]  view plain copy 在CODE上查看代码片 派生到我的代码片
    1. class DocumentController(object):  
    2.     “””the Document s API controller deceleration”””  
    3.    
    4.     def index(self,req):  
    5.         “””return a list of documents “””  
    6.         pass  
    7.     def create(self,req, body):  
    8.         “””create a document “””  
    9.         pass  
    10.     def show(self,req, id):  
    11.         “”” read the details of a document given its id”””  
    12.         pass  
    13.      def update(self, req, id, body):  
    14.          “””updates a document given its id and content “””  
    15.          pass  
    16.     def delete(self,req, id):  
    17.         “””removes a document given its id”””  
    18.         pass  
    19.   
    20.     class Documents(extensions.ExtensionDescriptor):  
    21.         “”“ExtensionDescriptor implementation”””  
    22.         name = "document"  
    23.         alias ="os-documents"  
    24.         namespace ="......"  
    25.         updated = "......"  
    26.   
    27.         def get_resources(self):  
    28.             “”” register the new Documents RESTful resource ”””  
    29.             resources = [extensions.ResourceExtension('os-documents',DocumentController())]  
    30.             return resources  
    31.    
    32. 提供以下API,  
    33.   
    34. GET v2/{tenant_id}/ os-documents  
    35. POST v2/{tenant_id}/ os-documents  
    36. GET v2/{tenant_id}/ os-documents/{document_id}  
    37. PUT v2/{tenant_id}/ os-documents/{document_id}  
    38. DELETE v2/{tenant_id}/ os-documents/{document_id}  

    展开全文
  • openstack nova-scheduler 模块分析

    千次阅读 2013-01-16 16:16:47
    图 1-1 openstack nova-scheduler 整体模块关联 由上图加上按照从上往下的思路来描述: 1. rpcapi.py : 继承自nova.openstack.common.rpc.proxy.RpcProxy,用于其他模块调用,所以是单独的模块。 2. driver.py:...

                              图 1-1 openstack nova-scheduler 整体模块关联

    由上图加上按照从上往下的思路来描述:

    1. rpcapi.py : 继承自nova.openstack.common.rpc.proxy.RpcProxy,用于其他模块调用,所以是单独的模块。

    2. driver.py: scheduler的基类,定义schduler操作使用到的方法。

    3. chance.py : 主要包括类ChanceScheduler,是scheduler的一种实现,具体逻辑在_scheduler。

    代码:

    def _schedule(self, context, topic, request_spec, filter_properties):
            """Picks a host that is up at random."""
    
            elevated = context.elevated()
            hosts = self.hosts_up(elevated, topic)
            if not hosts:
                msg = _("Is the appropriate service running?")
                raise exception.NoValidHost(reason=msg)
    
            hosts = self._filter_hosts(request_spec, hosts, filter_properties)
            if not hosts:
                msg = _("Could not find another compute")
                raise exception.NoValidHost(reason=msg)
    
            return hosts[int(random.random() * len(hosts))]  #######从此处可以看出条件筛选过得host选择条件是随即算法。


    4. filter_scheduler.py:主要包括类FilterSchduler,是scheduler的另一种重要实现,来看具体逻辑:

    代码:

    def _schedule(self, context, topic, request_spec, filter_properties,
                      instance_uuids=None):
            """Returns a list of hosts that meet the required specs,
            ordered by their fitness.
            """
            elevated = context.elevated()
            if topic != "compute":
                msg = _("Scheduler only understands Compute nodes (for now)")
                raise NotImplementedError(msg)
    
            instance_properties = request_spec['instance_properties']
            instance_type = request_spec.get("instance_type", None)
    
            cost_functions = self.get_cost_functions()
            config_options = self._get_configuration_options()
    
            # check retry policy.  Rather ugly use of instance_uuids[0]...
            # but if we've exceeded max retries... then we really only
            # have a single instance.
            properties = instance_properties.copy()
            if instance_uuids:
                properties['uuid'] = instance_uuids[0]
            self._populate_retry(filter_properties, properties)
    
            filter_properties.update({'context': context,
                                      'request_spec': request_spec,
                                      'config_options': config_options,
                                      'instance_type': instance_type})
    
            self.populate_filter_properties(request_spec,
                                            filter_properties)
    
            # Find our local list of acceptable hosts by repeatedly
            # filtering and weighing our options. Each time we choose a
            # host, we virtually consume resources on it so subsequent
            # selections can adjust accordingly.
    
            # unfiltered_hosts_dict is {host : ZoneManager.HostInfo()}
            unfiltered_hosts_dict = self.host_manager.get_all_host_states(   ####此为调用host_manager的出处,主要来从数据库中获取host的当前信息。
                    elevated, topic)
    
            # Note: remember, we are using an iterator here. So only
            # traverse this list once. This can bite you if the hosts
            # are being scanned in a filter or weighing function.
            hosts = unfiltered_hosts_dict.itervalues()
    
            selected_hosts = []
            if instance_uuids:
                num_instances = len(instance_uuids)
            else:
                num_instances = request_spec.get('num_instances', 1)
            for num in xrange(num_instances):
                # Filter local hosts based on requirements ...
                hosts = self.host_manager.filter_hosts(hosts,       ####使用host_manager调用Filters模块集中的good_filters筛选出满足资源请求的host
                        filter_properties)
                if not hosts:
                    # Can't get any more locally.
                    break
    
                LOG.debug(_("Filtered %(hosts)s") % locals())
    
                # weighted_host = WeightedHost() ... the best
                # host for the job.
                # TODO(comstud): filter_properties will also be used for
                # weighing and I plan fold weighing into the host manager
                # in a future patch.  I'll address the naming of this
                # variable at that time.
                weighted_host = least_cost.weighted_sum(cost_functions, ####此为调用least_cost的出处,使用其中的host加权算法,后面有介绍。
                        hosts, filter_properties)
                LOG.debug(_("Weighted %(weighted_host)s") % locals())
                selected_hosts.append(weighted_host)
    
                # Now consume the resources so the filter/weights
                # will change for the next instance.
                weighted_host.host_state.consume_from_instance(
                        instance_properties)
    
            selected_hosts.sort(key=operator.attrgetter('weight')) ### 按照weight对hosts排序,返回List对象。
            return selected_hosts


    总结: scheduler逻辑主要包括以下:

          a 从request_spec中获取资源请求,并更新在filter_properties中。

         b  在host_manager中使用good_filters以filter_properties为条件,筛选满足条件的hosts

         c  使用least_cost的加权算法,完成host List的排序。

    5. multi.py:基于compute_*_driver,将几类scheduler对应集中action。

        例如: schedule_run_instance -->FilterScheduler

                   schedule_prep_resize -->FilterScheduler

                   schedule_create_volum --> ChanceScheduler

    6. manager.py : 包含muti.py,作为外界的统一接口。


    备注:由于scheduler在nova instance启动,resize,change volume过程中处于中间过程,所以存在需要rpc的publish and consumer。


    转发: 请标注http://blog.csdn.net/soft_lawrency/article/details/8509939


    Good Luck

    Lawrency Meng


    展开全文
  • 深挖Openstack Nova - Compute模块

    千次阅读 2018-06-07 10:25:48
    nova-compute是一个非常重要的守护进程,负责创建和终止虚拟机实例,即管理着虚拟机实例的生命周期,包括instance的launch、shutdown、reboot、suspend、resume、terminate、resize、migration、snapshot等。...
  • 前言一、Nova服务简介1.1 Nova的元数据1.2 VM...在安装Nova模块之前,需先安装Placement组件,Placement在openstack的Stein版本之前,属于Nova组件的一部分。该组件需要在Nova之前安装。 一、Nova服务简介 1、Nova(O.
  • nova模块是的一部分,它是OpenStack基础结构团队的一项工作,旨在为OpenStack和OpenStack社区项目(作为核心软件的一部分)提供持续的集成测试和代码审查。 该模块本身用于灵活配置和管理OpenStack的计算服务。 模块...
  •  此阶段主要目的是调用事先在nova.conf文件中配置的过滤器,选择合适的计算节点。 文件nova/scheduler/manager.py 104行,self.driver实际是在nova.conf文件中配置的FileterScheduler 二、nova/...
  • 前言:nova和swift是openstack最早的两个组件,nova分为控制节点和计算节点,计算节点通过nova computer进行虚拟机创建,通过libvirt调用kvm创建虚拟机,nova之间通信通过rabbitMQ队列进行通信 文章目录一、Nova...
  • =============================== NeCTAR RC的Puppet Nova模块 变数 该模块明确使用了hiera,您将需要使用它才能使用此模块。 班级 新星 nova :: api 安装和配置nova-api nova :: api ::负载均衡 将Nginx放在nova-...
  • OpenStack之Nova模块

    2018-04-10 11:33:00
    nova和swift是openstack最早的两个组件,nova分为控制节点和计算节点,计算节点通过nova computer进行虚拟机创建,通过libvirt调用kvm创建虚拟机,nova之间通信通过rabbitMQ队列进行通信。 Nova体系结构 Nova重要...
  • 计算管理(codenamed “Nova”) 是基于用户需求为VM提供计算资源管理,它基于Python语言编写。
  • nova数据库模块的开发和使用 ...如果要增加一个新的功能,而且这个功能需要操作数据库,在操作数据库这个方面一般分为两个步骤:一、db模块中的内容编写,主要包括数据表的创建、功能及api的编写;二、c
  • Nova服务安装配置

    千次阅读 2017-05-09 16:28:08
    Openstack项目中的Nova计算服务是IaaS云计算平台的核心服务组件,控制着虚拟机实例和网络功能,通过对用户和项目的设置,管理对Openstack云资源的访问。Nova计算服务组件没有创建新的虚拟化技术(如KVM或Xen等虚拟化...
  • Nova

    2021-04-12 19:18:55
    Nova组件由Nova-API,Nova-scheduler,Nova-conductor,Nova-compute以及提供消息传递的消息队列(message queue)和数据裤模块(database)组成 Nova-API:主要提供了统一风格的REST-API接口,作为Nova组件的入口,...
  • Nova计算服务介绍

    2020-12-28 09:05:00
    ● 计算服务是openstack最核心的服务之一 , 负责维护和管理云环境的计算资源,它在openstack项目中代号是nova。 ● Nova自身并没有提供任何虚拟化能力,它提供计算服务,使用不同的虚拟化驱动来与底层支持的...
  • 提示:以下操作在控制节点完成,为计算服务创建数据库、服务认证和API端点 使用数据库客户端,以root用户连接到数据库中:mysql -u root -p 创建Nova数据库:CREATE DATABASE nova; 为Nova用户授予数据库权限: ...
  • Nova Scheduler的启动脚本中,最终的代码是创建Service类的create...分析Nova Scheduler服务的启动流程。 1、Service类的create方法 class Service(object): @classmethod def create(cls, host=None, binar
  • 传统公司部署OpenStack(t版)简易介绍(五)——nova模块部署一、nova组件部署位置二、ct节点Nova服务配置三、c1节点配置Nova服务(c2节点一样,只是配置文件的IP不同)四、controller节点操作(ct) 一、nova组件...
  • Nova RPC服务的工作流程,以及后面添加自定义Nova模块都是有帮助的。 以Nova Scheduler服务为例,分析Nova RPC服务的启动流程。Nova组件的“大脑”——Nova Scheduler(调度器)。 它是我们后续分析虚拟机创建的...
  • openstack-ocata nova oslo.log模块浅析

    千次阅读 2017-02-27 11:18:54
    仍然使用compute服务进行分析,在启动时的log服务预初始化:log.register_options(CONF) log.set_defaults(default_log_levels=log.get_default_log_levels() + extra_default_log_levels)注册了oslo_log库的config...
  • nova介绍 Nova 负责维护和管理云环境的计算资源,Nova这个模块很重要,可以说是 OpenStack 的最...也便于功能分配管理,才把虚拟存储、网络等部分分离出来,而使该模块主要负责云虚拟机实例(Compute 或 Instance) ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 5,811
精华内容 2,324
热门标签
关键字:

nova服务主要模块