《管理信息化互联网文件存储与共享系统》由会员分享，可在线阅读，更多相关《管理信息化互联网文件存储与共享系统（8页珍藏版）》请在金锄头文库上搜索。
1、FRONT互联网文件存储与共享系统刘斌 刘忠义网络实验室夏冰数据库实验室朱彬软工实验室摘要 本文受Freenet项目的启发，设计并实现了一个具备存储和共享功能的互联网分布式文件系统Files Reiable ON inTernet (FRONT)。FRONT在操作系统的文件系统之上提供了一层新的虚拟文件系统，上传到FRONT系统的文件被适当地切分并分配到网络中某些节点上。通过文件分块表或文件块复制和缓存，用户得以利用FRONT实现可用高效的文件访问。FRONT系统使用磁盘配额和固定共享空间比例的技术来配合这个虚拟文件系统，来解决P2P应用中的Free rider问题。Front使用Random
2、 Walk算法进行文件定位，并且在网路规模变化时保持系统中文件的高可用性和高性能。实验表明本文实现FRONT系统运行正确，性能有待进一步实验。关键词 分布式系统、P2P、网络存储、文件共享I. 介绍A. 工作动机今天互联网上已经有许多成熟的P2P文件共享系统，例如BT、迅雷、Maze等，它们的存在极大地丰富了普通网民可以访问的互联网资源。这些系统着重于将互联网上的文件以P2P的方式共享给更多用户。几乎在这些P2P共享协议在开始被研究和应用的同时（2001年），学术界也曾热烈地讨论过在互联网络上提供开放的存储服务的分布式文件系统，一些著名的系统包括CFS、Gnutella、FreeNet等。今天
3、仍有一些个人和组织在这些协议的基础上开发扩展和应用。但是由于版权、用户激励、网络封禁等等原因，这些系统一直停留在研究阶段或者很小规模的应用。随着网络的普及和计算服务的无所不在，普通用户开始在一个以上的计算机上进行文件存取；并且越来越多的群体或组织的成员参与到互联网上的协作和共享。这样的需求可以使用分布式的文件存储和共享技术来满足。本文是几位研究生在学习分布式系统课程之后的一次尝试，希望开发一个具有一定可扩展性的分布式文件系统FRONT（Files Reliable ON inTernet），用户可以使用这个系统实现高效的文件存储与访问。B. 本文内容FRONT文件系统最主要受到FreeNet6
4、项目的启发。FRONT系统无须依托任何基础设施，当文件存储或者共享的需求产生时，它即可从一台主机的规模开始扩展，在网络规模和共享空间逐渐扩大的同时，它可以持续提供高可用、高性能的文件存储与共享服务。FRONT采用用户磁盘配额的方式，让每一台主机向整个系统提供存储空间，并通过控制共享空间与用户需求空间的比例来避免free rider问题。FRONT系统对用户上传的文件进行适当地切分，使之映射为操作系统的文件系统之上的虚拟文件系统Front VFS中的文件。文件分块的设计让用户可以上传更大的文件，并且流行的文件块将被分配到更多的机器上，带来更高的访问性能。新的一层虚拟文件系统还造成了用户对磁盘空间
5、使用的不透明性，又一次保证了客户端在使用系统的同时提供必要的服务。在文件分块后，系统中需要存储的数据包括文件的分块表和文件块两种类型。文件分块表使用“发布者用户空间”上的路径来定位，文件块使用对数据内容的哈希来定位。为了提供高可用性和高性能，FRONT在文件块的级别在系统中实现了复制和缓存。FRONT对于局域网构成的网络还做了特别的优化处理，让处在同一个以太网络内的本地用户高效地利用网络，并降低对整体网络的负担。另外，FRONT系统中节点的通讯组织方式提供了高效的文件查找功能。这些都将在下面的章节中系统介绍。下文的主要内容：第II部分描述了Front文件系统对于应用场景的假设，并分析在假设情况
6、下的文件系需要解决的问题。第III部分是对Front文件系统的结构设计。第IV部分是本文的主要部分，介绍了开发Front文件系统的细节。第V部分讲述了Front文件系统的运行情况，分析对比了与其他文件系统的区别和特点。最后第VI部分是对本文工作的总结和展望。II. 假设和问题我们基于互联网上的存储和共享需求设计并实现了Front网络文件系统，为互联网用户提供了高效可靠的文件服务。它适用于在下文定义的一些假设情况，我们认为这些假设有较强的普遍性和适应性，满足了很多应用需求。这些假设包括以下几点：1） 互联网中存在多个节点，无论它们是否邻近。它们愿意共同组织一个文件存储和共享平台。这个平台可以选择
7、由预先定义的用户组成，与Internet上可能存在的其他front网络没有交互。2） 每个参与的节点提供存储空间和一定的网络带宽。每个节点的空间组合起来构成全局大容量的存储共享空间。节点在自己的文件需要的容量之外还能够提供一定比例的“服务空间”，用于存储全局的其他文件，为别人提供服务。3） 文件系统的文件发布和下载对于用户来说好像本地的一样。节点上的用户不用关心文件传输的事情，包括文件内容从哪里获得、发往哪里。分布式系统数据复制和协议通讯对用户都是不可见的。4） 一些节点组成的分布式网络中。发布和下载的需求并不一定是对称的。例如在一个极端情况下，一个网络中总是由一个节点在发布（上传）文件，其他
8、节点都是不同需要的下载者。5） 文件系统提供的语义是只读的。文件发布后即可由他人获得，但不可修改。6） 向Front网络上发布的文件可能很大，甚至大于本地节点提供的共享空间容量。但只要front网络平台上还有空间，它就应该上传成功。本文需要设计一个网络文件系统，满足以上假设的应用场景，并且保证这个分布式文件系统的高可用和高性能。需要解决的问题有下面3个方面：a) 本地文件系统首先，为了在本地保证用户提供的“共享空间”比例，Front在本地磁盘上的存取应该对用户有一定的不透明性。也即用户看不到是什么数据（在操作系统里看就是文件）占用了本地磁盘。一种可行的方案是，用户在操作系统里看到的存储文件不是
9、发布到Front系统的文件的直接形式。发布的文件可以经过某种转化后存在磁盘上，用户不知道那个什么文件是自己需要的还是提供给他人的，因此不太愿意去冒险删掉其中的一部分。从这个角度上可以部分解决P2P系统的Free Rider问题。一种简单的磁盘存储不透明性可以用文件分块来实现。通过把文件切分成一定大小的文件块，可以自然的把系统上的众多文件数据“混淆”在一起。把文件分成块，还可以简化一个节点上传大于本地空间大小的文件的设计。另外，在分布式文件系统中，我们希望资源（包括复本）可以均匀的分布在更多的节点上，这样可以带来更高的可用性和性能。显然，当文件分成较小的块时，系统中的大文件也更加容易实现在网络中
10、的这种分布。文件分块的一个额外开销是需要在这个网络中维护文件分块信息，并且对文件的请求被分为多个不走。另一个需要在本地处理的问题是，当资源请求超过了本地磁盘配额，如何权衡用户的需要得到满足和节点同时为网络提供存储服务的矛盾，Front系统本地需要一个安全有效的数据替换算法。b) 网络互联和文件查询网络上需要协作的Front节点需要一种办法来知道彼此的存在。节点加入和离开对网络的影响不能太大。因此当网络规模较大时，节点之间不可能两两可知的。相互可知的节点互为邻居，并且可以彼此交换信息，以增强网络连通性或者传递查询请求等。一个理想的网络连接情况是：临近（IP或者地理位置）的节点尽可能互为邻居，形成
11、连通性较强的局部网络；距离较远的节点之间保持一定的连通，这样才能让远处的查询得到本地的信息，让整个网络的信息通畅。为了避免网络中的节点孤岛，需要一种方法显式地加入已经存在的网络。文件的查询涉及命名和查询路由。文件在系统的命名最好可阅读的，并且具有一定的区分性。后者让不同用户发布文件较难产生命名冲突。对于系统内部，对文件（可能被切分成文件块）的识别应该是唯一的，可以跟可阅读的文件名一一对应。另外，不同的用户可能发布完全一样的文件，应该被识别并且利用起来。当网络中的节点向路由器一样连接起来后，每个节点根据本地邻居信息，以一定的方式将请求和应答在分布式系统中传播，最终使请求发起者获得文件的信息。c)
12、 数据复制和传输系统中的文件数据需要被合理地分配在分布式节点上。这一点保证系统中的文件以尽可能大的概率存在于网络中并且可达。同时对于文件的传输请求也可以向传统P2P网络中那样从多个目标节点同时开始。当文件被分块后，文件的结构信息也应该被广泛地分布于整个网络中，以使得被更多的节点可知。数据复制的触发可以放在发布时，当节点有可能探测到文件的复本可能在网络中下降时，或者很受欢迎被很多人请求时，也应该出发复制（在后一种情况中被称为缓存）。III. 系统结构设计为了解决第II部分提出来的几点问题，设计Front网络文件系统需要考虑的几个模块的交互。Front系统及节点的本地结构如图表一所示。图表 Fro
13、nt系统节点的本地结构系统中所共有的Front结构信息在common structures里定义。Front Virtual File System是本地与操作系统的文件系统交互的唯一模块，它通过将文件分块，并维持本地文件结构表和本地分块表，来向上层提供一层虚拟的文件系统。Networking component模块负责与其他节点的通讯和数据传输。在FrontVFS和Networking componet之上的一层是Front文件系统的对外接口FSClientNode。FSClientNode就好像一层中间件，可以向上层提供可以实现网络存储和共享的文件系统。在我们的实现中，我们设计了用户界面来
14、调用FSClientNode，即实现了一个完整的客户端。关于每个模块的实现将在第IV部分介绍。IV. 实现FRONT互联网文件存储与共享系统的实现，分成以下5个部分来介绍。A. 命名Front文件系统的命名问题属于第V部分介绍的Front common structures部分。上文已经提到，每个文件应该拥有一个可阅读（human readable）的文件路径。这个路径在用户发布是制定。有namespace域和systempath域组成。文件系统内部使用的定位符(identifier)统一使用128位数据来表示。针对文件的定位符，根据可阅读的文件路径经过MD5计算得到。因此，请求文件的用户只要
15、知道这个可阅读的文件路径即可发出请求。针对文件块的定位符，根据文件块数据内容经过MD5计算得到。这样当一个固定的文件被分块时，如果能够保证分块结构总是一致，那每一块计算得到的定位符也是相等的。这个特性有利于Front系统对发布相同文件的识别和利用。下文将会提到，Front VFS对于相同的文件，分块的结果是一致的。B. 本地文件系统FRONT VFSFRONT VFS是建立在操作系统文件系统之上的一层文件系统，用户与在整个系统中与FRONT VFS进行交互。对系统中存在的文件我们选择了对其进行分块。分块的好处首先在于一个节点存放不下的文件可以分开存储在多个节点上。第二，如果用户修改某个文件的一
16、部分，重新发布时很可能有的块并没有变化，此时只需发布更改过的块即可。第三个好处在于可以均衡负载，用户可以同时从几个网络节点上下载不同的块来达到加速传输的目的。考虑下面一种情况：网络中有三个节点存储三个300M的文件，每个节点指定的共享空间为300M。那么，如果我们将三个文件都分成三个块，分布在三个节点。这样用户下载每一个文件时都可以从三个节点同时下载三个块，比文件不分块时必须从单个节点下载的情况效率要高。但是，分块同时带来了资源存在的不确定性。如果存放一个文件的某个块的节点关机，系统中又没有该块的备份，那么这个文件就无法被完整获得。分块越多分布越广越容易出现这样的问题。除了采取一定的复制策略外，我们的分块算法也保证一个文件不要分成太多的块。根据文件大小所在的不同区间，我们对文件采取不同的分块策略。分块算法如下：int chunkSize;int times =
