OpenStackSwift学习笔记

1、OpenStackSwift学习笔记1概述OpenStackObjectStorage(Swift)是 OpenStack 开源云计算项目的子项目之一。Swift 的目的是使用普通硬件来构建冗余的、可扩展的分布式对象存储集群，存储容量可达 PB 级。Swift 并不是文件系统或者实时的数据存储系统，它是对象存储，用于永久类型的静态数据的长期存储，这些数据可以检索、调整，必要时进行更新。最适合存储的数据类型的例子是虚拟机镜像、图片存储、邮件存储和存档备份。Swift 无需采用 RAID(磁盘冗余阵列)，也没有中心单元或主控结点。Swift 通过在软件层面引入一致性哈希技术和数据冗余性，牺牲一定程

2、度的数据一致性来达到高可用性(HighAvailability,简称 HA)和可伸缩性，支持多租户模式、容器和对象读写操作，适合解决互联网的应用场景下非结构化数据存储问题。2技术特性2.12.1SwiftSwift 的主要特征Swift 的主要特性如下：极高的数据持久性(Durability)0完全对称的系统架构：“对称”意味着 Swift 中各节点可以完全对等，能极大地降低系统维护成本。无限的可扩展性： 一是数据存储容量无限可扩展； 二是 Swift 性能(如 QPS 吞吐量等)可线性提升。无单点故障：Swift 的元数据存储是完全均匀随机分布的，并且与对象文件存储一样，元数据也会存储多份。

3、整个 Swift 集群中，也没有一个角色是单点的，并且在架构和设计上保证无单点业务是有效的。简单、可依赖。2.22.2SwiftSwift 和 HDFSHDFS 的技术差异Swift 和 Hadoop 分布式文件系统（HDFS 都有着相似的目的：实现冗余、快速、联网的存储，它们的技术差异如下：在 Swift 中，元数据呈分布式，跨集群复制。而在 HDFS 使用了中央系统来维护文件元数据（Namenode,名称节点），这对 HDFS 来说无异于单一故障点，因而扩展到规模非常大的环境显得更困难。Swift 在设计时考虑到了多租户架构，而 HDF 酸有多租户架构这个概念。在Swift 中，文件可以写

4、入多次；在并发操作环境下，以最近一次操作为准。而在 HDFS 中， 文件写入一次， 而且每次只能有一个文件写入。Swift 用 Python来编写，而 HDFS 用 Java 来编写。Swift 被设计成了一种比较通用的存储解决方案，能够可靠地存储数量非常多的大小不一的文件；而 HDFSM 设计成可以存储数量中等的大文件（HDFS#对更庞大的文件作了优化）,以支持数据处理。3关键技术致性哈希（ConsistentHashingConsistentHashing在分布式对象存储中，一个关键问题是数据该如何存放。Swift 是基于一致性哈希技术，通过计算可将对象均匀分布到虚拟空间的虚拟节点上，在增

5、加或删除节点时可大大减少需移动的数据量；虚拟空间大小通常采用 2 的 n 次幕，便于进行高效的移位操作；然后通过独特的数据结构 Ring（环）再将虚拟节点映射到实际的物理存储设备上，完成寻址过程。衡量一致性哈希的 4 个指标：平衡性（Balance）:平衡性是指 Hash 的结果能够尽可能分布均匀，充分利用所有缓存空间。单调性（Monotonicity）:单调性是指如果已经有一些内容通过哈希分派到了相应的缓冲中，又有新的缓冲加入到系统中。哈希的结果应能够保证原有已分配的内容可以被映射到新的缓冲中去，而不会被映射到旧的缓冲集合中的其他缓冲区。分散性（Spread）:分散性定义了分布式环境中，不同

6、终端通过 Hash 过程将内容映射至缓存上时，因可见缓存不同，Hash 结果不一致，相同的内容被映射至不同的缓冲区。负载（Load）:负载是对分散性要求的另一个纬度。既然不同的终端可以将相同的内容映射到不同的缓冲区中，那么对于一个特定的缓冲区而言，也可能被不同的用户映射为不同的内容。Swift 使用该算法的主要目的是在改变集群的 node 数量时（增加/删除服务器）,能够尽可能少地改变已存在 key 和 node 的映射关系，以满足单调性。考虑到哈希算法在 node 较少的情况下，改变 node 数会带来巨大的数据迁移。为了解决这种情况，一致性哈希引入了“虚拟节点”（vnode,也称为 par

7、tition）的概念：fctJFr 就。Cache#|1罹计 03”dli-Wi-iiih匚 MM 辨爵 tl4图 1 一致性哈希环结构“虚拟节点”是实际节点在环形空间的复制品，一个实际节点对应了若干个“虚拟节点”，“虚拟节点”在哈希空间中以哈希值排列。总的来说，Swift 中存在两种映射关系，对于一个文件，通过哈希算法（MD5）找到对应的虚节点（一对一的映射关系），虚节点再通过映射关系（ring 文件中二维数组）找到对应的设备（多对多的映射关系），这样就完成了一个文件存储在设备上的映射。图 2 对象、虚结点、节点间的映射关系在设置虚结点数的时候，需要对系统预期的规模做充分考虑，假如集群的规模

8、不会超过 6000 个结点，那么可以将虚结点数设置为结点数的 100 倍。这样，变动任意一个结点的负载仅影响 1%的数据项。 此时有 6 百万个 vnode 数， 使用 2bytes来存储结点数（065535）o 基本的内存占用是 6*（10A6）*2bytes=12Mb,对于服务器来说完全可以承受。假 设 有 65536 （ 2A16 ） 个 node, 有 1287、倍 的 partition 数 223, 则PARTITION_POWER=23由于MD5码是32位的，使用PARTITION_SHIFWT32-PARTITION_POWE 咫等数据项的 MD5 哈希值映射到partitio

9、n 的 2A23 的空间中。数据一致性模型（ConsistencyModelConsistencyModel按照 EricBrewer 的 CAP（ConsistencyAvailability,PartitionTolerance）理论,无法同时满足 3 个方面，Swift 放弃严格一致性（满足 ACID 事务级别），而采用最终一VirtualNode-致性模型（EventualConsistency,来达到高可用性和无限水平扩展能力。为了实现这一目标，Swift 采用 Quorum 仲裁协议（Quorum 有法定投票人数的含义）：定义：N:数据的副本总数；W:写操作被确认接受的副本数量；R

10、:读操作的副本数量。强一致性：R+WN 以保证对副本的读写操作会产生交集，从而保证可以读取到最新版本；如果 W=N,R=1,则需要全部更新，适合大量读少量写操作场景下的强一致性；如果 R=N,W=1,则只更新一个副本，通过读取全部副本来得到最新版本，适合大量写少量读场景下的强一致性。弱一致性：R+WN/2,再保证读操作与写操作的副本集合至少产生一个交集，即 R+WNL在分布式系统中，数据的单点是不允许存在的。线上正常存在的 replica 数量是 1 的话将非常危险的，因为一旦这个 replica 再次错误，就可能发生数据的永久性错误。假如我们把 N 设置成为 2,那么，只要有一个存储节点发生

11、损坏，就会有单点的存在。所以 N 必须大于 2。但 N 越高，系统的维护和整体成本就越高。所以，工业界通常把 N 设置为 3。Swift 默认配置是 N=3,W=2N/2,R=1 或 2,即每个对象会存在 3 个副本， 这些副本会被尽量存储在不同区域的节点上；W=2 表示至少需要更新 2 个副本才算写成功。当 R=1 时，意味着某一个读操作成功便立刻返回，此种情况下可能会读取到旧版本（弱一致性模型）。当 R=2 时，需要通过在读操作请求头中增加 x-newest=true 参数来同时读取 2 个副本的元数据信息，然后比较时间戳来确定哪个是最新版本（强一致性模型）如果数据出现了不一致，后台服务进

12、程会在一定时间窗口内通过检测和复制协议来完成数据同步，从而保证达到最终一致性。图 3Quorum 协议示例环（RingRing）Ring 是 Swift 中最重要的组件，用于记录存储对象与物理位置间的映射关系。在涉及查询 Account、Container、Object 信息时就需要查询集群的 Ring 信息。环是为了将虚拟节点（partition,分区）均衡地映射到一组物理存储设备上，并提供一定的冗余度而设计的，其数据结构由以下信息组成：存储设备列表、 设备信息包括唯一标识号 （id） 、 区域号 （zone） 、 权重 （weight） 、IP 地址（ip）、端口（port）、设备名称（d

13、evice）、元数据（meta）。Swift 为账户、容器和对象分别定义了的 Ring,其查找过程是相同的。Ring 中每个partition 在集群中都默认有 3 个 replica。每个 partition 的位置由 ring 来维护，并存储在映射中。Ring 使用 zone 来保证数据的物理隔离。 每个 partition 的 replica 都确保放在了不同的 zone 中。Zone 只是个抽象概念，它可以是一个磁盘（diskdrive）,一个服务器（server） ,一个机架 （cabinet） ,一个交换机 （switch） ,甚至是一个数据中心（datacenter） ,以提供最

14、高级别的冗余性，建议至少部署 5 个 zone权重参数是个相对值，可以来根据磁盘的大小来调节，权重越大表示可分配的空间越多，可部署更多的分区。当集群中发生存储节点宕机、新增（删）存储节点、新增（删）zone 等必须改变partition 和 node 间的映射关系时，还可以对 Ring 文件通过重新平衡（rebalance）来进行更新。当虚节点需要移动时，环会确保一次移动最少数量的虚节点数，并且一次只移动一个虚节点的一个副本。总的来说，Ring 引入一致性哈希的原因是为了减少由于增加结点导致数据项移动的数量来提高单调性；引入 partition 的原因是为了减少由于节点数过少导致移动过多的数据

15、项；引入 replica 的原因是防止数据单点、提高冗余性；引入 zone 的原因是为了保证分区容忍性；引入 weight 的原因是为了保证 partition 分配的均衡。4架构设计SwiftSwift 数据模型Swift 采用层次数据模型，共设三层逻辑结构：Account/Container/Object（账户/容器/对象）。每层节点数均没有限制，可以任意扩展。这里的账户和个人账户不是一个概念，可理解为租户，用来做顶层的隔离机制，可以被多个个人账户所共同使用；容器类似文件夹，代表封装一组对象；对象由元数据和数据两部分组成。SwiftSwift 系统架构Swift 采用完全对称、面向资源的分

16、布式系统架构设计，所有组件都可扩展，避免因单点失效而扩散并影响整个系统运转；通信方式采用非阻塞式 I/O 模式，提高了系统吞吐和响应能力。Swift 组件包括：代理务（ProxyServer：Swift 通过 ProxyServer 向外提供基于 HTTP 的RESlBi 务接口,会根据环的信息来查找服务地址并转发用户请求至相应的账户、 容器或者对象， 进行 CRUD （增删改查） 等操作。 由于采用无状态的 RES*求协议，可以进行横向扩展来均衡负载。在访问 Swift 服务之前，需要先通过认证服务获取访问令牌，然后在发送的请求中加入头部信息 X-Auth-Token代理服务器负责 Swif

17、t 架构的其余组件间的相互通信。 代理服务器也处理大量的失败请求。例如，如果对于某个对象 PUT 请求时，某个存储节点不可用，它将会查询环可传送的服务器并转发请求。对象以流的形式到达（来自）对象服务器，它们直接从代理服务器传送到（来自）用户一代理服务器并不缓冲它们。认证服务（AuthenticationServer）：验证访问用户的身份信息，并获得一个对象访问令牌（Token）,在一定的时间内会一直有效；验证访问令牌的有效性并缓存下来直至过期时间。第 7 页/共 14 页缓存服务（CacheServe:缓存的内容包括对象服务令牌，账户和容器的存在信息， 但不会缓存对象本身的数据； 缓存服务可采

18、用 Memcached 集群， Swift会使用一致性哈希算法来分配缓存地址。账户服务（AccountServer）:提供账户元数据和统计信息，并维护所含容器列表的服务，每个账户的信息被存储在一个 SQLite 数据库中。容器服务（ContainerServe。：提供容器元数据和统计信息（比如对象的总数，容器的使用情况等），并维护所含对象列表的服务。容器服务并不知道对象存在哪，只知道指定容器里存的哪些对象。这些对象信息以SQLite 数据库文件的形式存储，和对象一样在集群上做类似的备份。对象服务（ObjectServer）:提供对象元数据和内容服务，可以用来存储、检索和删除本地设备上的对象。在

19、文件系统中，对象以二进制文件的形式存储，它的元数据存储在文件系统的扩展属性（xattr）中，建议采用默认支持扩展属性（xattr）的 XFS 文件系统。每个对象使用对象名称的哈希值和操作的时间戳组成的路径来存储。最后一次写操作总可以成功，并确保最新一次的对象版本将会被处理。删除也被视为文件的一个版本（一个以.ts结尾的 0 字节文件，ts 表示墓碑）。复制服务（Replicator）：会检测本地分区副本和远程副本是否一致，具体是通过对比哈希文件和高级水印来完成，发现不一致时会采用推式（Push）更新远程副本：对于对象的复制，更新只是使用 rsync 同步文件到对等节点。帐号和容器的复制通过 H

20、TTP 或 rsync 来推送整个数据库文件上丢失的记录；另外一个任务是确保被标记删除的对象从文件系统中移除：当有一项（对象、容器、或者帐号）被删除，则一个墓碑文件被设置作为该项的最新版本。复制器将会检测到该墓碑文件并确保将它从整个系统中移除。更新服务（Updater）：当对象由于高负载或者系统故障等原因而无法立即更新时，任务将会被序列化到在本地文件系统中进行排队，以便服务恢复后进行异步更新；例如成功创建对象后容器服务器没有及时更新对象列表，这个时候容器的更新操作就会进入排队中，更新服务会在系统恢复正常后扫描队列并进行相应的更新处理。审计服务（Auditor）：在本地服务器上会反复地爬取来检查

21、对象，容器和账户的完整性，如果发现比特级的错误，文件将被隔离，并复制其他的副本以覆盖本地损坏的副本；其他类型的错误（比如在任何一个容器服务器中都找不到所需的对象列表）会被记录到日志中。账户清理服务（AccountReaped 移除被标记为删除的账户，删除其所包含的所有容器和对象。删除账号的过程是相当直接的。对于每个账号中的容器，每个对象先被删除然后容器被删除。任何失败的删除请求将不会阻止整个过程，但是将会导致整个过程最终失败（例如，如果一个对象的删除超时，容器将不能被删除，因此账号也不能被删除）。整个处理过程即使遭遇失败也继续执行，这样它不会因为一个麻烦的问题而中止恢复集群空间。账号收割器将会

22、继续不断地尝试删除账号直到它最终变为空，此时数据库在 db_replicator 中回收处理，最终移除这个数据库文件。图 4Swift 系统架构Swift 支持的所有操作可以总结为下表：表 1SwiftRESTfulAP 总结Findbcationkraqr代代nnameinmappings/-XObjtRingObjectS*n/&rContainerServerAccountextendedfieattributQUkUObjectAuditortualconsistencYccwnt、ReaperContainsUpdjterAccount,UpdaterJ/entualconsiste

23、ncyContainer( (ReplicatorhAccounty.Replicator).inlegrltychcklnAccouAuditorContainerRingjfAccountaccfiunrQObjeetAeeoumTonel-mnoContainer资源URLGETPUTPOSTDELETEHEAD账户/account/获取容器列表-获取账户元数据容器/account/container获取对象列表创建容器更新容器元数据删除容器获取容器元数据对象/account/container/object获取对象内容和元数据创建、更新或拷贝对象更新对象元数据删除对象获取对象元数据Ri

24、ngRing 的数据结构Ring 的数据结构由三个顶层域构成，其中：ListofDevice表示集群中设备的列表，在 Ring 类内部被称为 devs；PartitionAssignmentList,用于存放每个 replica 与 device 间映射关系,在 Ring类内部被称为_replica2part2dev_id;PartitionShiftValue,表示计算数据 hash 的移位量，在 Ring 类内部称为_part_shift。使用 python读取/etc/swift/object.ring.gz存放的数据， 可以获得以 devs、 part_shift、replica2pa

25、rt2dev_id 为 key 的 dict 类数据。SwiftSwift 存储结构在 StorageNode 上运行着 Linux 系统并使用了 XFS 文件系统，逻辑上使用一致性哈希算法将固定总数的 partition 映射到每个 StorageNode 上，每个 data 也使用同样的哈希算法映射到 partition 上。存储内容一般放在/srv/node/sdb1 之类的路径下， 其目录结构如下所示： accounts、async_pendingcontainers、 objectsquarantined 和 tmp。 其中 accounts、 containers、objects

26、分另是账号、容器、对象的存储目录，async_pending 是异步待更新目录，quarantined 是隔离目录，tmp 是临时目录。objects：在 objects 目录下存放的是各个 partition 目录，其中每个 partition 目录是由若干个 suffix_path 名的目录和一个 hashes.pkl 文件组成，suffix_path目录下是由 object 的 hash_path 名构成的目录，在 hash_path 目录下存放了关于 object 的数据和元数据；object 的数据存放在后缀为.data 的文件中，它的 metadata 存放在以后缀为.meta 的

27、文件中，将被删除的 Object 以一个 0 字节后缀为.ts 的文件存放。accounts：在 accounts 目录下存放的是各个 partition,而每个 partition 目录是由若干个 suffix_path 目录组成，suffix_path 目录下是由 account 的 hsh 名构成的目录，在 hsh 目录下存放了关于 account 的 sqlitedb;在 account 的 db 文件中，包含了 account_stat、container、incoming_sync、outgoing_sync4 张表；其中,表 account_stat 是记录关于 account

28、的信息,如名称、创建时间、container 数统计等等；表 container 记录关于 container 的信息；表incoming_sync 记录到来的同步数据项；表 outgoing_sync 表示推送出的同步数据项。containers：containers 目录结构和生成过程与 accounts 类似，containers 的db 中共有 5 张表，其中 incoming_sync 和 outgoing_sync 的 schema 与accounts 中的相同。其他 3 张表分别为 container_stat、objectsqlite_sequence；表 container_

29、stat 与表 account_stat 相似，其区另是 container_stat 存放的是关于 container 信息。tmp：tmp 目录作为 account/container/objectserver 向 partition 目录内写入数据前的临时目录。例如，client 向 server 上传某一文件，objectserver 调用DiskFile 类的 mkstemp 方法创建在路径为 path/device/tmp 的目录。在数据上传完成之后，再调用 put()方法，将数据移动到相应路径。async_pending：async_pending存放未能及时更新而被加入更新队列的数据。本地 server 在与 remoteserver 建立 HTTP 连接或者发送数据时超时导致更新失败时，将把文件放入 async_pendin