1、 基于Amazon S3的文件系统中CAS层的设计与实现摘要网络文件系统常会花费很对精力在数据的分布式部署上,实际上现在很多优秀的第三方的服务商会提供完备的云存储服务,省去了开发人员大量管理数据的精力。开发基于云存储的文件系统是未来的存储技术发展趋势的观点已经被广为接受。为了防止用户误操作和其它灾害的发生导致数据的丢失,多版本连续技术被应用到基于Amazon S3的文件系统(Amazon-S3-based file system,下称S3fs)的开发中。因此每一次修改的版本都会被保留。 然而针对网络文件系统,尤其同步式的、基于第三方“云”的文件系统,过多的数据量会增加“云”端的所需要支付的费用
2、。然而这些额外的费用尚且可以接受,但是关键问题是会增加每个文件操作所带来的延迟。试想如果单纯的进行多版本连续的维护,每次修改文件都需要对整个文件进行备份,那样带来的额外带宽消耗是成倍增长的。 因此S3fs引入了重复数据删除技术,对每个文件进行分段,每次修改只需要同步更新的内容而避免整个文件的同步。 同时重复数据删除技术不仅允许在同一文件的不同版本之间进行数据段重复利用,还可以对不同文件进行相同数据段重复利用。这样就更加节省了磁盘的开销。本文主要介绍了S3fs的设计思想和实现方法,并着重描述底层CAS(Content Addressable Storage)层与云端通信的实现。S3fs是基于Am
3、azon S3在Linux 2.6 内核上使用Fuse为开发框架的用户态文件系统。S3fs的底层与云端操作是对用户透明,用户在对文件操作与普通文件系统无差别。而S3fs会自动的将文件的修改同步到S3服务器上。同时会根据同步策略与S3服务器同步,采用松耦合解决并发一致性问题。 S3fs还会自动保留多版本,但对用户同样是透明的,一般用户只能看到最后版本。S3fs还会对文件分段存储管理,并以内容计算哈希值进行索引,在每次同步进行重复数据删除来减小网络带宽的占用户数据量的传输及存储。关键词文件系统 AmazonS3多版本 重复数据删除 CASThe Design and Implementation
4、of CAS layer of an Amazon-S3-based File SystemABSTRACTNetwork File System often takes much time in distributed management of remote date access. Actually there are many 3rd-party excellent service providers can offer mature cloud storage service, saving much energy used to be concerned with data man
5、agement by developers. We argue that cloud-based file system is the trend of future storage development. To avoid losing data by users misoperation and other disasters, we propose the technique of continuous multi-version, which could remain every version of the same file automatically. However, for
6、 network file system, especially cloud-based file system with a synchronization policy, more data volume may lead users to purchase more fees for using network resources. Actually these fees are acceptable. The central problem is more data would consume more network workload and increase the delay c
7、aused by each file operation. We should hold two times space for each multi-versioned operation than common file operation which means two times more resource consumption would be used. Thus, we combine this cloud-based file system with Deduplication. We divide each file into many data segment which
8、 we called “chunk”. And we only update the last modified chunk instead of the whole file. Deduplication also allows us to exploit the similarity between different files. In this case, more resources could be saved. This paper describes the design and implementation of S3fs, and particularly shows th
9、e implementation of CAS (Content Addressable Storage) layer which also needs to communicate with S3 server. S3fs is developed through the frame of FUSE based on Amazon S3. The communication between CAS and S3 is transparent for users. Common users could access the latest version of the file only. S3
10、fs also take the management of chunked file indexed by hash value, which could reduce the consumption of bandwidth caused by synchronization. S3fs is implemented as a user-space file system by FUSE in the Linux 2.6 kernel. KEY WORDS Filesystem AmazonS3 Continuous-versioning Deduplication CAS北京邮电大学本科
11、毕业设计(论文)目 录第一章 引言11.1 研究意义11.2 研究背景2第二章 相关的关键技术42.1 重复数据删除42.2 连续多版本保护及索引52.3 本地cache以及并发访问和一致性问题72.4 云存储72.5 亚马逊 简单存储服务 (Amazon S3)92.5.1 S3的组成102.5.2 S3提供的常用操作112.5.3 亚马逊S3的一致性模型112.5.4 S3的身份认证112.5.6访问权限控制12第三章 S3fs文件系统的设计133.1系统模型概述133.2 CAS层的设计及S3fs工作流程163.2.1文件系统与S3的接口设计163.2.2创建与删除文件流程193.2.3
12、 修改文件流程193.2.4文件路径统一策略及修改流程203.2.5重命名文件流程213.2.6创建目录与删除流程213.2.7 本地cache与S3同步策略与流程223.2.8 旧版本文件恢复223.2.9文件系统临界区问题22第四章S3fs文件系统的实现23第五章系统测试28第六章总结336.1 存在问题336.2 结束语33参考文献35致 谢3737第一章 引言1.1 研究意义自从计算机技术的出现到现在,存储技术一直是被众多研究者和开发者所津津乐道。数据无疑是整个计算机系统最为关键的部分之一。因此如何高效、安全的管理数据直接影响到用户对计算机体验效果。目前,在整体信息技术界飞速创新发展的
13、大背景下,数据量同样在以前所未有的速度高速增长。传统的文件系统仅仅保证数据在本地的正确保存。然而意外事件的不断频发,如天难人祸,黑客病毒的破坏,数据的丢失无疑都会给数据使用者带来无法挽救的后果。所以对数据的保护以及备份成为了当下最热门的研究话题之一。因此用户更希望一种文件系统能够在对数据进行常规部署的同时进行恰当的数据保护措施。现在,磁盘的价格越来越低,所以导致开发者更倾向于利用空间换取数据安全的策略。而用户的备份意识目前还停留在传统、单纯的将现有的文件,甚至是显示的复制副本保存。这样的方法是最简单的,也能够避免意外的发生导致数据的丢失。但是这样的策略却忽略了一点,就是用户的误操作。现实生活中
14、很多情况造成数据丢失或意外被更改都是因为用户主观上的误操作所带来。比如一个人在将文件修改多次后发现其中的某一次修改导致了重大的错误,而即便有备份系统,那一次修改的文件也已经被后边无数次的修改所覆盖。如此这般无论粒度多么细的备份策略都无法挽回损失。因此本着牺牲磁盘空间换取数据的高可靠性的原则,引用了连续多版本保护技术。即用户的每一次的文件操作所引起的文件版本的变化都会被存储下来。这样就保证了用户可以根据需要(或是管理员)去访问任何一个版本,避免任何意外的发生。将各个版本存放在本地磁盘虽然能避免用户误操作所带来的损失,但是就失去了传统的灾备意义。很自然的将目光投向网络。在网络技术和分布式计算技术的
15、成熟,“云”的概念逐渐清晰并且出现了成熟的商业技术。云存储作为应运而生的一项技术,在目前和未来都会成为开发人员一个重要的研究方向和解决平台。目前,有少数的公司已经推出了云存储的产品。传统的在常见的局域网系统中,为了能更好地使用局域网,一般来讲,使用者需要非常清楚地知道网络中每一个软硬件的型号和配置,比如采用什么型号交换机,有多少个端口,采用了什么路由器和防火墙,分别是如何设置的。系统中有多少个服务器,分别安装了什么操作系统和软件。各设备之间采用什么类型的连接线缆,分配了什么地址和子网掩码。在做文件系统开发的同时需要关心什么数据存放在网络内哪个节点。而通过调用云存储服务零售商提供的公共标准接口,
16、将数据进行上单纯的上传操作,而后续的存储管理和安全保障都交给云端负责,开发者并不要关心,仅仅需要支付少量的服务使用费用。其中Amazon S3是一个较为成熟稳定的云存储服务。因此,基于云的文件系统较于网络文件系统,会节省许多需要花费在数据在网络上部署的精力。所以将数据都备份到“云”就成为了人们青睐的选择。选择云端所带来的问题是如果S3fs单纯的对文件进行连续多版本的保留,会导致每次新版本生成都需要将新生成的文件传输到云上。这样所占用的网络带宽、产生的延迟和需要支付的费用都会成倍的增长。而且现在用户往往需要在低带宽的环境下进行网络远程操作,这样带来的网络延迟的增长就显得无法接受了。比如,一个交互
17、编辑器会阻塞用户前端输入以便写100K “自动存储”的文件而不用考虑用户的输入或者消耗特别大的资源。 一个传统的文件系统传输文件的整个内容在网络上并且在传输过程中会阻塞编辑器。如果延迟过长,编辑器就会产生假死的情况。因为一般的交互编辑器在考虑网络延迟时无法统一标准,所以很难制定一个恰等的阻塞等待时间。 文本编辑器亦是如此,很难想象一些媒体编辑器会带来怎样糟糕的用户体验。 因此在开发过程中引入了重复数据删除技术。这样S3fs就不会由每次文件操作而引起整个文件在网络上的传输从而大大减少了数据传输量,节省了资源。通过上述原因,S3fs将会是这样一个文件系统: 是基于连续多版本的,能够自动冗余数据删除
18、,所有本地数据都与云服务器进行相连并根据一定策略同步同时保证并发性访问所导致的一致性问题。 1.2 研究背景当前最为常用的文件系统(ext2/3,FAT,NTFS等)都会以每次文件操作为基础立即对操作文件进行释放、更新、删除,而并不会保留任何副本。我们需要开发一个新的文件系统。现有的文件系统都是运行在操作系统内核,因此包括安全等问题导致难以对其进行功能扩展。经过前期调研,发现FUSE(filesystem in user space)框架。它是建立在VFS机制之上。本文所提出的S3fs就是基于fuse框架下实现的文件系统,突破了核心级应用的限制,更加方便的对其进行功能扩展。目前很多成熟的文件系
19、统都是基于fuse框架开发的,比如gmailfs,sshfs,p2p-fs等。Fuse框架本身会提供很多完备的API,S3fs是基于fuse中C语言的API库进行开发的。在选择云存储产品的时候,目前亚马逊S3、谷歌的Google Storage、以及AT&T和EMC都提供第三方存储服务,而零售巨头亚马逊公司所提供的云存储服务S3(Simple Storage Service,即简单存储服务)是非常成熟的,也是目前应用比较多的。由于它是公开的web服务,亚马逊将自己的“弹性计算云”建立在公司内部的大规模集群计算的平台之上,而用户可以通过弹性计算云的网络界面去操作在云计算平台上运行的各个实例。 弹
20、性计算云平台为用户或者开发人员提供了一个虚拟的集群环境,使得用户的应用具有充分的灵活性。同时Amazon S3本身提供非常安全的用户验证机制,使得开发者不用花更多的时间在文件的保密性上。基于上述特点和背景,我们希望开发出一款与存储零售商所提供的云存储服务相连的文件系统,能够让用户透明的在本机进行常规的文件系统,同时,文件系统底层与远端云相连从而达到自动备份的功能。在网络上进行数据的传输,首先就会考虑到网络延迟的问题。而在一个特定的网络环境下只有 的减小传输的流量以达到减小网络带宽的利用,减小响应时间。 除此之外,IDC最新报告显示【1】,2007年新增数据量(281 Exabyte)已经超过所
21、有可用存储介质总容量(264 Exabyte)约6%,并预计2011年数据总量将达到2006年的10倍。面对数据的爆炸性增长,仅仅提高系统运算能力和增加存储介质容量已经不能满足高速发展的各种数据应用,对高效数据缩减技术的需求已经逐步显现出来,并且越来越迫切。几年前人们还热衷于通过越来越低价存储介质来满足数据的存储。但是今天,人们的磁盘备份设备的容量已经趋于饱和,在数据中心已经没有足够的空间来备份PT级的数据,在这种情况下,当用户希望将备份数据保存一个月时,却只能保存两到三天。问题是在用户的备份设备中有太多的重复数据。重复数据删除是一种非常高级的数据缩减方式,可以极大的减少备份数据的数量。这种技
22、术通过减少存储的数据量,改变数据保护方式,卓越的提升了磁盘备份方式的经济性。重复数据删除被业界公认为备份技术的下一代发展步骤,是今日数据中心的“必备”技术。重复数据删除允许文件系统将最小操作单位降为数据块而不是文件。它利用不同的文件之间的相似块而将重复数据删除。在文件备份中,对文件各个版本都保留下来无疑是最为安全的方法。目前有一些针对多版本文件控制的文件系统是以快照的方式进行多版本管理,如Plan 9【2】是为文件系统每天做一次快照并将副本存于安全的存储介质,WAFL【3】是利用copy-on-write的数据块来节省磁盘空间, AFS也是通过copy-on-write来使用户访问更加原始的文
23、件版本。它们通过对当下的文档进行快照保存文件副本。但是这样似乎却存在一种“盲点”,即在两个快照点之间的改写是无法被文件系统所记录的。另外,这种基于快照的文件系统每次是将整个文件系统进行快照,而并不是针对有修改或变动的文件,大大浪费了系统资源。 S3fs就并没有这样的问题,它是采用即时的对每个文件更新操作进行捕获而针对更新文件进行的备份操作。本文主要介绍了S3fs的设计思路并着重介绍了CAS层的实现方法和流程。其中第二章介绍了S3fs所涉及的相关技术。第三章给出了了S3fs的设计思想和各个操作的算法流程。第四章则简要描述具体的实现方法和所支持功能的使用方法。第五章描述对S3fs做了简单的功能和性
24、能测试。第六、七章则是在毕设过程中做过的相关工作和对已完成的任务的总结和对自己未来的展望。 第二章 相关的关键技术S3fs的设计之初对该文件系统做了一个简要的功能设定。其中包括多版本连续、重复数据删除、本地cache、允许并发访问等问题。在设计过程中根据实际情况延续了其中恰当的方法并进行了实现。2.1 重复数据删除2009年全球的数据量已经接近ZB级别,2010年的数据量已经达到1.2ZB,相当于福克斯公司热门电视剧24小时连续播放1.25亿年。在2020年,将增长45倍达到35ZB【1】。这样的增长速度使任何用户甚至企业对备份数据的存储空间都捉襟见肘。另有研究表明【4】,尤其在海量的存储空间
25、中,系统在管理的数据中有很大一部分是存在重复冗余的,其中最高可达到60%的数据是冗余的。将冗余的重复数据删除以增加磁盘的利用率就顺理成章的成为了人们的焦点和研究的热点。将重复的数据在传输存储之前进行筛选并删除,再通过网络进行备份传输,可以大大节省网络带宽的占用。简要的将重复数据删除技术分类,可根据操作对象分为文件级和数据块级重复数据删除。两者的差异在于减小的数据量不同。文件级重复数据删除是在文件操作后,将新文件的属性在数据库中进行索引,如果存在,则指修改指针指向相同文件,而如果不存在则写入新文件。相对的,数据块级重复数据删除则是将文件分为若干个块,对每个块进行索引。并将这些块与之前的信息进行比
26、较,如果存在相同的则不进行实际插入仅仅是插入指针,而没有重复的则再插入新信息。而就在数据块级重复数据中对文件分块的算法也是各不相同的。比如有固定块检测技术(fixed-sized partition)【5,6】、不定长度块检测技术【5,7,8】(content-defined chunking)以及滑动块(sliding block)技术【5】进行重复数据的查找与删除.其中在S3fs设计之初中,主要借鉴了了LBFS【8】中介绍的文件分段的方法。以48字节不覆盖数据段为单位并以2-13的概率定位边界段。图2-1【8】描述了LBFS中在对一个文件不同位置进行插入时分块的变化。并利用SHA-1【9】
27、对每一块的内容计算哈希值并作为索引值。同时当两个数据段内容所计算出来的哈希值相同时,我们假设这两个数据段便是完全一样的。图2-1【8】 a.文件原始状态,被分为7块 b.插入内容在c4块中间,并替换为c8块,其余块不变 c.在c5块插入后被计算成为边界,替换为c9 c10两块 d.边界段被删除,则取消原边界,将新段c11替换c2 c3段2.2 连续多版本保护及索引传统的灾备概念是对整个文件系统或特定的关键文件进行定期的备份,将数据副本单独存在另外一个磁盘介质上以防止本地磁盘上的数据遭到意外的破坏。举例来说,现在比较成熟的备份产品如EMC的Mozy backup,是根据用户设定的时间间隔如每12
28、小时、每天、甚至每周或自动分析系统空闲时间来做文件的备份。但是这样,在两次备份之间会出现很大的时间缝隙。用户的数据量与日俱增,更重要的是数据的重要性也逐渐提高,因此对于有些用户的要害应用来说,任何数量的数据丢失都可能会导致巨大的损失。因此如果以每天为单位进行备份,那就最多有可能丢失一天的数据。那么将文件无缝的备份就是用户们很希望系统能够实现的功能。既然传统的磁带备份间隔较长,那么怎样才能够做到连续的数据保护呢?连续数据保护正是为了解决这个问题而出现的。 连续数据保护是一种连续捕获和保存数据变化,并将变化后的数据独立于初始数据进行保存的方法,而且该方法可以实现过去任意一个时间点的数据恢复。连续数
29、据保护技术可能基于块、文件或应用,并且为数量无限的可变恢复点提供精细的可恢复对象。 因此,所有的连续数据保护解决方案都应当具备以下几个基本的特性:数据的改变受到连续的捕获和跟踪;所有的数据改变都存储在一个与主存储地点不同的独立地点中;恢复点目标是任意的,而且不需要在实际恢复之前事先定义。所以,连续数据保护可以提供更快的数据检索、更强的数据保护和更高的业务连续性能力,而与传统的备份解决方案相比,连续数据保护的总体成本和复杂性都要低。尽管一些厂商推出了连续数据保护产品,然而从它们的功能上分析,还做不到真正连续的数据保护,比如有的产品备份时间间隔为一小时,那么在这一小时内仍然存在数据丢失的风险,因此
30、,严格地讲,它们还不是完全意义上的连续数据保护产品,目前通常只能称之为类似连续数据保护产品。而当连续数据保护基于文件系统应用时,多半是基于文件的。由于发生文件修改,而会产生不同的文件版本,以时间作为识别。文件系统就需要侦听到每次文件数据发生改变而保留每一个版本即基于连续多版本的文件系统(continuous-versioned file system)。然而不同的文件系统在实现连续多版本的时候采用的索引方式是不同的。比如Elephant file system【10】 是采用将不同文件根据策略分为不同等级:Keep One, Keep All, Keep Safe,Keep Landmarks
31、。其中keep one是不保存多版本,keep all是保存全部连续多版本,keep safe和keep landmark是保存重要的、能满足撤销操作(undo)的重要版本。而不同版本是根据最后修改时间作为索引。在PersiFs【11】中,PersiFS将所有过去的文件的元数据存在一个B+树里。并且提供对当前版本的读写和对过去版本的只读的接口。过去版本和当前版本的文件不需要重复存储。B+树里的metadate和文件目录挂载点存在各自独立的数据结构中。其中数据段是根据LBFS中的算法实现的。数据段的边界是根据目录而定,并且根据哈希值进行识别。图2-2【11】是PersiFs在进行从(a)原始状态
32、- (b)插入b的状态- (c)插入q-(d)插入d 元数据的B+树的变更状态。 图2-2【11】 Persi在进行文件操作时,对每一个版本信息存储在元数据扩展中由于S3fs是基于用户态的文件系统,对元数据的处理有一定限制,所以开发采取了类似的思路在文件的层面做了版本控制,而未对底层元数据做直接扩展。2.3 本地cache以及并发访问和一致性问题事实上这些年在cache实践中用到的方法,应该说至少在10年前在高性能计算领域就已经成熟了。思想也很简单,就是通过恰当的策略将文件非严格同步的进行上传(针对远程存储服务)。而当采用非严格同步的策略(全写法或回写法),就会出现本地cache和远程服务器的
33、文件由并发访问所产生的不一致性的问题。比如在一端客户端a对文件F进行的访问,并进行常规文件操作。在a未对F结束操作并释放文件的时候,另一端客户端b对F进行访问请求后,就会引发F不同版本所导致的一致性问题。在解决该问题的方法上主要分为静态方法和动态方法【13】,其中动态方法更多的是依靠硬件完成。而在处理想S3fs所带来的远程一致性问题,S3fs采用静态通过软件进行恰当的策略设计所完成的。大致有如下几种策略(根据S3fs所面临的特定情况有所变化):a) 共享cache法. 禁止本地cache. 即所有的客户端都不允许存储自己cache而是采用统一的cache。b) 写无效法(write-inval
34、idate). 这个是指本地cache更新时,除了用写直达法更新远端服务器,还需要作废其他客户端的本地cache中的相关内容.在云存储的客户端中是难以实现的。c) 播写法(write-update). 如名字所说.有更新时广播,同步复制(更新)到各个机器的本地 cache. 同样难以实现。d) 目录表法. 简单的说就是有一张目录表表示某一项内容在各个节点缓存中是否存在和存在状态. 写的时候用这些信息来避免写操作。e) 不用本地 cache. 直接与远端服务器实时交换数据。S3fs并没有将过多的精力花费到处理cache和一致性问题上。S3fs所采取的策略是松一致性策略。即在S3fs挂载到目录上初
35、始化时,会将本地cache与远端服务器进行同步至最新版本。在文件系统使用过程中每次完成文件操作在释放文件后如果有更改则同步至服务器。由于S3fs采用多版本控制,所以并发访问以最后写回时间为准会记录每一个时间的文件版本,同时文件元数据会记录客户端IP,所以并不会导致严重的一致性问题。 另外,在对云端S3读取数据时所造成的一致性问题,将在下面简要介绍。2.4 云存储网络、分布式计算的发展,为互联网用户带来了云计算时代。简而言之,云计算就是用户进行付费后,使用云服务提供商所提供的网络应用。云存储是类似于云计算的一种扩展的概念。用户不需要了解云状网络中的拓扑结构,不用关心自己数据所存的物理位置,只需要
36、通过服务商提供的接口并交纳一定的费用。云存储的主要架构可以自下而上分为存储层、基础管理层、应用接口层、访问层,如图2-3【12】。 图2-3【12】 云存储的基础架构其中最底层存储层设计实际物理存储介质。该层可以被理解为一个超大的网络存储设备,连接类型也可能是NAS、SAN各式,并通过FC光纤网络将各个物理介质相连。是整个云存储的基础数据库。基础管理层云存储的核心部分。所有的技术实现都在这一层,云存储服务的好坏、可靠性也主要依靠这一层。主要负责统一管理下层存储层,并保证所有数据的高可靠性、统一可用性、冗余性等。应用接口层则是根据不同的云存储服务商提供的服务不同而有所不同。比如提供在线文本编辑服
37、务、视频点播服务以及网络相册等不同服务就需要提供针对不同软件的接口以方便用户使用。最顶层则是访问层,与用户直接接触的层。通过不同的公用接口登录云端使用服务。目前提供云存储服务的产品有很多,包括谷歌、微软、EMC等大牌公司都竞相推出。而老牌零售商Amazon所提出的网络存储服务S3(简单存储服务)与其他服务不同,更多面向开发者,是根据使用量而付费的。根据S3网站上公布的价格,每月使用5G空间,10G流量,大约需付出2.5$的成本,每年大概200RMB,同时考虑到高可靠性,所以价格是可以接受的。S3fs便选择此款云存储服务。2.5 亚马逊 简单存储服务 (Amazon S3)亚马逊简单存储服务(A
38、mazon S3,下称S3)是亚马逊网络服务(Amazon Web Services)在2006年3月推出的在线存储服务。亚马逊 S3拥有一个简单的web服务接口,可以用来随时随地地在网络上存取数据。Amazon使用高扩展性、可靠、快捷、价廉的数据存储基础设施运行它自己的全球站点网络,S3让任何一个开发者有权使用同样的数据存储基础设施.这项服务旨在最大限度地扩大规模效益并把利益传递给开发商. 采用使用-付费的运营方式。使用多少服务(包括流量、存储空间、操作次数等计量标准),交纳多少费用。图2-4为S3目前公布的价格:图2-4 亚马逊网站公布的S3的使用价格假设将自建网站的数据存放到S3上,可以
39、一下大致的费用估算,如表2-1: 文件数2000文件平均大小0.005 G月下载次数20000月上传次数2000所需总存储量10 G每月上传量10 G每月下载量100 G存储费用1.5 $上传费用1 $下载费用18 $操作请求费用忽略总计20.5 $表2-1 大致计算自建网站使用S3的各项费用及总和所以可以看出,对于一个月流量在百G级别的网站维护上来说,使用S3的费用搭配它的高可靠性是完全可以接受的。总结起来亚马逊S3有如下几个特点:1. 不需要自己的硬盘及特定的网络硬盘,依靠商用亚马逊的网络服务,使用户的数据存储管理拥有更高可靠性。2. S3不同于寻常的云存储服务,并非面向一般消费者的,而是
40、面向开发者的。自己独立提供所有操作的API,并不是一个独立的网络应用。同时已经有很多成熟的开发样本可以参考借鉴。3. 费用便宜。 基于以上几个原因,S3fs使用了S3的服务。由于CAS层很重要的一个职责就是与S3进行数据的交换,下面将详细介绍S3的存储特性及在上S3fs中的实现方法。2.5.1 S3的组成S3核心组成部分为:桶(bucket),对象(object),关键字(key)。一个桶,简单地说,就是一个存储在亚马逊 S3上的对象的容器.每个对象都包含在一个桶内.例如:如果名为photos/puppy.jpg的对象存储在johnsmith桶中,那么可以用URL: 对象则是用户在S3上存储数
41、据的实体。每一个对象大小限制在1字节到5G字节不等。并能够包含元数据。这些包括一些默认的元数据如最后一次修改时间和标准HTTP元数据如内容类型。开发人员也可以在对象存储时指定自定义的元数据,自定义元数据必须以”amazon-S3-meta”开头。关键字是一个对象在一个桶内唯一的标识。Amazon S3可以被认为是“桶+关键字”和对象本身之间的一张数据地图。每一个Amazon S3中的对象都可以通过服务端点、桶名和关键字的组合唯一地找到。2.5.2 S3提供的常用操作 创建桶: 通过用户自己命名的名字创建一个桶存储对象。桶的名字是全局唯一的,即你所选的桶的名字必须是在S3的服务器内唯一的。 写对
42、象:通过创建或重写一个对象存储数据。当你写出一个对象时,你在你的桶中就确定了一个唯一的关键字,此时你也可以在此对象上指定任何你需要的访问权限控制. 读取一个对象: 即将S3上的数据下载下来。 删除对象/桶:删除不需要的数据/桶。 另外,删除桶时必须为空,不支持递归删除。 列出关键字: 通过筛选关键字名,列出全部或部分关键字。相当于查找的功能。2.5.3 亚马逊S3的一致性模型对一个关键字对象的更新是原子型的。例如:如果你对一个已存在的关键字进行写对象操作,接下来的读操作可能返回旧的数据也可能返回新的数据,但绝不可能写入损坏的或不完整的数据。 亚马逊S3通过对亚马逊的数据中心的各个服务器复制数据
43、达到了高度的可用性。在一个“成功”返回后,你的数据就得到了安全的存储.然而,在成功操作之前,再对相同对象进行操作,则会依据原始数据进行操作。如在更新一个对象后,传送到桶内过程未完成之前,再次读该对象,则会返回修改前的对象。另外,S3不提供对象锁定,比如两个用户端在同时对同一个对象进行写入,则S3只会记录以时间上最后更新的数据对象。2.5.4 S3的身份认证当创建一个AWS帐号时,AWS(亚马逊网络服务)会赋给你AWS访问密钥标志符和一对相关的证件:访问密钥ID(一个20个字符长的字母字符串),例如:022QF06E7MXBSH9DHM02,秘密访问关键码(一个40个字符长的字母字符串)。例如:
44、kWcrlUX5JEDGM/LtmEENI/aVmYvHNif5zB+d9+ct。 根据这两个标志符就可以确定用户的合法权限。在S3fs的开发过程中,将AWS访问密钥ID的秘密访问关键码存为系统的环境变量,S3fs在每次操作的时候都会调取该环境变量以获得操作权利。因为S3fs还处在实验阶段,所以并没有考虑到过多的权限安全问题。考虑在今后的开发中,可以将该密码存于文件并将文件的读取权限设为仅特定用户可见。2.5.6访问权限控制每个Amazon S3中的桶和对象都有一个ACL(access control list,访问权限列表),它定义了访问权限控制策略。当进行一个请求时,Amazon S3 使
45、用标准验证过程来验证请求,然后检查ACL来确认发送者被赋予了该桶或对象的访问权。如过发送者得到准许,请求继续,否则,Amazon返回一个错误。一个ACL是一列授权,一个授权包括一个授权者和一个权限。ACL 仅仅赋予权限,而不能否定权限。桶和对象的ACL完全独立,一个对象不会从它的桶中继承ACL。例如:如果你创建一个桶并赋予另一个用户写权限,你将不能够访问该用户的对象,除非此用户明确地赋予权限。当你向匿名用户赋予一个桶的写权限时,这种情况仍然适用,只有 “匿名的”用户才有权访问该用户创建的对象;除非桶的主人被明确地赋予了权限。S3明确了一下几种授权者类别:l Owner 主人l User by
46、E-mail 通过Email使用的用户l User by Canonical Representation 标准表示的用户 l AWS User Group AWS 用户组 l Anonymous Group 匿名用户组其中主人,即对象及桶的创建者;通过email和标准表示用户是桶的主人通过email或S3网站对某特定用户进行授权;AWS用户组为所有拥有AWS的用户;匿名用户组则允许所有人访问。S3还规定了权限操作:可写、可读、可读权限ACL、可写权限ACL以及全权控制。另外一个ACL有最多100个授权项。第三章 S3fs文件系统的设计S3fs是基于Fuse用户态文件系统的框架下、linux2
47、.6内核环境下开发的,在毕业设计期间由两名同学共同分工完成。本系统使用C语言和perl脚本语言进行开发,提供了一种Linux环境下依附于文件系统的数据块级别的在线备份系统。S3fs文件系统具有以下系统功能: 该系统提供文件级别的远程数据备份,所有本地数据都存到S3服务器上。 S3服务器与本地磁盘同步,并记录全部路径信息。 通过S3fs中的S3init.pl脚本或其它S3管理工具可以脱离S3fs查看用户数据。用户可以在任何地点任何S3管理工具对S3服务器中的用户数据进行修改,每次S3fs挂载后会自动同步S3服务器。 S3fs文件系统允许数据块级别的重复数据删除,在S3服务器和本地磁盘都会自动进行重复数据块检测并进行冗余数据删除。 S3fs文件系统提供文件级别的连续多版本控制,以最后修改时间作为版本信息标记,所有文件版本保存到S3服务器中,并对普通S3fs用户透明。文件系统用户像使用普通文件系统一样感受不到多版本控制过程。 文件系统自动记录每个文件操作日志。让用户轻松查看操作历史。本章主要介绍了S3fs的设计思想、总体构架以及相关的系统模型实现算法等。3.1系统模型概述S3fs整体系统分为文件系统层和CAS层。如图3-1。其中文件系统层是基于fuse框架