订阅云计算RSS CSDN首页> 云计算

新浪SAE存储工程师杨雨:Swift架构与实践

发表于2012-08-11 09:21| 次阅读| 来源CSDN| 0 条评论| 作者CSDN

摘要:新浪SAE存储工程师杨雨带来的主题为《Swift架构与实践》的精彩分享,他首先对Swift的原理和架构进行了介绍,通过分析Swift的原理,然后一步一步介绍它的架构实践;第二部分就是介绍Swift在新浪云计算的实践;最后介绍了在使用和部署过程中遇到的一些问题,以及一些改进的建议。

8月11日,首届OpenStack亚太技术大会(OSAC)进入第二天。作为OpenStack社区在亚太区的 首次技术大会,地区覆盖中 国、日本和韩国,数十位国外的OpenStack核心企业及国内前沿开发者将齐 聚OSAC。此次大会由全球最大中文IT技术社区CSDN和中国 OpenStack用户组COSUG联合举办, CSDN将对大会做全程报道,进入直播专题。

在8月11日北京站第二天的活动中,分论坛的第一场是由新浪SAE存储工程师杨雨带来的主题为《Swift架构与实践》的精彩分享。他与大家分享了OpenStack中的Swift组件,第一个是Swift的原理和架构,将通过分析Swift的原理,然后一步一步介绍它的架构实践。第二个就是Swift在新浪云计算的实践。第三个就是我们在使用和部署过程中遇到的一些问题,以及一些改进的建议。

新浪SAE存储工程师杨雨

存储有文件存储,块存储还有一些其他的存储。Swift属于一个对象存储,它使用一个FPP协议,然后有一个接口。存储有三个指标,一个是高性能,一个高可靠性以及低廉的成本,Swift对象存储选择了两个指标,一个是高的可靠性和一个低廉的成本。Swift的社区目标是什么?首先是高的可靠性,高的可靠性主要有两个指标,一个是数据是一个高持久的,而且数据的存储服务是高可用的。如果数据很持久,但是服务经常宕机的话,高可用性就达不到,那么高可靠性也就不能实现。

极高的数据持久性

一些朋友经常将数据持久性(Durability)与系统可用性(Availability)两个概念混淆,前者也理解为数据的可靠性,是指数据存储到系统中后,到某一天数据丢失的可能性。例如Amazon S3的数据持久性是11个9,即如果存储1万(4个0)个文件到S3中,1千万(7个0)年之后,可能会丢失其中1个文件。那么Swift能提供多少个9的SLA呢?下文会给出答案。针对Swift在新浪测试环境中的部署,我们从理论上测算过,Swift在5个Zone、5×10个存储节点的环境下,数据复制份是为3,数据持久性的SLA能达到10个9。

无限的可扩展性

这里的扩展性分两方面,一是数据存储容量无限可扩展;二是Swift性能(如QPS、吞吐量等)可线性提升。因为Swift是完全对称的架构,扩容只需简单地新增机器,系统会自动完成数据迁移等工作,使各存储节点重新达到平衡状态。

简单、可依赖

简单体现在架构优美、代码整洁、实现易懂,没有用到一些高深的分布式存储理论,而是很简单的原则。可依赖是指Swift经测试、分析之后,可以放心大胆地将Swift用于最核心的存储业务上,而不用担心Swift捅篓子,因为不管出现任何问题,都能通过日志、阅读代码迅速解决。

  

Swift利用一致性哈希算法构建了一个冗余的可扩展的分布式对象存储集群。Swift采用一致性哈希的主要目的是在改变集群的Node数量时,能够尽可能少地改变已存在Key和Node的映射关系。 该算法的思路分为以下三个步骤。 首先计算每个节点的哈希值,并将其分配到一个0~232的圆环区间上。其次使用相同方法计算存储对象的哈希值,也将其分配到这个圆环上。随后从数据映射到的位置开始顺时针查找,将数据保存到找到的第一个节点上。如果超过232仍然找不到节点,就会保存到第一个节点上。 假设在这个环形哈希空间中存在4台Node,若增加一台Node5,根据算法得出Node5被映射在Node3和Node4之间,那么受影响的将仅是沿Node5逆时针遍历到Node3之间的对象(它们本来映射到Node4上)。其分布如上图所示。

至于Swift在新浪的部署情况,我们的部署方案每台机器都具有一样的部署,然后前端有一个负载均衡。但是这可能并不是一个最优的存储的部署。然后我们还做了Ring1操作系统,其他的盘做了一些存储。然后介绍一下我们怎么用Swift做的一些事?首先我们开发了一个认证模块,这个认证模块就是为了支持SAE的认证方式,然后用户通过可以访问Swift存储,然后来请求授权,哪些权限可以获得哪些资源。然后第二个工作SAE也可以使用周边的工具,比如说java,PHP等,这些SDK我们可以直接拿过来用,客户端也可以直接通过SAE的帐户体系直接使用。第三个就是一个模块,做一个SAE的控制,可以给这个对象添加一个规则,规则用户就可以按需求来定,这个可以来缓解我们的压力,用户获取以后,很长一段时间之后它的图片是不会更新的,用户根据自己的需求来设计一个规则,比如说图片要保持多久等。,还有一个存储配额的东西,我们不可能为每一个用户提供无限的存储,如果用户增长过快的话,就会对存储有一个冲击,所以要对用户存储做限制。

下面就是Swift的一些问题,第一个问题保持进程的一致性,这些进程是很低效的,这些进程的工作方式是什么呢?它会循环磁盘上所有的文件,然后循环每一个目录的后缀目录,然后把后缀目录的hash值然后又请求其他的结点,比较这个值,如果不一致,就把数据继续推进,然后把所有的记录同不同步也询问一遍,当存储量很小的时候,是看不到这个问题的,但是随着存储量越来越大,那么这个过程是很耗时的,然后带来的结果是什么?一个是整个读写变慢了,而且还有很高的占用率。然后怎么来改善呢?首先第一个方式就是通过运维的方式,平时把线上的那些复制更新进程关掉,在业务比的低峰期就可以把这个打开跟数据同步,这就保证要有监控系统,如果出现了副本不一致的情况,数据没写成功的情况,就需要探测到这个情况,把这个数据尽快地恢复到一致,这样才能保证用户数据的安全持久。然后第二个方式就是说一种更合适的部署方案。第三个就是来保证副本一致性的协议,它是知道哪些数据是写失败了,通过一个消息并列把这些任务分布,它们就不用再去轮询整个磁盘,来决定应该同步哪些数据,这个可能是我们后续考虑改进的方案。

更多内容请关注:http://www.buildcloudstorage.com/2012/08/is-openstack-swift-reliable-enough-for.html

更多OSAC及OpenStack相关信息,请关注@CSDN云计算微博,也欢迎加入国际云计算技术交流群OpenStack中文社区 进行交流讨论。

0
0
新浪SAE存储工程师杨雨:Swift架构与实践