译 云计算与openstack学习（八）

Nova 组件如何协同工作

Nova 物理部署方案

前面大家已经看到 Nova 由很多子服务组成，同时我们也知道 OpenStack 是一个分布式系统，可以部署到若干节点上，那么接下来大家可能就会问： Nova 的这些服务在物理上应该如何部署呢？ 对于 Nova，这些服务会部署在两类节点上：计算节点和控制节点。 计算节点上安装了 Hypervisor，上面运行虚拟机。 由此可知： 1. 只有 nova-compute 需要放在计算节点上。 2. 其他子服务则是放在控制节点上的。 下面我们可以看看实验环境的具体部署情况。 通过在计算节点和控制节点上运行 ps -elf|grep nova 来查看运行的 nova 子服务 计算节点

计算节点 devstack-compute1 上只运行了 nova-compute 子服务 控制节点

控制节点 devstack-controller 上运行了若干 nova-* 子服务

RabbitMQ 和 MySQL 也是放在控制节点上的 可能细心的同学已经发现我们的控制节点上也运行了 nova-compute。 这实际上也就意味着 devstack-controller 既是一个控制节点，同时也是一个计算节点，也可以在上面运行虚机。 这也向我们展示了 OpenStack 这种分布式架构部署上的灵活性： 可以将所有服务都放在一台物理机上，作为一个 All-in-One 的测试环境； 也可以将服务部署在多台物理机上，获得更好的性能和高可用。 另外，也可以用 nova service-list 查看 nova-* 子服务都分布在哪些节点上

从虚机创建流程看 nova-* 子服务如何协同工作

从学习 Nova 的角度看，虚机创建是一个非常好的场景，涉及的 nova-* 子服务很全，下面是流程图。

客户（可以是 OpenStack 最终用户，也可以是其他程序）向 API（nova-api）发送请求：“帮我创建一个虚机”
API 对请求做一些必要处理后，向 Messaging（RabbitMQ）发送了一条消息：“让 Scheduler 创建一个虚机”
Scheduler（nova-scheduler）从 Messaging 获取到 API 发给它的消息，然后执行调度算法，从若干计算节点中选出节点 A
Scheduler 向 Messaging 发送了一条消息：“在计算节点 A 上创建这个虚机”
计算节点 A 的 Compute（nova-compute）从 Messaging 中获取到 Scheduler 发给它的消息，然后在本节点的 Hypervisor 上启动虚机。
在虚机创建的过程中，Compute 如果需要查询或更新数据库信息，会通过 Messaging 向 Conductor（nova-conductor）发送消息，Conductor 负责数据库访问。
上面是创建虚机最核心的几个步骤，当然也省略了很多细节，我们会在后面的章节详细讨论。 这几个步骤向我们展示了 nova-* 子服务之间的协作的方式，也体现了 OpenStack 整个系统的分布式设计思想，掌握这种思想对我们深入理解 OpenStack 会非常有帮助。

OpenStack 通用设计思路

API 前端服务

每个 OpenStack 组件可能包含若干子服务，其中必定有一个 API 服务负责接收客户请求。 以 Nova 为例，nova-api 作为 Nova 组件对外的唯一窗口，向客户暴露 Nova 能够提供的功能。 当客户需要执行虚机相关的操作，能且只能向 nova-api 发送 REST 请求。 这里的客户包括终端用户、命令行和 OpenStack 其他组件。 设计 API 前端服务的好处在于： 1. 对外提供统一接口，隐藏实现细节 2. API 提供 REST 标准调用服务，便于与第三方系统集成 3. 可以通过运行多个 API 服务实例轻松实现 API 的高可用，比如运行多个 nova-api 进程

Scheduler 调度服务

对于某项操作，如果有多个实体都能够完成任务，那么通常会有一个 scheduler 负责从这些实体中挑选出一个最合适的来执行操作。 在前面的例子中，Nova 有多个计算节点。 当需要创建虚机时，nova-scheduler 会根据计算节点当时的资源使用情况选择一个最合适的计算节点来运行虚机。 调度服务就好比是一个开发团队中的项目经理，当接到新的开发任务时，项目经理会评估任务的难度，考察团队成员目前的工作负荷和技能水平，然后将任务分配给最合适的开发人员。 除了 Nova，块服务组件 Cinder 也有 scheduler 子服务，后面我们会详细讨论。

Worker 工作服务

调度服务只管分配任务，真正执行任务的是 Worker 工作服务。 在 Nova 中，这个 Worker 就是 nova-compute 了。 将 Scheduler 和 Worker 从职能上进行划分使得 OpenStack 非常容易扩展： 当计算资源不够了无法创建虚机时，可以增加计算节点（增加 Worker）
当客户的请求量太大调度不过来时，可以增加 Scheduler

Driver 框架

OpenStack 作为开放的 Infrastracture as a Service 云操作系统，支持业界各种优秀的技术。 这些技术可能是开源免费的，也可能是商业收费的。 这种开放的架构使得 OpenStack 能够在技术上保持先进性，具有很强的竞争力，同时又不会造成厂商锁定（Lock-in）。 那 OpenStack 的这种开放性体现在哪里呢？ 一个重要的方面就是采用基于 Driver 的框架。 以 Nova 为例，OpenStack 的计算节点支持多种 Hypervisor。 包括 KVM, Hyper-V, VMWare, Xen, Docker, LXC 等。 Nova-compute 为这些 Hypervisor 定义了统一的接口，hypervisor 只需要实现这些接口，就可以 driver 的形式即插即用到 OpenStack 中。 下面是 nova driver 的架构示意图

在 nova-compute 的配置文件 /etc/nova/nova.conf 中由 compute_driver 配置项指定该计算节点使用哪种 Hypervisor 的 driver

在我们的环境中因为是 KVM，所以配置的是 Libvirt 的 driver。 不知大家是否还记得我们在学习 Glance 时谈到： OpenStack 支持多种 backend 来存放 image。 可以是本地文件系统，Cinder，Ceph，Swift 等。 其实这也是一个 driver 架构。 只要符合 Glance 定义的规范，新的存储方式可以很方便的加入到 backend 支持列表中。 再后面 Cinder 和 Neutron 中我们还会看到 driver 框架的应用。

Messaging 服务

在前面创建虚机的流程示意图中，我们看到 nova-* 子服务之间的调用严重依赖 Messaging。 Messaging 是 nova-* 子服务交互的中枢。

以前没接触过分布式系统的同学可能会不太理解为什么不让 API 直接调用Scheduler，或是让Scheuler 直接调用 Compute，而是非要通过 Messaging 进行中转。 这里做一些解释。 程序之间的调用通常分两种：同步调用和异步调用。 同步调用API 直接调用 Scheduler 的接口就是同步调用。 其特点是 API 发出请求后需要一直等待，直到 Scheduler 完成对 Compute 的调度，将结果返回给 API 后 API 才能够继续做后面的工作。 异步调用API 通过 Messaging 间接调用 Scheduler 就是异步调用。 其特点是 API 发出请求后不需要等待，直接返回，继续做后面的工作。 Scheduler 从 Messaging 接收到请求后执行调度操作，完成后将结果也通过 Messaging 发送给 API。 在 OpenStack 这类分布式系统中，通常采用异步调用的方式，其好处是： 解耦各子服务 子服务不需要知道其他服务在哪里运行，只需要发送消息给 Messaging 就能完成调用。
提高性能 异步调用使得调用者无需等待结果返回。这样可以继续执行更多的工作，提高系统总的吞吐量。
提高伸缩性 子服务可以根据需要进行扩展，启动更多的实例处理更多的请求，在提高可用性的同时也提高了整个系统的伸缩性。而且这种变化不会影响到其他子服务，也就是说变化对别人是透明的。
在后面各章节，我们都能看到 Messaging 的应用。

Database

OpenStack 各组件都需要维护自己的状态信息。 比如 Nova 中有虚机的规格、状态，这些信息都是在数据库中维护的。 每个 OpenStack 组件在 MySQL 中有自己的数据库。

小结

Nova 是 OpenStack 中最重要的组件，也是很典型的组件。 Nova 充分体现了 OpenStack 的设计思路。 理解了这种思路，再来学习 OpenStack 的其他组件就能够举一反三，清晰容易很多。

Nova 组件详解 - 每天5分钟玩转 OpenStack（26）

本节开始，我们将详细讲解 Nova 的各个子服务。前面架构概览一节知道 Nova 有若干 nova-* 的子服务，下面我们将依次学习最重要的几个。
今天先讨论 nova-api 和 nova-conductor。

nova-api

Nova-api 是整个 Nova 组件的门户，所有对 Nova 的请求都首先由 nova-api 处理。 Nova-api 向外界暴露若干 HTTP REST API 接口。 在 keystone 中我们可以查询 nova-api 的 endponits。

客户端就可以将请求发送到 endponits 指定的地址，向 nova-api 请求操作。 当然，作为最终用户的我们不会直接发送 Rest AP I请求。 OpenStack CLI，Dashboard 和其他需要跟 Nova 交换的组件会使用这些 API。 Nova-api 对接收到的 HTTP API 请求会做如下处理： 1. 检查客户端传人的参数是否合法有效 2. 调用 Nova 其他子服务的处理客户端 HTTP 请求 3. 格式化 Nova 其他子服务返回的结果并返回给客户端 nova-api 接收哪些请求？ 简单的说，只要是跟虚拟机生命周期相关的操作，nova-api 都可以响应。 大部分操作都可以在 Dashboard 上找到。 打开Instance管理界面

点击下拉箭头，列表中就是 nova-api 可执行的操作。

OpenStack 用术语 “Instacne” 来表示虚拟机，后面我们将统一使用这个术语。

nova-conductor

nova-compute 需要获取和更新数据库中 instance 的信息。 但 nova-compute 并不会直接访问数据库，而是通过 nova-conductor 实现数据的访问。

这样做有两个显著好处： 更高的系统安全性
更好的系统伸缩性

更高的安全性

在 OpenStack 的早期版本中，nova-compute 可以直接访问数据库，但这样存在非常大的安全隐患。 因为 nova-compute 这个服务是部署在计算节点上的，为了能够访问控制节点上的数据库，就必须在计算节点的 /etc/nova/nova.conf 中配置访问数据库的连接信息，比如 [database] connection = mysql+pymysql://root:secret@controller/nova?charset=utf8试想任意一个计算节点被******，都会导致部署在控制节点上的数据库面临极大风险。 为了解决这个问题，从 G 版本开始，Nova 引入了一个新服务 nova-conductor，将 nova-compute 访问数据库的全部操作都放到 nova-conductor 中，而且 nova-conductor 是部署在控制节点上的。 这样就避免了 nova-compute 直接访问数据库，增加了系统的安全性。

更好的伸缩性

nova-conductor 将 nova-compute 与数据库解耦之后还带来另一个好处：提高了 nova 的伸缩性。 nova-compute 与 conductor 是通过消息中间件交互的。 这种松散的架构允许配置多个 nova-conductor 实例。 在一个大规模的 OpenStack 部署环境里，管理员可以通过增加 nova-conductor 的数量来应对日益增长的计算节点对数据库的访问。

nova-scheduler 如何选择计算节点

本节重点介绍 nova-scheduler 的调度机制和实现方法：即解决如何选择在哪个计算节点上启动 instance 的问题。创建 Instance 时，用户会提出资源需求，例如 CPU、内存、磁盘各需要多少。OpenStack 将这些需求定义在 flavor 中，用户只需要指定用哪个 flavor 就可以了。

可用的 flavor 在 System->Flavors 中管理。

Flavor 主要定义了 VCPU，RAM，DISK 和 Metadata 这四类。 nova-scheduler 会按照 flavor 去选择合适的计算节点。 VCPU，RAM，DISK 比较好理解，而 Metatdata 比较有意思，我们后面会具体讨论。 下面介绍 nova-scheduler 是如何实现调度的。 在 /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.FilterSchedulerNova 允许使用第三方 scheduler，配置 scheduler_driver 即可。 这又一次体现了OpenStack的开放性。 Scheduler 可以使用多个 filter 依次进行过滤，过滤之后的节点再通过计算权重选出最适合的节点。

上图是调度过程的一个示例： 最开始有 6 个计算节点 Host1-Host6
通过多个 filter 层层过滤，Host2 和 Host4 没有通过，被刷掉了
Host1，Host3，Host5，Host6 计算权重，结果 Host5 得分最高，最终入选

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, ServerGroupAffinityFilterFilter scheduler 将按照列表中的顺序依次过滤。 下面依次介绍每个 filter。

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 Zone，所有的计算节点初始都是放在 “Nova” 中。 用户可以根据需要创建自己的 Availability Zone。

创建 Instance 时，需要指定将 Instance 部署到在哪个 Availability Zone中。

nova-scheduler 在做 filtering 时，会使用 AvailabilityZoneFilter 将不属于指定 Availability Zone 的计算节点过滤掉。

RamFilter

RamFilter 将不能满足 flavor 内存需求的计算节点过滤掉。 对于内存有一点需要注意： 为了提高系统的资源使用率，OpenStack 在计算节点可用内存时允许 overcommit，也就是可以超过实际内存大小。 超过的程度是通过 nova.conf 中 ram_allocation_ratio 这个参数来控制的，默认值为 1.5 ram_allocation_ratio = 1.5其含义是：如果计算节点的内存有 10GB，OpenStack 则会认为它有 15GB（10*1.5）的内存。

DiskFilter

DiskFilter 将不能满足 flavor 磁盘需求的计算节点过滤掉。 Disk 同样允许 overcommit，通过 nova.conf 中 disk_allocation_ratio 控制，默认值为 1 disk_allocation_ratio = 1.0

CoreFilter

CoreFilter 将不能满足 flavor vCPU 需求的计算节点过滤掉。 vCPU 同样允许 overcommit，通过 nova.conf 中 cpu_allocation_ratio 控制，默认值为 16 cpu_allocation_ratio = 16.0这意味着一个 8 vCPU 的计算节点，nova-scheduler 在调度时认为它有 128 个 vCPU。 需要提醒的是： nova-scheduler 默认使用的 filter 并没有包含 CoreFilter。 如果要用，可以将 CoreFilter 添加到 nova.conf 的 scheduler_default_filters 配置选项中。

ComputeFilter

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

ComputeCapabilitiesFilter

ComputeCapabilitiesFilter 根据计算节点的特性来筛选。 这个比较高级，我们举例说明。 例如我们的节点有 x86_64 和 ARM 架构的，如果想将 Instance 指定部署到 x86_64 架构的节点上，就可以利用到 ComputeCapabilitiesFilter。 还记得 flavor 中有个 Metadata 吗，Compute 的 Capabilitie s就在 Metadata中 指定。

“Compute Host Capabilities” 列出了所有可设置 Capabilities。

点击 “Architecture” 后面的 “+”，就可以在右边的列表中指定具体的架构。

配置好后，ComputeCapabilitiesFilter 在调度时只会筛选出 x86_64 的节点。 如果没有设置 Metadata，ComputeCapabilitiesFilter 不会起作用，所有节点都会通过筛选。

ImagePropertiesFilter

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

例如希望某个 image 只能运行在 kvm 的 hypervisor 上，可以通过 “Hypervisor Type” 属性来指定。

点击 “+”，然后在右边的列表中选择 “kvm”。

配置好后，ImagePropertiesFilter 在调度时只会筛选出 kvm 的节点。 如果没有设置 Image 的Metadata，ImagePropertiesFilter 不会起作用，所有节点都会通过筛选。

ServerGroupAntiAffinityFilter

ServerGroupAntiAffinityFilter 可以尽量将 Instance 分散部署到不同的节点上。 例如有 inst1，inst2 和 inst3 三个 instance，计算节点有 A,B 和 C。 为保证分散部署，进行如下操作： 创建一个 anti-affinity 策略的 server group “group-1”
nova server-group-create --policy anti-affinity group-1请注意，这里的 server group 其实是 instance group，并不是计算节点的 group。 依次创建 Instance，将inst1, inst2和inst3放到group-1中
nova boot --image IMAGE_ID --flavor 1 --hint group=group-1 inst1 nova boot --image IMAGE_ID --flavor 1 --hint group=group-1 inst2 nova boot --image IMAGE_ID --flavor 1 --hint group=group-1 inst3因为 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”
nova server-group-create --policy affinity group-2依次创建 instance，将 inst1, inst2 和 inst3 放到 group-2 中
nova boot --image IMAGE_ID --flavor 1 --hint group=group-2 inst1 nova boot --image IMAGE_ID --flavor 1 --hint group=group-2 inst2 nova boot --image IMAGE_ID --flavor 1 --hint group=group-2 inst3因为 group-2 的策略是 Affinity，调度时 ServerGroupAffinityFilter 会将 inst1, inst2 和 inst3 部署到同一个计算节点。 创建 instance 时如果没有指定 server group，ServerGroupAffinityFilter 会直接通过，不做任何过滤。

Weight

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

日志

是时候完整的回顾一下 nova-scheduler 的工作过程了。 整个过程都被记录到 nova-scheduler 的日志中。 比如当我们部署一个 instance 时 打开 nova-scheduler 的日志 /opt/stack/logs/n-sch.log（非 devstack 安装其日志在 /var/log/nova/scheduler.log）

日志显示初始有两个 host（在我们的实验环境中就是 devstack-controller 和 devstack-compute1），依次经过 9 个 filter 的过滤（RetryFilter, AvailabilityZoneFilter, RamFilter, DiskFilter, ComputeFilter, ComputeCapabilitiesFilter, ImagePropertiesFilter, ServerGroupAntiAffinityFilter, ServerGroupAffinityFilter），两个计算节点都通过了。 那么接下来就该 weight 了：

可以看到因为 devstack-controller 的空闲内存比 devstack-compute1 多（7466 > 3434），权重值更大（1.0 > 0.4599），最终选择 devstack-controller。 注：要显示 DEBUG 日志，需要在 /etc/nova/nova.conf 中打开 debug 选项 [DEFAULT] debug = Truenova-scheduler 就是这些内容了，稍微有些复杂哈（因为灵活嘛），大家这两天可以好好消化一下。