OpenStack的Swift组件详解

一：简介

    一、背景

1. Swift 最初是由 Rackspace 公司开发的高可用分布式对象存储服务（Object  Storage Service），并于 2010 年贡献给 OpenStack 开源社区作为其最初的核心子项目之一，为其 Nova 子项目提供虚机镜像存储服务。Swift 构筑在比较便宜的标准硬件存储基础设施之上，无需采用 RAID（磁盘冗余阵列），通过在软件层面引入一致性散列技术和数据冗余性，牺牲一定程度的数据一致性来达到高可用性和可伸缩性，支持多租户模式、容器和对象读写操作，适合解决互联网的应用场景下非结构化数据存储问题。

2. Swift 包括2个组成部分，一个是代理服务（proxy）,一个是存储服务（storage）。

1. 代理服务是Swift内部存储的拓扑逻辑，即一个具体文件位于哪个存储节点的哪个区上。它同时是一个web服务器，通过http或https对外提供REST API服务。

2. 存储服务是负责文件存储的服务，由3个组件组成：account-server、container-server、object-server。其中object-server负责具体的文件存储，container-server包含到每个object的索引，account-server包含到每个container 的索引。

    二、原理

1. 一致性散列（Consistent Hashing)：Swift 是基于一致性散列技术，通过计算可将对象均匀分布到虚拟空间的虚拟节点上，在增加或删除节点时可大大减少需移动的数据量；虚拟空间大小通常采用 2 的 n 次幂，便于进行高效的移位操作；然后通过独特的数据结构 Ring（环）再将虚拟节点映射到实际的物理存储设备上，完成寻址过程。

1. 平衡性：平衡性是指哈希的结果能够尽可能的分布到所有的缓冲中去，这样可以使得所有缓冲空间能够都得到利用。为了更好的满足平衡性，引入了虚拟节点概念，虚拟节点是实际节点在hash空间的复制品，一个实际节点对应若干个虚拟节点，这个对应的个数也称为复制个数，虚拟节点在hash空间以hash值排列。

2. 单调性：单调性是指如果已经有些内容通过Hash分派到相应的缓冲中，又有新的缓冲加入到系统中，哈希的结果应能够保证原有已分配的内容可以被映射到原有或者新的缓冲中区，而不会被映射到旧的或者其他缓冲区。

3. 分散性：在分布式环境中，客户端可能看不到所有的缓冲，而只能看到其中一部分。当终端希望通过哈希过程将内容映射到缓冲上时，由于不同的客户端所看到的缓冲范围可能不同，从而导致得到的Hash结果不一致，导致结果相同的内容被映射到不用的缓冲区中。这种情况应该被避免，因为这将会导致相同的内容将会被映射到不同缓冲区中，降低了系统的存储效率。

4. 负载：负载时对分散性要求的另一个维度。既然相同的内容可能被映射到不同的缓冲中去，那么对于同一个缓冲而言，就有可能被不同的用户映射不同的内容。与分散性一样，这种情况应该被避免。

5. 如图所示，以逆时针方向递增的散列空间有 4 个字节长共 32 位，整数范围是[0~232-1]；将散列结果右移 m 位，可产生 232-m个虚拟节点，例如 m=29 时可产生 8 个虚拟节点。在实际部署的时候需要经过仔细计算得到合适的虚拟节点数，以达到存储空间和工作负载之间的平衡。

2. 数据一致性模型（Consistency Model）

1. 按照 Eric Brewer 的 CAP（Consistency，Availability，Partition Tolerance）理论，无法同时满足 3 个方面，Swift 放弃严格一致性（满足 ACID 事务级别），而采用最终一致性模型（Eventual Consistency），来达到高可用性和无限水平扩展能力。为了实现这一目标，Swift 采用 Quorum 仲裁协议(Quorum 有法定投票人数的含义)：

1. 定义：N：数据的副本总数；W：写操作被确认接受的副本数量；R：读操作的副本数量

2. 强一致性：R+W>N，以保证对副本的读写操作会产生交集，从而保证可以读取到最新版本；如果 W=N，R=1，则需要全部更新，适合大量读少量写操作场景下的强一致性；如果 R=N，W=1，则只更新一个副本，通过读取全部副本来得到最新版本，适合大量写少量读场景下的强一致性。

3. 弱一致性：R+W<=N，如果读写操作的副本集合不产生交集，就可能会读到脏数据；适合对一致性要求比较低的场景。

2. Swift 针对的是读写都比较频繁的场景，所以采用了比较折中的策略，即写操作需要满足至少一半以上成功 W >N/2，再保证读操作与写操作的副本集合至少产生一个交集，即 R+W>N。Swift 默认配置是 N=3，W=2>N/2，R=1 或 2，即每个对象会存在 3 个副本，这些副本会尽量被存储在不同区域的节点上；W=2 表示至少需要更新 2 个副本才算写成功；当 R=1 时意味着某一个读操作成功便立刻返回，此种情况下可能会读取到旧版本（弱一致性模型）；当 R=2 时，需要通过在读操作请求头中增加 x-newest=true 参数来同时读取 2 个副本的元数据信息，然后比较时间戳来确定哪个是最新版本（强一致性模型）；如果数据出现了不一致，后台服务进程会在一定时间窗口内通过检测和复制协议来完成数据同步，从而保证达到最终一致性。如图 2 所示：

3. 环的数据结构

1. 环是为了将虚拟节点（分区）映射到一组物理存储设备上，并提供一定的冗余度而设计的，其数据结构由以下信息组成：

1. 存储设备列表、设备信息包括唯一标识号（id）、区域号（zone）、权重（weight）、IP 地址（ip）、端口（port）、设备名称（device）、元数据（meta）。

2. 分区到设备映射关系（replica2part2dev_id 数组)。

3. 计算分区号的位移(part_shift 整数，即图 1 中的 m)。

2. 使用对象的层次结构 account/container/object 作为键，使用 MD5 散列算法得到一个散列值，对该散列值的前 4 个字节进行右移操作得到分区索引号，移动位数由上面的 part_shift 设置指定；按照分区索引号在分区到设备映射表（replica2part2dev_id）里查找该对象所在分区的对应的所有设备编号，这些设备会被尽量选择部署在不同区域（Zone）内，区域只是个抽象概念，它可以是某台机器，某个机架，甚至某个建筑内的机群，以提供最高级别的冗余性，建议至少部署 5 个区域；权重参数是个相对值，可以来根据磁盘的大小来调节，权重越大表示可分配的空间越多，可部署更多的分区。

4. 数据模型

1. Swift 采用层次数据模型，共设三层逻辑结构：Account/Container/Object（即账户/容器/对象)，每层节点数均没有限制，可以任意扩展。

2. 账户和个人账户不是一个概念，可理解为租户，用来做顶层的隔离机制，可以被多个个人账户所共同使用；

3. 容器代表封装一组对象，类似文件夹或目录；叶子节点代表对象，由元数据和内容两部分组成，如图所示：

    三、特性

1. 大量对象的存储（Storage of large number of objects）。

2. 大对象的存储（Storage of large sized objects）。

3. 数据冗余（Data Redundancy）。

4. 档案能力——存储大数据集（Archival capabilities - Work with large datasets）。

5. 虚拟机和云应用的数据容器（Data container for virtual machines and cloud apps）。

6. 流媒体的能力（Media Streaming capabilities）。

7. 对象存储安全（Secure storage of objects）。

8. 备份和档案（Backup and archival）。

9. 极高的扩展性（Extreme scalability）

二：架构

    一、核心架构

           

    二、组件详解

1. 代理服务（Proxy Server）：对外提供对象服务 API，会根据环的信息来查找服务地址并转发用户请求至相应的账户、容器或者对象服务；由于采用无状态的 REST 请求协议，可以进行横向扩展来均衡负载。

2. 认证服务（Authentication Server）：验证访问用户的身份信息，并获得一个对象访问令牌（Token），在一定的时间内会一直有效；验证访问令牌的有效性并缓存下来直至过期时间。

3. 缓存服务（Cache Server）：缓存的内容包括对象服务令牌，账户和容器的存在信息，但不会缓存对象本身的数据；缓存服务可采用 Memcached 集群，Swift 会使用一致性散列算法来分配缓存地址。

4. 账户服务（Account Server）：提供账户元数据和统计信息，并维护所含容器列表的服务，每个账户的信息被存储在一个 SQLite 数据库中。

5. 容器服务（Container Server）：提供容器元数据和统计信息，并维护所含对象列表的服务，每个容器的信息也存储在一个 SQLite 数据库中。

6. 对象服务（Object Server）：提供对象元数据和内容服务，每个对象的内容会以文件的形式存储在文件系统中，元数据会作为文件属性来存储，建议采用支持扩展属性的 XFS 文件系统。

7. 复制服务（Replicator）：会检测本地分区副本和远程副本是否一致，具体是通过对比散列文件和高级水印来完成，发现不一致时会采用推式（Push）更新远程副本，例如对象复制服务会使用远程文件拷贝工具 rsync 来同步；另外一个任务是确保被标记删除的对象从文件系统中移除。

8. 更新服务（Updater）：当对象由于高负载的原因而无法立即更新时，任务将会被序列化到在本地文件系统中进行排队，以便服务恢复后进行异步更新；例如成功创建对象后容器服务器没有及时更新对象列表，这个时候容器的更新操作就会进入排队中，更新服务会在系统恢复正常后扫描队列并进行相应的更新处理。

9. 审计服务（Auditor）：检查对象，容器和账户的完整性，如果发现比特级的错误，文件将被隔离，并复制其他的副本以覆盖本地损坏的副本；其他类型的错误会被记录到日志中。

10. 账户清理服务（Account Reaper）：移除被标记为删除的账户，删除其所包含的所有容器和对象。

    三、Swift对CAP的支持程度

1. CAP概述：美国著名科学家，Berkerly大学Brewer教授提出的一个分布式系统不能同时满足一致性，可用性和分区容错性这三个需求，最多只能同时满足两个。重要属性：

1. 一致性(Consistency)：任何一个读操作总是能读取到之前完成的写操作结果，也就是在分布式环境中，多点的数据是一致的。

2. 可用性(Availability)：每一个操作总是能够在确定的时间内返回，也就是系统随时都是可用的。

3. 分区可容忍性(Tolerance of network Partition)：在出现网络分区（比如断网）的情况下，分离的系统也能正常运行。

2. Swift对CAP的支持

1. Consistency：Swift的一致性归为弱一致性模型。Swift 由 updater 保证最终一致性，auditor 保证存储对象的完整性。Swift 只能保证数据的最终一致性，即，如果upload(update也是一种upload)一个object,从其他客户端GET这个object，不一定是最新的。

2. Availability：基于python对hash的 原生支持，swift中广泛使用了hash算法。比如均衡ring中partition的分布，object  update备份策略。sqlite控制account/container/object的相关信息，简化了维护成本。

三：常用操作