OpenStake组件

KeyStone组件

openstack组件间的协同工作是通过rest api调用完成的，既然组件间需要相互调用API，那么安全认证是无法避免的对吧？

keystone的主要功能是分发各组件的endpoint并为组件之间的api调用提供认证服务；

User: 指使用了openstack 服务的对象
Project(Tenant): 在openstack资源池，划分一个逻辑资源称之为1个项目
Role: 用于权限的划分，user关联了role，使user拥有不同的权限
Policy: 默认就是1个/etc/keystone/policy.json的文件，定义角色包含的权限
Tocken: 认证完毕之后发放的令牌
Credentials: 用于确认用户的身份
Authentication: 认证过程（从普通用户拿到token的认证过程）
Service: openstack中各个组件提供的服务

Endpoint: 在openstack中，每一个service(Nova/Glance/Newtron)都有三种不同的 web api end points. Admin, public, internal。

Admin是用作管理用途的，如它能够修改user/tenant(project)。
public 是让客户调用的，比如可以部署在外网上让客户可以管理自己的云。
internal是openstack内部调用的。

# 以上3种endpoints 在网络上开放的权限一般也不同。Admin通常只能对内网开放，public通常可以对外网开放，internal通常只能对安装有openstack服务的机器开放；
admin url----->面向admin用户 port:3557

internal url ---->面向openstack内部组件间通信 port：5000

public url----->大家都可以访问的api port:5000（与internal url 的端口相同绑定Ip不同）
# 注意：用户的权限是根据角色赋予的，所以以上3中api能否调用成功是根据用户的角色决定的，只要有权限调用哪个api都可以，但是不要随便走这样配置会比较乱；

keystoneV3版新增概念

Tenant 重命名为 Project
添加了 Domain 的概念：domain包含多个project
添加了 Group 的概念：把N个用户加入1个组方便管理

工作流程

用户发送Credentials 给你 keystone，keystone返回1个temporary token（临时令牌）和 1个 generic catalog（openstack中 Endpoint，也就是27个url）
用户再次拿着临时令牌再次请求keystone，向kestone索取所有项目列表；
用户从项目列表中找到自己期望的项目发送给kestone，keystone颁发该项目的token给用户
用户拿着Token 直接访问Endpoint
Endpoint所在的service去和kestone验证该token是否正确、过期？如果正确和未过期endpoint则向该用户提供服务

Clance组建

glance组件主要提供镜像服务，架构分为glance-api 和glance-registry。

glance-api负责接收客户端组件（Nova..）的 api请求，分发给glance registry

glance-registry去Maria DB中检索镜像元数据，把镜像的信息返回glance api

glance api 根据glance registry返回的镜像元数据，去存储后端拉取相应的镜像，响应给客户端

ps：

注: glance内部组件（glance-api、glance-registry）间的通信不使用消息队列，所以在glance的配置文件中配置消息队列的socket是画蛇添足；

Cinder组件

"cinder主要提供块存储功能"

cinder包含以下组件：

cinder-api：提供rest api接口，接收客户端请求分发给cinder-scheduler（承接业务的）
cinder-scheduler: 通过算法选出合适的cinder-volume，通过rpc把cinder-api的任务调度分发给后端 cinder-volume （调度员）
cinder-volume：负责处理具体的volume请求，由不同后端存储提供 volume 存储空间。目前各大存储厂商已经积极地将存储产品的 driver 贡献到 cinder 社区（具体干活的）

RPC机制

openstack组件间通信: 调用各组件api提供的rest接口

组件内通信:基于rpc(远程过程调用)机制，而rpc机制是基于AMQP模型实现的

从rpc使用的角度出发，nova，neutron，和cinder的流程是相似的，以cinder为例阐述rpc机制：

Openstack 组件内部的 RPC（Remote Producer Call）机制的实现是基于 AMQP协议(Advanced Message Queuing Protocol)作为通讯模型，从而满足组件内部架构的松耦合性。

AMQP是用于异步消息通讯的消息中间件协议，AMQP 模型有四个重要的角色:

Exchange: 根据 Routing key 转发消息到对应的 Message Queue 中（路由器）
Routing key: 用于 Exchange 判断哪些消息需要发送对应的 Message Queue（路由表）
Publisher: 消息的生产者者，publish把消息发送到Exchange，并指明Routing key，以保证消息队列（Message Queue）可以接收到消息（服务端）
Customer: 消息的消费者/接受者，从消息队列（Message Queue）中取出消息（客户端）

Publisher可以分为4类：

Direct Publisher发送点对点的消息；（发送1对1消息）
Topic Publisher采用“发布——订阅”模式发送消息；（发送组播）
Fanout Publisher发送广播消息的发送；（发送广播）
Notify Publisher同Topic Publisher，发送 Notification 相关的消息。

Exchange可以分为3类：

Direct Exchange根据Routing Key进行精确匹配，只有对应的 Message Queue 会接受到消息；
Topic Exchange根据Routing Key进行模式匹配，只要符合模式匹配的Message Queue都会收到消息；
Fanout Exchange将消息转发给所有绑定的Message Queue。

cinder的工作流程

虚拟机要使用存储资源，于是通过Nova rest full api 调用cinder api
cinder api 把任务通过Exchange 扔进消息队列1，cinder scheduler从消息队列1拿到到任务
cinder shcheduler 去MariaDB获取所有cinder volume信息通过算法选择出1个最佳的cinder-volume（存储节点）
cinder shcheduler反转为Publisher通过Exchange 把任务扔进消息队列2，最佳cinder-volume（存储节点）从消息队列2拿到到存储任务
volume-backen存储节点（没有存储数据的功能），存储节点只是调用后端真实的存储设备，创建出一块设备；

ps: volume-backen存储节点只是在云主机创建时，只是帮助其调用后端真实存储，开辟一块存储空间，让云主机使用，开辟完成之后，云主机和这块块设备完成挂载；

Nova组件

"没有虚拟机就没有云计算，Nova是通过调用hypervisor 创建出虚拟机"

nova主要组成:

nova-api：接收客户请求（控制节点1）
nova-scheduler：调度nova-api下发的请求，通过算法选择出最适合创建当前虚拟机的计算节点
nova-compute：通过调用 hypervisor创建出虚拟机（计算节点N）
nova-conductor：nova-compute通过 nova-conductor连接MariaDB

为什么会有nova-conductor这个“中间人”？

Nova-computer 众多他们都要去数据库中获取Nova-api在数据库里存放的虚拟机创建信息，容易给数据库造成压力（性能考量）
Nova-compyte被攻破了后，黑客直接通过Nova-compute 从Maria DB中窃取虚拟机信息（安全考量）

Nova的工作流程

Nova-api接收到创建虚拟机的请求，Nova-api把虚拟机创建详细信息存到Maria DB，Maria DB 把数据创建成后响应Nova-api创建完成
Nova-api把创建虚拟机消息通过Exchange发到message queue中，Nova-scheduler从队列中获取消息
Nova-scheduler从数据库中获取计算节点信息（安装了Nova-compute软件的服务器）拿到信息后根据特定算法选择当前最佳创建虚拟机的计算节点
Nova-scheduler把创建虚拟机的任务Exchange发到message queue（连接当前最佳创建虚拟机的计算节点的队列）
当前最佳创建虚拟机的compute接收到创建虚拟机请求，把消息放到消息队列，发送给Nova-condutor
Nova-condutor连接数据库查询到创建详细信息通过消息队列发送给compute
nova-compute调用hypervisor开始创建虚拟机......开始要网络、要镜像.....

Neutron组件

neutron组件包含：

neutron-server：专门接收客户端rest full api请求，然后将不同的rest full api请求分发到不同的neutron-plugin上
neutron-plugin：neuton是提供网络资源的，在现实世界中会有很多网络设备厂商，而neutron-plugin就是各厂商通过plugin插件的形式把自己的网络设备的功能通过软件的实现
neutron-agent：和newtron-plugin对应为neutron-plugin实现功能

neutron-plugin分类

openstack刚刚兴起的时候每个网络设备厂商思科、思杰等都开发自己网络设备的插件集成到openstack，其实每个网络设备厂商开发的功能是差不多的，只是开发标准不一样，这就有一个反复造轮子、代码冗余的问题，针对这些问题 newtron-plugin一分为2。

core-plugin：Neutron中即为ML2（Modular Layer 2）提供二层网络核心功能，其他网络设备厂商基于Core-plugin开发自己的 neutron-plugin；
service-plugin：即为除core-plugin以外其它的plugin，包括三层网络router、firewall、loadbalancer、×××、metering等等，主要实现L3-L7的网络服务。这些plugin要操作的资源比较丰富，对这些资源进行操作的REST API被neutron-server看作Extension API，需要厂家自行进行扩展。

core-plugin ML2核心插件

ML2插件包括Type和Mechanism2部分，这2部分又都分为Manager和Driver；

所以我们要使用什么网络模式就去ML2配置文件种指定；

neutron-server和各neutron-plugin部署在控制节点或者网络节点上（接收Nova 发送的api请求）
neutron agent则部署在网络节点上和计算节点上（具体实现网络功能，安装一堆交换机、路由器、VPN等Agent）

neutron的工作流程

neutron-server接收Nova创建网络的请求，neutron-server根据Nova创建虚拟机的请求分析出哪个neutron-plugin可以干活，通过消息队列发送给该neutron-plugin；
neutron-plugin接收到需求之后又通过消息队列把需求发送给neutron-agent
neutron-agent复杂具体网络创建工作