GiPS系统理论与制造.docx
- 文档编号:30711943
- 上传时间:2023-08-19
- 格式:DOCX
- 页数:15
- 大小:222.34KB
GiPS系统理论与制造.docx
《GiPS系统理论与制造.docx》由会员分享,可在线阅读,更多相关《GiPS系统理论与制造.docx(15页珍藏版)》请在冰豆网上搜索。
GiPS系统理论与制造
GiPS系统理论与制造
摘要:
分布式文件系统(DFS)是一种网络文件系统,它分布在多个计算机节点上,每个节点只会直接存取整个文件系统的一部分。
我们参考了两个比较成熟的DFS架构——GFS和Hadoop,设计并实现了GiPS文件系统。
GiPS是一个面向数据密集型应用的分布式文件系统,整个系统由Master节点、数据节点和客户端组成,具有一定的容错性和可扩展性。
我们使用了适用于异种环境的面向对象中间件平台ICE,并使用C++语言进行开发实现。
测试和试验表明,GiPS具备了文件系统的基本功能,实现了对数据的流式读写操作,并有一定的容错功能。
关键词:
分布式文件系统;GFS;GiPS
1引言
分布式文件系统(DFS)是一种网络文件系统,它分布在多个计算机节点上,每个节点只会直接存取整个文件系统的一部分。
一般来说,分布式文件系统都会包括复制和容错功能,从而保障系统在某些节点出错的情况下仍能够继续正常工作,而不会出现数据丢失的情况。
DFS中的客户端、服务器端和存储设备分布在系统中的不同机器中,因此,它的服务必须通过网络来实现。
DFS的具体结构和应用可以有很多种,服务可以在一些指定的机器上运行,也可以同时在客户端和服务器端运行,系统可以被实现为分布式操作系统的一部分,也可以成为一类专用于管理传统文件系统之间通信的软件。
DFS最突出的特点,是其中的服务端和客户端的多样性和独立性[1]。
GiPS是一个面向数据密集型应用的分布式文件系统,系统的主要功能和应用集中于文件的分布式存储和读写。
整个系统由Master节点、数据节点和客户端组成。
它具有一定的容错性和可扩展性,屏蔽操作系统和硬件的异构性。
整个系统的设计参考了GFS和Hadoop系统的架构,使用ICE和C++进行实现。
2相关背景
2.1GFS
GoogleFileSystem(GFS)是由Google设计并实现的一个分布式文件系统,它基于大量安装有Linux操作系统的普通PC构成的集群系统。
整个系统由一台Master(通常有几台备份)和若干台ChunkServer构成。
GFS中文件备份成固定大小的Chunk分别存储在不同的ChunkServer上,每个Chunk有多份拷贝,也存储在不同的ChunkServer上。
Master负责维护GFS中的Metadata,即文件名及其Chunk信息。
客户端先从Master上得到文件的Metadata,根据要读取的数据在文件中的位置与相应的ChunkServer通信,获取文件数据。
GFS以64M为一个Chunk(Block),每个Chunk至少存在于三台机器上。
高可靠性是GFS最重要的特点。
GFS使用的是可靠性较差的普通PC,节点失效属于正常现象,因此解决单节点甚至双节点同时实效成为一个重要的问题。
在Google应用环境中需要处理海量数据,经常有大文件(几十G)的操作,而且常是多台机器同时数据输出到一个大文件中,供后面的流程使用。
GFS也对这种特殊的应用需求做了很多优化,保证往大文件并发追写数据时的可靠和高效[2]。
Google拥有超过200个的GFS集群,其中有些集群的计算机数量超过5000台。
Google现在拥有数以万计的连接池从GFS集群中获取数据,集群的数据存储规模可以达到5个PB,并且集群中的数据读写吞吐量可达到每秒40G。
图1GFS架构
GiPS系统借鉴了GFS的Master、Chunkserver、Client框架,实现了文件的分块存储,将文件分成多个大小为64M的文件块。
GiPS中的数据节点同样是构建于普通的PC机上,为解决可能频繁出现失效问题,系统实现了一定的容错功能。
2.2Hadoop
Hadoop是一个开源的分布式软件平台。
基于Hadoop平台,用户能够方便的开发和运行能够处理海量数据的应用程序。
Hadoop实现了MapReduce,能够把任务分配成多个部分,分配给集群中的节点进行处理。
Hadoop构建了分布式文件系统HDFS,系统中的数据被存储在不同运算节点中。
Yahoo已定期在搜索业务上使用Hadoop来增强其产品服务,如排名和广告功能等。
Hadoop的长期目标是提供世界级的分布式计算工具。
Hadoop借鉴了GFS的设计理念。
Hadoop同样认为硬件错误是正常的,而不是异常。
因此,检测错误并快速自动恢复就成了HDFS的核心设计目标。
HDFS为了那些批量处理而设计的,而不是为普通用户的交互使用,强调的是数据访问的高吞吐量而不是数据访问的低反应时间。
HDFS的应用程序需要对文件实行一次性写,多次读的访问模式。
文件一旦建立后写入,文件就不需要再更改了。
运行在HDFS上的应用程序使用大数据集。
HDFS一个典型的文件可能是几GB的或者几TB的。
Hadoop认为,把计算迁移到数据存储的近处要比把数据传输到程序运行的地方更好,HDFS提供了程序接口以便把他们自己移动到数据存储的地方执行。
HDFS设计为容易的从一个平台移动到另一个平台。
这有助于HDFS被采用做为一个大程序集合的工作平台。
对于一个大文件,Hadoop把它切割成多个大小为64M的block。
这些block是以普通文件的形式存储在各个节点上的。
默认情况下,每个block都会有3个副本[3]。
在Hadoop中,有一个master节点和多个数据节点。
客户端执行操作时,只需与master节点通信,获得所需要的文件操作信息,然后与数据节点通信,进行实际数据的传输。
2.3ICE
GiPS是基于ICE中间件平台实现的。
中间件能够使应用软件相对独立于计算机硬件和操作系统平台,为分布式应用搭起了一个标准的平台。
中间件具有标准的程序接口和协议,可以实现不同硬件和操作系统平台上的数据共享和应用互操作。
在具体实现上,中间件是一个用API定义的分布式软件管理框架,具有强大的通信能力和良好的可扩展性,可以大大提高开发效率而缩小应用开发的时间和精力,提高应用开发的成功[4]。
ICE(InternetCommunicationsEngine)是一种面向对象的中间件平台,为构建面向对象的CS应用提供了工具、API和库支持。
Ice适合在异种环境中使用:
客户和服务器可以用不同的编程语言编写,可以运行在不同的操作系统和机器架构上,并且可以使用多种网络技术进行通信。
无论部署环境如何,这些应用的源码都是可移植的。
ICE提供了一组完整的特性,支持广泛的领域中的分布式应用的开发;避免不必要的复杂性,使平台更易于学习和使用;在网络带宽、内存使用和CPU开销方面的效率都比较高;提供一种具有内建安全性的实现,适用于不安全的公共网络。
Ice构建了与CORBA等平台一样强大的中间件平台,而又尽量避免了它们的缺点:
.Net平台无法支持非Windows的操作系统;CORBA的体系庞大而复杂,近年的更新也很慢;WebService模式的效率不高,并且面临着安全问题[5]。
Ice提供了专用的接口描述语言——Slice,描述了客户端和服务端都必须遵循的接口规范,而且也可以用来描述持久数据。
3系统设计
3.1系统架构
图2是GiPS系统的总体架构图。
系统由Master节点、数据节点和客户端组成。
Master节点负责维护文件系统的全局元数据、文件目录结构、文件的块信息;数据节点储存文件块,维护本地文件目录;客户端则是对文件系统的访问接口。
注意节点可以无障碍的运行于Linux操作系统和Windows操作系统上。
在设计GiPS系统时,我们认为Master节点是不易出错的,而数据节点因为频繁的I/O操作,比较容易发生错误,因此系统需要满足容错性的要求。
图2GiPS系统架构图
在GiPS系统中,文件的存储和组织是以块为单位的。
1个文件可以由多个块组成,但每个块只能存储1个文件的内容。
与GFS和HDFS相同,我们把每个文件块的大小定为64M。
这种选择是具有一些优势的:
它减少了客户端和master的交互,对同一个文件块内的读写操作只需要客户端向master请求一次文件块信息就可以了;大的文件块使客户端可以在其上完成更多的操作,从而通过保持一个到数据节点的TCP连接来减少网络开销;另外它也减少了master节点上元数据的大小[2]。
TFS(TiwangFileSystem)采用了任意块大小的策略,试验表明可以将append操作的效率提高25%,但读操作的效率并不尽如人意[6]。
3.2系统功能
GiPS系统目前主要实现了完整性检查、文件操作、容错性等功能。
3.2.1完整性检查
在文件系统第一次启动或是Master出现故障重新恢复时,系统进入安全模式状态,并执行初始化操作。
系统中的数据节点向Master节点发送接入请求,Master将这些节点作为初始成员,建立文件系统。
Master读取元数据文件,检查文件的完整性,包括:
1.每个文件的所有分块都应该至少有1个副本,如果文件中某一块的所有副本都不存在,则该文件标记为损坏;
2.对于没有损坏的文件,每个文件的所有分块都应有规定数量(默认为2)以上的副本,如果副本数目小于系统设定的阈值,则在现有的数据节点中,按照它们的负责情况选取负载较小的节点进行冗余备份。
经过以上两步之后,系统初始化完成,开始提供文件服务。
3.2.2文件操作
基于命令行方式,实现对文件或目录的创建、删除等操作,实现对文件的流式读写操作。
文件的存储和读写操作是在考虑数据节点存储负载均衡的前提下进行的。
3.2.3容错性
系统具有一定的容错性。
在读写文件发生错误时,系统会选取新的数据节点完成读写操作;Master节点会定期检查数据节点的状态,当系统中的某个数据节点发生当机的情况时,系统会按照3.2.1中所述的方式尽可能维护文件的完整性。
3.3系统模块设计
3.3.1Master节点
Master节点承担了以下一些任务:
1.全局元数据维护。
元数据包括了数据节点的基本信息、文件目录、文件块信息等,数据节点的基本信息包括节点id,硬盘、内存使用情况等;文件块信息包括用户文件分块情况以及块文件在数据节点中存储文件名的映射等。
2.文件完整性检查。
包括系统启动时的完整性检查,数据节点故障时系统完整性的维护。
3.在适当的时刻,对那些不满足备份要求的文件,根据数据节点的基本信息选择负载较小的数据节点进行文件块备份操作。
4.当客户端发送针读文件请求时,根据文件块信息找到所有存有所需文件块的数据节点,并根据它们的基本信息选择其中负载较小的节点,返回相应的文件块表给客户端。
5.当客户端发送写文件请求时,首先把文件写到一个数据节点上,然后在其他数据节点中按负载均衡原则选取合适的来备份文件块,并将这些数据节点信息返回给客户端。
6.当发生数据节点加入或退出的情况时,维护相应的数据节点基本信息、文件块信息等。
检查文件的完整性,对数据块不足的文件标记损坏。
7.日志功能。
系统会定期记录文件目录和文件分块信息,以便于维护。
当Master执行初始化操作时,从日志中重新读取这些信息,在内存中重建文件目录表和文件分块表。
3.3.2数据节点
数据节点负责以下功能:
1.定期向Master节点发送自身状态信息,包括硬盘、内存使用情况和所存储的文件块信息等,以便于Master节点维护全局目录和及时处理出错情况。
2.维护自身文件目录,在内存中保存本地文件块表。
3.处理客户端的读文件块请求,根据客户端发来的块id在本地内存的块表中得到文件路径,读取并发送相应的文件块。
4.处理客户端的写文件块请求,按照文件块id将数据写入相应的位置,并将文件路径存入文件块表。
5.日志功能,定期记录数据节点上所保存的文件块信息,当数据节点执行错误恢复操作时,从日志中读入这些信息,在内存中重建文件块表。
3.3.3客户端
客户端直接面向用户,为用户提供了进行系统操作的终端。
GiPS客户端根据系统定义的接口,实现了文件或目录的创建、移动、重命名、删除等操作,并提供了文件流式读写操作接口。
当用户输入命令时,客户端将用户的请求发送到Master节点,从Master节点获取所需的文件目录和文件块信息,根据这些信息,连接相应的数据节点进行数据操作。
4系统实现
GiPS系统基于ICE平台进行开发,使用Slice接口描述语言定义了模块和接口。
4.1客户端与Master节点通信模块定义
moduleClientMaster{
sequence
//文件块结构
structFileBlock{
longblockID;//文件的块序号
stringindexID;//所属文件的ID
desIPListIPs;//储存这个块的节点列表
};
sequence
sequence
//用于处理client请求的接口
interfaceFileObjectsManager{
//得到某个文件的存储信息
boolgetFileObjectStorageInformation(stringfileName,outFileObjectfileObj);
//设置某个文件的存储信息
boolsetFileObjectStorageInformation(stringfileName,FileObjectfileObj);
//在写文件之前,请求master为这个文件分配存储节点
desIPListgetStorageNodes();
//列出当前系统中的全部文件
listgetFSList();
//创建目录
boolcreateFolder(stringfolderName);
//删除目录
booldeleteFolder(stringfolderName);
//删除文件
booldeleteFile(stringfileName);
};
};
4.2Master与数据节点通信模块定义
moduleCluster{
//clerk节点向master发送的心跳消息结构
structHeartBeatMessage{
stringip;//本节点ip
intblockNum;//当前节点中文件的块数
};
//备份时,一个文件块副本的结构
structReplicaInfo{
stringreplicaID;//需要被备份的文件块索引ID
stringclerkIP;//目的节点的ip
};
//clerk在master上注册的回调函数
interfaceClerkCallBack{
//报告clerk当前的状态
idempotentvoidreportState(outHeartBeatMessagehbMsg);
//对某个副本执行备份操作
boolreplicaCopy(ReplicaInforepInfo);
//对某个副本执行删除操作
boolreplicaDelete(stringreplicaID);
};
dictionary
//clerk向master注册的接口
interfaceClusterMessenger{
voidclerkCallBackRegister(stringclerkIP,ClerkCallBack*clerkcb);
};
};
4.3Client与数据节点通信模块定义
moduleClientClerk{
//二进制数据流
sequence
interfaceFileIOManager{
//向GiPS写文件
boolwriteFile(stringblockIndex,BinaryDatadata);
//从GiPS中读文件
boolreadFile(stringblockIndex,outBinaryDatadata);
};
};
4.4Master节点运行流程
4.5文件读写操作流程
写文件流程如图1所示:
(1)Client向namenode获取当前集群中各个节点的信息,namenode返回当前集群中各个节点ip的列表,列表依据各个节点的负载排序。
(2)Client向列表中的第一个datanode,写入全部数据,如果期间发生错误,则向列表中的下一个节点写入,直至写入成功或所有节点均写入失败。
假设向datanode1写入成功。
(3)Client将数据写入datanode1成功后,将相关信息高速namenode:
包括datanode1的ip,存储文件名,文件所分的块数,以及各块的索引ID。
(4)namenode开始让datanode1备份,namenode告知datanode1需要备份的文件块索引ID,以及目标datanode的ip。
(5)namenode1执行备份,将相应块备份至目标datanode。
(6)同(5)
图1写入文件流程图
读取文件流程如图2所示:
(1)Client向namenode发出读取请求,告诉namenode要读取的文件名,namenode返回该文件所分文件块的相关信息:
包括各块所在datanode的ip,以及每块的索引ID。
(2)Client依据每块块所在datanode的ip以及每块的索引ID开始依次读取文件酷爱,如果某块读取失败,则挑选备份datanode来进行读取,直至读取成功或所有备份datanode均读取失败。
图2读取文件流程图
5试验与讨论
限于试验条件,我们只在三台普通PC上配置了GiPS系统,试验环境的网络带宽为100Mb,三台PC中有两台的硬件配置基本相同,另外一台的使用时间相对较长,运行状态不如其他两台稳定。
我们选取了一些不同大小的文件进行系统测试和试验。
测试过程中,系统能够完成上文所述的各种功能,实现了文件分布式存储,并基本满足数据节点负载均衡的要求。
由于我们将文件块的默认备份数目设置为2,因而执行文件写入操作时,系统内部实际数据传输量应为写入文件大小的2倍,写操作时间应大致为读操作时间的2倍。
另外,测试PC相互间的网络速度基本相同,因此决定文件读写速度的主要因素是机器的硬盘转速和运行状态。
编号
文件大小
(MB)
写操作
时间(s)
读操作
时间(s)
写/读时
间比
实际写速度(MB/s)
读速度(MB/s)
1
13
3.828
3.572
1.07
6.79
3.64
2
79
36.11
16.406
2.201
4.38
4.82
3
125
50.312
33.728
1.49
4.97
3.71
4
154
70.313
30.937
2.27
4.38
4.98
平均文件传输速度(MB/s)
4.54
表1GiPS试验数据
表1列出了试验中的部分数据,基本符合理论分析的结果。
其中文件2与文件4的试验结果比较接近,并且与系统平均速度基本一致。
而1、3数据出现了一定偏差,它们的读速度基本相同,都明显比系统平均速度慢,而写速度反而较快;文件1的写入速度明显远高于系统平均速度,表现为文件1的读写时间非常接近。
我们认为出现这些情况的原因是系统所用PC的硬件情况不一致,文件1和文件3在写操作的文件块分配过程中,被比较多的分配到了运行状态不太稳定的节点(我们没有具体检测该节点硬件的详细状况,但读取速度明显慢于写入速度的试验结果,可能说明该节点的硬盘出现了一些问题),导致读写速度与平均速度相差较多。
文件1由于比较小,在试验的网络环境下,传输时间比较短,从而更容易出现速度偏差较多的偶然情况。
在文件块的分布上,3台PC上的存储负载基本一致,说明系统满足数据节点负载均衡的要求。
但从试验结果也可看出,在数据节点硬件配置不一致,甚至个别节点硬件状况可能存在问题的情况下,存储负载均衡的策略也会使得文件读写速度不稳定。
因此在决定文件块在数据节点间的分配时,可以把节点的硬件情况当作考虑因素之一。
由于试验环境限制,所能使用的节点数目和测试数据的数量都比较小,结果可能不能完全表明GiPS的运行效率。
理论上说,如果有足够多的节点和数据量,读写速度不稳定现象的出现概率应能明显降低。
6总结
我们借鉴了GFS和HDFS的设计思想,在ICE中间件平台上开发了GiPS分布式文件系统。
根据测试和试验,系统实现了分布式文件系统的一些基本功能,具备一定的容错性,并达到了理想的运行效率。
按照最初的设计,GiPS应能屏蔽操作系统和硬件的异构性,实现跨平台的系统。
目前只实现了运行于Windows系统的版本,我们希望进一步开发出能够与Windows版本无障碍共存的基于Linux系统的版本。
对于系统中的一些主要参数,如文件块大小、文件块备份数目等的设置,我们是参考了GFS等成熟系统的经验,并根据试验环境的实际条件决定的,这些设置是否可以最佳地符合GiPS的应用环境,还需要进一步的试验来调整。
参考文献
[1]Wikipedia.http:
//en.wikipedia.org/wiki/Distributed_file_system.
[2]S.Ghemawat,H.Gobioff,andS.-T.Leung,"TheGooglefilesystem,"SIGOPSOper.Syst.Rev.,vol.37,pp.29-43,2003.
[3]19-22.HadoopWiki.http:
//wiki.apache.org/hadoop
[4]周元春,李淼.中间件技术[J].计算机工程与应用,2002(15):
80-851
[5]MichiHenning,MarkSpruiell.DistributedProgrammingwithICE.ZeroC,Inc.2007.
[6]TFSProject2008
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- GiPS 系统 理论 制造