openstack 概述及组件间通信过程

概述

openstack有7大组件，分别是:horizon,keystone,nova,glance,neutron,cinder.
组件概述：

1. horizon 是openstack的UI操作平台。可以在可是界面操作openstack；
2. keystone是认证组件，负责用户的认证登陆，换取token，确认权限等；
3. nova是最核心组件，是OpenStack云中的计算组织控制器。支持OpenStack云中实例生命周期的所有活动都由Nova处理。在创建时，主要功能是创建虚拟机；
4. glance是镜像组件，主要作用是创建好虚机后向其提供镜像；
5. neutron是网络组件，负责创建虚拟网络给服务使用；
6. cinder是块存储，用于挂在一规定配额的存储空间给所起服务，也可以不挂载。此部分跟服务的生命周期无关，有自己独立的生命周期。
7. swift 是对象存储， 负责存储组件状态和资源使用情况。

一个服务必须除了cinder和swift以外的所有组件，才能正常创建。

各个组件调用流程

图中keystone贯穿整个流程，每个组件接受到请求时候 都会去keystone确定用户权限。只有得到肯定答复后才会执行请求。在正常情况下，首先会调用nova 创建虚机，虚机创建好发送请求去glance取得所需镜像，镜像导入成功后，请求neutron创建网络，此时相当于一个没有存储空间的计算机，类似于办公云桌面。接着从cinder获取对应的存储资源，“挂载”到服务。

此小结之针对整体流程，接下来会具体描述组件内部的运行过程。

openstack 组件间通过restful API 进行通信，组件内部通过rabbitMQ消息队列（基于RPC——remote procedures call ——基于AMQP——advanced message queuing protocol）进行通信

nova

nova主要组件： nova-api，nova-scheduler，nova-compute,nova-conductor。
内部通信流程：
horizon通过restful API 向nova组件传递创建服务所需要资源信息，nova-api 获取到请求后将资源信息存储到etcd中，并生产一个属于nova-api的publisher，将创建信息通过exchange发送到被nova-scheduler监听的消息队列（nova-scheduler message queue）中，nova-scheduler从消息队列中取出请求，并从etcd中取得各个服务器中剩余的cpu，gpu等资源，根据内部算法选举出一个计算节点服务器给服务提供所需的资源，并将选举出的服务器信息存储到 etcd中，此时 rabbitMQ又立即产生一个属于nova-scheduler 的publisher 通过exchange 将信息地址发送到一个新的消息队列，等待 nova-compute接收，nova-compute 接收到创建信息地址后，将地址发送到消息队列，等待nova-conductor（防止虚拟机被攻破后，通过nova-compute从数据库获取信息）接收，并通过restful API 从etcd中获取资源信息，返回（利用rabbitMQ）给nova-compute（将对应信息发送到对应组件 首先发送到glance获取虚拟机镜像，然后往neutron发送创建虚拟网络请求，接着通过cinder 获取块存储资源），最后所有下级组件获取信息都正常后，调用虚拟化驱动driver 去对应的服务器创建出虚拟机。

glance

glance主要组件：glance-sap(glance-registry版本2 合入API)。
内部通信流程：
nova组件通过restful API 向glance组件传递创建服务所需要的虚拟镜像名，cinder-api获取到请求后，镜像名发送到glance-registry，并从etcd中取得镜像信息，返回glance-api，再从数据库中获取镜像，并传递给nova。

neutron

neutron主要组件： neutron-server, neutron-plugin,neutron-agent(plugin的具体实现)。

1. Neutron-server可以理解为一个专门用来接收Neutron REST API调用的服务器，然后负责将不同的rest api分发到不同的neutron-plugin上。
2. Neutron-plugin可以理解为不同网络功能实现的入口，各个厂商可以开发自己的plugin。Neutron-plugin接收neutron-server分发过来的REST API，向neutron database完成一些信息的注册，然后将具体要执行的业务操作和参数通知给自身对应的neutronagent。
3. Neutron-agent可以直观地理解为neutron-plugin在设备上的代理，接收相应的neutron-plugin通知的业务操作和参数，并转换为具体的设备级操作，以指导设备的动作。当设备本地发生问题时，neutron-agent会将情况通知给neutron-plugin。
4. Neutron database，顾名思义就是Neutron的数据库，一些业务相关的参数都存在这里。
5. Network provider，即为实际执行功能的网络设备，一般为虚拟交换机（OVS或者Linux Bridge）
   内部通信流程：
   nova组件通过restful API 向neutron组件传递创建服务请求，neutron-server获取到请求后，生产一个属于neutron的publisher，将创建信息通过exchange发送到 rabbitmq中被neutron-plugin监听的消息队列中，neutron-plugin从消息队列中取出请求，并将需要的plugin信息存储到 etcd中，此时 rabbitMQ又立即产生一个属于neutron-plugin的publisher 通过exchange 将信息地址发送到一个新的消息队列，等待 neutron-agent接收，neutron-agent接收到信息地址后，通过restful API etcd中获取插件信息，创建网络。

cinder

cinder主要组件： cinder-api，cinder-scheduler，Cinder-volume。
内部通信流程：
nova组件通过restful API 向cinder组件传递创建服务请求，cinder-api获取到请求后，生产一个属于cinder-api的publisher，将创建信息通过exchange发送到 rabbitmq中被cinder-scheduler监听的消息队列（cinder-scheduler message queue）中，cinder-scheduler从消息队列中取出请求，并从etcd中取得各个服务器中剩余的块存储空间，根据内部算法选举出一个块存储服务器给服务提供所需的块存储资源，并将资源信息存储到 etcd中，此时 rabbitMQ又立即产生一个属于cinder-scheduler 的publisher 通过exchange 将信息地址发送到一个新的消息队列，等待 cinder-volume接受，cinder-volume 接收到创建信息地址后，通过restful API etcd中获取分配的资源信息，调用driver 去对应的块存储服务器中获取资源挂载到虚拟服务上。