OpenStack 其实有三个与存储相关的组件，这三个组件被人熟知的程度和组件本身出现时间的早晚是相符的，按熟悉程度排列如下：
Swift—提供对象存储（Object Storage），在概念上类似于 Amazon S3 服务，
不过 swift 具有很强的扩展性、冗余和持久性，也兼容 S3 API。对象存储支持多种应用，比如复制和存档数据、图像或视频服务，存储次级静态数据，开发数据存储整合的新应用，存储容量难以
估计的数据，为 Web 应用创建基于云的弹性存储。 Glance—提供虚机镜像（Image）存储和管理，它能够以三种形式加以配置：利用 OpenStack 对象存储机制来存储镜像；利用 Amazon 的简单存储解决方案（简称 S3）直接存储信息；或者将 S3 存储与对象存储结合起来，作为 S3 访问的连接器。OpenStack 镜像服务支持多种虚拟机镜像格式，包括 VMware（VMDK）、Amazon 镜像（AKI、ARI、AMI）以及 VirtualBox 所支持的各种磁盘格式。镜像元数据的容器格式包括 Amazon 的 AKI、ARI 以及 AMI 信息，标准 OVF 格式以及二进制大型数据。 Cinder--提供块存储（Block Storage），类似于 Amazon 的 EBS 块存储服务，OpenStack 中的实例是不能持久化的，需要挂载 volume，在 volume 中实现持久化。Cinder 就是提供对 volume 实际需要的存储块单元的实现管理功能。 Amazon 一直是 OpenStack 设计之初的假想对手和挑战对象，所以基本上关键的功能模块都有对应项目。除了上面提到的三个组件，对于 AWS 中的重要的 EC2 服务，OpenStack 中是 Nova 来对应，并且保持和 EC2 API 的兼容性，有不同的方法可以实现。
三个组件中，Glance 主要是虚机镜像的管理，所以相对简单；Swift 作为对象存储已经很成熟，连 CloudStack 也支持它。Cinder 是比较新出现的块存储，设计理念不错，并且和商业存储有结合的机会，所以厂商比较积极。
存储项目和组件对应关系如下面表格：
表 1.对应关系
项目 组件 描述 对应 Amazon 产品 Swift Object Storage as a service 对象存储 Amazon S3 Glance Image as a service VM
磁盘镜像存储和管理 Amazon AMI catalog Cinder Block Storage as a service 块存储 Amazon EBS
OpenStack 对象存储—Swift
OpenStack Object Storage（Swift）是 OpenStack 开源云计算项目的子项目之一,被称为对象存储，提供了强大的扩展性、冗余和持久性。 Swift 并不是文件系统或者实时的数据存储系统，它称为对象存储，用于永久类型的静态数据的长期存储，这些数据可以检索、调整，必要时进行更新。Swift 前身是 Rackspace Cloud Files 项目，随着 Rackspace 加入到 OpenStack 社区，于 2010 年 7 月贡献给 OpenStack，作为该开源项目的一部分。Swift 目前的最新版本是OpenStack Havana。Havana 版本中 Swift 新增特性如下：
Multiple-Region-Replication：支持对象异地复制容灾。 Memcache：增加对轮询 Memcache 连接的支持。 More-Optimization：并发 IO 支持，多网段分流支持，在多地复制情况下加强不同 Proxy-Server 的亲和度。
Swift 特性
在 OpenStack 官网中，列举了很多 Swift 特性，其中最引人关注的是以下几点。
极高的数据持久性
一些朋友经常将数据持久性（Durability）与系统可用性（Availability）两个概念混淆，前者也理解为数据的可靠性，是指数据存储到系统中后，到某一天数据丢失的可能性。例如 Amazon S3 的数据持久性是 11 个 9，即如果存储 1 万（4 个 0）个文件到 S3 中，1 千万（7 个 0）年之后，可能会丢失其中 1 个文件。那么 Swift 能提供多少个 9 的 SLA 呢？下文会给出答案。针对 Swift 在新浪测试环境中的部署，他们从理论上测算过，Swift 在 5 个 Zone、5×10 个存储节点的环境下，数据复制份是为 3，数据持久性的 SLA 能达到 10 个 9。
完全对称的系统架构
“对称”意味着 Swift 中各节点可以完全对等，能极大地降低系统维护成本。
无限的可扩展性
这里的扩展性分两方面，一是数据存储容量无限可扩展；二是 Swift 性能（如 QPS、吞吐量等）可线性提升。因为 Swift 是完全对称的架构，扩容只需简单地新增机器，系统会自动完成数据迁移等工作，使各存储节点重新达到平衡状态。
无单点故障
在互联网业务大规模应用的场景中，存储的单点一直是个难题。例如数据库，一般的 HA 方法只能做主从，并且“主”一般只有一个；还有一些其他开源存储系统的实现中，元数据信息的存储一直以来是个头痛的地方，一般只能单点存储，而这个单点很容易成为瓶颈，并且一旦这个点出现差异，往往能影响到整个集群，典型的如 HDFS。而 Swift 的元数据存储是完全均匀随机分布的，并且与对象文件存储一样，元数据也会存储多份。整个 Swift 集群中，也没有一个角色是单点的，并且在架构和设计上保证无单点业务是有效的。
简单、可依赖
简单体现在架构优美、代码整洁、实现易懂，没有用到一些高深的分布式存储理论，而是很简单的原则。可依赖是指 Swift 经测试、分析之后，可以放心大胆地将 Swift 用于最核心的存储业务上，而不用担心 Swift 捅篓子，因为不管出现任何问题，都能通过日志、阅读代码迅速解决。
Swift 架构概述
Swift Architectural主要有三个组成部分：Proxy Server、Storage Server 和 Consistency Server。其架构如图 1 所示，其中 Storage 和 Consistency 服务均允许在 Storage Node 上。Auth 认证服务目前已从 Swift 中剥离出来，使用 OpenStack 的认证服务 Keystone，目的在于实现统一 OpenStack 各个项目间的认证管理。
图 1. Swift 架构
主要组件
Proxy Server
Proxy Server 是提供 Swift API 的服务器进程，负责 Swift 其余组件间的相互通信。对于每个客户端的请求，它将在 Ring 中查询 Account、Container 或 Object 的位置，并且相应地转发请求。Proxy 提供了 REST API，并且符合标准的 HTTP 协议规范，这使得开发者可以快捷构建定制的 Client 与 Swift 交互。