OpenStack的Swift使用经验

Swift属于openstack项目里面的一个负责数据对象存储的一个项目，由Rackspace公司开发。它在整个openstack项目中所处的位置如下：

通过上图可以看出，openstack 通过计算项目，然后通过镜像服务找到存储的数据。

在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是一个非常简单的块存储服务器，对象以二进制形式存储。

  代理服务器接受外部网络相应的请求，根据代理的相应的一些策略（比如负载均衡，如果一个节点断电查找其他节点等），通过查找账户服务，容器服务，知道相应的对象服务，然后从对象服务器中返回相应的对象，将对象返回给代理服务器，通过代理服务器返回给外部网络，大概的一种硬件部署图如下：

Container Server的主要职责是提供objects的列表，objects列表以sqlite数据库文件的形式存储，并且像objects那样在集群中被备份。

Object Server是一个非常简单的块存储服务器，它可以用来存储，获取和删除存储在本地存储设备上的objects。objects以二进制文件的形式，连带着存储在扩展属性（xattrs）中的元数据，被存储在文件系统上（xattrs）。这需要存储objects的基础文件系统支持文件的xattrs。像ext3的一些文件系统，默认是关闭xattrs的。

Proxy Server负责将Swift架构的其他部分绑定在一起。对每一个请求，Proxy Server都要在环中查找account,container,或者object的位置，并且将请求转送到对应的地方。公开的API也是通过Proxy Server暴露出来。大量的失败也是由Proxy Server处理的。比如，如果一个server无法对一个object的PUT操作进行相应，它将从环中查询一个可以接手的server并将请求转递给它。当objects被传送object server或者从object server下载，他们将被直接通过proxy server传送。

复制器被设计用来在面临临时性错误（比如断网或存储器错误）时，保护系统的一致性。复制进程通过将本地数据与每一个远程备份进行比较，来确保它们都是最新版本的数据。Object复制器使用一个哈希列表来迅速地比较每一个分区的子部分，同时container和account复制器使用哈希的排列并且共享高峰标记。复制操作的更新是基于PUSH的方式。比如object的复制操作，更新就是一个往其他节点同步文件的过程。Account和container的复制操作通过HTTP来PUSH丢失的记录,或着远程同步全部的数据库文件。复制器同时也确保数据从系统的删除。当一个条目(object, container, account)被删除，一个墓碑将作为此目标的最新版本被设置。复制器将见到此墓碑，并将确保此目标被从所有的系统中删除。

    当contaniner或account数据不能被立即更新的情况会多次出现。这通常当出现错误或者系统过载时会发生。当一个更新失败时，更新操作就会在本地文件系统上排队，然后更新器会处理这些失败的更新。这时最终一致性的窗口会适时地出现。比如，假设当一个container server处于低负载并且一个新的object被put到系统中时，一旦proxy server向客户端回复成功消息，此object就将立即可读。然而，container server不会更新object的列表，并且因此更新将被排队以等待稍候的更新。此刻container列举的清单，可能不回立马包含此object。在实践中，一致性窗口的大小仅仅与更新器运行的频率一致，并且ProxyServer不会将list请求转递给最初对请求进行回复的那个ContainerServer。低负载的服务器可能不会接手接下来的list请求---其他的两个备份中的一个会处理此list请求。

审计师爬行本地服务器来检查objects,containers和accounts的完整性。当一个文件被发现有损坏（比如一点损坏），它将被隔离，并且复制器将同其他的副本复制一份来代替此损坏的文件。如果有别的错误发生，它们将被记录日志（比如列举一个object时，在所有的它应该位于的container server中都无法找到）。

    环代表磁盘上所存储的实体的名称与他们物理位置之间的映射。它们是分别对应于accounts,containers和objects的环。当其它的组件需要对object,container或者account执行某个操作时，它们需要通过

与对应的环沟通来确定执行客体在集群中的位置。

     Swift本身并不缓存任何数据对象，缓存单独用Memcached实现。Memcached用于缓存令牌信息，存在在容器跟账户等。在Rackspace，将Memcached部署在代理服务器上面，具体配置在文件proxy-server.conf中进行配置。

时间或许是相对而言的，但是它却是Swift中非常重要的一个因素！Swift使用时间戳来确定哪个才是对象的最新版本。将集群中的所有服务器的系统时间同步到最同步的状态非常重要(尤其是Proxy,但是最好将所有服务器的时间都同步)。在Rackspace,我们使用本地的一个NTP服务器来确保系统的时间尽可能地接近。这同样也应该被严密监视以确保系统时间相差不会太大。

大多数的服务都支持一个或者多个并发的处理器。这使服务可以更大化地利用多核的性能。一个好的起点是将Proxy和存储服务器的并发水平设置为内核数量的两倍。如果有１个以上的服务在共享一个服务器，那需要做些具体的实验以找出最平衡的方式。

Zone（区域）：一个zone可以代表一个存储器,一个服务器,一个机柜，一个交换机，甚至一个数据中心。

devices（存储）：

partitions（分区）：

replicas（副本）：

Weight(权重)：权重可以用来均衡存储设备上的partitions在集群间的分布。这是非常有用的，比如，当大小不同的存储设备被使用在同一集群中时。

环的管理由一个叫做ringbuilder的工具进行管理。

    由于Swif我目前为止还没有进行过真正的安装部署，所以暂时不写本部分，能成功部署后再补上这一块内容。