openstack核心组件及运行流程

OpenStack的核心组件

整个OpenStack架构由多个子服务组成：以下是几个核心项目

服务	项目	简要	描述
Compute 计算服务	Nova	负责创建，调度，销毁云主机	负责实例生命周期的管理，计算资源的单位。对Hypervisor（又称虚拟机监视器（英语：virtual machine monitor，缩写为 VMM），是用来建立与执行虚拟机器的软件、固件或硬件。）进行屏蔽，支持多种虚拟化技术(红帽默认为KVM),支持横向扩展 负责创建，调度，销毁云主机
Network 网络服务	Neutron	负责实现SDN	负责虚拟网络的管理，为实例创建网络的拓扑结构。是面向租户的网络管理，可以自己定义自己的网络，各个租户之间互不影响
Identify 身份认证服务	Keystone	为访问openstack各组件提供认证和授权功能，认证通过后，提供一个服务列表（存放你有权访问的服务），可以通过该列表访问各个组件	类似于LDAP服务，对用户、租户和角色、服务进行认证与授权，且支持多认证机制
Dashboard 控制面板服务	Horizon	就是web展示界面操作平台，方便用户交互的	提供一个Web管理界面，与OpenStack底层服务进行交互
Image Service 镜像服务	Glance	提供镜像服务，装机使用	提供虚拟机镜像模板的注册与管理，将做好的操作系统拷贝为镜像模板，在创建虚拟机时直接使用，可支持多格式的镜像
Block Storage 块存储服务	Cinder	提供持久化块存储，即为云主机提供附加云盘	负责为运行实例提供持久的块存储设备，可进行方便的扩展，按需付费，支持多种后端存储
Object Storage 对象存储服务	Swift	目录结构存储数据	为OpenStack提供基于云的弹性存储，支持集群无单点故障
Telemetry 计量服务	Ceilometer	很明显自用的根本不需要这功能，而且所谓的监控其实根本也算不上什么监控，监控性能，计费	用于度量、监控和控制数据资源的集中来源，为OpenStack用户提供记账途径

Heat（编排）	这个太高大上了，就目前阶段正常企业还搞不定	自动化部署应用，自动化管理应用的整个生命周期.主要用于Paas

拓展

hypervisor：一种运行在物理服务器和操作系统之间的中间层软件，可以允许多个操作系统和应用共享一套基础物理硬件。可以将hypervisor看做是虚拟环境中的“元”操作系统，可以协调访问服务器上的所有物理设备和虚拟机，所以又称为虚拟机监视器（virtual machine monitor）。hypervisor是所有虚拟化技术的核心，非中断的支持多工作负载迁移是hypervisor的基本功能。当服务器启动并执行hypervisor时，会给每一台虚拟机分配适量的内存，cpu，网络和磁盘资源，并且加载所有虚拟机的客户操作系统。

横向扩展：多增加几台API服务器，一起服务。横向扩展也叫水平扩展，用更多的节点支撑更大量的请求。 如成千上万的蚂蚁完成一项搬运工作
纵向扩展：把API服务器换成性能更好的机器。纵向扩展又叫垂直扩展，扩展一个点的能力支撑更大的请求。如利用1个人的能力，如蜘蛛侠逼停火车

openstack架构

OpenStack作为开源、可扩展、富有弹性的云操作系统，其设计基本原则如下:

• 按照不同的功能和通用性划分不同项目，拆分子系统
• 按照逻辑计划、规范字系统之间的通信
• 通过分层设计整个系统架构
• 不同的功能子系统间提供统一的API接口

OpenStack 概念架构

核心为虚拟机，所有组件围绕虚拟机，为它提供服务。可将上图的架构分为三个部分：

• 蓝色方框为全局组件：
  keystone：为所有服务模块提供认证与授权
  ceilometer：度量、监控所有数据资源
  horizon ：UI平台管理，提供一个web管理页面，与底层交互

• 红色方框为外部辅助组件：
  ironic 提供裸金属环境（没有操作系统的计算机硬件，简称裸机）
  trove 提供管理数据库服务（控制关系型和非关系型数据库）
  heat，sahara 提供对数据管理和编排

• 黄色方框为内部核心组件：
  glance：提供镜像服务
  neutron：提供网络服务
  swift：提供对象存储资源
  cinder：提供快存储资源
  nova：管理实例的生命周期，并负责调取以上四个资源给虚拟机使用。

具体流程

云平台用户在经过Keystone服务认证授权后，通过Horizon或者Reset API模式创建虚拟机服务，创建过程中包括利用Nova服务创建虚拟机实例，虚拟机实例采用Glance提供镜像服务，然后使用Neutron为新建的虚拟机分配IP地址,并将其纳入虚拟网络中，之后在通过Cinder创建的卷为虚拟机挂载存储块,整个过程都在Ceilometer模块资源的监控下，Cinder产生的卷(Volume)和Glance提供的镜像(Image) 可以通过Swift的对象存储机制进行保存。

详细解释一下openstack运行流程（每一步完成后去验证的过程省略了）

看到这张图不要怕，一步一步分析
MQ（Message Queue）消息队列
是基础数据结构中“先进先出”的一种数据结构。一般用来解决应用解耦，异步消息，流量削峰等问题，实现高性能，高可用，可伸缩和最终一致性架构。
常用的三种类型，包括rabbitmq、 rocketmq、kafka，是两个独立的服务之间，消息传递的载体，解决消息在传输是请求的高并发问题，会以容器的方式，存储消息列表（包括请求、交互、报文），划分重要等级放入队列中，逐个处理，处理完的会自动删除。
Token
服务端生成的一串字符串，以作客户端进行请求的一个令牌，当第一次登录后，服务器生成一个Token便将此Token返回给客户端，以后客户端只需带上这个Token前来请求数据即可，无需再次带上用户名和密码。

1. 登录界面或命令行通过RESTful API（接口，此接口是整个 Nova 组件的门户，接收和响应客户的 API
   调用）向keystone获取认证信息。
2. keystone通过用户请求认证信息，并生成auth-token（认证令牌）返回给对应的认证请求。
3. 界面或命令行通过RESTful API向nova-api发送一个boot instance（启动实例）的请求（携带auth-token）。
4. nova-api接受请求后向keystone发送认证请求，查看token是否为有效用户和token。
5. keystone验证token是否有效，如有效则返回有效的认证和对应的角色（注：有些操作需要有角色权限才能操作）。
6. 通过认证后nova-api和数据库通讯。
7. 初始化新建虚拟机的数据库记录。
8. nova-api通过rpc.call（远程过程调用）向nova-scheduler（虚机调度服务，负责决定在哪个计算节点上运行虚机）请求是否有创建虚拟机的资源(Host
   ID)。
9. nova-scheduler进程侦听消息队列，获取nova-api的请求。
10. nova-scheduler通过查询nova数据库中计算资源的情况，并通过调度算法计算符合虚拟机创建需要的主机。
11. 对于有符合虚拟机创建的主机，nova-scheduler更新数据库中虚拟机对应的物理主机信息。
12. nova-scheduler通过rpc.cast（远程创建）向nova-compute（管理虚机的核心服务，在计算节点上运行。通过调用Hypervisor API实现节点上的 instance（实例）的生命周期管理）发送对应的创建虚拟机请求的消息。
13. nova-compute会从对应的消息队列中获取创建虚拟机请求的消息。
14. nova-compute通过rpc.call向nova-conductor（经常需要更新数据库，比如更新和获取虚机的状态。
    出于安全性和伸缩性的考虑，nova-compute 并不会直接访问数据库，而是将这个任务委托给
    nova-conductor）请求获取虚拟机消息。
15. nova-conductor从消息队队列中拿到nova-compute请求消息。
16. nova-conductor根据消息查询虚拟机对应的信息。
17. nova-conductor从数据库中获得虚拟机对应信息。
18. nova-conductor把虚拟机信息通过消息的方式发送到消息队列中。
19. nova-compute从对应的消息队列中获取虚拟机信息消息。
20. nova-compute通过keystone的RESTfull
    API拿到认证的token，并通过HTTP请求glance-api（镜像组件接口）获取创建虚拟机所需要镜像。
21. glance-api向keystone认证token是否有效，并返回验证结果。
22. token验证通过，nova-compute获得虚拟机镜像信息(URL)。
23. nova-compute通过keystone的RESTfull
    API拿到认证的token，并通过HTTP请求neutron-server获取创建虚拟机所需要的网络信息。
24. neutron-server向keystone认证token是否有效，并返回验证结果。
25. token验证通过，nova-compute获得虚拟机网络信息。
26. nova-compute通过keystone的RESTfull
    API拿到认证的token，并通过HTTP请求cinder-api（块存储接口）获取创建虚拟机所需要的持久化存储信息。
27. cinder-api向keystone认证token是否有效，并返回验证结果。
28. token验证通过，nova-compute获得虚拟机持久化存储信息。
29. nova-compute根据instance的信息调用配置的虚拟化驱动来创建虚拟机。

OpenStack 逻辑架构

看到这里可能有点抽象，结合上下图，可以更好的理解openstack的流程

全局架构来看： OpenStack包括相互独立的服务组件。所有服务均可通过一个公共身份服务进行身份验证。除了那些需要管理权限的命令，每个服务之间均可通过公共API进行交互。所以，API即是每个服务内部和外部的交界处，隔离了内外。

服务之间交互过程： 每个服务又由若干组件组成，包含多个进程。每个服务至少有一个API进程，用于侦听API请求，对这些请求进行预处理，（ 预处理就是将请求暴露出来的API接口，给keystone进行认证，如果认证通过，则放入队列等待被处理。） 然后将它们传送到自己服务后端的其他组件，对请求进行处理，而不是API进程去处理。也就是说除了认证服务，实际工作都是由具体的进程完成的。

服务内各个进程之间的通信： 使用AMQP（一个提供统一消息服务的应用层标准高级消息队列协议，是应用层协议的一个开放标准，为面向消息的中间件设计。）消息代理，将不同的消息格式进行转换，能够统一处理。服务的状态存储在数据库中。

OpenStack组件通信关系：

• 基于AMQP协议的通信
  用于每个项目内部各个组件之间的通信。
• 基于SQL的通信
  用于各个项目内部的数据库通信。
• 基于HTTP协议进行通信
  通过各项目的API建立的通信关系，API都是RESTful Web API。
• 通过Native API实现通信
  OpenStack各组件和第三方软硬件之间的通信。