Swift提供的服务与AWS S3基本相同：
作为IaaS的存储服务
与OpenStack Compute对接，为其存储镜像
文档存储
存储需要长期保存的数据，例如log
存储网站的图片，缩略图等
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存储，依赖与临时链接）
swift的构架一般如下：可扩展性和伸缩性是我们的主要目标
swift服务依赖于以下技术
memcache 存储token、account、container信息等。
sqlite 用于管理account和container数据库
rsync 在storage node之间同步数据
xfs
WSGI python web服务网管接口管理swift进程
eventlet python 并发网络库
proxy server
proxy server是proxy node中运行的唯一的进程服务，他是swift集群的endpoint。proxy server负责连接swift的其他构件，对每次请求，proxy server都会查询ring中的account、container或者object，然后转发请求。API接口也是通过proxy server开放给外部的。proxy server也会处理大量的失败请求，例如当一个object PUT时，这时他会查询ring中其他可以提供服务的server，并转发请求。proxy server并不缓冲数据在object server和user之间，对于用户的请求proxy server会根据配置文件将请求交给中间件处理，在处理完成后会将请求路径转发给相应的storage node中的account、container或者object进行处理
ring
ring代表了存储在硬盘上的实体和实际物理位置的映射，account、container、object都有自己的ring，当其他组件需要对account、container或者object操作时，就需要用ring去确定各自在集群上的位置。
ring使用zone、devices、partitions、replicas来维护这些映射信息，每个ring中的partition在集群中都默认有3个副本(replicas),每个partition的位置由ring来维护，存贮在映射中，当请求失败时ring负责决定哪一个device接手请求。ring中的数据由zone保证各自隔离，每个partition的replica都被放在不同的zone上，一个zone可以是一个drive，一个server，一个cabinet，一个switch或者一个datacenter。
swift在安装ring的device时，会均衡的划分每个partition，当partition需要移动时，ring确保一次移动最少数量的partition，并且一次只移动一个partition的一个replica，weight可以用来均衡drive在partition在集群中的分布。
container server
container server主要处理object的listing，container server并不知道object存贮在哪里，只知道指定的container里面存储了哪些object，这些列表一sqlite数据库文件的形式存储，object一样在集群上做备份，container server也跟踪做一些统计。
container-server是storage node中负责处理对container的GET、HEAD、PUT、DELETE、RELICATION请求的服务进程。
account server
account server负责处理container的listing动作，作用和container server一样，account-server是storage node中负责处理对account的GET、HEAD、PUT、DELETE、RELICATION请求的服务进程。
object server
object server是一个简单的blob存储，他可以用来操作(检索和删除)本地devices上的objects，object以二进制文件的形式和元数据(metadata)存贮在文件系统上，元数据存放在文件系统的扩展属性中(xattrs)中，ext3的xattrs默认是关闭的。每个object的名字hash之后加上操作的时间戳组成object的存贮路径名，last write一定是成功的，并确保最新的object已经可以对外提供服务，删除操作也作为文件的一个版本，确保被删除的文件副本被正确的删除。
object-server是storage node中负责处理对object的GET、HEAD、PUT、PSOT、DELETE、RELICATION请求的服务进程，object-server直接操作object，并利用XFS文件系统的xattr包存object的元数据。
replication
replication用来保证系统故障时的数据一致性，replication进程比较本地数据和远程的拷贝，确保他们都包含最新的版本，object replication用hash表快速的比较每个partition的子段，container replication和account replication使用hash和high water marks进行文件版本比较，replication更新时，replication是以push为基础，对于object replication来说，更新时传输一些rsync同步文件到各个节点，并不是全部文件，account server和container server使用http或者rsync补全整个数据库文件上丢失的记录，replication同样确保被删除的数据确实从系统中删除了，当一项(object、container、account)被删除掉，则这项的最新的版本标志被设置成tombstone，replication能够看到ts，并确保设置为ts的项从系统中删除。
auditors
auditors 会在本地服务器上反复的检查，以保证object、container、account的完整性，一旦发现不完整的数据，该文件会被立即隔离，然后replication会从其他副本那里把问题文件替换。
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进程进行异步更新。
在Swift中会涉及到Proxy Server，Account Server，Container server，Object Server四种服务器。在Account Server，Container server，Object Server 3个服务器中都会有复制器（Replication），更新器（Updater），审计器（Auditor），分别负责相应服务存储数据的复制，更新，及其数据的审核。
在Account server中存储了包括的该系统会涉及到的容器列表，在Container server中，包含的是该系统存储的所有的对象信息列表，这两种服务器的数据组织都以Sqlite数据库文件的形式存储，而Object Server是一个非常简单的块存储服务器，对象以二进制形式存储。
请发表评论