设为首页 收藏本站
查看: 1513|回复: 0

[经验分享] Openstack swift 学习笔记

[复制链接]

尚未签到

发表于 2015-4-12 08:23:25 | 显示全部楼层 |阅读模式
  Swift 不是文件系统或者实时的数据存储系统,而是对象存储,用于长期存储永久类型的静态数据。这些数据可以检索、调整和必要时进行更新。Swift最适合虚拟机镜像、图片、邮件和存档备份这类数据的存储。
  Swift没有采用RAID,也没有中心单元和主控点,而是通过在软件层面采用一致性HASH和数据冗余性,牺牲一定程度的数据一致性达到高可用性和可收缩性。支持多用户模式、容器、和对象存储。最佳应用场景为非结构化数据存储问题。所谓的非结构化数据是相对于结构化数据而言的,节后数据即行数据,存储在数据库中,可以用二维表结构来逻辑实现的数据,而非结构化数据不方便用数据库二维逻辑表来表现,包括所有格式的办公文档、文本、图片、标准通用标记语言下的子集XML、HTML、各类报表、图像和音频/视频。
  swift的主要技术特点:
  1、极高的数据持久性
  2、完全的对称系统架构:对称意味着Swift中的各节点可以完全对等,能极大的降低成本
  3、无限的可扩展性:一方面是数据可以无限的扩,另一方面Swift的性能可以线性提升(暂时没有体会到,可以再后续的阅读了解中体会,主要看它的架构设计)
  4、无单点故障:Swift的元数据存储时完全均匀随机分布的,并且与对象文件存储一样,元数据也会存储多份。
  swift与HDFS的技术差异
  1、在Swift中,元数据呈分布式,跨集群复制,而在HDFS中,采用中央系统(Namenode)来维护元数据,这对于HDFS来说,无疑使单点故障点,因而扩展到规模非常大的环境很困难
  2、Swift设计时考虑到多租户架构,而HDFS没有考虑这个概念(下午学习什么是多租户架构)
  3、在Swift中,文件可以写入多次,在并发场景下,以最近一次的的操作为标准。而在HDFS中,文件写入一次,而且每次只能有一个文件写入
  4、Swift能够可靠地存储数量非常多的大小不一的文件,而HDFS用于存储数量中等的大文件,来支持数据处理。
  注:存储系统元数据的缺点:元数据是指记录数据逻辑与物理位置的映像关系。对于元数据的管理一般分为两种,一种是使用集中式元数据服务来维护元数据,如HDFS,这种维护方式会导致单点故障和性能瓶颈,另外一种是使用分布式元数据服务来维护元数据,如OpenStack的Swift,这种维护方式存在性能负载和元数据同步一致性问题,如Swift就是通过系统一定程度的数据一致性来达到高可用性和可伸缩性的。
  Swift的原理:
  1、一致性Hash
  一致性Hash算法提出了在动态变化的Cache环境中,判定hash算法好的标准:
  1、平衡性:平衡性是指哈希的结果能够尽可能的分布到所有的缓冲中去,这样可以使得所有缓冲空间能够都得到利用。为了更好的满足平衡性,引入了虚拟节点概念,虚拟节点是实际节点在hash空间的复制品,一个实际节点对应若干个虚拟节点,这个对应的个数也称为复制个数,虚拟节点在hash空间以hash值排列。
  2、单调性:单调性是指如果已经有些内容通过Hash分派到相应的缓冲中,又有新的缓冲加入到系统中,哈希的结果应能够保证原有已分配的内容可以被映射到原有或者新的缓冲中区,而不会被映射到旧的或者其他缓冲区。
  3、分散性:在分布式环境中,客户端可能看不到所有的缓冲,而只能看到其中一部分。当终端希望通过哈希过程将内容映射到缓冲上时,由于不同的客户端所看到的缓冲范围可能不同,从而导致得到的Hash结果不一致,导致结果相同的内容被映射到不用的缓冲区中。这种情况应该被避免,因为这将会导致相同的内容将会被映射到不同缓冲区中,降低了系统的存储效率。
  4、负载:负载时对分散性要求的另一个维度。既然相同的内容可能被映射到不同的缓冲中去,那么对于同一个缓冲而言,就有可能被不同的用户映射不同的内容。与分散性一样,这种情况应该被避免。
  swift使用一致性Hash的主要目的是在改变集群的节点数时,能尽可能少的减少key和node的映射关系,以满足单调性。
  由于在node较少的情况下,改变node会导致大量的数据迁移,因此使用虚拟节点。
  Swift中存在两种映射关系:对于一个文件,通过hash算法找到对应的虚拟节点,虚拟节点再通过映射关系找到对应的设备,这样就文在在设备上的存储。(关于虚拟节点和节点的个数设置后续再学习)
  数据一致性模型
  根据CAP理论,一致性、可用性、分区容忍性三个方面只能满足两方面,Swift放弃了一个一致性,而采用一致性模型,以达到高可用性和水平扩展能力。
  为了控制一致性,Swift采用了NWR策略(Quorum协议),NWR是一种在分布式存储系统中控制一致性级别的策略,其中N代表一份数据的Replica数,
  W是更新一份数据对象确保成功更新成功的份数,R代表读取一个数据需要读取的Replicad的份数。公式W+R>N保证某个数据不被两个不同的事物同时读和写,公式W>N/2,保证两个事物不能并发写同一份数据。在分布式系统中,通常把备份数目设置为3份,如果是1,则是非常危险的,一旦这个Replica失败了,则数据就损坏了,如果N为二,那么只要一个存储节点发生错误,就会有单点存在。如果副本数设置过高高,则系统的维护成本就会变高。
  补充:对于NWR,强一致性:R+W>N,以保证对副本的读写操作可以产生交集,从而保证可以读到最新版本;如果W=N,R=1,则需要全部更新,适合大量读少量写操作的场景下的强一致性。如果R=N,W=1,则只更新一个副本,通过读取全部分布来得到最新版本,适合少量读大量写的的强一致性。
  
  环是Swift中的重要组件,用于记录存储对象和物理位置间的映射关系,在查询Account、Container、Object信息时就需要查询集群的Ring信息。
  ring是为了将虚拟节点(partition)均衡的映射到一组物理存储设备上,并提供一定的冗余度而设计的
  Swift为账户、容器和对象分别定义了环,其查找过程是相同的。Ring中每个分区的在集群中都默认有3个副本,每个分区的位置都有ring来维护,并存储在映射中。
  Ring使用zone来保证数据的物理隔离,每个分区的副本数确保放在不同的zone中。
  总的来说,Ring引入一致性Hash的原因是为了减少由于增加节点导致数据项移动的数量来提高单调性,引入partition的原因是为了减少由于节点数过少而导致移动过多的数据项,引入副本为了防止数据单点,提高冗余性,引入zone的原因是为了保证分区容忍性,引入权重是为了保证分区的分配的平衡性。
  swift架构设计
DSC0000.jpg
  Swift部署架构
  主要组件:
  1、Proxy Server
  Proxy Server是提供swift api的服务器进程,swift通过Proxy Server 向外提供基于HTTP和RESET的服务接口,负责swift其余组件的相互通信。对于每个客户端的请求,它将在环中查询Account、Container或者Object的位置,并相应的转发 请求。由于采用无状态的REST请求协议,可以进行横向扩展来均衡负载。在访问swift之前,要先通过认证服务获取访问令牌,然后在发送的请求中加入头部信息 X-Auth-Token。
  2、Storage Server
  Storage Server提供累了磁盘设备上的存储服务。在Swift中有三类存储服务器账户服务器(Account Server)、容器服务器(Container Server)、对象服务器(Object Server)。
  2.1 Account Server
  账户服务提供账户元数据和统计信息,并维护所含容器列表的服务,每个账户的信息被存储在一个SQLite数据库中
  2.2  Container Server
  容器服务器提供容器元数据和统计信息,并维护所包含对象列表的服务。容器并不知道对象存在位置,只知道容器里存的那些对象。这些对象信息以SQLLite数据库文件的形式存储,和对象一样在集群上做类似的备份。
  2.3 Object Server
  对象服务器提供元数据和内容服务,用于存储、检索和删除本地设备上的对象。在文件系统中,对象以二进制的文件的形式存储,它的元数据存储在文件系统的扩展属性中,建议采用默认支持扩展属性饿XFS文件系统。每个对象使用对象名称的哈希值和操作的时间戳组成的路劲来存储。最后一次的写操作总可以成功,并确保最新一次的对象版本将会被处理。
  3、Consistency Server
  在磁盘上存储数据并向外提供Rest-ful API 最主要的问题是故障处理。Swift的Consistency Server的目的是查找并解决由数据损坏和硬件故障引起的错误。主要由3个server组成,Auditor、Updater、和Replicator。Auditor运行在每个Swift服务器的后台持续的扫描磁盘来检测对象、容器和账号的完整性,如果发现数据损坏,Auditor将会将该文件移动到隔离区域,然后由Replicator负责将一个完好的副本来替代该数据。在系统高负载或者发生故障的情况下,容器或账号中的数据不会被立即更新。如果更新失败,该次更新在本地文件系统中被加入队列,然后Updater会继续处理这些失败了的更新操作。
  3.1 审计服务(Auditor)
  在本地服务器上反复的检查对象、账户和容器的完整性,如果法相比特级的错误,文件将会被隔离,然后由Replicator负责用一个完好的拷贝来替代该数据,其他类型的错误会被记录到日志中
  3.2 复制服务(Replicator)
  该服务一方面用于检测本地分区副本和远程副本是否一致,具体方式是用对比哈希文件盒高级文件水影来完成,当发现不一致时采用push的方式更新远程副本:对于对象的复制,更新只是使用rsync同步文件到对等节点。账号和容器的复制通过HTTP或Rsync来推送整个数据库文件上丢失的记录,另一方面用于确保被标记删除的对象从文件系统中移除:当有一项被删除,则一个墓碑文件被设置为该项的最新版本,复制器或检测到该墓碑文件确保将他从整个系统中移除。
  3.3  更新服务(Updater)
  当对象由于高负载或者系统故障等原因而无法立即更新时,任务将会被序列化到本地文件系统中进行排队,以便回复后进行异步更新。
  4、Cache Server
  缓存的内容包括对象服务令牌,账户和容器的存在信息,但不会缓存对象本身的数据。

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-56157-1-1.html 上篇帖子: [网摘学习]关于OpenStack架构 下篇帖子: 【转】 [官版翻译ing]OpenStack云计算快速入门之三:OpenStack镜像管理
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表