OpenStack各组件逻辑关系、通讯部署关系及工做流程

1、 OpenStack组件之间的逻辑关系

OpenStack 是一个不断发展的系统，因此 OpenStack 的架构是演进的，举个例子：

• E 版本有5个组件 

Compute 是 Nova；Image 是 Glance，为 Nova 提供镜像存储服务；Object 是提供 Object 存储服务的 Swift；Dashboard 是咱们平时说的 Horizon；Identity 是 Keystone；

• F版本有7各组件，核心组件：

有这七个组件能够搭出一个相对完整的云计算环境，Heat、Sahala 是可选的；相对 E 版本，新增长的两个组件分别是 Block Storage Cinder 和 Network Neutron，这两个组件和 Glance，Swift 之间没有直接的联系，其实是从 Compute Network 和 Compute Volume 发展出来的，Neutron 组件并无直接的去替换 Compute Network，它是一个相对独立的，也是很是著名的 SDN 的一个项目，它为 Compute 提供网络链接，提供网络的资源管理这样一些服务，Block Storage（也就是 Cinder）为 Compute 提供块存储服务，替换了 Compute Volume.

 2、OpenStack的API

OpenStack 的逻辑关系是要各个组件之间的信息传输来实现的，而组件之间的信息传输主要是经过OpenStack 之间相互调用 API 来实现的，做为一个操做系统，做为一个框架，它的 API 有着重要的意义。

基于 HTTP 协议，RESTful Web API；

什么是 REST？

全称是：Representational State Transfer，表现状态传输。由 Fielding 博士（HTTP 协议的1.0 和 1.1 版本的主要设计者，Apache 服务器软件的做者之一，Apache 基金会的第一任主席）提出。REST 是经过操做资源的表现来操做资源的状态。

另一种 Web 服务接口协议是 SOAP。

二者的区别，RESTful Web API 的调用很是简单，可是咱们平时编程的时候用 SOAP 多是基于一些框架在去作，.Net，Java 的这些都已经很成熟了，咱们感觉不到底层机制的这种复杂性，而 REST 其实和 SOAP 比起来很是之简洁的，另一方面，REST 描述的是一种风格一种架构一种原则，因此它并无规定具体的实践方式或者说协议。
目前最多见的实现方式就是基于 HTTP 协议实现的 RESTful Web API，咱们的 OpenStack 里面用的就是这种方式。REST 架构里面对资源的操做，包括：获取、建立、修改和删除，正好对应着 HTTP 协议提供的 GET、POST、PUT 和 DELETE 方法，因此用 HTTP 来实现 REST 是比较方便的。

RESTful Web API 主要有如下三个要点：

1 资源地址与资源的 URI，好比：http://example.com/resources/
2 传输资源的表现形式，指的是 Web 服务接受与返回的互联网媒体类型，好比：JSON，XML 等，其中 JSON 具备轻量级的特色，移动互联网的飞速发展轻量级的协议很是受欢迎，JSON 获得了普遍的应用 3 对资源的操做，Web 服务在该资源上所支持的一系列请求方法，好比：POST,GET,PUT,DELETE

下面以 OpenStack Swift 的接口做为一个例子来讲明：

1 首先，用 curl 命令访问一个 http 服务 2  crul -i -X GET http://storage.clouddrive.com/v1/my_account?format=json\ -H 
3 "X-Auth-User:jdoe" -H "X-Auth-Key:jdoepassword"

返回结果：

它是一个 HTTP 响应的头部，有 Account 的细节信息，包括这个 Account 有多少个 ，Container 有多少个 Object，占用了多少字节的存储空间等等。
而后是 JOSN 格式的内容，列出了这个 Account 下面的 Container

调用及调试 API 的几种方式：

1 第一种方式：curl 命令（linux 下发送 HTTP 请求并接受响应的命令行工具），这种方式其实用的比较少，比较麻烦 2 第二种方式：比较经常使用的 OpenStack 命令行客户端，每个 OpenStack 项目都有一个 Python 写的命令行客户端 3 第三种方式：用 Firefox 或 Chrome 浏览器的 REST 的客户端（图形界面的，浏览器插件） 4 第四种方式：用 OpenStack 的 SDK，能够不用手动写代码发送 HTTP 请求调用 REST 接口，还省去了一些管理诸如 Token 等数据的工做，可以很方便地基于 OpenStack 作开发，
  那么 OpenStack 官方提供的是 Python 的 SDK，固然还有第三方提供的 SDK 好比说支持 Java 的著名的 Jclouds，还有支持 Node.js、Ruby、.Net 等等

OpenStack 还提供了另一套 API 兼容亚马逊的 EC2，可以方便应用在两套系统之间作迁移。

3、OpenStack组件间的通讯关系

OpenStack 组件之间的通讯分为四类：

1 基于 HTTP 协议 2 基于 AMQP(Advanced Message Queuing Protocol，一个提供统一消息服务的应用层标准高级消息队列协议) 协议（基于消息队列协议） 3 基于数据库链接（主要是 SQL 的通讯） 4 Native API（基于第三方的 API）

有个概念须要了解一下：

1 Compute Node 是实际运行虚拟机的节点 2 Block Storage Node 主要是 Cinder 链接的存储后端（存储设备） 3 Network Node 一般是具备路由等一些网关功能的节点（网络设备）

3-1. 基于HTTP协议进行通讯

经过各项目的 API 创建的通讯关系，基本上都属于这一类，这些 API 都是 RESTful Web API，最多见的就是经过 Horizon 或者说命令行接口对各组件进行操做的时候产生的这种通讯，
而后就是各组件经过 Keystone 对用户身份进行校验，进行验证的时候使用这种通讯，还有好比说 Nova Compute 在获取镜像的时候和 Glance 之间，对 Glance API 的调用，
还有比方说 Swift 数据的读写，也是经过这个 HTTP 协议的 RESTful Web API 来进行的。

3-2. 基于高级消息队列协议

基于 AMQP 协议进行的通讯，主要是每一个项目内部各个组件之间的通讯，比方说 Nova 的 Nova Compute 和 Scheduler 之间，而后 Cinder 的 Scheduler 和 Cinder Volume之间。
须要说明的是，Cinder 是从 Nova Volume 演化出来的，因此 Cinder 和 Nova 之间也有经过 AMQP 协议的通讯关系，因为 AMQP 协议进行通讯也属于面向服务的架构，
虽然大部分经过 AMQP 协议进行通讯的组件属于同一个项目，可是并不要求它们安装在同一个节点上，给系统的横向扩展带来了很大的好处，
能够对其中的各个组件分别按照他们负载的状况进行横向扩展，由于他们不在一个节点上，分别用不一样数量的节点去承载它们的这些服务。
（ AMQP 是一种协议，OpenStack 没有规定它是用什么实现，咱们常用的是 Private MQ，实际上用户也能够根据自身的状况选择其它的消息中间件。）

3-3. 基于SQL的通讯

经过数据库链接实现通讯，这些通讯大多也属于各个项目内部，也不要求数据库和项目其它组件安装在同一个节点上，它也能够分开安装，还能够专门部署数据库服务器，
把数据库服务放到上面，之间经过基于 SQL 的这些链接来进行通讯。OpenStack 没有规定必须使用哪一种数据库，虽然一般用的是 MySQL

3-4. 经过Native API实现通讯

出如今 OpenStack 各组件和第三方的软硬件之间，好比说，Cinder 和存储后端之间的通讯，Neutron 的 agent 或者说插件和网络设备之间的通讯，
这些通讯都须要调用第三方的设备或第三方软件的 API，咱们称为它们为 Native API，那么这个就是咱们前面说的基于第三方 API 的通讯。

4、OpenStack几种不一样的存储

OpenStack的存储服务分为三种：

Glance：

Glance（镜像存储）是一个镜像存储管理服务，自己不具有存储的功能；

Swift：

Swift （对象存储）提供的是对象存储服务，一样的具备像亚马逊 IWSS3 的特色，提供经过RESTful API 的方式去访问数据，
这样作是为了解决两个问题：第一个，咱们能够直接去访问一个存储，而不须要在经过本身开发的 Web 服务器去作一次数据的转发，不然对服务器的负载来讲是一种压力。
第二个，在咱们的大数据时代，当数据量特别大的时候，若是咱们用文件系统就会出现问题：文件的数量激增之后，存储的性能会急剧降低，而对象存储实际上则是解决这个问题的，
对象存储抛弃了那种目录树的结构，用一种扁平化的结构去管理数据。Swift 实际上只有三层结构，即 Account、Container、Object。Object 就是最终的那个数据了，
就是文件，前面有两级管理，一级是 Container 容器，它把 Object 放到容器里面，而后再上面一级是 Account，是和帐户去关联的，Container 至关因而把这些 Object 作了分类，
用 Account 去跟帐户关联起来。

Cinder：

Cinder （块存储）提供块存储的接口；自己也不提供数据的存储，后面也须要接一个存储的后端，像 EMC 的散设备，华为的存储设备，NetApp 的存储设备能够作它的后端。
还有一个比较火的开源分布式存储叫 Ceph，Ceph 也提供块存储服务，也能够用来做为 Cinder 的后端。Cinder 的做用就是为 OpenStack 提供块存储的接口，
有个很重要的功能叫卷管理功能，虚拟机并不直接去使用存储设备（并不直接去使用后端的存储系统），使用的是虚拟机上的块设备（卷 Volume），
实际上 Cinder 就是建立和管理这些 Volume 而且把它挂载到虚拟机上。Cinder 是从 Nova Volume 里面独立出来的，独立出来以后很受各类存储厂商的欢迎，
能够经过写 Cinder Driver 的形式把本身的存储设备归入到 OpenStack 的生态圈里面去。

三种存储的概念：

文件存储：

有 POSIX 接口或者 POSIX 兼容的接口，就可认为它是一个文件系统，比较典型的分布式文件系统有像 Glance 的 FS，Hadoop 里的 HDFS

块存储：

电脑上的一个盘格式化以后是一个文件系统，那么在格式化以前是一个块设备，也就是块存储，实际上咱们在数据中内心面，像 EMC 的不少设备，
像华为的一些叫做 SAN 的设备，像 NetApp 的一些设备，若是是散存储通常来讲就是提供块存储的；

对象存储：

对象存储的典型表明是亚马逊的 AWS S3，它的接口不是 POSIX，也不是像一块硬盘那样做为一个块存储的接口，是经过 RESTful Web API 去访问的，
对于应用开发者来讲优点在于能够很方便的去访问存储里面存的数据，对象存储里存的数据一般叫作 Object，实际上它就是 File，
可是对象存储里面为了和文件系统作一个区别，便被叫做对象 Object。

5、 OpenStack工做流程

这里以建立一个虚拟机为例来了解 OpenStack 是如何工做的，下面的图是 OpenStack 建立虚拟机整个工做过程：

下面进行简要的文字说明：

 1 登陆界面或命令行经过RESTful 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发送对应的建立虚拟机请求的消息。 13 nova-compute会从对应的消息队列中获取建立虚拟机请求的消息。 14 nova-compute经过rpc.call向nova-conductor请求获取虚拟机消息。（Flavor） 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拿到认证k的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的信息调用配置的虚拟化驱动来建立虚拟机。

注：

keystone

User：指使用Openstack service的用户，能够是人、服务、系统，但凡使用了Openstack service的对象均可以称为User。 Project(Tenant)：能够理解为一我的、或服务所拥有的 资源集合 。在一个Project(Tenant)中能够包含多个User，每个User都会根据权限的划分来使用Project(Tenant)中的资源。好比经过Nova建立虚拟机时要指定到某个Project中，在Cinder建立卷也要指定到某个Project中。User访问Project的资源前，必需要与该Project关联，而且指定User在Project下的Role。 Role：用于划分权限。能够经过给User指定Role，使User得到Role对应的操做权限。Keystone返回给User的Token包含了Role列表，被访问的Services会判断访问它的User和User提供的Token中所包含的Role。系统默认使用管理Role admin和成员Role _member_ Policy：OpenStack对User的验证除了OpenStack的身份验证之外，还须要鉴别User对某个Service是否有访问权限。Policy机制就是用来控制User对Tenant中资源(包括Services)的操做权限。对于Keystone service来讲，Policy就是一个JSON文件，默认是/etc/keystone/policy.json。经过配置这个文件，Keystone Service实现了对User基于Role的权限管理。 Token：是一个字符串表示，做为访问资源的令牌。Token包含了在 指定范围和有效时间内 能够被访问的资源。EG. 在Nova中一个tenant能够是一些虚拟机，在Swift和Glance中一个tenant能够是一些镜像存储，在Network中一个tenant能够是一些网络资源。Token通常被User持有。 Credentials：用于确认用户身份的凭证 Authentication：肯定用户身份的过程 Service：Openstack service，即Openstack中运行的组件服务。 Endpoint：一个能够经过网络来访问和定位某个Openstack service的地址，一般是一个URL。好比，当Nova须要访问Glance服务去获取image 时，Nova经过访问Keystone拿到Glance的endpoint，而后经过访问该endpoint去获取Glance服务。咱们能够经过Endpoint的region属性去定义多个region。Endpoint 该使用对象分为三类： admin url –> 给admin用户使用，Post：35357
internal url –> OpenStack内部服务使用来跟别的服务通讯，Port：5000
public url –> 其它用户能够访问的地址，Post：5000 建立完service后建立API EndPoint. 在openstack中，每个service都有三种end points. Admin, public, internal。 Admin是用做管理用途的，如它可以修改user/tenant(project)。 public 是让客户调用的，好比能够部署在外网上让客户能够管理本身的云。 internal是openstack内部调用的。
三种endpoints 在网络上开放的权限通常也不一样。Admin一般只能对内网开放，public一般能够对外网开放internal一般只能对安装有openstack对服务的机器开放。

一个实例：

1 用户alice登陆keystone系统（password或者token的方式），获取一个临时的token和catalog服务目录
 （v3版本登陆时，若是没有指定scope，project或者domain，获取的临时token没有任何权限，不能查询project或者catalog）。 2 alice经过临时token获取本身的全部的project列表。 3 alice选定一个project，而后指定project从新登陆，获取一个正式的token，同时得到服务列表的endpoint，用户选定一个endpoint，
 在HTTP消息头中携带token，而后发送请求（若是用户知道project name或者project id能够直接第3步登陆）。 4 消息到达endpoint以后，由服务端（nova）的keystone中间件（pipeline中的filter：authtoken）向keystone发送一个验证token的请求。
 （token类型：uuid须要在keystone验证token，pki类型的token自己是包含用户详细信息的加密串，能够在服务端完成验证） 5 keystone验证token成功以后，将token对应用户的详细信息，例如：role，username，userid等，返回给服务端（nova）。 6 服务端（nova）完成请求，例如：建立虚拟机。 7 服务端返回请求结果给alice。

cinder：

cinder主要组成:

1 Cinder-api 是 cinder 服务的 endpoint，提供 rest 接口，负责处理 client 请求，并将 RPC 请求发送至 cinder-scheduler 组件。 2 Cinder-scheduler 负责 cinder 请求调度，其核心部分就是 scheduler_driver, 做为 scheduler manager 的 driver，负责 cinder-volume 具体的调度处理，
发送 cinder RPC 请求到选择的 cinder-volume。 3 Cinder-volume 负责具体的 volume 请求处理，由不一样后端存储提供 volume 存储空间。

neutron

neutron主要组成：

1.Neutron-server能够理解为一个专门用来接收Neutron REST API调用的服务器，而后负责将不一样的rest api分发到不一样的neutron-plugin上。 2.Neutron-plugin能够理解为不一样网络功能实现的入口，各个厂商能够开发本身的plugin。Neutron-plugin接收neutron-server分发过来的REST API，向neutron database完成一些信息的注册，而后将具体要执行的业务操做和参数通知给自身对应的neutron agent。 3.Neutron-agent能够直观地理解为neutron-plugin在设备上的代理，接收相应的neutron-plugin通知的业务操做和参数，并转换为具体的设备级操做，以指导设备的动做。当设备本地发生问题时，neutron-agent会将状况通知给neutron-plugin。 4.Neutron database，顾名思义就是Neutron的数据库，一些业务相关的参数都存在这里。 5.Network provider，即为实际执行功能的网络设备，通常为虚拟交换机（OVS或者Linux Bridge）。

虚拟机建立的四个阶段：

1 scheduling 2 networking 3 block_ device_mapping 4 spawing

几种通讯关系的体现：

1 各个组件 API 之间的调用，这就属于 HTTP 通讯； 2 Nova 和 Neutron 内部各个组件的通讯属于经过 AMQP 协议的通讯； 3 中间频繁的读写数据库的操做属于数据库链接进行通讯的； 4 Nova 与 Hypervisor 或者说 Libvirt 交互属于经过 Native API 即第三方接口去进行通讯的，还有一个就是在给虚拟机准备 Volume 的过程当中 Cinder 还须要和存储设备进行交互，
这中间也须要用到 Native API 或者是第三方接口；

6、OpenStack的部署架构

前面已经从逻辑关系、通讯关系分析了OpenStack 各组件之间的关系，而且也介绍了 OpenStack 的 API 和存储。

前面谈到的各类架构基本上都是属于软件上的逻辑架构，可是 OpenStack 是个分布式的系统，就得解决从逻辑架构到物理架构的映射的问题，也就是 OpenStack 的各个项目、组件按什么方式安装到实际的服务器节点上去，实际的存储设备上，如何经过把它们经过网络链接起来，这就是 OpenStack 的部署架构。

OpenStack的部署分为:

单节点部署，一般是用于学习或者是开发
多节点部署（集群部署）

OpenStack 的部署架构不是一成不变的，而是根据实际的需求设计不一样的实施方案。

在实际生产过程当中，咱们首先要对计算、网络、存储所须要的资源进行规划，虽说咱们如今用的云计算技术，它比传统的 IT 架构在资源规划方面的困难和工做量要小一些，可是仍是须要有一个规划，这里学习了解一下基本的和复杂的两种集群部署架构。

6-1. 简单部署架构

是一个最基本的生产环境所须要的 OpenStack 的部署状况。

根据实际须要设计不一样的实施方案

下面解释一下 “三种网络和四种节点”

（1）绿色的管理网络 + 蓝色的存储网络 + 黄色的服务网络

 管理网络 是 OpenStack 的管理节点或者说是它的管理服务对其它的节点去进行管理的这样一个网络，他们之间有 “不一样组件之间的 API 调用，虚拟机之间的迁移” 等等；
 存储网络 是计算节点访问存储服务的网络，包括向存储设备里面读写数据的流量基本上都须要从存储网络走，还有另一种是服务网络；
 服务网络 是由 OpenStack 去管理的虚拟机对外提供服务的网络，服务器上一般都是一台服务器上带好几块网卡，好几块网口，咱们能够给各个网络作隔离。隔离的好处是，
它们的流量不会交叉，比方说咱们在读写存储设备的时候，可能在存储网络上的流量特别大，可是它不会影响到咱们这些节点对外提供服务，
一样，在咱们作虚拟机迁移的时候可能在管理网络上它的数据流量会很是大，可是它一样不会影响到咱们这些计算节点对存储设备的读写性能。

（2）四种节点：

控制节点（OpenStack 的管理节点，OpenStack 的大部分服务都是运行在控制节点上的，好比说 Keystone 的认证服务，虚拟机镜像管理服务 Glance 等等）
计算节点（计算节点指的是实际运行虚拟机的节点）
存储节点（提供对象存储服务，提供对象存储的 Swift 的节点或者是 Swift 集群的 Proxy 节点，也能够是其它服务的存储后端）
网络节点（实现网关和路由的功能）

有些服务能够直接部署在 Controller 节点上或者说是直接部署在控制节点上，可是特别须要说明的一点是： Nova 和 Neutron 这两个组件必须采用分布式部署。说一下 Nova：Nova-Compute 是控制虚拟机的，是控制和管理虚拟机的，因此必须部署在计算节点上，而 Nova 的其它几个服务则应该部署在控制节点上，特别须要强调一点，Nova-Compute 和 Nova-Conducter 必定不能部署在同一个节点上，把这两个分开就是为了解耦。
说一下 Neutron：Neutron 的一些插件或 Agent 须要部署在网络节点和计算节点上，而其余的部分，好比说 Neutron Server 能够部署在控制节点上

6-2. 复杂部署架构

须要掌握三个要点：

1 规模较大的状况下，把各类管理服务部署到不一样的服务器上。把这些 服务拆开部署 到不一样的节点上，甚至要把同 一个服务的不一样组件也拆开部署，
 好比说能够把 Nova 的数据库给独立拧出来部署成一个 MySQL 数据库集群，还有 Cinder 里面的 Scheduler 和 Volume 能够部署到不一样的节点上，
 实际上由于 Swift 项目具备必定的独立性，因此 Swift 自己就有跨地域部署的生产环境，规模很是之大，跨地域部署，因此它的服务的可用性极高，天然有这种栽培的特性，
 能够提供极高可用性和数据持久性 的对象存储服务。因而乎，很容易的对 OpenStack 的这些服务进行横向扩展，对 OpenStack 整个系统作横向扩展，
 这些让 OpenStack 具备比较高的负载能力，能够达到一个比较大的规模。全部的这些都得益于 OpenStack 设计的时候采用了 SO 吻合的面向服务的架构，就是 SOA 架构，
 具体到每一个组件如何进行分布式的部署，如何进行横向扩展。 2 出于高可用的考虑，生产环境中咱们会把 OpenStack 的同一个服务部署到不一样的节点上，造成双机热备或者多机热备的高可用集群。（或者用负载均衡集群）。 3 在复杂的数据中心环境中，还有不少第三方服务，比方说 LDAP 服务、DNS 服务等等，考虑如何与第三方服务进行对接和集成。好比说，
  咱们可能须要使用 OPEN LDAP 服务器来做为 Keystone 的认证和健全的后端，这些通常是在管理网络中去完成的。

转：http://blog.csdn.net/q123_xi/article/details/78550273?locationNum=10&fps=1