OpenStack学习笔记之-Nova组件深入了解
视频了解：
nova组件是用来建虚拟机的（功能：负责响应虚拟机创建请求、调度、销毁云主机）
nova主要组成：
nova-api:负责接收外部的rest api的请求
nova-scheduler：负责调度（相当于nova-api的秘书）
nova-compute：负责具体的去调相关的虚拟化驱动
nova-conductor：帮助nova-computer查看数据库，然后将消息通过message queue传给nova-computer
为什么查看数据库时要借助nova-conductor而不是nova-computer直接查？
1、基于安全考虑：一旦虚拟机被攻破了，就会通过nova-computer拿到虚拟机相关信息
2、基于数据库压力考虑：nova-computer有很多个，可以同时建很多虚拟机出来，多个nova-computer同时访问数据库会对数据库造成压力
书籍了解：
初步认识Nova：
是OpenStack的计算组件，控制着一个个虚拟机的状态变迁与生老病死，管理着它们的资源分配。在OpenStack项目中扮演者最为核心的角色。
现在的Nova只专注于提供统一的计算资源抽象，这些计算资源可以是物理机、虚拟机，甚至是容器。
Nova体系结构：
Nova由多个提供不同功能的组件组成，对外通过REST API通信，对内通过RPC进行通信，使用DB数据库来存储数据
Nova主要由API、 Compute、 Conductor、 Scheduler 4个核心组件所组成，它们之间通过RPC进行通信。
API：是进入Nova的HTTP接口，可以通过部署多个来实现横向扩展。
1、API依据请求是长时任务或者是短时任务，将请求发送给Conductor或者Compute。
2、长时任务请求发送到Conductor
Conductor：负责对其全程跟踪和调度。
1、对于新建虚拟机或者迁移类需要调度的请求，Conductor会向Scheduler请求一台符合要求的计算节点，然后将请求最终发送到合适的计算节点上。
2、除了长时任务还负责代理其他节点的DB访问。（这主要是为了安全问题和实现在线升级功能）
3、最后对于虚拟机操作的请求都会发送到Compute组件
Compute：负责与Hypervisor进行通信，实现虚拟机的生命周期管理。
1、对各个Hypervisor的支持通过 Virt Driver 框架来实现
以创建虚拟机为例，Nova组件内部执行流程：
1、首先用户执行novaclient提供的用于创建虚拟机的命令。
2、API服务监听到novaclient发送的HTTP请求并且API将它转换到AMQP消息
3、通过消息队列(Queue)调用Conductor服务，Conductor服务通过消息队列接收任务后，做一些准备工作（如汇总虚拟机参数等）
4、再通过消息队列告诉Scheduler去选择一个满足虚拟机创建要求的主机
5、Conductor拿到Scheduler提供的目标主机之后，会去要求Compute服务创建虚拟机
6、Compute与Hypervisor进行通信
ps：并不是所有的业务流程都像上面那样，对于一些短时任务，如删除虚拟机，不需要Scheduler服务，API通过消息队列告诉Compute删除指定虚拟机，Compute通过Conductor更新数据库即完成业务流程。
Nova内部详细服务：
1、nova-all：用于启动所有Nova服务的辅助脚本，其中API服务作为WSGI服务器启动
2、nova-api：对外提供的REST API服务，目前提供两种API服务，nova-api-metadata和nova-api-os-compute。nova-api根据配置文件/eyc//nova/nova.conf的enable_apis选项设置启动这两种服务
3、nova-api-metadata：接受虚拟机实例metadata（元数据）相关的请求。目前这部分工作由Neturon完成（只有在多计算节点部署，并且使用nova-network的情况下才使用nova-api-metadata API服务）。
4、nova-api-os-compute：OpenStack API服务。
5、nova-cells:Cell模块允许用户在不影响现有的OpenStack云环境的前提下，增强横向扩展、大规模部署能力。Cell模块启用后，OpenStack云环境中的主机被划分成组（成为Cell）。noval-cells负责各个Cell之间的通信，以及为一个新的虚拟机实例选择合适的Cell(因此每个Cell都需要运行nova-cells服务)
6、nova-cert：管理X509证书。
7、nova-compute：Compute服务
8、nova-conductor：Conductor服务
9、nova-consol：允许用户通过代理访问虚拟机实例的控制台。ps:在G版本中被nova-xvncproxy取代
10、nova-novncproxy: Nova提供了 novncproxy代理支持用户通过vnc访问虚拟机。提供完整的vnc访问功能，涉及几个Nova服务（nova-consoleauth提供认证授权， nova-novncproxy用于支持基于浏览器的vnc客户端，nova-xvpvncproxy用于支持基于Java的vnc客户端。）
11、nova-dhcpbridge：管理 nova-network 的 DHCP bridge
12、nova-manage：提供很多与Nova的维护和管理相关的功能，比如用户创建等。
13、nova-network：提供网络服务，己经被Neutron所取代（现只有在使用Devstack部署 OpenStack时才会使用 nova-network）
14、nova-rootwrap：用于在OpenStack运行过程中以root身份运行某些shell命令。
15、nova-scheduler： Scheduler 服务。
Nova中各个服务之间的通信使用了基于AMQP实现的RPC机制，其中nova-compute、 nova-conductor 和 nova-scheduler 在启动时都会注册一个 RPC Server,而 nova-api 因为Nova内部并没有服务会调用它提供的接口，所以无需注册。
Nova API:
1、Nova API是访问并使用Nova所提供的各种服务的公共接口。是作为客户端和Nova之间的中间层。Nova API把客户端的请求传给Nova，待Nova处理完成请求后再将处理结构返回给客户端。
2、Nova v2 API是Nova诞生就存在的API，一直是用Extension作为扩展API的机制。Extension机制本身也并不符合OpenStack的 发展。随着越来越多的OpenStack部署，不同的OpenStack部署通过Extension机制来扩展或者裁剪API,这导致OpenStack完全失去了互操作性。没有正确地处理错误的机制，这导致有些DB层差异被暴露在RESTful API 当中，同样损害了 OpenStack的互操作性。
3、Nova v2.1 API改进了错误处理方式，覆盖掉了不同DB之间的差异。其中最重要的是它引入了一个新的机制Microversion来扩展Nova API。从此Extension在v2.1API中将彻底被删除，最终OpenStack将拥有一个统一的API来实现互操作性。
4、Microversion是单调递增的，表现为X.Y的形式。X只有在非常重大的改变并影响 了整个API才会变化（实际上这种情况会很少发生），而其他任何API的改变都需要改变Y, 无论是API的请求，返回或是语义改变。只有bug才不需要Microversion的变化
5、任何Nova API的改变都需要提交nova-specs,需要严格的review以防止未预期的改变破坏API的兼容性。
6、系统拥有一个最小版本和最大版本号，只要请求在这个范围之内都会被接受。最小和最大版本号可通过version API来查询。
7、Nova API是基于WSGI实现的。nova/api/openstack/下包含着WSGI基础架构的代码，其 中包含一些Nova WSGI stack中所需要的middleware,以及如何解析请求与分发请求的核心代码。