OpenStack架构详解

一、OpenStack概述

OpenStack既是一个社区，也是一个项目和一个开源软件，它提供了一个部署云的操作平台或工具集。其宗旨在于，帮助组织运行为虚拟计算或存储服务的云，为公有云、私有云，也为大云、小云提供可扩展的、灵活的云计算。

OpenStack旗下包含了一组由社区维护的开源项目，他们分别是OpenStack Compute（Nova）计算，OpenStack Object Storage（Swift）对象存储，以及OpenStack Image Service（Glance）镜像服务。

OpenStack Compute，为云组织的控制器，它提供一个工具来部署云，包括运行实例、管理网络以及控制用户和其他项目对云的访问（the cloud through users and projects）。它底层的开源项目名称是Nova，其提供的软件能控制IaaS云计算平台，类似于Amazon EC2和Rackspace Cloud Servers。实际上它定义的是，与运行在主机操作系统上潜在的虚拟化机制交互的驱动，暴露基于Web API的功能。

OpenStack Object Storage，是一个可扩展的对象存储系统。对象存储支持多种应用，比如复制和存档数据，图像或视频服务，存储次级静态数据，开发数据存储整合的新应用，存储容量难以估计的数据，为Web应用创建基于云的弹性存储。

OpenStack Image Service，是一个虚拟机镜像的存储、查询和检索系统，服务包括的RESTful API允许用户通过HTTP请求查询VM镜像元数据，以及检索实际的镜像。VM镜像有四种配置方式：简单的文件系统，类似OpenStack Object Storage的对象存储系统，直接用Amazon's Simple Storage Solution (S3) 存储，用带有Object Store的S3间接访问S3。

云服务提供商的概念架构

OpenStack能帮我们建立自己的IaaS，提供类似Amazon Web Service的服务给客户。为实现这一点，我们需要提供几个高级特性：

1. 允许应用拥有者注册云服务，查看运用和计费情况；
2. 允许Developers/DevOps folks创建和存储他们应用的自定义镜像；
3. 允许他们启动、监控和终止实例；
4. 允许Cloud Operator配置和操作基础架构

这四点都直击提供IaaS的核心，现在假设你同意了这四个特性，现在就可以将它们放进如下所示的概念架构中。

在此模型中，作者假设了需要与云交互的四个用户集：developers, devops, owners and operators，并为每类用户划分了他们所需要的功能。该架构采用的是非常普通的分层方法（presentation, logic and resources），它带有两个正交区域。

展示层，组件与用户交互，接受和呈现信息。Web portals为非开发者提供图形界面，为开发者提供API端点。如果是更复杂的结构，负载均衡，控制代理，安全和名称服务也都会在这层。

逻辑层为云提供逻辑（intelligence）和控制功能。这层包括部署（复杂任务的工作流），调度（作业到资源的映射），策略（配额等等），镜像注册image registry (实例镜像的元数据)，日志 (事件和计量) 。

假设绝大多数服务提供者已经有客户身份和计费系统，任何云架构都需要整合这些系统。

在任何复杂的环境下，我们都将需要一个management层来操作这个环境。它应该包括一个API访问云管理特性以及一些监控形式（forms）。很可能，监控功能将以整合的形式加入一个已存在的工具中。当前的架构中已经为我们虚拟的服务提供商加入了monitoring和admin API，在更完全的架构中，你将见到一系列的支持功能，比如provisioning和 configuration management。

最后，资源层。既然这是一个compute云，我们就需要实际的compute、network 和 storage资源，以供应给我们的客户。该层提供这些服务，无论他们是服务器，网络交换机，NAS（network attached storage）还是其他的一些资源。

二、OpenStack架构

OpenStack 每半年会发布一个版本，版本以字母顺序命名。现在已经到第 12 个版本 Liberty（字母 L）。 OpenStack最初只有两个模块（服务），现在已经有 20+（见下图），每个模块作为独立的子项目开发。

面对如此庞大的阵容，OpenStack的核心是什么呢？

作为 IaaS 层的云操作系统，OpenStack 为虚拟机提供并管理三大类资源：计算、网络和存储。

这三个就是核心，所以我们的学习重点就是： 搞清楚 OpenStack 是如何对计算、网络和存储资源进行管理的。 在 20+ 模块中，管理这三类资源的核心模块其实不多，这几个模块就是我们的重点了。

要达到这个目的，我们自然需要研究 OpenStack 的整体架构。 架构里哪些核心模块负责管理计算资源、网络资源和存储资源？模块之间如何协调工作？ 同时我们会构建一个实验环境，进到各个模块的内部，通过实际操作真正理解和掌握 OpenStack。

架构是个好东西，它能帮助我们站在高处看清楚事物的整体结构，避免过早地进入细节而迷失方向。

下图是 OpenStack 的 Conceptual Architecture

核心模块：

中间菱形是虚拟机，围绕 VM 的那些长方形代表 OpenStack 不同的模块（OpenStack 叫服务，后面都用服务这个术语），下面来分别介绍。

 计算服务 - Nova：管理 VM 的生命周期，是 OpenStack 中最核心的服务。

网络服务 - Neutron：为 OpenStack 提供网络连接服务，负责创建和管理L2、L3 网络，为 VM 提供虚拟网络和物理网络连接。

镜像服务 - Glance：管理 VM 的启动镜像，Nova 创建 VM 时将使用 Glance 提供的镜像。

块存储服务 - Cinder：为 VM 提供块存储服务。Cinder 提供的每一个 Volume 在 VM 看来就是一块虚拟硬盘，一般用作数据盘。
 Swift：提供对象存储服务。VM 可以通过 RESTful API 存放对象数据。作为可选的方案，Glance 可以将镜像存放在 Swift 中；Cinder 也可以将 Volume 备份到 Swift 中。

认证服务 - Keystone：为 OpenStack 的各种服务提供认证和权限管理服务。简单的说，OpenStack 上的每一个操作都必须通过 Keystone 的审核。

监控服务 - Ceilometer：提供 OpenStac k监控和计量服务，为报警、统计或计费提供数据。

UI服务 - Horizon：为 OpenStack 用户提供一个 Web 的自服务 Portal。

对象存储服务 - Swift 

集群服务 - Heat

数据库服务 - Trove

在上面的这些服务中，哪些是 OpenStack 的核心服务呢？ 核心服务就是如果没有它，OpenStack 就跑不起来。 很显然

1. Nova 管理计算资源，是核心服务。

2. Neutron 管理网络资源，是核心服务。

3. Glance 为 VM 提供 OS 镜像，属于存储范畴，是核心服务。

4. Cinder 提供块存储，VM怎么也得需要数据盘吧，是核心服务。

5. Swift 提供对象存储，不是必须的，是可选服务。

6. Keystone 认证服务，没它 OpenStack 转不起来，是核心服务。

7. Ceilometer 监控服务，不是必须的，可选服务。

8. Horizon 大家都需要一个操作界面吧。

现在核心服务有了，接下来我们将镜头拉近点，看看核心服务内部的组成结构。

逻辑架构：

在 Logical Architecture 中，可以看到每个服务又由若干组件组成，以 Neutron 为例，包含。

1. Neutron Server、Neutron plugins 和 Neutron agents

2. Network provider

3. 消息队列 Queue

4. 数据库 Neutron Database

在后面 Neutron 章节我们会展开学习这些组件。

这里想要强调一点： 上面是 Logical Architecture，描述的是 Neutron 服务各个组成部分以及各组件之间的逻辑关系。 而在实际的部署方案上，各个组件可以部署到不同的物理节点上。

OpenStack Compute逻辑架构

OpenStack Compute逻辑架构中，组件中的绝大多数可分为两种自定义编写的Python守护进程（custom written python daemons）。

1. 接收和协调API调用的WSGI应用（nova-api, glance-api, etc）
2. 执行部署任务的Worker守护进程（nova-compute, nova-network, nova-schedule, etc.）

然而，逻辑架构中有两个重要的部分，既不是自定义编写，也不是基于Python，它们是消息队列和数据库。二者简化了复杂任务（通过消息传递和信息共享的任务）的异步部署。

逻辑架构图如下所示：

 从图中，我们可以总结出：

1. 终端用户（DevOps, Developers 和其他的 OpenStack 组件）通过和nova-api对话来与OpenStack Compute交互。
2. OpenStack Compute守护进程之间通过队列（行为）和数据库（信息）来交换信息，以执行API请求。
3. OpenStack Glance基本上是独立的基础架构，OpenStack Compute通过Glance API来和它交互。

其各个组件的情况如下：

1. nova-api守护进程是OpenStack Compute的中心。它为所有API查询（OpenStack API 或 EC2 API）提供端点，初始化绝大多数部署活动（比如运行实例），以及实施一些策略（绝大多数的配额检查）。
2. nova-compute进程主要是一个创建和终止虚拟机实例的Worker守护进程。其过程相当复杂，但是基本原理很简单：从队列中接收行为，然后在更新数据库的状态时，执行一系列的系统命令执行他们。
3. nova-volume管理映射到计算机实例的卷的创建、附加和取消。这些卷可以来自很多提供商，比如，ISCSI和AoE。
4. Nova-network worker守护进程类似于nova-compute和nova-volume。它从队列中接收网络任务，然后执行任务以操控网络，比如创建bridging interfaces或改变iptables rules。
5. Queue提供中心hub，为守护进程传递消息。当前用RabbitMQ实现。但是理论上能是python ampqlib支持的任何AMPQ消息队列。
6. SQL database存储云基础架构中的绝大多数编译时和运行时状态。这包括了可用的实例类型，在用的实例，可用的网络和项目。理论上，OpenStack Compute能支持SQL-Alchemy支持的任何数据库，但是当前广泛使用的数据库是sqlite3（仅适合测试和开发工作），MySQL和PostgreSQL。
7. OpenStack Glance，是一个单独的项目，它是一个compute架构中可选的部分，分为三个部分：glance-api, glance-registry and the image store. 其中，glance-api接受API调用，glance-registry负责存储和检索镜像的元数据，实际的Image Blob存储在Image Store中。Image Store可以是多种不同的Object Store，包括OpenStack Object Storage (Swift)
8. 最后，user dashboard是另一个可选的项目。OpenStack Dashboard提供了一个OpenStack Compute界面来给应用开发者和devops staff类似API的功能。当前它是作为Django web Application来实现的。当然，也有其他可用的Web前端。

OpenStack Compute由一些主要组件组成。“Cloud controller”包含很多组件，它表示全局状态，以及与其他组件交互。实际上，它提供的是Nova-api服务。它的功能是：为所有API查询提供一个端点，初始化绝大多数的部署活动，以及实施一些策略。API 服务器起cloud controller web Service前端的作用。Compute controller 提供compute服务资源，典型包含compute service，Object Store component可选地提供存储服务。Auth manager提供认证和授权服务，Volume controller为compute servers提供快速和持久的块级别存储。Network controller提供虚拟网络使compute servers彼此交互以及与公网进行交互。Scheduler选择最合适的compute controller来管理（host）一个实例。

OpenStack Compute建立在无共享、基于消息的架构上。Cloud controller通过HTTP与internal object store交互，通过AMQP和scheduler、network controller、 和volume controller 来进行通信。为了避免在等待接收时阻塞每个组件，OpenStack Compute用异步调用的方式。

为了获得带有一个组件多个备份的无共享属性，OpenStack Compute将所有的云系统状态保持在分布式的数据存储中。对系统状态的更新会写到这个存储中，必要时用质子事务。

对系统状态的请求会从store中读出。在少数情况下，控制器也会短时间缓存读取结果。

OpenStack 本身是一个分布式系统，不但各个服务可以分布部署，服务中的组件也可以分布部署。 这种分布式特性让 OpenStack 具备极大的灵活性、伸缩性和高可用性。 当然从另一个角度讲，这也使得 OpenStack 比一般系统复杂，学习难度也更大。

OpenStack Compute采用无共享、基于消息的架构，非常灵活，我们能安装每个nova- service在单独的服务器上，这意味着安装OpenStack Compute有多种可能的方法。可能多结点部署唯一的联合依赖性，是Dashboard必须被安装在nova-api服务器。几种部署架构如下：

1. 单结点：一台服务器运行所有的nova- services，同时也驱动虚拟实例。这种配置只为尝试OpenStack Compute，或者为了开发目的；
2. 双结点：一个cloud controller 结点运行除nova-compute外的所有nova-services，compute结点运行nova-compute。一台客户计算机很可能需要打包镜像，以及和服务器进行交互，但是并不是必要的。这种配置主要用于概念和开发环境的证明。
3. 多结点：通过简单部署nova-compute在一台额外的服务器以及拷贝nova.conf文件到这个新增的结点，你能在两结点的基础上，添加更多的compute结点，形成多结点部署。在较为复杂的多结点部署中，还能增加一个volume controller 和一个network controller作为额外的结点。对于运行多个需要大量处理能力的虚拟机实例，至少是4个结点是最好的。

一个可能的Openstack Compute多服务器部署（集群中联网的虚拟服务器可能会改变）

 如果你注意到消息队列中大量的复制引发了性能问题，一种可选的架构是增加更多的Messaging服务器。在这种情形下，除了可以扩展数据库服务器外，还可以增加一台额外的RabbitMQ服务器。部署中可以在任意服务器上运行任意nova-service，只要nova.conf中配置为指向RabbitMQ服务器，并且这些服务器能发送消息到它。

多结点的部署架构

Openstack的网络拓扑结构图

​

整个OpenStack是由控制节点，计算节点，网络节点，存储节点四大部分组成。

这四个节点也可以安装在一台机器上，单机部署。

其中：

• 控制节点负责对其余节点的控制，包含虚拟机建立，迁移，网络分配，存储分配等等
• 计算节点负责虚拟机运行
• 网络节点负责对外网络与内网络之间的通信
• 存储节点负责对虚拟机的额外存储管理等等

1. 控制节点架构

控制节点包括以下服务

管理支持服务

基础管理服务

扩展管理服务

1）管理支持服务包含MySQL与Qpid两个服务

MySQL：数据库作为基础/扩展服务产生的数据存放的地方

Qpid：消息代理(也称消息中间件)为其他各种服务之间提供了统一的消息通信服务

2）基础管理服务包含Keystone，Glance，Nova，Neutron，Horizon五个服务

Keystone：认证管理服务，提供了其余所有组件的认证信息/令牌的管理，创建，修改等等，使用MySQL作为统一的数据库

Glance：镜像管理服务，提供了对虚拟机部署的时候所能提供的镜像的管理，包含镜像的导入，格式，以及制作相应的模板

Nova：计算管理服务，提供了对计算节点的Nova的管理，使用Nova-API进行通信

Neutron：网络管理服务，提供了对网络节点的网络拓扑管理，同时提供Neutron在Horizon的管理面板

Horizon：控制台服务，提供了以Web的形式对所有节点的所有服务的管理，通常把该服务称为DashBoard

3）扩展管理服务包含Cinder，Swift，Trove，Heat，Centimeter五个服务

Cinder：提供管理存储节点的Cinder相关，同时提供Cinder在Horizon中的管理面板

Swift：提供管理存储节点的Swift相关，同时提供Swift在Horizon中的管理面板

Trove：提供管理数据库节点的Trove相关，同时提供Trove在Horizon中的管理面板

Heat：提供了基于模板来实现云环境中资源的初始化，依赖关系处理，部署等基本操作，也可以解决自动收缩,负载均衡等高级特性。

Centimeter：提供对物理资源以及虚拟资源的监控，并记录这些数据，对该数据进行分析，在一定条件下触发相应动作

控制节点一般来说只需要一个网络端口用于通信/管理各个节点

2. 网络节点架构

网络节点仅包含Neutron服务

Neutron：负责管理私有网段与公有网段的通信，以及管理虚拟机网络之间的通信/拓扑，管理虚拟机之上的防火等等

网络节点包含三个网络端口

eth0：用于与控制节点进行通信

eth1：用于与除了控制节点之外的计算/存储节点之间的通信

eth2：用于外部的虚拟机与相应网络之间的通信

3. 计算节点架构

计算节点包含Nova，Neutron，Telemeter三个服务

1）基础服务

Nova：提供虚拟机的创建，运行，迁移，快照等各种围绕虚拟机的服务，并提供API与控制节点对接，由控制节点下发任务

Neutron：提供计算节点与网络节点之间的通信服务

2）扩展服务

Telmeter：提供计算节点的监控代理，将虚拟机的情况反馈给控制节点，是Centimeter的代理服务

计算节点包含最少两个网络端口

eth0：与控制节点进行通信，受控制节点统一调配

eth1：与网络节点，存储节点进行通信

4.存储节点架构

存储节点包含Cinder，Swift等服务

Cinder：块存储服务，提供相应的块存储，简单来说，就是虚拟出一块磁盘，可以挂载到相应的虚拟机之上，不受文件系统等因素影响，对虚拟机来说，这个操作就像是新加了一块硬盘，可以完成对磁盘的任何操作，包括挂载，卸载，格式化，转换文件系统等等操作，大多应用于虚拟机空间不足的情况下的空间扩容等等

Swift：对象存储服务，提供相应的对象存储，简单来说，就是虚拟出一块磁盘空间，可以在这个空间当中存放文件，也仅仅只能存放文件，不能进行格式化，转换文件系统，大多应用于云磁盘/文件

存储节点包含最少两个网络接口

eth0：与控制节点进行通信，接受控制节点任务，受控制节点统一调配

eth1：与计算/网络节点进行通信，完成控制节点下发的各类任务

三、OpenStack各组件详解

1. OpenStack认证服务（Keystone）

Keystone为所有的OpenStack组件提供认证和访问策略服务，它依赖自身REST（基于Identity API）系统进行工作，主要对（但不限于）Swift、Glance、Nova等进行认证与授权。事实上，授权通过对动作消息来源者请求的合法性进行鉴定。下图显示了身份认证服务流程：​Keystone采用两种授权方式，一种基于用户名/密码，另一种基于令牌（Token）。

除此之外，Keystone提供以下三种服务：
令牌服务：含有授权用户的授权信息
目录服务：含有用户合法操作的可用服务列表
策略服务：利用Keystone具体指定用户或群组某些访问权限

keystone认证服务注意点：

服务入口：如Nova、Swift和Glance一样每个OpenStack服务都拥有一个指定的端口和专属的URL，我们称其为入口（endpoints）。

区位：在某个数据中心，一个区位具体指定了一处物理位置。在典型的云架构中，如果不是所有的服务都访问分布式数据中心或服务器的话，则也称其为区位。

用户：Keystone授权使用者
　　PS：代表一个个体，OpenStack以用户的形式来授权服务给它们。用户拥有证书（credentials），且可能分配给一个或多个租户。经过验证后，会为每个单独的租户提供一个特定的令牌。

服务：总体而言，任何通过Keystone进行连接或管理的组件都被称为服务。举个例子，我们可以称Glance为Keystone的服务。

角色：为了维护安全限定，就云内特定用户可执行的操作而言，该用户关联的角色是非常重要的。
　　PS：一个角色是应用于某个租户的使用权限集合，以允许某个指定用户访问或使用特定操作。角色是使用权限的逻辑分组，它使得通用的权限可以简单地分组并绑定到与某个指定租户相关的用户。

租间：租间指的是具有全部服务入口并配有特定成员角色的一个项目。
　　PS：一个租间映射到一个Nova的“project-id”，在对象存储中，一个租间可以有多个容器。根据不同的安装方式，一个租间可以代表一个客户、帐号、组织或项目。

 2. OpenStack计算设施----Nova

Nova是OpenStack计算的弹性控制器。OpenStack云实例生命期所需的各种动作都将由Nova进行处理和支撑，这就意味着Nova以管理平台的身份登场，负责管理整个云的计算资源、网络、授权及测度。虽然Nova本身并不提供任何虚拟能力，但是它将使用libvirt API与虚拟机的宿主机进行交互。Nova通过Web服务API来对外提供处理接口，而且这些接口与Amazon的Web服务接口是兼容的。

功能及特点：　
实例生命周期管理
计算资源管理
网络与授权管理
基于REST的API
异步连续通信
支持各种宿主：Xen、XenServer/XCP、KVM、UML、VMware vSphere及Hyper-V

Nova弹性云（OpenStack计算部件）包含以下主要部分：

API Server（nova-api）
消息队列（rabbit-mq server）
运算工作站（nova-compute）
网络控制器（nova-network）
卷管理（nova-volume）
调度器（nova-scheduler）

解释如下：

1）API服务器（nova-api）
API服务器提供了云设施与外界交互的接口，它是外界用户对云实施管理的唯一通道。通过使用web服务来调用各种EC2的API，接着API服务器便通过消息队列把请求送达至云内目标设施进行处理。作为对EC2-api的替代，用户也可以使用OpenStack的原生API，我们把它叫做“OpenStack API”。

2）消息队列（Rabbit MQ Server）
OpenStack内部在遵循AMQP（高级消息队列协议）的基础上采用消息队列进行通信。Nova对请求应答进行异步调用，当请求接收后便则立即触发一个回调。由于使用了异步通信，不会有用户的动作被长置于等待状态。例如，启动一个实例或上传一份镜像的过程较为耗时，API调用就将等待返回结果而不影响其它操作，在此异步通信起到了很大作用，使整个系统变得更加高效。

3）调度器（nova-scheduler）

调度器负责把nova-API调用送达给目标。调度器以名为“nova-schedule”的守护进程方式运行，并根据调度算法从可用资源池中恰当地选择运算服务器。有很多因素都可以影响调度结果，比如负载、内存、子节点的远近、CPU架构等等。强大的是nova调度器采用的是可插入式架构。

目前nova调度器使用了几种基本的调度算法：
　　随机化：主机随机选择可用节点；
　　可用化：与随机相似，只是随机选择的范围被指定；
　　简单化：应用这种方式，主机选择负载最小者来运行实例。负载数据可以从别处获得，如负载均衡服务器。

4）运算工作站（nova-compute）
运算工作站的主要任务是管理实例的整个生命周期。他们通过消息队列接收请求并执行，从而对实例进行各种操作。在典型实际生产环境下，会架设许多运算工作站，根据调度算法，一个实例可以在可用的任意一台运算工作站上部署。

5）网络控制器（nova-network）
网络控制器处理主机的网络配置，例如IP地址分配，配置项目VLAN，设定安全群组以及为计算节点配置网络。

6）卷工作站（nova-volume）　
卷工作站管理基于LVM的 实例卷，它能够为一个实例创建、删除、附加卷，也可以从一个实例中分离卷。卷管理为何如此重要？因为它提供了一种保持实例持续存储的手段，比如当结束一个 实例后，根分区如果是非持续化的，那么对其的任何改变都将丢失。可是，如果从一个实例中将卷分离出来，或者为这个实例附加上卷的话，即使实例被关闭，数据 仍然保存其中。这些数据可以通过将卷附加到原实例或其他实例的方式而重新访问。

因此，为了日后访问，重要数据务必要写入卷中。这种应用对于数据服务器实例的存储而言，尤为重要。

3. OpenStack镜像服务器----Glance

OpenStack镜像服务器是一套虚拟机镜像发现、注册、检索系统，我们可以将镜像存储到以下任意一种存储中：
本地文件系统（默认）
S3直接存储
S3对象存储（作为S3访问的中间渠道）
OpenStack对象存储等等。

功能及特点：
提供镜像相关服务。

Glance构件：
1）Glance-API：
　 主要负责接收响应镜像管理命令的Restful请求，分析消息请求信息并分发其所带的命令（如新增，删除，更新等）。默认绑定端口是9292。
2）Glance-Registry：
　　主要负责接收响应镜像元数据命令的Restful请求。分析消息请求信息并分发其所带的命令（如获取元数据，更新元数据等）。默认绑定的端口是9191。

OpenStack Image Service包括两个主要的部分，分别是API server和Registry server(s)。

OpenStack Image Service的设计，尽可能适合各种后端仓储和注册数据库方案。API Server（运行“glance api”程序）起通信hub的作用。比如各种各样的客户程序，镜像元数据的注册，实际包含虚拟机镜像数据的存储系统，都是通过它来进行通信的。API server转发客户端的请求到镜像元数据注册处和它的后端仓储。OpenStack Image Service就是通过这些机制来实际保存进来的虚拟机镜像的。

OpenStack Image Service支持的后端仓储有：

1. OpenStack Object Storage。它是OpenStack中高可用的对象存储项目。
2. FileSystem。OpenStack Image Service存储虚拟机镜像的默认后端是后端文件系统。这个简单的后端会把镜像文件写到本地文件系统。
3. S3。该后端允许OpenStack Image Service存储虚拟机镜像在Amazon S3服务中。
4. HTTP。OpenStack Image Service能通过HTTP在Internet上读取可用的虚拟机镜像。这种存储方式是只读的。

OpenStack Image Service registry servers是遵守OpenStack Image Service Registry  API的服务器。

根据安装手册，这两个服务安装在同一个服务器上。镜像本身则可存储在OpenStack Object Storage， Amazon's S3 infrastructure，fileSystem。如果你只需要只读访问，可以存储在一台Web服务器上。

4. OpenStack存储设施----Swift

Swift为OpenStack提供一种分布式、持续虚拟对象存储，它类似于Amazon Web Service的S3简单存储服务。Swift具有跨节点百级对象的存储能力。Swift内建冗余和失效备援管理，也能够处理归档和媒体流，特别是对大数据（千兆字节）和大容量（多对象数量）的测度非常高效。

swift功能及特点：　　
海量对象存储
大文件（对象）存储
数据冗余管理
归档能力-----处理大数据集
为虚拟机和云应用提供数据容器
处理流媒体
对象安全存储
备份与归档
良好的可伸缩性

Swift组件
Swift账户
Swift容器
Swift对象
Swift代理
Swift RING
　　
Swift代理服务器　　
用户都是通过Swift-API与代理服务器进行交互，代理服务器正是接收外界请求的门卫，它检测合法的实体位置并路由它们的请求。
此外，代理服务器也同时处理实体失效而转移时，故障切换的实体重复路由请求。

Swift对象服务器
对象服务器是一种二进制存储，它负责处理本地存储中的对象数据的存储、检索和删除。对象都是文件系统中存放的典型的二进制文件，具有扩展文件属性的元数据（xattr）。

注意：xattr格式被Linux中的ext3/4，XFS，Btrfs，JFS和ReiserFS所支持，但是并没有有效测试证明在XFS，JFS，ReiserFS，Reiser4和ZFS下也同样能运行良好。不过，XFS被认为是当前最好的选择。

Swift容器服务器
容器服务器将列出一个容器中的所有对象，默认对象列表将存储为SQLite文件（译者注：也可以修改为MySQL，安装中就是以MySQL为例）。容器服务器也会统计容器中包含的对象数量及容器的存储空间耗费。

Swift账户服务器
账户服务器与容器服务器类似，将列出容器中的对象。

Object Storage如何工作 ?

1. Ring（索引环）

Ring容器记录着Swift中物理存储对象的位置信息，它是真实物理存储位置的实体名的虚拟映射，类似于查找及定位不同集群的实体真实物理位置的索引服务。这里所谓的实体指账户、容器、对象，它们都拥有属于自己的不同的Rings。

Ring 代表磁盘上存储的实体的名称和它们的物理位置的映射。accounts, containers, and objects都有单独的Ring。其他组件要在这三者之一进行任何操作，他们都需要合相应的Ring进行交互以确定它在集群中的位置。

Ring用zones，devices，partitions，和replicas来维护映射，在Ring中的每个分区都会在集群中默认有三个副本。分区的位置存储在Ring维护的映射中。Ring也负责确定失败场景中接替的设备。（这点类似HDFS副本的复制）。分区的副本要保证存储在不同的zone。Ring的分区分布在OpenStack Object Storage installation所有设备中。分区需要移动的时候，Ring确保一次移动最少的分区，一次仅有一个分区的副本被移动。

权重能用来平衡分区在磁盘驱动上的分布。Ring在代理服务器和一些背景进程中使用。

2. Proxy Server

代理服务器负责将OpenStack Object Storage架构中其他部分结合在一起。对于每次请求，它都查询在Ring中查询account, container, or object的位置，并以此转发请求。公有APIs也是通过代理服务器来暴露的。

大量的失败也是由代理服务器来进行处理。比如一个服务器不可用，它就会要求Ring来为它找下一个接替的服务器，并把请求转发到那里。

当对象流进或流出object server时，它们都通过代理服务器来流给用户，或者通过它从用户获取。代理服务器不会缓冲它们。

Proxy服务器的功能可以总结为：查询位置，处理失败，中转对象。

3. Object Server

Object Server，是非常简单的blob存储服务器，能存储、检索和删除本地磁盘上的对象，它以二进制文件形式存放在文件系统中，元数据以文件的扩展属性存放。

对象以源于对象名的hash和操作的时间戳的路径来存放。上一次写总会成功，确保最新的版本将被使用。删除也视作文件的一个版本：这确保删除的文件也被正确复制，更旧的把本不会因为失败情形离奇消失。

4. Container Server

其主要工作是处理对象列表，它不知道对象在哪里，只是知道哪些对象在一个特定的container。列表被存储为sqlite 数据库文件，类似对象的方式在集群中复制。也进行了跟踪统计，包括对象的总数，以及container中使用的总存储量。

5. Account Server

 它是类似于Container Server，除了它是负责containers的列表而非对象。

6. Replication

设计副本的目的是，在面临网络中断或驱动失败等临时错误条件时，保持系统在一致的状态。

副本进程会比较本地的数据和每个远处的副本，以确保他们所有都包含最新的版本。对象副本用一个Hash列表来快速比较每个分区的片段，而containe和 account replication 用的是Hash和共享的高水印结合的方法。

副本的更新，是基于推送的。对于对象副本，更新是远程同步文件到Peer。Account和container replication通过HTTP or rsync把整个数据库文件推送遗失的记录。

副本也通过tombstone设置最新版本的方式，确保数据从系统中清除。

7. 更新器（Updaters）

有时，container 或 account数据不能被立即更新，这通常是发生在失败的情形或高负载时期。如果一个更新失败，该更新会在文件系统上本地排队，更新器将处理这些失败的更新。事件一致性窗口（eventual consistency window）最可能来起作用。比如，假设一个container服务器正处于载入之中，一个新对象正被放进系统，代理服务器一响应客户端成功，该对象就立即可读了。然而，container服务器没有更新Object列表，所以更新就进入队列，以等待稍后的更新。Container列表，因此可能还不会立即包含这个对象。

实际上，一致性窗口只是与updater运行的频率一样大，当代理服务器将转发清单请求到响应的第一个container服务器中，也许甚至还不会被注意。在载入之下的服务器可能还不是服务后续清单请求的那个。另外两个副本中的一个可能处理这个清单。

8. Auditors

Auditors会检查objects, containers, 和 accounts的完整性。如果发先损坏的文件，它将被隔离，好的副本将会取代这个坏的文件。如果发现其他的错误，它们会记入到日志中。

Proxy Services  偏向于CPU和network I/O 密集型，而 Object Services， Container Services， Account Services  偏向于disk and networkI/O 密集型。

可以在每一服务器上安装所有的服务，在Rackspace内部， 他们将Proxy Services放在他们自己的服务器上，而所有存储服务则放在同一服务器上。这允许我们发送10G的网络给代理，1G给存储服务器，从而保持对代理服务器的负载平衡更好管理。我们能通过增加更多代理来扩展整个API吞吐量。如果需要获得Account或 Container Services更大的吞吐量，它们也可以部署到自己的服务器上。

在部署OpenStack Object Storage时，可以单结点安装，但是它只适用于开发和测试目的。也可以多服务器的安装，它能获得分布式对象存储系统需要的高可用性和冗余。

有这样一个样本部署架构，如图5-1所示。一个Proxy 结点，运行代理服务，一个Auth 结点，运行认证服务，五个Storage结点，运行Account，Container和Object服务。

 

5. OpenStack管理的Web接口----Horizon

Horizon是一个用以管理、控制OpenStack服务的Web控制面板，它可以管理实例、镜像、创建密匙对，对实例添加卷、操作Swift容器等。除此之外，用户还可以在控制面板中使用终端（console）或VNC直接访问实例。

总之，Horizon具有如下一些特点：　　
实例管理：创建、终止实例，查看终端日志，VNC连接，添加卷等
访问与安全管理：创建安全群组，管理密匙对，设置浮动IP等
偏好设定：对虚拟硬件模板可以进行不同偏好设定
镜像管理：编辑或删除镜像
查看服务目录
管理用户、配额及项目用途
用户管理：创建用户等
卷管理：创建卷和快照
对象存储处理：创建、删除容器和对象
为项目下载环境变量