3 openstack -- Nova
openstack -- Nova
一、The origin of the Nova
--- openstack 是由 rackspace 和 NASA 共同开发的云计算平台
--- 类似于 Amazon EC2 和 S3 的云基础架构服务
--- nava 在openstack 中提供计算服务
二、what is nova?
--- Nova 是 openstack 云中的计算组织控制器
--- 支持 openstack 云中 instance 生命周期的所有活动都由 Nova 处理
--- 是一个负责管理计算资源、网络、认证、所需可扩展性的平台
--- 但是 Nova 自身没有提供任何虚拟化能力，相反它使用 libvirt API 来与被支持的 Hypervisors 交互
--- Nova 通过一个与 Amazon Web Services（AWS）EC2 API 兼容的 web services API 来对外提供服务
三、Nova 功能与特点
--- 实例生命周期管理
--- 管理计算资源
--- 网络和认证管理
--- REST风格的API
--- 异步的一致性通信
--- Hypervisor透明：支持Xen,XenServer/XCP, KVM, UML, VMware vSphere and Hyper-V
四、Nova in openstack
五、Nova framework
六、Nova core module
1、nova 组件组成：
nova - api
nova - scheduler
nova - compute
nova - conductor
hypervisor
nova - console
nova - consoleauth
nova - cert
database
message - queue
2、nova 组件功能概述
***** API *****
1）、nova - api
-- API Server对外提供一个与云基础设施交互的接口，也是外部可用于管理基础设施的唯一组件
-- 负责发起相应的类似运行instance（虚拟机实例）这样的资源调度活动
-- 两种 API 选择：EC2 API 通过 web services && openstack API
-- API server 通过 message queue 轮流与云基础设施的相关组件通信
-- 在实现层面上，nova API 是 python 实现的 WSGI
-- nova 接收的请求：简单的说，只要是跟虚拟机生命周期相关的操作，nova-api 都可以响应。
***** Core *****
2）、nova - scheduler
-- 调度器 Scheduler 把 nova-API 调用映射为 OpenStack 组件
-- 调度器作为一个称为 nova-schedule 守护进程运行，通过恰当的调度算法从可用资源池获得一个计算服务
-- Scheduler 会根据诸如负载、内存、可用域的物理距离、CPU 构架等作出调度决定，openstack 将这些需求定义在 flavor 中，用户只需要指定用哪个 flavor 就可以啦
-- nova scheduler 实现了一个可插入式的结构
-- 调度算法：随机算法 && 可用域算法 && 简单算法
-- scheduler 的具体实现方式，还没弄懂 # http://www.cnblogs.com/CloudMan6/p/5441782.html
3）、nova - compute
-- nova compute 处理管理实例生命周期，负责对虚拟机实例进行创建，终止，迁移，resize的操作
4）、nova - conductor
-- 调度nova-compute服务和数据库的交互。避免nova-compute服务对云数据库的直接访问。
-- nova-conductor模块可以水平扩展。但是，不要把它部署在nova-compute服务所运行的节点上。
-- 所有的 nova 服务使用一个 AMQP 来相互沟通。nova-compute 需要经常访问DB。
nova-conductor 是一个在 nova-compute 上的一个层次，避免数据库被暴露，最好把 nova-conductor 和 nova-compute 不要安装到一个节点上
-- 优点：更高的系统安全性，更好的系统伸缩性
从 G 版本开始，Nova 引入了一个新服务 nova-conductor，将 nova-compute 访问数据库的全部操作都放到 nova-conductor 中，而且 nova-conductor 是部署在控制节点上的。
这样就避免了 nova-compute 直接访问数据库，增加了系统的安全性。
nova-compute 与 conductor 是通过消息中间件交互的。 这种松散的架构允许配置多个 nova-conductor 实例。
5）、hypervisor
-- 计算节点上跑的虚拟化管理程序，虚机管理最底层的程序
***** Console Interface *****
6）、nova - console
-- 用户可以通过多种方式访问虚机的控制台：
-- nova-novncproxy，基于 Web 浏览器的 VNC 访问
-- nova-spicehtml5proxy，基于 HTML5 浏览器的 SPICE 访问
-- nova-xvpnvncproxy，基于 Java 客户端的 VNC 访问
7）、nova - consoleauth
-- 负责对访问虚机控制台请求提供 Token 认证
8）、nova - cert
-- 提供 x509 证书支持
***** Database *****
9）、database
***** Message Queue *****
10）、message - queue
-- Nova 包含众多的子服务，这些子服务之间需要相互协调和通信。 为解耦各个子服务，Nova 通过 Message Queue 作为子服务的信息中转站
-- 这里需要知道为什么？
程序之间的调用通常分两种：同步调用和异步调用。
同步调用
API 直接调用 Scheduler 的接口就是同步调用。 其特点是 API 发出请求后需要一直等待，直到 Scheduler 完成对 Compute 的调度，将结果返回给 API 后 API 才能够继续做后面的工作。
异步调用
API 通过 Messaging 间接调用 Scheduler 就是异步调用。 其特点是 API 发出请求后不需要等待，直接返回，继续做后面的工作。 Scheduler 从 Messaging 接收到请求后执行调度操作，完成后将结果也通过 Messaging 发送给 API。
在 OpenStack 这类分布式系统中，通常采用异步调用的方式，其好处是：
# 解耦各子服务 子服务不需要知道其他服务在哪里运行，只需要发送消息给 Messaging 就能完成调用。
# 提高性能 异步调用使得调用者无需等待结果返回。这样可以继续执行更多的工作，提高系统总的吞吐量。
# 提高伸缩性 子服务可以根据需要进行扩展，启动更多的实例处理更多的请求，在提高可用性的同时也提高了整个系统的伸缩性。而且这种变化不会影响到其他子服务，也就是说变化对别人是透明的。
七、从虚机创建流程看 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 内部组件的交互
八、nova 的 drive 架构
九、Nova 与openstack其他组件之间的交互
