2017.4.5 OpenStack简介

OpenStack 管理的资源不是单机的而是一个分布的系统，把分布的计算、存储、网络、设备、资源组织起来，形成一个完整的云计算系统；OpenStack 也提供一个 UI，这里包括一个图形化的 UI：Horizon，也提供命令行的界面，还提供了一套 API 支持用户开发自己的软件…

OpenStack是什么?

OpenStack是一套框架，有下面这两个特点：

1. 它是一个中间层，可以创建、管理和销毁虚拟机，但是要完成这些操作需要依赖于第三方的 Hypervisor，通过这个 Hypervisor 去完成虚拟化的工作，OpenStack 并不能自己去提供一个虚拟化的运行环境，OpenStack 有个组件叫 Cinder（用来提供块存储服务的），但是 OpenStack 自己并不能进行数据的存储和读写，它需要依赖一个实际的块存储设备的支持，这个设备可以是一个分布式的存储系统，比如说 Ceph，也可以是一个存储设备，比如说 EMC 的 SAN，也可以是存储服务器的本地硬盘，但是它必须依赖一个存储设备的支持，OpenStack 本身并不具备这个功能。OpenStack 是一个中间层。
2. 框架有一个很重要的特点，那就是它能提供一批 API 去支持应用的开发，这也是我们业内对框架的一个定义，OpenStack 当然也有这个特点，云计算的愿景就是让用户能够像用电一样去使用计算，OpenStack 的设计也是朝着这个愿景去做设计的，但是实际上我们平时是不能直接用电的，我们需要用的是电冰箱、电脑、电视等等这些电器。同理，对于云计算来说，提供 API 去支持开发应用这个事情就合情合理的非常的重要了，具有完备的 API 是 OpenStack 的突出优点。

OpenStack不是什么？

1. 它不是虚拟化软件（必须知道这点），OpenStack 虽然管理虚拟机，但不具备虚拟化的功能，它给上层提供一个虚拟化的运行环境，必须得依赖一个第三方的虚拟化软件来实现，比如默认支持的 Linux 内核虚拟机，装完 Linux 之后就自动带了，集成到 Linux 内核里面了（KVM），另外它还支持 Xen，还支持微软的 Hyper-V，支持 VMware 的 Vshpere，还支持像 Linux Container 和 Docker 这样轻量级的虚拟化技术。总之，OpenStack 本身不提供虚拟化，依赖第三方软件。
2. 需要了解的第二层含义：这个云化和虚拟化实际上是不一样的，云 != 虚拟化，云化的目的是为了实现效用计算，弹性计算，动态资源调度，多租户等这样的一些特性；而虚拟化只是实现云计算的这些特性中的一个技术手段而已，而且它不是必需的。比方说 IBM 的 Softlayer 是 IBM 主推的云服务之一，它中间有一个非常大的特点就是，它支持 Bare Metal Server，直译过来就是 “金属裸机”，也就是 Softlayer 在上面不做虚拟化，而是直接用物理服务器来实现云，直接给用户、租户提供的就是物理服务器，Softlayer 也可以在上面来实现多租户 、弹性计算等等特性。总之，Softlayer 没有虚拟化，但是 Softlayer 也做了云。第二个例子是 OpenStack 也有一个项目叫作 Ironic，是为了通过管理 “金属裸机”来实现云从而提出的项目。

 

OpenStack生态圈

一个成功的开源平台，有三个要素组成，技术 + 生态 + 用户； OpenStack 诞生于2010年；

了解一下：

• 社区的组成
• 基金会的管理机构
• 项目的孵化

项目产生与发展

每个项目经过孵化阶段以后才能够集成发布，OpenStack 为项目的孵化提供了一整套的基础设施和资源，包括代码和文档的管理，还有配置管理，版本控制等等工具；这些基础设施能够支持全球范围内的大规模的协作开发，这些基础设施和工具本身也是代表了 IT 领域先进的生产工具；

每半年发布一个版本，会由技术委员会和版本发布经理以及项目的 TPL 来共同决定每个版本中间要发布哪些 Feature。

 

OpenStack资源管理

OpenStack 作为一个操作系统，管理资源是它的首要任务；OpenStack 管理资源主要有三个方面：计算、存储和网络。

OpenStack 对资源进行管理，并且以服务的形式提供给上层应用或者用户去使用。这些资源的管理是通过 OpenStack 中的各个项目来实现的。其中计算资源管理相关的项目是 Nova（又称为 OpenStack Compute）；存储相关的主要有块存储服务 Cinder、对象存储服务 Swift、镜像存储服务 Glance 这三种；

与网络相关的主要是一个和软件定义网络相关的项目叫作 Neutron；另外，Nova 中间有一个管理网络的模块叫作 Nova Network，作为一个比较稳定的遗留组件仍在 OpenStack 里面和 Neutron 并存，我们在小规模部署里面经常为了追求这种稳定，并且减少工作量会去使用 Nova Network 这样的一个组件来对网络资源进行管理。

OpenStack 提供的这些服务和公有云上的服务往往有一种对应关系，这里以亚马逊的公有云 AWS 为例，看一下 OpenStack 的服务和亚马逊的服务之间的对应的关系：

与aws的部分功能做对应：

Nova - EC2;Cinder - EBS;Neutron - VPC;Swift - S3；Glance - VM Import/Export 等；

OpenStack基本组件

   OpenStack 核心的项目：Nova 、 Cinder、 Neutron、 Swift、 Keystone、 Glance、 Horizon

4-1. Nova

又被称为 OpenStack Compute，主要作用是控制虚拟机的创建，以及改变它的容量和配置，还可以做虚拟机的销毁，虚拟机的整个生命周期都是由 Nova 来控制的；

Nova 的部署运行一般有两种情况：一类是 Nova 作为 Controller 节点去运行，Controller 节点是用来控制其它的一些计算节点的；另外一类节点就是 Compute 节点，是计算节点，上面是运行实际的虚拟机的；

[ 那么有什么区别呢？]

• 在 Compute 节点上部署的 Nova，它上面核心运行的一个东西叫作 Nova Compute，主要是为了去对虚拟机进行控制，它去和 Hypevisor 进行交互，对虚拟机进行控制；
• 在 Controller 上运行的 Nova 就相对复杂一些，它有 Scheduler、Conductor、Nova Cell；
• Scheduler 在用户发起请求的时候决定这个虚拟机应该在哪个机器上启动，应该在哪个计算节点上启动；
• Conductor 对所有的计算节点进行统一的管理；
• Nova Cell 的作用是级联
• 控制节点：Scheduler（决定虚拟机的启动位置）、Conductor（对所有的计算节点进行统一管理）、Nova Cell（级联）
• 计算节点：对虚拟机进行控制

4-2. Cinder

Cinder 组件主要的用途是提供块存储服务，最核心的两个部分是 Scheduler 和 Cinder Volume。有读写存储服务请求的时候，Scheduler 决定通过哪个 Cinder Volume 进行读取操作，Cinder Volume 是实际控制存储的设备。

4-3. Neutron

有一个非常火的概念叫作 SDN，软件定义网络，Neutron 是在 OpenStack 里边的一个实现， 有一个很大的特点就是提供 Plugin 模块，这个是用户可以自己去写的。

4-4. Swift

Swift 是一个比较有趣的组件，从 OpenStack 的诞生之初就已经有 Swift 的这个项目了，但是它发展到现在还是比较独立的，和其它组件的交互关系比较少，是一个相对独立的发展套路，美国有一个公司叫作 SwiftStack，是专门用 Swift 来做的一个公司，Swift 是提供对象存储服务的 ，提供一个类似于像亚马逊 S3 或者像国内的七牛这样的一个存储服务。 其他的组件如果要用到对象存储的时候，就去 Swift 里边去写数据，读数据； Swift 可以利用 Keystone 来做认证。

4-5. Glance

需要使用 Swift 最多的一个组件，主要是用 Swift 来存虚拟机的镜像、快照等等这样一些东西。

4-6. Keystone

主要是为各个组件提供用户的认证、建权等等这样的一些服务。

4-7. Horizon

图形界面。

4-8. Heat

是用来做各个服务的编排的。

4-9. Sahara

把 Hadoop 能够放在 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 的接口作为一个例子来说明：

首先，用 curl 命令访问一个 http 服务

crul -i -<span class="hljs-type">X <span class="hljs-type">GET http:<span class="hljs-comment">//storage.clouddrive.com/v1/my_account?format=json\ -H

<span class="hljs-string">"X-Auth-User:jdoe" -<span class="hljs-type">H <span class="hljs-string">"X-Auth-Key:jdoepassword"</span></span></span></span></span></span>

返回结果：

 

它是一个 HTTP 响应的头部，有 Account 的细节信息，包括这个 Account 有多少个 Container 有多少个 Object，占用了多少字节的存储空间等等

然后是 JOSN 格式的内容，列出了这个 Account 下面的 Container

 

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

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

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

3. OpenStack组件间的通信关系

[ OpenStack 组件之间的通信分为四类：]

• 基于 HTTP 协议
• 基于 AMQP 协议（基于高级消息队列协议）
• 基于数据库连接（主要是 SQL 的通信）
• Native API（基于第三方的 API）

有一张图需要了解一下：

 

Compute Node 是实际运行虚拟机的节点； Block Storage Node 主要是 Cinder 连接的存储后端（存储设备）； Network Node 通常是具有路由等一些网关功能的节点（网络设备）。

[ 基于 HTTP 协议进行通信：]

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

[ 基于高级消息队列协议：]

基于 AMQP 协议进行的通信，主要是每个项目内部各个组件之间的通信，比方说 Nova 的 Nova Compute 和 Scheduler 之间，然后 Cinder 的 Scheduler 和 Cinder Volume 之间。

需要说明的是，Cinder 是从 Nova Volume 演化出来的，所以 Cinder 和 Nova 之间也有通过 AMQP 协议的通信关系，由于 AMQP 协议进行通信也属于面向服务的架构，虽然大部分通过 AMQP 协议进行通信的组件属于同一个项目，但是并不要求它们安装在同一个节点上，给系统的横向扩展带来了很大的好处，可以对其中的各个组件分别按照他们负载的情况进行横向扩展，因为他们不在一个节点上，分别用不同数量的节点去承载它们的这些服务。

（ AMQP 是一种协议，OpenStack 没有规定它是用什么实现，我们经常使用的是 Private MQ，实际上用户也可以根据自身的情况选择其它的消息中间件。）

[ 基于 SQL 的通信：]

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

[ 通过 Native API 实现通信：]

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

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

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

1. scheduling
2. networking
3. block_ device_mapping
4. 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. 复杂部署架构

[ 需要掌握三个要点：]

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

 

以上均为学长整理，仅用于学习记录，非常感谢。转自：http://www.cnblogs.com/07byte/p/5899693.html