OpenStack Object Storage（Swift）架构、原理及特性

摘要： 简介 OpenStack Object Storage（Swift）是OpenStack开源云计算项目的子项目之一。Swift使用普通的服务器来构建冗余的、可扩展的分布式对象存储集群，存储容量可达PB级。

简介

OpenStack Object Storage（Swift）是OpenStack开源云计算项目的子项目之一。Swift使用普通的服务器来构建冗余的、可扩展的分布式对象存储集群，存储容量可达PB级。Swift的是用Python开发，前身是Rackspace Cloud Files项目，随着Rackspace加入到OpenStack社区，Racksapce也将Cloud Files的代码贡献给了社区，并逐渐形成现在Swift。Swift最新的发型版本为essex 1.4.6。

功能

Swift提供的服务与AWS S3基本相同，可以用以下用途：

  • 作为IaaS的存储服务
  • 与OpenStack Compute对接，为其存储镜像
  • 文档存储
  • 存储需要长期保存的数据，例如log
  • 存储网站的图片，缩略图等

· 存储媒体库(照片、音乐、视频等) 

· 视频监控文件的存档 

· 电话呼叫音频记录的存档 

· 压缩日志文件的存档 

· 备份存档(每个对象<5GB) 

· 存储和加载系统的镜像文件等 

· 存储数量不断增加基数庞大的文件

· 存储小型文件擅长于此. 

· 存储数以亿计的文件. 

· 存储PB级别的数据.

Swift使用RESTful API对外提供服务，目前 1.4.6版本所提供的功能:

  • Account（存储账户）的GET、HEAD
  • Container（存储容器，与S3的bucket相同）的GET、PUT、HEAD、DELETE
  • Object（存储对象）的GET、PUT、HEAD、DELETE、DELETE
  • Account、Container、Object的元数据支持
  • 大文件（无上限，单个无文件最大5G，大于5G的文件在客户端切分上传，并上传manifest文件）、
  • 访问控制、权限控制
  • 临时对象存储（过期对象自动删除）
  • 存储请求速率限制
  • 临时链接（让任何用户访问对象，不需要使用Token）
  • 表单提交（直接从HTML表单上传文件到Swift存储，依赖与临时链接）
  • 静态WEB站点（用Swift作为静态站点的WEB服务器）

特性

优点

通过编程语言封装的API来存储和管理文件

使资源的管理和提取自动化

可以创建公共或私有的容器

更好的控制性。既允许数据共享也可以设为私有

使用商用硬件

没有锁定，每GB更低廉的价格

硬盘驱动器/结点不可预知的失效

具有自我修复的可靠性，数据冗余性来保护失效的影响

无限制的存储

巨大且扁平的名称空间，高度可伸缩的读写访问能力，直接从存储系统提供内容服务

多维可伸缩性（向外扩展的结构）

允许垂直和水平分布地调整存储

以线性的性能来备份/存档大量数据

帐号/容器/对象 没有嵌套，不是传统的文件系统

规模优化，允许百万个PB级别的对象

内建复制

(帐号、容器、对象的N份拷贝)

3x+的数据冗余性与RAID的2x的对比

高可靠性

不同于RAID的大小调整，非常简单的容量增减

 

简单的弹性的数据调整

没有中央数据库

更高的性能，没有瓶颈

不需要RAID

允许更有效地处理大量小型、随机的读写

内建Mgmt.工具

帐号管理：创建，增加，验证，删除用户

容器管理：上传，下载，验证

监测：容量、主机、网络、日子筛选、集群健康情况

 

驱动器检查

允许检测驱动器失效，尽早知悉数据受损

通过web浏览器使用VNC代理

快速、简单的命令行管理

 

架构

在介绍Swift的架构之前，先介绍一下OpenStack的设计原理：

  1. Scalability and elasticity are our main goals
    （可扩展性和伸缩性是我们的主要目标）
  2. Any feature that limits our main goals must be optional
    （任何影响到可扩展性和伸缩性的功能都必须是可选的）
  3. Everything should be asynchronous，If you can’t do something asynchronously, see #2
    （所有的环节必须是异步的，如果不能异步实现，参考第二条设计原理）
  4. All required components must be horizontally scalable
    （所有的基础组件必须能横向扩展）
  5. Always use shared nothing architecture (SN) or sharding，If you can’t Share nothing/shard, see #2
    （始终使用无共享的架构，如果不能实现，参见第二条）
  6. Distribute everything，especially logic. Move logic to where state naturally exists.（所有的都是分布式的，尤其是逻辑。把逻辑放在状态应该存在的地方）
  7. Accept eventual consistency and use it where it is appropriate.
    （接受最终一致性，并在适合的条件下使用）
  8. Test everything
    （充足的测试）

依赖组件

  • Memcached，分布式缓存系统，在swift中主要被用于token和account信息，container信息的存储
  • Sqlite，轻量级数据库引擎，在swift中主要被用于管理account和container数据库
  • rsync，远程同步工具，用于storage node之间的数据同步
  • XFS文件系统
  • WSGI，Python Web服务网关接口，通过paste.deploy工具包管理swift各服务进程、中间件的处理流程
  • Eventlet，Python搞并发网络编程库，swift所有的服务器进程均依赖于该库

主要组件

  • Ring文件
    在基本架构图中，我并没有画出ring文件，但是它却是整个Swift中最重要的组件。ring文件是由一致性哈希算法生成，它的主要作用是存储名字到位置的映射。
    ring文件分为三类，分别是：account.ring，container.ring，object.ring。
    对于account的请求，就能通过account_name查询account.ring得到{‘/account_name’ : account_db_position}的映射，从而知道account数据库文件在集群的位置；
    对于container的请求，通过account_name和container_name查询container.ring文件，得到{‘/account_name/container_name’ : container_db_position}的映射；
    对于object的请求，通过account_name，container_name，object_name查询object.ring文件，得到 {‘/account_name/container_name/object_name’ : object_position}的映射；
    Ring文件作为一个静态文件存储在每个节点的/etc/swift目录下，被用于各节点之间的位置查询，使得swift的内部网络是一个P2P网络，不依赖某几个节点进行位置查询，避免了单点瓶颈。
    生成ring文件的一致性哈希算法不但为数据的冗余性，分区容忍性提供了保证，也为整体架构上实现性能、容量的横向扩展奠定了基础。
    Ring的详细构造过程将在下一节介绍。
  • proxy-server
    proxy-server是proxy node中唯一运行的服务进程，也是swift集群的endpoint，向用户提供RESTful API。
    对于用户的请求，proxy-server会根据配置文件的配置，将请求交给各个中间件进行处理，其中最重要的就是Auth中间件（认证），在处理完成后 会根据请求路径将请求转发给相应的storage node中的account-server。container-server或object-server进程处理。
    swift集群的流入数据和流出数据都需要经过proxy-server，proxy-server不会对数据进行缓存。
  • auth-server
    验证服务进程，为用户生成token和验证每个请求的token及token的权限。swift的验证服务是作为一个中间件被proxy-server使 用，是可选的，可以自己开发，也可以使用OpenStack Keystone。Keystone是官方开发的验证服务，使用Keystone可以无缝的与其它OpenStack项目整合。
  • account-server
    account-server是storage node中负责处理对account的GET、HEAD、PUT、DELETE、RELICATION请求的服务进程，account-server使用sqlite的数据库文件保存account的相关信息。
  • container-server
    container-server是storage node中负责处理对container的GET、HEAD、PUT、DELETE、RELICATION请求的服务进程，container- server使用sqlite的数据库文件保存container的相关信息。
  • object-server
    object-server是storage node中负责处理对object的GET、HEAD、PUT、PSOT、DELETE、RELICATION请求的服务进程，object- server直接操作object，并利用XFS文件系统的xattr包存object的元数据。
  • account-auditor、container-auditor、object-auditor
    这三个进程运行在storage node中，分别检测account的db文件，container的db文件，object是否损坏，如果损坏，将会向存储有其它副本的storage node请求副本，替换损坏的。
  • account-replicator、container-replicator、object-replicator
    这三个进程运行在storage node中，分别负责account的db文件，container的db文件，object在集群中副本的同步。
    例如，一个object在swift集群中通常被存储在3个不同的storage node中，对于一个PUT /account/container/object的请求，proxy-server会根据 /account/container/object查询ring文件，得到该object应该存储的节点列表（长度为3），proxy-server会 将请求转发到这三个节点。如果只有两个节点写入成功，就认为这次PUT操作成功。写入失败的节点在一段时间后将会得到写入成功的节点object- replicator进程推送过来的数据。
  • container-updater、account-updater
    这两个进程运行在storage node中，负责container数据库和account数据库的异步更新。使用异步更新的原因：在请求来量大时，container-server和 account-server不能实时处理对数据库更新的请求，这些请求将被本地化到队列中，由updater进程进行异步更新。
  • What’s limitations of Swift?
  •  
    不是文件系统
    Swift使用REST API,因此不能使典型的POSIX 文件系统的语法如open(), read(), write(), seek()和close()。
    没有目录结构
    可以创建任意数量的容器，但是不支持嵌套
    在文件中没有写入字节偏移量
    The only way to update a file is to essentially overwrite it. The system creates a new version of an object each time you upload one with the same name.
    上传一个文件的唯一方式本质上就是重写这个文件。当你上传一个相同名字的对象时，系统就创建这个对象的新版本。
    不是数据库
    不支持服务器上的数据查询和处理。值可以列出指定容器内的对象，但是不能基于对象的元数据进行查询。
    不要尝试频繁地更新大对象
    所有的更新将会产生对象的新版本，因为对象是不可变的。
    不要在每个容器内存储超过无限的对象
    adrian otto 发现当容器的对象数超过100万个对象时，将会影响性能。