广告设计就业方向,如何选择百度网站优化公司,来安网站建设,网站的功能建设免责声明#xff1a; 本文转自网络文章#xff0c;转载此文章仅为个人收藏#xff0c;分享知识#xff0c;如有侵权#xff0c;请联系博主进行删除。 原文作者#xff1a;崔炳华 原文地址#xff1a;http://blog.csdn.net/i_chips/article/details/17787017 1 概…免责声明 本文转自网络文章转载此文章仅为个人收藏分享知识如有侵权请联系博主进行删除。 原文作者崔炳华 原文地址http://blog.csdn.net/i_chips/article/details/17787017 1 概述 OpenStack Object StorageSwift是OpenStack开源云计算项目的子项目之一。Swift的目的是使用普通硬件来构建冗余的、可扩展的分布式对象存储集群存储容量可达PB级。 Swift并不是文件系统或者实时的数据存储系统它是对象存储用于永久类型的静态数据的长期存储这些数据可以检索、调整必要时进行更新。最适合存储的数据类型的例子是虚拟机镜像、图片存储、邮件存储和存档备份。 Swift无需采用RAID磁盘冗余阵列也没有中心单元或主控结点。Swift通过在软件层面引入一致性哈希技术和数据冗余性牺牲一定程度的数据一致性来达到高可用性High Availability简称HA和可伸缩性支持多租户模式、容器和对象读写操作适合解决互联网的应用场景下非结构化数据存储问题。 2 技术特性 2.1 Swift的主要特征 Swift的主要特性如下 极高的数据持久性Durability。 完全对称的系统架构“对称”意味着Swift中各节点可以完全对等能极大地降低系统维护成本。 无限的可扩展性一是数据存储容量无限可扩展二是Swift性能如QPS、吞吐量等可线性提升。 无单点故障Swift的元数据存储是完全均匀随机分布的并且与对象文件存储一样元数据也会存储多份。整个Swift集群中也没有一个角色是单点的并且在架构和设计上保证无单点业务是有效的。 简单、可依赖。 2.2 Swift和HDFS的技术差异 Swift和Hadoop分布式文件系统HDFS都有着相似的目的实现冗余、快速、联网的存储它们的技术差异如下 在Swift中元数据呈分布式跨集群复制。而在HDFS使用了中央系统来维护文件元数据Namenode名称节点这对HDFS来说无异于单一故障点因而扩展到规模非常大的环境显得更困难。 Swift在设计时考虑到了多租户架构而HDFS没有多租户架构这个概念。 在Swift中文件可以写入多次在并发操作环境下以最近一次操作为准。而在HDFS中文件写入一次而且每次只能有一个文件写入。 Swift用Python来编写而HDFS用Java来编写。 Swift被设计成了一种比较通用的存储解决方案能够可靠地存储数量非常多的大小不一的文件而HDFS被设计成可以存储数量中等的大文件HDFS针对更庞大的文件作了优化以支持数据处理。 3 关键技术 3.1 一致性哈希ConsistentHashing 在分布式对象存储中一个关键问题是数据该如何存放。Swift是基于一致性哈希技术通过计算可将对象均匀分布到虚拟空间的虚拟节点上在增加或删除节点时可大大减少需移动的数据量虚拟空间大小通常采用2的n次幂便于进行高效的移位操作然后通过独特的数据结构 Ring环再将虚拟节点映射到实际的物理存储设备上完成寻址过程。 图1 一致性哈希环结构 衡量一致性哈希的4个指标 平衡性Balance平衡性是指Hash的结果能够尽可能分布均匀充分利用所有缓存空间。 单调性Monotonicity单调性是指如果已经有一些内容通过哈希分派到了相应的缓冲中又有新的缓冲加入到系统中。哈希的结果应能够保证原有已分配的内容可以被映射到新的缓冲中去而不会被映射到旧的缓冲集合中的其他缓冲区。 分散性Spread分散性定义了分布式环境中不同终端通过Hash过程将内容映射至缓存上时因可见缓存不同Hash结果不一致相同的内容被映射至不同的缓冲区。 负载Load负载是对分散性要求的另一个纬度。既然不同的终端可以将相同的内容映射到不同的缓冲区中那么对于一个特定的缓冲区而言也可能被不同的用户映射为不同的内容。 Swift使用该算法的主要目的是在改变集群的node数量时增加/删除服务器能够尽可能少地改变已存在key和node的映射关系以满足单调性。 考虑到哈希算法在node较少的情况下改变node数会带来巨大的数据迁移。为了解决这种情况一致性哈希引入了“虚拟节点”vnode也称为partition的概念 “虚拟节点”是实际节点在环形空间的复制品一个实际节点对应了若干个“虚拟节点”“虚拟节点”在哈希空间中以哈希值排列。 总的来说Swift中存在两种映射关系对于一个文件通过哈希算法MD5找到对应的虚节点一对一的映射关系虚节点再通过映射关系ring文件中二维数组找到对应的设备多对多的映射关系这样就完成了一个文件存储在设备上的映射。 图2 对象、虚结点、节点间的映射关系 在设置虚结点数的时候需要对系统预期的规模做充分考虑假如集群的规模不会超过6000个结点那么可以将虚结点数设置为结点数的100倍。这样变动任意一个结点的负载仅影响1%的数据项。此时有6百万个vnode数使用2bytes来存储结点数(0~65535)。基本的内存占用是6*(10^6)*2bytes12Mb对于服务器来说完全可以承受。 假设有655362^16个node有1282^7倍的partition数2^23则PARTITION_POWER23。由于MD5码是32位的使用PARTITION_SHIFT等于32- PARTITION_POWER将数据项的MD5哈希值映射到partition的2^23的空间中。 3.2 数据一致性模型ConsistencyModel 按照Eric Brewer的CAPConsistencyAvailabilityPartitionTolerance理论无法同时满足3个方面Swift放弃严格一致性满足ACID事务级别而采用最终一致性模型Eventual Consistency来达到高可用性和无限水平扩展能力。 为了实现这一目标Swift采用Quorum仲裁协议Quorum有法定投票人数的含义 定义N数据的副本总数W写操作被确认接受的副本数量R读操作的副本数量。 强一致性RWN以保证对副本的读写操作会产生交集从而保证可以读取到最新版本如果 WNR1则需要全部更新适合大量读少量写操作场景下的强一致性如果 RNW1则只更新一个副本通过读取全部副本来得到最新版本适合大量写少量读场景下的强一致性。 弱一致性RWN如果读写操作的副本集合不产生交集就可能会读到脏数据适合对一致性要求比较低的场景。 Swift针对的是读写都比较频繁的场景所以采用了比较折中的策略即写操作需要满足至少一半以上成功WN/2再保证读操作与写操作的副本集合至少产生一个交集即RWN。 在分布式系统中数据的单点是不允许存在的。线上正常存在的replica数量是1的话将非常危险的因为一旦这个replica再次错误就可能发生数据的永久性错误。假如我们把N设置成为2那么只要有一个存储节点发生损坏就会有单点的存在。所以N必须大于2。但N越高系统的维护和整体成本就越高。所以工业界通常把N设置为3。 Swift默认配置是N3W2N/2R1或2即每个对象会存在3个副本这些副本会被尽量存储在不同区域的节点上W2表示至少需要更新2个副本才算写成功。 当R1时意味着某一个读操作成功便立刻返回此种情况下可能会读取到旧版本弱一致性模型。 当R2时需要通过在读操作请求头中增加x-newesttrue参数来同时读取2个副本的元数据信息然后比较时间戳来确定哪个是最新版本强一致性模型。 如果数据出现了不一致后台服务进程会在一定时间窗口内通过检测和复制协议来完成数据同步从而保证达到最终一致性。 图3 Quorum协议示例 3.3 环Ring Ring是Swift中最重要的组件用于记录存储对象与物理位置间的映射关系。在涉及查询Account、Container、Object信息时就需要查询集群的Ring信息。 环是为了将虚拟节点partition分区均衡地映射到一组物理存储设备上并提供一定的冗余度而设计的其数据结构由以下信息组成 存储设备列表、设备信息包括唯一标识号id、区域号zone、权重weight、IP 地址ip、端口port、设备名称device、元数据meta。 Swift为账户、容器和对象分别定义了的Ring其查找过程是相同的。Ring中每个partition在集群中都默认有3个replica。每个partition的位置由ring来维护并存储在映射中。 Ring使用zone来保证数据的物理隔离。每个partition的replica都确保放在了不同的zone中。Zone只是个抽象概念它可以是一个磁盘disk drive一个服务器server一个机架cabinet一个交换机switch甚至是一个数据中心datacenter以提供最高级别的冗余性建议至少部署5个zone。 权重参数是个相对值可以来根据磁盘的大小来调节权重越大表示可分配的空间越多可部署更多的分区。 当集群中发生存储节点宕机、新增删存储节点、新增删zone等必须改变partition和node间的映射关系时还可以对Ring文件通过重新平衡rebalance来进行更新。当虚节点需要移动时环会确保一次移动最少数量的虚节点数并且一次只移动一个虚节点的一个副本。 总的来说Ring引入一致性哈希的原因是为了减少由于增加结点导致数据项移动的数量来提高单调性引入partition的原因是为了减少由于节点数过少导致移动过多的数据项引入replica的原因是防止数据单点、提高冗余性引入zone的原因是为了保证分区容忍性引入weight的原因是为了保证partition分配的均衡。 4 架构设计 4.1 Swift数据模型 Swift采用层次数据模型共设三层逻辑结构Account/Container/Object账户/容器/对象。每层节点数均没有限制可以任意扩展。这里的账户和个人账户不是一个概念可理解为租户用来做顶层的隔离机制可以被多个个人账户所共同使用容器类似文件夹代表封装一组对象对象由元数据和数据两部分组成。 4.2 Swift系统架构 Swift采用完全对称、面向资源的分布式系统架构设计所有组件都可扩展避免因单点失效而扩散并影响整个系统运转通信方式采用非阻塞式 I/O 模式提高了系统吞吐和响应能力。 Swift组件包括 代理服务ProxyServerSwift通过Proxy Server向外提供基于HTTP的REST服务接口会根据环的信息来查找服务地址并转发用户请求至相应的账户、容器或者对象进行CRUD增删改查等操作。由于采用无状态的REST请求协议可以进行横向扩展来均衡负载。在访问Swift服务之前需要先通过认证服务获取访问令牌然后在发送的请求中加入头部信息 X-Auth-Token。代理服务器负责Swift架构的其余组件间的相互通信。代理服务器也处理大量的失败请求。例如如果对于某个对象PUT请求时某个存储节点不可用它将会查询环可传送的服务器并转发请求。对象以流的形式到达来自 对象服务器它们直接从代理服务器传送到来自用户—代理服务器并不缓冲它们。 认证服务AuthenticationServer验证访问用户的身份信息并获得一个对象访问令牌Token在一定的时间内会一直有效验证访问令牌的有效性并缓存下来直至过期时间。 缓存服务CacheServer缓存的内容包括对象服务令牌账户和容器的存在信息但不会缓存对象本身的数据缓存服务可采用Memcached集群Swift会使用一致性哈希算法来分配缓存地址。 账户服务AccountServer提供账户元数据和统计信息并维护所含容器列表的服务每个账户的信息被存储在一个SQLite数据库中。 容器服务ContainerServer提供容器元数据和统计信息比如对象的总数容器的使用情况等并维护所含对象列表的服务。容器服务并不知道对象存在哪只知道指定容器里存的哪些对象。 这些对象信息以SQLite数据库文件的形式存储和对象一样在集群上做类似的备份。 对象服务ObjectServer提供对象元数据和内容服务可以用来存储、检索和删除本地设备上的对象。在文件系统中对象以二进制文件的形式存储它的元数据存储在文件系统的扩展属性xattr中建议采用默认支持扩展属性xattr的XFS文件系统。每个对象使用对象名称的哈希值和操作的时间戳组成的路径来存储。最后一次写操作总可以成功并确保最新一次的对象版本将会被处理。删除也被视为文件的一个版本一个以.ts结尾的0字节文件ts表示墓碑。 复制服务Replicator会检测本地分区副本和远程副本是否一致具体是通过对比哈希文件和高级水印来完成发现不一致时会采用推式Push更新远程副本对于对象的复制更新只是使用rsync同步文件到对等节点。帐号和容器的复制通过HTTP或rsync来推送整个数据库文件上丢失的记录另外一个任务是确保被标记删除的对象从文件系统中移除当有一项对象、容器、或者帐号被删除则一个墓碑文件被设置作为该项的最新版本。复制器将会检测到该墓碑文件并确保将它从整个系统中移除。 更新服务Updater当对象由于高负载或者系统故障等原因而无法立即更新时任务将会被序列化到在本地文件系统中进行排队以便服务恢复后进行异步更新例如成功创建对象后容器服务器没有及时更新对象列表这个时候容器的更新操作就会进入排队中更新服务会在系统恢复正常后扫描队列并进行相应的更新处理。 审计服务Auditor在本地服务器上会反复地爬取来检查对象容器和账户的完整性如果发现比特级的错误文件将被隔离并复制其他的副本以覆盖本地损坏的副本其他类型的错误比如在任何一个容器服务器中都找不到所需的对象列表会被记录到日志中。 账户清理服务AccountReaper移除被标记为删除的账户删除其所包含的所有容器和对象。删除账号的过程是相当直接的。对于每个账号中的容器每个对象先被删除然后容器被删除。任何失败的删除请求将不会阻止整个过程但是将会导致整个过程最终失败例如如果一个对象的删除超时容器将不能被删除因此账号也不能被删除。整个处理过程即使遭遇失败也继续执行这样它不会因为一个麻烦的问题而中止恢复集群空间。账号收割器将会继续不断地尝试删除账号直到它最终变为空此时数据库在db_replicator中回收处理最终移除这个数据库文件。 图4 Swift系统架构 Swift支持的所有操作可以总结为下表 表1 SwiftRESTful API总结 4.3 Ring的数据结构 Ring 的数据结构由三个顶层域构成其中 List of Devices表示集群中设备的列表在Ring类内部被称为devs Partition Assignment List用于存放每个replica与device间映射关系在Ring类内部被称为_replica2part2dev_id Partition Shift Value表示计算数据hash的移位量在Ring类内部称为_part_shift。 使用python读取/etc/swift/object.ring.gz存放的数据可以获得以devs、 part_shift、 replica2part2dev_id 为key的dict类数据。 4.4 Swift存储结构 在Storage Node上运行着Linux系统并使用了XFS文件系统逻辑上使用一致性哈希算法将固定总数的partition映射到每个Storage Node上每个data也使用同样的哈希算法映射到partition上。 存储内容一般放在/srv/node/sdb1之类的路径下其目录结构如下所示accounts、async_pending、containers、objects、quarantined和tmp。其中accounts、containers、objects分别是账号、容器、对象的存储目录async_pending是异步待更新目录quarantined是隔离目录tmp是临时目录。 objects在objects目录下存放的是各个partition目录其中每个partition目录是由若干个suffix_path名的目录和一个hashes.pkl文件组成suffix_path目录下是由object的hash_path名构成的目录在hash_path目录下存放了关于object的数据和元数据object的数据存放在后缀为.data的文件中它的metadata存放在以后缀为.meta的文件中将被删除的Object以一个0字节后缀为.ts的文件存放。 accounts在accounts目录下存放的是各个partition而每个partition目录是由若干个suffix_path目录组成suffix_path目录下是由account的hsh名构成的目录在hsh目录下存放了关于account的sqlite db在account的db文件中包含了account_stat、container、incoming_sync 、outgoing_sync 4张表其中表account_stat是记录关于account的信息如名称、创建时间、container数统计等等表container记录关于container的信息表incoming_sync记录到来的同步数据项表outgoing_sync表示推送出的同步数据项。 containerscontainers目录结构和生成过程与accounts类似containers的db中共有5张表其中incoming_sync和outgoing_sync的schema与accounts中的相同。其他3张表分别为container_stat、object、sqlite_sequence表container_stat与表account_stat相似其区别是container_stat存放的是关于container信息。 tmptmp目录作为account/container/object server向partition目录内写入数据前的临时目录。例如client向server上传某一文件object server调用DiskFile类的mkstemp方法创建在路径为path/device/tmp的目录。在数据上传完成之后再调用put()方法将数据移动到相应路径。 async_pendingasync_pending存放未能及时更新而被加入更新队列的数据。本地server在与remote server建立HTTP连接或者发送数据时超时导致更新失败时将把文件放入async_pending目录。这种情况经常发生在系统故障或者是高负荷的情况下。如果更新失败本次更新被加入队列然后由Updater继续处理这些失败的更新工作account与container的db和object两者的pending文件处理方式有所不同db的pending文件在更新完其中的一项数据之后删除pending文件中的相应的数据项而object的数据在更新完成之后移动pending文件到目标目录。 quarantinedquarantined路径用于隔离发生损坏的数据。Auditor进程会在本地服务器上每隔一段时间就扫描一次磁盘来检测account、container、object的完整性。一旦发现不完整的数据该文件就会被隔离该目录就称为quarantined目录。为了限制Auditor消耗过多的系统资源其默认扫描间隔是30秒每秒最大的扫描文件数为20最高速率为10Mb/s。account和container的Auditor的扫描间隔比object要长得多。 图5 隔离对象的处理流程 5 小结 Swift牺牲一定程度的数据一致性来达到高可用性和可伸缩性支持多租户模式、容器和对象读写操作适合解决互联网的应用场景下非结构化数据存储问题。 有理由相信因为其完全的开放性、广泛的用户群和社区贡献者Swift可能会成为云存储的开放标准从而打破Amazon S3在市场上的垄断地位推动云计算在朝着更加开放和可互操作的方向前进。 6 参考资料 1) 《Openstack Swift 原理、架构与 API 介绍》http://www.kankanews.com/ICkengine/archives/66411.shtml 2) 《深入云存储系统Swift核心组件Ring实现原理剖析》http://www.cnblogs.com/yuxc/archive/2012/06/22/2558312.html 3) 《深入云存储系统Swift核心组件Ring数据结构及构建、重平衡操作》http://www.cnblogs.com/yuxc/archive/2012/06/28/2568584.html 4) 《深入云存储系统Swift存储节点存储实现分析》http://www.cnblogs.com/yuxc/archive/2012/07/04/2575536.html 5) 《OpenStack对象存储——Swift开源云计算》http://dev.yesky.com/244/33228744.shtml 6) 《讨论HDFS和OpenStack对象存储的技术差异》http://os.51cto.com/art/201202/314254.htm转载于:https://www.cnblogs.com/sdjnzqr/p/3909498.html
