Nova-api

• Nova-api
  是整个 Nova 组件的门户，所有对 Nova 的请求都首先由 nova-api 处理。
• Nova-api
  向外界暴露若干
  HTTP
  REST API 接口。

• 在keystone 中我们可以查询 nova-api 的 endponits

  • openstack endpoint list | grep nova查看nova暴露的api端口

  [root@controller ~]# openstack endpoint list | grep nova
  | 1cf03146ee544acba6bec34001239104 | RegionOne | nova         | compute      | True    | public    | http://controller:8774/v2.1 |
  | 5c8a70f3262849fbbcfc4556d1d69253 | RegionOne | nova         | compute      | True    | admin     | http://controller:8774/v2.1 |
  | c9d717d5a33544e8aecae95b3add0f42 | RegionOne | nova         | compute      | True    | internal  | http://controller:8774/v2.1 |

• 客户端就可以将请求发送到
  endponits
  指定的地址，向
  nova-api
  请求操作。
• 当然，作为最终用户的我们不会直接发送Rest API请求。
• OpenStack
  CLI，Dashboard 和其他需要跟 Nova 交换的组件会使用这些API。

• Nova-api
  对接收到的
  HTTP
  API 请求会做如下处理：

  • ①检查客户端传人的参数是否合法有效
  • ②调用

  Nova 其他子服务的处理客户端 HTTP 请求

  • ③格式化

  Nova 其他子服务返回的结果并返回给客户端

问题：Nova-api接收哪些请求？？
答：只要跟虚拟机生命周期相关操作的都会接收

Nova-conductor

• nova-compute
  需要获取和更新数据库中
  instance
  的信息。

• 但
  nova-compute
  并不会直接访问数据库，而是通过
  nova-conductor
  实现数据的访问，好处在于：

  • 更高的系统安全性

    • nova-compute部署在计算节点上，Database部署在控制节点，  如果黑客入侵计算节点后就会威胁控制节点上的数据库，所以我们可以在nova-conduct上去做数据安全性的操作。

  • 更好的系统伸缩性

    • 在大规模Openstack部署环境中，我们可以配置多个nova-conductor实例来满足日益增长的计算节点对数据库的访问。

Nova-scheduler

• Nova-scheduler是为了解决如何选择计算节点运行Instance
• Flavor中定义CPU、RAM、Disk和Metadata四类
• Nova-scheduler会按照flavor选择合适的计算节点

• 在/etc/nova/nova.conf中，nova通过scheduler_driver，scheduler_available_filters 和 scheduler_default_filters 这三个参数来配置 nova-scheduler。
  

  Filter scheduler

• Filter scheduler 是 nova-scheduler 默认的调度器，调度过程分为两步：

  • ① 通过过滤器（filter）选择满足条件的计算节点（运行 nova-compute）

  • ② 通过权重计算（weighting）选择在最优（权重值最大）的计算节点上创建 Instance。

    • scheduler_driver=nova.scheduler.filter_scheduler.FilterScheduler
    • Nova

  允许使用第三方
  scheduler，配置
  scheduler_driver
  即可。
  这又一次体现了OpenStack的开放性。

• Scheduler 可以使用多个 filter 依次进行过滤，过滤之后的节点再通过计算权重选出最适合的节点。
  

  Filter

• 当 Filter scheduler 需要执行调度操作时，会让 filter 对计算节点进行判断，filter 返回 True 或 False。

• Nova.conf 中的 scheduler_available_filters 选项用于配置 scheduler 可用的 filter，默认是所有 nova 自带的 filter 都可以用于滤操作。

  scheduler_available_filters = nova.scheduler.filters.all_filters

• 另外还有一个选项
  scheduler_default_filters，用于指定
  scheduler
  真正使用的
  filter，默认值如下：

  • scheduler_default_filters =

  RetryFilter, AvailabilityZoneFilter, RamFilter, DiskFilter, ComputeFilter,
  ComputeCapabilitiesFilter, ImagePropertiesFilter,
  ServerGroupAntiAffinityFilter, ServerGroupAffinityFilter
  

  RetryFilter

• RetryFilter 的作用是刷掉之前已经调度过的节点。

  • 举个栗子：假设 A,B,C 三个节点都通过过滤，最终 A 因为权重值最大被选中执行操作。 但由于某个原因，操作在 A 上失败了。 默认情况下，nova-scheduler 会重新执行过滤操作（重复次数由 scheduler_max_attempts 选项指定，默认是 3）。 那么这时候 RetryFilter 就会将 A 直接刷掉，避免操作再次失败。 RetryFilter 通常作为第一个 filter。

  AvailabilityZoneFilter

• 为提高容灾性和提供隔离服务，可以将计算节点划分到不同的Availability Zone中。

  • 例如把一个机架上的机器划分到一个Availability Zone中，Openstack默认有一个nova的Availability Zones，初始所有计算节点都放入“nova”Zone中；创建Instance时，需要指定Availability Zone，nova-scheduler在做flitering时，会使用AvailabilityZoneFilter将不属于指定Availability Zone的节点过滤掉。
  • 简单来讲，就是有两个机架，第一个机架上的所有节点划分用来创建虚拟机，第二个机架上的所有节点用来备份虚拟机，这样当我们命令创建一台虚拟机时，只会从第一个机架上选择一台机器去创建虚拟机，也就是划分了区域。

RamFilter

• 将不能满足 flavor 内存需求的计算节点过滤掉。

  • 比如一个虚拟机的创建需要消耗8G内存，而一个节点只剩下4G空闲内存，那么就不足以创建这个虚拟机。

• 为了提高系统的资源使用率，Openstack在计算节点可用内存可以overcommit(超售)，也就是超过内存实际大小。

  • 参数设置：ram_allocation_ratio = 1.5（默认）
  • 例如：某台计算机点 内存资源一共32g，现在创建4个实例每个实例规定8G内存，在实际物理机器上资源不一定就跑满了，8G只是创建虚拟机时选择规格中的一个大小，所以我们设置超售值为1.5，那么物理机就会认为自己有32*1.5 也就是48G，所以可以跑6个内存大小为8G规格的虚拟机。

DiskFilter

• 将不能满足 flavor（创建虚拟机时的规格实例） 磁盘需求的计算节点过滤掉。

• 为了提高系统的资源使用率，Disk同样允许overcommit。

  • disk_allocation_ratio

  =
  1.0（默认）

CoreFilter

• 将不能满足 flavor vCPU需求的计算节点过滤掉。

• 为了提高系统的资源使用率，vCPU同样允许overcommit。

  • pcpu_allocation_ratio

  =
  16（默认）

  • nova-scheduler 默认使用的 filter

  并没有包含
  CoreFilter。
  如果要用，可以将 CoreFilter
  添加到
  nova.conf
  的
  scheduler_default_filters
  配置选项中。

ComputeFilter

保证只有nova-compute服务正常工作的计算节点才能够被调度
ComputeFilter显然是必选的filter。

ComputeCapabilitiesFilter

• 根据计算节点的特性来筛选。

• 举个栗子：

  • 例如我们的节点有 x86_64 和 ARM 架构的，如果想将 Instance 指定部署到 x86_64 架构的节点上，就可以利用到ComputeCapabilitiesFilter。
  • flavor中有个Metadata，Compute的Capabilities就在 Metadata中指定。
  • 配置好后，ComputeCapabilitiesFilter 在调度时只会筛选出 x86_64 的节点。
  • 如果没有设置 Metadata，ComputeCapabilitiesFilter 不会起作用，所有节点都会通过筛选。

ImagePropertiesFilter

• ImagePropertiesFilter 根据所选 image 的属性来筛选匹配的计算节点。
• 跟 flavor 类似，image 也有 metadata，用于指定其属性。

• 举个栗子：

  • 例如希望某个 image 只能运行在 kvm 的 hypervisor 上，可以通过 “Hypervisor Type” 属性来指定。
  • 配置好后，ImagePropertiesFilter 在调度时只会筛选出 kvm 的节点。 如果没有设置 Image 的Metadata，ImagePropertiesFilter 不会起作用，所有节点都会通过筛选。 

ServerGroupAntiAffinityFilter

• ServerGroupAntiAffinityFilter
  可以尽量将
  Instance
  分散部署到不同的节点上。

• 举个栗子：

  • 例如有 inst1，inst2 和 inst3 三个 instance，计算节点有 A,B 和 C。

  • 为保证分散部署，进行如下操作：

    • 创建一个 anti-affinity 策略的 server group “group-1”
    • 请注意，这里的

  server group 其实是 instance
  group，并不是计算节点的 group。

  - 依次创建 Instance，将inst1, inst2和inst3放到group-1中
  - 因为 group-1

  的策略是
  AntiAffinity，调度时
  ServerGroupAntiAffinityFilter
  会将
  inst1,
  inst2 和
  inst3
  部署到不同计算节点
  A,
  B 和
  C。

  - 目前只能在

  CLI
  中指定
  server
  group 来创建
  instance。

  - 创建 instance

  时如果没有指定
  server
  group，ServerGroupAntiAffinityFilter
  会直接通过，不做任何过滤。

ServerGroupAffinityFilter

• 与
  ServerGroupAntiAffinityFilter
  的作用相反，ServerGroupAffinityFilter 会尽量将 instance 部署到同一个计算节点上。

• 方法类似：

  • 创建一个 affinity 策略的 server group “group-2”
  • 依次创建 instance，将 inst1, inst2 和 inst3 放到 group-2 中
  • 因为 group-2 的策略是 Affinity，调度时 ServerGroupAffinityFilter 会将 inst1, inst2 和 inst3 部署到同一个计算节点。
  • 创建 instance 时如果没有指定 server group，ServerGroupAffinityFilter 会直接通过，不做任何过滤。

Nova-scheduler—Weight

• 经过前面一堆
  filter
  的过滤，nova-scheduler 选出了能够部署 instance 的计算节点。 如果有多个计算节点通过了过滤，那么最终选择哪个节点呢？
• Scheduler
  会对每个计算节点打分，得分最高的获胜。
  打分的过程就是 weight，翻译过来就是计算权重值，那么 scheduler 是根据什么来计算权重值呢？
• 目前
  nova-scheduler
  的默认实现是根据计算节点空闲的内存量计算权重值：
  空闲内存越多，权重越大，instance
  将被部署到当前空闲内存最多的计算节点上。

Nova-scheduler日志

所有的服务（glance,keystone,nova,neutorn....）,日志都会记录在/var/log/service_name/service_children中

• 打开nova-scheduler的日志/var/log/nova/scheduler.log
• 日志显示有两台Host，并且通过一系列Filters，最后两个计算节点都通过
• 通过比较Weight，因为 devstack-controller 的空闲内存比 devstack-compute1 多（7466 > 3434），权重值更大

例子：

虚拟机创建失败，就nova服务来说，你会怎么去排查，思路是什么？
1.资源不够，过滤器筛选之后，没有合格的机器，需要查找scheduler的日志
2.认证出现了错误，nova-api的日志，keystone日志

Nova-compute

• nova-compute
  在计算节点上运行，负责管理节点上的
  instance。
• OpenStack
  对 instance 的操作，最后都是交给 nova-compute 来完成的。
• nova-compute
  与 Hypervisor 一起实现 OpenStack 对 instance 生命周期的管理。

• **通过 Driver
  架构支持多种
  Hypervisor**

  • 接着的问题是：现在市面上有这么多

  Hypervisor，nova-compute
  如何与它们配合呢？

• nova-compute
  为这些 Hypervisor 定义了统一的接口，Hypervisor 只需要实现这些接口，就可以 Driver 的形式即插即用到 OpenStack 系统中。
• 下面是Nova Driver的架构示意图：

• 我们可以在/usr/lib/python2.7/site-packages/nova/virt/目录下查看到 OpenStack 源代码中已经自带了上面这几个 Hypervisor 的 Driver。
• 某个特定的计算节点上只会运行一种
  Hypervisor，只需在该节点 nova-compute 的配置文件 /etc/nova/nova.conf 中配置所对应的 compute_driver 就可以了。
• 在我们的环境中因为是
  KVM，所以配置的是 Libvirt 的 driver。

• nova-compute
  的功能可以分为两类：

  • ①   

  定时向 OpenStack
  报告计算节点的状态

  • ②   

  实现 instance
  生命周期的管理

定期向 OpenStack报告计算节点的状态

• Nova-scheduler的很多Filter是根据节点的资源使用进行过滤，那Openstack是如何得知每个计算节点的资源使用信息呢？

  • Nova-compute会定期向OpenStack报告。

  • Nova-compute是如何获得当前计算节点的资源使用信息呢？

    • Hypervisor

    • 举例来说：

      • 在我们的实验环境下 Hypervisor 是 KVM，用的 Driver 是 LibvirtDriver。
      • LibvirtDriver 可以调用相关的 API 获得资源信息，这些 API 的作用相当于我们在 CLI 里执行 virsh nodeinfo、virsh dominfo 等命令。

实现instance生命周期的管理

学习nova-compute如何实现instancelaunch（部署操作）

• nova-compute
  创建 instance 的过程可以分为 4 步：

  • ①为 instance 准备资源（RAM、Disk、vCPU、网络）

  • ②创建 instance 的镜像文件

    • a)首先将image下载到计算节点（qemu-img 将 image 的格式改为raw，作为backingfile）
    • b)然后将其作为backing file 创建 instance的镜像文件（可以通过qume-info查看disk文件的属性）
  • ③创建 instance 的 XML 定义文件（XML文件的位置）
  • ④创建虚拟网络并启动虚拟机（创建网络设备）
• 查看Instance的运行状态：virsh list

<补充>

find指令

http://blog.itpub.net/31559985/viewspace-2673646/
find（查找）主要沿着文件层次（目录）结构依次向下遍历，匹配符合条件的文件，可以附带执行相应的操作选项，默认的操作结果是打印出符合条件的文件与目录。