OpenStack之基础组件（二）_【尚学堂大数据】

OpenStack之基础组件（二）...

4. OpenStack几种不同的存储

[ OpenStack的存储服务分为三种：Glance、Swift、Cinder ]

Glance（镜像存储）是一个镜像存储管理服务，本身不具备存储的功能；
Cinder （块存储）提供块存储的接口；本身也不提供数据的存储，后面也需要接一个存储的后端，像 EMC 的散设备，华为的存储设备，NetApp 的存储设备可以做它的后端。还有一个比较火的开源分布式存储叫 Ceph，Ceph 也提供块存储服务，也可以用来作为 Cinder 的后端。Cinder 的作用就是为 OpenStack 提供块存储的接口，有个很重要的功能叫卷管理功能，虚拟机并不直接去使用存储设备（并不直接去使用后端的存储系统），使用的是虚拟机上的块设备（卷 Volume），实际上 Cinder 就是创建和管理这些 Volume 并且把它挂载到虚拟机上。Cinder 是从 Nova Volume 里面独立出来的，独立出来之后很受各种存储厂商的欢迎，可以通过写 Cinder Driver 的形式把自己的存储设备纳入到 OpenStack 的生态圈里面去。
Swift （对象存储）提供的是对象存储服务，具有像亚马逊 IWSS3 的特点，提供通过RESTful API 的方式去访问数据，这样做是为了解决两个问题：
（1）我们可以直接去访问一个存储，而不需要在通过自己开发的 Web 服务器去做一次数据的转发，否则对服务器的负载来说是一种压力。
（2）在我们的大数据时代，当数据量特别大的时候，如果我们用文件系统就会出现问题，文件的数量激增以后，存储的性能会急剧下降，而对象存储实际上则是解决这个问题的，对象存储抛弃了那种目录树的结构，用一种扁平化的结构去管理数据。Swift 实际上只有三层结构，即 Account、Container、Object。Object 就是最终的那个数据了，就是文件，前面有两级管理，一级是 Container 容器，它把 Object 放到容器里面，然后再上面一级是 Account，是和账户去关联的，Container 相当于是把这些 Object 做了分类，用 Account 去跟账户关联起来。

[ 三种存储的概念：文件存储、块存储、对象存储 ]

文件存储：有 POSIX 接口或者 POSIX 兼容的接口的，可以被认为它是一个文件系统，比较典型的分布式文件系统有像 Glance 的 FS，Hadoop 里的 HDFS
块存储：电脑上的一个盘格式化之后是一个文件系统，那么在格式化之前是一个块设备，也就是块存储，实际上我们在数据中心里面，像 EMC 的很多设备，像华为的一些叫作 SAN 的设备，像 NetApp 的一些设备，如果是散存储一般来说就是提供块存储的；
对象存储：对象存储的典型代表是亚马逊的 AWS S3，它的接口不是 POSIX，也不是像一块硬盘那样作为一个块存储的接口，是通过 RESTful Web API 去访问的，对于应用开发者来说优势在于可以很方便的去访问存储里面存的数据，对象存储里存的数据通常叫做 Object，实际上它就是 File，但是对象存储里面为了和文件系统做一个区别，便被叫作对象 Object

5. OpenStack工作流程

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

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

总共有 28 个步骤，主要是和 Nova 相关的，实际上在 Keystone Glance Neutron Cinder Swift 等组件内部还有很多小步骤，加起来恐怕有50多个步骤。现在主要看这28个基本步骤，这里的大部分信息发表在来自 ilearnstack 网站上的一篇文章，在 Dashboard 上创建虚拟机的过程.

第 1 步，首先，Horizon 或者是命令行工具向 keystone 发起了 REST 调用，并且把用户名和密码发给 Keystone；
第 2 步，Keystone 对接收到的用户名及其密码进行验证，并生成 Token，这个 Token 在后面为其他组件发送 REST 调用时使用；
第 3 步，Horizon 或者命令行客户端把启动虚拟机操作或者在命令行上敲的 nova boot 命令，包括上一步说的 Token 转化成 RESTful Web API 发送给 Nova-API；
第 4 步，Nova-API 收到请求之后向Keystone 验证客户端发来的 Token 的合法性，这就是说 Nova 和 Keystone 之间有一个交互了；
第 5 步，Keystone 验证完 Token 之后，将用户的角色和权限返回给 Nova，也是返回到 Nova-API；
第 6 步，是 Nova-API与 Nova Database 之间有一个交互的过程；
第 7 步，是 Nova Database 为新的虚拟机实例创建一条记录，并且将结果返回给 Nova-API。
第 8 步，Nova-API 通过 AMQP 向 Nova-Scheduler 发送一个同步远程调用请求，这里的同步远程调用请求实际上是 AMQP 协议里的叫作 rpc.call request，这地方是同步调用，同步调用的意思就是，它发送完请求以后就一直在等待，一直等待到这个队列（消息队列）里面给它返回来结果，所以就是在等待获得新的虚拟机实例的条目和 Host ID，Host ID 是虚拟机将来要启动的寄主机的 ID；
第 9 步，Nova-Scheduler 从消息队列里面取出请求，因为中间有 AMQP 组件在这，所以 Nova 的其他各个组件之间的交互基本上都是通过 AMQP 来做的，实际上 AMQP 的实现用的是 RabbitMQ；
第 10 步，是 Nova-Scheduler 与 Nova Database 进行交互并且挑选出一台适合的宿主机来启动这个虚拟机，（挑选的过程很复杂）；
第 11 步，是 Nova-Scheduler 通过 AMQP 返回给前面的 Nova-API 的调用，并且将宿主机的 ID 发送给它；
第 12 步，是 Nova-Scheduler 通过消息队列，向 Nova-Compute 发出一个在上述宿主机上启动虚拟机的异步调用请求，这里是异步调用请求（Nova-Schduler 把请求发送到消息队列里面以后它就返回了，就不用再等待这个请求给它返回结果，在 AMQP 里面是 rpc-cast 这个请求）；
第 13 步，是 Nova-Compute 从队列里面取该请求；
第 14 步，是 Nova-Compute 通过消息队列向 Nova-Conducter 发送一个 rpc.call 同步调用请求获取虚拟机的信息（包括宿主机的 ID，虚拟机配置信息有内存大小、CPU 配置、硬盘大小等等）；
第 15 步，Nova-Conducter 从队列里取出上述请求；
第 16 步，Nova-Conducter 与数据库进行交互；
第 17 步，Nova-Conducter 返回前面 Nova-Compute 请求的这些信息；
第 18 步，Nova-Compute 从消息队列里面取出 Nova-Conducter 返回的信息，也就是同步调用到这里就结束了；
第 19 步，是 Nova-Compute 向 Glance-API 发出带有 Token 的 REST 请求，去请求这个镜像数据；
第 20 步，是 Glance-API 向 Keystone 去验证这个 Token 的合法性，在前面有类似的步骤（Nova 去验证 Token 的合法性，其实在 19 步和 20 步两步里面还有很多细节比如说，如果是 Swift 来存储 Glance 的镜像，中间还有 Swift 和 Glance 之间的交互，Glance 内部也有一些交互）；
第 21 步，是 Nova-Compute 获取镜像的元数据，前面几步相当于把镜像的元数据给获取了，知道了镜像是从哪里来的长什么样的。后面的 22 到 24 步这几步是为虚拟机去准备网络，还是以 Nova-Compute 为中心的；
第 22 步，是 Nova-Compute 向 Neutron API 发送带有 Token 的 REST 请求进行网络配置，并获得分配给待创建的这个虚拟机的 IP 地址，这中间其实 Neutron 做了一些工作，也有很多细节；
第 23 步，Neutron Server 向 Keystone 去验证 Token 的合法性；
第 24 步，Nova-Compute 就获得了网络的配置信息，后面这几步是给虚拟机去准备虚拟机的硬盘，也就是前面提到过的卷存储或块存储；
第 25 步，是 Nova-Compute 调用 Cinder-API 的 RESTful 接口给虚拟机挂载卷，也就是块设备或者是虚拟硬盘；
第 26 步，跟上面的 Glance 和 Neutron 类似，Cinder-API 也要向 Keystone 去验证，这个Token 的合法性；
第 27 步，Nova-Compute 就会得到这个虚拟机的块存储的信息；经过 27 个步骤，这样创建一个虚拟机所需要的各种信息和条件才正式地准备完毕；
第 28 步，Nova-Compute 去调用 Hypervisor 或者 Libvirt 的接口创建虚拟机，当然，在 Libvirt 或者说是 Hypervisor 去创建虚拟机的过程中，内部也是一个非常复杂的过程；

[ 虚拟机创建的四个阶段：]

scheduling
networking
block_ device_mapping
spawing

[ 几种通信关系的体现：]

各个组件 API 之间的调用，这就属于 HTTP 通信；
Nova 和 Neutron 内部各个组件的通信属于通过 AMQP 协议的通信；
中间频繁的读写数据库的操作属于数据库连接进行通信的；
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. 复杂部署架构

[ 需要掌握三个要点：]

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

尚学堂：每天推送新技术文章，跟着我们扩展技术视野吧