文章目录
- 简单说说Nova
- Nova基本架构
- 前台：nova-api
- 经理：nova-scheduler
- 外勤：nova-compute
- 后勤：nova-conductor
- 实例创建具体流程
简单说说Nova
Nova是OpenStack最为核心的服务，负责管理OpenStack平台的计算资源，这也就意味着在OpenStack平台中实例的创建、移除和使用都是通过Nova来实现的。
OpenStack作为一个IaaS服务平台，最主要的服务就是为租户提供实例，实例就是OpenStack在虚拟化技术支持下为租户创建的虚拟机，而这一切都是靠Nova完成的。因此事实上Nova处于OpenStack架构的中心，其他的组件都在为Nova提供支持：
- glance为Nova提供image
- cinder和swift为Nova提供块存储和对象存储
- neutron为Nova提供虚拟网络
类似的还有很多，由此可见Nova的重要性。
Nova基本架构
OpenStack的服务组件开发大都遵循这样一个思路：不把鸡蛋放在一个篮子里。
每一个服务组件又分为若干个小的组件来协同工作，每一个小的组件都只负责一部分的服务内容，通过消息队列完成消息传递和互相配合，这样才是一个完整的服务。
现在我要把Nova比做一个工作室，工作室包括：前台、经理、外勤和后勤。nova也包括对应的组件，通过这种方式来理解nova每个组件在nova服务中起到什么作用。
前台：nova-api
工作室有前台，前台一般都处在工作室的门口，首先前台会向外界提供本工作室的位置，当客户按照这个位置信息来到工作室想委托一件事情，他看到的第一个人一定是前台。客户见到前台之后向前台提出请求，希望由工作室的某人为他完成一项工作，前台答应客户的请求。
这就说明了nova-api的作用：
- 向外界暴露若干HTTP的REST API接口
- 接受并响应客户的API调用
说是响应请求，那么具体是怎么相应的呢
nova-api会对接收到的HTTP API请求作出处理
- 检查客户端闯入的参数是否有效
- 调用Nova其他子服务处理客户端的请求
- 格式化Nova其他子服务返回的结果并返回给客户端
经理：nova-scheduler
当前台接到一个客户的订单后马上反馈给经理，经理得知后立刻开始统筹自己工作室现有的资源，开始规划怎样完成客户的订单，由哪个员工去做这件事，然后综合考虑每个员工的优缺点，选择一个最合适的员工。
nova-scheduler在Nova中就是这样一个角色，用户向api发出请求想要创建一个新的实例，scheduler需要决定在哪个计算节点上创建这个实例，具体决策的过程如下：
- 通过过滤器过滤符合条件的计算节点（剩余资源足够）
- 通过权重计算选择在最优节点上创建实例（其实是找剩余内存最大的节点）
外勤：nova-compute
外勤就是工作室真正干活的人，经理决定了由哪个外勤去执行这项任务后，该外勤就全权负责这项任务。
nova-compute就是这样的一个角色。它一般部署在计算节点，当scheduler决定由哪个计算机点创建实例后，compute就开始正式工作。
后勤：nova-conductor
工作室需要的办公用品一般会有一个人统一购买，这个人就是后勤。之所以把所有需要公费花钱的事情交给一个人，就是为了减少其他人在钱上出问题。
nova-conductor在nova中就是这么一个角色。nova-compute经常需要更新数据库，它总是对数据库进行增删改查，但是一个OpenStack平台包括那么多计算节点，每一个节点上都有一个nova-compute，如果让这么多nova -compute都去访问数据库，既不安全也不能保证架构的伸缩性，所以设计了一个专门的组件来负责访问数据库，这个组件就是nova-conductor。
实例创建具体流程
我们一般会把实例都创建在计算节点上，这样计算节点需要安装nova-compute，nova的其他组件需要安装在控制节点上；如果我们想把实例创建在控制节点，搭建一个all in one的测试环境，也可以把nova-compute安装在控制节点，所以说nova十分的灵活
部署好之后我们开始创建实例。
客户向nova-api发送请求：创建一个实例
nova-api对请求作出处理后，通过rabbitmq向nova-scheduler发送消息：创建一个实例
scheduler收到消息后，选择计算节点1来创建创建实例并通过rabbitmq向其发送消息
节点1上的nova-compute收到消息后，开始在本节点上创建实例
创建过程中nova-compute需要访问数据库，通过rabbitmq让nova-conductor访问数据库创建实例的核心步骤就是这些，当然实际的步骤远不止这些
界面或命令行通过RESTful API向keystone获取认证信息。
keystone通过用户请求认证信息，并生成auth-token返回给对应的认证请求。
界面或命令行通过RESTful API向nova-api发送一个boot instance的请求（携带auth-token）。
nova-api接受请求后向keystone发送认证请求，查看token是否为有效用户和token。
keystone验证token是否有效，如有效则返回有效的认证和对应的角色（注：有些操作需要有角色权限才能操作）。
通过认证后nova-api和数据库通讯。
初始化新建虚拟机的数据库记录。
nova-api通过rpc.call向nova-scheduler请求是否有创建虚拟机的资源(Host ID)。
nova-scheduler进程侦听消息队列，获取nova-api的请求。
nova-scheduler通过查询nova数据库中计算资源的情况，并通过调度算法计算符合虚拟机创建需要的主机。
对于有符合虚拟机创建的主机，nova-scheduler更新数据库中虚拟机对应的物理主机信息。
nova-scheduler通过rpc.cast向nova-compute发送对应的创建虚拟机请求的消息。
nova-compute会从对应的消息队列中获取创建虚拟机请求的消息。
nova-compute通过rpc.call向nova-conductor请求获取虚拟机消息。（Flavor）
nova-conductor从消息队队列中拿到nova-compute请求消息。
nova-conductor根据消息查询虚拟机对应的信息。
nova-conductor从数据库中获得虚拟机对应信息。
nova-conductor把虚拟机信息通过消息的方式发送到消息队列中。
nova-compute从对应的消息队列中获取虚拟机信息消息。
nova-compute通过keystone的RESTfull API拿到认证的token，并通过HTTP请求glance-api获取创建虚拟机所需要镜像。
glance-api向keystone认证token是否有效，并返回验证结果。
token验证通过，nova-compute获得虚拟机镜像信息(URL)。
nova-compute通过keystone的RESTfull API拿到认证k的token，并通过HTTP请求neutron-server获取创建虚拟机所需要的网络信息。
neutron-server向keystone认证token是否有效，并返回验证结果。
token验证通过，nova-compute获得虚拟机网络信息。
nova-compute通过keystone的RESTfull API拿到认证的token，并通过HTTP请求cinder-api获取创建虚拟机所需要的持久化存储信息。
cinder-api向keystone认证token是否有效，并返回验证结果。
token验证通过，nova-compute获得虚拟机持久化存储信息。
nova-compute根据instance的信息调用配置的虚拟化驱动来创建虚拟机。
