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。

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

  # 以上3种endpoints 在网络上开放的权限一般也不同。Admin通常只能对内网开放，public通常可以对外网开放，internal通常只能对安装有openstack服务的机器开放；
  admin url----->面向admin用户 port:3557internal url ---->面向openstack内部组件间通信 port：5000public url----->大家都可以访问的api port:5000（与internal url 的端口相同绑定Ip不同）
  # 注意：用户的权限是根据角色赋予的，所以以上3中api能否调用成功是根据用户的角色决定的，只要有权限调用哪个api都可以，但是不要随便走这样配置会比较乱；

keystoneV3版新增概念

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

工作流程

1. 用户发送Credentials 给你 keystone，keystone返回1个temporary token（临时令牌） 和 1个 generic catalog（openstack中 Endpoint，也就是27个url）
2. 用户再次拿着 临时令牌再次请求keystone，向kestone索取所有项目列表；
3. 用户从项目列表中找到自己期望的项目发送给kestone，keystone颁发该项目的token给用户
4. 用户拿着Token 直接访问Endpoint
5. 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包含以下组件：

1. cinder-api：提供rest api接口，接收客户端请求分发给cinder-scheduler（承接业务的）
2. cinder-scheduler: 通过算法选出合适的cinder-volume， 通过rpc把cinder-api的任务调度分发给后端 cinder-volume （调度员）
3. 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类：

1. Direct Exchange根据Routing Key进行精确匹配，只有对应的 Message Queue 会接受到消息；
2. Topic Exchange根据Routing Key进行模式匹配，只要符合模式匹配的Message Queue都会收到消息；
3. 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这个“中间人”？

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

Nova的工作流程

1. Nova-api接收到创建虚拟机的请求，Nova-api把虚拟机创建详细信息存到Maria DB，Maria DB 把数据创建成后 响应Nova-api创建完成
2. Nova-api把创建虚拟机消息通过Exchange发到message queue中，Nova-scheduler从队列中获取消息
3. Nova-scheduler从数据库中获取计算节点信息（安装了Nova-compute软件的服务器）拿到信息后根据特定算法选择当前最佳创建虚拟机的计算节点
4. Nova-scheduler把创建虚拟机的任务Exchange发到message queue（连接当前最佳创建虚拟机的计算节点的队列）
5. 当前最佳创建虚拟机的compute接收到创建虚拟机请求，把消息放到消息队列，发送给Nova-condutor
6. Nova-condutor连接数据库查询到创建详细信息通过消息队列发送给compute
7. 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。

1. core-plugin：Neutron中即为ML2（Modular Layer 2）提供二层网络核心功能，其他网络设备厂商基于Core-plugin开发自己的 neutron-plugin；
2. 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配置文件种指定；

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

neutron的工作流程

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